3 ms·

Ask HN: Why all websites are not statically generated?

• minimaxir 10y ago
  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.
• unfathomable 10y ago
  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.
• codegeek 10y ago
  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.
• Raed667 10y ago
  Just compare the typical process for deploying a Jekyll website vs. the "one-click-installer" most hosting providers have for WordPress.
• frou_dh 10y ago
  Put a cache in front of a dynamically generated page and you have a static page again. Now... when should the cache expire?
  • jazoom 10y ago
    Manually or automatically upon update of the website?
• alfredxing 10y ago
  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.
• nbm 10y ago
  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.
• joeclark77 10y ago
  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...
• sogen 10y ago
  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...