He just showcases a GitHub bug that Liveview doesn’t have so I guees that ?
Seems like the ususal promotional stuff, like when he posted a lot of arguments about how the virtual dom is pure overhead but then there are plenty of libraries with the same features as svelte but perform better and use vdom.
I would take all of those claims with a grain of salt, the same goes for everything that is happening in the frontend js space. Too much chatter but everyone is reinventing stuff from 2012 or 2014.
The real issue he mentions is latency, but then again this is used when you need the roundtrip to the server anyways so
As he says, it depends on what you build and how you need it to behave. If your app must run even when the network is crap, forget hotwire or liveview. Same when the client logic is complicated, although that would depend on your preferences too.
The Github quirks are interesting because I notice them all the time as well. As you noted, LiveView applications don’t suffer from this kind of thing because we have actual reactive templates backed by state. He is talking broadly about the server rendered approach, so I think in that light his argument is fair since many solutions poke areas of the page with pre-rendered HTML fragments, but I want to make it clear lumping LiveView in with his “fundamentally flawed approach” argument isn’t correct
I like Rich (and Svelte!) however I agree that it probably wasn’t fair to use some of the weakest versions of the tech for the comparison, would have been much more interesting to see his comments comparing the strongest (like LiveView!)
By his own argument a native app should be preferred all the time, because a native app can keep the app state even better.
Each app arch has its sweetspot. In fact, I think svelte has probably the least overlaps with liveview in terms of sweetspot, out of all the possibilities.