3 ms·
If you're applying idiomatic Nix to modern JS, I wouldn't be surprised - modern JS tends to involve installing thousands of packages by just combining them into
by geofft 6y ago
If you're applying idiomatic Nix to modern JS, I wouldn't be surprised - modern JS tends to involve installing thousands of packages by just combining them into a directory, but Nix doesn't want you to edit existing directories. So your dependency graph turns into a build-dependency graph, with each JS package requiring a full build of everything it depends on, and the Nix build system is presumably not optimized for fast turnaround times on five-line JS modules that don't even have a compilation step.
(Personally, I wouldn't try to apply idiomatic Nix to modern JS - I'd apply it to the major components like "my web server" and "my database library" and have "all the JS I depend on" as one big Nix package. That's not really a claim about Nix, I wouldn't try to apply idiomatic, say, Debian packaging to modern JS either. In both cases I'd still get about 90% of the benefit of using Nix/Debian as a delivery mechanism.)
The other thing that could be slow is if you start compiling all your dependencies, including gcc and node.js, from scratch. While there's some security benefit in doing so, the reality is that just about nobody actually does that. You'd want to set things up to use the precompiled packages, or at least set up your own cache server and have compiled binaries you trust but only do it once.
- joepie91_ 6y agoHi, JS developer here who uses Nix and who liberally makes use of single-responsibility modules. No, Nix does not need "hours" to build a modern JS project. Something else is going on here. Nix is slow, but not that slow. (With the limited information provided here, my first guess would be "someone turned off the binary cache because they don't trust prebuilt binaries, and now it recompiles the world from scratch because there are no prebuilt binaries anymore".)
- somatic 6y ago“who liberally makes use of single-responsibility modules” If your aim is precision of language, you should call this “400MB of unaudited and unauditable mystery code from the [total clowns]( https://github.com/babel/babel/pull/3646 https://github.com/babel/babel/pull/3646 )* who run the npm ecosystem.” Imagine [this]( https://medium.com/s/silicon-satire/i-peeked-into-my-node-modules-directory-and-you-wont-believe-what-happened-next-b89f63d21558 https://medium.com/s/silicon-satire/i-peeked-into-my-node-mo... )* but instead riddled with advertisers and intelligence agencies. Burn it down and start over. * Insert Markdown, etc.
- yawaramin 6y agoPart of the removed code: test("guy", function() { assert.equal(typeof babel.guy, "string"); }); Facepalming so hard right now
- somatic 6y agoThat’s a quality test. Don’t you feel more comfortable? Your browsing experience is in good hands.
- geofft 6y agoThank you for heavily derailing the productive, technically meaningful conversation I was having. Next time I won't say anything since apparently productive and technically meaningful conversations aren't what this site is for.
- joepie91_ 6y agoIn case you hadn't noticed, this was a joke commit. The code in question was never actually a real part of Babel.
- yawaramin 6y agoI assure you, I understand what an easter egg is. I was facepalming at the test, which was doing the equivalent of: expect(true).toBe(true)
- joepie91_ 6y agoPlease take your badly-informed language bashing elsewhere. I actually audit dependencies for a living, and the dependency model that JS uses is far, far preferable for auditability over the "monolithic tightly-coupled framework and a mountain of custom badly-maintained copy-pasted business logic" approach that is widely used elsewhere.
- somatic 6y ago
- yawaramin 6y agoI suspect that someone being the auditors who are suspicious of opaque binary caches and insist on building everything from scratch.
- joepie91_ 6y agoI don't know. If that were the case, I'd imagine they would know why their build was taking hours and that it wasn't a Nix problem.
- yawaramin 6y agoThat was my reading, based on the fact that they glossed over Nix itself and attributed most of the issues to code complexity.
- joepie91_ 6y agoIt explicitly says this, though: > while much of that build time is attributable to Nix's way of building dependencies And that part just doesn't make sense to me. I can't see any way in which specifically Nix's way of building dependencies would contribute to this. The compiling of the universe, sure, but then why mention Nix?
- yawaramin 6y agoIt does say that, but it's off in its own clause, then shifts focus away from it towards what seems like the focus of the auditors.
- somatic 6y agoThe term “modern JS” should be used only as a pejorative.
- dang 6y agoWould you please not post in the flamewar style to HN? It damages the container here (i.e. the capacity of this place to sustain curious conversation), and you unfortunately did it repeatedly in this thread. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html