I've been putting off this thread because it got weird and I couldn't follow but it seems to have calmed down.
It's good to be wary that Nim does not explode its JS output size. However it is unfair to say that Nim is overly lenient with regard to the JS output size and Nim users will have the rug pulled from under them for using the JS backend. This is especially true when you consider other languages that compile to JS or even JS frameworks that emulate what Nim can do with metaprogramming or just normal language features. Nim in fact generally beats its competitors in this regard. It may be that compared to the alternatives, Nim produces more mechanical and unreadable JS code. However sometimes this is [actually faster](https://github.com/nim-lang/Nim/issues/20219#issuecomment-1214306965) because of JS being weird or engine specific quirks or whatever. Bigger code size doesn't necessarily imply that engines will use more CPU/memory either. I can't really give an informed account here because it's difficult to benchmark such a general issue but I doubt there's many issues to encounter. If people notice something is wrong and investigate, as said above it's fine to deal with it, but specifically searching for issues isn't worth the time and effort. If you are concerned about bandwidth use, minifying Nim JS output usually brings the size down by 50% (mostly because of whitespace), and gzip brings it down to basically nothing (20 kb max if you are careful). Compared to other files on most webpages Nim really doesn't have any impact. We should really have FAQ answers or wiki pages or whatever for stuff like this.
