4 ms·
Iv been upset with HTTP/2 / SPDY since the very first beginning (yet i never used it, nor try). Now, thanks to you, i understand why. It's not a replacement/ e
by 131hn 10y ago
Iv been upset with HTTP/2 / SPDY since the very first beginning (yet i never used it, nor try). Now, thanks to you, i understand why.
It's not a replacement/ enhancement of HTTP, it's definitively not a Transport layer. It has no use/gain for webservices, and as single page apps tends to optimise resources delivery (webpack, browserify, scss, stylus & co, very few resources are left to deliver) so no urgent "need" for it here.
So, for an _application layer_ it's comming a little late, i guess "block SPA" with intrisected client side & server side (nodejs/ express & spa) apps might gain of it, but it have to be considered as the very first line of the app developpement , the transition/ enhancement cost / gain ratio for existing apps is too hard to plan.
Great writing !
- axman6 10y agoI actually disagree with both your conclusions - the techniques you mentioned exist to get around painful deficiencies with HTTP/1.1, and are anti patterns in http/2 - sprites exist to reduce the latency of loading many small images, which is now no longer an issue (see httpvshttps.com for a demonstration). Also my brief experiments using HTTP/2 in Haskell involved zero changes to my web service handler code, and maybe one or two extra lines to give paths to the TLS cert files. Web services will benefit massively from HTTP/2 in some domains, I do a lot of web geospatial work and using it for servers which return hundreds of image tiles will be a massive win