I find it interesting that you did not mention what is probably the biggest predictor of performance in the browser - the size of the download. In general, the less code you send to the browser, the better.
That's mostly true when your audience has relatively recent hardware and a good connection to the internet. Something about 4 billion people don't have.
No. I'm sorry. But it doesn't matter whether you have gigabit fiber or a 56k dial-up modem. Once the code has been downloaded, the amount of code makes no difference to performance. I'm not saying - in any way - that you shouldn't care at all about bundle size. But if you're inferring that more code leads to lower performance once the package has been downloaded, then that's simply not accurate.
Comment hidden by post author - thread only visible in this permalink
I guess you're referring to the performance of the code in memory. Because more code can take up more space in RAM. But even on a relatively-ancient system, the "performance" hit needed to process 10,000 lines of JS code versus 1,000 lines of JS code is extremely minimal. If you think that you can improve the runtime performance of your code, on anyone's system, merely by writing fewer lines of code, then your target audience probably can't effectively run ANY React / Angular / jQuery / whatever app.
Comment hidden by post author - thread only visible in this permalink
I didn't mention lines of code. There is a correlation between the size of the app and the complexity of its function and the demand it places on its running environment.
The size isn't the actual cause (usually). It's just indicative of the likelihood that the app will be more demanding of its execution environment.
I'm sorry, but this is a bit disingenuous. You say that you didn't mention lines of code. But your initial comment was about the size of the download. What do you think makes the download large???
Comment hidden by post author - thread only visible in this permalink
I'm sorry, but your original use of the phrase was disingenuous. It comes across as an attempt to belittle the point. Lines of code is purely a function of formatting (unless you can point me to an accepted standard of how to measure it).
I get that you don't think the number of bytes you send to the browser matters. You've made that perfectly clear. I understand that point of view. The company I work for takes the exact same stance. It's still the wrong stance. Size is not usually the actual cause, but it is certainly a reasonable proxy for judging potential performance requirements. And that is exactly what I pointed out.
The more code you send to the client, the more potential for execution errors, logic errors, or errors indirectly related to the code itself. More code usually means more complexity, which is another vector for more demand placed on the client system.
The code you didn't have to write will never cause a problem. I'm a firm believer in the best code is no code. If you've never heard the phrase before, you might look it up. The idea has been around for quite a while.
Comment deleted
Comment hidden by post author - thread only visible in this permalink
I find it interesting that you did not mention what is probably the biggest predictor of performance in the browser - the size of the download. In general, the less code you send to the browser, the better.
With regard to initial page load time, yes. After the initial page load, the size of the download has almost nothing to do with performance.
That's mostly true when your audience has relatively recent hardware and a good connection to the internet. Something about 4 billion people don't have.
No. I'm sorry. But it doesn't matter whether you have gigabit fiber or a 56k dial-up modem. Once the code has been downloaded, the amount of code makes no difference to performance. I'm not saying - in any way - that you shouldn't care at all about bundle size. But if you're inferring that more code leads to lower performance once the package has been downloaded, then that's simply not accurate.
I'm referring to the fact that a lot of people run on old hardware and/or out of date browsers and more code does affect performance for them.
I guess you're referring to the performance of the code in memory. Because more code can take up more space in RAM. But even on a relatively-ancient system, the "performance" hit needed to process 10,000 lines of JS code versus 1,000 lines of JS code is extremely minimal. If you think that you can improve the runtime performance of your code, on anyone's system, merely by writing fewer lines of code, then your target audience probably can't effectively run ANY React / Angular / jQuery / whatever app.
It sounds like you've never encountered an app that will not run well on your old system, but runs fine on your new system.
When an app runs poorly on your old system, but it runs fine on your new system, it's not based on the number of lines of code.
I didn't mention lines of code. There is a correlation between the size of the app and the complexity of its function and the demand it places on its running environment.
The size isn't the actual cause (usually). It's just indicative of the likelihood that the app will be more demanding of its execution environment.
I'm sorry, but this is a bit disingenuous. You say that you didn't mention lines of code. But your initial comment was about the size of the download. What do you think makes the download large???
I'm sorry, but your original use of the phrase was disingenuous. It comes across as an attempt to belittle the point. Lines of code is purely a function of formatting (unless you can point me to an accepted standard of how to measure it).
I get that you don't think the number of bytes you send to the browser matters. You've made that perfectly clear. I understand that point of view. The company I work for takes the exact same stance. It's still the wrong stance. Size is not usually the actual cause, but it is certainly a reasonable proxy for judging potential performance requirements. And that is exactly what I pointed out.
The more code you send to the client, the more potential for execution errors, logic errors, or errors indirectly related to the code itself. More code usually means more complexity, which is another vector for more demand placed on the client system.
The code you didn't have to write will never cause a problem. I'm a firm believer in the best code is no code. If you've never heard the phrase before, you might look it up. The idea has been around for quite a while.
Wow. Your sarcasm skills are epic. I hope you can teach me as well.
I could. But you'd have to download the instructions. And I'm sure that your bandwidth/device couldn't handle the bundle size.
Now that you've given up refuting my point, you're going to stick to ad hominem attacks instead. I'll keep that in mind.
It sounds really impressive to use Latin words like "ad hominem" - until you use them in a way that doesn't make any sense in the current context.
Definition of ad hominem (Entry 1 of 2)
1: appealing to feelings or prejudices rather than intellect
It's appropriate.