5 ms·

About static vs. dynamic rendering on the server side, the Movable Type CMS used to do exactly as you suggest and it was difficult to make changes on large site

by firasd 11y ago

About static vs. dynamic rendering on the server side, the Movable Type CMS used to do exactly as you suggest and it was difficult to make changes on large sites. Imagine if you want to change a link on a sidebar and have to re-build every HTML page served by your CMS to do that. Caching dynamic pages is a bit of a “hybrid” system where you can just publish your new sidebar, then clear cache on the first request for each particular changed page. About the client side, the situation is a bit different because the JS is actually third-party software designed to be dropped in and updated easily, so it’s not just an implementation detail. Very few publishers are going to build or host their own server-side analytics or commenting systems…

radicalbyte 11y ago
You can do that async - have the edit experience use the db then a publish action which re-generated the site. As for monitoring/comment systems: using external sites is actually really good for performance. Third party tools do a great job of blocking them and that makes a lot of sites very fast.
userbinator 11y ago
Imagine if you want to change a link on a sidebar and have to re-build every HTML page served by your CMS to do that. On the other hand, doing the processing on the client side means that work would be done every single time by every single client, and the result of that work isn't even preserved. As decades of programmers have had absolutely no problem compiling software with many, many more dependent files than pages on a typical HTML site, I suspect the problem is in the implementation and not the concept. build or host their own server-side analytics or commenting systems I've not written any analytics before so I won't comment on that, but it's funny you mention commenting systems since a simple one (textboard-like) is literally less than a day's work.
- TeMPOraL 11y ago
  > On the other hand, doing the processing on the client side means that work would be done every single time by every single client, and the result of that work isn't even preserved. Exactly! If that amount of work on server seems big, then realize that doing it client-side means dumping a million[0] times more work on the society, with all associated electricity usage. [0] - literally; if you have 100k visitors and each visited you 10 times, that's 1M times the work that should actually have been done.
oneeyedpigeon 11y ago
That's exactly how a site I work on operates. True, changing a link across all pages is a very slow operation (about 50 seconds for 11,000 pages) but a) that's happening in a highly structured and powerful but resource-intensive way (i.e. DOM parsing) b) it happens so rarely that I haven't bothered to optimise it. The main trade-off for an update that happens maybe once every 1-2 months taking 50 seconds is that every single page load is faster. There are other benefits from static files, too - it's much easier to work with content in flat files, 1-per-page, than the kind of complicated database / file / code relationship used by many 'normal' CMSes.

by firasd 11y ago

radicalbyte 11y ago

You can do that async - have the edit experience use the db then a publish action which re-generated the site. As for monitoring/comment systems: using external sites is actually really good for performance. Third party tools do a great job of blocking them and that makes a lot of sites very fast.

userbinator 11y ago

Imagine if you want to change a link on a sidebar and have to re-build every HTML page served by your CMS to do that. On the other hand, doing the processing on the client side means that work would be done every single time by every single client, and the result of that work isn't even preserved. As decades of programmers have had absolutely no problem compiling software with many, many more dependent files than pages on a typical HTML site, I suspect the problem is in the implementation and not the concept. build or host their own server-side analytics or commenting systems I've not written any analytics before so I won't comment on that, but it's funny you mention commenting systems since a simple one (textboard-like) is literally less than a day's work.

TeMPOraL 11y ago
> On the other hand, doing the processing on the client side means that work would be done every single time by every single client, and the result of that work isn't even preserved. Exactly! If that amount of work on server seems big, then realize that doing it client-side means dumping a million[0] times more work on the society, with all associated electricity usage. [0] - literally; if you have 100k visitors and each visited you 10 times, that's 1M times the work that should actually have been done.

oneeyedpigeon 11y ago

That's exactly how a site I work on operates. True, changing a link across all pages is a very slow operation (about 50 seconds for 11,000 pages) but a) that's happening in a highly structured and powerful but resource-intensive way (i.e. DOM parsing) b) it happens so rarely that I haven't bothered to optimise it. The main trade-off for an update that happens maybe once every 1-2 months taking 50 seconds is that every single page load is faster. There are other benefits from static files, too - it's much easier to work with content in flat files, 1-per-page, than the kind of complicated database / file / code relationship used by many 'normal' CMSes.