Every Programming Language Needs Its BabelJS
It’s without doubt that BabelJS, the most famous of the future-to-present language compilers, has been helping the JS spec development community iterate — to put it in JS terms — asynchronously in a try/catch block, with the output being that language spec writers can see their spec implemented before they finish writing it. Language development, when it comes to Javascript, has been turned into a non-blocking process so it can run concurrently with the main thread of Javascript development, and not as an isolated process. This has given Javascript users and developers a tremendous advantage, one that I believe gives it an edge over other languages.
While today we may look at languages that we speak of fondly, like Clojure/Script and ReasonML, we can see that the rate of innovation in Javascript language development is unstoppable, and much faster than that for any other language, including the ones I mentioned.
It is no doubt that quantity of spec writing is no indication of the quality of the language development process, the current setup with BabelJS as the de facto Javascript target, spec writers are able to test their assumptions and reasoning around language development much faster and much more accurately given the size of the crowd that these new ideas get tested by.
As you can see, we have managed to evaluate in several different directions at once multiple strategies for handling asynchrony. We had ES6 Promises, generators, async/await, then async generators. We still don’t have ClojureScript’s core.async (modeled after Go’s channels/csp) or scheduler-level concurrency constructs like OCaml’s multi-prompt continuations (https://github.com/strmpnk/hansei/tree/master/caml-shift), but what we do have is some proposals to take us there, like this one(see https://esdiscuss.org/topic/one-shot-delimited-continuations-with-effect-handlers), which for now we can see at a higher level in the form of the Fiber abstraction in React 16. If someone wanted to write a Babel plugin that made one-shot delimited continuations, multi-prompt continuations or any other concurrency construct available in userland and on general basis they certainly could do so. Nothing is stopping them (http://shuheikagawa.com/blog/2015/09/13/lets-create-a-babel-plugin/) Once such concepts are proven in userland, those who author ES specifications will take notice. BabelJS is definitely accelerating the development of Javascript as a language, and every language needs its BableJS.
In other words, Javascript doesn’t only have BabelJS propelling it forward but also the forward thinking of the React team.
So it’s hard to see a future where any Compile-to-JS or Compile-to-WASM language evolving faster than JS itself.
The conclusion being made here is that every language should have its own BabelJS just to keep up with JS in terms of the speed of language design evolution.
