Yeah. I've done the server-side thing quite a lot. I don't like it. You always end up with "little bits" of javascript code strewn about in your DOM doing adhoc manipulations based on user events, server data arriving etc., and so the actual behaviour of your app is more difficult to reason about. Also, I want my users to have a nice experience and enjoy using the app, even if I don't have a KPI to represent that benefit. And until quite recently that was much easier to do in a modern SPA framework. I think the newer hybrid approaches like Phoenix LiveView give you the best of both worlds though.
I don't follow this logic. Why do you end up with JS strewn everywhere? Sounds like poor organization practices.
1. User arrives at a page where a real-time widget may exist. <src> widgets/mywidget.js on that page.
2. User triggers mywidget.js by pressing a button or just existing. It dynamically creates the widget elements, requests a secure websocket, then sets up input/output handlers.
3. Done.
mywidget.js could be big and sophisticated -- a multiplayer video game, for instance -- but it is certainly not "strewn everywhere".
I'm not talking about how my javascript source files are organized, I'm talking about how the functions are dispatched from the UI. That is done with event listeners strewn about in the DOM.
If you are referring to "the page is the widget" then you need to make a very good case why wrapping all the HTML in JS is in your interest. Facebook has an interest in doing this because they want to wrap every element in a bit of JS so they can closely track user behavior. Briefly hovering over a link, button or ad? Facebook wants to know everything about that interaction, in order to provide value to their clients (i.e. advertisers).
A normal developer is happy with that element just being a `<a>` or `<input>`. The entire page does not need to be a JS widget (SPA).
