Monday, September 26th, 2005

War of the Web: Revenge of the Dynamics

Category: Editorial

>As I was watching “24 hour party people” on DVD, I heard the main character talk about the ebbs and flows of the music business. He is talking about the scene in Manchester at the end of the 70′s, and into the eighties. Moving from Joy Division to Happy Mondays and New Order.

I think that we are in a new chapter for the web, and as is often the case, the wheel of time is repeating history for us.

There are a few dimensions to the current war though. They are on the client side (DHTML Ajax vs. simple HTML vs. Flash/PDF vs. XAML vs. XUL) and on the server side (Rails vs. Java vs. PHP vs. .NET).

Let’s start at the beginning.

Perl: Birth of CGI

Do you remember how the web changed as it moved from static HTML connected content to dynamic websites? That came about due to CGI, and how our nice web server would now fork off our programs to generate the HTML.

I remember my first CGI programs were written in C, and Scheme. I quickly moved on though, and found the beauty, and craziness of Perl.

I spent quite some time with Perl, trying to get by without writing too much NSAPI and ISAPI code (oops, I guess that core dump hurts the entire server?).

I really enjoyed the community at that time. #perl was interesting (some of the time), and CPAN became the holy grail. As soon as you thought you needed something, someone had kindly put that functionality up into CPAN. I even have some of my own modules hanging out there, and helped with others.

Over a short time period, we had developed some fairly rich web modules. We didn’t have to work with $ENV{‘SOME_CGI_ENVIRONMENT’}, or STDIN or the like. Our framework abstracted all of that for us, and gave us a simple model. We lauched at the folks who generated html via methods such as b("whee") and we stuck close to HTML itself, allowing our design teams to simply open the html files and see what their stuff looked like. We even had the notion of components, and special tags that you could create. <$mytag name=”…” /> was nice because the name of the tag was the key for the framework to dynamically discover that functionality. No config files, or interfaces, in the strict sense. The coupling was based on a name.

In retrospect, life was pretty simple for web development, a lot simpler than some of the frameworks we have today!

But, we moved from Perl. CGI was not the nicest for our high load servers. It was crazy to think that we would fork a process for every little request that came in, and that a Perl interpreter would start up, load the program, do the work and then die off.

We naturally moved to solutions such as mod_perl, and that helped. It was so new though that it was buggy and we had a lot of problems. Some of the problems had nothing to do with mod_perl itself, but due to laziness and side-effects.

When you work in an environment like CGI you can be a very bad man indeed. If you don’t close something correctly, or don’t play totally nice with resources, baaaah who cares? The server is going to kill me in 2 seconds anyway, so I will get my job done and have him kill me. In mod_perl world though, these programs start to live longer, and they get fat and oily.

Java: No more stinking processes!

Remember the beginning of Java (Oak!). We were building applets, and feeling the pain very early on.

Servlets were the big thing though. We ported our Perl based framework over, and were able to see significant performance improvements at the time. Some of the team loved the change, others hated the verboseness and static typing.

The nice threading model that Java gave us was huge though, even with the poor JVMs back then (Microsofts was by far the best remember!).

This is when we moved from the world of Perl to having Java start to take over. That isn’t to say that there wasn’t competition. In the waters we saw the lurkers of ColdFusion, ASP, and the beginning of the PHP revolution. Java came up with JSP to compete with these tag based approaches, but it was the advent of the rich MVC style frameworks that really spurred everyone on.

In my opinion Java is still in the hot-seat, especially in the corporate world.

Preparing for the server war

The troops are being gathered. Strategies are being worked out. We are currently getting ready for a new battle on the server side.

What’s happening?

  • Ruby on Rails: Whatever you think about Rails, it has lit a fire under the server side web development community. Many have jumped on the bandwagon, claiming real productivity improvements. Some of the PHP converts enjoy a richer language, which is still nice and dynamic, with a framework that enforces clean MVC techniques. Some of the Java community are frankly a little bored of Java, and enjoy the new challenge. They also love the freedom of the language, and the fact that they now have just ONE stack to worry about. Will the Rails buzz keep growing? Will it be the Perl of Web 2.0?
  • Java: Java isn’t going down without a fight. Some argue that the problem with web development in Java is that it has been too complicated and heavy for much usage. I have personally called for the need of a common stack for Java, and people have stepped up to the plate. On one side we have companies that will certify a set of technologies (JavaServer Faces + Spring + Hibernate). Then we get frameworks taking on simplicity themselves (WebWork now embedding Spring). Finally we have initiatives like JBoss Seam, which is trying to combine the component models of JavaServer Faces and the backend. Seam aims to give you the power of the Java tier, but also giving you a simple productive environment. So, Java frameworks are rising to the challenge of Rails, and we will soon see how much of the success of Rails is Ruby, and how much can be duplicated in other platforms.
  • PHP: We can’t discount PHP. A lot of “serious engineers” (read: anyone who isn’t a PHP developer thinks they are serious) poo poo the PHP world. Yet, by all accounts, there is a LOT of PHP development going on out there. PHP has the advantage of being something written JUST for the web. Take a look at how WordPress came along (PHP based blogging software) and in no time at all there were thousands and thousands of plugins that you could simply drop into your WordPress system. Literally, you drop in a file and you are done. There are numerous PHP frameworks that are aiming to mimic, and compete with Rails, so we can’t forget about these guys. The question with the PHP community is: will it grow more into the enterprise, or will it be for script-kiddies.

    NOTE: Some people have concluded that this is anti-PHP, or making fun of PHP. This is NOT the case. It is making fun of the people that make fun of PHP :) I know that my british sarcasm is hard to see in print. We have worked on PHP projects, and like how pragmatic the platform is. PHP was made for the web, and it shows.

  • .NET: Never discount Microsoft. ASP.NET keeps getting more productive, and it is hard to compete with their end to end story, which includes fantastic tooling in their latest Visual Studio. And, we get Avalon and XAML along for the ride, as well as the futures of C# 3.0 which takes a lot of ideas from the dynamic languages and puts them into a static structure (such as: var foo = new Bar(); and the relational/xml integration)

It is going to be an interesting couple of years, as all of these platforms mature, and take eachother on, trying to get mindshare!

Client Side: JavaScript is cool again

But what about Ajax? The battle for the client side is going to be just as hot as on the server. And they will even intertwine with eachother.

Firstly we have the big debate of how far Ajax is going to go. Is it a one hit wonder? or will it become a standard part of our toolbox and even just be called dhtml again?

As an Ajaxian, I obviously have my thoughts on this matter. But there is a lot of competition inside and outside of Ajax:

  • Flash/PDF: Adobe/Macromedia are a definitely force to be reckoned with. Flash is almost ubiquitous, and PDF is used everywhere. Now the companies are combined, what do they have in store for us?
  • Avalon/WPF/E/XAML: Microsoft announced WPF/E, which is a subset of XAML that will be ported on various platforms and available in many browsers. This means that you can build your rich application in the .NET set of tools, and have it run in Safari on Mac OSX. Impressive. When are we actually going to see this in a form that we can deploy to the real world?
  • HTML: How much do we want to work in the open (ish) world of HTML. A large group of developers do not want to jump into any monopoly, and will therefore want to stick to a more open environment. But, another set will just want to use the best tool to add business value. What will the split be?

JavaScript will play a big role in this war. JavaScript 2.0 offers big improvements, that many people will cheer for. Also, the same people who poo-poo’d JavaScript in the past have come to realise that it really is a great language. It may not be what they are used too (it uses prototype-based OO vs. class-based OO), but it is powerful and robust. There are some features missing, and a big question around libraries. JSAN and others are trying to build a CPAN for JavaScript. We also worry about the black box of the JavaScript VM in the browsers, and cross-browser bugs are truly real painful. Fortunately, frameworks like Dojo and Prototype are trying to help us out on that front.

We are also seeing that we need to take JavaScript from the former:

“That is just crappy code that the web dood View-Source’s and pastes into the web pages”

to the future:

“JavaScript also needs to be engineered, and is a first class citizen”

Thus we finally see more unit testing of JavaScript code, and professional ways of creating modules and namespaces for our code. We also see great advantages with features like E4X where XML becomes a native type.

JavaScripts increased popularity, thanks to Ajax (and Flash/ActionScript) has also drawn it into the server side. Mozilla Rhino gives you a quality Java-based approach, so why not use a cool dynamic scripting language for certain tasks on the server side? You don’t have to use JavaScript for everything, but it has its place, and that place is growing.

The Battles Join

This is where the battles are joining. We have JavaScript bleeding across the layers, and we have the need for server-side frameworks to support the new Web. It isn’t enough to generate simple HTML and be done with it.

Today’s frameworks need to be able to help us build Ajaxian components, and help us write this applications quickly and cleanly.

There are various directions that frameworks are going in here.

  • JavaScript Code Gen: Why not give you a simple macro that splits out the ugly JavaScript that you would have to write?
  • JavaScript Framework Code Gen: Spitting out low-level JavaScript is too much work. Many frameworks are writing on top of a higher level JavaScript framework like Dojo or Prototype. Now the code-gen is less, and you get the benefits of the rich functionality, browser compatibility, and visual effects available from these frameworks.
  • Tools and Widgets: Should developers even care if a piece of their page is Ajax or not? Some frameworks give you drag and drop editors that let you setup widgets or components. Some happen to be ajaxian. Some are not. Who cares?
  • Markup based: A lot of frameworks are giving us markup based solutions. That is one of the strengths of Microsoft Atlas, not the fact that they added support for $() etc. Are we going to want to build using markup or via programatic APIs?

Conclusion

It is hard to predict the winners of the new battles, and the losers will not die off totally, but it is an exciting time to be watching web development. The dynamic languages of Ruby, JavaScript, and PHP are making a big run, and people are realising that they aren’t just cheesy scripting languages that can’t be used. It’s time to take them serious.

We are going to start really working out what makes sense for usability on the web with rich interfaces. And, at the same time we will get simpler and simpler backend tools to make the generation of rich web experiences easier and easier.

I am looking forward to seeing this battle!

ps. I know that I haven’t listed every possible technology, and I apologise for not mentioning your technology. This is due to not being able to list everything that is possible.

Related Content:

Posted by Dion Almaer at 12:23 am
15 Comments

+++--
3.9 rating from 12 votes

15 Comments »

Comments feed

Dion,

Thanks for the insight into the looming battles. I was especially interested in your analysis of the various directions of JavaScript frameworks. There is a fifth alternative which is about to hit the market. It is called JavaScript Synthesis Technology (‘JST’) and is developed by a company named Morfik. This technology will be launched as part of the Web 2.0 Conference next week. See http://www.web2con.com

In a nutshell, Morfik allows the programmers to implement the business logic of their application in a high-level object oriented language of their choice. Morfik compiles this code into a JavaScript AJAX engine. The process is a true compilation and avoids boilerplates or code snippet libraries. The source code is put through a parser which includes a tokenizer and syntax analyser. The parser output is then passed to a semantic map builder which crates a detailed semantic map that conveys the entire ?meaning? of the application. This is a technique in widespread use by CAD systems. Finally a synthesiser uses this map to create JavaScript code which is semantically identical to the original source and conveys the same ?meaning?.

Since the output is neither an executable in machine-code nor a one to one translation of source code nor a collection of predefined code snippets, this Morfik process is referred to as JavaScript Synthesis Technology.

Siamack Yousofi
Chief Technology Officer
http://www.morfik.com

Comment by Siamack Yousofi — September 25, 2005

You don’t include XUL but talk about vaporware XAML?

Riiiight
Another MS sponsored article

Comment by biased — September 25, 2005

biased -

I find it quite funny that you think this is MS sponsored, because it doesn’t mention XUL????

I apologise for not going into detail on XUL, but there are only SO many technologies that we could cover in this article.

XUL is great technology, and there are other great technologies that we couldn’t mention here. This is a high level article :)

Cheers,

Dion

Comment by Dion Almaer — September 25, 2005

well if you follow the “worse is better” mindset, php will continue to be pervasive. it is a junk language, but it is very easy to configure and conceptually simpler than the perl approach (whereby you must layer ax or mason or apache::asp etc on top of mod_perl) or the java approach which seems to change every week (faces? hibernate? struts?).

ruby on rails needs to be able to scale to big high traffic sites before it will become mainstream, and i don’t mean bitplayers like backpack, think more like ebay, amazon, yahoo, google, etc: sites that get serious traffic. that said, i am a huge ruby fan, the language seems to have supplanted perl as the cool hackers language, but it has performance issues.

python could also be resurgent if it is intergrated into mozilla as certain project pages seem to indicate, amking it an alternative to javascript, a language that simply is not acceptable as the future of application development.

what we need in the browser is some sort of ABI so i can do perl,python,ruby or javascript coding, all of which gets compiled at page load time into an object file the browser can execute. why should dynamic web pages with ajax like behavior be limited to one language? it makes no sense, particularly if that language is a weak toy like javascript. its good to learn javascript now but remember language diversity always comes back – look at sql!

Comment by grumpY! — September 25, 2005

Excellent article. I liked reading it. However there’s just one thing I don’t really understand and that’s the almost humiliating remark on PHP and PHP developers:

“We can’t discount PHP. A lot of “serious engineers” (read: anyone who isn’t a PHP developer thinks they are serious) poo poo the PHP world.”

I guess I’m offended by that line. I for one am a PHP developer and I think I’m serious. It’s not the language itself but the scriptkiddies that might give PHP a bad name. However, one can do pretty serious AND scalable stuff in PHP as long as it’s done right. I even wrote a book about the serious type of PHP development.

Java may still be in the corporate ‘hot seat’ but from a developer point of view I really think this is thanks to excellent marketing by Java based companies. I’ve yet to see the first large scale Java implementation that performs well and doesn’t suffer from deadlines being crossed big time, going over the budget by a lot and engineers close to being burned-out. I guess I’m amazed by the fact that the corporate world still buys this garbage. As a language it’s exellent but implementation is your worst nightmare.

Ruby seems like the exciting new kid on the block indeed. I agree wholeheartedly on that one. However we’ll still have to see what will be left of it after ‘the hype’.

All in all a great write, except for that line about PHP… :P

Comment by Marco — September 26, 2005

JavaScript 2.0? Sorry, but JS2.0 is a dead horse. JScript.NET’s pseudo-implementation follows no known spec, and Macromedia has taken some interesting bits of JS2.0 and then gone and f’d them all up, as they are want to do with perfectly capable interpreted languages.

I see a future for JS 1.6 in mainline browsers and embedding situations. Things like e4x, Rhino’s continuations, and some of the new spidermonkey functional programming primitives point to a direction where where it’s not necessary to add lots of new syntax to get the kinds of capabilities that JS2.0 was supposed to provide.

JS2.0 is dead. Long live JS.

Regards

Comment by Alex Russell — September 26, 2005

Hey guys:

I don’t think that JS will be taken seriously anytime soon. That said, I think that AJAX and it’s increased usage will speed that up quite a bit.
I’ve worked in too many shops where you have client/server developers put onto web projects. As you know, going from a stateful environment to a stateless environment is a difficult transition.
While the .NET stuff is very very good – it allows developers who’ve never done any kind of web work to dive in and create all sorts of pages that abuse the hell out of postback. What you end up with is a page that wants to act as a client /server thing but fails…miserably.

I’m really hoping that AJAX technology becomes the technology of choice to get rid of the unnecessary chatiness that products like .NET are introducing and finally make the stateless environment issue go away. At least, by making it appear to be stateful!

If that happens, then yeah Javascript will have to taken a lot more seriously. That means testing, automation, functional specs, etc.

I’m hoping to make it to the December 8th conference. My boss hasn’t responded yet about whether I can go or not, but my fingers are crossed!

Comment by John K — September 26, 2005

Marco -

I am not trying to make fun of PHP developers there. The opposite. I am making fun of the OTHER developers who consider themselves BETTER than PHP developers for no actual reason.

I apologise for that not being obvious. My english sarcasm is hard to capture in text sometimes ;)

Dion

Comment by Dion Almaer — September 26, 2005

Hi Dion,

That’s ok, I guess it’s a tad ambiguous maybe then :)

I agree that PHP has it’s issues though!

P.S: Love this blog! There was no need to repost on my site because I read everything on this site ;)

Comment by Marco — September 26, 2005

I think some of WHAT-WG (http://www.whatwg.org/) specs have real potential to be an important part of the future of the web, as it offers a good path forward from the current state of affairs, building upon strengths instead of just working around perceived weaknesses. More than Javascript 2.0, which I don’t think is a realistic proposal.

WHAT-WG’s specs take a lot of what uses Javascript now and turns it into declarative HTML, with higher-level Javascript hooks (e.g., a validate event instead of just an onsubmit event). It doesn’t invalidate Javascript at all, but just gives us a higher-level way to handle it.

In actual implementation, it will have to be implemented in Javascript itself (to be backward compatible, which is a primary goal). However, I think it has more weight than the current Javascript frameworks, in that it is limited and well defined. I hope current frameworks use it as an opportunity to simplify themselves, rather than seeing it as a competitor.

Comment by Ian Bicking — September 26, 2005

Ian -

I am a huge fan of what the WHAT-WG is doing. I really hope that the IE team gets totally onboard and we move forward on all fronts.

Cheers,

Dion

Comment by Dion Almaer — September 26, 2005

The fact is that PHP is in version 5 right now and there isn`t too many servers allowing this version. The new features on OOP are great, and i think that this can make PHP better than other options. Besides, i hanven’t seen faster sites than sites developed with PHP.

Comment by Juan Luis — September 29, 2005

It’s not a comparison between PHP developers and others; the point is that dynamic web has disadvantages related with accessibility, functionality, search engines, and others. From my point of view, PHP is the least dynamic language resulting in such issues in comparing to others.

Comment by Mag — April 29, 2006

PHP is the most distributed programming language, but for some things there are languages, which are better…

Comment by Plasma — October 22, 2006

Great and excellent article t’s realy helpful. Thanks again.

Comment by Shop Optimierung — February 20, 2007

Leave a comment

You must be logged in to post a comment.