Let’s assume we create a new version of JavaScript that is not backward compatible and fixes all of its flaws. As a result, we’d encounter the following problems:
• JavaScript engines become bloated: they need to support both the old and the new version. The same is true for tools such as IDEs and build tools.
• Programmers need to know, and be continually conscious of, the differences between the versions.
• We can either migrate all of an existing code base to the new version (which can be a lot of work). Or we can mix versions and refactoring becomes harder because we can’t move code between versions without changing it.
• We somehow have to specify per piece of code – be it a file or code embedded in a web page – what version it is written in. Every conceivable solution has pros and cons. For example, _strict mode_ is a slightly cleaner version of ES5. One of the reasons why it wasn’t as popular as it should have been: it was a hassle to opt in via a directive at the beginning of a file or a function.
I have used many languages in my nearly 40 years as a programmer (Scheme, C++, Java, Python, Haskell, OCaml, Rust, etc.) and still enjoy JavaScript: It’s decent as a language and there is so much you can do with it.
Tips:
• If you like static typing, you’ll want to use TypeScript. It’s more work to set up, but it catches many bugs, especially subtle ones where JavaScript’s semantics are not intuitive.
• I learned a lot about JavaScript (and Node.js) by writing shell scripts in Node.js.
My books on JavaScript, TypeScript and Node.js shell scripting are free to read online and target people who already know how to program: https://exploringjs.com
You can indeed translate an async function to an equivalent function that uses .then() but it’s a radical change, not syntactic sugar (as I use that term).
I wrote my JavaScript book for people who already know how to program – maybe it works for you. Free to read online: https://exploringjs.com/impatient-js/
W.r.t. the “Dr.”: It’s interesting how much reactions differ. In Germany, people tend to think you are smart if you have a title. In the States, people tend to think you’re incapable of functioning in the real world.
I’m still experimenting. The title has worked well for me w.r.t. branding. Sometimes I mention it, sometimes I don’t.
For what it’s worth: That’s not what motivated this blog post. It was that I often encounter people who see the three dots being used in parameter definitions or destructuring and don’t understand what is going on (because they think it is spreading). The section on triple dots not being operators is more of a side note.
Let’s assume we create a new version of JavaScript that is not backward compatible and fixes all of its flaws. As a result, we’d encounter the following problems:
• JavaScript engines become bloated: they need to support both the old and the new version. The same is true for tools such as IDEs and build tools.
• Programmers need to know, and be continually conscious of, the differences between the versions.
• We can either migrate all of an existing code base to the new version (which can be a lot of work). Or we can mix versions and refactoring becomes harder because we can’t move code between versions without changing it.
• We somehow have to specify per piece of code – be it a file or code embedded in a web page – what version it is written in. Every conceivable solution has pros and cons. For example, _strict mode_ is a slightly cleaner version of ES5. One of the reasons why it wasn’t as popular as it should have been: it was a hassle to opt in via a directive at the beginning of a file or a function.
More information: https://exploringjs.com/js/book/ch_history.html#backward-com...