I feel like independent thought will decrease considerably with LLMs. I wonder if they will effectively become oracles in the sense that the average output of an LLM will be what most companies do therefore you can predict what most companies will do.
Is it slow though? Like in practice? This demo [1] using Datastar (a streaming HTML framework) every action including scrolling roundtrips to the server. Even the checkboxes changing colour is a roundtrip.
every action including scrolling roundtrips to the server
As soon as you include a network roundtrip in anything you're opening up a Pandora's box of slow connections, slow DNS queries, network outages, what-if-the-user-is-on-a-train problems, what-if-their-IP-changes-mid-flow problems, etc.
Reducing the network calls in any app has upsides and downsides. It isn't really true that SPAs are faster to render (as your example proves) but rendering speed isn't the only thing that matters.
It baffles me people can write software like this.... Surely it's the most basic tenet of webpages is that it's all sent over the network and the network lags and drops packets.
The advantage of SPAs, like the checkboxes page, is that they can do the round-trip less visibly. The user can still continue the next thing. So even if it is slow, it's less of a deal than loading and rendering a page anew.
> Is it slow though? Like in practice?
The multi-page wizards? The ones I've seen were. Enterprise crap systems.
You don't even need your backend that close if your server is fast enough. Streaming HTML immediate mode is pretty good. See this demo (server is in Germany and runs on a potato uses no optimistic updates, eveb scroll round trips) [1]
Honestly client side animations go a long way to masking latency too.
Sync engines are fast to a point but if you start working with large enough datasets and/or care about security you ultimately end up with something closer to streaming immediate mode HTML. Of course that means sacrificing local first.
whats the security problem here? all mutations go through the server authority and clients can only load data they have access to. the only thing i see is users being able to read cached versions of private content that was accidentally set to public then private again, and if that happens to you something is wrong with your access controls. and its also not a big deal for most organizations.
User permission can often be very dynamic. Sync engines (local first ones even more so) give them access to a much larger set if that data in a client side database.
This also makes them much more vulnerable to a data leak/breach if their device gets compromised or stolen as the data is all on their device.
The client having access to only what it needs in terms of data and making that as ephemeral as possible is a big part of defence in depth.
Although not as prominent as insert SELECT and UPDATE both benefit from page cache locality, assuming rows that are stored near each other are often selected/updated together.
An insignificant amount for the comparison (why I didn't mention it), it's a fast implementation and the JVM C2 JIT has kicked in by the time the first batch has completed.
reply