Making Sense of the JavaScript Ecosystem with Ethan Brown – InApps Technology 2022

Ethan Brown is director of engineering at Pop Art, a Portland-based interactive marketing agency, where he builds and implements web services for clients ranging from small businesses to international enterprise companies. He is also the author of two O’Reilly titles: “Web Development with Node and Express,” and “Learning JavaScript, 3rd Edition.” With over twenty years of professional programming experience, from embedded to the web, Brown has embraced the JavaScript stack as the web platform of the future — to the point where he refers to himself as a “Node.js evangelist.”

At the Node.js Interactive 2017 conference in Vancouver, Brown gave a well-attended presentation called “The JavaScript Ecosystem: Making Sense of the Madness.” Rather than attempting to put a pin in precisely where the language is now — a moving target if ever there was one — Brown offered a framework for us to consider the various aspects of the JavaScript ecosystem in context, both current and going forward. InApps Technology caught up with Brown recently for a look back at the past year in JavaScript, and what might be coming next.

What word would you say best describes the JavaScript ecosystem in 2017?

That word would have to be “change.” JavaScript has of course been around a very long time, and historically there were some people doing sophisticated things with the language. But for a long time the mass attitude was, why would you even use ECMAScript 5 (ES5)? And then came 2014-15, the time period you saw a massive shift in the popular use of JavaScript, which in turn is spurring rapid evolution and constant change.

I think some people worry we are getting too distracted by all the change, that maybe we should all slow down and not chase every JavaScript framework that comes out. Which is true, in terms of that critical ability to quickly discern what is good and useful, from what is maybe not ready now but will be good in a year. Doing that involves really taking a look at what’s in front of you.

On the other hand, though, I’m not sure truly slowing down is even possible anymore. There is so much that comes out on a daily basis now that makes our lives better. So you have to be able to see change and adapt quickly. To say, “Wow I can see if I adopt this now, it going to save me a lot of time down the road” and just go ahead and do it.

Because there is a risk in resisting change. I was very slow to come to React, and it’s cost me a lot. When I first saw, from my lofty position as an experienced engineer, the munging of concepts, the integration of presentation and logic — I thought, this is the worst thing ever. I had a 24-year-old engineer on my team who was like, “Oh no man, React is really cool, you should give it a shot” and I was like, “No, this is going to blow over.”  It was kind of my calcified experience that kept me from seeing that this was really big, and really good. I fell right into the old dog trap. And it cost my company a lot of money because we spent a year using competing technologies that felt more comfortable to me. But eventually we got there, and fortunately this developer still looks up to me as a mentor, despite the fact that I was so so wrong.

What are some of the things driving both the adoption and evolution of JavaScript?

Unlike other languages, JavaScript is the first massively popular languages that has moved to this continuous availability and evolution of features, in continuous deployment. So it’s not like the C++ community meeting in 2020 to talk about getting ready for new features to be introduced in 2022 — that kind of tectonic shift is no longer how things are. We don’t have that kind of time.

You cannot separate what’s happening with JavaScript from what’s happening with browsers. Browser manufacturers are not following a biannual release schedule — they release when the updates are ready. Which speaks to a maturity in the software industry as a whole; 10 years ago it was not even possible to have that kind of continuous deployment. The mounting evidence, is that this is now the best way to do software development and product releases — the internet is working, we’re not hearing QA people saying we need to stop this continuous deployment business.

So therefore it only makes sense that if this is the environment we are in, then the language and ecosystem evolve continuously the same way. At the same time, I’m still waiting for the Hindenburg moment.

The Hindenburg moment?

Yeah, when it all blows up. Not necessarily predicting it’s going to happen, but there is a part of me nervous that every day you may open your browser to a different version using a slightly different set of JavaScript features. And it’s a little mind-boggling to think that somehow it won’t break — we are building houses on sand that’s constantly shifting.

That said, it seems to be working, and we are certainly developing techniques to deal with the rapid evolution. The TC39 committee is doing a great job adding language features in a backward compatible, non-impactful way. And, even back five years ago, people were polyfilling shit, before we use this feature we need to detect if it’s even available in the browser. We are already comfortable with runtime decisions about what language features are available to us, and it’s not as if this all happened over night. So maybe my nervousness is just more old dog syndrome.

What is your advice to new developers trying to figure out what to learn in order to land their first job in 2018?

The JavaScript ecosystem is overwhelmingly broad now, and I think so many young devs feel like they have to know something about everything in order to be hireable. But you really don’t. In modern JavaScript web development there are so many a la carte options you can pick when you do a project. Broadly speaking the choices are, do we use Angular, React, or Vue? If you say React, then are you going to use Redux? MongoDB or RethinkDB or…? And etcetera. Given this massive palette to choose from, we know we can’t hand some HR person a list of the 20 specific technology choices we’ve made out of a list of millions and expect to find someone that has that exact combination.

So if you are a job seeker, I would say as much as possible be a very surface generalist. Have run through a Vue tutorial, a React, an Angular — pick a weekend for each and do one. Focus on the big technology. If you’re looking to do cloud infrastructure, deploy something on AWS or Heroku. Whatever your space, pick the biggest piece and get some initial experience playing with it.

Then, when you see a job you are really interested in, you will have time to dive a little deeper. Go back, redo that Angular tutorial, then go a little deeper, read some blog posts. You don’t need to know everything in great depth all the time — just the ability to in the space for a few days, focus your skills and prep to talk to a company. Do your homework! It makes me insane when someone applies at my company and it’s obvious they have not done at least even five minutes of homework about our company and the tech we are using. I know instantly I will not be hiring them.

What are some areas of interest you see for 2018?

I think 2018 will be the year of functional programming and higher-level abstractions. There’s already a lot of momentum there, and I think it’s really going to grow in the new year. Maybe we’ll see a surge in the popularity of Elm, which I would welcome. Maybe the TC39 committee will start talking about adding more sophisticated immutable data structures to the language?

On a personal note, 2018 is the year I’m really going to adopt Flow, and integrate it into my work (ahem) flow.