Dave Ford's Programming Blog: One Language for Client and Server

Some web developers categorize themselves as a "front-end" developer or a "back-end" developer. For large teams, this specialization is a nice luxury. But more often than not (I think) most developers end up playing both roles. I'm glad that I play both roles, because often it takes an intimate understanding of both, to create the best overall architecture. Often the most important part of an architecture is deciding what should be part of the the front-end and what should be part of the back-end and the communication protocol between the two. Thus, I proudly categorize myself as an end-to-end developer (or a front-back developer?).

Side-note #1: The terms front-end and back-end is not necessarily the same thing as client-side and server-side. But for this post, this is how I am using them.

So here is the problem with being an end-to-end developer. The predominate programming languages for front-ends are JavaScript and ActionScript. The predominant language for back-ends are: Java, C#, VB.NET, PHP, Ruby and Python. This means developers must learn at least two languages to do their job (lets ignore CSS, HTML and SQL for the moment). This is good for me personally, because I enjoy learning new languages and (as luck would have it) I already know most of the server-side and client-side languages. But most of my clients (corporate IT developers) must also spend time learning their own problem domain (insurance, medical, banking, or whatever). These people are not as geeky as me and don't enjoy learning new programming languages for sport. Many come from backgrounds where they used to create entire applications using only one language like VB, PowerBuilder or Oracle Forms. Thus, I ask the question, how much more productive can we be if we can use the same language end-to-end?

My guess: very much more productive.

Side-note #2: Sometimes additional, more special-purpose languages are a good thing. There is even an acronym to represent the concept: DSL - (Domain Specific Language). Examples of DSLs include things like HTML, CSS, SQL, XSLT and regular expressions. But when I speak of a single programming language for front-end and back-end, I am talking about general purpose languages. The predominant front-end and back-end languages mentioned above are general purpose programming languages.

So, if you would like a single end-to-end language for web development. Here are your options:

Compile your favorite server-side language-to-JavaScript

Find an Application Server that supports JavaScript

Use a server-side framework that generates all the JavaScript

Below are a few examples from each of these categories.

[Update: 7/10/2012] : This post pre-dates nodejs and dart, both of which enable same-language development on client and server.

GWT: Google Web Toolkit

GWT compiles Java into JavaScript. Thus, you can use Java for the front-end and Java for the back-end. Think of JavaScript as the new byte-code. In both cases the Java part is really an illusion; at runtime the Java is gone and all that's left is JVM byte-code (server-side) or JavaScript (client-side). But once you are coding in Java on both sides, network (i.e. AJAX) programming becomes much easier; you can now send Java objects back and forth RPC-style.

Pyjamas

Pyjamas is similar to GWT except it compiles Python to JavaScript.

Other X-to-JavaScript Compilers

Java2Script

Ruby to JavaScript

Harmony Framework - PHP to JavaScript

ASP.NET and JScript

One can create ASP.NET pages using JavaScript. Thus, in principal, one can use JavaScript for both front-end and back-end development. The only problem is that JScript is a more modern version of JavaScript (more like ActionScript 3) thus client and server languages are not technically the same.

JSF AJAX

JSF (JavaServer Faces) when coupled with an AJAX JSF tag library like ICEFaces, allows one to create an entire AJAX application and not see a lick of JavaScript. Just as traditional server-side tags are expanded into HTML before being served to the browser, AJAX aware JSF tags are expanded to HTML + JavaScript. Thus you get most of the benefits of a rich JavaScript client, but you are only coding in one language: Java. The only problem with this is that, in reality, you are coding in all sorts of languages: JSP, JSF tags, EL (the Java Expression Language). Plus large chunks of the application ends up in JSF specific XML files (faces-config). This model is the least flexible of the solutions mentioned in this article.

Sun's Phobos

Phobos, like Jaxer, is a server-side JavaScript web application server. However, Phobos is based on the rhino JavaScript engine. Rhino itself is a pure Java application. This means it will be slower than C based JavaScript engines (like SpiderMonkey, TraceMonkey used in Jaxer). But it also means its very easy to make use of existing java code and libraries - a potentially huge benefit. Plus, Phobos takes the form of a standard Java WAR file. Meaning it can run on top of any Web Container that supports the Java Servlet 2.4 spec such as Tomcat, Jetty, IBM WebSphere, etc.

Jaxer

Jaxer is a server-side JavaScript application server. Technically speaking Jaxer takes the form of a web server plug-in. It currently runs on Apache 2.0 and Jetty (with plans to support IIS). It uses the SpiderMonkey JavaScript engine, the same one used by Firefox. They claim that "Jaxer performance is comparable to PHP and Rails". However, they will soon be switching to Firefox's newest JavaScript engine (TraceMonkey) which should prove much faster. One interesting point about Jaxer is that it's server-side programming model is essentially the same as the client-side programming model, namely DOM. Thus client and server not only use the same language, they also use the same API.

10Gen

10Gen (like Jaxer and Phobos) is a server-side, application server that supports JavaScript, Ruby and Python. There whole schtick is that the platform is "cloud-aware" from the get-go. In that since it's a bit like Google's app engine. You can use their platform as a "service" or you can run their software in your own cloud (i.e. on your own servers).

My Own Experience

I have dabbled with all of these technologies. But the ones I have the most experience with are GWT and JSF/ICEFaces. Presently, my favorite tool for web development is GWT. It doesn't have the most feature-rich widget library in the world. But that is because they focus their efforts on making the "core" as good as it can be, then leave some of the widgets to third party vendors (of which there are dozens). If you work with GWT you will become a better web developer. There is some serious "smarts" contained in GWT. And it will rub off on you. Things that took days in JSF take minutes in GWT (creating your own component, for example). GWT is a thin layer on top of DHTML. It doesn't try to hide anything and generally doesn't create a whole new abstraction layer. But I could go on all day about GWT, but that would be a subject for a different post. Here are a few links about the general philosophies behind GWT:

GWT Mission Statement
GWT Design Axioms