Will Anyone Be Writing JavaScript In A Couple Of Years?

JavaScriptJavaScript has its problems. If we (or Brendan Eich) could go back in time and create the ideal language for front-end development, it’s unlikely it would look like JavaScript. But for nearly twenty years, JavaScript has been the only game in town. JavaScript is supported in web browsers, and that’s what we have to use, whether we like it or not.

However, just because the web platform runs only JavaScript, it doesn’t follow that we have to write JavaScript: we don’t have to write assembler if we want an application to run on a PC. Instead, we write in C, Python, Ruby, Java, or whatever other language we choose and compile to a language our computers understand.

Recently, languages that compile or transpile to JavaScript have become increasingly common. So common, in fact, that it’s hard to know which of them should be taken seriously. Many experienced JavaScript developers reject these language because they believe the only way to understand and control the web experience properly is to embrace JavaScript. To my mind, that isn’t much different to the bearded sages of the early days of computing dismissing “high-level” languages like C because assembler gave them so much more control.

CoffeeScript

CoffeeScript is probably the closest of this group of languages to plain-old JavaScript. It doesn’t attempt to add new features to JavaScript, instead opting to add a layer of syntactic sugar that makes JavaScript more pleasant to code in. Taking its cues from languages like Ruby and Python, CoffeeScript attempts to smooth out JavaScript’s rough edges. It transpiles cleanly to the equivalent JavaScript.

If you wanted to create something like JavaScript, while learning the lessons of Python and Ruby (with a sprinkling of Haskell magic), it might look something like CoffeeScript. In fact, JavaScript’s creator is a fan.

TypeScript

TypeScript, which is developed by Microsoft, goes a step further than CoffeeScript. It adds features like optional static typing and class-based object orientation while encompassing all of JavaScript. It bills itself as a strict superset of JavaScript, which means ordinary JavaScript is valid TypeScript, but developers have the option to use the additional features if they choose.

Elm

Elm, which I think is the most exciting of the languages we’ve looked at here, goes much further. Elm is not an expansion of JavaScript or simply a nicer syntax, it’s a completely different language that compiles to JavaScript.

Elm is a statically typed functional programming language that enforces immutability. It’s heavily influenced by languages like Haskell, although, unlike Haskell, it’s easy to learn if you have some programming background (no computer science PhD. required).

Elm is intended to be a complete front-end development language. Although it compiles to JavaScript, that JavaScript is capable of writing HTML and CSS too, which means the entire front-end application can be written in Elm. Elm is a powerful functional language in its own right, which means no more kludgey templates — you get all the power of Elm when writing CSS, HTML, and JavaScript. Because Elm is statically typed and immutable, its compiler can spot common bugs that impact JavaScript developers at compile-time. In essence, there are no run-time errors for Elm code – the only bugs are logical errors the developer makes. The JavaScript it produces is also blazingly fast compared to competing systems like Facebook’s React.

Adieu, JavaScript?

I think it’s likely that JavaScript will be around for many years to come, and by that point, discussing languages that compile or transpile to JavaScript may be moot. Web Assembly could take its place as the web’s development target. In that case, Elm is likely to be the victor because it would be relatively straightforward to use WebAssembly as the compile target for Elm, instead of JavaScript.

What do you think? If you were embarking on a new front-end web development project today, would you choose plain-old JavaScript, or would you opt for one of the languages we’ve discussed here?

Matthew Davis is a technical writer and Linux geek for Future Hosting.

Dedicated Server Special

Take advantage of our Double RAM offer on the E3-1230v2 4 x 3.30GHz+HT server! Only $134.95 per month. Managed and Unmanaged options available at checkout.

GET STARTED
  • Chad Windham

    “Many experienced JavaScript developers reject these language because they believe the only way to understand and control the web experience properly is to embrace JavaScript. To my mind, that isn’t much different to the bearded sages of the early days of computing dismissing “high-level” languages like C because assembler gave them so much more control.”
    I see the comparison you are making… but that also isn’t a great comparison. A higher level language that compiles down is a valuable tool. But things like typescript are “transpiled” because it is in no way on a higher level than vanilla js. I work with typescript every day. And I would much rather us vanilla JS in its place. Because in order to be good at typescript. You actually need to be pretty good at basic JS in the first place. Typescript is simply an extra layer of abstraction that is not needed (and in my real world working experience of it, not very useful). I think it is silly to for everyone to hate on stuff like JS or PHP. They are high level tools that do their job (pretty darn well at this point) that also have some quirks. Just learn vanilla JS very well. You won’t regret it, I promise.
    That being said, I’m currently learning ELM because it seems pretty awesome, is not a superset of JS, is a dedicated tool that seems to really have something to offer that JS supersets don’t, and potentially (and maybe the biggest reason) can target Web Assembly down the road.