THE Tasty, Tasty Jamstack
If you’ve never heard of THE Jamstack then you’re not alone. Jamstack has quietly grown in the shadows of goliath Content Management System (CMS) technologies like WordPress, Joomla, and Drupal, and platforms like Squarespace, Wix, and even more WordPress with WordPress.com and WPEngine.
Jamstack is not about any specific technology but rather the latest manifestation of Developer Experience (DX) thinking. Jamstack doesn’t care about your tool choices because it’s simply a different methodology for building websites and web applications that focuses more on the build process and less on the client/server process of content delivery. It just so happens that Jamstack delivers better performance, higher security, lower cost, and an overall better developer experience.
Saturday Morning JAM Session
No templates. No database processing. No plugins.
Only pre-rendered which are browser-friendly pages and load lightning fast. Pre-rendering also means a greatly reduced attack surface area for malware, ultra-fast hosting via content-delivery networks (CDN), no debugging PHP or optimizing render times, and a super cheap way to scale your hosting.
Doesn’t that sound like a balanced coder breakfast? If it does, then read on!
Cloud JAM versus CMS Jelly
How does Jamstack accomplish all of these advantages? It’s because Jamstack uses modern build tools to produce automated builds because everything now lives in Git. Jamstack is a citizen of the distributed world of cloud computing. By decoupling and pushing all the complexity of server rending back into the build process, you remove complexity. This in turn reduces the load on the server to only serving pre-rendered static files deployed via a CDN.
Remember all those pesky dependencies and plugins that your CMS needs to function (or not function) when each page is requested? Jamstack doesn’t have those 3rd party time bombs lurking on the server. There are no white screens of death or compatibility warning bugs to ruin your weekend when all the files are static. If you’re a WordPress developer this is a huge improvement over trying to de-bug a complicated WordPress site.
Building Faster Toast
Static files have another huge advantage over-bloated CMS software – speed! Mobile devices need fast files without all the fat size. This makes static files ideal for mobile demand because they load faster and do not need to be rendered. When you add in the advantage of a CDN, you can now deliver those pre-rendered files to customers in milliseconds over WiFi. One trip to and from the CDN and done. Meanwhile, the CMS is making its fifth-round trip to complete the request.
To put it simply, Jamstack pages have already finished loading before the CMS has a chance to put its pants on!
Speed and small file sizes equal bandwidth savings too. When Amazon AWS, Google Cloud, Digital Ocean, Heroku, and every other cloud host charges you for egress bandwidth throughput, it would be nice to have a greatly reduced bill for a change. The bandwidth savings alone can make JAM Stack a viable solution for any web development team.
Jamstack in your Lunch Box
Security is a big problem with CMS sites. Every trip to and from the server includes a database connection, sketchy 3rd party plugin code, and even an exposed URL for CMS administration. All of these tightly coupled connections are potential attack surfaces for hackers, bottlenecks, outages, and failure. If just one of these areas is hit the entire CMS is down.
Meanwhile, Jamstack literally lives on the edge. That is to say that the CDN is the only point of failure. But let’s say the CDN does go down. Your static website is unchanged until you change it and deploy a new version. Additionally, the failure of a single CDN, although rare, is not the end of the world. CDN’s scale-like Tribbles during an outage. You kill one CDN and two more rises to take its place! Hail Hydra! Um… err… I mean Cloud CDN Technology! Because Jamstack rides on a distributed cloud environment framework, taking out the CDN is only 0.1% likely (due to the industry 99.9% uptime that most providers give you — see what I did there).
I’ll have some Jamstack with my Netlify coffee too!
To deploy quickly to Netlify:
- Create a free-tier Netlify account.
- Connect your GitHub repository to your Netlify account.
- Then, using any website or web application builder (I happen to use Parcel) you tell Netlify how to build your site.
- With everything set up correctly, the next time you update that particular GitHub repo, Netlify will trigger a build.
- You can then decide if you want that build to be published or have Netlify automatically publish it for you.
Either way, all your code, pre-processors, task runners, and dependencies are local to you. They don’t live on the server and don’t need the server to render them when requested. All of that work has already been completed.
Jamstack with Every Balanced Breakfast
I am a bit late to the Jamstack game but it feels like it’s only halftime. Plenty of time to make some plays, put some points on the board, and leverage this thinking with several of my sites. Especially websites and small apps that do not benefit from being wrapped around the WordPress axel. Not to mention freeing myself from a web host that likes to hit me with overage charges created by having too many WordPress sites running all at once.
In fact, I see Headless WordPress and/or GatsbyJS as a direct response to Jamstack thinking. Both are interesting decouping solutions for building websites, however, only Jamstack appears to have the better community. Headless WordPress is gaining traction, but not unlike WordPress Multisite, mainstream WordPress developers will take some convincing before they fully embrace Jamstack-like thinking.
Meanwhile, Jamstack is blazing a trail forward with Developer Experience (DX) at the forefront of their growth with a community built around the practice of Jamstack, not the products it uses.
#jamstack #cloud #buildprocess #webapps #cicd #headlesswordpress #wordpress #dx