Is The Death Of JavaScript Upon Us, Or Is A Universal Language Transformation Underway?

Editor's note: Péter Halácsy is co-founder and CTO of Prezi. Follow him on Twitter @halacsy.

Startups identify with JavaScript. When you're just starting out, you need to be dynamic. You need to be flexible. You need to be able to bust out a prototype that just works, and you need to be able to change it on a dime without recompiling your code. JavaScript was once the startup of the browser wars, and it crushed Java and Flash for the same reasons that startups have the ability to disrupt markets and displace the established players: agility and flexibility.

Today, JavaScript is no longer a startup, and it's no longer just startups that are using it. Companies of all sizes and levels of maturity build applications for the browser, and JavaScript is the language they use to build them. The demands that were once placed on languages like C/C++ and Java are now shifting to JavaScript, and that shift is exposing the language's limitations: performance and maintainability.

Those in the latest generation of JavaScript engines deliver incredible performance gains, but these still aren't enough. Look at sites such as YouTube and Hulu, as well as Facebook's and EA's gaming platforms. When it comes to demanding multimedia applications, companies still turn to Flash for performance. The oracle of Steve Jobs may have predicted the ultimate fate of Flash, but we still have to deal with it until JavaScript can match its performance.

Once your codebase reaches hundreds of thousands of lines of code, and it's all written in a dynamic language such as JavaScript, development velocity starts to suffer. If you make modifications to one side of your codebase, there's no way to know if that is going to introduce bugs somewhere else without actually running your application. Testing can only get you so far; there are only so many contingencies that you can anticipate. The result is either more buggy software or longer release cycles.

Somebody needs to address these limitations so that companies can continue to innovate and build amazing applications for the web. Who's going to do it and how?

JavaScript is caught in an iron triangle of its own making.

Prezi, LogMeIn and Ustream organized MLOC.js, a conference to focus on how to scale JavaScript. Engineers from Google, Facebook, Mozilla, Groupon and others who are working to solve immense technical problems gathered for three days in Budapest to discuss how they're tackling the limitations of JavaScript that companies are grappling with today. Their work will ensure that JavaScript is not only a viable platform for the future, but one that will change the way we write applications on the web.

Here's my takeaway: JavaScript is caught in an iron triangle of its own making. We've all grown accustomed to the flexibility and freedom it offers, and we don't want to give that up. At the same time, we want it to be blazing fast, and it turns out that when you reach millions of lines of JavaScript, maintaining such a flexible language becomes a problem. All three of these areas — flexibility, performance, and maintainability — are intertwined. When you make progress in one area, one of the other two, or even both, will suffer.

This tells me that there is no one silver bullet that will solve these problems, but there may be many that do. JavaScript is a dynamic language that excels at being the glue of the web, and that shouldn't change.

Business logic needs to work, and it needs to work correctly. The static analysis that systems such as Dart or TypeScript offer is essential to ensuring that the most sensitive components of our applications work — and continue to work as our applications grow and evolve. We need more static analysis tools like these. However, given the browser market, it's unlikely that we'll see widespread native support for these technologies any time soon.

It turns out that native support for new languages isn't always necessary. Alon Zakai from Mozilla spoke about ASM.js, a subset of JavaScript that runs extremely fast on modern browsers without modification. When speed matters, we should be writing ASM.js. Or even better, we can write our code in C and have a compiler generate the ASM.js for us. Beyond performance, we can apply this technique to other languages and other use cases. Developers are already doing it, and all their efforts are listed on atl.js.

One of the best ways to make your code more maintainable is by writing less code. Libraries like bacon.js or the Elm language succinctly express complex data dependencies in your application and offload the work of keeping your data up-to-date to a library. The result is less code that we have to maintain and higher quality applications.

JavaScript isn't going anywhere, but it is undergoing a transformation. Developers are creating language variants and expressive libraries to better handle specific use cases, including performance. They're making progress on tooling and static analysis, as well. All these trends are changing the way that we write applications for the web. After MLOC.js, that much is certain.

For the big players out there, the ones who use JavaScript every day, only one question remains: How are you going to contribute to making JavaScript the most flexible, performant, and scalable language we've ever known?