« Back to home

One language to rule them all: a manifesto.

Posted on

Javascript is everywhere. Javascript is the only language that runs in your web browser and on your desktop, your phone, your server, and your Raspberry Pi.

Unlike many, I believe Javascript is a beautiful language. I don't believe this because Javascript has numerous weird bugs ..erm "quirks". I don't believe this because I think hoisting, anonymous functions, prototypal inheritance, and loose casting are ideal. I think it's beautiful because the constraints it faces make it stronger.

Most languages aren't built with asynchronous behavior in mind. But the nature of the web is that everything is asynchronous: user actions, CRUD operations, image/script/css/asset retrieval. All of it.

Yes, some of these things can be made to behave synchronously, but when they do they affect one of Javascript's other beautiful constraints: Javascript is single threaded.

The advantage of single threaded behavior is in the challenge such a limitation presents. Why do ES6/ES7 bring the Promise and async/await specs? Because these are needs and APIs that JS developers battle tested while trying to maintain non-blocking IO. How did the runLoop in node turn into such a big deal? Because it showed that non-blocking IO on a single thread could far outperform a thread based solution when scaling requests.

Of course, none of this means that Javascript needs to be or should remain single threaded. But the constraints of the language have (and continue) to cause Javascript to evolve as a language the solves real-world problems. With the use of transpilers, it won't be long before all our applications are written with ES7 code. With the advent of evergreen browsers (thank you Edge for joining), it won't be much longer too until even ALL our browsers run our ES7 code without that transpilation step.

Could your app use the efficiency boost of being able to strictly cast some vars? We'll get that eventually. Strict classes? We'll get that too. JS runtimes have already made JS an extremely fast language, it won't take the language evolving much to close the 17% gap between optimized JS and optimized C++.

Need threads? Try WebWorkers or Shared WebWorkers. Need threaded rendering?

Wait, what?!?

Yeah, I just said that. I'll say it again. Need threaded rendering?

What if we treat the main thread as just the ui-assembly-thread, nothing more? Want a snappy application with super fast route rendering? Choose the ideal spot, swap out. Fast internet connection? Reach out to the server. Nothing going on on the main thread? Render there. Where exactly could/will this go?

  • if WebWorkers are given the ability to create a DocumentFragment
  • if Ember or React's fastboot servers are embedded within your Cordova application

Imagine the possibilities. You have a complex and demanding interface. Possibly you've used html-gl or react-canvas or a customized webView or similar to improve your rendering (don't worry, better solutions ARE coming). Regardless of final rendering environment, your one thread has a lot to handle. What if it just assembled?

Your route hits a Shared WebWorker which delegates various components on the page to be rendered by other threads, each with then transfers a completed documentFragment to the ui-assembly-thread for DOM insertion. This could end the native vs. HTML5 debate. Native is HTML5 is native.

Javascript is mutating, evolving, and iterating in a much different manner than any other language. And it's doing it organically, based on the involvement, feedback, and usage of hundreds of thousands of developers. Not many languages get that sort of privilege.