The Rise of the Bully Pulpit in the Evolution of JavaScript

Update: Some conversations on Medium have helped me to refine my argument. While I stand by my original conclusion that there is a need for caution in using experimental language features in production projects, I refined my argument in a new post, A Revised Caution on Experimental Language Features in JavaScript. The original post appears, unedited, immediately below.

Two months ago, Google issued the death knell for AtScript, the language it was previously gunning for the lingua franca of the next generation of web applications.

Largely through insisting that Angular 2 development would be preferable in AtScript than in JavaScript (or even TypeScript), Google had hoped to push a set of language features into the web development ecosystem and perhaps even into the browser.

This isn’t inherently bad, but it is remarkable that the authors of an application development framework might impose their own requirements both on developers and on the languages they use.

Angular is not alone in this recent trend. I am also seeing it now in Aurelia, which is building not only on the rapidly solidifying ground of ECMAScript 6, but also on experimental ECMAScript 7 features.

Though it could turn out beautifully, there is some risk in this. Generally ECMAScript has evolved through considered discussion and debate, leading usually (though not always) to brilliantly architected solutions that empower developers and lower entry barriers to creating business value.

The frameworks have typically followed, building useful tools on top of the best that the language has to offer.

The authors of popular frameworks now know, however, that they have considerably more power than to be passive recipients in the process. They can speak directly to their constituents, and leave language committees pandering to maintain market share.

They can, in effect, leverage a bully pulpit.

When framework authors build on top of experimental features that are not finalized, they do an end-run around the way that JavaScript has historically evolved.

The results remain to be seen. But here is one possible result: ECMA may find itself in a position of having to adopt language features simply because everyone is already using them, not because they are necessarily any good.

No doubt if everyone is building apps with experimental ES7 features and there is a critical mass of those apps on the web, ECMA will have no choice but to adopt them or be left behind.

Proponents would no doubt argue that this is democratic and also that it is good product development. If developers express their needs, the language should account for them. This is a valid argument.

On the other hand, this phenomenon erodes the control of dedicated committees who spend tremendous time and consideration on selecting and designing language features.

Here is another possibility: JavaScript becomes little more to the browser than assembler is in the operating system. Under this scenario, it would be clear that it is not ECMA’s job to define a language that most people code in, but rather a kind or compilation target. An interesting possibility, for certain.

It is too early for me to make a prediction about how this will all pan out.

All I can do is urge developers to think carefully about whether they want to adopt experimental languages features and the frameworks that implement them.

(To Aurelia’s credit, they, at least, have allowed developers to choose whether they want to go all the way to ES7, or stop at ES6.)

Though it is tempting to embrace novelty, we would be doing the entire community a disservice to focus on it exclusively.

Because JavaScript is still the only language guaranteed to be available in the widest assortment of browsers, all front-end developers have to work with it at the end of the day.

We all have a part to play in ensuring that this remains a productive and enjoyable experience.