While Rails took the evolutionary path, other languages could be the seeds of revolution. I’m sure many of us are looking forward to a streamlined Web application development process.
Here are three heroes that could have a shot in the next round:
ECMAScript 4
Also known as: JavaScript, one of the most dreaded, abused, and wide-spread languages. It has nothing to do with Java. And contrary to what some think, JavaScript is one of the most feature-rich languages.
Just to be clear, ECMAScript is the specification, JavaScript is an implementation, a dialect so to speak. DOM trees, for example, are part of JavaScript as used by Web browsers, not part of ECMA specifications.
ECMAScript 4 (ES4 for short) is backed strongly by Adobe and Mozilla, since both need ES4 as common base language from which they would derive ActionScript and JavaScript. Tamarin is the current implementation, and it will eventually be included in Mozilla’s Firefox.
We’re not used to JavaScript outside browsers, probably because its history is tied to Netscape who used to influence Web standards. But with a virtual machine for ES4, things could change. We will be able to use one language to develop both the server and client side.
Server-side JavaScript isn’t a new idea, but it never took off the way PHP, or Rails, did. Unfortunately, so far there’s no JavaScript framework that transparently ties both ends of a Web application.
Lua
It might seem counter-intuitive, since Lua is gamers’ favorite toy. But surprisingly, Lua is one of the fastest scripting languages around, it’s simple to learn, it can be compiled, and it’s embeddable.
Now if you picture your server stack as an RPG game engine, and your applications as pluggable “scenarios”, then Lua starts to make some sense. Web applications are mostly front-ends for data stores, these stores could be implemented in C, and extended using Lua.
As opposed to Perl, Python and Ruby, Lua’s loves being embedded. This makes it very easy to build bridges between Lua and other languages, but makes it harder to extended with external libraries.
The Kepler Project is currently the only Web development framework for Lua, but it can already talk SOAP, XML-RPC, LDAP and SQL, and has its own Web server.
Haskell
Functional languages in general suffer the stigma of being too academic, with no real-world applications. Haskell is one of those languages that you learn because you have to, or because your instructor twisted your arm and forced you into obedience.
Haskell is one of the fairly known functional languages. To learn it, you need to throw away all you know about C, Java, or PHP, and start anew. And that’s exactly why languages like Haskell have a shot in becoming the next best thing.
Web applications, like I said before, are front-ends to data stores, with attached behaviors. These stores take action depending on certain conditions (e.g. user permissions). With a Haskell-based framework, all you need to do is define these states and conditions, and let the rest be taken care of.
Of course I’m over-simplifying here, but the gist of it is that functional languages don’t have a starting point like procedural ones, there’s no main() function. A functional program decides what to run depending on its input, this should sound familiar to Web developers.
The problem with Haskell is the same problem with Lisp: Nobody wants to use it. It’s very different than what we’re used to, it looks like it belongs to the ’80s, and there’s barely any support for it.
Comments (2)
Nice write up. I’d like to point out that ECMAScript has started leaving the web. Widget, Gadgets, call them as you want are all JS based. Not to mention Adobe Apollo (client side flash based apps). ActionScript after an implementation of ECMA.
Absolutely. There are many ECMAScript-based frameworks coming together nicely, and they’re making use of advanced language features.
ECMAScript is just disguised as C/Java, in reality it can be much more powerful and flexible.