Comment by cookiecaper | Hacker News Reader

Comment by cookiecaper | Hacker News Reader

Parent Full thread

>No, I'm sorry, JS has not become awesome. We just arrived to a point were we accepted we have everything to built with it and agree to pay the huge price for it. That's all.

Yep, this is the crux. ES6+ has finally made JavaScript look more or less like the languages we were using in the mid-90s, so I appreciate that, but it's not like it's some glorious boon to the developer community.

Any gains from the new semi-tolerable semantics are quickly overwhelmed by requiring layer-upon-layer-upon-layer of crap, including hundreds of dangerous random modules from GitHub to compensate for the virtually non-existent standard library and a "build pipeline" that consists of several unrelated runners, bundlers, transpilers and transformers to make code that's actually usable in real environments.

JavaScript is a tragedy for the development community from start to finish, and its increasing prominence should disabuse us of the notion that development is dictated by meritocracy or any such fantastical nonsense like that. Marketing and groupthink have just as much pull here as anywhere else (if not more because so many of us egotistically believe we are immune to it).

Everyone complains about the build tools, but they simply haven't thought through the issues.

Let's say you were writing the web using Python. New browsers run v3.x, but old ones run 2.x or even 1.x. Further, features in newer versions of v3.x won't work on older versions of v3.x. New browsers could include all three runtimes, but old ones would be SOL.

How do you use v3 features and target v2 or v1? You must transpile knowing that newer browsers also have v2 and v1 engines included too.

You have hundreds of Python files in your system. Delivering hundreds of files is simply not practical on HTTP/2. You combine them and now you have webpack.

What about libraries? As big as the standard lib is for Python, it doesn't do everything. You use pip or conda and now have npm/yarn.

What about code consistency? The solution is pylint.

What about testing? Add that to your chain as well.

It's the unique issues of the web -- NOT Javascript -- that makes the build pipeline what it is. Until a few short years ago, these things weren't even possible. Today, if you know node/npm, webpack, babel, and eslint, you know the overwhelming majority of build processes.

I'd finally add that make, Jenkins, etc are far more complicated to learn than the JS systems.

The original crappy design is definitly a problem with JS: the typing/testing, the lack of namespace import, the emptyness of the stdlib. Half of the problems we have today are directly correlated with this.

Most of our tools are not here to make things better, but to avoid sucking too much.

So yes, forward compat is an issue. But that's hardly the one I'm complaining about. I'm really ok with not being able to use spread, but I can live with it. I'm not ok with having to use npm + webpack to download, install, isolate and bunddle a remote lib to do a leftpad.

Add to this the WTF ES6 added to the lanuage like different "this" scoping for arrow functions. Great. Now I have 2 headaches instead of 1.

I'd say you have one. If you had one before, you didn't know what really happened when you went `var that = this;` and aired your opinion about how `this` is being stupid. So you got the arrow function, where `this` acts the way you expected before, when you said it was stupid. You can't complain about both.

The scoping of `this` has never really been too hard to understand. I learned it my first week doing JS.

Reply on news.ycombinator.com