Fade to Grey: Will Headless Browsers Kill Web Design?

Is the browser as we know it today a phase-out model? Can we use the web without it? The answer to the second question is a clear yes. Will headless browsers kill web design?

Headless Browser: UI Without UI

Headless browsers have been around for about ten years now. They are applications based on the standard rendering engines (Chrome, Webkit, Gecko), and can display web content without actually displaying it. They lack the visual user interface; they are headless.

Originally, headless browsers were developed to allow for fast and automatic testing of websites. Usually, this happens via the call level interface (CLI), or defined interfaces (API). Upon request, error messages are sent out as screenshots, or in other specified ways.

Since the introduction of headless browsers, the developer community has had split opinions on them. Some think the technology is nonsense, and would instead test their designs and applications on a bunch of “normal” browsers. This is reasonable.

After all, the visitor the offer is meant for won’t be using a headless browser either. PhantomJS, being one of the most popular ones of its genre, also produces error messages that don’t exist in a regular browser. This is only partly useful.

As a server sided base technology, Node.js is pretty popular with creators of headless browsers as well. A somewhat modern specimen of that kind is ZombieJS, where the name already hints at the headlessness. In contrast to what the name suggests, ZombieJS is said to be extremely fast, making it an excellent choice for widescale efficient testing.

The confident users of headless browsers appreciate the ability to run a plethora of automatic tests via a headless browser, or an entire group of these services in a fast and straightforward way. The main supporters of headless browsers are developers of complex web applications for large target audiences.

The average web developer with a moderate product and client range doesn’t really need the economics of scale, meaning he’s likely to choose the conventional path.

Headless Browser: Google Scales the Benefit

In 2009, the search engine giant Google had the idea to use headless browsers in a very different way. The Californians were facing the problem of being unable to index content dynamically generated via AJAX. In the end, this content only turns into an indexable website after generation, as we need the browser for them to be rendered correctly and become legible.

Thus, the search engine needed an internal browser, to make the content usable. No sooner said than done! Since then, Google has been using headless browsers, allowing them to read content that needs a front-end interaction to get to be displayed, as long as the page operator takes some precautions. Bing is using similar technology.

Now that the browser engines are becoming more and more performant, what does that mean for headless browsers? Right, they are growing increasingly performant as well.

Progressive Web Apps (PWA) Show Where We’re Going

One of the core technologies of every Progressive Web App (PWA) is the so-called service worker. This is a JavaScript, capable of executing functions without the website having to be called up at all. You can find some more detailed explanations in the article mentioned above.

The service worker is a part of the headless web itself and can be used by both a headless browser and on the client site. This turns the headless browser into a service that can process programmatic procedures on the server side. This potentially makes the browser on the visitor side redundant.

On the Headless Web Contents Turn Into Modules

The headless browser has modularly pre-rendered contents. These rendered pieces of web content are available for further processing, or for display. It doesn’t necessarily take a browser to display them correctly. At the same time, a native app could take care of the entire presentation, and show a structured layout of the pre-rendered web snippets within the own UI.

Examples of these approaches are Facebook Instant Articles or Google’s AMP Project. In the article mentioned above, I stated that Google should have a particular interest in protecting the open web. AMP is a building block. However it does not receive unrestricted approval.

The web push notifications, as seen under Google’s operating system Android, go into the same direction.

Microdata is an essential factor as well. You may say that even today, there are data transfers via JSON, for example, and you’re right. The headless web takes this a few steps further, though, as it does not only take data from the handover interface but also takes entire function modules, including integrated program logic components.

For that, it is necessary to pay attention to semantically correct markup, to create building blocks that can be used sensibly.

Advocates of open web standards might enjoy this. I think it is safe to say that these open standards will gain significance in the future.

The joy of average web designers because of the victory of open web standards could quickly fade away, though. After all, classic web design won’t be needed anymore, and the aspect of architecture moves even more into the focus as it is already. This aspect becomes very clear when looking at AMP. The very standardized display and the delivery of contents via Google servers don’t cater to everyone’s taste. The project is somewhat controversial, but it is almost entirely supported by publishers. Content providers seem to love it.

So, does this mean that the areas of design and development will just be separated even more? Today, at least in front-end development, we still see a mix of the disciplines. This already starts where web designers install the software on the server and adjust the CMS theme in a way that allows it to correctly display dynamic content.

Speaking of headless, we should also mention that the trend continues for CMS. It is even possible to run WordPress and WooCommerce headless, without a frontend. In a standardized form, the contents can be drawn from the backend, and used in any desired way, like in a native app for mobile devices specially made for that.

Aside from the famous market participants, there are also solutions going for headlessness from the start, allowing them to function without legacy burdens. An example for this is ButterCMS, which exists in the Google Cloud; another example is Kentico Cloud, which is also operated as cloud SaaS.

Currently, there is no solution for scaling headless browsers in a way that they can provide thousands of instances at once. This technological obstacle is sure to vanish in the future, but it still exists as of right now. At least until then, websites with a head won’t become redundant.

(The article was originally written in the German language by Dieter Petereit for magazine Dr. Web.)

Photo by Markus Spiske on Unsplash