5 ms·

Agreed. I once worked with an engineer who seemed to have dedicated their career to reducing bundle sizes. I think it's easy to do things like this in the name

Agreed. I once worked with an engineer who seemed to have dedicated their career to reducing bundle sizes. I think it's easy to do things like this in the name of "better" because they're measurable. I'd advise that if you've not accumulated Gandalf levels of experience yet, or you genuinely don't really need to reduce bundle sizes, or eek out an extra 10ms of execution time, your energies are best focussed on creating better software for users (here's the important bit) _that doesn't hurt the developers who'll need to modify it in future._ Why? Because bad code compounds in cost. When you make a decision and write code, it always results in other tangential decisions to need to be made in future. If your decision makes future decisions harder, they're more likely to be wrong. And then it makes all the tangential decisions after that likely to be even harder. Compounding, like interest, but the bad kind: debt. So it's far more valuable to invest your time in learning to make inoffensive decisions than to go swapping libraries or trimming bundle sizes in the name of kilobytes. On that front, it's more noble to choose a framework because it makes the pit of success as wide as possible, helping even the least skilled engineers make changes that are simple to change, fix or undo when needed, than to save 30ms per user, only to lose it because someone screwed up because of some bad code you wrote in one of the features.

411111111111111 4y ago
You're just flat out wrong. The original point is correct, all modern frameworks have comparable performance, which is why the app will perform similarly, no matter which framework was used. However, bundle size has a direct impact in loading speed and there are multiple thresholds where even kilobytes can matter. The only time you can ignore it is if your users will exclusively access your website from a direct broadband connection.
- deleted 4y ago
  [deleted]
- beaker52 4y ago
  To some people, loading speed is everything. My experience has taught me that it is not. I work on web apps and I've learnt from experience that optimising software for simplicity and ease of change over a few milliseconds or kb is far more valuable than a lot of people would have you believe. Your users will barely notice a few kb or ms. But your colleagues do notice software complexity. Your stakeholders do notice delivery times. Your directors do notice costs. And ultimately you'll notice your share value. That said, you might benefit greatly from fine tuning your bundle sizes and library choices. But what I'm saying, is that maybe you'd make a different choice if you take the time to consider the broader activity of software development.
  - vlunkr 4y ago
    IMO the other reason to not care about bundle size is because the browser is going to cache them for you for free. All the API calls you make in a SPA are bound to be much much slower than your asset load time.
    - gervwyk 4y ago
      this. unless your serving static content, the impact of bundle size is minimial. of course there is a difference between 500kb and 5mb. Just try not to be the 5mb guy.
  - vijaybritto 4y ago
    You are correct that loading times are not valuable for B2B apps or apps behind a login. But the main issue is that there is no simple or straightforward process to achieve performance in load time / run time if its not followed from the start. You build the same capabilities but they are just smaller. I worked for an analytics product that never really bothered about performance on load or any of the web vital metrics. When they wanted to strike a deal with a fortune 20 customer, they were questioned on the performance of the app. It was not good. Took around 5 to 10 seconds to load everything on a macbook pro. Now all of a sudden we needed to fix the performance for all the pages. I helped set up the processes we needed to follow to measure and focus. This was one of the most complex scenarios you can face in an Enterprise product. Touching old code for the sake of speed. btw, the biggest perf improvement we realized was when we switched from React to Preact. There were some issues to iron out but it was okay considering the perf benefit.
- hinoki 4y ago
  Even if the bundle is always cached locally, a large bundle can hurt startup performance. A little discipline goes a long way. You probably don’t need to fight against every few kb, but having a bot post the bundle size in every commit can help a lot. If you think you can ignore it, you will, until you can’t ignore it, and then it’s a very annoying problem to solve.

411111111111111 4y ago

You're just flat out wrong. The original point is correct, all modern frameworks have comparable performance, which is why the app will perform similarly, no matter which framework was used. However, bundle size has a direct impact in loading speed and there are multiple thresholds where even kilobytes can matter. The only time you can ignore it is if your users will exclusively access your website from a direct broadband connection.

deleted 4y ago
[deleted]
beaker52 4y ago
To some people, loading speed is everything. My experience has taught me that it is not. I work on web apps and I've learnt from experience that optimising software for simplicity and ease of change over a few milliseconds or kb is far more valuable than a lot of people would have you believe. Your users will barely notice a few kb or ms. But your colleagues do notice software complexity. Your stakeholders do notice delivery times. Your directors do notice costs. And ultimately you'll notice your share value. That said, you might benefit greatly from fine tuning your bundle sizes and library choices. But what I'm saying, is that maybe you'd make a different choice if you take the time to consider the broader activity of software development.
- vlunkr 4y ago
  IMO the other reason to not care about bundle size is because the browser is going to cache them for you for free. All the API calls you make in a SPA are bound to be much much slower than your asset load time.
  - gervwyk 4y ago
    this. unless your serving static content, the impact of bundle size is minimial. of course there is a difference between 500kb and 5mb. Just try not to be the 5mb guy.
- vijaybritto 4y ago
  You are correct that loading times are not valuable for B2B apps or apps behind a login. But the main issue is that there is no simple or straightforward process to achieve performance in load time / run time if its not followed from the start. You build the same capabilities but they are just smaller. I worked for an analytics product that never really bothered about performance on load or any of the web vital metrics. When they wanted to strike a deal with a fortune 20 customer, they were questioned on the performance of the app. It was not good. Took around 5 to 10 seconds to load everything on a macbook pro. Now all of a sudden we needed to fix the performance for all the pages. I helped set up the processes we needed to follow to measure and focus. This was one of the most complex scenarios you can face in an Enterprise product. Touching old code for the sake of speed. btw, the biggest perf improvement we realized was when we switched from React to Preact. There were some issues to iron out but it was okay considering the perf benefit.
hinoki 4y ago
Even if the bundle is always cached locally, a large bundle can hurt startup performance. A little discipline goes a long way. You probably don’t need to fight against every few kb, but having a bot post the bundle size in every commit can help a lot. If you think you can ignore it, you will, until you can’t ignore it, and then it’s a very annoying problem to solve.