evanw
commented
9 months ago This is a useful data point but I hesitate to make any assumptions based on a single data point. Especially when you consider compression, I imagine you can find cases for any tool where that tool does the best. But that doesn't necessarily mean that tuning another tool for such a case is the right thing to do, as it may cause other cases to regress. This kind of thing is likely best attempted as a large-scale study over many code bases and code patterns so that the average case is improved instead of over-optimizing for a special case at the expense of the average case. I'm not saying that esbuild's output couldn't be made better (I'm sure it can) but I think this is more involved than for example swapping binary operand order based on what happens in a few test cases.
I was trying to see what would happen when passing code through multiple minifiers. I noticed that when SWC output is fed through esbuild it actually ends up increasing the size of the files. In the playground repl, the expansion in uncompressed code is 36 bytes, and the compressed size is increased by 156 bytes.
The first major difference I saw was the identifiers, looks like swc assigns them based on order of appearance so I'd expect esbuild usage frequency based assignment to perform better here, https://github.com/evanw/esbuild/pull/2614 may help in this regard.
The second difference I noticed is that esbuild seems place constants in equality comparisons on the right where as swc/terser move all constants to the left, I couldn't find any documentation why terser prefers it that way or why esbuild does the opposite and I can't intuit which one is generally better.
repl