3 ms·

> Dynamic content management systems are a convenience for the developer/maintainer It isn't harder to call a script that regenerates the static files. It is

by tjoff 7y ago

> Dynamic content management systems are a convenience for the developer/maintainer It isn't harder to call a script that regenerates the static files. It is just that dynamic content management systems are more common.

toyg 7y ago
It’s harder to scale it properly over time, because every new post takes longer to regenerate aggregated pages. Obviously this can be somewhat lightened with some hard choices (e.g. only have aggregated pages by fixed period), but it is a tradeoff that dynamic sites typically don’t have to worry about. Anybody who was around during the first blogwave in the early 2000s knows the score: after a while, with static generators you end up waiting a lot after hitting “publish”. And god help you when you change the template over the whole site. Of course, dynamic systems have their own tradeoffs, but they tend to scale better by volume content. You can then slap a simple cache in front and be done with it until views get in the hundred millions.
- the_duke 7y ago
  Just think of the immense amount of work a compiler is doing to compile a decently sized C++ or Rust binary. If there was a need for it, static site generators could be scaled to tens or hundreds of thousands of pages and still finish in a few seconds. Caching partial results is always an option. There are generators that are decently performant, like Hugo (Go) [1] or Zola (Rust) [2]. [1] https://gohugo.io/ https://gohugo.io/ [2] https://github.com/getzola/zola https://github.com/getzola/zola
- AndrewStephens 7y ago
  You are not wrong but it hardly matters for most blogs/product web sites. For example, I generate my blog from markdown with a custom generator written in not-very-optomised Python. There are about 400 pages currently and it only takes about 2 seconds on a 6 year old MacBook to completely build the entire site. Even if I write another 1000 blog posts each year, generating the site will still take less than a minute for the foreseeable future. Paying the cost of building the pages up front like this is still much better than having my users pay it by waiting 10s of seconds from the page to slowly be dredged out of a database. There are sites that do have tens of thousands of pages, and perhaps a content management system is appropriate for them. Horses for courses and all that.

by tjoff 7y ago

toyg 7y ago

It’s harder to scale it properly over time, because every new post takes longer to regenerate aggregated pages. Obviously this can be somewhat lightened with some hard choices (e.g. only have aggregated pages by fixed period), but it is a tradeoff that dynamic sites typically don’t have to worry about. Anybody who was around during the first blogwave in the early 2000s knows the score: after a while, with static generators you end up waiting a lot after hitting “publish”. And god help you when you change the template over the whole site. Of course, dynamic systems have their own tradeoffs, but they tend to scale better by volume content. You can then slap a simple cache in front and be done with it until views get in the hundred millions.

the_duke 7y ago
Just think of the immense amount of work a compiler is doing to compile a decently sized C++ or Rust binary. If there was a need for it, static site generators could be scaled to tens or hundreds of thousands of pages and still finish in a few seconds. Caching partial results is always an option. There are generators that are decently performant, like Hugo (Go) [1] or Zola (Rust) [2]. [1] https://gohugo.io/ https://gohugo.io/ [2] https://github.com/getzola/zola https://github.com/getzola/zola
AndrewStephens 7y ago
You are not wrong but it hardly matters for most blogs/product web sites. For example, I generate my blog from markdown with a custom generator written in not-very-optomised Python. There are about 400 pages currently and it only takes about 2 seconds on a 6 year old MacBook to completely build the entire site. Even if I write another 1000 blog posts each year, generating the site will still take less than a minute for the foreseeable future. Paying the cost of building the pages up front like this is still much better than having my users pay it by waiting 10s of seconds from the page to slowly be dredged out of a database. There are sites that do have tens of thousands of pages, and perhaps a content management system is appropriate for them. Horses for courses and all that.