How JavaScript works: class static blocks and 6 proposed semantics
blog.sessionstack.com
blog.sessionstack.com
If you’re familiar with ES6 classes but not class fields, then you can skip the first half of the article and start at the “Public class fields” heading.
For a format that is easier to consume and isn't marketing content, see:
Because they're useful articles?
As for what you linked, the second edition book about classes isn't even started, and the first edition book only goes up to ES6. If I'm here for the thing in the title, class static blocks, that doesn't help at all.
With #private variables, this is unfortunately no longer true. You can’t do private variables as outlined in the spec with prototype inheritance. It’s a feature that would be very difficult indeed to polyfill.
The code in the above comment probably should have used a recursive setTimeout() that waited for each API call to finish, rather than a setInterval().
If you have code that freezes the backend for 50ms you're unlikely to notice it. And if the code running in the browser blows up you're going to notice just like in the backend case.
Also, JS is not the only language that runs in the browser. You have TypeScript, as well as any language that compiles to wasm. If you want one that's not bad, it's up to you to pick one.
If you want to write code that runs in a browser, JavaScript really is your only option.
Where do you get this from? Has there been any comparisons made between JS and other languages to see which ones have the most gotchas? I'd love to see the data behind this.
> since bad backend languages just stop getting adopted
What? This is obviously not true (bypassing the discussion around what "bad" means, which is highly subjective). People continue to adopt all kinds of languages all the time. New projects in PHP are still created (although I disagree PHP is necessarily a bad language [today])
> issues are less obvious as long as it appears to work
Hmm, isn't it the opposite? Frontends is what the users see, when something is wrong it's very easy to see that something is broken. And if the backend breaks the wrong way, the frontend usually breaks as a result too if the programmers haven't setup error handling correctly.
> freezing the UI for 50 ms is ok-ish in the browser
Freezing the browser UI for 50ms is as noticeable as adding additional 50ms to the processing time of all backend requests. If you're actively building it you might notice that the timings off, but if you're just using it, everything might look fine. Not sure what backend/frontend makes a difference here...
If we ignore the cluster setup to get parallelism, concurrency in nodejs is done by running all request in the same thread by segmenting them and each sub part of a request into asynchronous callbacks.
By doing like this nodejs can achieve high performance because it avoids high cost of thread context switching.
The drawback is that one request can block all other request if some code is badly written, if only one callback takes too much time everyone needs to wait until it is finished, remember only one thread, no parallelism.
If you compare to PHP where the web server handles all process management (threads or processes), one badly implemented endpoint will most likely not affect other request to other endpoints. (Of course we have same limitations as always being on the same machine, limits on memory, cpu etc). Other endpoints will continue to work as before even if your team committed a few lines of shitty code whereas in nodejs it can bring down the entire system.
Avoiding this blocking effect in nodejs is usually not a problem if you are a skilled developer, however if not it is highly likely that you will deploy this behavior to production.
That is also in a sense a paradox of nodejs, it is pitched as something easy to pickup if you already know JavaScript, it is true that it is similar to browser JS, which is also asynchronous in a single thread, but in nodejs you run all users in one thread whereas in browser JavaScript you get a thread per user (each browser instance). nodejs may look easy, because it is just JavaScript, but it has these subtle parts that you need to be aware of even as a beginner.
Unfortunately JavaScript is one of those languages that has lots of "never or rarely use this" cases
Usually you want a recurring task that start after the previous invocation finished. Recursive setTimeout is the straight forward choice, while setInterval may require you to cancel the interval, making you just reimplementing setTimeout.
Scheduling task in setInterval will run the task every interval time set regardless the previous task has finihsed or not. This in turn will starve your hardware if the function could not finish before the next execution begin.
That only applies to async work performed inside the callback. Once the CPU is starved, or if the work performed inside the callback takes longer than the interval, then setInterval will start to skip.