I don't understand the benefit ??? This seems like unnecessary overhead for any startup software companies, costing both extra time and money while overloading your server right out the gates. Instead of expecting 100 requests per min from say like 20 users, I can now expect 1000s+ to my server because I'm sending every keystroke to the server ??? That means I'll need a super expensive instance to handle all those us…
The future of web software is HTML over WebSockets
261–270 of 337 posts
Re: The future of web software is HTML over WebSockets
#262Earlier quoted context omitted.
Could you explain why that is to someone (me) has never done anything nontrivial with it? Thanks.
i'd encourage everyone thinking about using it to go read the code (it's fairly approachable) but in short it just connects each node in the cluster to each other node in the cluster via a tcp connection and sends packets between them. there's almost nothing as far as protocol, queue management, congestion control or traffic management. it's discovery mechanism is just shipping lists of peers around. pretty much any…
Re: The future of web software is HTML over WebSockets
#263Earlier quoted context omitted.
>In essence, I am building a DIY database such that people connect directly to the database and get that sweet giant JSON object along with a stream of updates Isn't that Firebase DB?
Yeah, that was my reaction to a lot of the discussion on this article. Firebase Realtime DB has been one of the most amazing pieces of software I've used. I don't have to worry about the connection details at all, I just have this data store that feels like a local DB except it's "magically" synced with the server, and any other users of the DB "magically" get updates when I change it.
Re: The future of web software is HTML over WebSockets
#264This seems like X Windows protocol over HTTPS with JSON as the wire encoding. It's sad to think how much effort is spent reimplementing technologies because the IPv4 address space wasn't large enough. If IP address space were larger, we wouldn't have needed to rely on Network Address Translation (NAT). NAT became a poor-man's firewall and effectively blocked peer-to-peer connections making it difficult to host a serv…
HTTP is successful partly because it's simple and "stateless", in the sense that all protocol state is held by the client in cookies. Keeping all state in cookies+database provides some useful properties, in particular around scaling, being unfazed by IP address changes (e.g. wifi to wired), reboots of both clients and servers, version changes, hibernation/wake-from-sleep, and a variety of other things that otherwise break connection oriented protocols.
Of course sometimes people screw that up in other ways, hence the popularity of "clear your cookies" as a troubleshooting tip. But overall it works pretty well. Look at the prevalence of hacks on top of SSH to create persistent sessions, to see what has to be done when you don't have that model. SSH only survives as a protocol because remote administration doesn't need to be a particularly great user experience and it doesn't need to scale, so legacy and inertia wins out. Otherwise we'd probably see a request/response protocol take over there too.
X11 was always a PITA not only due to NAT but also due to institutional firewalls, e.g. universities often have enough IPs to give everyone a public IP but firewall traffic anyway to stop exploitation of vulnerable devices. So the whole "remote client connects to local server" model was not only confusing but also a poor fit for the real world internet in which centralised, professionally run servers are invariably more secure than scattered non-professionally run edge devices.
Re: The future of web software is HTML over WebSockets
#265Simply put a client-side SPA is much cheaper to run than almost anything else because you're pushing as much computation as possible onto the client where you don't pay for it. You just need a good static host with a CDN like Netlify, Firebase, etc which is nearly free (for small sites, completely free).
Developers who have tried this are not keen to go back to paying for servers to do this computation. Big companies can and will pay for this cost to improve user experience (see: Next.js popularity) but I just think a lot of solo hackers will shy away from it and that will affect momentum.
This isn't really a critique of the technique one way or the other, just a prediction of how far the trend can go.
Re: The future of web software is HTML over WebSockets
#266Please don't let us come back to Rails
Re: The future of web software is HTML over WebSockets
#267Re: The future of web software is HTML over WebSockets
#268Earlier quoted context omitted.
I think ultimately Phoenix and by extension LV just don't have the manpower. LiveWire builds on Laravel which is a massively popular framework on a massively popular language, Laravel itself using components from Symfony that is basically the backend framework with the most contributors in the world. But LiveView may hit 1.0 this year :)
> I think ultimately Phoenix and by extension LV just don't have the manpower. For comparison's sake: - [LivewWire] Caleb (creator of LiveWire) made 1,000+ commits and added 200k lines of code from Jan 2019 to Feb 2021 - [LiveView] Chris (creator of LV) made 700+ commits and added 80k lines of code from Oct 2018 to Feb 2021 - [LiveView] Jose (creator of Elixir) made 450+ commits and added 25k lines of code from Oct 2…
Maybe Chris and Jose are more efficient? Maybe the Elixir/LiveView code is just better written and doesn't need rewrites?
Why do so many people glorify quantity over quality?
Re: The future of web software is HTML over WebSockets
#269I don't quite buy it. Go with Rails if you like Ruby, Rspec, rapid development and the nice ecosystem around it. Most Rails apps are CRUD and don't really need streaming with websockets. Rails with stimulus is more than enough to create a good user experience, I don't see why you need to add the complexity of websockets.
Turbo is actually a rather simple way of achieving this with rails https://turbo.hotwire.dev/handbook/streams
Which is something that would be very clunky for stimulus
Re: The future of web software is HTML over WebSockets
#270Various forms of server-side rendering for JavaScript-heavy webapps are definitely picking up steam, but I don't see how they will gain popularity among the long tail of web developers because of one thing: cost. Simply put a client-side SPA is much cheaper to run than almost anything else because you're pushing as much computation as possible onto the client where you don't pay for it. You just need a good static ho…
I also feel there is something to ownership of your tools and platform, and an application strung across several SaaS and a toolset that requires phoning out to different SaaS in order to work is anything but yours.