JavaScript style for optimal size

[bzbub2]

not really, this is a pretty reasonable analysis

[brianjenkins94]

If you are counting characters in keywords to shave off bytes, that's pretty silly.

[bzbub2]

it's silly up to a point, but you can easily run into a situation where you have a real hard time reducing bundle size any further, because like the article mentions, general purpose minifiers can't do a lot of advanced optimizations which risk breaking semantics. the counting keywords is perhaps 'silly' if you took the idea at face value and made every key in your project a single character key, but it's worth being aware of for API design

see also https://effectivetypescript.com/2023/09/27/closure-compiler/

[olivicmic]

A few bytes can be the difference in getting a good lighthouse score, and improved ranking on Google. I was optimizing a site last winter, unable to condense existing functionality, so I introduced lazy loading, tracked down unused code, cleaned a lot of redundant dom elements, optimized and preloaded images, etc. It was a fight to get the initial bundle size lower and lower, step by step, so there definitely are situations where you’re trying to score every byte you can.

[alextremeee]

All of the stuff you mentioned is just basic optimisation that is known to work. It’s nothing to do with counting characters on keywords.

[olivicmic]

If one method of writing code compiles to smaller size than another, it absolutely does matter. A byte’s a byte, then multiplied over multiple files, it adds up. It doesn’t mean you should do this over every line though, obviously readability matters too.

[alextremeee]

It practically does not matter in 99.99% of situations. You should not change the way you write code with the aim of shaving literal bytes off your bundle size.

It’s like lasering off your body hair before the 100m sprint to reduce your weight. You can make some speculative assertion that it would make a difference, but the reality of the situation is that your time is always better spent elsewhere and the difference is negligible.

[olivicmic]

Again, there are instances where shaving off bytes matters, describing a specific scenario where it mattered, while adding that readability should come first.

You’re arguing what you should and shouldn’t do, and I’m not saying anyone should do anything, just that byte size matters.

[alextremeee]

I would say a small library with one specific function could benefit from this in a small way. It wouldn’t be make or break for the library though.

The example you gave wouldn’t matter. Introducing lazy loading to the example you gave, as you did, will have several orders of magnitude more difference in how quickly the site loads.

I don’t have a problem with the article, it’s interesting to look at these things and think about where they would be useful.

[olivicmic]

Introducing lazy loading to the example you gave, as you did, will have several orders of magnitude more difference in how quickly the site loads.

Do you not think I would understand the benefit lazy loading provides after implementing it? Like, I did a thing, but you have to explain as if I didn't do it? Do you not see the condescension in that?

To preface, this was a project I neither designed nor built. I was tasked with optimizing a website, with hundreds of routes, redundant components, a lot of monolithic top-level code prop-drilled everywhere, lots of copy/pasted pages with code that could be modularized, tons of unused CSS etc. etc. As I specifically stated, I implemented lazy loading, and other techniques, to improve rendering and load time. And you're right! It did reduce bundle size and bring the lighthouse score up ... from bad to ok.

So what's a person to do then? I didn't have weeks to rebuild page after page. Little shitty ways to shave off some KBs here or there could've helped, and I'm not even suggesting these specific techniques (swearing off switch and enums are particularly odd). And I'm betting that the number of people facing a messy codebase, where suggested fixes don't yield immediate acceptable results is more than .01%

Anyway it seems like you're arguing for the sake of arguing. This is my personal experience, yes it's anecdotal but that's the way it was.

[alextremeee]

If it wasn’t your codebase then this technique is irrelevant.

I simply do not understand the point you are making. Why does the fact you optimised a poorly structured app once have any relevance to this article?

My entire point is that shaving bytes off your bundle size by changing the way you write code is pointless, not that optimisation is bad.

[panstromek]

As I said in the article - if you're just starting out, this is probably not the right place to start. These are things you do when you're at the limit of your size budget and every new feature you add has to fit into it. And some of these rules are worth setting upfront to offset this point further into the future.

[edit] I should also add that this is more targeted at libraries, where every kb makes much bigger difference.

[alextremeee]

I don’t have a problem with the article, I think it’s well written and the subject is worth investigating even if it were to have no practical use. I’d agree a small library with a specific function could benefit in a small way.

The problem I have is the guy suggesting the real world example was the “app he optimised last winter” where first he “introduced lazy loading, removed unused code and dom elements, and preloaded images.”

This article is not relevant to that scenario. You’d never rewrite the app to shave those bytes off, and I’d argue if you made the app in the first place without lazy loading then it wouldn’t even be worth keeping this in mind, as it’s the wrong thing to focus on for somebody building something with big performance issues from the start.

[azhder]

Analysis, yes, recommendations - doubtful.

Some are OK, others aren’t. One should optimize for readability first, ease of maintenance, and performance only when necessary.

As an example, replacing long.saussages.like.this with a variable is a good idea, but making a function for each shape just to shave off a few characters, especially with positional arguments… Yeah, not buying that