What is an SSG ? Is it better than a CMS ?

[JeevanisM]

Hi All,

I happened to stumbled upon this website gatsbyjs.com . I know there is a huge hype about Node.JS but I never understand the Node/NPM concepts yet. So what is a Static Site Generator, as in how good it is when almost  99% of web projects are Dynamic ?  I would love to have some comments on this. 

[MoritzLost]

Static site generators will probably be 'the next big thing'. You get way better performance and security by default than you could have with any CMS by definition. Which doesn't mean that you can't have dynamic content like comments, e-commerce etc. But instead of bundling that functionality, you're using external services, APIs, serverless functions and build automation to persist data and trigger builds whenever something changes. I'd recommend reading the Jamstack book (created by the Netlify people), you can get the ebook for free and it explains all the concepts related to SSG.

By the way, you don't need NodeJS / NPM to have a static site generator. Though many SSG are built with JavaScript, they use NodeJS only as a runtime for the build step, not as an actual server. But there are SSG written in all kinds of languages - check out this site if you want to find one you like. One could argue, by the way, that the ProCache module for ProcessWire is also kind of a SSG generator, even though it works a bit differently than most tools on that list.

My current recommendation is eleventy, I'm currently rebuilding a couple of my own sites as well as a ProcessWire-related project that I might release soon with it ?

[LostKobrakai]

11ty is great. It's super flexible and doesn't lock you into a certain way of using it or fixed templating. Static site generators make a lot of sense for anything in the realms of corporate or product marketing page. You can keep all the stuff, which rarely changes in plain html. Form submissions and such can just be sent to a different headless endpoint. There's also things like Netlify CMS or similar tools, which allow you to trigger rebuilds whenever something in the underlying data changes. This is nice if you don't want to involve a dev every time some copy changes. For more dynamic content like e.g. comments I'd still not use a static site generator. They make sense if the cost of rebuilding for each change is outweight by the simplicity of deployment / putting the site up somewhere, but not really if you're constantly rebuilding. I don't really subscribe to the idea of having highly dynamic content just rendered client side, but people do use ssg's as an alternative to the dreaded SPA. Dynamic content is still all loaded/rendered in js, but at least it's multi page with some static bits.

[teppo]

On 8/16/2020 at 3:52 PM, MoritzLost said:

Static site generators will probably be 'the next big thing'. You get way better performance and security by default than you could have with any CMS by definition. [...] One could argue, by the way, that the ProCache module for ProcessWire is also kind of a SSG generator, even though it works a bit differently than most tools on that list.

When I started working professionally on web projects...

(don't you just love when folks start with that? "oh man, it's going to be another rant!")

... some of the first CMS' I had the pleasure to work with were kind of "static site generators": they generated static HTML files when you saved the content, and if your site had subdirectories, those were literal directories on the disk with more HTML files in them. I believe this was in part because server-side rendering back then was pretty darn slow and clunky, but also because it was easier to build a clean site structure with actual directories filled with static HTML files.

"Dynamic" features, comment forms, polls, and whatnot were not quite as important back then, mind you.

Now, I get that modern SSG's are a different beast in many ways, and I think they're actually pretty rad. What bugs me, though, is the amount of marketing bullsh... uhm, opinionated information floating around. Things like this gem from the staticgen.com website (emphasis added):

Quote

The typical CMS driven website works by building each page on-demand, fetching content from a database and running it through a template engine. This means each page is assembled from templates and content on each request to the server.

I mean... how is this what a "typical CMS driven website" looks like? Any half-decent CMS has built-in caching support, at least to some extent, and caching plugins regularly pop up amongst those lists of most popular plugins for platform X. You don't need to be a rocket scientist to figure out that running a server-side rendered, CMS generated website with no caching whatsoever is a Very Bad Idea™. Comparisons like this may make the SSG approach sound good, but they've also got little to do with how things actually work.

Quote

Is it better than a CMS ?

Without hopefully being too blunt, I don't think this is necessarily the best question to ask.

If you define SSG as an application that reads markdown files from disk and generates a static site from those (that's one of the first definitions that comes up if you search for the term) then I don't see this as a solution most of us could push to our clients. At least not unless the site in question is a static one that doesn't need to update too often, and/or you can convince the client to pay you for each modification on a case-by-case basis.

On the other hand if you think of an SSG as something that generates static site from dynamic content managed by some piece of software, well... that software you use to generate the content for the SSG? That's a CMS. It may be a headless CMS, but a CMS nevertheless ?

I'm also going to agree with @MoritzLost on the point that ProcessWire + ProCache is indeed a kind of an SSG. Keeping a few potential pitfalls in mind one could definitely use this combination to build a setup that pre-renders the whole site and thus doesn't depend on request time server-side rendering.

The web is full of interesting tech: headless CMS', static site generators, APIs, and whatnot. While the "best" choice depends on the use case — you would have to consider the pros vs. cons and figure out what's best for each particular project, client, and team — in my opinion it's also rarely all that important. Websites are created for end users and end users don't care what you're running the site on — as long as it works, serves their needs, is fast (enough), etc.

... and you can get that with any platform ?

Sorry, that last part was a bit off-topic. Overall the SSG market is well worth keeping tabs on. Personally I tend to lean on the "dynamic CMS generated content rendered server-side with efficient caching policy" approach, but that's mostly because I feel it makes sense for the kind of projects and clients I tend to work with. Pros and cons ?‍♂️

[JeevanisM]

22 hours ago, MoritzLost said:

Static site generators will probably be 'the next big thing'. You get way better performance and security by default than you could have with any CMS by definition. Which doesn't mean that you can't have dynamic content like comments, e-commerce etc. But instead of bundling that functionality, you're using external services, APIs, serverless functions and build automation to persist data and trigger builds whenever something changes. I'd recommend reading the Jamstack book (created by the Netlify people), you can get the ebook for free and it explains all the concepts related to SSG.

By the way, you don't need NodeJS / NPM to have a static site generator. Though many SSG are built with JavaScript, they use NodeJS only as a runtime for the build step, not as an actual server. But there are SSG written in all kinds of languages - check out this site if you want to find one you like. One could argue, by the way, that the ProCache module for ProcessWire is also kind of a SSG generator, even though it works a bit differently than most tools on that list.

My current recommendation is eleventy, I'm currently rebuilding a couple of my own sites as well as a ProcessWire-related project that I might release soon with it ?

thanks for the detailed explanation 

[JeevanisM]

15 hours ago, teppo said:

When I started working professionally on web projects...

(don't you just love when folks start with that? "oh man, it's going to be another rant!")

... some of the first CMS' I had the pleasure to work with were kind of "static site generators": they generated static HTML files when you saved the content, and if your site had subdirectories, those were literal directories on the disk with more HTML files in them. I believe this was in part because server-side rendering back then was pretty darn slow and clunky, but also because it was easier to build a clean site structure with actual directories filled with static HTML files.

"Dynamic" features, comment forms, polls, and whatnot were not quite as important back then, mind you.

Now, I get that modern SSG's are a different beast in many ways, and I think they're actually pretty rad. What bugs me, though, is the amount of marketing bullsh... uhm, opinionated information floating around. Things like this gem from the staticgen.com website (emphasis added):

I mean... how is this what a "typical CMS driven website" looks like? Any half-decent CMS' has built-in caching support, at least to some extent, and caching plugins regularly pop up amongst those lists of most popular plugins for platform X. You don't need to be a rocket scientist to figure out that running a server-side rendered, CMS generated website with no caching whatsoever is a Very Bad Idea™. Comparisons like this may make the SSG approach sound good, but they've also got very little to do with how things actually work.

Without hopefully being too blunt, I don't think this is necessarily the best question to ask.

If you define SSG as an application that reads markdown files from disk and generates a static site from those (that's one of the first definitions that comes up if you search for the term) then I don't see this as a solution most of us could push to our clients. At least not unless the site in question is a static one that doesn't need to update too often, and/or you can convince the client to pay you for each modification on a case-by-case basis.

On the other hand if you think of an SSG as something that generates static site from dynamic content managed by some piece of software, well... that software you use to generate the content for the SSG? That's a CMS. It may be a headless CMS, but a CMS nevertheless ?

I'm also going to agree with @MoritzLost on the point that ProcessWire + ProCache is indeed a kind of an SSG. Keeping a few potential pitfalls in mind one could definitely use this combination to build a site that pre-renders the whole site and thus doesn't depend on request time server-side rendering.

The web is full of interesting tech: headless CMS', static site generators, APIs, and whatnot. While the "best" choice depends on the use case — you would have to consider the pros vs. cons and figure out what's best for each particular project, client, and team — in my opinion it's also rarely all that important. Websites are created for end users and end users don't care what you're running the site on — as long as it works, serves their needs, is fast (enough), etc.

... and you can get that with any platform ?

Sorry, that last part was a bit off-topic. Overall the SSG market is well worth keeping tabs on. Personally I tend to lean on the "dynamic CMS generated content rendered server-side with efficient caching policy" approach, but that's mostly because I feel it makes sense for the kind of projects and clients I tend to work with. Pros and cons ?‍♂️

To be honest, I guess you will be an awesome journalist or a/an writer/author in literature ?

[JeevanisM]

I was reading this article about JAMstack.  Consider a NewMagazine website, a person A would search for articles tagged 'sports' then it should do some DB queries, same time person B would search for article 'politics' then again the DB queries should work. This is conventional CMS work flow. So from the article I understand, JAMstack will generate all kind of possible  DBqueries and save it as a static way for one time only then it will provide the Static HTML . Is my understanding correct ? 

 

Quote

 

JAMstack is faster

Picture a CMS-based solution. For every visitor, the web app would have to generate a number of backend database queries to gather the information needed to generate a web page and send it back to the user.

With a JAMstack app, you serve generated HTML instead of rendering documents live on the server. This ensures faster loading times, reduces security risks and is a solution that is easy to integrate with a CDN.

 

 

[LostKobrakai]

2 hours ago, JeevanisM said:

So from the article I understand, JAMstack will generate all kind of possible  DBqueries and save it as a static way for one time only then it will provide the Static HTML . Is my understanding correct ?

Yes and no. It might pre-compile some pages like e.g. all the category listings of blog posts. But those are not dynamic by something the user requests, but those are added by a developer to be created at buildtime. Say your SSG has access to all your blogposts. It can easily aggregate them by tags and create pages for "/blog/tag/static-site-generator". But it can't precompile a site where a user searched for "Static Site" in a search box and showing results.

[MoritzLost]

@JeevanisM @LostKobrakai That doesn't mean you can't have search, but it would probably be in the form of an external service or a serverless function. Algolia is the go-to solution for client-side search. Basically, you send all your content to their API during the build step, allowing them to index it. Then you use their API or their InstantSearch component to perform searches against their index. The search results then take you to the canonical URL of that content.

[JeevanisM]

thanks for all info - so these SSG seems quit complicated, I will stick with traditional CMS ?

[Peter Falkenberg Brown]

Back in 2005/6, I built a SSG/CMS combination application, based on a Perl Framework that I had written.

The magazines' editors input their stories via a CMS login, and then, when they were done, they clicked a button that sent a special secure command to the server to run a script that generated all of the pages as static HTML files. It generated thousands of pages blazingly quickly.

Having done that, I think ProcessWire with ProCache accomplishes the same thing, since it also writes HTML files.

But... ProcessWire is SO much better than my application ever was, for so many reasons.

ProcessWire with ProCache gives us the best of both worlds.

Peter

 

[Mikie]

Will second https://www.11ty.dev/ as an awesome static site generator, really great product.

For a list of lots of options check https://www.staticgen.com/

Gatsby isn’t really a pure static site generator, it’s more a framework for creating progressive single page app websites with react. It has a heavy reliance on graphql and can handle server side rendering like next / nuxt / sapper.

It would actually be pretty overkill to use gatsby just for a completely static site (ie one that doesn’t use a database of any kind). The power of these frameworks is data is pulled in from one or more sources at build time which is used to programatically create pages / populate content.

This data can come from the file system, from a csv file, but mostly it is stored in a cms. There are lots of “headless cms” out there (I like to think of these as more cms as a service) that you will read about being used with gatsby. The most promising of these in my opinion is https://www.sanity.io/ which is a pretty amazing product.

However there is nothing stopping you from using PW for this. 11ty makes it super easy to grab data from anywhere to use at build time (unlike gatsby where it all has to be ported into its own graphql instance), and if you wanted you could have all your content stored in PW, create some json api endpoints manually or using a module like the graphql one, and use that data to build a flat HTML static site with 11ty that you host on netlify or zeit. Obviously this requires rebuilds when content changes, and doesn’t allow much interactivity, which is where the more complex feature set of gatsby comes in... server side rendering etc.

Another project I am really digging at the moment which I think more meets the topic of this post is https://saber.land/ If you are into vue definitely check it out.

[MoritzLost]

Just a little follow-up to this topic, my new ProcessWire tutorial site processwire.dev (see the discussion thread) is built as a static site, using 11ty. It was super fun to build, and easy to get that coveted 100/100 lighthouse score with ?

I see the following advantages of using a static site generator for this project:

• The big one (at least for me): All the content is under version control! (see the source code here).
• Having the content stored as markdown files also means I could use my regular code editor (VS Code) to seamlessly switch between templating / developent and writing (though of course that only applies to developers). Being able to search all files (i.e. the entire site) was also super useful for correcting common typos and stuff like that.
• The site fits comfortably in the free tier on Netlify, so hosting is completely free for me (except the .dev domain, of course). But since it's a static site there's zero vender lock-in, I could switch to Vercel or any regular webhosting package in a few minutes.
• Having a build step on a linux environment with NodeJS enables all sorts of fun stuff that wouldn't be feasible to do on the fly, especially on shared webhosting packages with a limited environment. For instance, I wrote a fun little script that generates preview images using a special template and a headless browser that takes screenshots programmatically using Puppeteer. See the generated example image below. Not super necessary, but fun ? I published the script on NPM (generate-preview-images) if you want to give it a try, though it's a super alpha version and not really documented yet.

So yeah, I think static site generators are going places. 11ty in particular is pretty cool, though it's kind of barebones at the moment and still missing some features that you already have in ProcessWire.