Conversation
Now that we no longer support IE we can raise the minimum ES target a bit. Changing to es2015 shaves off ~17% from the main bundle size, also it prevents generators from being transpiled into regular functions etc. so I would guess it has the potential to give some general performance improvements too. For fun I also tried to raise it to es2022, this gave a slightly bigger bundle than es2015 so I think es2015 could be an ok target unless we need something newer for some reason.
Tyriar
left a comment
Tyriar
left a comment
There was a problem hiding this comment.
17% is a pretty awesome win, I'll merge in and try update it in vscode soon to see if anything goes wrong 🤞
|
Yes the savings are awesome 👍 On a sidenote: I wonder if ts compiler/webpack could be instructed to mangle private names as well (with the help of a skip list in case we really do ugly private access from outside of a module/class). When looking at the generated output it really seems, that most of the package size results from chatty property names, that dont get mangled. (Rough estimate from a python script extracting chatty names sees this at 60%, lol) |
|
I don't think the TS compiler can do it, but I'd love to minify some of those long names without compromising readability/sourcemaps. Before: After: |
Main change: xtermjs/xterm.js#3992
Main change: xtermjs/xterm.js#3992
3 participants
Now that we no longer support IE we can raise the minimum ES target a
bit. Changing to es2015 shaves off ~17% from the main bundle size, also
it prevents generators from being transpiled into regular functions etc.
so I would guess it has the potential to give some general performance
improvements too.
For fun I also tried to raise it to es2022, this gave a slightly bigger
bundle than es2015 so I think es2015 could be an ok target unless we
need something newer for some reason.