{"id":298412,"date":"2019-11-15T09:48:07","date_gmt":"2019-11-15T16:48:07","guid":{"rendered":"https:\/\/css-tricks.com\/?p=298412"},"modified":"2019-11-21T07:18:36","modified_gmt":"2019-11-21T14:18:36","slug":"jamstack-cmss-have-finally-grown-up","status":"publish","type":"post","link":"https:\/\/css-tricks.com\/jamstack-cmss-have-finally-grown-up\/","title":{"rendered":"JAMstack CMSs Have Finally Grown Up!"},"content":{"rendered":"
This article is based on Brian’s presentation at Connect.Tech 2019<\/a>. Slides with speaker notes from that presentation are available to download<\/a>.<\/p>\n In my experience, developers generally find the benefits of the JAMstack<\/a> easy to comprehend. Sites are faster because the resources are static and served from a CDN<\/abbr>. Sites are more secure because there is no framework, application server or database to compromise. Development and deployment can be optimized because all of the pieces that make up the stack are unbundled. And so on.<\/p>\n What can be more difficult for developers to comprehend are the trade-offs that this can often require for the folks who create and edit content. Traditional, monolithic content management systems have often been ridiculed by developers (yes, even WordPress) who became frustrated trying to bend the tool to their will in order to meet project requirements. But, until recently, the JAMstack largely just passed that burden onto the non-technical content creators and editors.<\/p>\n <\/p>\n Static site generators (i.e. tools like Jekyll, Hugo and Gatsby) grew enormously in popularity in large part because developers adopted them for projects. They became common solutions for things like blogs, documentation or simple static pages. By and large, these were sites created by developers, maintained by developers and with the content primarily written and edited by developers.<\/p>\n When I first wrote about these tools in a report for O’Reilly in 2015, this is what I said:<\/p>\n Just in case this isn\u2019t already clear, I want to emphasize that static site generators are built for developers. This starts with the development of the site all the way through to adding content. It\u2019s unlikely that non-developers will feel comfortable writing in Markdown with YAML or JSON front matter, which is the metadata contained at the beginning of most static site engine content or files. Nor would non- technical users likely feel comfortable editing YAML or JSON data files.<\/p>\n —Me (Static Site Generators report for O’Reilly 2015)<\/small><\/p><\/blockquote>\n When, two years later, I wrote a book for O’Reilly<\/a> on the topic (with my friend Raymond Camden), not too much had changed. There were some tools at the very early stages, including Jekyll Admin<\/a> and Netlify CMS<\/a>, but they had not matured to a point that they could realistically compete with the sort of WYSIWYG<\/abbr> tooling that content editors were used to in tools like WordPress.<\/p>\nBy developers, for developers<\/h3>\n
\n