React is gaining ground as a universal server side templating system
As a web developer it’s been near impossible to miss the explosion of popularity that React and other component based view libraries have enjoyed in the recent years.
They’ve brought structure to front end development. Instead of haphazardly monkey scripting the DOM, you are forced to have discipline.
A lot of the hubbub around React is around sophisticated Single Page Apps with cool dashboard views, 60 FPS animations... But what is easy to miss is the fact that the component based structure, popularised by React, also makes a lot of sense for server side templating — output being vanilla HTML.
Traditionally front end clients have mimicked back end templating systems, but lately front end templating techniques are increasingly being adopted on the server side. In a sense the tables have turned. On this front and others.
A brief history of server side templating
Server side developers have for a long time been relying on a number of templating systems to generate their HTML output. Depending on your environment you might have come across Blade, Handlebars, Jinja2, JSP, Pug, Twig or even the dreaded inline PHP from the days of yore.
So, there is no lack of server side templating languages. But what the most popular options lack is enforcing structure. Jinja2 and derivatives like Twig have useful concepts like child templates derived from parents. Wielded correctly they can be used to maintainable templates. But we can do better.
Before React, the closest thing to enforced structure in templating systems that I can recall is using XML and XSLT from the late 1990's. This combination allows you to combine an XML document and an XSLT transformation definition to output a desired markup. Sounds nice, no?
In fact, browsers can actually directly perform the task of XML and XSLT processing without plugins. In some visions HTML was going to be replaced by this combination. But XML/XSLT are notoriously difficult to write and have a horrible syntax. This is probably why the approach never became widely adopted for web UI development. The notable exception being enterprise tools like Documentum that were deeply interlinked with XML.
Component based templates on the server side
Now with the rise of component based view libraries, and React in particular, composing structured templates on the server side is becoming a staple for developers. Writing isolated components that have all related functionality in a single file has it’s advantages and is very convenient.
Instead of needing to dig out how to write template extensions, register them in your backend and other boilerplate tasks… You write it on the spot to that specific component. And instead of writing cumbersome macros in a template language, you write standard JavaScript syntax leading to more readable template code. A well written component will also be directly reusable in the browser, which can be a positive side effect in some cases.
The vast majority of React developers write their components in JSX, a format that many developers learn to love after the initial shock of mixing JavaScript and HTML. In fact, you can think of JSX as a developer friendly version of XML/XSLT. It enforces you to write valid component markup.
Speaking of JSX, Facebook actually introduced a JSX like XHP templating format for PHP way back in 2010: XHP: A New Way to Write PHP. The XHP format continues to power some Facebook’s back ends, now in Hacklang.
Using React rendered HTML is not limited to Node
React and server side rendering are still considered as cutting edge or exotic by some. And yes, writing universal JavaScript applications that execute the same code in the client as on the server continues to be non-trivial.
But when it comes down to using React as a server side rendering technology, it’s more wide spread than you would think. And this is not limited to greenfield projects or projects that run JavaScript exclusively.
Many choose to create a separate front end delivery layer and go all in on React, but this can be overly complicated and unfeasible. What you can do is go with a hybrid solution, where you embed React rendering to your current back end stack. Some of these bridge solutions for popular platforms are:
- Java: jreact
- dotNET: React.NET
- Golang: go-starter-kit
- PHP/Symfony: ReactBundle
- Ruby/RoR: React on Rails
So as you can see there are working concepts for many different platforms. All of them rely in one way or another on a JavaScript engine like Duktape, Nashorn or V8. So your template code is always executed as JavaScript.
Some might feel that running an embedded JavaScript engine through phpv8 or a separate daemon on Node.js is a hack. Maybe so, but on the other hand just a decade ago running JavaScript on the server was a joke.
Essentially maintaining a dedicated service for template rendering is no different from the other services you’re running; Elastic/Solr for search, Memcached/Redis for caching, MySQL/MongoDB for persistance…
As a bonus, if you treat template rendering as a service and architect correctly — you can scale templating horizontally by adding render nodes.
Server rendered React HTML is already everywhere
I intentionally left out Python from the list of technologies able to render React on the server side in the section above. This is because Python and Pinterest provide one of the best examples of where React is being used to render templates in a non-JavaScript setting, with a gradual deployment.
In their in-depth article Pinterest describes reasoning and the process they to migrate gradually from Jinja2/Nunjucks templates to React components:
In 2015, we made the decision to migrate our legacy web experience to React to keep up with our fast growth and perform better with increased developer velocity. Ultimately, we found React rendered faster than our previous template engine, had fewer obstacles to iterating on features and had a large developer community.
- How we [Pinterest] switched our template rendering engine to React
Pinterest is a significant web property that can afford to pour resources into such a project, so it could be considered as somewhat of an isolated case.
Being based in Finland I’ve tracked a some local mainstream websites and services that already serve React rendered HTML to their visitors:
- Yle.fi: The national broadcasting company in Finland, YLE, has a large number of web properties, but the main site’s news section recently switched to React rendering.
Example: http://yle.fi/urheilu/3-9315477 - Verkkokauppa.com: The second largest electronics retailer in Finland switched their site to React rendering in October of 2016.
Example: https://www.verkkokauppa.com/fi/product/27457/ghgmv/Microsoft-Surface-Pro-4-tablet-Win-10-Pro - Ampparit.com: A news aggregation service. In their current beta, their site is now rendered using React.
Example: http://beta.ampparit.com/kotimaa - Finder.fi: Finder is a business catalog. They have been serving React rendered HTML since late 2015.
Example: https://www.finder.fi/Kiinalaiset+ravintolat/Kiinalainen+Ravintola+Tung+Hing/Espoo/yhteystiedot/182245 - VR.fi: The Finnish railway services provider is renewing their services. As of now they’re not rendering on the server side yet, but it’s likely just a matter of time that they do.
Example: https://beta.vr.fi - Suomi.fi: A government portal that collects various content from a number of different locations. In the latest beta the portal uses client side rendered React.
Example: https://beta.suomi.fi/kansalaiselle/oppaat/178
So as you can see React is already being used to build interfaces across a number of different type of web services. Some of them may have more rich functionality built on top, but in this case I decided not to focus on those.
The days of Twig and other templating engines are far from over, but React is increasingly attractive for pure backend templating as well. Even if you’re not into the front end UI development, knowing React basics is worthwhile.
