Web Design Blog

JAMstack and WordPress: Friends or Foes?

“Modern” web dev is suffering from some sever tunnel vision, it seems.The problem is simple.You have some data. You want people on the other side of the world to interact with your data. Between the people and the data, there is the Big Bad Internet, and the human-machine boundary. This is where you come in, the “big bad internet and also human-machine-boundary expert”.Now, WordPress has a reputation for being slow. Well, Sherlock, you were never supposed to use that thing for anything serious. WordPress was designed so that a random layperson could blog about their hobby without having to learn about servers, HTTP, Continuous Integration, XMLHttpRequest Objects, Linux filesystems, and all that. It’s easy to install, it runs on literally any shitty $1/mo shared web hosting out there, it delivers. All that comes at a cost: the “template system” is a steaming mess, the self-modifying updater is a security nightmare, installing it requires violating several security best practices, the data model is heavily biased towards casual blogging and will get in your way the moment you start using it for something that isn’t a casual blog, performance is atrocious especially under load, it doesn’t scale in any sense of the word, it sacrifices a sane data model for ease of use (essentially, the data model is “fragments of HTML source that we’ll concatenate together and then pray that the result resembles well-formed HTML enough to fool an average browser”). Frankly, it’s a miracle that it does what it does as well as it does. Of course it’s slow – but that has nothing to do with the “LAMP stack”, nor is the fact that it pulls data from a local database part of the problem.Remember, what we’re doing is pull data out of a database, move it over the big bad internet, and while doing so, convert it into something an average non-technical user can work with. Whether that data comes from a local database, or from a database someone else runs for us and that we access through an API, the reality remains, we need to pull the data out of a database, move it over the internet, and convert it into a nice representation. One way of another. “JAMstack” isn’t inherently faster than the older server-centric model, and if we ditch WordPress and use something that was actually built for security and performance, the server-centric approach can be just as fast and secure as your typical JAMstack site.But there are still massive advantages to the JAMstack approach.One of them is client-side rendering. Turning raw data into a pretty DOM tends to eat up significant hardware resources, and especially when our application is highly dynamic, caching won’t help much. And a simple truth about the economics of all this is that we have one server (or one cluster, but still), but as many clients as we have visitors; and while we pay for the server, the visitors pay for the clients. In other words, rendering on the client means we’re rendering on hardware that 1) we don’t have to pay for, and 2) automatically scales with demand. This is a big advantage. The downside is of course that there is no longer a shared cache between clients (we cannot have client B pull rendered documents from client A, because they don’t know about each other).Another one is that we can offload a lot of complexity to third parties. We can put the data in some headless CMS, run by a third party; we can use all sorts of functionality from third-party web services; if we can offload all that stuff, then all our server needs to do is serve a JavaScript program and a couple of static assets. In other words, our hosting environment becomes ridiculously simple – a vanilla Apache or Nginx, or even lighttpd or whatever, with a run-of-the-mill configuration, will do the trick. Our deployment script can be an rsync one-liner. No need to mess with docker, a vanilla Debian image will do. No need to “orchestrate” anything. No need to manage a database. Heck, we can even outsource the hosting entirely, run it on heroku or github pages or whatever – after all, we just need to host some static files. But of course, the Free Lunch Theory strikes here again: if we offload everything to third parties, we have to play by their rules, we depend on them, we are at the mercy of their business decisions, and we may end up paying more for their services than doing it ourselves would have cost us.Fortunately, this isn’t even a dichotomy. There are more ways of doing server-side web dev than WordPress. And you don’t have to go all-out with the JAMstack idea to reap the benefits.