A lot of this article is background—it only really starts talking about class static blocks two thirds of the way through! If you’re familiar with the situation up to class fields (the last part of which, private class fields, has only landed in Firefox and Safari in the last few months), then you can skip to that point, the “Class static blocks” heading.
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.
It's not the first time I complain about these articles from the same company popping up onto the front page, and I am really wondering how they are consistently doing this.
For a format that is easier to consume and isn't marketing content, see:
> I am really wondering how they are consistently doing this.
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.
> It is important to note that classes in JavaScript still use the prototypal inheritance pattern under the hood. They simply provide syntactic sugar for the prototypal inheritance pattern.
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.
As someone whose programmed predominantly in Java and Python and worked on back-end type stuff, Javascript is super weird to me. I run a webservice that I noticed occasionally freezes up and crashes and had trouble figuring out why. Just the other day I realized that it was because we were DDoS'ing ourselves through a badly implemented progress-bar functionality that made use of the setInterval function in Js
Is there something particular with JS that makes this extra likely to happen compared to other languages? Or does JS simply have more developers overall, then also more beginner developers who do mistakes like this?
The big strength and at the same time big weakness of nodejs is the asynchronous event loop.
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.
It has more gotchas than most languages since bad backend languages just stop getting adopted, and being client-side, issues are less obvious as long as it appears to work. n^2 code that should be n with some memoization might blow up a backend service, but freezing the UI for 50 ms is ok-ish in the browser.
Readit News
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:
https://github.com/getify/You-Dont-Know-JS
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.
Deleted Comment
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 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