The Real State of JavaScript in 2015

Artemi Krymski
2 min readDec 1, 2014

--

A recent HN article — “The State of JavaScript in 2015" — seems to suggest that there is a crisis in the happy JavaScript world of today: libraries are being pushed out too fast! Developers can’t keep up.

Leaving aside the hyped up mini-market of MVC frameworks (React, Angular, Ember) the JavaScript world at large is doing just fine. Node.js is seeing over 2 million downloads per month, with 81,000 modules on NPM. Somehow in the Node world nobody is complaining — Express is the de-facto standard library for the backend. It’s small, readable, and gets the job done.

On the front-end however, things are very different. There’s no agreement on which package manager should be used, so libraries are floating around in globals. Monolithic libraries look simpler to newcomers for this reason — one <script> include should cover most of your needs right?

Wrong. It’s no surprise that when that include doesn’t work as expected, or is updated and breaks your code — you’re completely lost. If it’s 100KB of code, are you really expected to read it?

The problem is not the pace of releases, it’s the lack of a standardized package management system. If CommonJS was the standard there too, we’d end up with lots of small libraries that we can just drop into our apps as needed. Need some routing? Require a router. It should be that simple.

I love the Node community for this very reason — small, readable libraries that require little vanilla JS to put together and voila — things just work. It’s a breath of fresh air when compared to the globals nightmare on the front-end and the Maven nightmate in Java-land. Why can’t we apply the same methodology to our front-end development?

I believe the best developers do just that. They write vanilla JavaScript, require CommonJS modules from npm, Browserify their code and inline all their assets into a single binary for the web. That is the future workflow. And there are no monolithic libraries in it.

If you’re interested in seeing what a tiny MVC library with zero dependencies looks like, check out Espresso.js

--

--