> Webrtc. Google’s implementation is super widely used in all sorts of communications software.
Webrtc uses the user's bandwidth without permission or notification and it used to prevent system sleep on macs without any user visible indication.
> V8. Lots of innovation on the interpreter and JIT has made JS pretty fast and is reused in lots of other software like nodejs, electron etc.
No matter how efficient they made it, javascript "applications" are still bloatware that needlessly waste the user's resources compared to native code.
> Sandboxing. Chrome did a lot of new things here like site isolation and Firefox took a while to catch up.
That's useful but only because the bloatware above. If you didn't give code running in the browser that much power you wouldn't need sandboxing.
> Codecs. VP8/9 and AV1 broke the mpeg alliance monopoly and made non patented state of the art video compression possible.
Could agree. Not sure of Google's real contribution to those.
> SPDY/QUIC. Thanks to Google we have zero RTT TLS handshakes and no head of line blocking HTTP with header compression, etc now and H3 has mandatory encryption.
It's also a binary protocol that cannot be debugged/tested via plain telnet, which places a barrier to entry for development. Perhaps enhances Google's market domination by requiring their libraries and via their control of the standard.
> > Codecs. VP8/9 and AV1 broke the mpeg alliance monopoly and made non patented state of the art video compression possible.
> Could agree. Not sure of Google's real contribution to those.
They were not the only contributor (I was the technical lead for Mozilla's efforts in this space), but they were by far the largest contributor, in both dollars and engineering hours.
> No matter how efficient they made it, javascript "applications" are still bloatware that needlessly waste the user's resources compared to native code.
Well that's just biased. Saying application is bloated (which is often not true) is the result of an entire ecosystem, has something to do with an interpreter, is ridiculous. Any qualified software engineer can see the fault in such a comment. You probably know that as well.
Is have to agree to be honest. Whoever decided to run JavaScript in the backend should be committed to a mental institution. JavaScript is a nightmare. But you can't tell a man something his paycheck depends on him not knowing.
>Webrtc uses the user's bandwidth without permission or notification and it used to prevent system sleep on macs without any user visible indication.
>No matter how efficient they made it, javascript "applications" are still bloatware that needlessly waste the user's resources compared to native code.
>No matter how efficient they made it, javascript "applications" are still bloatware that needlessly waste the user's resources compared to native code.
So should we not deliver advanced sandboxed cross platform applications for any platform, and instead deliver unsandboxed native code for all possible platforms? ActiveX called, it wants to say thanks for the endorsement and that it told you so.
And no more zoom meetings because somebody's Mac might not go to sleep? I'm with you on that one, brother!
> Webrtc. Google’s implementation is super widely used in all sorts of communications software.
Webrtc uses the user's bandwidth without permission or notification and it used to prevent system sleep on macs without any user visible indication.
> V8. Lots of innovation on the interpreter and JIT has made JS pretty fast and is reused in lots of other software like nodejs, electron etc.
No matter how efficient they made it, javascript "applications" are still bloatware that needlessly waste the user's resources compared to native code.
> Sandboxing. Chrome did a lot of new things here like site isolation and Firefox took a while to catch up.
That's useful but only because the bloatware above. If you didn't give code running in the browser that much power you wouldn't need sandboxing.
> Codecs. VP8/9 and AV1 broke the mpeg alliance monopoly and made non patented state of the art video compression possible.
Could agree. Not sure of Google's real contribution to those.
> SPDY/QUIC. Thanks to Google we have zero RTT TLS handshakes and no head of line blocking HTTP with header compression, etc now and H3 has mandatory encryption.
It's also a binary protocol that cannot be debugged/tested via plain telnet, which places a barrier to entry for development. Perhaps enhances Google's market domination by requiring their libraries and via their control of the standard.