The JAMStack is PRPL at Build Time
October 27, 2018
Two interesting web-related things happened this week. First, I finally started reworking 12inchesbehind.com into a personal gallery for myself. It’s still a complete wreck, but in the interest of following the “release while embarrassed” paradigm, I loaded it onto Netlify, fixed up DNS, and put it out there.
The other thing that happened is that this blog went down briefly. At first I thought it was the hosting (surge.sh), but they’re actually great hosting as always and it was my mistake on the DNS side. Anyway, all the other small sites I host are on Netlify so I took the opportunity to move this over also.
That took literally two minutes, and I actually did it while filling my car up with gas on the way home. The low level of friction for hosting these days is incredible.
12inchesbehind is a fairly simple Vue.js app, front end only, with just JSON and images on the backend. I’m not using Nuxt or anything like that right now.
Kanonical, on the other hand, is all Gatsby, and I’ve talked before about how much I like this setup. It’s clean, simple, makes a very performant site and let’s you focus only on what you care about: content and style.
Gatsby follows the PRPL pattern to gain all of it’s performance. PRPL stands for:
- Push critical resources for the initial URL route.
- Render initial route.
- Pre-cache remaining routes.
- Lazy-load and create remaining routes on demand.
The goal is to get to interactivity as fast as possible.
Which is very similar to the JAMStack.
If the whole point of PRPL is to get the user to interactivity as fast as possible, then the whole goal of the JAMStack is to get the developer to interactivity as fast as possible.
Meanwhile, the developer gets to focus on rendering the front end, making sure the style and UX is strong, knowing the content will be injected.
A build ends up becoming an optimized set of static files that can be loaded anywhere, just like the many generations of static-site generators. But the additional focus on APIs, interactivity can be added and lazy-loaded after a build is complete. A simple example is comments loaded via Disqus. Render the critical content first (the article, or whatever) while reaching out to Disqus to get the comments loaded as needed.
As always, I have way too many little projects either in progress or in the queue. And I am also always frustrated by the friction that’s required to really get started, whether real or imagined. The full stack of a development environment grows in complexity every day, and we frequently build on top of 20 other abstraction layers.
12inchesbehind is still a mess, but it’s out there. It’s started. Removing barriers made me get started on it. Aside from the simplicity, that’s the real beauty of the JAMStack. It optimizes for interactivity and removes the excuses I have to just throw something simple out there.