4 ms·
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 t
by 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 agoBut 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 agoYes, 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 agoI 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.