Deliver us from TextMate, vi, and emacs.

Some years ago, we would have followed TextMate to whatever end. Now, however, we see that TextMate was a false prophet. He led us down a garden path but abandoned us before we reached the promised land. In our desperation, we turned to the elder sages: vi and emacs. Alas, they seem curiously unaware that it’s 2009. You know: 2009. The year before the year we make contact.

Editor Gods, we don’t ask for much. We just want an editor that makes us stand up and shout: “Hey! The future is here, and I’ve got a text editor to prove it!”

While we’re praying, we might as well let you know exactly what our hearts yearn for.

(more…)

I’ve been building rich web applications for quite some time now. These days, my back-end code is written in Python or Ruby and my front-end code is written in JavaScript.

As I build more sites, two important patterns have come to light:

1. I implement model classes on both the front and back ends. This allows me to manipulate my models wherever it’s most appropriate; for cool AJAX features, this is usually on the front-end.

As a result, I am forced to implement the same class — for example, a class that represents a user or the state of a game — in two different languages. I then have to do the work of marshalling model data between the back-end and front-end. Right now my marshalling is often one-off, but it occurs to me that this really shouldn’t be the case. It also occurs to me that it would be a lot more desirable to just implement each model once, in JavaScript.

2. Much the same: sometimes I generate large blobs of HTML on the server side; sometimes I need to generate the same blobs of HTML dynamically on the client side. 

A typical example is a contact list. Depending on the size, it might be desirable to generate HTML for known contacts on the server side. But when you add a contact you probably do so via AJAX calls, which means you need to dynamically generate that same HTML blob via JavaScript. There are plenty of approaches to this problem, of course — you might decide to always dynamically generate on the client side, or you might have the server return some HTML in response to an AJAX call (yuck!) — but the cleanest approach would certainly be: write the generating code once and use it everywhere.

Batteries

I am aware of some template languages that approximate a solution to my second problem. Most recently, the json-template library made a bit of a splash. None of the libraries I’ve evaluated so far seem to capture the full problem.

And my first and frankly more pressing problem? I’ve seen no solutions whatsoever.

These thoughts have led me to believe that JavaScript should be the next big language. The obstacle, of course, is that while JavaScript works pretty well inside a browser, outside of a browser it is largely a naked language. What is a scripting language without the ability to talk to a database, fetch a URL, access files on disk, or interoperate with web servers? Heck, what is a scripting language without a basic system for defining and importing modules?

For these reasons, JavaScript is currently a non-starter on the back-end. I’m hopeful that someone will take up the mantle and build both the batteries — the APIs that server-side JavaScript so desperately needs — and the standards for those batteries so that we have one language with one library, rather than many.

I should mention that I don’t think server-side JavaScript APIs need to look anything like client-side JavaScript APIs, though there would certainly be some crossover — DOM APIs belong on both sides, for example. I would look to the Python and Ruby worlds for inspiration about what sorts of APIs JavaScript needs before it can become the one language to rule them all.