↗ The rising complexity of JAMstack sites
Two weeks ago I shared my thoughts and doubts about the JAMstack. Today I came across an article by Mike Riethmuller, who seems to have a lot more JAMstack experience under his belt than me. Most of the article resonated with me:
Despite my enthusiasm, I'm often disheartened by the steep complexity curve I typically encounter about halfway through a JAMstack project. Normally the first few weeks are incredibly liberating. It's easy to get started, there is good visible progress, everything feels lean and fast. Over time, as more features are added, the build steps become more complex, multiple APIs are added, and suddenly everything feels slow. In other words, the development experience begins to suffer.
[…]
The end result is we've outsourced the database, fragmented the content management experience and stitched together a bundle of compromises. That’s a stark contrast from the initial ease of setting up and deploying a JAMstack site.
Mike continues with a thoughtful analysis of the current state of the JAMstack, and intrudoces the idea of a "JAMstack Plus", essentially bringing the best parts of JAMstack and monoliths together.
I don’t think JAMstack should defined by pushing all the complexity into the front-end build process or by compromising on developer and user experience. Instead, I think JAMstack should focus on providing lean, configurable static front-ends.
That said, lean and configurable static front-ends are kind of a niche requirement in my world. While the JAMstack is a great tool in this space, I do believe it's in a hype phase.
Read the "The Rising Complexity of JAMstack Sites and How to Manage Them" on CSS-Tricks.