Tightly Coupled Web Frameworks Are Reaching the End of the Road

The other day I read about how the choice/change of JavaScript frameworks in Rails has caused some controversy in the Rails community. In addition, I’ve been asked several times over the last few weeks if Bowler “integrates” with any particular JavaScript framework, and when I’ve responded with “any framework you like” I’ve been met with a slight stare of disbelief until I’ve elaborated on what I meant.

Tight Coupling & Obsolescence
To me the question of “does serverside web framework X integrate with JavaScript framework Y” is a question that should be entirely irrelevant. JavaScript (in this context) is a client-side technology.
A server-side web framework that needs to incur integration cost with a client-side technology has failed as far as I am concerned, yet this is exactly the model that 99% of web frameworks in the past 10-15 years have adopted.
The end result is that serverside web frameworks grow obsolete at an alarming rate, whereas the current version of HTTP (1.1) is still chugging along nicely even though it was only a minor upgrade from its predecessor. I put this down to the tight coupling most server-side web frameworks both have and endorse to client-side technologies.

There is absolutely no reason whatsoever for a server-side web framework to be wedded to a particular set of client-side technologies or frameworks - as far as I am concerned, this is a bad thing, as server-side and client-side become tightly coupled, fragile and any update cycle becomes dependent.

As long as a server-side framework can emit something that is useful, like, oh say, JSON, for client-side technologies like JavaScript to consume, why should the server-side need to know anything about the client-side JavaScript or vice versa? Besides, keeping this separation of concerns in place means that you can use best of breed technologies on both sides and you can do so while incurring absolutely no framework integration cost whatsoever.

As far as I’m concerned, if your server-side framework needs to know the details of what JavaScript or CSS framework you are using, how it’s being used and what JavaScript calls you are making, it has a level of tight coupling that is just asking for trouble.

HTTP & Resources to the Rescue
The HTTP specification is actually a mature, very well thought out set of ideas. Unfortunately a whole generation of web developers have largely not learned it, mostly because the support through things like the Java Servlet specification has been clunky and horrible to work with, and the amount of boilerplate code to do even the most basic thing has been massive, so relying on “magic” frameworks that hide it all away has been the approach most have taken.

However, clunky language & language API support is NOT the same thing as the underlying protocol being bad: with the right support I contend that it should be easier, not harder to write amazing webapps by embracing HTTP rather than hiding it.

Instead of working with fragile, tightly coupled frameworks that reach obsolescence the second a new technology arrives, we should embrace HTTP and the stability and good practices that comes with it.
If HTTP and HTTP Resources are our contract we can in fact get a lot closer to a lot of very desirable architectural traits:

• Separation of UI from backend: The server-side is concerned with rendering resources, client-side technologies are concerned with snazzy UI features and pretty formatting of said resources.
• Best of breed technologies with zero integration cost: We can use best of breed technologies on both sides, use the latest, greatest JS framework without having to wait for someone to integrate it with your server-side framework.
• Managed evolution of apps, instead of risky revolution: serverside and client-side can truly evolve independently. Many webapps today are rewritten from scratch when they are renewed because of the tight coupling in most modern server-side web frameworks. With a more well-defined contract (HTTP & HTTP Resources, duh), you can rewrite a front-end while keeping the same server back-end, or vice versa.
• Better testability: goes without saying, with less coupling comes better testability.
• Less duplication of effort: today, writing a webapp and writing a REST API to support the same functionality for third party clients is often a complete duplication of effort in that two similar, but not identical applications are written to do largely the same thing. Does it really need to be that way? If we are more concerned with resources and less concerned with output, I’d say the answer is NO.

Obviously, a server-side framework can’t entirely get away from rendering JSON, HTML or XML, but my point is that it should be as neutral as possible to the format of output and be concerned with resources rather than the exact content-type, let alone stylesheets and JavaScript. A lot of what we have traditionally rendered on the server-side can be pushed out almost entirely to browser-resident JS clients.

I contend that a lot of the implicit assumptions around what server-side web frameworks should be concerned with are just plain wrong. By integrating too tightly vertically with what are effectively (browser) client-side, browser-resident technologies, we have been shooting ourselves in the foot, causing ourselves development pains, poor architectures, high development cost and a constant cycle of obsolecense in web frameworks.

If we instead choose the path of embracing and respecting HTTP and HTTP Resources with the right framework support, while combining with best-of-breed client-side frameworks I’m sure we would make life both a lot simpler and a lot more comfortable and enjoyable for ourselves.

And yeah, I’ve put my money where my mouth is on this with Bowler.