Main navigation

Breadcrumb

The word is out. Headless Drupal with a REST API, is not the future. You're better off rendering your initial view on the server side. The wheel has been reinvented. This is called Isomorphic or Universal Javascript. The jury is still out on what title is the best. But Isomorphic JavaScript, introduced way back in 2013 by AirBNB and others holds some advantages.

In the past few years the web community has been buzzing about client side applications that consume JSON. While this is an attractive prospect in some uses cases, the truth of the matter is it won't invalidate the page-to-page content consuming paradigm. You know - browsing websites.

With evergreen browsers and polyfills we can adopt new technologies like web components faster than ever before. On the CSS side developers are used to using CSS pre-prosessors like SASS and LESS. You can send the SASS to the browser and have the it render that to CSS, but that will take time and make the application less responsive on the first pageload.

This is why it is common to render SASS and LESS on server-side to CSS - which is the native format browsers consume. A similar workflow can be applied to custom tags and other polyfills. So essentially you will prerender the generated polyfill HTML/CSS/JavaScript on the server and send them over in a browser native format. This improves the user experience at the most crucial time - the first time a user visits your website.

You can also have a hybrid model (isomorphic applications, which run the same code on the server and client) where you render the first pageload HTML on server-side and then the JavaScript client takes over and no subsequent requests will be just JSON rendered by the JavaScript framework of your choice. The hybrid model will give you the best experience for your users and if done right, won't add much development overhead.

Isomorphic applications and Drupal REST API in practise

There are various ways of taking isomorphic JavaScript into use today. Some will insist on running a Node.js server and a completely separate application for this. While necessary in some cases, for many it simply adds complexity of running yet another http process on your site - possibly requiring proxy setups, etc. within. This might make sense, or not. Your mileage will vary.

Another option is to render the view sent to your browser with a browser. Sounds like a WTF with a lot of overhead (it is!), but it's a practical solution. You can expose your site with a reverse proxy such as Phantom.js and have your JavaScript application be capable of hooking up to an existing DOM, instead of a virgin one with custom templating in it, like Angular templating.

The third option is to render your JavaScript components in with node in PHP. Write your application templating in Twig, make a Twig extension that renders components using Node - internally in your Drupal PHP code. It may sound like a lot of overhead, but it's the most simple way of not creating a strong dependency on Isomorphic JavaScript - allowing smooth transition between completely serverside rendered applications and isomorphic JavaScript created with React or Riot.js.

Riot is a JavaScript framework (and pattern) called Riot.js and RiotControl. It works very much like Facebook's React.js+Flux combination, but it is more simple to use - making it perfect for examples. Learn more: