6 ms·

Indeed. Also, "very painful" is subjective. I never had issues with async code in JS (well, I had bugs, but it's not a fault of the language). There's nothing p

Indeed. Also, "very painful" is subjective. I never had issues with async code in JS (well, I had bugs, but it's not a fault of the language). There's nothing painful in async JS.

1f60c 6y ago
Having to use an async immediately invoked function expression in Node scripts is kind of a pain, but I agree.
- cpfohl 6y ago
  I haven't found it painful, but i avoid iife in favor of a named function I call... ``` async function main() { await stuff(); } if (module === require.main) main(); ```
- infensus 6y ago
  Top-level await is available in ES modules in Node without any flags since 14.8.0
MaxBarraclough 6y ago
Agree, JavaScript's approach to concurrency and asynchronous events is one of its strong points. The model of There is exactly one thread, and everything that could be asynchronous is asynchronous works nicely for web work, keeping things relatively simple (of course, race conditions are still possible) while avoiding the pitfalls of full-bore multithreading. I imagine it also makes things far simpler for the browser engineers. It's the opposite of the old Java Swing approach, where applications would often have far more threads than they really needed. (iirc, NetBeans idles with something like 30 threads.) The await/async feature seems like a sensible addition to JavaScript, but I'm open to the idea that there are alternative solutions that would be even better. As an example, I don't know much about what Java is up to but I understand it's not going with await/async exactly.
- skohan 6y ago
  > There is exactly one thread, and everything that could be asynchronous is asynchronous works nicely for web work, keeping things relatively simple It might keep things simple, but I don't know if this is really a sensible design constraint going into the future. Parallelism is where performance is going to come from in the future, and having the web - the most common way most people consume software - be single-threaded seems like a massive waste of hardware. If I have a 16 core processor just so the add trackers in each of my chrome tabs can run in parallel, this is a world I don't want to live in.
  - girvo 6y ago
    Genuine question, what would the ad trackers be able to do with runtime level parallelism in the JS runtime that they can’t achieve now? Do they do a lot more blocking calculation than I’d expect?
    - vbsteven 6y ago
      Stuff like parsing JSON is typically still blocking. I’m sure there are other forms of blocking computation. JS being single threaded means that while some tracker is parsing a big json blob your website becomes unable to handle input events until the tracker is done. Let’s say there is an option to do this in some form of threaded worker or coroutines then the main UI thread does not become blocked.
      - MaxBarraclough 6y ago
        > Stuff like parsing JSON is typically still blocking. I’m sure there are other forms of blocking computation. I agree that it's a neat idea to use asynchrony to move specific heavyweight browser-native computations out of the JavaScript thread, but is JSON parsing really a significant performance issue? > JS being single threaded means that while some tracker is parsing a big json blob your website becomes unable to handle input events until the tracker is done. I'd rather parallelism not be a viable option for accelerating trackers. Users are known to hate unresponsive UIs. I'd rather that web trackers bring an unavoidable performance penalty. > Let’s say there is an option to do this in some form of threaded worker or coroutines then the main UI thread does not become blocked. You've just described the Web Workers API. I don't know whether today's tracker scripts use Web Workers. I imagine probably not though, I think the Web Workers API is only appropriate when you're doing substantial computation.

Indeed. Also, "very painful" is subjective. I never had issues with async code in JS (well, I had bugs, but it's not a fault of the language). There's nothing painful in async JS.

1f60c 6y ago

Having to use an async immediately invoked function expression in Node scripts is kind of a pain, but I agree.

cpfohl 6y ago
I haven't found it painful, but i avoid iife in favor of a named function I call... ``` async function main() { await stuff(); } if (module === require.main) main(); ```
infensus 6y ago
Top-level await is available in ES modules in Node without any flags since 14.8.0

MaxBarraclough 6y ago

Agree, JavaScript's approach to concurrency and asynchronous events is one of its strong points. The model of There is exactly one thread, and everything that could be asynchronous is asynchronous works nicely for web work, keeping things relatively simple (of course, race conditions are still possible) while avoiding the pitfalls of full-bore multithreading. I imagine it also makes things far simpler for the browser engineers. It's the opposite of the old Java Swing approach, where applications would often have far more threads than they really needed. (iirc, NetBeans idles with something like 30 threads.) The await/async feature seems like a sensible addition to JavaScript, but I'm open to the idea that there are alternative solutions that would be even better. As an example, I don't know much about what Java is up to but I understand it's not going with await/async exactly.

skohan 6y ago
> There is exactly one thread, and everything that could be asynchronous is asynchronous works nicely for web work, keeping things relatively simple It might keep things simple, but I don't know if this is really a sensible design constraint going into the future. Parallelism is where performance is going to come from in the future, and having the web - the most common way most people consume software - be single-threaded seems like a massive waste of hardware. If I have a 16 core processor just so the add trackers in each of my chrome tabs can run in parallel, this is a world I don't want to live in.
- girvo 6y ago
  Genuine question, what would the ad trackers be able to do with runtime level parallelism in the JS runtime that they can’t achieve now? Do they do a lot more blocking calculation than I’d expect?
  - vbsteven 6y ago
    Stuff like parsing JSON is typically still blocking. I’m sure there are other forms of blocking computation. JS being single threaded means that while some tracker is parsing a big json blob your website becomes unable to handle input events until the tracker is done. Let’s say there is an option to do this in some form of threaded worker or coroutines then the main UI thread does not become blocked.
    - MaxBarraclough 6y ago
      > Stuff like parsing JSON is typically still blocking. I’m sure there are other forms of blocking computation. I agree that it's a neat idea to use asynchrony to move specific heavyweight browser-native computations out of the JavaScript thread, but is JSON parsing really a significant performance issue? > JS being single threaded means that while some tracker is parsing a big json blob your website becomes unable to handle input events until the tracker is done. I'd rather parallelism not be a viable option for accelerating trackers. Users are known to hate unresponsive UIs. I'd rather that web trackers bring an unavoidable performance penalty. > Let’s say there is an option to do this in some form of threaded worker or coroutines then the main UI thread does not become blocked. You've just described the Web Workers API. I don't know whether today's tracker scripts use Web Workers. I imagine probably not though, I think the Web Workers API is only appropriate when you're doing substantial computation.