Keep Betting on JavaScript

Brendan Eich’s famous quip, “Always bet on JavaScript”, revels in JS’s history of naysayers predicting that we’d eventually reach a point where JS couldn’t grow to meet the demands of modern development; it turns out those have always been bad bets.

It’s safe to say JS is no longer trying to prove itself. It has arrived. Even if it was once a “dumb kid brother” to something like Java, it’s now fully a first class citizen in the programming language ecosystem. JS is certainly not the only dominant language or the “best tool” for every situation. But increasingly, most tech stacks have it as a central part of their strategy.

In this talk, we’re going to look forward at what’s over the horizon for JavaScript, the world’s most ubiquitous and popular (by usage if not emotion!) language. We’ll look at Web Assembly, upcoming proposals that will be game changers for the web platform, and more. A bet is always a guess, but let’s explore why bets on JS will only get sweeter.

Find all of Kyle’s fantastic books at github.com/getify/You-Dont-Know-JS

Kyle begins with a moment to reflect on the privilege we hold; and the cultural problems we have with ideas of meritocracy – ideas over people. That’s bullshit! The people are what matters. Our jobs are to communicate and cooperate with humans. We all started somewhere, we all have different lives, we need to think more about empathy. Think about the person behind the pixels on your screen.

The best way to predict the future is to invent it. – Alan Kay

This doesn’t mean we have to just go do, do, do. Kyle feels there’s another way to frame things: what direction are we headed? What is our responsibility in the future direction of any given thing we are talking about (including JavaScript)?

Comparison photos of the iterations of Mercury rockets

A brief and incomplete history lesson on American spaceflight… beginning with the Mercury rockets. They could not go directly to fully-crewed space flight. They started with a single person in a tiny survival pod, doing very little; and each mission was designed to test out things they’d need to put together. Then the Gemini project came along, which could fit two people with a greater role to play. Then the Apollo missions came along, starting to do things while in space.

So getting to the moon took lots of baby steps. Lots of iterations. Can we take some inspiration from that, look ahead by a decade to see where things are going; then have the discipline to do the work to get there?

Brendan Eich coined the phrase always bet on JS. Whenever people bet against JS they end up being wrong. Of course that’s not how gambling really works, because in true gambling history means nothing. Your odds never change.

So Kyle says keep betting on JavaScript. The future of JS is not as certain as people might assume.

A quick history of Kyle’s journey. Like many people, he learned about cool tricks on the web by viewing source. This is one of the most fundamental reasons the web (and javascript) have won so far. When we are curious, we can find out how did they do that? There’s no closed wall – you can see the code.

Kyle wanted to know how people did funny tricks like mouse cursor trails. That particular trick wasn’t important, but view source is how he learned. His knowledge took bigger steps forward when he started doing paid work on the web. He eventually built southwest.com, which included the first exposure to a UI framework (YUI)… but right before launch they wanted it to work in Netscape 4! So he had to hack through all kinds of code trying to make things happen.

For a little while he ‘cheated’ by using Flash to do stuff. Although Actionscript meant it wasn’t cheating all that much. At one point he used a Flash/JS hybrid to produce an XHR library.

Like everyone else jQuery brought him back; and he looked into the library a lot.

I didn’t even know $ could be a variable name!

But there’s only so far you can get reading other peoples code.

There’s an old joke comparing ‘complete Javascript’ books against Javascript: the good parts. The problem with abridged versions of things is that you get the high points and not the full understanding. There were lots of gaps. Kyle wrote You don’t know JS to fill those gaps, largely because he realised the best way to learn was to teach others.

Kyle’s journey has been made up of baby steps.

So, to JavaScript… The first standardised versions of JS came in the late nineties; and the first really complete spec was ES3 in 1999. ES4 never really happened, it was used as ActionScript3 but never as JavaScript. E4X also died, it had a lot of problems.

ES5 came a decade later; and ES6 about five years after that. They had heaps in them, but they were things that people were trying and working on way back in the ES3/ES4 era.

Naming is tough, we have ES6, then ES2016, ES2017… yes the years are correct from 2016, but not before.

Talk recommendation: Dream big, think small @petrosalema #fronteers14 … the idea is that big things happen when people do lots of small things to progress them.

When we say we ‘stand on the shoulders of giants’ we acknowledge all the work that has gone before. The best work is incremental.

So the question then – things to bet on?

Bad bets:

  • Things that assumed the web was headed towards sandboxes. Flash, NaCl, Silverlight, etc.
  • App stores. They’ve paid off in the short term, but in future we’ll think of them as a bad idea.

Good bets:

  • JS
  • HTML5
  • CSS3
  • PWA

Open collaboration has beaten closed off silos in the long run. We can look to space and see that the International Space Station was more successful than the competing projects that existed before.

We are a big fork in the road now in space… we have government and private/corporate visions for space travel going in very different directions. For JavaScript, we have a fork in the road… JS about the language; vs JS about the machine.

Small steps mean things look like they’re going in the same direction at first, but at the end the differences become much more obvious.

JavaScript the language: cdshmncmmnctn vs. code is human communication …. we have very different ideas how to write the code. JS is the lingua franca and yet it can be written wildly differently, perhaps partly because it allows multi-paradigm coding.

JS is becoming more declarative – declaring the outcome, not the steps to get there.

Backwards compatibility is a difficult issue for JS. We’d love to break away from old ideas, but JavaScript remains massively backwards-compatible. Yes we have to endure the inconsistency and odd choices from the early days, but old code still runs.

A lot of the current problems with JavaScript are not about the language. Performance, DOM limitations, etc… these are not about the capability of the language. The language itself has a heap of great features and lots of new ones coming that people will be really happy using.

JS has gone a long way from the primitive ten-day version, to the serious language it is now.

JS has been adding features designed more for compilation and frameworks than the average developer. Shared memory, wake and wait… these are features most people are unlikely to use.

Compilers are the new frameworks (Tom Dale). There is an increasing gap between the code we write and the code we serve in the browser. The biggest fork in the road is WebAssembly/WASM. It’s incredibly powerful… but wither view source?

So we have a tale of two JavaScripts: one for the language, one for the machine.

Kyle thinks the future of JavaScript needs to be JavaScript for humans.