Hacker News Reader

Comment by westoque | Hacker News Reader

I might get heat for this but personally I find the JavaScript ecosystem to be a mess. There are so many changes to the language that are done aggressively which I think are done without much thought. For example, the promises API, now we also have async/await. The module system, with require(s), then import/export, and there's browser JS and system JS (node), and npm and now yarn, then your build system, with webpacker, browserify, bower. Oh! You might also be interested in using new JavaScript syntax so don't forget to use babel.

And the funny thing is they are teaching all these at bootcamps and the students have a hard time trying to understand the concepts with so many variations in them.

There is however light at the end of the tunnel which I think where TypeScript is.

View on HN

> I might get heat for this but...

Some variant of this is the top-voted comment of every HN thread on modern JavaScript.

> For example, the promises API, now we also have async/await. The module system, with require(s), then import/export, and there's browser JS and system JS (node), and npm and now yarn, then your build system, with webpacker, browserify, bower.

Async/Await are essentially sugar on top of Promises -- use them if you want, you don't have to. Require has been deprecated in favor of import/export to be more semantically meaningfull (e.g. with TypeScript). Webpack is the next iteration of the Browserify approach, and Bower is just flat out dead.

All of this happened 3-4 years ago, if it's your job it's not hard to keep up. If it isn't your job there's plenty of guides out there to get you up to speed. I wouldn't expect to be able to jump back into Android dev after 5+ years away from it without doing some reading, I don't know why people expect web development to be so static.

> All of this happened 3-4 years ago, if it's your job it's not hard to keep up. If it isn't your job there's plenty of guides out there to get you up to speed. I wouldn't expect to be able to jump back into Android dev after 5+ years away from it without doing some reading, I don't know why people expect web development to be so static.

The thing is that the JavaScript language is so aggressively changed, unlike Ruby for example, that for years, working with it professionally, the only change I can remember that was significant in my work was the safe navigation operator `&.`. The build tool (Bundler) is still the same, along with other tools. Not sure why JavaScript can't do the same? More innovation I guess?

> Not sure why JavaScript can't do the same?

We should be celebrating the fact that JavaScript finally has a sane module system after 20+ years, not complaining about it. Ruby had namespaces and modules from day one.

You can use the old JavaScript if you want to. All those fancy tools just compile down to the same old es5 you can write by hand if you're so inclined.

After the big dump of new features in ES2015, I don't find the pace of planned updates to the language aggressive at all. JavaScript is still playing catch up.

People will complain if they don't add features. When they do add new features, people complain that they're "bloating" the language or moving too fast. Damned if you do, damned if you don't.

The JS ecosystem is a different matter.

It's really not though. If you look at the official yearly releases, you'll find that there have only been a few major changes since ES5 (aka ES2009): Async/await, modules (import/export), arrow functions and destructuring.

None of those are mandatory. They're mostly just syntactic sugar on top of existing features.

Every other change has just been things like new util methods on primitives like the string trim functions.

The build tools are separate, don't conflate them with the language. That being said, for ~4 years, most people's build chain hasn't changed; webpack with a babel plugin.

The problem is that JavaScript wasn't considered a stable and useful language until it really started to hit its stride in about 2009. So all of the changes that have happened are because the community is still figuring out the best way to do builds whilst things in the language are still changing.

My guess is there are too many options, and ways, to the casual person it’s a lot to learn/compare then choose, for people that don’t care to compare well there is always a bootstrap starter app

Ryan Dahl seemed to imply that promises were a necessary pre-requisite for async/await. https://medium.com/@imior/10-things-i-regret-about-node-js-r...

I don't have the actual transcript so summarizing based off of someone else's comments:

* I added promises to Node in June 2009 but foolishly removed them in February 2010. * Promises are the necessary abstraction for async/await. * It's possible unified usage of promises in Node would have sped the delivery of the eventual standardization and async/await. * Today Node's many async APIs are aging badly due to this.

Async/await is just syntactic sugar in languages. It's always implemented by some kind of promise/futures/task based API, itself usually built on some kind of state-machine/iterator/generator model.

Promises could be shimmed in browser JS (Jquery was my first experience with it) where async/await needed something like a babel/webpack transpiler for the syntax to really be feasible in a browser.

It's becoming the new PHP, where "classes" are an after-thought and there's a beginning of a "frankenstein's monster" of features pulled from other languages.

Having said that, looking at the code sample it's looking quite nice (ignoring the #'s).

Isn't TypeScript committed to implementing all stable ECMAScript features?

It being a superset with TypeScript-only features on top of ECMAScript, wouldn't the "aggressive changes" you complain about be worse?

It’s fine if you are a fairly experienced JavaScript developer, and understand the tools that you used to have, and what their pain points were, and what solutions are coming along the way; then you just go with the flow and enjoy the progress.

I can understand the frustration of people who don’t touch JavaScript on a daily basis, or confusion of newcomers. I can sympathize. But I don’t think that personal inexperience should reflect negatively on the language.

I certainly get framework fatigue with JavaScript but I think most of that has little to do with the core standard. The things that the core language has added I have found, for the most part, to have been well-considered and beneficial.

Async/await and promises do seem to be a thorough solution, with my main criticism being that they are difficult to conceptualize what is going on when a lot of promises are being composed together.

I love TypeScript but I think it's funny that your answer to the woes of JS complexity is just another JS transpiler. It's a tool you're familiar with and one that you like so you give it a pass on all the complaints you leveled up front. Maybe... just maybe... in a similar vein to TypeScript, most of these other JS tools were built to solve real problems and not just to deliberately confuse you.

All of these bits and pieces were built for good reason, it's nice to see them grow organically in different directions but able to borrow concepts from each other or collapsing down (as happened with Node and IOjs).

As a beginner it's a far more daunting picture, compared to Rails for example, but as a practitioner I'd like to build my project with pieces suited for purpose.

I hadnt used es6 syntax in 5 months and just got the ‘luxury’ of discovering that babel 7 came out sometime and that all of the babel dependencies are namespaced and renamed, but are the new best practices “or else”

Basically everything on stackoverflow/github issues/random JS blog is outdated regarding the inevitable error messages youll google

I don't disagree that it's moving fast, but my experience is that the thriving ecosystem makes JS apps nice to work on.

Every project has its own little tech stack, each part being filled a-la-carte by some JS framework/library/preprocessor. The server might use express or raw node or Koa, the web client might use React or Angular, styles might be done with SCSS or styled-components, etc. JavaScript might have a different syntax between projects if they're using typescript/babel. There are lots of choices to fit many needs and preferences, and that's a good thing™.

All of these technologies are built around the same language and syntax, which at its core is relatively simple to learn (aside from the occasional type coercion/prototypal inheritance weirdness). This makes learning new frameworks and tooling easy: does it need a config file? Chances are it's a raw .js or .json file with a similar format to webpack.config.js or package.json or .eslintrc.

It's not a huge ask, nor would it be terribly difficult, for one developer to become competent with both Angular and React, for example. And once you've made your choices for your project and installed all the npm packages you need, there's no need to keep all of them updated to the very latest, bleeding-edge releases at all times. Just install patch (0.0.x) updates and wait for npm to warn you about any security issues in your existing packages.

That's why I'm kind of surprised to see so many companies advertising JS jobs with requirements like "Must have 3 years experience with React." Any competent Angular developer should be able to pick up React and start being useful in a matter of weeks, not months or years. Just hire JavaScript Developers, IMO.

> For example, the promises API, now we also have async/await.

These go together, right? An async function returns a Promise, await operates on a Promise.

You can sill use the "good parts" but you will probably be accused for being unfashionable.

if we’re here, i’ve got a rant about npm. if you have more than a few dependencies, you need to download half of the internet for all the required 3rd party packages. this has security implications too, as i see no way to be able to watch them all, even with a local mirror

@downvoters: do you care to add a reply? it’s silly that instead of having a conversation, we’re doing this.

I didn't downvote you but I think you're getting grayed out because it's a tired argument that's been had time and time again. It's just… kinda pointless to have it again.

Yes, the all-too-common super-deep dependency trees are a problem. If you're reasonable about your dependencies though it doesn't happen (my last few JS dependency graphs are pretty similar to my Python ones).

One of the issues is the stdlib and the other issue is a different mindset due to a lower barrier of entry to creating a package. (eg. creating and maintaining a package in Python sucks, so you're less likely to do it for small, self-contained things rather than create a utils.py)

shrugs, I honestly don't know what meaningful change this discussion can lead to. People are generally aware of this, and the problem isn't actively getting worse, so I imagine it'll get better over time.

ok, that’s fair, thanks. i haven’t participted that much in js related discutions, it’s just frustrating to me and didn’t know that this is pushing some hot buttons :)

Reply on news.ycombinator.com