I am curious about your answers to the following questions.
-- Why can't Chrome browser include most of the popular versioned libraries/frameworks (react, angular, etc) within the browser itself? Then, developers write codes to access to those natively for the better performance. Can you imagine how many millions of websites save a lot of bandwidth?
-- Is there any way to compile/bundle the 3rd party libraries with only used functions instead of as a whole? Most of web/mobile apps don't use those libraries fully.
Why can't Chrome browser include most of the popular versioned libraries/frameworks (react, angular, etc) within the browser itself? Then, developers write codes to access to those natively for the better performance. Can you imagine how many millions of websites save a lot of bandwidth?
We've debated this a few times :)
The main challenge here is versioning. At the end of the day, the reason bundling popular JavaScript libraries in the browser wouldn't work in practice is that individual sites would want to pin to specific versions or serve from their own infrastructure. They might be convinced they have to use a "trusted" version or that a newer/bug-fix version could break their site.
Attempting to bundle multiple versions of each library with Chrome in each release could also be problematic for other reasons (e.g constantly keeping up to date with vulnerability fixes). In theory, HTTP caching addresses the overall benefit of shipping libraries in the browser, albeit on repeat load if it isn't already in the user's cache.
We're exploring a more slimmed down variation of this idea in a project called Layered APIs (github.com/drufball/layered-apis). The basic idea is if we can define and ship primitives implemented in JavaScript within browsers (and formal polyfills where needed), third-party libraries would be able to use these as dependencies without needing to ship quite as much code down. It's still in the very early phases though.
Is there any way to compile/bundle the 3rd party libraries with only used functions instead of as a whole? Most of web/mobile apps don't use those libraries fully.
An approach I recently saw a PWA in Japan (Nikkei) take is self-hosting third-party JavaScript and running it through webpack to try stripping out as much unnecessary code as needed. This isn't going to always be feasible without the complete source though.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi Addy,
I am curious about your answers to the following questions.
-- Why can't Chrome browser include most of the popular versioned libraries/frameworks (react, angular, etc) within the browser itself? Then, developers write codes to access to those natively for the better performance. Can you imagine how many millions of websites save a lot of bandwidth?
-- Is there any way to compile/bundle the 3rd party libraries with only used functions instead of as a whole? Most of web/mobile apps don't use those libraries fully.
Thanks
Nizam
We've debated this a few times :)
The main challenge here is versioning. At the end of the day, the reason bundling popular JavaScript libraries in the browser wouldn't work in practice is that individual sites would want to pin to specific versions or serve from their own infrastructure. They might be convinced they have to use a "trusted" version or that a newer/bug-fix version could break their site.
Attempting to bundle multiple versions of each library with Chrome in each release could also be problematic for other reasons (e.g constantly keeping up to date with vulnerability fixes). In theory, HTTP caching addresses the overall benefit of shipping libraries in the browser, albeit on repeat load if it isn't already in the user's cache.
We're exploring a more slimmed down variation of this idea in a project called Layered APIs (github.com/drufball/layered-apis). The basic idea is if we can define and ship primitives implemented in JavaScript within browsers (and formal polyfills where needed), third-party libraries would be able to use these as dependencies without needing to ship quite as much code down. It's still in the very early phases though.
An approach I recently saw a PWA in Japan (Nikkei) take is self-hosting third-party JavaScript and running it through webpack to try stripping out as much unnecessary code as needed. This isn't going to always be feasible without the complete source though.