Live data from Hacker News

Huge no. of files for Angular 2

stackoverflow.com

91–100 of 105 posts

Re: Huge no. of files for Angular 2

#91
post #55

babel 6 with jsx transformer used to install a comparable number of files due to module duplication. At one point it was a 100M install with some modules being duplicated 45 times. Much of this was the fault of npm 2. But with latest babel and npm 3 it's now a 35M install with 5700 files over 814 directories. I guess that's considered lean by modern standards.

Just because of the way npm2 ordered the dependencies, the runtime of babel got incredibly slow [1]. Npm3 fixed that drastically, but I wonder how much is still wasted just because of navigating the file tree to the dependencies. [1]: https://github.com/babel/babelify/issues/206

The opposite is true - directory traversals themselves are effectively free, this is not going to be something that slows down your app - but loading the JS & creating the IR will be much slower. The 4 second startup time with npm2 & babel6 is almost certainly due to the duplicated dependencies, which means literally hundreds of megs of JS have to be parsed & warmed up. With npm3, the same files are (correctly) reused which significantly speeds up start time.

Re: Huge no. of files for Angular 2

#92
post #54

Earlier quoted context omitted.

But it is still possible to have the best of both worlds. Essentially, all they need to do is: 1. leave the current behavior for backwards compatibility; then 2. provide a flag like npm -G that exposes the correct behavior as suggested in the grand parent of using the same path like SHARED_DIR/node_modules/NAME/VERSION for package imports and package management. With time, newer npm versions will default to the corre…

The problem isn't in the "package manager" it's in node.js node loads modules in a given pattern. Changing that pattern would be global to your project, and would cause issues with tons of 3rd party tools. the best possible scenario would be to introduce a "new_node_modules" type directory and change to the new system, then look in "new_node_modules" first, then the legacy "node_modules" next, but that's a ton of wor…

node's module resolution will not likely ever be fixed. Too many modules depend on its undocumented implementation details and there isn't the will to improve it. A major source of problems is node's symlink resolution scheme that depends on fully resolved paths, counter to how other UNIX programs use files. Because many module developers know how the resolution scheme works they often hard code behaviors and paths into their code that would basically prevent any alternative module resolution scheme from working.

Re: Huge no. of files for Angular 2

#93
post #74

Earlier quoted context omitted.

My results of the hello world tutorial in Angular2 was 53 requests, 4933.49KB, and loaded in 1.74s on local dev, according to browser dev tools. All for one html file that had one h1 element. Plus, it started out broken. I had to search elsewhere to find the solution to the error the tutorial produced.

That's not a production build. Minify it, run dead code elimination. Exactly as you would with any other language with a compiler. Also, worth noting that the tutorial being broken isn't symptomatic of JS, that's a problem with Angular (which has a history of sucking, and IMO Angular 2 just takes all of the problems with Angular 1 and adds more baggage to it). Be aware as well that Angular 2 is a full-fledged Web Fra…

I'm confused by your response. I haven't claimed anything along the lines of your response nor am I implying anything about Angular nor JS. I simply just communicated my results from completing the tutorial.

Re: Huge no. of files for Angular 2

#94

Interesting fact that I recently came across: bower and many other npm packages, has some dependencies that eventually depends on a package called "wordwrap". And this "wordwrap" package somehow has its test folder exposed in npm. The result: Every single person using bower would have one or more copies of In Praise of Idleness by Bertrand Russell on your local machine, depending on how many of your projects has a np…

Very nice! The file can also be found by searching for "Saran finds some mischief", which fees like an apt phrase.

Satan, I think you'll find.

Re: Huge no. of files for Angular 2

#95
post #26

Interesting fact that I recently came across: bower and many other npm packages, has some dependencies that eventually depends on a package called "wordwrap". And this "wordwrap" package somehow has its test folder exposed in npm. The result: Every single person using bower would have one or more copies of In Praise of Idleness by Bertrand Russell on your local machine, depending on how many of your projects has a np…

Wasteful yet subversive

I don't know about you but I think the world can spare an extra 29kb.

Re: Huge no. of files for Angular 2

#96
post #83

Earlier quoted context omitted.

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.

Re: Huge no. of files for Angular 2

#97
post #90

Earlier quoted context omitted.

Just ignore your whole dev/code folder from Spotlight. It's not a good way to get to it anyway.

Is there an indexer in any operating system that's worth the aggravation? Windows Explorer's is hot garbage, and I've never been real impressed with any of the ones in my various Linux distributions. Old-school grepping or using Notepad++'s find in files feature is far away the best method I've come across, which is... kinda sad.

The indexing itself is great - I use Everything [1] heavily.

The client on the other hand? It's baaad.

[1] http://www.voidtools.com/

Re: Huge no. of files for Angular 2

#98
post #96

Earlier quoted context omitted.

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.

Re: Huge no. of files for Angular 2

#99

Earlier quoted context omitted.

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…

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.

Re: Huge no. of files for Angular 2

#100
post #28

Earlier quoted context omitted.

I was just about to write a comment to ask why it can't be done like this (using CAS / symlinks). So I guess it can. Are there any disadvantages to using ied over npm?

It does not support external packages from git remote url (github).

Update:

Looks like it is supported now:

https://github.com/alexanderGugel/ied/issues/7#issuecomment-...

Post reply on HN