Wednesday, November 16th, 2005

Is Ajax gonna kill the web frameworks?

Category: Editorial

James Strachan has written some flame bait with Is Ajax gonna kill the web frameworks? :)

His contention is that:

The Java eco system has zillions of web frameworks from JSF, Tapestry, Struts, WebWork, Spring WebFlow to things like JSP/JSTL/Velocity etc. There’s probably a new web framework born every day in Java some place.

However if the world really does go Ajax or some kinda client technology very Ajax like – will that cause these traditional HTML/HTTP web frameworks to become legacy?

Web frameworks spend most of their time doing things like, dealing with HTTP and HTML, maintaining client side state on the server – handing intermediate form submissions & validation, templating/rendering issues and binding business objects to HTML form controls etc.

These days Ajax has template engines, XPath/XSLT engines, SOAP stacks, XForms implementations and so forth all done on the client side. You can do clever things like hide the JavaScript from your HTML page and use CSS to bind the JavaScript to the markup.

So is the web application of the future going to be static HTML & JavaScript, served up by Apache with Ajax interacting with a bunch of XML based web services (maybe using SOAP, maybe just REST etc)? If so, do we really need a web framework thats focussed on HTTP and HTML, or are we just gonna end up developing a bunch of XML based web services and letting Ajax do all the templating, editing and viewing?

I definitely see how more code is going to be running on the client with Ajax, and you even get into an interesting paradigm of MVC on the client talking to MVC on the server.

We still need something on the server though, and depending on the app, the bulk of the work could be on the server side still, so we still need frameworks there to deal with it.

The big question is who will win out of:

  • Loose Coupling: I develop my client side in one world, and just talk to web services that are developed by the server team
  • Tight Coupling: I use a tool that lets me build applications, and it generates the bindings between the ajax client and server piece

What do you think?

Posted by Dion Almaer at 4:49 pm

3 rating from 5 votes


Comments feed

I’ll post my same thoughts here, too:
I don’t see them replacing web frameworks, because they work hand-in-hand. Ajax doesn’t do much good in a larger project if it doesn’t follow MVC principles that the web framework provides in order to give it some sort of structure. This is especially true because of how sloppy Ajax code is. Rails and Scriptaculous are a match made in heaven.

Comment by PJ Hyett — November 16, 2005

Not all AJAX code is sloppy. Dojo Toolkit and MochiKit are very clean and rigorously tested code.

Comment by Bob Ippolito — November 16, 2005

Our server-side web frameworks create the fertile ground from which AJAX has sprung. This client-side scripting is icing on our universally readable, addressable & accessible pages of HTML/CSS.

Adding this kind of client::server coupling makes any application more complex, which is not usually a Good Thing. Right?

Will apps that require ECMAScript to run ever reach as many people or be fundamentally more useful or faster?

Comment by Mars — November 16, 2005

People are constantly looking for the next killer app. And as soon as some geek learns about a new techy tool they think they’ve made it (I’ve been there). Time after time it is always going on. C type dev’s are bashing VB dev’s and PHP scripters are bashing ASP(& .NET) scripters. Java dev’s are no diff. I’ve only recently become a Java developer. Before that I earned my bread with PHP, ASP, and ASP.NET(c#). But a better job came along and I adapted to the opportunity. AJAX is great, I wish I had been working on that type of functionality a year ago. But AJAX is just another tool, without some server-side service or app it is no more than plain old DHTML, but with a good backend it becomes a tool that makes a web app run more like a desktop app, and that is great. I can’t deny that Java frameworks are born like rabbits, but for the most part Java works for business (I know there is a current fad going against this, but that is the nature of the beast). AJAX, in my small and worthless opinion, is not a killer framework, just another useful tool that will be integrated with the bigger more mature frameworks for now, but every dog has his day (COBOL for example).

Comment by Les M — November 16, 2005

There will probably be market for both types of coupling that you describe above, but I believe the loose coupling model is still being developed that leverages the web most effectively.

The client may be developed separate from the data services, but that does not mean the client application won’t be streamed to the user as HTML/CSS/JavaScript. There are very powerful motivations for a browser-based client, like natural upgrades through cache control, and wide distribution/accessibility.

Even though the UI can be delivered via web server, it should be possible to build the UI so that it could be served from local disk, and not require server processing power to generate the UI (besides the power to distribute the files via a web server). And even in this UI approach, there are needs for frameworks that help the developer construct the UI, help reuse components and allow the developer to use shorthand to produce quicker.

Comment by James — November 16, 2005

I don’t see Ajax replacing web framework…
they will start to live together, because Ajax is good for web applications that needs to be winform-alike, but there are a lot of situations that just need to display data.

Imagine this blog: I just enter the ajaxian site, I read the posts, eventually I post a comment.
I cannot imagine it being realized as just one HTML page that reads the posts via Ajax and accept comments via ajax: how can you get the contents indexed this way?

And also, web browser are not designed to host complex js applications: they are designed to load a page, make some js tricks on it, send data to the server, unload the page. If you make a lot of interaction just with JS the memory occupation tends to increase.

And last but not least: I develop with ASP.NET, I’ve Visual Studio, I’ve an IDE that helps me do a lot of things and manages all databinding to forms in an easy manner. With Ajax I’ve to do it myself, loose all the post-back handling that the ASP.NET framework does for me: we don’t have to speak/think just as the geek we are, we also have to make our PM side express: with an IDE you have a shorter time to market for the development of complex applications
my 2 cents


Comment by Simone — November 17, 2005

Why would you use MVC on the server side if the Ajax side is doing MVC? Surely the server side is just a bunch of web services – hence my point that there’s no need for a server side web framework; just a bunch of web services will do the job fine – Ajax can do the rest.

Irrespective of the server side implementation detail – you need to bind the XML in Ajax land to the view; so an Ajax binding framework would seem like a good idea. However I don’t see why this can’t just be dependent on some XML format (XSD/WSDL maybe) – I see no real reason to tie it more tightly with how the server side actually works.

Comment by James Strachan — November 17, 2005

Agree that Web frameworks will not be the same. However, the consequences will go two directions, IMO.
One, as you suggested, is to bring a strong client that acts as a conductor to orchestrate available Web/RSS services.
The other is a bit ironic: bring back the event-driven model we used for years in desktop applications. In this model, application developers know nothing about Ajax or JavaScript. They just represent Web applications in ready-to-use components and manipulate them when user triggers some events. All are done at the server. Synchronization and communication between browsers and servers shall be done by the server; totally transparent to developers. The advantage, in additions to rich user interfaces, is easy-to-use.
That is the reason we found the ZK project. ZK is an event-driven, XUL-based, AJAX-embedded, all Java framework to enable rich user interfaces for Web applications. If you are interested, you might take a look at
Live demo is at

Comment by Tom Yeh — November 17, 2005

I agree with James Strachan completely about the long term trends. Loosely coupled data-oriented server-based APIs are just going to be the easiest, most generic, and useful way of developing things as the client gets richer. It’s easier and cleaner to code this way.

Interesting how hard it is to convince people that client state in the client and server data on the server is a clean model. But things will trend that way in the end, I think. Water flows downhill.

Comment by Tom — November 17, 2005


Ruby on Rails is an example of a beautiful framework for creating & providing web services to AJAX clients and other loosely coupled server-side systems (e.g. B2B transactions).

So how will client-side kill server-side?

It’s a mutual relationship.

In my situation, I think that Rails will evolve & grow parallel to the client-side technologies.

p.s. The CAPTCHA is a pain. It’s taken me six tries to finally post.

Comment by Mars — November 17, 2005


I believe Ajax will be integrate into existing Framework. A good example is

In general what a we trying to do? Save time and money… Having an ajax layer added over a server side framework, for me, seems to be the way to go.

Comment by Niooi — November 23, 2005

Leave a comment

You must be logged in to post a comment.