1. 33

  2. 9

    Disclaimer: I’m only an onlooker of JS these days.

    Do JS programmers ever just flat out get tired of the fact that there’s a new tool for X that they should use every other week, where X is an element of the set { build tool, packaging tool, testing tool, web framework, front end framework, chart library, http client, ECMAscript version, compiler for ECMAscript today, yet another build tool only compatible with ECMAscript today, Promises library that works only with ECMAscript yesterday, Nevermind, this new one, with completely different ideas works with ECMAscript today, so we'll just use that one instead }

    I don’t mean to rag on JS developers, who do an incredible job in all parts of the stack. Obviously this is satire, but every time I see the words “A new ___________ for JavaScript” I ask the question to myself, “how does anyone keep up?” But, maybe this is exactly the reason that there are 3 JavaScript conferences every other week?

    1. 18

      It can be tiring, but I don’t know that Yarn is a good example of the problem. For one thing, Yarn is built on top of, and works with (rather than replaces) npm. Its relationship to npm is similar to the relationship between gem and Bundler. npm/gem do the fetching of the actual libraries, Yarn/Bundler manage the dependencies to make sure builds are easy and consistent. This is an area of real pain in JavaScript, and Yarn appears to make the situation a lot better than it would otherwise be. Now, instead of having to remember to shrinkwrap your dependencies, or make sure to always pass –save when installing with npm, you have a system that should just work correctly without much worry.

      1. 6

        That’s totally fair! I reacted to this post before really digging into what it meant.

      2. 4

        I ask the question to myself, “how does anyone keep up?”

        It very much depends on what you mean by “keep up.” I follow JS news relatively closely, but I don’t try out many new frameworks/libraries/build tools. The question I use to filter whether something is worth experimenting with is, “Is this actually likely to make my day to day work better in some way?” Very few things cross that threshold. Maybe a couple of largish things per year.

        Yarn seems like it is one of those few things. Lack of shrinkwrapping-by-default and dependency tree reproducibility are my two biggest pain points in managing JavaScript projects.

        EDIT: I should note that even now, I’m not planning on trying Yarn until it supports private package registries.

        1. 4

          It very much depends on what you mean by “keep up.”

          You sound like a smart developer, skeptical of trends, evaluates things on actually solving pain points, etc. That doesn’t seem very common anywhere, let alone the JS community (again, as an outsider looking in now and again).

          I haven’t seen much evidence that the bulk of JS advocates (e.g. those that regularly speak at conferences, have a blog that gets promoted, etc), feel the same way. In fact, it seems that they encourage their followers to “adopt or become irrelevant.” But, maybe this is self-perpetuating. As a “thought-leader” in the JS community, I’d, of course, have to keep up with trends so I can continue to travel on conference goers' dimes, and have my thought-leadering libraries and techniques be used by everyone to stay relevant.

      3. 7

        I joked this morning in #lobsters that they’re in the “embrace” stage with npm, “extend” will come in 6-9 months, and “extinguish” won’t be too far behind. And Justin Searls pointed out the mechanism: yarn fetches from a mirror of the npm registry. There’s an undocumented registry config setting for it.

        1. 8

          This was the first thing I pointed out on HN and reddit; the team says that it’s just a CNAME and that they have no intentions of even running a mirror. We’ll see.

        2. 5

          It’s interesting how the numbers put things in perspective: “The React Native package.json currently lists just 68 dependencies, but after running npm install the node_modules directory contains 121,358 files”.

          I had a similar experience when doing an npm install on a project, and ended up with a current directory weighting 350Mb+. To me, this is a sign that something is fundamentally wrong with NPM’s packaging ecosystem: over fragmentation, lack of well-thought building blocks, and too many alternatives. I don’t think you’d find that kind of complexity/bloat in things like CPAN, PyPI, etc, where it seems that the community is a little bit more structured.

          It would be worth investigating how packaging/modules guidelines influence the community of developers, and how it impacts the quality of the module ecosystem in the long run. I don’t use Perl, but I’ve always held CPAN in high regard for the quality of the packages.

          1. 1

            I’ve always wondered if the dependency sprawl is a byproduct of Javascript’s lack of good stdlib. In python and perl, you can get a ton of traction by solely using the stdlib (source: my job for years was restricted to using python’s stdlib). Javascript, not so much.

            1. 1

              It’s a bit of an unfair comparison. JavaScript the language (as it runs in browsers) is sparse and without a stdlib. But then again, Python doesn’t run in browsers (natively). A fairer comparison would be Node vs Python, and while Node doesn’t even come close to Python, it does provide a stdlib (link to doc) that will get you well on your way.

          2. 3

            The immediate and obvious reaction is “urgh why”, but they seem to have some pretty good reasons and they seem to be going about it the right way, reaching out to the community for requirements and setting development up in an open and community-oriented way.

            1. 10

              I’m under the impression that for a bunch of node developers, the immediate and obvious reaction was ‘Finally!’.

              These last few years I don’t count how many times I had to rm -rf node_modules to fix an unpredictable dependency issue, or how many times I had to rm -rf repos/*/node_modules to claim space back on my laptop because I had 20 repos with 500MB of dependencies in each of them.

              This project seems to solve both of these issues.

              1. 8

                As an engineer that works on a lot of Node software, the NPM client is always the least reliable part of the build process. I’m excited to see if we can use Yarn instead in the future, though we’ll need to finish migrating things to at least Node 4.X – there is no support for 0.12.X or earlier in Yarn.

                Early indications look good, though: the Yarn web site (and particularly the documentation) appears to be quite good, and the command line tool appears to work quickly and reliable in the quick test run I gave it today.

            2. 2

              I’m wondering if Facebook is going to start to replace npm next. Feels like they have been the major corporate sponsor of javascript in the browser as of late.

              1. 2

                It seems unlikely that they would try to or want to replace npm. As I mention in my comment to apg’s post, Yarn works on top of npm. It still uses the npm registry, and I can’t imagine Facebook would be interested in investing the time, energy, and money needed to replace that registry wholesale.