Live data from Hacker News

The future of web software is HTML over WebSockets

alistapart.com

111–120 of 337 posts

Re: The future of web software is HTML over WebSockets

#111
Wrangling with JSON?

Not sure about React, but with Angular and tools like gRPC you don't see a single byte of JSON and the code that interacts with the APIs is automatically generated at compile-time and is type safe (with intellisense too!)

It is pretty effortless these days IME. You can't make a mistake with the coding side of things calling an API as the actual mechanics is seamlessly hidden away - mistakes can only be made in the "business" side of things (and this HTML-approach won't save you there...)

If you are using an "in house" framework (or just something ancient/niche like rails) then perhaps you don't benefit as much from modern bug-resistant frameworks and tooling I guess... In which case you're probably going to make more gains just by using a mainstream framework rather than trying something new/unusual/untested(?) like this.

Good luck anyway!

Re: The future of web software is HTML over WebSockets

#112

This 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…

Couldn’t agree more

Re: The future of web software is HTML over WebSockets

#113
post #77

Earlier quoted context omitted.

But LV is still in its infancy and there are very real implications of using websockets that are unrelated to open connections. Just the other day someone posted on the Elixir forums about live_redirect causing 2 network round trip connections[0]. Basically there was double the latency to transition between pages due to this "bug". I air quoted "bug" because it's working as intended, it's just not optimal. The creato…

When did you last use it? Javascript hook support wasn't there early on. The state of the art is the "PETAL StacK" [1] which uses client-side JS for interactions that don't require a roundtrip [1] https://thinkingelixir.com/petal-stack-in-elixir/

> When did you last use it?

I gave it a fair shake a few times.

Once when it first came out, then again a year later and then again 6 months ago.

Lack of hooks wasn't a concern I had at the time. It was more around core behavior of the library and critical features that were missing. Some of those features have been added after I posted about them but all that did was destroy any confidence I had in using LV because these are things that would have been encountered on day 1 of deploying a single LV app to production. We're talking huge things, like how to invalidate and update assets in the of your page in a user friendly way.

It left an impression on me that LV isn't really being used much in real world apps by the team developing it. I could be wrong of course but that's the impression it left. Plus it feels like it's taking a really long time for certain features to make their way into the library. For example file uploads took something like 18 months to go from being talked about publicly to getting an alpha release and now it feels like it's on the burden of the community to test this in production without really knowing much about the feature.

That and the docs still leave a lot to be desired (especially around the time I read them) and the story for the last ~18 months is that since LV is a pre 1.0 release the docs aren't really written up yet since stuff is changing all the time. I know docs take a long time to write (I've written literally over a million words of blog posts / course notes / documentation) but docs and practical examples are also the most important thing IMO to nudge folks into using something.

Personally I don't want to have to read minimal docs, API specs and dive into the source code that I can't read very well because there's a lot of macros to see how something works just to use it effectively. Especially if I'm on the front lines of having to pioneer the tech, which means I'll probably be under pressure to report and fix bugs that I don't know how to fix.

I don't know. All of this experience with LV and Elixir / Phoenix really made me understand that this tech stack is not for me. Especially not when Hotwire Turbo exists and works with any back-end language and it also has proof of it being used in a mission critical massive SAAS application (https://hey.com). That leaves me super confident that it'll work for me (and it has been), even outside of Rails.

Maybe in 5+ years I'll try Elixir again (hopefully Stripe and other payment providers have Elixir clients by then!), because the core Elixir eco-system in general has a bunch of nice things. It just doesn't feel optimized yet for building applications (IMO). At least not compared to most other web frameworks.

Also, while I don't use Laravel I also have major respect for Caleb Porzio. He created Laravel's version of Live View (LiveWire)[0] by himself. It mainly uses HTTP and he also has a ton of docs / videos on implementing practical application features with it. He shipped 2 major versions and everything about its API and docs just oozes creating something made for developers to develop applications. It's funny how a slightly different position on something can make something explode in popularity.

I haven't even written a single line of Laravel and have no intention on switching to it, but his presentation and execution of an open source library is something I admire.

[0]: https://laravel-livewire.com/

Re: The future of web software is HTML over WebSockets

#114
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 users and this is in the extremely conservative use-case of 20 users at once.

No thanks.

Re: The future of web software is HTML over WebSockets

#116

Earlier quoted context omitted.

As a thought exercise; - What happens if the client’s internet connection temporarily drops? How do you handle client reconnections and retries? - What if the remote server crashes through no fault of your own (AWS server rack catches fire)? How do you ensure a consistent reconnection that preserves application state? These are just two questions that HTTP + Browsers solved decades ago. Websockets are this cool techn…

Here's another one. How do you deploy a new version of your service? Imagine a few customers open up your site and leave for lunch. Or maybe just a random crawler or bot sitting watching for some piece of information they are scraping. These sorts of issues can be challenging with stateless connections. I can only imagine how daunting they are with persistent connections.

it is called hot-reload.

Re: The future of web software is HTML over WebSockets

#118
post #83

Earlier quoted context omitted.

I feel like websockets get waaay too much hype and attention compared to SSE, especially for use cases that are barely interactive at all.

Future-proofing is a good use case though. As a developer I don't want to maintain both SSE and WebSockets, since they solve similar problems and WebSockets are a superset of SSE. Even though my WebSockets implementation is currently unidirectional (server to client), I still opted for that over SSE because I'll probably need send data the other way at some point in the future. Why learn two tools when I can just lea…

What's wrong with normal HTTP requests for client->server streams? You get the added bonus of being able to dump them to a curl command for debugging.

Re: The future of web software is HTML over WebSockets

#119
post #83

I used to love WebSockets a lot more. At some point I got deeper into implementing HTTP servers and proxies, and realized how much of a special case WebSockets are to implement. They're cool, but I prefer Server-Sent Events on HTTP/2 whenever I can get away with it, which is pretty much always (binary data being a big exception, and even then I consider long-polling first). I think there's value in keeping our protoc…

I feel like websockets get waaay too much hype and attention compared to SSE, especially for use cases that are barely interactive at all.

Sadly it's not entirely unfounded. SSE on HTTP/1.1 is basically useless due to the connections-per-domain limits implemented in browsers. So WebSockets got a lot of mindshare while we waited for HTTP/2.

But today I always start with plain HTTP, then try SSE, and finally WebSockets if I have to.

Re: The future of web software is HTML over WebSockets

#120

I’m gonna be “that jerk on HN,” but this is that idea that just keeps getting rehashed every couple of years then fizzles out. The reason that it’s so attractive is because as developers we love to build and save time, and we think, “imagine what we could do if we didn’t have to ask for data from remote servers...” The problem is that stateful connections suck and create artificial complexity when you don’t need them…

> The problem is that stateful connections suck and create artificial complexity when you don’t need them. Instead of managing the state of your app you’re now managing the state of your app and a connection to a remote server. HTTP is a stateless protocol on top of a stateful socket connection. It wasn’t designed this way by accident.

Seriously, try phoenix liveview if you haven't already. These problems of dealing with stateful connections over questionable tranport and managing them are what the Erlang vm were designed for, and phoenix was designed by rails core team members.

Post reply on HN