Tightly Coupled Web Frameworks Are Reaching the End of the Road
Tight Coupling & Obsolescence
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.
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.
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.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)