3 ms·

Although I take your point that people do a lot of needless computation these days, I don't quite understand the dig at caching. Isn't adding an HTML file to yo

• dpezely 15y ago
  Serving static files is more about pre-processing, or rather: Don't do at run-time what can be done at compile-time. This doesn't need to be any more manual that the labor involved in uploading content into a CMS or data store by another name (e.g., blog engine). It's more of a substitution of one task for another. I prefer to think of the static HTML approach as the difference between using Makefiles versus a shell script for compiling code. Once you understand that the shell script will duplicate nuances that 'make' offers, use of Makefiles for compiling code usually gets viewed as the better approach. (There are always edge-cases, of course.)
  • chc 15y ago
    But what I'm saying is, doesn't caching accomplish essentially the same thing? You process the resource once, cache the result and serve that. Full static site generation just seems like a more aggressive version of the same thing, and AFAIK you have to give up some of the benefits of being partially dynamic (like the ability to do have a "Latest comments" sidebar without unnecessarily relying on JavaScript).
    • dpezely 15y ago
      Yes, end results are equivalent, but complexity shifts. If a consistent stack is more important, caching may be the best option. If fewer layers of complexity at run-time is more important, out-of-band/pre-processing may be the best option.
    • efsavage 15y ago
      I think there's a semantic hangup here, what you're describing is accurate, but it probably "better" explained (in the case of something like the popular wordpress caching plugins) as "compiling" your content to flat HTML which is saved on disk. The web server/CDN can then "cache" that file.
• jasonkester 15y ago
  Pretty much. Only chances are it's not actually manual, either. The way I do this for the CMS/Blog stuff on my products is to set up a 404 handler that looks for urls that seem like they should be blog entries. So if it sees a request for the non-existant http://mysite.com/blog/caching_is_awesome.html http://mysite.com/blog/caching_is_awesome.html, it'll do a quick check for that article in the database, and if necessary create the static .html file before redirecting to it. It's a little nicer than caching because you only need ever lookup/create the thing once each time it changes. From there, it's just the webserver being a webserver. No need to involve any application layer at all.
  • danneu 15y ago
    Even a minimal blog written in Rails can cache to .html files with a page caching line in the PostsController and some lines for expiration when new posts are created/updated/destroyed.
  • crdoconnor 15y ago
    Why not go the whole way and only edit/serve up the static file instead of the database entry? That has the added benefit that you can use version control on it.
  • philwelch 15y ago
    > The way I do this for the CMS/Blog stuff on my products is to set up a 404 handler that looks for urls that seem like they should be blog entries. So if it sees a request for the non-existant http://mysite.com/blog/caching_is_awesome.html http://mysite.com/blog/caching_is_awesome.html, it'll do a quick check for that article in the database, and if necessary create the static .html file before redirecting to it. You have done the webserver equivalent of method_missing trickery in Ruby.