[jamiesonbecker]

It's simply a matter of inversion. Is the page generation and publication performed upon each change (by editors/authors/etc) or upon each access? Obviously, the former is much more efficient, even for frequent changes, and even across millions of data points. (Just ask Twitter).

Just because we don't really have common, enterprise-grade authoring tools for non-technical people that publish static sites anymore doesn't mean that it's not the better way.

[Retric]

Sure we do, it's called caching.

There is a minimal difference between a webserver serving static pages and a caching server serving static content. When you get down to it caching is simply a more flexable approach to the classic (autoring tool) -> static webpage approach. In many ways the only difference is the authoring tool is a website not a stand alone program.

[icebraining]

Caching is usually done on demand, though, not ahead of time. That means the dynamic portion is still launched by the request, which increases the probability of security flaws being exploited.

[jamiesonbecker]

Exactly.

In other words, some fraction of the requests are responded to dynamically and then the result is cached. That dynamic nature can be exploited. Site search engines, etc, are also often (but not always) dynamic, server-generated results that have a greater likelihood of exploits via XSS, CSRF, SQL Injection, etc. Login forms almost always require server interaction and are great targets.

(I say "almost" because REST interactions might be stateless and thus login forms really just serve to generate an access token and verify that it's working; this is how Userify works, for instance. It's still theoretically more exploitable than pure static files, but it raises the bar quite a bit.)