Why is this written in ancient JavaScript in 2022? It just makes everything unclear for no benefit. It uses close to 30 lines to define default arguments, which are now just part of the JS spec. IE11 is not supported by Microsoft. Either you’re writing for modern browsers or for browsers without JS, but there’s no benefit in writing for browser with ancient JS.
Thank you for your feedback. I had in my head that optional function parameters were part of ES6, which has only limited support on the oldest browsers I target. At your suggestion, I learned that this limited support /does/ include optional function parameters and I’ve updated my article accordingly.
As a side note, I found the tone of your remarks to be somewhat confrontational. You may find that your future critiques are more widely received in the generous spirit they are given if you share them in a collaborative tone.
Sorry about the tone. I found the code bugs me because it’s quite difficult to read. I wanted to go back and post a comment rewriting it to be clearer but haven’t had the time yet. The basic idea is you want to separate fetching from retrying. Make a generic retryer that can retry anything and then pass in the fetcher as a specific case.
What browsers are you targeting by the way? And why? In my experience if you don’t actually test in older browsers, there’s no point in trying to write to them because you’ll get something wrong accidentally and have a showstopping bug but not actually know about it. To have working code, it has to be tested in the relevant environment, so the best strategy for someone without QA team is to target both modern JS and no JS, but not old JS, which is impractical to test.
Most developers I’ve met have their own preference on when and how to factor out apparently-generic functionality. My personal preference is to not factor something out until I have at least two concrete uses for it. I think I do a better job of weighing the trade-offs and finding the right place to “draw the line” with a couple of real-world examples to work from. I also know myself well enough to know that I enjoy a good yak-shave, so I try not to tempt myself with developing a “generic method for transferring condiments” when “passing the salt” will suffice.
For lofi.limo I test against Firefox 52 and Chrome 49 on Windows XP, current Firefox, Chrome, and IE on Windows 10, current Safari and Chrome on macOS, and current Safari on iOS. I haven’t found this testing to be burdensome. I support XP because it’s a nice thing to do and it gives me pleasure to do it. I’ve heard from some of my listeners that they like to listen on older, disused hardware in their workshop, sewing room, or similar environment.
Gotcha, makes sense. Glad to hear you’re actually testing it and not relying on intuition. Windows XP is 20 years old. That’s retrocomputing by any definition. Retrocomputing is cool! But your blog post would be more clear if you prefaced it by saying that that’s your audience, not general web devs. I wouldn’t accept a PR that looked like your original code because it’s very hard to read. The browsers added promises and fetch and ES6 etc. because the old code was harder to read and write, and the new code is designed to be easier. But I’m not a retrocomputing developer, so it’s just a different standard, like how demoscene is different or games dev is different. For retrocomputing it makes sense.
Why is this written in ancient JavaScript in 2022? It just makes everything unclear for no benefit. It uses close to 30 lines to define default arguments, which are now just part of the JS spec. IE11 is not supported by Microsoft. Either you’re writing for modern browsers or for browsers without JS, but there’s no benefit in writing for browser with ancient JS.
Thank you for your feedback. I had in my head that optional function parameters were part of ES6, which has only limited support on the oldest browsers I target. At your suggestion, I learned that this limited support /does/ include optional function parameters and I’ve updated my article accordingly.
As a side note, I found the tone of your remarks to be somewhat confrontational. You may find that your future critiques are more widely received in the generous spirit they are given if you share them in a collaborative tone.
Sorry about the tone. I found the code bugs me because it’s quite difficult to read. I wanted to go back and post a comment rewriting it to be clearer but haven’t had the time yet. The basic idea is you want to separate fetching from retrying. Make a generic retryer that can retry anything and then pass in the fetcher as a specific case.
What browsers are you targeting by the way? And why? In my experience if you don’t actually test in older browsers, there’s no point in trying to write to them because you’ll get something wrong accidentally and have a showstopping bug but not actually know about it. To have working code, it has to be tested in the relevant environment, so the best strategy for someone without QA team is to target both modern JS and no JS, but not old JS, which is impractical to test.
Most developers I’ve met have their own preference on when and how to factor out apparently-generic functionality. My personal preference is to not factor something out until I have at least two concrete uses for it. I think I do a better job of weighing the trade-offs and finding the right place to “draw the line” with a couple of real-world examples to work from. I also know myself well enough to know that I enjoy a good yak-shave, so I try not to tempt myself with developing a “generic method for transferring condiments” when “passing the salt” will suffice.
For lofi.limo I test against Firefox 52 and Chrome 49 on Windows XP, current Firefox, Chrome, and IE on Windows 10, current Safari and Chrome on macOS, and current Safari on iOS. I haven’t found this testing to be burdensome. I support XP because it’s a nice thing to do and it gives me pleasure to do it. I’ve heard from some of my listeners that they like to listen on older, disused hardware in their workshop, sewing room, or similar environment.
Gotcha, makes sense. Glad to hear you’re actually testing it and not relying on intuition. Windows XP is 20 years old. That’s retrocomputing by any definition. Retrocomputing is cool! But your blog post would be more clear if you prefaced it by saying that that’s your audience, not general web devs. I wouldn’t accept a PR that looked like your original code because it’s very hard to read. The browsers added promises and fetch and ES6 etc. because the old code was harder to read and write, and the new code is designed to be easier. But I’m not a retrocomputing developer, so it’s just a different standard, like how demoscene is different or games dev is different. For retrocomputing it makes sense.