-
Notifications
You must be signed in to change notification settings - Fork 26.3k
Lose 70KB with One Weird Trick! Doctors hate it! #5293
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
We shouldn't leak these helpers outside of our bundles otherwise we could run into conflicts with other people doing the same. What we should do instead is include helpers only once within each bundle. IMO this can be done post beta because it doesn't change API surface, but if someone really wants to implement this before beta then I'm not going to stand in their way. |
@robwormald did you measure things with min+gzip? I was assuming that with gzip the actual gains (in terms of size) would be much smaller. For me the biggest pb here is that TS doesn't give us a file with all the helpers it can produce (we don't have any equivalent of traceur-runtime). |
Even if it isn't much smaller, savings in JS parse time will still be good to have. |
tl;dr; using min+gzip numbers we can see that we can save only ~2kB (< 2%) using this trick. Here are exact numbers on what we can save for a simple "Hello World" application (see diff of what had to be changed to package helpers only once):
Impact on the load time is harder to see: during my naive measures I couldn't see significant and consistent improvement. |
If we want to implement this trick, here is a TODO list:
This would be a breaking change for people that bundle things on their own and don't use |
TS is going to ship helpers as a separate npm package. There is an issue
|
the issue tracking this is microsoft/TypeScript#3364; along with that we should have a tslib npm package that has all the known helpers along with some .d.ts for them. This will not be in TS 1.8, but we should have it out soon though. using |
Don't know if this is still valid issue, but in the meantime, you can use https://github.com/ngParty/ts-helpers |
@vicb |
@vicb Right now, Im having over 60+ __extends methods in my result bundle. Vote to open this issue again. Angular is very big, why dont to make it a bit smaller from nothing? |
The duplicates should no longer be there in 4.0.0-rc.2, can you check?
…On Wed, Mar 8, 2017, 12:30 PM Павел Богатырёв ***@***.***> wrote:
@vicb <https://github.com/vicb> Right now, Im having over 60+ __extends
methods in my result bundle. Vote to open this issue again. Angular is very
big, why dont to make it a bit smaller from nothing?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#5293 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AANM6NJREoQfAu7M0v4ktim873LZxQpFks5rjxABgaJpZM4Gifjd>
.
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Typescript emits an
__extends
helper to, well, help with extending classes.It currently shows up a few dozen times in our codebase, turning it off in the broccoli tree saves ~70KB unminified / 44KB minified in the existing System bundles.
option is
noEmitHelpers: true
Same optimization in Rx saves ~20KB or so, will submit a PR over there as well.
We'll need to include it at least once, of course, so this might be best added into our proposed "ngPolyfill" along with Reflect?
cc @IgorMinar
The text was updated successfully, but these errors were encountered: