3 ms·

My experiment on how to reduce javascript size of every web app by 30-50% : https://github.com/avodonosov/pocl https://github.com/avodonosov/pocl Working appro

My experiment on how to reduce javascript size of every web app by 30-50% : https://github.com/avodonosov/pocl https://github.com/avodonosov/pocl Working approach, but in the end I abandoned the project - I doubt people care about such js size savings.

dagelf 2y ago
Wdym?? 50% is a big deal
- bluGill 2y ago
  50% size savings isn't important to the people who pay for it. They pay at most pennies for 100% savings (that is somehow all the functionality in zero bytes - not worth anything to those paying the bills)
  - tyre 2y ago
    Size savings translates to latency improvements which directly affects conversion rates. Smaller size isn’t about reducing costs but increased revenue. People care.
    - soared 2y ago
      Agreed - often a CTO of an ecom site is very very focused on site speed and has it as their #1 priority since it directly increases revenue.
    - fwip 2y ago
      Note that this proof-of-concept implementation saves latency on first load, but may add latency at surprising points while using the website. Any user invoking a rarely-used function would see a delay before the javascript executes, without the traditional UI affordances (spinners etc) to indicate that the application was waiting on the network. Further, these secretly-slow paths may change from visit to visit. Many users know how to "wait for the app to be ready," but the traditional expectation is that once it's loaded, the page/app will work, and any further delays will be signposted. I'm sure it works great when you've got high-speed internet, but might break things unacceptably for users on mobile or satellite connections.
      - vlovich123 2y ago
        > without the traditional UI affordances (spinners etc) to indicate that the application was waiting on the network. This part is obviously trivially solvable. I think the same basic idea is going to at some point make it but it’ll have to be through explicit annotations first and then there will be tooling to automatically do this for your code based upon historical visits where you get to tune the % of visitors that get additional fetches. Also, you could probably fetch the split off script in the background anyway as a prefetch + download everything rather than just 1 function at a time (or even downloading related groups of functions together) The idea has lots of merit and you just have to execute it right.
        avodonosov 2y ago
        I agree with most of your comment, but don't get what you mean about explicit annotations. Note that most of the unused code is located in libraries, not in the app code directly.
        vlovich123 2y ago
        split async function handle_button_press() { … } This would cause the bundler to inject a split point & know how to hide that + know what needs bundling and what doesn’t. GWT pioneered almost 20 years ago although not a fan of the syntax they invented to keep everything running within stock Java syntax: https://www.gwtproject.org/doc/latest/DevGuideCodeSplitting.html https://www.gwtproject.org/doc/latest/DevGuideCodeSplitting....
        avodonosov 2y ago
        Why do you want them explicit in the code? The tooling producing such annotaion based on historical visits whould constantly change the annotated set of functions, I suspect, whith app versions evolving. Note, the inactive code parts are very often in 3rd party libraries. Some are also in your own libraries shared between your different application. So the same shared library whould need one set of split-annotated functions for one app, and another set for another app. So these conflicting sets of annotations can not live in the library source code simultaneously.
    - bluGill 2y ago
      Who? anyone who is on a slow internet connection or who has a slow device can tell you they don't care. Or maybe they do but features are far more important. I guess if things are slow on a top of the line device withia fast connection they would care.
- avodonosov 2y ago
  Why big deal? 50% is just a big O of the original size :) If we consider overall Internet traffic, which is dominated by video and images, the size of javascript transmitted is negligible. Savings of memory and cpu for end user's browser? Maybe, but our software at all layers is so bloated, without need, just carelessly, that I'm not sure working of such javascript savings is useful - any resources saved will be eaten by something else immediately. For an application developer or operator, the 50% savings of javascript size are probably not worth dealing with some tool that dynamically prunes the app code, raising questions about privacy and security. I though through the security and privacy questions, but who would want to even spend attention on these considerations? As I mention in the README at github, a Microsoft researcher investigated the same approach earlier, but Microsoft haven't taken it anywhere. There was a commercial company offering this approach of javascript minification as a product, complete product. As well as other optimizations, like image size, etc. Their proxy embedded special "agent" code into the app which inspected the device and reported to server what image sizes are optimal for user, what js functions are invoked. And the server prepared optimized versions of app for various devices. Javascript was "streamed" in batches of only functions needed by the app. Now the company is dissolved - that's why the website is unavailable. Wikipedia says they were bought out by Akamai - https://en.wikipedia.org/wiki/Instart https://en.wikipedia.org/wiki/Instart. But I don't see any traces of this approach in the today's Akamai offerings. I contacted several companies, in CDN business and others, trying to interest them in the idea and get very modest funding for a couple more months of my time to work on this (I was working on this in the end of a long break from payed work and was running out of savings). Didn't find anyone ready to take part. This all may be signs that possibility of such an optimization is not valuable enough for users.
philipwhiuk 2y ago
How do you evaluate call usage?
- avodonosov 2y ago
  By instrumenting the code so that the function records the fact that it is being invoked. Then the info about the called functions is sent back to the server. (Only the functions never seen to be called are instrumented, the known active functions are not instrumented).
KTibow 2y ago
I think this is called tree shaking and Vite/Rollup do this by default these days. Of course, it's easy when you explicitly say what you're importing.
- avodonosov 2y ago
  That's not tree-shaking.
  - KTibow 2y ago
    Oh, I guess you would need something like dynamic imports to not include uncommonly used functionality in the main bundle
hinkley 2y ago
I got measurable decreases in deployment time by shrinking the node_modules directory in our docker images. I think people forget that, when you’re copying the same images to dozens and dozens of boxes, any improvement starts to add up to real numbers.
- syncsynchalt 2y ago
  I've not done it, but have you considered using `pnpm` and volume-mounting a shared persistent `pnpm-store` into the containers? It seems like you'd get near-instant npm installs that way.
  - hinkley 2y ago
    The only time npm install was on the critical path was hotfixes. It’s definitely worth considering. But I was already deep into doing people giant favors that they didn’t even notice, so I was juggling many other goals. I think the only thank you I got was from the UI lead, who had some soda straw internet connection and this and another thing I did saved him a bunch of hard to recover timeouts.
- avodonosov 2y ago
  In this approach the size of deployment bundles / images is not necessarily reduced. Reduced is the size of javascript loaded into the end user's browser.

dagelf 2y ago

Wdym?? 50% is a big deal

bluGill 2y ago
50% size savings isn't important to the people who pay for it. They pay at most pennies for 100% savings (that is somehow all the functionality in zero bytes - not worth anything to those paying the bills)
- tyre 2y ago
  Size savings translates to latency improvements which directly affects conversion rates. Smaller size isn’t about reducing costs but increased revenue. People care.
  - soared 2y ago
    Agreed - often a CTO of an ecom site is very very focused on site speed and has it as their #1 priority since it directly increases revenue.
  - fwip 2y ago
    Note that this proof-of-concept implementation saves latency on first load, but may add latency at surprising points while using the website. Any user invoking a rarely-used function would see a delay before the javascript executes, without the traditional UI affordances (spinners etc) to indicate that the application was waiting on the network. Further, these secretly-slow paths may change from visit to visit. Many users know how to "wait for the app to be ready," but the traditional expectation is that once it's loaded, the page/app will work, and any further delays will be signposted. I'm sure it works great when you've got high-speed internet, but might break things unacceptably for users on mobile or satellite connections.
    - vlovich123 2y ago
      > without the traditional UI affordances (spinners etc) to indicate that the application was waiting on the network. This part is obviously trivially solvable. I think the same basic idea is going to at some point make it but it’ll have to be through explicit annotations first and then there will be tooling to automatically do this for your code based upon historical visits where you get to tune the % of visitors that get additional fetches. Also, you could probably fetch the split off script in the background anyway as a prefetch + download everything rather than just 1 function at a time (or even downloading related groups of functions together) The idea has lots of merit and you just have to execute it right.
      - avodonosov 2y ago
        I agree with most of your comment, but don't get what you mean about explicit annotations. Note that most of the unused code is located in libraries, not in the app code directly.
        vlovich123 2y ago
        split async function handle_button_press() { … } This would cause the bundler to inject a split point & know how to hide that + know what needs bundling and what doesn’t. GWT pioneered almost 20 years ago although not a fan of the syntax they invented to keep everything running within stock Java syntax: https://www.gwtproject.org/doc/latest/DevGuideCodeSplitting.html https://www.gwtproject.org/doc/latest/DevGuideCodeSplitting....
        avodonosov 2y ago
        Why do you want them explicit in the code? The tooling producing such annotaion based on historical visits whould constantly change the annotated set of functions, I suspect, whith app versions evolving. Note, the inactive code parts are very often in 3rd party libraries. Some are also in your own libraries shared between your different application. So the same shared library whould need one set of split-annotated functions for one app, and another set for another app. So these conflicting sets of annotations can not live in the library source code simultaneously.
  - bluGill 2y ago
    Who? anyone who is on a slow internet connection or who has a slow device can tell you they don't care. Or maybe they do but features are far more important. I guess if things are slow on a top of the line device withia fast connection they would care.
avodonosov 2y ago
Why big deal? 50% is just a big O of the original size :) If we consider overall Internet traffic, which is dominated by video and images, the size of javascript transmitted is negligible. Savings of memory and cpu for end user's browser? Maybe, but our software at all layers is so bloated, without need, just carelessly, that I'm not sure working of such javascript savings is useful - any resources saved will be eaten by something else immediately. For an application developer or operator, the 50% savings of javascript size are probably not worth dealing with some tool that dynamically prunes the app code, raising questions about privacy and security. I though through the security and privacy questions, but who would want to even spend attention on these considerations? As I mention in the README at github, a Microsoft researcher investigated the same approach earlier, but Microsoft haven't taken it anywhere. There was a commercial company offering this approach of javascript minification as a product, complete product. As well as other optimizations, like image size, etc. Their proxy embedded special "agent" code into the app which inspected the device and reported to server what image sizes are optimal for user, what js functions are invoked. And the server prepared optimized versions of app for various devices. Javascript was "streamed" in batches of only functions needed by the app. Now the company is dissolved - that's why the website is unavailable. Wikipedia says they were bought out by Akamai - https://en.wikipedia.org/wiki/Instart https://en.wikipedia.org/wiki/Instart. But I don't see any traces of this approach in the today's Akamai offerings. I contacted several companies, in CDN business and others, trying to interest them in the idea and get very modest funding for a couple more months of my time to work on this (I was working on this in the end of a long break from payed work and was running out of savings). Didn't find anyone ready to take part. This all may be signs that possibility of such an optimization is not valuable enough for users.

philipwhiuk 2y ago

How do you evaluate call usage?

avodonosov 2y ago
By instrumenting the code so that the function records the fact that it is being invoked. Then the info about the called functions is sent back to the server. (Only the functions never seen to be called are instrumented, the known active functions are not instrumented).

KTibow 2y ago

I think this is called tree shaking and Vite/Rollup do this by default these days. Of course, it's easy when you explicitly say what you're importing.

avodonosov 2y ago
That's not tree-shaking.
- KTibow 2y ago
  Oh, I guess you would need something like dynamic imports to not include uncommonly used functionality in the main bundle

hinkley 2y ago

I got measurable decreases in deployment time by shrinking the node_modules directory in our docker images. I think people forget that, when you’re copying the same images to dozens and dozens of boxes, any improvement starts to add up to real numbers.

syncsynchalt 2y ago
I've not done it, but have you considered using `pnpm` and volume-mounting a shared persistent `pnpm-store` into the containers? It seems like you'd get near-instant npm installs that way.
- hinkley 2y ago
  The only time npm install was on the critical path was hotfixes. It’s definitely worth considering. But I was already deep into doing people giant favors that they didn’t even notice, so I was juggling many other goals. I think the only thank you I got was from the UI lead, who had some soda straw internet connection and this and another thing I did saved him a bunch of hard to recover timeouts.
avodonosov 2y ago
In this approach the size of deployment bundles / images is not necessarily reduced. Reduced is the size of javascript loaded into the end user's browser.