Are Serverside Web Frameworks Becoming Irrelevant?

It might be very tempting to just use a REST API and a JS client for your web application. With the _escaped_fragment_ technique, you can even get indexed by Google (I'm not sure whether the other search engines already do this, but Google still is good for 90% of my search referrals, so it's ok for me).

The architecture is very clean. And you get a full third-party API "for free" instead of having to bolt it on afterwards (and maybe missing some stuff that can only be done in the web client).

Not only that, by the statelessness of REST you get really good scalability: Each request is independent of each other request, so you should be able to just add frontend- and backend-servers as you see fit without having to worry about global state.

Still, after having done just that (build a web application that is nothing but a JS frontend to a REST API - quite like the new twitter) with http://tempalias.com (source is available), I can tell you that it's not all rainbows and unicorns to misuse that saying once more.

One thing is Sammy, the client-side framework I used. It's quite easy to get lost in one big heap of application that's very hard to maintain. That is totally my mistake though and with a bit of additional experience and some help of require.js or something, I could fix that.

The other thing is UI. People are still used to the browsers page-loading-paradigm. In that case, the browsers themselves provide status update during requests. With AJAX, you'll have to do your own loading indicators and every site does it differently and no site as fine-grained as browsers (Connected, Waiting for reply, Loading... etc).

While the granularity of notifications can be fixed (best is to leave it as a single notification, but respond really quickly), you still don't solve the problem that it looks different on every site. This is a general problem of pure-AJAX sites.

Newtwitter suffers from this. Lately it's quite slow for me and I'm constantly wondering whether some JS has crashed or whether it is just slow.

And finally, sometimes, you have to do really convoluted solutions for problems which could ever-so-easily be solved by just being able to send a few dynamically generated bytes.

Of course, you could cave in and chose the impure solution, but I didn't want to which caused me some headache in my case, like not having access to the hostname of the 'd bookmarklet runner script (https://github.com/pilif/tempalias/blob/master/public/bookma...) which I now have to pass in on bookmarklet invocation.

To be honest though, over time, we'll learn to cope with such issues (and browsers might get a bit better in notifying users about AJAX connections going on) and at that point the advantages could really get into play.

After tempalias which was a personal fun-project, we decided to reuse this rest-only architecture for a project my company is currently working on, fully prepared to deal with the issues outlined here because, really, we believe that the benefits might well outweigh the issues.

I realize that you don't want to maintain state in a REST api. It's not that it's painful to do something I'm use too (ie: session handling), it's just its painful implementing.

My point was that I totally agree with the notion of a REST-based service, but it's easier from an implementation perspective to have have web-heads for views (static files, session handling, etc) that interact with the application (REST) server.

Separating the domain from the UI is just common sense and good business practice. Having the two melded is probably the most common way for companies to get stuck using an old application. Their business logic (the real value) is stuck in a glob of UI outdated code (which no one cares about anymore).

I say this as a Smalltalk programmer of 10+ years experience. Unfortunately, it's often been the worst Smalltalk apps that have had the longest life. In those cases, it's just too horrible to migrate to a different environment, and the rate of change in the current application makes the opportunity cost of freezing ongoing development too painful. The result is often one or two failed Java projects seeking to replace the Smalltalk app, which continues to creak along beyond all expectations. Often, the apps with the good architectures got replaced quickly.

I think a lot of that could be fixed with automated translation to Groovy and some custom UI frameworks.

It's probably just a question of server-side frameworks being more mature at this point in time, and client-side logic being a more fertile ground for innovation due to longstanding cross-platform roadblocks. A client-server architecture is always a balancing act, and it's just teetering a bit towards the client side at the moment.

The future is being able to divide work arbitrarily between front-end and back-end depending on the particular needs of your application.

It's about moving the generation of HTML to the client. The concept of rendering the UI (using HTML) on the server was a step backward right from the beginning of the WWW. Servers are simply not needed to construct HTML.

I predict within a few years everyone will agree that all server-side HTML template languages (PHP, eRuby, JSP, Django etc) are obsolete. There will be a great normalization of server-side frameworks -- Ruby, PHP, Java, will essentially only be for shuffling data from your database to your client. The way it should have been all along.