At SXSW 2017, David Woody and I spoke about making JavaScript “great again.” We want to call development and engineering teams in action to not just leverage JavaScript to build awesome products, but to motivate the community to come together and make JS sane. We had an amazing experience speaking, and I wanted to reiterate the lessons we talked about for those that weren’t able to come in person.

First, here are the slides from the talk:

How it “feels” to develop with JavaScript is well written across the interwebs. A pandemonious rat-race of “this is great!”, “this sucks!”, and “what the …?”. It seems we try to solve every problem we possibly can with JavaScript: from webpack to JSX, from IoT to virtual reality. The web environment has gone from new-framework-a-day, to new-ReactJS-knockoff-a-day. As developers, we’re left to pick up the pieces from this rapid explosion of JS-everywhere, and still manage to put the puzzle together (ideally without cramming in too many pieces that don’t fit).

The accessibility of JavaScript and this renaissance of software-everywhere created the perfect storm. Now, JavaScript is not just the most popular language in the world (by many metrics), but it also has the largest development and open-source community.

A language that was built in 10 days,
as a prototype,
is literally eating the software world.
Have you heard it’s been used in space?

The rate of JavaScript growth isn’t slowing down either. Last year alone JavaScript activity on GitHub nearly doubled from the year before. In fact, JavaScript growth continues to outpace every other established language out there.

Maybe you know that already. You also probably know the origin story of JavaScript, right? How Brendan Eich and NetScape fought over design considerations in the language. How the first version of JavaScript for Internet Explorer was reverse-engineered by Microsoft (dubbed JScript). How there were up to decade-long drought periods without new JavaScript versions or official features. Remember how much it sucked building websites for IE6? Man, I’m glad that’s over.

But these early days for JavaScript are pivotal to understand where we are now. These historical restrictions and restraints are what forced JavaScript to become a great language:

When Brendan Eich convinced Netscape that it should have its own scripting language,And Internet Explorer and every browser after that followed suit:

JavaScript became the only language of the browser.
Which forced Javascript to succeed.

The internet wasn’t going to wait for something else to catch up.
Now, the language is catching up.

A language that has slowly become the only true universal language. Java was built to be a universal language, but it never (and will never) get there. JavaScript has gotten there, and that’s a lot to celebrate. A universal language brings product teams together. It helps us leverage more product with less technical debt. It keeps our teams out of silos.

So - we should be asking ourselves - can we keep up with JavaScript? JavaScript might already be great today, and with ongoing ECMA releases, it gets better day by day. Its biggest risk of not becoming great is us, as developers, engineers, product teams, innovators: to not be able to keep up with the pace of innovation demanded today. What can we do? (you should totally reference our slides above for additional insights)

Marc was almost ready to implement his "hello world" React app pic.twitter.com/ptdg4yteF1

— Thomas Fuchs (@thomasfuchs) March 12, 2016

1. Keep it (stupid) simple.

As product teams, we need to realize the debt that any line of code or dependency adds to a product as a whole, and consider that debt a liability. If there’s one skill you should focus on in 2017 to become a better developer, it’s to learn how to gauge the value code actually gives to your product, and whether that value is greater than the debt you take on by adding it. It’s an abstract thought, but so important to be thinking about.

When I hear of stories like left-pad or see still-wildly-popular dependencies like is-array that consists of literally a one-line function: I have to ask, have we forgotten how to be programmers?

2. Write readable code.

Code shouldn’t just be optimized for a machine, it should be optimized for other humans to read it. I’ve heard of this expressed as the “WTF factor” - reducing the number of times you mutter “WTF” when reading code. I like to think of code as a story - I love telling stories. As a species, we’ve been telling stories for thousands of years. It’s one of our earliest activities, and we’ve had a lot of practice at it.

We’ve also built up a ton of science behind storytelling. Did you know that people emit very similar brain activity when they are consuming the same story? This is called neural coupling and causes people to think of the same things, at the same times, in the same way. It’s amazing. Our brains also release dopamine when consuming engaging stories, triggering our brains to commit to memory not just the details of the story, but what we were thinking about at the time.

Wouldn’t it be great if we could trigger the same things in our code?

Well, you can. This is what you should focus on as a coder: letting your code reveal itself like a good story (instead of a puzzle). In that same vain, start looking at the features of JavaScript as your literary tools. The different paradigms of JavaScript—be it functional programming with pure functions and immutability or object-oriented constructs like the class syntax—are just mechanisms to cleanly express your code. Don’t focus on these as absolutes just because other teams say they’re technically better or worse. Use them to articulate how your code behaves and to tell the best story.

3. Don’t try to be an expert in everything.

Pick your tools (wisely, using the advice above) and become an expert in those. It’s okay to have niches, and it’s important to not continually jump ship. After our session, someone asked me what I thought of Angular 2. I should’ve answered “that’s a dumb question.” It doesn’t matter what I think. Angular is being worked on by terrific people and can be used to build terrific products. The question should be: does Angular communicate well to your team?

We stuck to our guns early on with Meteor. We still use pieces of Meteor today because it communicates well with our team and allows us to focus on the story of our product. When we feel that there’s choices that better adhere to the advice above, we certainly choose it over Meteor. But it’s not because someone blogged about it. If we wouldn’t have kept up with Meteor we also wouldn’t be where we are today with Apollo and GraphQL, which is becoming an amazing initiative, and a great benefit for our partners.

In short:

Software is eating the world; Javascript is eating software.

There is no such thing as a non-digital company today. Even in traditional markets, if you’re not leveraging software you’re going to be outpaced by someone that is. Every company is a software company (if you don’t think so you’ll likely be disrupted). JavaScript may not be the perfect tool for every job, but it is the perfect language for a product team to stand behind as their default. We still write Java or Objective-C when we need to. JavaScript as a default allows our team to focus more time on product and the bigger picture. It cuts down walls (if you don’t care for the “make it great again” mantra, I’m sure you can get behind that!). Used responsibly, it can greatly reduce technical debt and complexity.

As a community, we need to work more towards the three things I mentioned above. We also need to create an inviting and distinct culture for all JavaScript developers to follow. JavaScript is a language that’s designed to be written in so many styles and environments, but we need to discover our “JavaScript way” to do things (much like the Ruby world). By walking back towards sanity in the JavaScript sphere, we will get there.