This person is counting the node_modules directory. While JS is a bit insane and this directory will have a ridiculous number of files, they are concerned:
"because my deployment (google app engine) allows only 10K files"
meaning, they don't realize that node_modules is for development and not related to the application they would actually deploy.
Hope this comment stays at the top before all the "wow JS sucks!!!" people arrive :-) Though to be fair a "modern" JS dev environment does use a ton of stuff!
IIRC Angular 2 production builds are actually pretty efficient.
IIRC the Angular2 production builds are the largest among all the frameworks. If you add the router it sits just shy of a meg - and that's just the dependencies. Not sure if they've started working on bringing the size down yet, but there are 1KB alternatives[1] for those who cares about their users.
I personally don't care but I've had super long install times when using slow internet—which in many parts of the world is the standard speed. I'll keep using Babel, but I like that there are alternatives that install faster if need be.
I agree. Also there are multiple ways that you can install these things.
The "recommended" way is to install babel for each project independently. Space is cheap, internet speeds are fast for many, and avoiding version issues outweighs the savings.
But you can install globally, so you'd install babel once and can use it in all projects that way.
Then throw in the possibility of different package managers and you get a crazy amount of freedom and choice. People get overwhelmed with "javascript fatigue" and I just don't get it. You don't need to do everything, but having the option to is amazing.
I believe NPM also caches your file locally. So the second install of babel would 304 from GitHub and get pulled from your local cache, saving time and bandwidth.
Buble's purpose is that it is supposed to be significantly faster to compile from ES6 to ES5 with minimal configuration, since it actually does things out of the box.
That's right, Buble's secret sauce to being fast is that is skips the code generation step, not because of the number of dependencies.
Although there definitely is a performance cost to Babel's large dep tree as each of these modules have to be found by Node (which is inefficient). If you use Babel with npm2 it is super slow, because npm2's folder structure causes more lookups.
Yeah, I think that was a bit of a mistake by you guys. AVA's entire point is to be fast but it has the perception of being slow because you've made transpiling a core feature. I would drop that and let people do their own transpiling.
Aside from the concurrent testing, Babel with async functions built-ins is our second biggest "bullet point", so even if you were right it's too late. AVA is opinionated and I think the benefits (from what people have told us) gained from using the latest syntax with no Babel config are worth the Babel bottleneck—which isn't that bad.
and not related to the application they would actually deploy.
this.
Granted, it's the same with everything- if you expanded every compressed file and counted every class, most languages and frameworks would just be incredibly nuts, because all of them aren't needed.
But, something could be done about that; you could better differentiate what is there for convenience, and what needs to be there and make the developer more aware of what they are using. It can make development more difficult if done poorly, but good examples of minimalist development are out there, e.g. Sinatra and similar frameworks that said X is too much- just use this.
Comments
This person is counting the node_modules directory. While JS is a bit insane and this directory will have a ridiculous number of files, they are concerned:
"because my deployment (google app engine) allows only 10K files"
meaning, they don't realize that node_modules is for development and not related to the application they would actually deploy.
Hope this comment stays at the top before all the "wow JS sucks!!!" people arrive :-) Though to be fair a "modern" JS dev environment does use a ton of stuff!
IIRC Angular 2 production builds are actually pretty efficient.
IIRC the Angular2 production builds are the largest among all the frameworks. If you add the router it sits just shy of a meg - and that's just the dependencies. Not sure if they've started working on bringing the size down yet, but there are 1KB alternatives[1] for those who cares about their users.
[1] - http://monkberry.js.org/
This website froze my Firefox running on an i7 CPU due to the animated background.
I'm not sure the right conclusion here is "oh, well then that is reasonable."
Though to be fair a "modern" JS dev environment does use a ton of unnecessary stuff!
I fixed your comment.
Eh, transpiling ES2015+ to ES5 is not unnecessary if it makes you more productive—Babel is just really big.
Well to be fair, does anyone expect a compiler to be small?
https://gitlab.com/Rich-Harris/buble
Buble says "Files (940 KB)" but it doesn't do everything Babel does (just a strict subset).
I know that it's possible, but what's the purpose?
Is anyone's quality of life really impacted by the size of babel vs buble?
Does the size of a compiler really change anything for the average developer (obviously within reason)?
I personally don't care but I've had super long install times when using slow internet—which in many parts of the world is the standard speed. I'll keep using Babel, but I like that there are alternatives that install faster if need be.
I agree. Also there are multiple ways that you can install these things.
The "recommended" way is to install babel for each project independently. Space is cheap, internet speeds are fast for many, and avoiding version issues outweighs the savings.
But you can install globally, so you'd install babel once and can use it in all projects that way.
Then throw in the possibility of different package managers and you get a crazy amount of freedom and choice. People get overwhelmed with "javascript fatigue" and I just don't get it. You don't need to do everything, but having the option to is amazing.
I believe NPM also caches your file locally. So the second install of babel would 304 from GitHub and get pulled from your local cache, saving time and bandwidth.
Buble's purpose is that it is supposed to be significantly faster to compile from ES6 to ES5 with minimal configuration, since it actually does things out of the box.
But that has nothing to do with it's size. If Buble was 10% larger than Babel it would still solve it's purpose.
That's right, Buble's secret sauce to being fast is that is skips the code generation step, not because of the number of dependencies.
Although there definitely is a performance cost to Babel's large dep tree as each of these modules have to be found by Node (which is inefficient). If you use Babel with npm2 it is super slow, because npm2's folder structure causes more lookups.
We ship Babel built in with the AVA[1] test runner and I can confirm `babel-require` is our bottleneck.
[1] https://github.com/avajs/ava
Yeah, I think that was a bit of a mistake by you guys. AVA's entire point is to be fast but it has the perception of being slow because you've made transpiling a core feature. I would drop that and let people do their own transpiling.
Aside from the concurrent testing, Babel with async functions built-ins is our second biggest "bullet point", so even if you were right it's too late. AVA is opinionated and I think the benefits (from what people have told us) gained from using the latest syntax with no Babel config are worth the Babel bottleneck—which isn't that bad.
this.
Granted, it's the same with everything- if you expanded every compressed file and counted every class, most languages and frameworks would just be incredibly nuts, because all of them aren't needed.
But, something could be done about that; you could better differentiate what is there for convenience, and what needs to be there and make the developer more aware of what they are using. It can make development more difficult if done poorly, but good examples of minimalist development are out there, e.g. Sinatra and similar frameworks that said X is too much- just use this.