Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The future of web software is HTML over WebSockets

alistapart.com

Post reply on HN
Print view View original

31–40 of 337 posts

Re: The future of web software is HTML over WebSockets

#31

Post by mathgladiator »

vfclists wrote: post #20

More snake oil from the Internet industry as usual. It is almost 30 years since the web came into existence and somehow people harbour this illusion that those who control the standards or are responsible for implementing them are genuinely committed to delivering technology which will help the competition (ie the rest of the world) bypasses their app stores. It makes one wonder whether those who keep blabbing on abo…

They are neither shills nor explicitly stupid, just inexperienced (mostly young people) with a great deal of enthusiasm and energy.

Re: The future of web software is HTML over WebSockets

#32

Post by MentallyRetired »

`The dual approach of marrying a Single Page App with an API service has left many dev teams mired in endless JSON wrangling and state discrepancy bugs across two layers. `

Umm... not it hasn't? Separating the backend from the frontend allows for multiple frontends on multiple types of delivery. Outside of edge workers, how is HTML-over-websockets supposed to compete with a good ol CDN (jamstack) on TTR?

Re: The future of web software is HTML over WebSockets

#33

Post by aeoleonn »

jack_riminton wrote: post #26
aeoleonn wrote: post #6

Another "The future of is what says it is" without much more than a few paragraphs of explanation. No diagrams. I don't see much of a comparison between costs/benefits of alternatives. Nice hypothetical. I didn't read it, because I've seen the format before and I'm getting a bit bored of it. Whereas if it cited some other engineers/technologists, some studies, some academics, etc., then perhaps I'd be more inclined t…

Well, it is an opinion piece

Clearly I arrive at this piece without the expectation of it defining the future-- I know better than to expect a pop tech piece to deliver to me a view of the future.

format: blatantly unoriginal

content: not persuasive, underdeveloped

effort: very low

value: very low

"The future of" is a very bold statement. The more cliche it becomes, the more I expect an author to actually outline, in a bold, cohesive, relatively comprehensive way, their theory.

Otherwise stop trying to tell people what the future will be-- it's a waste of time & attention.

Sure, the headline is catchy. The rest seems like the author was simply trying to reach a certain word count and claim their cheque.

--> "Future of" articles should read like a graduate academic paper-- give the future of technology the proper respect it deserves.

--> Or, they should be a policy paper.

Not a pop tech piece. Pop writers-- stop with the silliness-- stop appointing yourselves as definers of the future unless you expect folks like myself to come along and bring you back to reality.

____

Take this linked citation for example:

"Fast-forward to 2020 and the web isn’t getting any faster"

It's linked to an article by an individual who has an undergrad degree in psychology, a grad degree in IT, and is a design/UX-related employee. That's not the person I would go to for a technical, knowledgeable analysis of internet speed evolution.

Re: The future of web software is HTML over WebSockets

#34

Post by blacksmith_tb »

burnished wrote: post #19
hinkley wrote: post #10

Earlier quoted context omitted.

The guy I learned about 'mis en place' from had coined a term, "retro-grouch" for people who loudly insist on a nostalgia for old technology. When the Trough of Disillusionment hits, us old farts pop out of the woodwork to say "see, told you so" whether we were right or wrong.

Did you learn mis en place in a kitchen, or does it have a meaning in technology circles that I'm unaware of?

I work in an org where it is used to refer to the prep for a release, but with sort of a wink and a nod.

Re: The future of web software is HTML over WebSockets

#35

Post by skullum »

frompdx wrote: post #2

This seams really optimistic and kind of glosses over the subject of scaling out websocket connections apart from this. Anecdotally, the typical single Rails server process seems to be perfectly happy supporting nearly 4,000 active connections. And you can easily swap in the excellent AnyCable to bump that up to around 10,000+ connections per node by not relying on the built-in Ruby WebSocket server. That's not a lot…

Phoenix live view (anything on BEAM really) maps each ws to a BEAM process so scaling to 10000+ connections is both cheap and built-in

Re: The future of web software is HTML over WebSockets

#36

Post by hinkley »

burnished wrote: post #19
hinkley wrote: post #10

Earlier quoted context omitted.

The guy I learned about 'mis en place' from had coined a term, "retro-grouch" for people who loudly insist on a nostalgia for old technology. When the Trough of Disillusionment hits, us old farts pop out of the woodwork to say "see, told you so" whether we were right or wrong.

Did you learn mis en place in a kitchen, or does it have a meaning in technology circles that I'm unaware of?

Turns out if you do skilled manual labor, the concepts translates. Bob was a bike mechanic. I don't know if he used the words, but he kept harping on us for not having our shit or tools together for a task ahead of time. When you're covered in grease is not a time to be digging for a wrench.

Re: The future of web software is HTML over WebSockets

#37

Post by ehayes »

hg35h4 wrote: post #14

Everything about this sounds terrible for mobile, lossy or even medium latency connections. Non-blocking background updates are unnoticeable, but imagine your website being jammed like a stuck video every time you click or scroll? He describes a "please wait buffering" future of web software. No thanks.

Turbo[links], Stimulus, etc. ARE non-blocking background updates. It's HTML over the wire instead of JSON. [1] I don't think this is what you think it is.

[1] https://hotwire.dev/

Re: The future of web software is HTML over WebSockets

#38

Post by methyl »

mathgladiator wrote: post #16

I have thoughts, and I agree but also disagree a bit. We are in the dark-ages with respect to streaming sockets, and I am the architect of one of the worlds largest WebSocket and streaming services. First off, unseating the operational benefits provided by request response is a huge challenge. It's possible, and I've done it. One of these days, my co-authors and I will present an OSDI paper with the broad strokes. It…

> Let the browser maintain a DOM tree that templates over a JSON object, then reactive-ly update and it's an amazing experience

Totally agreed. I even pulled off an Elixir library as a POC to show this concept, here's an example project: https://github.com/surferseo/live_data/tree/master/examples/... (most relevant part of API is here: https://github.com/surferseo/live_data/blob/master/examples/... and here: https://github.com/surferseo/live_data/blob/master/examples/...)

Re: The future of web software is HTML over WebSockets

#39

Post by silon42 »

hg35h4 wrote: post #14

Everything about this sounds terrible for mobile, lossy or even medium latency connections. Non-blocking background updates are unnoticeable, but imagine your website being jammed like a stuck video every time you click or scroll? He describes a "please wait buffering" future of web software. No thanks.

At least their web page seems to work without Javascript... I hope this technology will too.

Re: The future of web software is HTML over WebSockets

#40

Post by Asmod4n »

hg35h4 wrote: post #14

Everything about this sounds terrible for mobile, lossy or even medium latency connections. Non-blocking background updates are unnoticeable, but imagine your website being jammed like a stuck video every time you click or scroll? He describes a "please wait buffering" future of web software. No thanks.

With this approach you can keep all of the traffic inside a WebWorker, so nothing blocks. You also get the benefit of not having to open a new connection for every request and automatic reconnects when someting goes wrong. The connection is most likely already established before you even need it.
Post reply on HN