3 ms·
> OTOH Firefox is vastly fatter than it was in its early versions, which supported FTP (and Gopher!), so it doesn't seem like FTP or other minor protocols are a
by signal11 5y ago
> OTOH Firefox is vastly fatter than it was in its early versions, which supported FTP (and Gopher!), so it doesn't seem like FTP or other minor protocols are an actual cause of complexity- and bloat-creep.
I’m sure someone will correct me, but without looking at the source code, I suspect the following will have played a role in increasing code size since the earliest days of Phoenix:
* support for newer media formats, from MP4 through AVIF
* DRM maybe?
* WebGL
* SVG?
* The complexity of modern CSS
- handrous 5y agoMuch, much bigger JS engine/sandbox, probably. Backwards compat with an ever-growing set of HTML, CSS, and JS. I'd guess a modern CSS engine is several times (dozens of times?) larger than what Phoenix shipped with. I expect their internal UI-drawing code/framework is a lot larger than in the Phoenix days. Webassembly. Canvas. And yeah, several of the other things you mentioned—video used to be the responsibility of plugins, for example. [EDIT] in fact, some things browsers do now were seen as terrible ideas when Phoenix was released, because they would kill performance, since they're so much more expensive than alternatives. Vector graphics were regarded as to-be-avoided for a long time, because they're so much more taxing on the client than raster. CSS doing animations would have been considered insane, fit only for "look how I can bring your machine to a crawl with a web page" demos. Maintaining an entire "shadow DOM" of Javascript objects would have been regarded as parody-levels of resource wasting for all but very niche use-cases. No wonder the modern web is so slow and resource-hungry....
- hutzlibu 5y agoOr Wasm, or WebRTC, or indexedDB ... plus anything else on that long list: https://developer.mozilla.org/en-US/docs/Web/API https://developer.mozilla.org/en-US/docs/Web/API