Peter Wagener
Engineering Manager @ Conductor

Started off building CPU's and writing kernel drivers. Have been pushing myself away from the hardware ever since.

So ... JavaScript: Why is it winning?

Reason #1: It survived an awkward childhood.

- It was created in 10 days in 1995 by one guy at Netscape.

- Threading? No. Block variable scope? No. Compilation? Hell no.
Mocha --> LiveScript --> JavaScript --> EMCAScript

- It had people trying to kill it: Mostly Microsoft via JScript & ActiveX in Internet Explorer

But then ...

Something weird happened:

- MSFT invents XMLHttpRequest.
- Firefox & others follow suit
- Ajax becomes a transformational technology.

Douglas Crockford, on JavaScript's survival & success: "It is better to be lucky than smart."

Reason #2: No one calls it fast, but it definitely isn't slow.

Of the four largest companies in the world, one drills oil. The other three are competing to make JavaScript faster.

(remember that benchmarks are artificial measurements)

Side Note: Measurements of DOM modifications are not the same as JS performance.

This is a short section of the rendering process of CNN.com. Note almost every rendering event (Paint, or Style Change), triggers a whole sequence of "reflow" events (in green). This is one of the many things that makes changing the DOM slow.

Reason #3: It Can Bend In Almost Any Way

Functional? Object-Oriented? Reactive? All pretty easy to implement in JavaScript.


The Atwood Principle (Jeff Atwood):

"Any application that can be written in JavaScript will eventually be written in JavaScript."

This is a corollary of the Rule of Least Power.

- Originally an axiom of good design

- The Rule of Least Power was initially codified in 2001 by the W3C (Tim Berners-Lee, Others).

- Principle: Powerful languages inhibit information reuse.

- Simpler languages encourage information reuse, and therefore are more likely to be used broadly:
o HTML versus XML
o Markdown versus RTF

Reason #4: JavaScript is Everywhere.


It's not just about browsers:
- Node JS & NPM providing server-side JavaScript.

- Companies managing massive amounts of data (Netflix, LinkedIn) are migrating large swaths of their infrastructure to JS-based technologies

- The language of AWS Lambda Compute Service

- Used in micro controllers (Tessel.io)
- Used for Robotics (Node Bots).

Reason #5: Lots of People Use It

- Despite it not being a part of many formal educations, there are an enormous number of practitioners.

- Every non-4-year degree program out there (Code Academy, General Assembly) treat it as a top-level offering

- After 2011, more JavaScript has dominated.

- Currently the only languages that are keeping pace are Java and (god save us) CSS.

Reason #6: The Tools

- The IDE-based tools are great.

- The browser-based tools are surprisingly good. There is an arms race there similar to the speed one.

- This is another place where the ROLP comes into play.

- Lots of active competition in the tool chain as well
- Build Tools, Repositories, Testing Frameworks, Modular Frameworks
- All these are competing for developer mindshare, and the best ideas are floating to the top.

Reason #7: The Community is Wide Open

- This is a lot of free code, and a lot of people use it.

- 51M downloads per day
- 1.1B downloads per month
- Broad span of quality, but a sheer ton of it

This is a summary of usage of Bower in the past month.

- Lots of people that actually want to collaborate with you.

Reason #8: No One Claims Ownership

- JavaScript: Multiple Vendors; specs by ECMA & W3C
- Java: Oracle
- Ruby: Yukihiro Matsumoto (Matz); Benevolent Dictator
- Python: Guido van Rossum; Benevolent Dictator
- PHP: Zend + Community
- C/C++: Multiple Vendors

ECMAScript 6 (ES6) is due to be finalized mid-year, after spending ~ 5 years in the making.

ECMAScript 7 (ES7) is now under active development, and is where all the craziness is happening these days.

Reason #9: Workers

They are specified by W3C, but are broadly supported by browser-based JavaScript engines.

Multi-threaded applications are hard. JS has followed the Principle of Least Power here too: threads without shared state are easier to conceive of, harder to mess up.

Web Workers are supported on 85% of Internet users. Only IE9 users (mostly corporate US) clients cannot take advantage.

Every major browser have supported Web Workers for the past two major releases, and there are easy ways to work around that last 15%, and compatibility numbers will continue to grow.

Microsoft Tried For Years.

Google Has At Least 4 current candidates, yet their largest applications use Closure (a JavaScript library).

Apple has vacillated for years between embracing & pushing away. Swift is likely the next language to be made niche by JavaScript. See, React Native JS.

Conductor's Architecture
- Collect, process & store data from The World; expose it via UI Servers & Services.
- We do a lot of client-side rendering already; it allows us to produce interesting, dynamic views into large-scale data sets.
- Use Backbone, RequireJS, Jasmine, and others.

- Open Question: How close to the user can we migrate data processing & service code?