Cross-posted on Medium
If there was ever a model of a true love-hate relationship, it would be programmers and JavaScript. JavaScript is the language of the web, perhaps the single most powerful force for innovation and change in our modern societies. With just a few lines of JavaScript, engineers can move markets, change lives, and build the future. But the language has also traditionally been one of the most annoying programming environments available to the contemporary hacker, filled with traps, pitfalls, and awkward behavior.
You could write that javascript == Good && javascript == Bad, but then we would have an argument about equality operators. Such is the JavaScript life.
Or at least, to my eyes, it used to be. I got JavaScript fatigue before it was fashionable, way back in 2011. I basically ignored the entire ecosystem — including Node — in the interim, while happily programming away in Python 3 and its excellent stats libraries.
This past year, a number of great summaries of the JavaScript ecosystem were published, including the quite critical[How it feels to learn JavaScript in 2016]. In reading these articles, I realized that everything I knew about JavaScript and its platform was just completely out-of-date. ES2015? Arrow functions? Transpilers? Babel? React?
It was like people were talking in a foreign language — and they were, for the JavaScript I had grown up with was dead, and had been replaced with something far better (although still with quirks).
I have never been more excited about JavaScript than today in 2017. And while I understand the fatigue that many engineers feel (I would too if I had churned through front-end libraries like [Japan churns through prime ministers]), it seems to me that JavaScript today has never been in a stronger position to build the best products of the future. This is my story of leaving the community, and now wanting to be a part of it more than ever.
JavaScript: The Dark Times
I have programmed since I was in elementary school, first doing basic scripting with HyperTalk and HyperCard back in the mid-1990s, then later moving on to TI graphing calculators, where I made my first tic-tac-toe AI in fifth grade (should have used deep learning to stay ahead of the buzzword curve, but alas). In high school, I mostly programmed in Java, trying to build a really awkward Civilization clone that never really got anywhere.
It was still an incredibly early time for JavaScript when I started attended Stanford in 2007. It’s hard to believe, but almost nothing we take for granted with JavaScript today had even reached a stable release. AJAX had just been popularized by Google through Gmail and Maps, and jQuery had just been released the year before. Not only that, but popular frameworks like Ember and Angular were still years away, the whole ecosystem of Node.js was still just a glint in Ryan Dahl’s mind, and Douglas Crockford hadn’t even published his legendary JavaScript: The Good Parts yet.
That first year in school, I was working on an app written in Ruby on Rails (itself in its initial release cycle!) to create a social platform for drug discovery. It was here I learned just how exhausting it can be to use new tools for web development. Rails would work, until it didn’t, and no one could explain why. Mercurial, our DVCS, was still an early product, and had its own bugs. And of course, JavaScript itself was an absolute zoo of crazy hacks pasted together to try to get anything working.
I played with JS on and off for the next three years, and experimented with some of the new frontend frameworks as they were released. But by the end of my degree in 2011, I was really quite done with coding for the internet. I was spending more and more time in the Python world, particularly around statistics, and Python was just a joy to program compared to the kluge that web development always turned into.
So I took a hiatus. For five years.
Fast-Forward Five Years Later
Last year, there were a number of great reviews of the Javascript ecosystem and how much it had changed. It was clear that something new was underfoot, and so I decided to dedicate some side project time to relearning the stack and getting myself back out to the bleeding edge.
I started with John Resig’s newly updated Secrets of the JavaScript Ninja, which covers many of the changes that ES2015 promises (pun intended!) Coming from the Python world, the addition of lambda-like constructs called arrow functions, generators, iterators, and classes completely transforms the quality of JavaScript code. While JS may not be entirely “Pythonic,” it certainly closed the distance in code readability. Plus, the addition of Promises significantly reduces callback hell, which is one reason I never really got on the Node bandwagon years ago.
Now, here is where these changes start to become controversial. The introduction of ES2015 meant that suddenly, developers had to use transpilers to ensure that this new code is usable in old JavaScript runtimes, usually with a library called Babel. This requirement is indeed a bit of a pain, but I found it to be fairly easy to setup and understand what is going on. Furthermore, [support for the new standard is going really well] (except with Android of all things), particularly given [my recent experience with the Python 2 to 3 transition]. We are definitely a long way from the old IE days.
In addition to the advancement in the language, perhaps the most exciting aspect of modern JavaScript is the creation of smart new frontend frameworks, most notably React and Vue.js. When mixed with a state container like Redux or Flux, it allows developers to write much more sophisticated user experiences with some degree of organized logic compared to the old days of simply hacking scripts together. These tools are decently mature, although they are not perfect, and their philosophy certainly takes some getting used to.
(To be honest, I struggled in my first sandbox app even to get started, but eventually, the construction of these apps became much clearer as I figured out my program requirements. My recommendation is to ignore the create\_react\_app library and to build your first app entirely from scratch. It’s super helpful, even though it can take the better part of a weekend to get all the pieces to fit together.)
Finally, there are compilers and build tools like Webpack that help to put all this together. Webpack is one of those tools that is annoying to setup (seriously, “batteries included” is definitely not a good description), but once you play around with the scripts, add in the right plugins and get the correct result, it is so quick and painless to rebuild an entire app that it is almost magical.
In short, there has just been a sea change when it comes to the maturity of the JS ecosystem. Sure, there are a lot of tools, but there are also are a lot of problems that crop up in web development. It’s great to see the community building best-of-breed tools that solve each of these problems in a modular way, and the cooperation to orchestrate them together for the developer.
It’s not just JavaScript
It’s clear to me that the JavaScript community wants to succeed, but that’s not what it takes to make web development shine. Ultimately, our goal is to build products that work for end users in a seamless way. We also need tools that give us the leverage to do a lot with limited people — engineers are expensive these days!
On the seamless, side, we have seen the development of Electron, which allows for a translation of JavaScript apps to the desktop, as well as React Native for mobile devices. These libraries are not always great (the memory requirements, for one, with Electron are insanity in my experience playing with some sandbox apps), but they are hugely helpful for users who want a more native experience.
But the real excitement comes from the number of third party libraries supporting our projects today. As just one example, accepting payments through Stripe is a breeze compared to what it took to do the same work back in 2007. Payments might have been someone’s full-time job a decade ago, and now it can be just a few lines of JavaScript. When you mix in the number of consistent REST-based API services, the cognitive overhead is just so much better than it used to be.
There are also some key cultural changes that have improved the community. Test coverage was not something that was actively discussed outside of some marquee projects, but now I am pleasantly surprised how even some small libraries are building testing into their codebases from line one. Documentation, the great bane of web development a decade ago, is actually quite good. Not only are developers are documenting their work better, but the huge number of StackOverflow questions and blog posts means that an issue can almost always be solved in a short period of time.
JavaScript: The Best Times?
It’s clear that JavaScript has made huge strides in the past five years. To everyone in the community who has put time into making it so — thank you!
It’s of course also clear that not everything is rosy. NPM and the sheer number of dependencies required for even a basic JavaScript app is quite terrifying. Frontend framework churn is going to continue, and I am willing to bet that the Next Best Thing will replace React within five years. These are real complaints, and deserve attention, although I don’t agree with the idea of stopping the evolution of the web.
That dizzying change in the Javascript ecosystem can honestly be exhausting, but it is also its greatest strength. Things have been getting better — pretty consistently — and at a rapid clip to boot.
So for those who are thinking of walking away, my advice is simple: don’t. Maybe take a few months off (definitely not five years!) Dart around an Elm tree, or Go play with a Python while drinking Java. But don’t knock the changes we have seen: they may not all be linear improvements, but they have collectively created one of the best environments for building great products I have seen. Now excuse me, I have a new frontend library to make.