What Decoupled IS Good For

Posted on 13 Jul 2019 by Alexei Raiu
Decoupled code

The "decoupled" agitation is slowly coming around. The time when web agencies sold to their clients expensive but less functional sites, using the "cool" as an argument, is slowly coming to an end. Dozens of startups with "progressive new JS frameworks" have sprung up and then meteored down. What do we have in the end, besides the clients having to rebuild their websites based on a more traditional approach now? What are the lessons? Some thoughts:

  1. Headless and decoupled sites, explained.
  2. Web agencies should have been more honest, clients - more sober over the "headless" sites.
  3. Most likely, you do not need a "decoupled" web site.
  4. The proper use of the decoupled technology.

1. What are headless (decoupled) websites?

What is "headless" or "decoupled"? The decoupled technology is called "headless", when it is decoupled from it's UI. Traditional websites create HTML markup on the server, browser receives HTML markup with the data embedded in it, and styled. The "headless" web sites serve raw data from the server, which is not rendered or styled, and then that data is rendered and themed in the browser.

Decoupled web sites allowed the CMS to act as a headless provider - storing and processing the site content, and providing it on request as a set of data responses. But getting the data from the server and building the UI for it client-side, in user's browser is much much harder then theming it back on the server. That is why the "headless wonders" looked more like a white screen with a huge image and some items just load dynamically, simplistic and primitive, though much more expensive to build.

2. Web agencies should have been more honest, clients - more sober over the "headless" sites.

From the usability and value perspective, making a decoupled blog or newspaper site means losses. Yes, your site will load faster - but if you build a primitive site like that traditional way, it will also load faster. Modern powerful websites looked like cheap blogs for a time, a single wall of text albeit loaded dynamically. If you are running a site that does not need to change live-time, you don't need to have it decoupled.

Web agencies should have resisted the urge to earn a big buck by selling their customers low value but expensive to build web sites. In most cases, building a whole client-site app just to display a web site they could have better displayed without that app, has been purely a waste. Creating and fanning excitement in order to sell that technology to the clients who didn't really need it was a sad thing to observe.

On the other hand, the clients should have been smarter. if you are given a less functional car, but told that it has wonders of science under the hood - it's time to check what value it actually provides, and whether those "wonders of technology" will actually benefit you.

3. Most likely, you do not need a "decoupled" web site.

If you own a blog, a news site page, a business presence site, or a small online commerce shop - chances are you don't need a decoupled web site. The only benefit that the decoupled technology will bring in your case is a better loading time, which will be imperceptible if you have a small site anyway. The two usual benefits of the decoupled technology - less server stress and better load times, become levelled down when the site is small or even medium sized. On the other hand, if your site is large or very large, then the cost of implementing it in decoupled way will be astronomical. Well, you can cut the cost of decoupling of throwing away some functionality of the web site. That's why most decoupled sites look so primitive. But there is a sleight of hand there. You can make your huge web site smaller and less stressful to the server, by making it simpler, or even primitive - and you don't need to go decoupled to do it!

Thus, there are very slim chances that you will need a fully decoupled web site. You need to have you site constantly evaluated, items of value added, items with no value removed. If your site is slow, you need to optimize it, cache it, throw away the parts the slow it but deliver little value, and make sure you have a good hosting provider and a good hosting plan. Writing a complex app that needs to be transpiled before it can be used on your site, and basing your site on it is a crutch, not an efficient way to solve your problem.

4. The proper use of the decoupled technology.

There is a proper use of decoupled technology in websites. When I say "proper" I mean that this tool will address the need in the best value way. Decoupled technology with its benefits of loading selective data rather than reloading the whole page is good precisely at that - when you need to load some data but leave the page as is. Here are some general proper uses of decoupled technology:

- Social Networks. You have your social network wall open, and people all over the world are updating, liking, commenting. Lots of changes in live-time. You would have to reload the page every few seconds to keep it updated. Thus, polling the necessary data from the server periodically is definitely a win here.

- Web apps. Shops. Ticket reservations. Complex searches. Various kinds of data filters. All the places where you need to constantly adjust the settings, and see the results updated. This is also a case of live data update, like in the Social Networks scenario.

5. Conclusion.

Rebuilding the whole website on a now-popular javascript framework will make your website overpriced, hard to change, and poor in functionality. You only need a completely decoupled site if your site is an app that needs constant refreshing, like a social network or an online superstore. In most cases, you want a usual website, and if you have in it some element that needs a highly reactive functionality, then you can have an app for this built into your site, leaving everything else as is.