161–170 of 504 posts
For me, I think the biggest issue with large scale deployment of HTTP 3 is that it increases the surface area of potentially vulnerable code that needs to be kept patched and maintained. I'd far rather have the OS provide a verified safe socket layer, and a dynamically linked SSL library, that can be easily updated without any of the application layer needing to worry about security bugs in the networking layer. Addi…
For me, I think the biggest issue with large scale deployment of HTTP 3 is that it increases the surface area of potentially vulnerable code that needs to be kept patched and maintained. I'd far rather have the OS provide a verified safe socket layer, and a dynamically linked SSL library, that can be easily updated without any of the application layer needing to worry about security bugs in the networking layer. Addi…
HTTP/3 is terrible for fast connections (with download speeds on gigabit fiber notably capped) and great for bad ones (where latency + three way handshakes make the web unusable).
Perhaps there should be some kind of addon/setting for the browser to detect the quality of the network (doesn't it already for some JS API?) and dynamically enable/disable HTTP/3 for the best performance. I can live with it off 99% of the time, but those rare times I'm dropped to 2G speeds, it's a night and day difference.
> At the same time, neither QUIC nor HTTP/3 are included in the standard libraries of any major languages including Node.js, Go, Rust, Python or Ruby. .NET actually looking like it has decent support for any teams that are interested[0] (side note: sad that .NET and C# are not considered "major"...). There is an open source C library that they've published that seems rather far along[1] Support for Windows, Linux[2],…
> side note: sad that .NET and C# are not considered "major I've said it before on here, but the tech community severely underrates .NET today. It's not Windows only (and hasn't been for ~8 years) plus C# is a very nice language. F# is also an option for people who like functional languages. I'd highly recommend giving it a try if you haven't already.
Earlier quoted context omitted.
A "few extra ms" is up to 3 roundtrips difference, that's easily noticeable by humans on cellular. For all the CPU optimisations we're doing, cutting out a 50ms roundtrip for establishing a HTTP connection feels like a great area to optimize performance.
> A "few extra ms" is up to 3 roundtrips difference, that's easily noticeable by humans on cellular. That's a valid concern. That's the baseline already though, so everyone is already living with that without much in the way of a concern. It's a nice-to-have. The problem OP presents is what are the tradeoffs for that nice-to-have. Is security holes an acceptable tradeoff?
Earlier quoted context omitted.
Have those findings been independently confirmed? Has Google said anything? Is it dependent on certain e.g. server-side factors? Did Google "get this wrong" or was this intentional? E.g. is it by far a net positive to be faster on slow internet where the difference is perceivable, than to be slower on fast internet because it's still lightning-fast even when it's slower?
Google's needs are not most people's needs, "wrong" for them is different than "wrong" for general users.
Earlier quoted context omitted.
And yet, compared to the time you're waiting for that mast head jpeg to load, plus an even bigger "react app bundle", also completely irrelevant. HTTP/3 makes a meaningful difference for machines that need to work with HTTP endpoints, which is what Google needed it for: it will save them (and any other web based system similar to theirs) tons of time and bandwidth, which at their scale directly translates to dollars…
Almost every optimization is irrelevant if we apply the same reasoning to everything. Add all savings together and it does make a difference to real people using the web in the real world.
Nearly all of my real world performance issues have come from a very small set of functionality running extremely poorly.
Earlier quoted context omitted.
Only Typescript is in-house. Others are acquisitions. Do you remember Embrace, extend, and extinguish times? https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
VS code is mostly in house too. Sure, they don’t own Electron, but I was at MSFT when project Monaco (which became the basis for VS Code) was started and remember being very impressed by it back then
Earlier quoted context omitted.
A "few extra ms" is up to 3 roundtrips difference, that's easily noticeable by humans on cellular. For all the CPU optimisations we're doing, cutting out a 50ms roundtrip for establishing a HTTP connection feels like a great area to optimize performance.
> A "few extra ms" is up to 3 roundtrips difference, that's easily noticeable by humans on cellular. That's a valid concern. That's the baseline already though, so everyone is already living with that without much in the way of a concern. It's a nice-to-have. The problem OP presents is what are the tradeoffs for that nice-to-have. Is security holes an acceptable tradeoff?