Writing Javascript without writing Javascript

Last updated on Friday, November 2, 2018

A while ago I tweeted a poll, asking which "compiles-to-javascript" language you would choose when starting a new project. I'd like to shed some light on why I asked the question and what I'm going to do with the results.

This is the first in a series of 5 posts. Post will be updated with links to the other articles.

Some background

I've written Javascript for a long time now. First because as best I knew at the time it was the only language you could program with in browser. Then later because I didn't have interest in other languages, or enough knowledge to successfully use any of them. Whether a lack of understanding of category theory or a disinterest in Java's programming model, I always stuck with JavaScript. I've since come around to using statically typed systems (I've used both Flow and Typescript in production), and while I absolutely enjoy both, I also understand there are limitations to bolt-on type systems. I'd like to explore those limitations, and see what compiles-to-javascript languages have to offer.

"I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail."

Javascript as a compilation target

There are languages that compile to Javascript, and offer other ways of ensuring program correctness. Mechanisms such as static typing, and exhaustive pattern matching. Now, up to here you might think that I don't like JavaScript, or that I'm going to go into why I think it's broken. You'd be wrong though. I think Javascript is an excellent programming language, and that despite anyone's opinion about it, it's everywhere. What I do think, though, is that it's not necessarily a good solution for every problem. "if all you have is a hammer, everything looks like a nail", so to say. When starting a new back-end project, is it not also wise to research which programming language best solves your unique problems? That's not to say it's a problem restrained to simply "this language's syntax is the most natural fit to the type of project we're running". There are other factors you would consider:

  • How easy is it to attract additional engineers and onboard them?
  • How viable is its ecosystem in the long-term?
  • What facilities does it have for debugging?

It seems only fitting, now that Javascript is increasingly being considered a viable compilation target, that we now make the same considerations in the front-end space. So, let's look at building a real-world application.

The requirements

I'm in the process of setting up a basic application specification, in broad strokes it will need to:

  • Communicate with a RESTful or, preferably, GraphQL API
  • Have multiple routes
  • Share state between at least 2 of those routes, without loss of already fetched data
  • Interop with existing JavaScript ecosystem (notably d3 and React, preferably a third party React component as well)
  • Run self-contained in docker

In the process of replicating the application's functionality, I'll of course be reading documentation, interacting with their respective communities, and in general trying to get a feel for what it'd be like to use this language every day and maintaining it long-term. If a community is hostile to beginners, there's very little I can do when more front-end engineers are on-boarded, and that's not something I'd feel comfortable exposing my future colleagues to. If a language releases breaking changes often, and the upgrade process is manual or not well supported by automatic tooling, that's a lot of extra work to take on, which needs to be carefully weighed. All this to say, choosing an obvious winner might not be so straightforward.

So, let's meet the competition...

Typescript & Flowtype

I've grouped these two together, which led to some resistance on twitter, but I will evaluate them both independently. I'm obviously not going to rewrite everything from scratch between these two, and seeing how to add typing to existing code will be important, so I'll start out with some stand-alone UI work.

Flowtype https://flow.org/
Typescript https://www.typescriptlang.org/

ReasonML

There's plenty of buzz around ReasonML, which makes me both interested and weary. Hype wears off, but will it be maintained after? Seeing it has Facebook's backing, and they're building Messenger.com with it, gives me enough confidence to at least take the language into serious consideration.

Website https://reasonml.github.io/

Elm

Elm was all the rage about a year ago, and I'm happy to see the language and its ecosystem are progressing after the hype wearing off somewhat. There were plenty of encouraging remarks from people replying on twitter, and Elm is famous for its friendly compiler, so I'm stoked to put some real time into working with it.

Website http://elm-lang.org/

ClojureScript

I've always been curious about ClojureScript. Reading Clojure code feels the farthest removed from Javascript I've ever seen. I've been reading a little bit about LISP's history, and I can't help but be intrigued. I'm looking forward to learning more about it.

Website https://clojurescript.org/

Take me home!