Live data from Hacker News

Yarn – A new package manager for JavaScript

code.facebook.com

451–460 of 486 posts

Re: Yarn – A new package manager for JavaScript

#451

This may come off as a troll, but it's an honest question. I'm not a javascript guy. It's not a language I deal with at all. Why on God's green earth does it need as much tooling as it seems to have? Are people really making projects with dozens (hundreds? more?) of dependent libraries? Are there aspects of the language or runtime that reward multiple layers of configuration management? In short, what the hell is up…

I have no idea if you're familiar with the java ecosystem, but I am, so I'll use that as an example: Node libraries are typically several orders of magnitude smaller and more single purpose than java libraries. Java libraries like Guava and Spring are typically quite large. A practical example is from unit testing: In Java, you might use JUnit+Mockito for your test dependencies. In Node, to get similar functionality,…

> It's a much newer technology than java

Strangely enough both Java and JavaScript were first released in May 1995. Server side JavaScript was released the same year just after the browser version.

Though I get that you are referring to the js eco systems (commonjs, npm) compared to the much more mature Java ecosystem.

Re: Yarn – A new package manager for JavaScript

#452
post #258

Earlier quoted context omitted.

In fairness to the language and tools, this seems to be more of a cultural problem than anything. You can do the same kind of version range tricks in typical Java builds, for example (Maven), but most people hardcode the values to keep builds as deterministic as possible. For some reason, the JS community seems to prefer just trusting that new versions won't break anything. Its either very brave of them really (or ma…

It's not a cultural problem. People make mistakes. People don't know what a non-breaking change is, especially those not well versed in refactor work. I don't think Yarn solves any of these problems, tbh. It seems like what we really need is a package manager that tests the api of each package update to make sure nothing in it has broken expectation in accordance with Semver.

It is a cultural problem in that people on other platforms (eg, Maven) don't choose floating dependency versions, generally.

Re: Yarn – A new package manager for JavaScript

#453
post #353

Earlier quoted context omitted.

IMO it's the "javascript way" to invent new tools instead of trying to improve others (when it makes sense to do so). Let me explain that a little bit... The javascript "ecosystem" takes the unix philosophy to the extreme in many ways. And one of the points of the unix philosophy is to try to avoid "bloating" tools with tons of options, and instead trying to create new tools where appropriate. Many of those are perfe…

> The javascript "ecosystem" takes the unix philosophy to the extreme in many ways. Bullshit, nix systems rely on stable global dependencies, not 50 versions of the same library installed locally. I don't buy the "unix philosophy" excuse. The nodejs community just doesn't care about API stability which is why there is that inflated number of modules with 90% never maintained more than a year.

> 50 versions of the same library installed locally

Are you seriously telling me you've never had a linker (static or dynamic) choose the wrong library?

Re: Yarn – A new package manager for JavaScript

#454
post #410

Earlier quoted context omitted.

Somewhat funny to have an FB employee complaining about overly centralized systems.

I used to find such comments funny until I began working for Big Name Corps myself and I realized how much one's personal philosophy could be inconsistent or sometimes even contradictory to the employer's philosophy. I make money by selling my skills to an employer despite inconsistent philosophies. I think it's like a chef that can cook meat for his/her guests although the chef has decided to refrain from consuming…

Yup. And such a chef probably wouldn't publicly berate people for eating meat, or expect being called out if they did.

Re: Yarn – A new package manager for JavaScript

#455
post #410

Earlier quoted context omitted.

Somewhat funny to have an FB employee complaining about overly centralized systems.

I used to find such comments funny until I began working for Big Name Corps myself and I realized how much one's personal philosophy could be inconsistent or sometimes even contradictory to the employer's philosophy. I make money by selling my skills to an employer despite inconsistent philosophies. I think it's like a chef that can cook meat for his/her guests although the chef has decided to refrain from consuming…

Yup. And such a chef probably wouldn't publicly berate people for eating meat, or expect being called out if they did.

Re: Yarn – A new package manager for JavaScript

#456
post #410

Earlier quoted context omitted.

I used to find such comments funny until I began working for Big Name Corps myself and I realized how much one's personal philosophy could be inconsistent or sometimes even contradictory to the employer's philosophy. I make money by selling my skills to an employer despite inconsistent philosophies. I think it's like a chef that can cook meat for his/her guests although the chef has decided to refrain from consuming…

Yup. And such a chef probably wouldn't publicly berate people for eating meat, or expect being called out if they did.

Yup. And I don't see anyone berating anybody in this thread. Do you?

Re: Yarn – A new package manager for JavaScript

#458

This is not a problem with the package manager. This is a problem with complexity. When did it start becoming reasonable for a front-end only part of the MVCC pattern to have 68 dependencies? Or for a transpiler like Babel to add 100k+ files? I'm sorry I just find it ridiculous that instead of taking a look at the disease (unbounded complexity), we are looking to engineer our way out of the problem by creating a pack…

The Javascript ecosystem has to deal with unrelenting, multi-decade backwards compatibility requirements; supporting numerous, inconsistent implementations; and an incredibly wide set of stakeholders and participants with diverse motivations when advancing the spec.

Do any other software platforms out there face the same magnitude of complications?

To speak to one of your primary examples: Babel is freaking huge and somewhat absurd, but is there any other way to advance the Javascript language? Fortunately, this is only a development dependency, and the client doesn't have to see it.

On a happier note, these are good problems to have. This is another indicator of how successful the web platform has become. You can build some absolutely incredible projects these days, and they are instantly available to billions of people who are operating thousands of different hardware devices (with different specs and dimensions) running dozens of operating systems. No gatekeeper, bureaucrat, or corporate curator must approve your work. Just simply deploy it, and anyone with the URL can access it. It is a mind-blowing human accomplishment. I look forward to seeing how the web continues to progress over the coming decades.

Re: Yarn – A new package manager for JavaScript

#460
post #22

This is a huge leap forward for the JavaScript community—probably more than many people will realize right away. I loved Bundler's deterministic builds but chafed against the Ruby limitation of only having a single version of a dependency at once. npm solved this problem elegantly, but still struggles with non-determinism. I had resigned myself to thinking that maybe these were just fundamental tradeoffs in package m…

Why do you think that everybody is inspired from javascript tech? It is probably the other way around. For example there were very good build tools long before npm which are still used today and unmeasurably better (like Maven or Gradle).
Post reply on HN