Web development since its inception has gone a long way. From the very first dynamic websites which were done using C or LISP programs to interface with web servers via CGI to something like Facebook, Twitter or Basecamp, it’s a very long way indeed.
The first programming language that saw major adoption as a language / an environment for web development was Perl. Although Perl nowadays is notorious for it’s quirky and (supposedly) ‘write-only’ code, its dynamic nature and language features that made ‘easy things easy and hard things possible’ was a huge improvement over anything that existed before. Perl is still one of the most widely used scripting languages, so there is definitely something to it, although hardly anyone does consider using Perl when starting a new web project nowadays.
Then came PHP, which again was a huge improvement over Perl – or at least the way Perl was used to that point. PHP allowed you to create much more maintainable code for web applications. Wait a minute, PHP and maintainable? Yes, consider the difference between reading and writing something like
print "<img src=\"$some_var\" alt=\"$another_var\" />\n";
in Perl and something like
<img src="<?=$some_var?>" alt="<?=$another_var?>" />
in PHP. The latter is both much easier on the eyes and written more swiftly. The huge advantage of PHP was that you could mix HTML code with PHP commands without having to resort to print (or echo for that matter) calls for rendering HTML tags.
This allowed non-programmers to add simple dynamic content to their website – which somehow of course is both a blessing and a curse 😉 . However, it opened up dynamic Internet content creation for more than just the IT-savvy crowd.
Oh, yes and then since the mid 9ties there was Java. Starting with the now completely obsolete applets Java promised to bring dynamic content to the browser that reacted sort of like applications on your desktop.
While applets were a nice tech gimmick mostly used for displaying menu roll-overs (apart from some rare cases where they performed useful tasks as in early online banking software), Java was a lot more useful as a server side language serving dynamic web content. However, while Java allowed to develop and maintain applications that went beyond the complexity you could usually handle with PHP or Perl, there were shortcomings, too.
Java didn’t feel as dynamic (nowadays you’d say ‘agile’) as scripting languages because you’d have to go through a cumbersome ‘edit – compile – (hopefully) test – edit again’ cycle while with your usual scripting language you would do changes right on the live system and they’d appear right away (which of course is very bad practice but more frequently than not it was done anyway).
Even worse, with things like Java Enterprise Edition many developers – or architects, as they soon began to call themselves – boasted to be able to deliver enterprise-class, highly scalable applications, which more often than not was just a euphemism for ‘So damn complex I hardly understand it myself but it allows me to draw lots of awe-inspiring colourful diagrams and charge much higher rates without doing a single bit of actual coding.’.
Then, back in mid-2004, along came a new web development framework built upon a – at that point – rather esoteric scripting language that was bound to take the web development world by storm: Ruby on Rails.
Rails kind of united the best from both Java and the previous scripting environments. While it took things up a notch by allowing you to develop under a rigorous MVC environment it also did away with the complexity and initial setup effort that was harrowing Java developers.
To me – and I’d venture to say to many others as well – it was like some kind of epiphany like ‘I always knew there was something wrong with how A or B is done and finally someone got it right.’
In 2006 this spirit was ported to the Java platform with the advent of Grails, which as you can tell by its name feels a lot like Rails, with some new concepts of its own. Grails is built upon Groovy, a scripting language for the Java Virtual Machine, that brings all the cool scripting language features like comprehensible, succinct code, closures and dynamic typing to the Java world.
As you can probably tell from previous posts Grails currently is my favourite web development framework as it sports most of the advantages of Rails, combined with some pretty nifty features of its own and the advantages of the JVM, which of course are performance, scalability and a vast variety of robust libraries for all sorts of purposes.
So, the big question is: What will web app development look like in let’s say 5 years from now? This seems like an awful lot of time considering that Rails has already been here for 5 years.
My guess for the not-so-distant future is that in the Java world we will see Groovy being much more widely used even in more traditional frameworks such as Struts, Seam or Wicket. It allows you to be much more productive without having to abandon Java. It also is rather likely to feel more natural to most Java developers than other alternative languages for the JVM like Scala, JRuby or Clojure.
However, that’s for the Java world and that’s actually a rather incremental change. My feeling is that it’s about time for the next big step in web app development. With AJAX and similar technologies having dissolved and melded both the traditional page and desktop app paradigms it seems that classical MVC-oriented frameworks are no longer completely appropriate.
Visual user interface designers like Atlas sure are promising but still have a long way to go. Furthermore, good developers love to write actual code so mere visual development might not be a general approach.
I also like this idea of development on mobile devices, which due to the limits of handheld devices would to some degree also involve visual development processes.
What is quite certain though is that the choice of frameworks and languages will become less important. It’s the APIs and web services that you use and how you combine them that will make all the difference.
Maybe, we’ll see something like a sophisticated (well, even more, that is) version of Yahoo Pipes combined with something like Atlas that will allow you to visually design awesome web user interfaces and combine all sorts of services and APIs to something entirely new while not having to consider the actual design of the underlying model anymore.
Ideally, this development engine would take care of source code management all by itself and would allow you to design tests using a visual interface alongside with an explicit domain-specific language as well.
This would certainly require an even higher level of abstraction and services that provide the building blocks like user / permission management and pre-designed models for the most common use cases.
Considering current plugin systems like the ones sported by Grails or Rails, I envision something like a public plugin system that can be loosely integrated into an application no matter which framework that application is built in.
So, enough with the rant for now, I probably shall elaborate on one or two of them soon. For now I’d like to wish you a happy and exciting new year 2010.
The MetaSieve Blog 