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
> 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.
It’s worth looking at JSDoc as an alternative to regular TypeScript. No compiler to set up, and you’re restricted in a good way - less likely to get over-engineered types.
> I learned a lot about JavaScript (and Node.js) by writing shell scripts in Node.js.
Totally! This will give you lot of insights into low-level working of JS. Of course, some Node.js specifics too. Reading from STDIN, parsing strings into structured data etc.
For writing shell scripts in Node, there’s a helper library called zx created by Google.
I find it a lifesaver for the common occasion when I’m tempted to write a bash script but also know it’s going to need some slightly more advanced features (as in parsing a JSON, or just arrays that are not totally bonkers in syntax).
Yes, I was about to propose this. But then again, the author wants to learn the basics without grappling with abstractions. I think zx can be a bit quirky.
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/
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.
I don't think GP was saying your blog post was pedantic. I think they were referring to the stack overflow answer (which, unlike yours, was kind of pedantic). Your post was great.
That said, since we're discussing pedantry, I truly do mean for this to be constructive. In the US at least, most people avoid putting the "Dr." title in their name unless they're in a context where it specifically matters (such as on a course syllabus that they're teaching in university, for example). Medical doctors is an area where this is much less true. The "Dr." title can come off to many people as very pedantic unless it is specifically relevant to the situation.
Part of that is probably because historically in software development/engineering there's been a stigma against people that didn't graduate or go to university, so people feel insecure about others with a lot more education than them. It's gotten a lot better, but there's definitely still some of that happening even now.
I also want to say _thank you_ for your books and blog! I've found them quite helpful over the years. Javascript isn't my primary language so I often have to look things up, and I always click on your posts first because I know that they will:
1. Be brief and to the point (not a bunch of extra unrelated stuff to sort through)
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.
So it seems like the good Doctor does have a doctorate in a very relevant field. Informatics is quite closely related to programming especially as I understand in continental European universities. I find that knowing that the author has studied in the field for 10+ years is very relevant and adds authority to the blog.
The confusion is a byproduct of using the same syntax in multiple places. It's even easy to fall into the trap of reasoning through the logic of what's happening as spreading, e.g.: "If I put the spread syntax right before the argument in my function, I'm telling the engine to essentially spread [ arguments[n] ... arguments[arguments.length] ] into this single argument value, where 'n' is the position of my spread syntax."
It's not truly correct but if you think about it in this manner it actually fits reasonably well into what the result is.
Don’t forget that this book is for people who already know JavaScript well. It doesn’t try to explain the basics. This book does, though: https://exploringjs.com/impatient-js/
Sure, but as an expert, explanations that holds up for everyone are always preferred no matter what level of book I'm reading, compared to an explanation that makes sense "if you already how it works". In both cases linked, the text feels incomplete or even just "wrong, were it not for the fact that I know what you actually meant".
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...