Ask HN: What is happening to JavaScript with ES6 and friends?
I'm hoping that someone can point me in the right direction, or at least offer some insight to the below.
- NPM is great, but why are we now installing web dependencies with it? Bootstrap, Material-Components, etc. I know that there are still "traditional ways" of either using a CDN or downloading a local copy. I've avoided NPM for a while until I wanted to use Google's Material-Components-Web thing. My confusion here's because node_modules is private, so how do I correctly load a front-end asset by referring to node_modules?
- Suggestions for the above were to copy what's installed to a public/static folder, but NPM just spills everything all over the node_modules root now, so how would I know what depends on what?
- There's been the Browserify, CommonJS, RequireJS, WebPack et al. movement, where we are now using "require" and "import" 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/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?
While I appreciate the work that everyone's doing with JavaScript, I really feel like we're taking something fun and "easy" and complicating it. I've been teaching beginner programmers ES5 and earlier at work, and was planning on moving onto ES6 once I'm comfortable with the stuff I've been avoiding, but I'm inclined to change my mind so far.
I really hope someone can shed some light on this :)
10 comments
[ 5.6 ms ] story [ 35.9 ms ] threadCynicism 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)
At least Java has Kotlin, it's made Java pleasant for me again.
I get the logic of the browserify movement, after all we've been punting Node.js as the grail of shared code. The irritating thing is that a lot of what's out there is opinionated, you read 3 tutorials/guides and everyone does something differently. I follow nodejs/node on Github, and the amount of comments over the past year or 2 for and against modules is what kept me standing on the fence for very long.
I struggled just to get Mongoose working properly with TS a few weeks ago, the thought of having to waste a few days converting everything to a Class before I can export my functions properly turned me off. Now I just ignore the TS warnings because I know my code works.
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.
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.
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.
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.
[0] http://blog.isquaredsoftware.com/2016/10/presentation-modern...
[1] https://github.com/markerikson/react-redux-links/blob/master...
[2] https://github.com/markerikson/react-redux-links
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.
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.