E.g. nothing will ever beat a dumb file server with a cdn in front when it comes to simplicity and scalability.
And how much skill you have to not mess up basic browser functionality.
As a reference point, GitHub still breaks the back button for me like 40% of times when I'm navigating their source code (me using Chrome on OSX because I only need to do this on my work laptop). I don't even know how they manage to do this.
In my experience, sites that generate HTML server-side tend to feel faster and more reliable than anything that depends on rendering client-side. Loading a booru with 50+ images per page with a cold cache in my browser, always feels quicker and more pleasant than loading text-only GitHub pages that should already be cached everywhere and haven't been modified for days.
You might want to store user-submitted content in a database, for example. Or you might want to do authentication. You might want to provide full-text search in a multi-gigabyte dataset. You might want to provide an interface to something which can't be accessed from a web browser. You might want to validate user-provided input.
All of those require custom code running on a server. So now you have to take whatever data you have on the server, translate it into a well-defined custom transfer protocol, send it to the client, translate it back, and finally turn it into html. And the same for the other direction, but now you suddenly have to do input validation on both the client and the server to prevent anyone creating a custom client from doing anything malicious.
Or you can just turn it directly into html on the server and be done with it. It's a lot less work, and provides basically the same experience for most applications.
PS: how complicated that is all depends on the library ecosystem IMHO.
If you haven’t used the device integration features of OS X and iOS you are missing out. Cut and paste is very, very useful.
* If you have some secrets that need to stay hidden (e.g. database passwords, API keys, encryption keys, etc) then that needs to be processed by code that lives on your servers. If all your code runs on the client, then there is always the chance for an attacker to discover those secrets.
* It is often easier to present a smaller, limited API to the client to reduce the surface area available to attacks. For example, if you let the client connect directly to your database, you need to make sure that that database is correctly secured, that the correct permissions are there, and that nothing can go wrong. But if you just give them a list of books, or films, or whatever your app does, then it will be harder for them to break through that defence. (And if they do manage that, you should still have the database set up as securely as possible to provide an additional layer of defence.)
* A site often feels more responsive if the initial load is served as one single chunk of ready-to-use data (as opposed to serving the application, showing a loading indicator, making the necessary data fetches, then showing the data). Even if they take the same time the first option often intuitively feels quicker to the user.
* Leading on from that, it can often be quicker to load things up front, just because the server that's responding to the user is probably sitting next to your database and any other servers it needs to talk to. These network calls are also much more reliable in that sort of context. If you push all of the processing to the user, you're going to have to handle the slower and more unreliable calls.
* The server will probably be a much more consistent platform than user browsers. Browsers are a lot better these days, but there are still lots of slight differences that you'll need to be aware of. If you have control of a server, though, you can specify the exact versions of every tool, runtime, etc that you need, and be able to update things more deterministically.
Fwiw, these aren't all true all of the time, and there will be exceptions. I work primarily on frontend applications, and there's a lot of value in a well-designed application that does the majority of work, if not all, in the browser. But this is typically only true for fairly complex web apps, or projects where some amount of rendering has to happen in the browser whatever happens.
Because the generation is done once, and it is darn quick. After that all of the numerous advantages of a static page still applies from a users perspective. The resource use is many orders of magnitude less and the page is much more responsive. The user experience is vastly superior, we haven't cared about that in the last decade.
It was great. Until the webhost took away PHP anyway.
If you use Jekyll as static site generator and GH Pages for hosting, it even works out of the box (eg no GH Action tinkering needed, just flip a switch in the GH project settings)
But arguably, a local static site generator workflow works just as well (convert to html locally and upload those files to web hoster instead).
The only thing you can make use of is the design and the actual content.
Why is that supposed to be better?
Now, for a forum, I’m not sure this is a good idea, unless you have a super fast optimised build process. Even then, the delay in build is not what people expect from a forum. But the OP is not suggesting pulling a 100mb db down into the browser.
I know how static sites work, I run dozens of them for people.
I don't see how using WASM improves the situation any.
One can perfectly store data as JSON or even Markdown itself on separate files but do the templating in the frontend, for example.
Pretty easy and doesn't require downloading 100mb of data.
Especially the ones predating PHP. Also a couple of the most popular open source Perl ones. I remember Matt's wwwboard working like this, for example.
Some of them didn't. But A LOT certain did.