My datacenter provider updated some of its UI components from a plain non-responsive page to a newer brand identity. A new API + docs, a new wiki/community page, a new monitoring/status page. Fancy pancy JS frameworks all over the place. Gatsby, react / next.js, …
This is a new incentive for me diving into these new js frameworks popping up in a monthly fashion. What are the advantages? What is done “better”, than having a good ol’ PHP page?
From what I’ve seen so far, everything gets fine tuned to a nearly instant loading of the general page, even if it’s just for blank page without anything but html headers and a bunch of javascript files. The rest: AJAX.
So what is the advantage?
I’m not entirely sure, yet. Caching is a big deal. As the content gets pulled via ajax, you can control the cache by a wide range for every single piece of text or asset.
Another advantage is having static sites. Once “compiled”, it’ll become a single ready-to-view html file. This reduces any performance peaks by just providing a single html file. Damn.
What about PHP?
After looking for some information, I’ve questioned myself: but how comparable is it to PHP? The point of view is kind of different, so a side-by-side comparison is not possible, or then again not meaningful.
If we take our view away from comparing to combining them, the possibilities become clear.
Think about PHP as the door bouncer of a big mariadb database, for example as an API. The JS code runs on the client and pulls the content from the API. A part of the computing code has been shifted to the client.
Now, if we would have a single PHP site, every page refresh would step through everything every single time: process any parameters, connect to the db, select the data, process the data, foreach it several times and send the final result to the client. That’s when the page is displayed.
While having the API<->client design in mind, the client hits the page. HTML and some js stuff gets transfered; the content will load right after displaying the html skeleton.
Any caveats?
In this very moment, I could think of 2 major drawbacks. The first one is having a proper error handling from the client. With PHP I just set a try-block with a logging instance, or an email on critical stuff. But what happens, when the client raise an error?
Thinking further on this one, and coming to my second negative point, what happens when the client is having a faulty network. The browser displays a page, as the initial load is done pretty quick. But then again it displays a bunch of placeholder stuff – if any is provided beforehand. Most likely it won’t even display anything useful to the client – just an eternally spinning loading-gif.
Time to test?
I surely would like to test any of the frameworks for a small project. Sadly I can’t think of a project on my todo which would benefit from having js client-driven code. Provided that my view on this topic is on point, though.