Great applications deserve great marketing sites, which is why we’re always on the lookout for new developments and trends in content management systems (CMSs). While traditionally a space occupied by open-source giants such as WordPress and Drupal, ever since the back in 2017 there has been a resurgence of interest in static-sites. Smashing Magazine relaunch Given the complexity of modern front-end , the desire to return to the simplicity of plain HTML is perhaps unsurprising — after all, many of today’s problems (performance, async data, caching etc) are either irrelevant or come as standard with the removal of a dynamic server-side language. development While there are many vocal proponents of modern static sites, the biggest champion is Mathias Biilmann of , who is responsible for the somewhat absurd sounding ‘ ‘, and has helped popularise static-based workflows with tools such as a and . Netlify JAMStack static CMS e-commerce API ↑ Mathias Biilmann talking about the JAMStack at a conference. The JAMStack has become so popular it even has its own , birthing a whole ecosystem of plugins, services, articles and even . So what exactly makes it different? newsletter conferences Defining the JAMStack The JAMStack boils down to: JavaScript to handle async data requests/interactivity. APIs to handle dynamic data retrieval/requests. Markup compiled into static HTML files. Despite the original acronym, these principles could easily apply to blogs of yesteryear. The difference is characterised by the advanced tooling, workflows and ecosystem that have sprung up to accommodate the renewed interest. By combining the modern tooling of with services such as and a ‘static’ CMS (such as Netlify’s own), the JAMStack suggests that static-sites need not be relegated to esoteric developer blogs or hobbyist sites, but are serious contenders for client projects. Jekyll Gatsby Formspree The include performance gains, improved security and an escape from the bloated content-management systems we have become accustomed to: purported benefits “It’s a new way of building websites and apps that delivers better performance, higher security, lower cost of scaling, and a better developer experience.” However, we think there’s more than a few reasons why you should give this particular innovation a miss: Enforced minimalism Unfortunately, nearly all of the advantages of a static site are simply due to enforced minimalism. For instance, performance will be the (all else being equal), since there is no overhead to serving pages that come with dynamically generated content. The site will be considerably more secure only by virtue of there being no server-side language or database to provide a vector for intrusion. Hosting will be more economical and scaling will be infinitely easier because there are no requirements for a server-side language or database. TTFB best it possibly can be ↑ A performance chart from CSS Tricks demonstrating speed improvements from adopting the JAMStack. To say a static site is faster, more secure and more scalable is undeniably true, but it’s akin to removing the engine from a car and heralding it as a more economical means of transport. If the features were expendable in the first place, then the real question is why they were included at all. It’s true that it’s easier to start lean than it is to make something slow and bloated quicker, but a well-configured full-page cache (using something like or ) will effectively give you the performance of a static-site for ‘free’. Even Eric Meyer’s recent plea for sites to ‘ ‘ so they may better serve the traffic demands of a COVID-19 world suggests this: Redis FastCGI Get Static I can’t tell you how best to get static—only you can figure that out. Maybe for you, getting static means using very aggressive server caching and a cache-buster approach to updating info. Immature (but complex) tooling While tooling has come a long way, most static-site builders don’t provide anywhere near the flexibility of more traditional CMSs or server-side frameworks. Basic features such as named/aliased routes are rarely present, and the (while interesting) will struggle to rival the editing experience of Craft’s or ACF’s . Anyone who has spent more than a couple of hours with modern CMS-as-a-service offerings knows how much they’re lacking compared to their predecessors, missing key features all the way from conditional inputs through to . Netlify CMS Matrix Flexible Content Fields required fields Ironically it’s the content-editing experience itself which suffers the most from the JAMStack approach since, despite the developer obsession with plain text, it’s surprisingly painful to create complex editorial content the aid of a configurable CMS. If you imagine a content-builder with variable content types and related-entity fields, this becomes extremely problematic to represent in Markdown, unwieldy as and counterintuitive as JSON – especially with long-form content. without YAML Moreover, if you decide to avoid the CMS and just enter these as front-matter yourself (which admittedly works), you’ll be entirely responsible for remembering the fields and their types yourself. Forget the type-checking, restrictions (such as related entity/foreign key constraints) and the conditionals afforded by conventional CMSs. ↑ You can get part of the way there with typed MDX files, which let you intersperse React components with Markdown, but it’s a very developer-centric solution. As a result, it’s hard to provide anywhere near as robust an editing system as any CMS on the market. This isn’t just an issue for ‘less-techy’ editors, but a serious inconvenience for all involved. Fighting the JAMStack system The most perplexing JAMStack case-studies are not those which are static marketing sites, but those with a . genuine need for dynamic features Smashing Magazine itself requires advanced search capabilities, basic e-commerce features, a multi-user CMS and an integrated comments system. These are features to the success and functionality of their business and have already been excluded by their choice of stack. integral Instead of these being problems (as the developer), and choosing if/when to farm them out to third-party services, the JAMStack leaves you with little choice other than to distribute responsibility to a variety of (often unproven) 3rd parties. In much the same way as server-less is just “someone else’s server”, the JAMStack usually requires “someone else’s backend”. your Reading the dependency list for Smashing Magazine reads like the service equivalent of , including , , , and a variety of Netlify services to name a few. There is a huge amount of value in , but it is amusing to note the complexity that has been introduced in an apparent attempt to ‘get back to basics’. This is to say nothing of the potential fragility in relying on so many disparate third-party services. node_modules Algolia GoCommerce GoTrue GoTell knowing what to outsource (and when) If you can be that a project will never require a ‘dynamic’ server-side feature, then perhaps the JAMStack is appropriate. However, the second you need a dynamic feature (such as a form or comments) you either have to rely on a 3rd party or build a separate API yourself (essentially creating a backend). This solves nothing, but instead just awkwardly spreads the responsibility. certain This is even a minor blow for since features traditionally provided for ‘free’ (such as form validation messages) and e-commerce options will JavaScript, where before they did not. Anything dynamic be client-side, meaning the more holes that need to be plugged the worse things become. This is not to mention the potential performance issues created by moving an abundance of logic (possibly unnecessarily) to the client. progressive enhancement require must Conclusion There’s still a place for static sites on the web, but it’s shrinking, not growing, and likely still the domain of developer portfolios and side-projects. Sure, it’s possible to engineer a workflow in 2020 that manages to smoosh together a set of disparate 3rd parties, a version-control-system backed CMS and a bunch of template files into a working (and fast!) site, but the value is questionable. Instead of reducing complexity, the JAMStack just shifts it around. Security and performance are real concerns and will undoubtedly continue to plague developers, library authors and product owners as long as software development lives, however, the solution won’t be found in a reduction of responsibility. It’s fitting that we have taken the simplest form of a website — static HTML — and transformed it into a complex landscape of build processes, tooling and services that more than rivals the complexity it set out to supplant. Previously published at https://www.browserlondon.com/blog/2020/04/20/issues-with-jamstack-you-might-need-backend/

BUNCH

Progressive

View our award-winning work and job openings

Take a peek at our other articles (and job openings) right here!

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

The Issues with JAMStack: You Might Want To Get a Backend

Too Long; Didn't Read

Companies Mentioned

Browser London

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

The Issues with JAMStack: You Might Want To Get a Backend

Too Long; Didn't Read

Companies Mentioned

Browser London

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES