2 ms·
That sounds like poor tooling in JS, something solved by say, linkers, in other systems. And I'm not exaggerating about build times. A simple grunt build doing
by MichaelGG 12y ago
That sounds like poor tooling in JS, something solved by say, linkers, in other systems.
And I'm not exaggerating about build times. A simple grunt build doing some basic template stuff would take about 20 minutes. The majority of that time was bringing in the ~13,000 files a rather simple static website needed to build. I ended up tossing the idea of independent builds and just made a persistent build machine that symlinked in node_modules. I've got a million lines of C program that takes less time to fully compile and link.
- mattdesl 12y agoI would be curious to see what kind of tool could do this. It sounds like "tree shaking" (like dead code removal) which may be possible in the far future with ES6 imports. I imagine it would further add to build times. Not sure how your rant about grunt tasks and templating relates to small npm modules. A 20 minute build time sounds like something was vey wrong. My browserify (incremental) build time is < 100 ms which I can handle.
- MichaelGG 12y agoYeah perhaps current JS tools can't do dead code elimination because of the highly dynamic environment? Each module could provide some metadata on what it actually needs. I only target JS via cross compilers so I've never dealt with this problem. The small module system ends up requiring a ton of files, which is slow. Incremental builds don't really apply to a clean build server where you are basically doing "git clone ... && make". The actual processing isn't my complaint, just the enormous overhead npm's style imposes. I mentioned grunt since just having that plus uglify or so ends up bringing in 13k files or something.