Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> As for the remaining possible cases, they’re served about as well and more compatibly by older techniques.

Noteably none of the alternatives deal directly in HTTP resources. HTTP PUSH could have/should have allowed sending new http resources directly. HTTP could have become a way to allow a page to be reactive, as new content was streamed at it, and this would have been a near ideal fit architecturally, building on what the web is and what http is, to meet with modern apps which have incoming new data streamed to them all the time.

Instead we have this long list of un-HTTP non-resourceful hacks, to have a separate eventing system. Because HTTP2 built the tech then failed to let the page use it. Technology like RFC 8030 demonstrate what that better future look like & is widely used, just, as you say, not by the page directly. This is a fuck up, a huge missed opportunity. I disagree with your assessment that backwards compatibility means we should stick to the same ratty old non-resourceful options we've been stuck with: we should & ought to use better. That good tech was impossible to use directly by the page was a sin that prevented this technology from receiving adoption & attention.

It feels like everyone is fixated on the cache-digest problem, which indeed is hard, but it's just not relevant. There's so many other interesting & good architectural options that this tech opened up. Just, the web never empowered developers to use them.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: