aka. Seshpenguin
title: 'Introducing: React Seshan.XYZ – Fundamentals for Legacy PCs!' author: Seshan Ravikumar type: post date: 2019-07-24T16:00:13+00:00 url: /2019/07/24/introducing-react-seshan-xyz-fundamentals-for-legacy-pcs/ classic-editor-remember:
Have you ever wanted to browse my website, but were stuck with Netscape Navigator, IE 5, or something even more obscure? Well, I have the solution for you!
No Seshan, no one even visits your website.
On top of the regular xyzwp WordPress theme, and the recently introduced client-side React frontend, we have a third option to view this website: React Seshan.XYZ – Fundamentals for Legacy PCs (RSXYZFLP)!
Please just stop…
RSXYZFLP has a number of key features. It no client-side JS, and is based around plain HTML to support all the browsers!
Here’s how it works behind the scenes: The website itself is written in React (plus React Router), but instead of letting React run and render on the client side, as it is designed to do, we instead make use of ReactDOMServer to render the app in a NodeJS Express app, which then serves the resulting HTML.
There are a few limitations of ReactDOMServer I had to work around, though. Most notably is that the renderToStaticMarkup() function is completely synchronous. Basically, I can’t actually fetch data from within the React part of the server.
To overcome this, I implemented a data caching system. When the Node app first starts, we call a function to load fresh data (page content, blog posts, etc,) into an object. Then, every request calls a function that will:
This actually works out pretty well, since there is always data ready to be served, and the data object will be periodically updated. The reason we have to pull in all the data at once is because React Router handles the… well routing, the app doesn’t know what page is to be served until we are already executing renderToStaticMarkup (which calls React). Recall that React won’t be able to wait for async calls in this configuration, so the data has to be available before it starts rendering.
The way we pull in data is more or less the same function from React Seshan.XYZ, which uses the Axios library for really easy calling of the WordPress wp-json REST API.
But wait! There’s more!
I decided, just for the heck of it, let’s throw Espi.Dev in there too! His website makes use of lots of CSS3 things, like animations, which poor IE wouldn’t be able to keep up with.
To pull content from Espi.Dev, I used axios as usual, but this time we are just pulling in the straight HTML from Espidev’s website. In order to parse the HTML and pull out the data we need, I used Cheerio, a NodeJS implementation of jQuery that allows us to parse the html into a DOM, so we can pick out the content we need.
The NodeJS server itself is running on the same machine as everything else, a PowerMac G5 running Ubuntu 16.04. Now, while this is a ppc64 (Big Endian) machine, and there are ppc64 builds of Node, I couldn’t get them to work. I think it has to do with that fact that Ubuntu uses a ppc64 kernel, but the userspace is just the regular 32-bit powerpc.
Since I couldn’t get Node 8 (there weren’t even ppc64 builds of Node 10, though ppc64le builds exist), the next best option was the Node 4, available from the package manager. Even though Node 4 is alarmingly old (and probably a really bad idea to run from a security standpoint), that didn’t stop me. What would stop me is if I had to write old-school JS that worked on Node 4. Thankfully, Babel to the rescue! Babel lets me write in modern ES2019, and have it “transpile” to old-school JS, bundling the necessary polyfills too!
So yea… as you can tell I am really bored and decided to write some more garbage code 😀
Oh and if you were wondering about the name: It is a reference to Windows Fundamentals for Legacy PCs, and version of Windows XP Embedded that Microsoft released to transition old systems running Windows NT 4, 95 etc to a more modern version of Windows.