[Loque]

The only problem I feel this really solves is caching, and for that specific problem, generating static pages may be a (work-aroundy) solution to consider, but in general I don't think static website generators are going to be the next big thing...

When you look at page speed, not much of the slow-down is from servers delivering pages, but browsers having to digest HTML/CSS/IMG/JS

I guess it all depends on what you are trying to achieve. Thanks as always for the article, interesting to see someone taking this with both hands.

[willholloway]

The more important problem it solves is security. Caching can easily be handled by adding something like Cloudflare in front.

What local static site generation with html,js,css pushed to remote server solves is giant problem of insecure code.

> more than 70% of today’s WordPress installations are vulnerable to known exploits (and WordPress powers more than 23% of the web).

I did some consulting for a company that was being destroyed by wordpress installations being hacked. When they first started offering wordpress for a blog option (blogs were not their main offering) the threat profile was different. Fast forward six years and they were getting hacked daily.

I recommended that they move their wordpress blogs to flywheel, and have flywheel manage wordpress for them. It worked and they were able to focus on their main offering, the real reason customers were paying them.

Services like flywheel are one answer to the problem of insecure CMS code. The other, and better in my opinion for a lot of sites is to run the CMS locally, keep the database local, and push the rendered code to the server.

[oneeyedpigeon]

> When you look at page speed, not much of the slow-down is from servers delivering pages, but browsers having to digest HTML/CSS/IMG/JS

I think both can be to blame, although you're right that JS load is becoming more and more of an issue. I used to work on a site that used Joomla and literally hundreds of separate database queries were executed for each page request. That is going to put a huge strain on server-delivery time, and it's unsurprising that this site couldn't handle much of a load before falling over.

Static pages are really so much faster than any dynamically-generated site I've seen. Still, I agree about JS - it's possibly time for a 'back to basics' approach on client-side scripting akin to the static page revolution that has occurred on the server-side. At the very least, I think the 'many scripts, many sources' issue needs to be resolved.

[eterm]

I think you're vastly overestimating how well engineered most SME web-platforms are when you say that the client-side is slower than the server side. There are a huge number of server-side asp.NET webforms/JSP/php sites out there which are far slower server side than client side.

And it's not just legacy code, new applications in 2015 are still using those mostly server side technologies without too much done on the front-end.

[UK-AL]

And thank god, these new js heavy frontends really hammer the performance of browsers and are often buggy.

[pjmlp]

Given that the browser should be about interactive documents, that is how it should be.