Yet another attempt to rip up the web into extremes. In the option number 2, author is clearly trying to hide an elephant behind a curtain. Complex CMS written

Yet another attempt to rip up the web into extremes. In the option number 2, author is clearly trying to hide an elephant behind a curtain. Complex CMS written in PHP requires a web server, but for a collection of static HTML files this requirement is cleverly skipped? Now when a new post added happens what? #1. You log-in to admin panel and write a post. A row is added to the database, a worker subscribed to the table sends the row via websocket to every active visitor on the site. They download few hundred bytes of data and see the post immediately without needing to refresh their browser. If they refresh, they will get cached version of the app and data instantly, then fill in the missing post from the API. #2. You either use SSG or you generate a new static HTML page by hand, specifically on a device which has a private key for uploading to the server. If you don't choose an SSG, then since Javascript is complex, scary and prohibited, you also change the main feed HTML to include a new post, you timestamp all the new stuff by hand, etc. You upload it to the server via ftp. Great, now new visitors of the main blog feed will see it. Active visitors will see it only if they reload the whole page (hopefully they don't load the cached version). Being professional is not to choose an extreme. Being professional is to solve a problem, and to make the best tradeoffs possible when solving it. There are many different configurations which are somewhat in the middle of extremes provided in the post, and using any of them professionally is about using them right and fitting them to solve an issue. You would expect all normal users, including professionals to distribute normally between your neo-web-luddite static NGINX+HTML+FTP solution and javascriptpunk2033 complex CMS.