Ask HN: Why all websites are not statically generated?
9 comments
If you only did not need to deal with people who are not developers or techies, then perhaps. But words like "Jekyll", "Hugo" and "Lektor" don't mean anything to a lot of people who own and run websites.
A lot of websites are powered by WordPress. Most of the users who run those sites don't even know the difference between Static and Dynamic (I explain this all the time to clients). They don't care. They just want their website to work.
A lot of websites are powered by WordPress. Most of the users who run those sites don't even know the difference between Static and Dynamic (I explain this all the time to clients). They don't care. They just want their website to work.
I tried Pelican for my blog a while back, and the biggest problem was that I'd forget the syntax of the blog file, and the sequence of actions needed to publish it, if I went more than a day between blog posts. Useful for a professional blogger, I suppose, but not for the casual user. Also, quite complex code to understand, debug, and tweak, compared to the elegance and simplicity of a Flask or even (gasp) PHP webpage.
I have thought, recently, about the possible utility of a dynamic-site generator for things like CMS or even ERP. Imagine you are designing an open source ERP to be customized for different companies. Instead of having sensible tables like "customers", "products", "orders", etc., you have these weird higher-level "table" tables to allow different users to customize their own schemas.
Maybe what you could do to simplify this is create a generator that spits out dynamic sites without the overly abstract data model...
I have thought, recently, about the possible utility of a dynamic-site generator for things like CMS or even ERP. Imagine you are designing an open source ERP to be customized for different companies. Instead of having sensible tables like "customers", "products", "orders", etc., you have these weird higher-level "table" tables to allow different users to customize their own schemas.
Maybe what you could do to simplify this is create a generator that spits out dynamic sites without the overly abstract data model...
Imagine you have a news web site with decades of news articles. You add a new article, which changes the "Top articles" section on a side bar. With a static generator, you would need to rebuild every single article, which may take minutes or even longer, using both CPU and disk I/O.
With a dynamic generator, you might maintain a cache of the latest articles somewhere, and stitch it into another cached copy of the newspaper section chrome, and then insert the content. It might be more CPU in total, but the changes are live faster, and the total disk I/O would be much lower.
Also, you'd need more disk space with a static generator.
For most simple sites and blogs, there's no real resource use regenerating the entire site, so you get all the benefits of the static generator, and almost none of the drawbacks.
With a dynamic generator, you might maintain a cache of the latest articles somewhere, and stitch it into another cached copy of the newspaper section chrome, and then insert the content. It might be more CPU in total, but the changes are live faster, and the total disk I/O would be much lower.
Also, you'd need more disk space with a static generator.
For most simple sites and blogs, there's no real resource use regenerating the entire site, so you get all the benefits of the static generator, and almost none of the drawbacks.
I think in general we can classify websites into 3 categories: static sites with no dynamic content, static sites with dynamic content (through, for example, REST API calls), and non-static sites (where the delivered HTML/front-end code is server-generated).
When there is no dynamic content, using a static site tends to make the most sense. For example, a WordPress site with no moving parts (i.e. no comments) can be easily converted into a purely static site, though adding a cache in front achieves basically the same result.
Things get more complicated when a site or app needs dynamic content. Using API calls, the server doesn't need to generate the HTML every time, but performance-wise, you would also need to factor in the additional round-trips performed to fetch the data.
When there is no dynamic content, using a static site tends to make the most sense. For example, a WordPress site with no moving parts (i.e. no comments) can be easily converted into a purely static site, though adding a cache in front achieves basically the same result.
Things get more complicated when a site or app needs dynamic content. Using API calls, the server doesn't need to generate the HTML every time, but performance-wise, you would also need to factor in the additional round-trips performed to fetch the data.
Because data is rarely static.
In the instance where data changes rarely, static output can be cached, but you still need a way to generate the output dynamically.
In the instance where data changes rarely, static output can be cached, but you still need a way to generate the output dynamically.
I'd say it's a mix of laziness and convenience. Unfortunately this results on 3.5 MB pages that take ages to load, and then publishers wonder why the user is blocking scripts and ads...
Just compare the typical process for deploying a Jekyll website vs. the "one-click-installer" most hosting providers have for WordPress.
Most websites are not constantly changing and would benefit from static hosting.
I guess the dynamic page generators are simpler.
You need to change a lot of the static generators for custom solutions. A lot of tinkering is involved.
I guess the dynamic page generators are simpler.
You need to change a lot of the static generators for custom solutions. A lot of tinkering is involved.
Don't statically generated sites save a lot of computational resources?