No, this is a terrible idea that is being spread like a cancer by people who don't know their history.
First of all, static rendering CMS-es are IN NO WAY missing as you say; in fact, as your own comment hints, such systems are incredibly abundant. There are MANY other static-render-HTML products that could be added to that list, and they stretch back into the 1990s.
The basic problem with this approach is well understood: As the corpus of content on a given site grows, render time quickly approaches time between updates. In other words, you start waiting for renders to complete before you can change something else on the site.
This happens in part because changes to a single particular piece of content often cause changes to multiple pages — think blog views, archive pages, index pages, tag pages, RSS feeds. Meanwhile, as a site grows, the number of contributors tends to grow, including authors, editors, illustrators, photographers. So not only are the static renders taking longer as the site grows, there is also a growing likelihood that someone will want to touch a piece of content in a given time period, thus triggering a new render.
Probably the most high-profile example of how this could fail was when there were a lot of people using Movable Type for their blogs in the early 2000s; MT did static renders and many bigger blogs had switch to other blog engines or carefully operate around massive render times for MT sites.
If you have a small personal site, static renders are fine. But SO IS BASICALLY EVERYTHING ELSE. You can build a personal site using any number of primitive-but-effective technologies, like server side includes, emacs macros — hell you could literally make a Microsoft Word template and publish everything from there via SFTP. On the flipside, you could install the most inefficient, computationally intensive, database driven crapfest of a web app and it won't matter because you don't need to scale.
In other words, static CMSes are fine if you don't actually really need a CMS. By all means, for yourself, or a tiny project, use whatever you want. But we don't need MORE of those tools.
I don't think anyone is claiming that a static CMS would be a "good idea" for people who have a multitude of pages that are constantly changing, that is of course, madness.
There are a huge number of websites (ie: like every small business website I have ever been to) that have like 5-10 pages tops and they almost never change. For all intents and purposes, they are static. Throwing such sites up on github or s3 is a no brainer. I disagree with your statement that we don't need MORE of those tools. We absolutely need more of those tools, but not for developers (there are literally a million to choose from if you are a developer), what we need are nice clean user-friendly front ends. Every time I have to enable javascript just to visit some Wix website I cringe a little.
There are plugins for Wordpress that will bake the front end of the site in to static HTML and push it up to an S3 bucket for hosting. Seems like a decent solution to me.
On HN you are generally expected to 'get started', rather than insulting projects like that without expanding.
I would actually say, though I vastly prefer say Jekyll over WordPress, that generating a static site from a WordPress site probably works pretty well and gets you a very mature CMS UI for your users.
Doing it that way round is probably preferable and better understood at this point than the newer solutions that are trying to bolt CMS backends onto Jekyll sites (CodeCannon, Prose.io etc).
Fair enough, I half expected to get called out. My original comment suggested that what was needed (particularly for non-developers) was a "nice clean user-friendly front end". Wordpress, although incredibly popular, is IMHO, a usability nightmare and does not fit the bill. It is one of the least intuitive pieces of software I have ever used. I have recently spent some time searching twitter for people having problems with wordpress, and I know i'm not alone.
In any case, for the websites I am talking about (small non-technical businesses in particular), wordpress is overkill and operates at a higher layer of abstraction then necessary. Also, such a solution has almost all the disadvantages of wordpress (Finding wordpress hosting [These guys are not going to have their own on-premise wordpress install], setting up and configuring wordpress, keeping wordpress and plugins up-to-date), for very little advantage (slightly more consistent load times? ). Just putting a CDN in front of it would get you most of the way there.
It's also hard to recommend a good wordpress host [The exception to this is sandstorm, which is amazing and does the wordpress->static thing exactly right]. Managed wordpress is what you want, but it's bloody expensive (again, IMO, but these kinds of customers are generally cheap). Anything more hands-on than fully manged hosting is a lot of work and maintenance for something these people are realistically NOT going to use on a daily basis.
I think Wix and Squarespace serve a very much needed part of the market, and I wish I could point people at an elegant open source solution that would allow "normal" people to have affordable websites backed by S3 or Github pages (like us developers enjoy).
> The basic problem with this approach is well understood: As the corpus of content on a given site grows, render time quickly approaches time between updates. In other words, you start waiting for renders to complete before you can change something else on the site.
Is this limit still likely (honest question)? Hugo seems to benchmark at around 1ms/page.
What sort of scale is common for large sites, what speed would need to be hit for this to become a problem that's simply irrelevant at even the largest scales?
You're assuming that a site's traffic and content change rate grow at the same (or similar) rates. This is almost always true of media properties, but not necessarily of popular single-contributor blogs or brochureware for business, organizations, political campaigns, etc. Many of those are powered by WordPress or Drupal, but they could exist as static sites, as their traffic level is not correlated with their rate of change.
>* The basic problem with this approach is well understood: As the corpus of content on a given site grows, render time quickly approaches time between updates. In other words, you start waiting for renders to complete before you can change something else on the site.*
Only on naive systems -- or if you change the design and layout of the whole site.
Besides, for 99% of websites that are not news or forum sites, the content never grows that much. And for brochure style sites, it's at most a few 10s of pages per year.
>Meanwhile, as a site grows, the number of contributors tends to grow, including authors, editors, illustrators, photographers.
That never happens for 99% of sites -- that could still use static rendering.
So not only are the static renders taking longer as the site grows, there is also a growing likelihood that someone will want to touch a piece of content in a given time period, thus triggering a new render.
>On the flipside, you could install the most inefficient, computationally intensive, database driven crapfest of a web app and it won't matter because you don't need to scale.
Is speed really an issue today though? With multiple cores, multiple machines etc.. Seems like a simple enough engineering problem. How many "pages" does a big site have? How many can be touched by a single update?
Also see Hugo, as someone mentioned..
Not doubting that you're right regardign the history, just that it has to be this way today. OTOH, a dynamic page can also be plenty fast, it does not have to be Wordpress.
The small answer is that rendering touches not just CPU but storage as well. Yes we have SSDs, which help, but writing to "disk" is still relatively slow.
The big answer is: If you can render each of your pages very quickly, there's no real win from pre-rendering everything. You should just render on the fly. The whole point of pre-rendering, historically at least, is to make a site very fast by eating the cost of the render up front.
But from that storage "problem" you get to avoid hosting on a dynamic platform, and literally just need a static web host. As mentioned you can put stuff up on s3 and be done with it.
At large scale of visitors, this kind of approach is a lot easier to handle than the dynamic model.
You could also get a static website generator to output e.g. PHP or HTML files with 99.99% static content and includes/SSI for commonly shared content.
This way few or no pages need to change just because the shard content (e.g. a "latest posts" box) changes when a new post is added.
And you still get the speed of serving, security, AND simplicity and easy hostability of merely serving static files.
How large does a site need to be before render time becomes a significant issue? I can understand it being an issue for, say, Google News or some other highly dynamic site where the input sources are programmatic. But for sites where there are humans providing the content, why in today's computing era would it take more than a minute to update hundreds of pages?
First of all, static rendering CMS-es are IN NO WAY missing as you say; in fact, as your own comment hints, such systems are incredibly abundant. There are MANY other static-render-HTML products that could be added to that list, and they stretch back into the 1990s.
The basic problem with this approach is well understood: As the corpus of content on a given site grows, render time quickly approaches time between updates. In other words, you start waiting for renders to complete before you can change something else on the site.
This happens in part because changes to a single particular piece of content often cause changes to multiple pages — think blog views, archive pages, index pages, tag pages, RSS feeds. Meanwhile, as a site grows, the number of contributors tends to grow, including authors, editors, illustrators, photographers. So not only are the static renders taking longer as the site grows, there is also a growing likelihood that someone will want to touch a piece of content in a given time period, thus triggering a new render.
Probably the most high-profile example of how this could fail was when there were a lot of people using Movable Type for their blogs in the early 2000s; MT did static renders and many bigger blogs had switch to other blog engines or carefully operate around massive render times for MT sites.
If you have a small personal site, static renders are fine. But SO IS BASICALLY EVERYTHING ELSE. You can build a personal site using any number of primitive-but-effective technologies, like server side includes, emacs macros — hell you could literally make a Microsoft Word template and publish everything from there via SFTP. On the flipside, you could install the most inefficient, computationally intensive, database driven crapfest of a web app and it won't matter because you don't need to scale.
In other words, static CMSes are fine if you don't actually really need a CMS. By all means, for yourself, or a tiny project, use whatever you want. But we don't need MORE of those tools.