12 ms·

I happen to develop a JS-App that also has to be optimised for an Android Phone from 2017. I don't think the amount of JS is in any way related to performance.

I happen to develop a JS-App that also has to be optimised for an Android Phone from 2017. I don't think the amount of JS is in any way related to performance. You can make 1MB of JS perform just as poorly as 10MB. In our case, the biggest performance issues were: - Rendering too many DOM nodes at once - virtual lists help. - Using reactivity inefficiently. - Random operations in libraries that were poorly optimised. Finding those things was only possible by looking at the profiler. I don't think general statements like "less JS = better" help anyone. It helps to examine the size of webpages, but then you have to also put that information into context: how often does this page load new data? once the data is loaded, can you work without further loading? Is the data batched, or do waterfalls occur? Is this a page that users will only visit once, or do they come regularly? ...

acdha 3y ago
> It helps to examine the size of webpages, but then you have to also put that information into context: how often does this page load new data? once the data is loaded, can you work without further loading? Is the data batched, or do waterfalls occur? Is this a page that users will only visit once, or do they come regularly? I totally agree - my point was simply that people sometimes focus on network bandwidth and forget that a huge JS file can be a problem even if it’s cached. What you’re talking about is the right way to do it - I try to get other developers to use older devices and network traffic shaping to get an idea for those subjective impressions, too, since it’s easy to be more forgiving when you’re focused on a dedicated testing session than, say, if you’re trying to use it while traveling and learning that the number of requests mattered more than the compressed size or that you need more robust error handling when one of the 97 requests fails.
lukan 3y ago
"- Rendering too many DOM nodes at once - virtual lists help" Yup, despite all the improvements, the DOM is still slow and it is easy to make it behave even slower. Only update what is necessary and be aware of the performance bottleneck forced reflow. Every time you change anything and then get clientWidth for example and then change something else - you will make the DOM calculate(and posibly render) everything twice. I found the chrome dev tools to be really helpful with spotting those and other stuff. But sure, if you update EVERYTHING anyway, including waiting for the whole data transfer, with any click, when you just want some tiny parts refreshed, you have other problems anyway.
- acdha 3y ago
  > the DOM is still slow and it is easy to make it behave even slower I think this should be more nuanced: the DOM itself has been fast for 10-15 years but things like layout are still a concern on large pages. The problem is that the DOM, like an ORM, can make it easy to miss when you’re requesting the browser do other work like recalculating layout, and also that as people started using heavier frameworks they started losing track of what triggers updates. Lists are an interesting challenge because it’s surprisingly hard to beat a well-tuned browser implementation (overflow scrolling, etc.) but a lot of people still have the IE6 instincts and jump for implementing custom scrolling, only to find that there are a lot of native scrolling implementation features which are hard to match, and at some point they realize that what they really should have done was change the design to make layout easier to calculate (e.g. fixed or easily-calculated heights) or displayed fewer things at once.
  - troupo 3y ago
    > I think this should be more nuanced: the DOM itself has been fast for 10-15 years It's faster than it was 10-15 years ago. It's still extremely slow. > things like layout are still a concern on large pages. > it easy to miss when you’re requesting the browser do other work like recalculating layout You can't say things like "DOM is fast" and "oh, it's fast if you exclude literally everything that people want to be fast". > and also that as people started using heavier frameworks they started losing track of what triggers updates. I don't know if you realise, but on the very same devices where you're complaining about "large pages and oh my god layout" people are routinely rendering millions of objects with complex logic and animations in under 5 milliseconds? The DOM is excruciatingly slow.
    - acdha 3y ago
      I think you’re using DOM to refer to the entire browser, not just what’s standardized as the DOM. Things like creating or modifying elements will run at tens of millions per second on an old iPhone _but_ there are operations like the one you mentioned which force the browser to do other work like style calculation and layout, and if you inadvertently write code which is something like “DOM update, force recalc, DOM update” in a loop it’s very easy to mistakenly think that the DOM is the source of the performance problem rather than things like the standard web layout process having many ways for different elements to interact. And, yes, I’m not unaware that different display models have different performance characteristics. Modern browsers can run into into the millions of objects range but fundamentally a web page is doing more work and there’s no way it’s going to match something which does less. This is why there have been various ways to turn off some of the expensive work (e.g. fixed table layout) and when APIs like canvas, WebGL, and WebGPU use different designs to allow people who need more control to avoid taking on costs their apps don’t need.
realusername 3y ago
You can theoretically have a somewhat fast enough large JS app but it's going to be an uphill battle. You have to make regular bundle analysis otherwise the cache won't work if you deploy too much and package updates and new additions are likely to break the performance analysis you've just made before. Less JS = better performance is a simplified model but very accurate in practice in my opinion, especially on large teams.
guappa 3y ago
> You can make 1MB of JS perform just as poorly as 10MB. But can you make a 10MB js perform as good as a good 1MB js?
- hnarn 3y ago
  I'm not a JS developer but I imagine that the amount of JavaScript code isn't the most relevant part if most of it isn't being called. I mean, if you have some particularly heavy code that only runs when you click a button, is that really parsed and causes overhead before the button is clicked?
  - guappa 3y ago
    It is parsed and loaded in memory, and not executed.
    - lifthrasiir 3y ago
      "Loaded" part is no longer true in major JS implementations (for example, [1]). [1] https://v8.dev/blog/preparser https://v8.dev/blog/preparser
      - acdha 3y ago
        That’s a broader claim than that page supports. They describe how they avoiding fully generating the internal representation and JITing it, but clearly even unused code is taking up memory and CPU time so you’d want to review your app’s usage to make sure that it’s acceptable levels of work even on low-end devices and also that your coding style doesn’t defeat some of those optimizations.
  - jitl 3y ago
    Depending on how the code is loaded, yes. If all 10mb is in a single JS file, and that file is included in a normal script tag in the page’s HTML, then parsing the 10mb will block UI interaction as the page loads. Once the browser parses 10mb, it’ll evaluate the top level statements in the script, which are the ones that would set up the click event handler you’re referencing. If the entire page is rendered by JavaScript in the browser, then even drawing the initial UI to the screen is blocked by parsing JS. The solution to this for big apps is to split your build artifact up into many separate JS files, analogous to DLLs in a C program. That way your entry point can be very small and quick to parse, then load just the DLLs you need to draw the first screen and make it interactive. After that you can either eagerly or lazily initialize the remaining DLLs depending on performance tradeoff. I work on Notion, 16mb according to this measurement. We work hard to keep our entry point module small, and load a lot of DLLs to get to that 16mb total. On a slow connection you’ll see the main document load and become interactive first, leaving the sidebar blank since it’s a lower priority and so we initialize it after the document editor. We aren’t necessarily using all 16mb of that code right away - a bunch of that is pre-fetching the DLLs for features/menus so that we’re ready to execute them as soon as you say, click on the settings button, instead of having awkward lag while we download the settings DLL after you click on settings.

acdha 3y ago

> It helps to examine the size of webpages, but then you have to also put that information into context: how often does this page load new data? once the data is loaded, can you work without further loading? Is the data batched, or do waterfalls occur? Is this a page that users will only visit once, or do they come regularly? I totally agree - my point was simply that people sometimes focus on network bandwidth and forget that a huge JS file can be a problem even if it’s cached. What you’re talking about is the right way to do it - I try to get other developers to use older devices and network traffic shaping to get an idea for those subjective impressions, too, since it’s easy to be more forgiving when you’re focused on a dedicated testing session than, say, if you’re trying to use it while traveling and learning that the number of requests mattered more than the compressed size or that you need more robust error handling when one of the 97 requests fails.

lukan 3y ago

"- Rendering too many DOM nodes at once - virtual lists help" Yup, despite all the improvements, the DOM is still slow and it is easy to make it behave even slower. Only update what is necessary and be aware of the performance bottleneck forced reflow. Every time you change anything and then get clientWidth for example and then change something else - you will make the DOM calculate(and posibly render) everything twice. I found the chrome dev tools to be really helpful with spotting those and other stuff. But sure, if you update EVERYTHING anyway, including waiting for the whole data transfer, with any click, when you just want some tiny parts refreshed, you have other problems anyway.

acdha 3y ago
> the DOM is still slow and it is easy to make it behave even slower I think this should be more nuanced: the DOM itself has been fast for 10-15 years but things like layout are still a concern on large pages. The problem is that the DOM, like an ORM, can make it easy to miss when you’re requesting the browser do other work like recalculating layout, and also that as people started using heavier frameworks they started losing track of what triggers updates. Lists are an interesting challenge because it’s surprisingly hard to beat a well-tuned browser implementation (overflow scrolling, etc.) but a lot of people still have the IE6 instincts and jump for implementing custom scrolling, only to find that there are a lot of native scrolling implementation features which are hard to match, and at some point they realize that what they really should have done was change the design to make layout easier to calculate (e.g. fixed or easily-calculated heights) or displayed fewer things at once.
- troupo 3y ago
  > I think this should be more nuanced: the DOM itself has been fast for 10-15 years It's faster than it was 10-15 years ago. It's still extremely slow. > things like layout are still a concern on large pages. > it easy to miss when you’re requesting the browser do other work like recalculating layout You can't say things like "DOM is fast" and "oh, it's fast if you exclude literally everything that people want to be fast". > and also that as people started using heavier frameworks they started losing track of what triggers updates. I don't know if you realise, but on the very same devices where you're complaining about "large pages and oh my god layout" people are routinely rendering millions of objects with complex logic and animations in under 5 milliseconds? The DOM is excruciatingly slow.
  - acdha 3y ago
    I think you’re using DOM to refer to the entire browser, not just what’s standardized as the DOM. Things like creating or modifying elements will run at tens of millions per second on an old iPhone _but_ there are operations like the one you mentioned which force the browser to do other work like style calculation and layout, and if you inadvertently write code which is something like “DOM update, force recalc, DOM update” in a loop it’s very easy to mistakenly think that the DOM is the source of the performance problem rather than things like the standard web layout process having many ways for different elements to interact. And, yes, I’m not unaware that different display models have different performance characteristics. Modern browsers can run into into the millions of objects range but fundamentally a web page is doing more work and there’s no way it’s going to match something which does less. This is why there have been various ways to turn off some of the expensive work (e.g. fixed table layout) and when APIs like canvas, WebGL, and WebGPU use different designs to allow people who need more control to avoid taking on costs their apps don’t need.

realusername 3y ago

You can theoretically have a somewhat fast enough large JS app but it's going to be an uphill battle. You have to make regular bundle analysis otherwise the cache won't work if you deploy too much and package updates and new additions are likely to break the performance analysis you've just made before. Less JS = better performance is a simplified model but very accurate in practice in my opinion, especially on large teams.

guappa 3y ago

> You can make 1MB of JS perform just as poorly as 10MB. But can you make a 10MB js perform as good as a good 1MB js?

hnarn 3y ago
I'm not a JS developer but I imagine that the amount of JavaScript code isn't the most relevant part if most of it isn't being called. I mean, if you have some particularly heavy code that only runs when you click a button, is that really parsed and causes overhead before the button is clicked?
- guappa 3y ago
  It is parsed and loaded in memory, and not executed.
  - lifthrasiir 3y ago
    "Loaded" part is no longer true in major JS implementations (for example, [1]). [1] https://v8.dev/blog/preparser https://v8.dev/blog/preparser
    - acdha 3y ago
      That’s a broader claim than that page supports. They describe how they avoiding fully generating the internal representation and JITing it, but clearly even unused code is taking up memory and CPU time so you’d want to review your app’s usage to make sure that it’s acceptable levels of work even on low-end devices and also that your coding style doesn’t defeat some of those optimizations.
- jitl 3y ago
  Depending on how the code is loaded, yes. If all 10mb is in a single JS file, and that file is included in a normal script tag in the page’s HTML, then parsing the 10mb will block UI interaction as the page loads. Once the browser parses 10mb, it’ll evaluate the top level statements in the script, which are the ones that would set up the click event handler you’re referencing. If the entire page is rendered by JavaScript in the browser, then even drawing the initial UI to the screen is blocked by parsing JS. The solution to this for big apps is to split your build artifact up into many separate JS files, analogous to DLLs in a C program. That way your entry point can be very small and quick to parse, then load just the DLLs you need to draw the first screen and make it interactive. After that you can either eagerly or lazily initialize the remaining DLLs depending on performance tradeoff. I work on Notion, 16mb according to this measurement. We work hard to keep our entry point module small, and load a lot of DLLs to get to that 16mb total. On a slow connection you’ll see the main document load and become interactive first, leaving the sidebar blank since it’s a lower priority and so we initialize it after the document editor. We aren’t necessarily using all 16mb of that code right away - a bunch of that is pre-fetching the DLLs for features/menus so that we’re ready to execute them as soon as you say, click on the settings button, instead of having awkward lag while we download the settings DLL after you click on settings.