> The gist of that article is by using edit-distance/levenstein distance to 'cluster' JS code fragments, you can improve the efficiency of GZIP by bringing more code into its 32K window OR optimize the huffman codes it uses. However, edit-distance doesn't know anything about the LZ algorithm's mechanism.
That sounds really cool, and even though I couldn't understand the technical details I understood the gist of it. But, because there is a "but", the issue with tech- and algorithm-focused companies like Google is that they don't look at the grander scheme of things, the same way as some other less tech-focused companies/people would have.
To go back to your example, that solution meant that Google could "serve" even more JS code to clients' browsers, and as I assume other googlers came out with different but related solutions that meant that even more and more JS code would "make it" to Google's web products. That's how we got to things like the latest GMail interface, which is a mess in terms of JavaScript, because Google just couldn't say at any one point: "No more JS!" presumably because it was getting easier and easier to "input" JS into that thing. All of this could have been prevented if at any one point a Google higher-up would have said "YAGNI!" or "KISS!", which are also very valid programming principles but which I didn't notice as being emphasized on this Google Tech Dev Guide page.
Everything has gotten bulkier in Gmail, not just the JS, but th CSS, the DOM, the fonts, assets overall because Gmail is an app that’s over a decade old and features have mostly been added, not removed.
This is the fate of all legacy software, OSes, native apps, they all eventually burst under their own weight, and are rewritten clean. Inbox was that dream :)
In particular, Gmail has been engineered to mostly be served as a single page app that functions offline as well. SPAs were a bad architectural trend now being somewhat reversed by code-split PWAs.
The same JS tools like Closure Compiler that enable large SPAs also enable efficient code splitting into tiny pieces (look at photos.google.com as an example)
A hammer is only as good as what you use to build. Web apps got native app envy after installables and app stores took off. I think we’ve woke up from that now and you’ll gradually see it improve.
Happy to hear that and happy to hear that in the end there were people at Google that managed to impose a KISS-like view on one of their most used products.
> Web apps got native app envy after installables and app stores took off. I think we’ve woke up from that now and you’ll gradually see it improve.
Yeah, the hype was big with SPAs, I also hope that Google diverging from that path will set an example for the rest of the industry and things will become more "normal" again.
That sounds really cool, and even though I couldn't understand the technical details I understood the gist of it. But, because there is a "but", the issue with tech- and algorithm-focused companies like Google is that they don't look at the grander scheme of things, the same way as some other less tech-focused companies/people would have.
To go back to your example, that solution meant that Google could "serve" even more JS code to clients' browsers, and as I assume other googlers came out with different but related solutions that meant that even more and more JS code would "make it" to Google's web products. That's how we got to things like the latest GMail interface, which is a mess in terms of JavaScript, because Google just couldn't say at any one point: "No more JS!" presumably because it was getting easier and easier to "input" JS into that thing. All of this could have been prevented if at any one point a Google higher-up would have said "YAGNI!" or "KISS!", which are also very valid programming principles but which I didn't notice as being emphasized on this Google Tech Dev Guide page.