Designing CoffeeScript like Elixir

I just finished working through a backend project from an Elixir book. When I started working on the frontend, suddenly all the inefficient syntax of JavaScript bothered me a lot more.

I looked into CoffeeScript 2. It smooths over JS syntax (like Elixir does for Erlang) but doesn’t quite take the same “build upon” design of Elixir. In other words, it disallows certain JS syntax, meaning if I put JS in a .coffee file, I don’t get the guarantee that the code will compile (as I do in Elixir).

Additionally, the compilers’ errors are not at Elixir’s level either.

I like JSX because ultimately programming languages amount to DSLs, which then can be extended. ElixirScript, to me, looks too much like backend code and is harder to read. When I see JSX, it makes clear to me that this code will appear on the page.

I say all that to suggest that I think with a revision from someone with a “build upon” mindset (i.e. all JS will be guaranteed to compile, the resulting code has better code style, and the compiler errors are revamped), CoffeeScript can remove the friction of Javascript’s syntax like Elixir does masterfully for backend development.

By removing this conceptual friction, I think it will speed up frontend development. (I am thinking of react-native-web, which is finally delivering on the promise of “Write once, use anywhere.”)

The principle I’m getting at is that in Elixir, everything exists for a purpose–all syntax is meaningful and makes the language more powerful. This is the direction I’d like to see JavaScript grow in.

I.e. treating JS more like a VM.

Well, Web Assembly aims to fix that, however the JS syntax, “semantics” and legacy themselves are a catastrophy which will not be ever fixed – too many projects rely on them.

As much as I like seeing languages like Elixir, LISP and OCaml in the browser, I keep thinking that the dedicated efforts such as React Native will eventually win, but who knows.