This is quickly changing. Anecdotal evidence, of course, but I seem to come across a lot more scripts online in Node for some reason. And by 'scripts' I mean reproducers to various issues, such as triggering error state in an app I was working on.
At first, I thought it was crazy. It kinda makes sense though, JS seems to be growing extremely fast.
As someone who has worked in Javascript basically since Javascript was invented, it's been "quickly changing" that entire time, and the majority of the changes have made things worse, not better. It used to be that you could trace your code through 15 layers of callback hell and eventually find the problem. Now there's 10 different syntactic sugars around callbacks, so you get to save a few characters of typing and then trace your bugs through 50 layers of callback hell, most of which are in some 0.0.1-alpha-versioned promise library which may actually just be a XSS attack. Improvement? I think not.
Just because more people are doing it, doesn't mean it's improving.
I'll believe things are going in a good direction when `{}.foo` throws an exception in all major JS implementations. But I'm not optimistic about that ever happening.
My only hope for JavaScript right now is that it might die because WebAssembly lets a reasonable language achieve dominance.
> I'll believe things are going in a good direction when `{}.foo` throws an exception in all major JS implementations. But I'm not optimistic about that ever happening.
Okay, please make a little effort to understand meaning rather than taking things completely literally.
Try one of the following:
> ({}).foo
undefined
> var a = {};
undefined
> a.foo
undefined
Now imagine hundreds of lines of code and a bunch of asynchronous callbacks occur between the last two lines, and imagine what that does for your debugging experience. Or watch Wat[1] and see if any of that is what you want your language to do when it happens.
The fact that JavaScript throws an exception on `{ foo: 'bar' }.foo` and not `({}).foo` isn't exactly a defense of the language.
({}).foo returning undefined is exactly what I'd expect. That's a basic part of how accessing properties in Javascript works, and wanting it to work differently is like wanting NullPointerException generation in Java to work differently.
> Now imagine hundreds of lines of code and a bunch of asynchronous callbacks occur between the last two lines, and imagine what that does for your debugging experience
That's what using typed signatures for your objects is for. It's not even substantially different from having, say, Java with an object with properties that can be nullable or Optional.empty().
Just because more people are using it does not mean it is more readable. Footguns about in JS and it is remarkably easy to read the same code over and over again and not see them because of it.
Readable languages are the kinds where not only do you understand what they're trying to do at a quick glance, but also what they actually do.
The biggest problem I have with JS in term of readability is IIFE. I know what it does, but it just looks ugly when you have hundreds of them in a program. The "semicolon in front" is even worse, needless to say.
There gotta be a better way to design syntax for an async language.. right?
At first, I thought it was crazy. It kinda makes sense though, JS seems to be growing extremely fast.