| > For instance, a major selling point of Node was running JS on both the client and server so you can write the code once. (I'm not actually arguing with you, just thinking out loud) This is often repeated but I don't think it even close to a primary reason. The primary reason you build JS web clients is for the same reason you build any client: the client owns the whole client app state and experience. It's only a fluke of the web that "MPA" even means anything. While it obviously has its benefits, we take for granted how weird it is for a server to send UI over the wire. I don't see why it would be the default to build things that way except for habit. It makes more sense to look at MPA as a certain flavor of optimization and trade-offs imo which is why defaulting to MPA vs SPA never made sense now that SPA client tooling has come such a long way. For example, SPA gives you the ability to write your JS web client the same way you build any other client instead of this weird thing where a server sends an initial UI state over the wire and then you add JS to "hydrate" it, and then ensuring the server and client UIs are synchronized. Htmx has similar downsides of MPAs since you need to be sure that every server endpoint sends an html fragment that syncs up to the rest of the client UI assumptions. Something as simple as changing a div's class name might incur html changes across many html-sending api endpoints. Anyways, client development is hard. Turns out nothing was a panacea and it's all just trade-offs. |