Hacker News new | past | comments | ask | show | jobs | submit login

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.




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.


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.


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.


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.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: