
Ask HN: What is happening to JavaScript with ES6 and friends? - nevi-me
I&#x27;ve been working on a redesign of one of my websites, which is built with Node.js using Express.js. I&#x27;ve recently also been playing around with TypeScript, and was starting to like it, until the unpleasant stuff below.<p>I&#x27;m hoping that someone can point me in the right direction, or at least offer some insight to the below.<p>- NPM is great, but why are we now installing web dependencies with it? Bootstrap, Material-Components, etc. I know that there are still &quot;traditional ways&quot; of either using a CDN or downloading a local copy. I&#x27;ve avoided NPM for a while until I wanted to use Google&#x27;s Material-Components-Web thing. My confusion here&#x27;s because node_modules is private, so how do I correctly load a front-end asset by referring to node_modules?<p>- Suggestions for the above were to copy what&#x27;s installed to a public&#x2F;static folder, but NPM just spills everything all over the node_modules root now, so how would I know what depends on what?<p>- There&#x27;s been the Browserify, CommonJS, RequireJS, WebPack et al. movement, where we are now using &quot;require&quot; and &quot;import&quot; to load modules. I understand the desire to do that, but why is it so complicated for front-end? I created a simple TypeScript file under my public assets, I require&#x2F;import something, and then when I go to the browser, I get an error about require being undefined. I go to RequireJS website, and have to now learn the nuances of this library before I can get productive. Why should I have to load dozens of dependencies before loading a Hello World with some JavaScript? Is ES5 that broken?<p>While I appreciate the work that everyone&#x27;s doing with JavaScript, I really feel like we&#x27;re taking something fun and &quot;easy&quot; and complicating it. I&#x27;ve been teaching beginner programmers ES5 and earlier at work, and was planning on moving onto ES6 once I&#x27;m comfortable with the stuff I&#x27;ve been avoiding, but I&#x27;m inclined to change my mind so far.<p>I really hope someone can shed some light on this :)
======
skylark
If your goal is to do something fun and easy, then jQuery or even vanilla JS
is fine.

If, however, your goal is to make a full fledged single page application,
you'll find yourself running into a lot of solved problems.

You'll definitely want to modularize your code by putting it into different
files. Soon, you'll find that you're spending a lot of time figuring out what
order to load your scripts in your main JavaScript file. That's what
Browserify, CommonJS, etc. are for.

You'll get sick of recompiling your files and refreshing the page. Or maybe
you want to write ES6 code but have it used in browsers that only support ES5.
Or you might want to do something simple like concat your files when
deploying. That's where the Grunt/Gulp/WebPack build tools come into play.

And so on. These tools are massively popular because they solve real pain
points for developers working on large scale front end applications.

------
acemarke
I gave a presentation a couple months ago that goes over some of the history
of web development, then introduces some of the problems that today's web
developers are trying to solve and how these tools are used to solve them
([0]). That might help clarify things a bit. I also have a number of similar
articles linked ([1]) as part of my React/Redux resources list ([2]).

[0] [http://blog.isquaredsoftware.com/2016/10/presentation-
modern...](http://blog.isquaredsoftware.com/2016/10/presentation-modern-web-
dev-overview/)

[1] [https://github.com/markerikson/react-redux-
links/blob/master...](https://github.com/markerikson/react-redux-
links/blob/master/basic-concepts.md)

[2] [https://github.com/markerikson/react-redux-
links](https://github.com/markerikson/react-redux-links)

------
johncoltrane
The two first points don't have much to do with the "language" aspects of
JavaScript itself or ES6.

NPM (the registry) is simply the winner of a long-running low-intensity
conflict to determine _the_ canonical registry for the JavaScript ecosystem.
Bower (the registry), is NPM's front end alternative. It is now almost
irrelevant but its client essentially works just like the NPM client,
installing whole packages and dependencies in `bower_components` (versus
`node_modules` for NPM).

Both clients let you choose where to put that directory and/or how to name it
but you will undoubtedly end up with a lot of useless/potentially harmful
files coming from dozens and dozens of untrusted third parties to manage in
your `public` directory. That sucks hard.

The only working solution to that problem is to use a bundling mechanism. You
keep all your third party packages and their dependencies private as well as
all your sources, and only deliver to the browser a couple of bundles that
only contain what's strictly needed: `main.js` and `main.css`.

But now you have to choose a bundler.

And the module pattern you will use throughout your project.

And the JS flavor.

ES5 is no more broken than ES3 was and ES6 doesn't really fix anything in ES5.
If you want to find something broken, take a look at the JS ecosystem instead.

Hyper modularizing your code and juggling with `exports` and `require()` can
be useful but it's definitely not the only way to write a working website.

~~~
nevi-me
Thanks for the explanation. I understand the rationale (if any), but the
irritating part is when one sits down and tries to get stuff done.

The mere fact that there are a lot of ways of doing something, with one tool
having many variants, is a pain.

I thought of pointing my NPM installs to a different folder, but that felt
like a hack for something that should be simple. I tried out WebPack, but was
getting silly errors that were leading me to keep on searching for solutions.

I eventually just copied over the files that I need, and overriding 'require'
with a function that returns null, just so I could at least get some stuff
done without worrying about too much for now.

I'll spend more time in the coming days trolling Github to see how some people
are doing things.

> ES5 is no more broken than ES3 was and ES6 doesn't really fix anything in
> ES5. If you want to find something broken, take a look at the JS ecosystem
> instead.

That's my feeling too, it's like we're creating stuff just because other
languages have it too.

~~~
johncoltrane
Believe me, making choices as a technical leader is really hard these days.

------
dyeje
1\. & 2\. Haven't personally seen that usage NPM, but I'm not really surprised
since people have been doing similar with Rails (e.x. jquery-rails) for a long
time. Did you check the NPM module's GitHub for instructions? If you can't
figure it out, then just do it the 'traditional' way.

3\. If you don't want to use those tools, then don't. You certainly don't need
them for a Hello World project. Those are for organizing huge projects that
are having trouble dealing with the global scope. This has nothing to do with
ES5.

All in all, it seems like you're over complicating things for yourself by
grabbing a bunch of libraries you don't need. Also, the way you're thinking of
ES6 doesn't make sense. It's just the next version of the language, which
includes new features and syntaxes. It's like saying "Oh I don't want to
upgrade to Ruby 2 until I'm comfortable with Ruby 1.9", which you just
wouldn't do.

------
cocktailpeanuts
haha you're quite behind my friend, nowadays it's all about "Yarn", even npm
is outdated. I'm starting to see more and more open source projects using yarn
instead of npm.

Cynicism aside, I am with you on this, it's becoming too damn annoying to
build anything simple. No matter what people used to say I used to like
Javascript because of its simplicity. Now it's become the next Java, I'm sure
that's part good thing but also part bad, and some new, much simpler language
will come along sooner or later to replace what a lot of people are using JS
for.

The reason you need to use browserify and its friends nowadays is people
started shoving in too much code to frontend, and all the logic is on the
frontend nowadays. Basically you need to do an equivalent of backend
programming on the frontend side and it's become too complex not to use
dependency manager.

Like I said I fucking hate this movement too and I think something much
simpler will come along to replace much of what people use JS for, especially
for simple cases.

Also I think this change will happen once the pendulum swings and things move
back to backend again (this pendulum swinging happens ALWAYS with technology
so I'm sure it will happen someday in unforseeable future)

~~~
BjoernKW
I don't think we have to throw out the baby with the bathwater here.
JavaScript is perfectly adequate. Like you said it's just how it's used which
makes front-end development exceedingly complex.

So, our approaches and techniques need to change not necessarily the language
itself.

I agree that the pendulum will swing back to the back-end again. The question
is how we can achieve that without foregoing many of the useful patterns and
the interactivity that came along with approaches like SPAs and frameworks
like Angular and React.

The approach Rails took with Turbolinks seems viable in some ways. It's
lacking in terms of reactiveness / interactivity though. Turbolinks is great
for SPA-like switching between views but not really useful for making that
views more reactive.

I'm not sure how exactly a technique would have to look like that allows you
to have React-like reactiveness but still have all the logic in the back-end.
Maybe that's an avenue worth exploring. Another one might be how the same
problem was solved with Swing and similar UI frameworks for other languages.

~~~
cocktailpeanuts
I agree with you to certain degree, but this was not the only thing I was
talking about.

I dislike what has happened to Javascript the language itself. The way they
changed makes the language almost unrecognizable. I think JS the language used
to be simple and elegant (even though a lot of people would say otherwise).
But they've added on these new features that introduce a lot of complexity.

Sure these features make Javascript more "powerful", but at a cost of making
it way too complex. And these new features don't do anything that wasn't
possible before. The new JS is more different from the old JS than how C++ was
different from C. Normally when something like this happens to other
languages, they say they've "forked" it and come up with a new name.

I was perfectly fine with the old approach of creating classes from functions
and that was what really attracted me to javascript once I got used to it
since it's a very unique concept that showed you how you can create complexity
from simplicity.

And I'm sure soon with the official support of the new js, the ecosystem will
become even more complex and chaotic. And then people will realize it's not
worth it to build or learn yet another javascript framework, and stop. Then
there will be few winners left in the arena, and innovation will stop. No more
"javascript fatigue" so I guess that would be good, but that's when I think
another simple language will take over. Besides, js will probably NOT be the
primary language of devices of the future, so people will probably move on.

