JavaScript: Web Servers of the Future

I posted an article about the History of Data Validation and I think that was only half of the full idea that was rattling around in my head.  Recently I've been doing a lot of work on single-page applications and the technologies that make them possible, but what's really interesting in this world is how to reuse server assets on the client and vice versa.  At the end of my previous post I was talking about Node.js and sharing server code with the client.  I believe that is how all web applications will be written in the future; the specific technology might vary, but conceptually that's how they will be built.

Don't believe me?

Microsoft has been developing TypeScript for several years now and many view it as a competitor to languages like CoffeeScript.  I don't think that is the case at all.  TypeScript's primary goal is to allow developers to write enterprise-scale JavaScript applications in a manageable, reliable, scalable, and structured way; they're trying to eliminate the fragility inherent with JavaScript.  TypeScript accomplishes this by making it easy to write modular code and by layering in a type system that gives you compile-time checking (which also gives you Intellisense).

On top of that, Microsoft has continued to advance the Windows Runtime for some time now, which allows you to write Windows applications in JavaScript.  That JavaScript code loaded in the Windows Runtime is then executed in a hosted instance of Chakra, the JavaScript engine powering Internet Explorer 11 (it started in IE9).  This is very similar to Google's V8 JavaScript engine that is used to power Node.js.  Not too long ago, Microsoft actually released an API for Chakra that allows you to host the JavaScript engine inside your own application, which means that someone could build a Node.js-like web server that runs on Chakra if they really wanted to.

I think JavaScript is quite powerful and the benefit of using the same technology on the server and the client has an incredible amount of potential that's on the cusp of being tapped.  As soon as you have a truly shared code base between the client and server, I think the traditional division of where functionality belongs will get fuzzy.  This means that you're free to shift more of your application to the server or push more of it into the client with very little effort; it's entirely up to you and the requirements of the application you're building.

Still need proof of the impending shift?  It's already happening in places you might not expect.

Since Microsoft has been putting such a huge investment into TypeScript, I can't help but think they saw this coming a long time ago.  In fact, Microsoft's project "Monaco" (a Visual Studio IDE in the browser) is 100% TypeScript on the client and on the server, and it runs entirely on Node.js (not IIS like you might have expected).  TypeScript has allowed them to build a massive JavaScript application with complete confidence in their code base.  I saw a really interesting talk at BUILD about this very topic.

If you're a server-side developer and don't know anything about JavaScript, I encourage you to learn it now while you're still ahead of the game.