July 05, 2016
From nczonline.net, with love.

JavaScript's Uncomfortable Adolescence

Hi everyone,

At around the age of 12, I had a major growth spurt. I was towering over my friends and looked older than almost everyone my age. My body, dealing with the shock of the sudden and profound growth, didn't do very well. I had a lot of trouble with my knees buckling as I walked and I had significant back pain. My doctor reassured my parents and me that these were the textbook definition of "growing pains," and that they would go away on their own once my body had completed this dramatic shift.

In a lot of ways, I see the same thing happening with JavaScript right now. ECMAScript 6 is a massive enhancement on top of ECMAScript 5, and we had to wait four years for it to complete. The anxiousness around new features led to the creation of tools like Babel, promising that we wouldn't have to wait to use the new stuff. Unfortunately, that created a tooling explosion that meant setting up new projects to use ES6 was really complicated. On top of that, the ES6 features kept changing, and tools had to keep changing to keep up.

Perhaps the most controversial and problematic aspect of ES6 is the introduction of modules as a separate compilation target. I wrote about the differences between module and scripts previously, and about why they have to be loaded in different modes. To TC39, the committee that manages ECMAScript, modules are the way that all JavaScript code will be written in the future. As such, there was a concerted effort not to leave around any syntax clues that would become obsolete in the future (for instance, forcing people to write "use module" at the top of a file wouldn't make any sense in another five years when people don't write anything other than modules). Unfortunately, the ambiguous syntax is proving complicated during this transition period where everyone is still writing scripts and wants to transition to writing modules.

All of this adds up to what people have been calling JavaScript fatigue. Things have been changing so quickly, with new tools necessary to do new things, that it's made all of our lives more complicated. The good news is that this period is temporary. Much like my growth spurt at age 12, JavaScript is going through an uncomfortable adolescence where it grew very big very fast and now we're all learning to adjust. The transition from scripts to modules is the last, and most painful, part of this adolescence. 

In another two years, when you're writing modules all the time and modules are natively supported in browsers and Node.js, you'll forget all about the pain you're experiencing right now. JavaScript is growing up and we're all in the privileged position of watching it do so. There's some pain now, but things will be better than ever before you know it.

Be well.


P.S. I'm having trouble finding sponsors. If you enjoy the newsletter, you can help support it: Leave a tip or become a patron.

Recommended Links

An Introduction to Redux (article)
Redux is a JavaScript library for managing application state. While it's most closely associated with React applications, there's no reason you can't use it without React as well. The beauty of Redux is in its simplicity and the powerful ways it can scale as your application scales. This article gives a short overview of what Redux is and how it can change the way you manage your web application state.

Home Office Digital Accessibility Posters (posters)
Accessibility is a very large topic that can sometimes seem overwhelming. That's why I'm happy when I see people putting effort into making accessibility information easier for everyone to understand. This GitHub repo has several easy-to-read posters covering various accessibility topics. Print these out and keep them around your computer to remind yourself of the basics.

Chrome Resource Priorities and Scheduling (Google Doc)
It wasn't too long ago that browsers didn't share how they determined which resources to download, when to download them, and whether or not the download blocked rendering. These days, browsers share this information freely, and this document outlines Chrome's approach. The document itself was written a while back, so scroll down to "Proposed Changes" to see how Chrome currently prioritizes fetching of content.

Recommended Book

Depending on who you talk to, people regard Tim Ferriss as either a genius or a madman based on The 4-Hour Workweek, his book that questions societal norms about working. At its heart, this book asks the question, "why should you put off enjoying life until you're retired? Why can't you do it now?" The goal isn't to be lazy, but rather, to guard your one nonrenewable resource: time. In reaching for that goal, the book explains just how cheap it is to do the things you really want to do and how you can free up your time by paying people to do things you have no interest in doing. If you have ever hired someone to mow your lawn, shovel snow, or clean your house, then you're already familiar with some of these suggestions. But did you know that you could hire people to manage your email inbox? Or to schedule vacations for you? This book completely changed the way I thought about work-life balance and helped me refocus on what really matters to me.

Recently on NCZOnline

ES6 module loading: More complicated than you think
One of the most long-awaited features of ECMAScript 6 is the formal definition of modules as part of the language. For years, JavaScript developers have struggled with organizing their code and needing to decide between alternate ad-hoc module formats like RequireJS, AMD, and CommonJS. Formally defining modules as part of JavaScript will eliminate a lot...

Mimicking npm script in Node.js
I'm a big fan of npm scripts[1] and have been using them in all of my projects instead of a standalone build system. The feature I like the most from npm scripts is the ability to run command line executables that are installed in your project's node_modules/.bin directory. That allows you to, for example, install...

Reflections on ESLint's success
It's hard for me to believe, but I first conceived and created ESLint[1] in June 2013 and first announced it's availability in July 2013[2]. As frequent readers might recall, the primary goal of ESLint was to create a linter with rules that could be loaded at runtime. I had seen some problems in our JavaScript...

Books I've Written


Love this newsletter? Hate it? Have suggestions for how to make it better? When you subscribe to the newsletter, you can just reply to send in feedback.

Ready to subscribe?

Join over 2,000 others and subscribe to get the newsletter delivered to your inbox every other Tuesday. 
If you enjoy this newsletter and would like to support my work (including the newsletter, my blog, my books, and ESLint), please consider becoming a patron. I provide a lot of free content and your support allows me to spend more time doing so, and there are great rewards for patrons.
Copyright © 2016 Nicholas C. Zakas, All rights reserved.

unsubscribe from this list    update subscription preferences