-
-
Notifications
You must be signed in to change notification settings - Fork 626
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
Putting Aurelia on a diet #692
Comments
I actually don't think 85k Gzipped is bad at all for such a full-featured framework. None of the other competitors you mention come anywhere close to us on feature-richness. But, yes, we can probably do a few things to improve this. Here are some thoughts off the top of my head... There are things we could pull out of binding, such as the Unparser and the SVG support. These could be put into separate modules. Unparser is usually only useful for debugging. Not everyone needs SVG binding either. This would be a breaking change, though it wouldn't affect most people and would be easy to migrate to. Templating has some code duplication in the view compiler. There may be other things in there as well. Across everything, if we move to TS and then centralize the helpers, we could probably reduce the amount of boilerplate the transpiler is generating on every library. For templating-resources, I think it would be nice to have an easy way to include only what you want, since everyone doesn't use all of what is in there. Polyfills could be replaced with an empty module, depending on what browsers need to be supported. Perhaps we could do something smart there and actually generate the polyfills module at build time based on what browsers the developer wants to support? |
I'd like to see the CLI use tslib when TypeScript is selected. |
A few unused things might be dropped by tree-shaking (I have yet to test that. When I do I'll report how much is actually dropped). With webpack, another backward-compatible way to drop optional stuff could be to use defined variables. If we wrap SVG support in a big Using similar techniques, I think the bootstrapper could be much smaller in a webpack build (it's not that big unfortunately). Of course the clean way is to extract SVG in its own module and require an import in code that wants support. As you noted that would be a breaking change. BTW if we make several modules optional, a good way to help back-compat would be to reference them all in a new I noticed that |
@AshleyGrant Thanks for the explanation! I could swear I've used the console but it turns out |
Yeah, it bit me back in the day. Unfortunately, IE9 is an important thing for us to support for the foreseeable future. But hey, we welcome a PR w/that comment :-P |
@jods4 the whole story about sizes is pretty worthless if you can't compare a common set. E.g. out of fun I started building my own ViewOnly Library for a specific project and guess what, unminified code version is 4kb. If I'd remove even more error handling and additional helper-functions I could bring it down to 3kb for sure. This was enough for said specific use case but would never be something I'd propose to more general projects. So the bottom line is its never about the size alone. If thats all you care about going VanillaJS is certainly the best option with 0 kb. A templated approach vs all JS like React and alike does clearly has to have differences, last but not least in size. What we can do is clearly cut things down or as described by @EisenbergEffect make things even more optional (SVG and stuff). But I wouldn't ever expect Aurelia to be somewhere near to Inferno or Svelte size-wise, as the target audience/use cases are not the same for a Framework vs a View Library. Btw. take a look at these size-comparisons. https://gist.github.com/Restuta/cda69e50a853aa64912d |
@zewa666 I don't agree that looking at Aurelia size and trying to make it smaller worthless. For example by doing this exercice I could spot that The smaller the framework, the better startup times, working sets, etc. I acknowledged that comparing frameworks size was not really doable because of different supported targets and features. Yet it's not completely worthless either. Just |
It is an apples to oranges comparison in many cases, but I think we can definitely improve in this area. It's worth it to spend some time looking at what we could do to improve this in the future. |
@jods4 I didn't say it's worthless to try to reduce the size, actually this is something we should do and your examples are good. What is worthless though is to compare apples to oranges. Use cases matter as well and Aurelia simply covers different ones then Inferno etc. As such I just meant that you shouldn't expect Aurelia ever to compete with 9kb sized Libs. |
@zewa666 of course I don't expect Aurelia to become 9Ko in size! 😆 I was looking at my webpack builds and I definitely think we can reduce the base size of Aurelia. The comparisons were only for some context and I agree they are not 100% meaningful. Yet I don't think we should completely ignore them. For instance I have previously looked at Vuejs. It's very similar to Aurelia and supports a lot of identical features. Comparing its size with Aurelia's templating+binding is not so far fetched and Vuejs is only 17Ko. React is interesting because it's one of the most popular alternatives to Aurelia (second to Angular I guess). So it's interesting to know where we stand, even if the philosophy is very different. I am well aware that React doesn't really have a "templating" engine as everything is compiled code that produces fragments. Someone cited Svelte above. It has no runtime, 0B. It's still interesting because we can copy those ideas. Compiling views at build time would improve perf and if an application has all its views pre-compiled, then we could remove the view-compiler from the output and reduce the size! |
Some news, I finally managed to get tree shaking to work properly with Aurelia.
My comments:
|
Important current tree-shaking limitation, for reference: webpack/webpack#2899 |
@jods4 Would you mind sharing your webpack configuration where you enabled tree shaking for Aurelia? |
@lu4nm3 it's based on the new set of plugins I've made. I am holding off pushing the last (important) changes to jods4/aurelia-webkit because they need a few PR in core Aurelia packages to work out-of-the-box. Webpack 2.2 always does tree-shaking, but:
So to take advantage of that you must use ES6 The tricky part with Aurelia is that without my plugins anything loaded by |
@jods4 perhaps we could try using the original |
Another option would be Closure Compiler. It supports ES6, while Uglify still doesn't. I saw there was a TypeScript fork which emits Closure Compiler annotations that the compiler can then work with to minify and do its own tree-shaking. Not sure how stable / feature complete it is though. |
@niieani I think duplicate helpers will be removed with the current plan to move all sources to TS? @zewa666 webpack is very extensible. Uglify is just a built-in plugin, you can substitue anything you want. @niieani ES6 is undeniably smaller (if only because of |
Some ideas that may slightly reduce code size:
|
Regarding polyfils, https://polyfill.io/ is a service which serves only the needed polyfills for each browser (MutationObserver was added recently). It could be mentioned in the documentation alongside instructions on how to replace |
I remember that I opened a ticket back then to make polyfills optional but it was rejected. In our apps for example we use corejs to build exactly the set of polyfills that we use and need given our minimum browser target. This is redundant with the polyfills shipped with Aurelia. |
I lurked around the code and here are a few observations:
The best example of last bullet is @EisenbergEffect Would you mind if I try adding some |
Go for it!
…On Feb 2, 2017 5:23 PM, "jods" ***@***.***> wrote:
I lurked around the code and here are a few observations:
- There are some ES5 helpers repeated a few times across the whole
codebase. -> the plans to migrate to TS + use a single helpers module
should help a little bit.
- The current codegen names all functions, like: var frob = function
frob() { }, I guess to preserve Function.name. This results in quite
some duplicated names. TS doesn't do that, so again the migration should
shrink size a bit.
- Some modules have potential for smaller code size, but nothing
really significant. One problem is that pretty much any change is a
breaking change. For example: I think making BehaviorInstruction and
TargetInstruction interfaces (i.e. use plain objects) instead of
classes could reduce code size. But that is a breaking change as they are
exported. Opportunities to make *significant* size reductions while
keeping exactly the same public API are hard to find.
- Another direction could be to try harder to remove unused parts from
the build output. I think many users use just a fraction of Aurelia and
there is a lot of dead code carried around.
The best example of last bullet is svg.js in aurelia-binding: there is
nearly 20K of attributes names there, which can't be minified as it's all
strings. That's an easy, large reduction for people who don't use SVG
bindings (probably the majority).
@EisenbergEffect <https://github.com/EisenbergEffect> Would you mind if I
try adding some if (!NO_SVG) in a few places? This adds zero overhead but
build tools/minifiers, which are able to define constants and remove dead
code could then drop large parts of code on an opt-out basis.
My idea is that you could then do a webpack build with new
AureliaPlugin({ noSvg: true }) and get a bundle that is 20K smaller.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#692 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAIBndHwgUm0rGHCbJIMEykQGl6RaGLYks5rYoF3gaJpZM4LjyJ6>
.
|
I noticed that webpack So removing There are two drawbacks, though:
|
I am putting SVG support behind a global variable But defining that variable in my webpack build brings the bundle down to 279K, which is 19K down from previous build. (But I lost SVG support, obviously.) I started this experiment at 343K so I went already quite a long way. 📢 If anyone is aware of other large-ish features that are often unused let me know. It can be quite easy to put them behind a flag. Ideally, it would have been better to make this an opt-in |
Yeah, the HMR CSS hot reloading is hacky that way. See my comment here about a possible solution. |
One thing that could potentially reduce a lot of fat is to do something like this in class methods across Aurelia src: method() {
var _this = this;
// replace all direct _this with this; to help minifier throw some fat
} A quick sum through the minified code shows me this could help. Maybe this job can be delegated to build tool. Another 1 is to have class transformation more efficient: // src
class ABC {
xyz1() {}
xyz2() {}
}
// unoptimized
function ABC() {}
ABC.prototype.xyz1 = function() {}
ABC.prototype.xyz2 = function() {}
// optimized
function ABC() {}
var ABC_proto = ABC.prototype
ABC_proto.xyz1 = function() {}
ABC_proto.xyz2 = function() {} I believe the latter can have good impact on production bundles, but it seems harder to achieve atm. |
@bigopon Yes using local variables/parameters rather than global names/properties results in smaller code because the former can easily be mangled by minifiers, while the latter can't. In my opinion this comes at the expense of source code readability, which I see as more important -- unless we talk about large wins in specific areas. I don't know what others think about it. Moreover it tends to gzip well, although minified size is also important. If there is a minifier that supports such transformations in a safe way, that would be interesting! The second point is really up to the ES6 transpiler. Currently Babel, but there's a move towards TS. |
I did a build using ES6 distribution + Babili minifier (based on Babel, supports ES6). The result (with default Babili options) seems to work. The ES6 bundle is 251K minified, which is 28K less than my previous ES5 bundle (at 279K). Gzipped ~72K. Another easy win I have in mind is providing an opt-out for the polyfills. If you target modern browsers, that should be an easy ~10K removal. |
Excellent work investigating that @jods4 My thought from the beginning is that Aurelia would get smaller over time by basing things on standards. So, smaller syntax and no polyfills as a nice side-effect of the progress of the web. |
I just cut 2K from the minified build by removing So starting an ES6 project with the core of Aurelia is now under 250K minified. |
aurelia/polyfills#46 adds support for selectively removing polyfills, based on This is acceptable if you target only modern browsers (in which case you probably want Another situation is that you might include a specific list of polyfills (probably from In this second case, I should point out that the main page of This goes hand-in-hand with the ES6 minified build. Assuming we target modern browsers, removing ES2015 and ES2016 polyfills brings the size just under 240K minified, or 68K gzipped. This is 9K down from the 249K build. 🎉 If you can target a modern browser, this build configuration is more than 100K (minified) smaller than what I started with one month ago (343K)! I will probably look at |
A |
@gheoan all those changes are opt-in for compatibility purposes. The default build still includes everything. You must set flags to remove parts that you don't need, which can be a breaking change, indeed. |
@jods4 I was under the impression that they would be removed from the default build. Sorry for the confusion. These flags can be used for other build systems other than |
@gheoan Surely. if (typeof FEATURE_NO_SVG === 'undefined') {
// svg support is here
} And likewise for a bunch of What you need is a build that is able to statically evaluate Webpack has all the required tools to perform that but I'm sure it's not unique. |
I think requirejs can use this too. I'll check.
…On Feb 14, 2017 11:56 AM, "jods" ***@***.***> wrote:
Reopened #692 <#692>.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#692 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAIBnbxhm5_Fr2zobpo2FT6NQ6EMu6Epks5rcgb-gaJpZM4LjyJ6>
.
|
The journey continues... The numbers are not directly comparable with the previous build because there has been a release in between and some unrelated changes but my small build is now at 237K minified, ~67K gzipped. |
Keep up the great work! |
@jods4 Random, but are you documenting all this switches (and how to flip them) somewhere? |
@RichiCoder1 Here: Also relevant: |
@jods4 I've been having some issues with the plugin regarding the I've tried creating a fresh webpack & Aurelia project and it seems that defining
The same effect is noticed even if I define EDIT: Scrub that, I stupidly assumed that by using the |
I am a little bit surprised: if you use the |
I am using it like so;
My deps are;
Calling |
You have latest Aurelia libs? All those flags were added very recently. |
I have just deleted by
I'm personally not worried about it as I now know to pass |
@Robula I'm not sure what is going with your project. I did an experiment with my ES6 Small Build demo. If I comment out the feature line then the resulting bundle is 309,674 bytes. So there's approx. a 30K win by removing unused features. Looking at the bundle contents I can see the polyfills being there or missing. |
How did you create this treemap of the project? |
I upgraded everything to Webpack 3 today. Without any change, I was happy to see it provided a 13% minified size reduction. 😄 Then I tried the new scope hoisting, aka Don't get me wrong, scope hoisting is great and provides faster load times, and smaller sizes if you use tons of small modules. There are a couple reasons why it isn't efficient on this application:
Your mileage may vary. In a large application, the more files and the more libraries you use the better the results. Anyway, new build is 242'310 bytes minified, 64Kb gzipped. |
Note from Webpack 4 upgrade, the same build as above but using built-in I expect some larger wins if we start to use the new |
Yessss, thanks you |
In addition to the original plans, we're also currently experimenting with a compile-time transform version of Aurelia that would obviate the need for huge parts of the framework, move certain runtime components into the build process and allow dropping all parts of the framework unused by the app. We're early on in the experimental process, but you can watch via the experiment repo. |
There is a lot of awareness around "modern" web app sizes and their libs recently. I am assuming this is obvious so won't repeat all here (download times, parsing/startup time, mobiles, etc.).
Some libraries make efforts to reduce size, for example jQuery has slimmed down by stopping supporting old browsers and removed deprecated apis. It also offers non-bundled sources so that you can import only the modules you actually use.
Some of Aurelia's competitors take pride in being very small: React is 45K gzipped, Vue.js 17K and Inferno only a tiny 9K!
Of course, the comparaison is never completely fair because it depends on supported targets and the feature set (for example none of the numbers above include a router). But it gives an idea what to aim for.
Aurelia is not lightweight. Here's an analysis of a basic, empty app. The only dependency in
project.json
isaurelia-bootstrapper
. It was built with Webpack 2.2 and minified with default settings. Spoiler: the whole thing is 85Ko gzipped, almost 10 times Inferno.Here's a picture of the whole thing, the treemap is proportional to gzipped size:
And for reference, some modules:
There is essentially two ways to improve: (1) enable people to only include what they actually use (granular modules and/or tree shaking). This is already discussed in other issues. (2) reduce the size of the code.
I noticed a few low-hanging fruits:
aurelia-webpack-loader
, moduleaurelia-hot-module-reload
is there even when building for prod. This is 5K (gzip) wasted, half the size of inferno!aurelia-polyfills
is 3.5K (gzip), even though the target platform might not need them or the build might include them externally anyway.There is definitely potential for improvement in the code but unless obvious wasted or duplicated code is found it will be made of many small wins. :(
binding
,templating
andtemplating-resources
are really the lion's share in the core packages.The text was updated successfully, but these errors were encountered: