Part of the awkwardness in the post is also mixing what looks like express with promises. I think using an async function as the handler with express 5 would probably feel a lot nicer.
I agree about CORS being frustrating. I think we should have allowed totally anonymous fetch requests across domains for saved to home screen PWAs (or with a permission prompt.) Missing that feature means you end up needing native apps for a lot of things that otherwise are totally reasonable web apps. CORS does make sense though because the alternative is drive by attacks against your local network from random web pages. And since the S in IOT stands for security that seemed like a bad idea at the time.
Recently I've been building tools like this in tampermonkey (greasemonkey but newer/oss) since those scripts run in an environment where exceptions can be made to bypass CORS, and do a lot of things that in-page javascript just can't get access to.
I sympathize with the authors pain, and at least from the comments, it sounds like most have a similar view of CORS. Many weeks of face -> keyboard in response.
At some point trying to write JS, I really started believe that the people who implemented CORS did it just to break every single part of the world wide web that might ever be enjoyable.
It really felt like somebody held out a beautiful idea with AJAX, and requests lacking synchronization, and then the only response was endless exploits, security holes, patches that took away functionality, and posts like the authors. "This idea seems so simple...nevermind, 'Access-Control-Allow-Origin' ERROR"
There is another solution, in this specific case. If all they wanted is to start returning the test results before all the tests are done, a streaming http response can be used.
In Bottle, returning a generator or iterator will send the response in chucks, instead of all at once. The effect would be that the test results load in one by one, providing the user with feedback. No JavaScript needed.
> It was also getting harder and harder to debug as JavaScript has no timeout functionality I would have had to wrap that request in another promise.
I'm pretty sure you could use an AbortController to address this? But it's one of those things you have to know about. I completely understand the author's frustration with CORS, but I don't think JS is to blame here. I have felt a similar level of frustration whenever I try to use a language other than JS to work with JSON. Does that mean the language sucks? I would say no. I don't think this made a compelling case for avoiding JS, but I would never want to deny someone the catharsis from venting about technology.
> Three days wasted. I should have just written the PHP script .
The good news is that any leading class LLM today would certainly be able to one-shot translation of the script from Python to PHP or create it in PHP.
CORS has killed a lot of my SPA ideas too. Also I've been toying with Svelte which I was told was a lightweight framework. But you still need npm to use it which generates dozens of other boilerplate files.
The JS Frameworks always feel fun to start with, but then I always end up realising how complex and flakey the tool chain is and switch to something simpler.
ASP.NET + alpine.js is my current happy place. If I need a JS lib then I get it from unpkg.com and avoid npm.
Then Docker on a Digital Ocean Container App is a really easy way to CI/CD.
> I feel like every time I look at JavaScript it’s different .
So much truth in this. It's amazing that JS has managed to survive (even thrive!) in spite of the constant fundamental backwards-breaking changes every few cycles. Maybe that speaks to the lack of web based alternatives than anything else.
> [JavaScript's] constant fundamental backwards-breaking changes
wat
TC-39 literally has "Don't break the Web" as an explicit goal.
You are conflating "JavaScript" with something else (possibly some popular packages written in JS, for example—by people who have no control or say over the standard, usually, and with dubious taste to begin with).
By all means, avoid those packages and tastemakers. JS is still JS and still works despite their whims.
> You are conflating "JavaScript" with something else (possibly some popular packages written in JS, for example—by people who have no control or say over the standard, usually, and with dubious taste to begin with).
Readit News
https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal...
Part of the awkwardness in the post is also mixing what looks like express with promises. I think using an async function as the handler with express 5 would probably feel a lot nicer.
I agree about CORS being frustrating. I think we should have allowed totally anonymous fetch requests across domains for saved to home screen PWAs (or with a permission prompt.) Missing that feature means you end up needing native apps for a lot of things that otherwise are totally reasonable web apps. CORS does make sense though because the alternative is drive by attacks against your local network from random web pages. And since the S in IOT stands for security that seemed like a bad idea at the time.
Dead Comment
At some point trying to write JS, I really started believe that the people who implemented CORS did it just to break every single part of the world wide web that might ever be enjoyable.
It really felt like somebody held out a beautiful idea with AJAX, and requests lacking synchronization, and then the only response was endless exploits, security holes, patches that took away functionality, and posts like the authors. "This idea seems so simple...nevermind, 'Access-Control-Allow-Origin' ERROR"
In Bottle, returning a generator or iterator will send the response in chucks, instead of all at once. The effect would be that the test results load in one by one, providing the user with feedback. No JavaScript needed.
I'm pretty sure you could use an AbortController to address this? But it's one of those things you have to know about. I completely understand the author's frustration with CORS, but I don't think JS is to blame here. I have felt a similar level of frustration whenever I try to use a language other than JS to work with JSON. Does that mean the language sucks? I would say no. I don't think this made a compelling case for avoiding JS, but I would never want to deny someone the catharsis from venting about technology.
> Three days wasted. I should have just written the PHP script .
The good news is that any leading class LLM today would certainly be able to one-shot translation of the script from Python to PHP or create it in PHP.
The JS ecosystem does indeed suck.
Isn't this the same with any language ecosystem where you opt to use the package manager?
ASP.NET + alpine.js is my current happy place. If I need a JS lib then I get it from unpkg.com and avoid npm.
Then Docker on a Digital Ocean Container App is a really easy way to CI/CD.
So much truth in this. It's amazing that JS has managed to survive (even thrive!) in spite of the constant fundamental backwards-breaking changes every few cycles. Maybe that speaks to the lack of web based alternatives than anything else.
wat
TC-39 literally has "Don't break the Web" as an explicit goal.
You are conflating "JavaScript" with something else (possibly some popular packages written in JS, for example—by people who have no control or say over the standard, usually, and with dubious taste to begin with).
By all means, avoid those packages and tastemakers. JS is still JS and still works despite their whims.
Those are functionally part of the language