Few people would dispute that JavaScript has become the lingua franca of the web and is one of the most important programming languages in the world today. There's no question that if you want your website to have dynamic, interactive features, you should be *using* JavaScript. The question you need to consider is whether you should still be *writing* it.

JavaScript has been called "The Assembly Language of the Web", but that's a slightly flawed analogy. Assembly, which is just one step above binary machine code, is hardware-specific and notoriously non-portable. That's exactly the opposite of JavaScript, which can more accurately be viewed as a virtual machine for web browsers — something other languages can target.

Consider the attitude toward low-level assembly languages 30-40 years ago. The attraction of writing programs in pure assembly language was that it allowed highly skilled expert programmers to produce code that is extremely optimized for size and performance. Compiled languages (like C, FORTRAN, or BASIC) were easier to work with and could be ported between systems much more easily, but they were often slower and orders of magnitude larger. Thirty years ago it was common to hear statements such as "Higher-level compiled languages are convenient, but they'll never be able to compete with hand-optimized assembly!"

A funny thing happened, though…actually three funny things:

First, Moore's Law worked in our favor such that the performance difference between human-written assembly and compiler-generated code practically vanished.

Second, the scope and complexity of programs increased by several orders of magnitude, making assembly code-bases harder to manage, particularly with large teams.

Finally, and perhaps most significantly, compilers improved significantly. Vast resources were focused on improving the performance of compilers and the efficiency of higher-level languages. Eventually, they reached the point where the assembly code they were producing was smaller and more efficient than what average developers could write.

JavaScript's current situation is very similar. Browsers, especially on mobile devices, are significantly faster than they were just a few years ago, and much effort is being invested in further improvements. At the same time, we're asking JavaScript to do far more now than we were as recently as five years ago, and arguably much, much more than it was intended to do. It is, after all, 18 years old, and originated in the very early days of Netscape and IE. Some would argue that JavaScript is being stretched well beyond the "sweet spot" of its capabilities, helped along thus far only by its inherent flexibility.

That's actually a very common pattern for programming languages: They begin as solutions to specific types of problems, then they're generalized to solve many other existing problems. As new types of problems arise, they're expanded to address those as well, gradually expanding until the weaknesses in their underlying models become apparent, at which point they're supplanted by new languages and/or tools that address those weaknesses.

As such, as we've learned more in recent years about what we actually need JavaScript to do, many very smart people, along with some very powerful companies, have begun investing in new tools to solve those problems.

In particular, some of the major problems they're attempting to solve are:

1) Writing Better Code –

You may know how to write good JavaScript code now, but odds are that it could be much better. Take a look at the code for jQuery and honestly ask yourself if you have the time (or the skills) to produce something better. The flexibility of JavaScript, which is one of its great strengths, also allows for some truly terrible shortcuts and misapprehensions of behavior.

2) Scaling Projects –

A long, long time ago (around 2005), JavaScript was just something you added a little of to a web page to get some more interactive features. Those days are long gone, though, and the modern era of fully interactive web-based applications calls for ever-increasing amounts of client-side JavaScript. JavaScript code snippets that were manageable for a few developers across a handful of pages become increasingly unwieldy with dozens of developers and scores of pages.

3) Portability –

Yes, JavaScript is portable between browsers, but we all know that "portable" doesn't mean "identical," and that there are countless small differences that need to be taken into account when moving code between browsers.

4) Longevity –

Portability applies across time, too. Does the JavaScript you wrote for Firefox in 2009 still work the same under Internet Explorer in 2013? For that matter, does what you wrote for IE last year still work correctly today? Complex web applications have far longer lifespans today than they did just a few years ago, and time spent going back to rewrite "completed" code is time spent not moving forward.

The emerging solution to these problems is to write less JavaScript, and instead, write in higher-level languages from which JavaScript is generated by pseudo-compilers or interpreters.

Using tools to generate JavaScript potentially produces better code, since it allows you to take advantage of the expertise of the experts who created the tools. In many cases the improvements are as simple as automating things you know you *should* be doing but probably aren't, like good scope practices. In other cases, the improvements can take the form of more esoteric optimizations or just simple minifying. In either case, unless you're a serious JavaScript expert, it's increasingly probable that the tools written by people who *are* will do a better job than you.

By enforcing naming, typing, and scoping rules that aren't native to JavaScript, many of these tools make it easier to scale projects and reuse code, especially between multiple groups.

Also, by allowing you to regenerate your JavaScript at any time under new rules, or multiple sets of rules, these tools can make it easier to address cross-browser needs or adapt to evolving capabilities and standards.

Let's quickly look at a few examples:

ClojureScript:

Clojure is a Lisp language targeting the Java Virtual Machine. ClojureScript is a specialized version of Clojure that targets JavaScript for output instead of Java bytecode. If that distinction doesn't mean much to you, or the mention of Lisp didn't get you excited, then ClojureScript may not be your best option.

Dart:

Also from Google, Dart represents less of a departure from the C-style syntax of JavaScript, which may make it a more comfortable alternative for those comfortable with JavaScript. What separates Dart from the other alternatives is that in addition to generating Javascript, it can also compile to bytecode intended to run in a dedicated Dart virtual machine. Although currently limited to experimental versions of Chrome, the performance is significantly better than standard Javascript, and the approach at least represents an attempt to advance the state of the art.

TypeScript:

TypeScript is Microsoft's solution to the shortcomings of JavaScript. So far, it seems to represent the smallest departure for Javascript developers, since its main purpose is to enforce a type system on JavaScript code, thus making it easier to generate and optimize.

Although it is still possible to create some truly incredible programs using assembly the vast majority of production code is produced in higher level languages. Similarly, while JavaScript still dominates client-side web programming (and is making inroads on the server), and will continue to be significant for years to come, it seems inevitable that it will eventually be supplemented, then replaced, by higher-level alternatives that empower us to create better user experiences easily and safely.

At least let's hope so!