Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Yarn – A new package manager for JavaScript

code.facebook.com

Post reply on HN
Print view View original

241–250 of 486 posts

Re: Yarn – A new package manager for JavaScript

#241

Post by wycats »

odbol_ wrote: post #182
bandrami wrote: post #131

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…

Compared to C/C++ tooling and package managers, npm is like taking a bazooka to a knife fight.

Is npm the bazooka or C++? As someone who's worked with C/C++ (and its hilarious explosion of tooling -- half-a-dozen at Google alone), maven, bundler and Cargo, I think it's just not accurate to say that the npm ecosystem has a particularly high level of complexity.

Re: Yarn – A new package manager for JavaScript

#243

Post by [deleted] »

RyanCavanaugh wrote: post #223
mambodog wrote: post #195

Earlier quoted context omitted.

> Flow, introduced 3 months after TypeScript Do you think Flow was built in 3 months as a reaction to Typescript? Not that it was a big enough problem that two different groups of people independently decided to try to solve it? EDIT: disregard this, Flow was introduced much longer than 3 months after TypeScript. The blog post introducing Flow mentions TypeScript, and is probably worth reading for background [1] > Nu…

TypeScript was released October 1, 2012. Flow was released November 18, 2014 Did Flow take 2 years to get implemented? I didn't think the initial release looked like a project that had 2 years of dev time on it.

[deleted]

Re: Yarn – A new package manager for JavaScript

#244

Post by wycats »

steveklabnik wrote: post #144
mvdanj wrote: post #126

Earlier quoted context omitted.

You say "decent performance" and "predictability". What is the basis of this claim? I've heard these all before, but unless you've actually shipped a product using this tool I don't know how you can back this up.

> unless you've actually shipped a product using this tool Given that wycats _worked on_ this tool, I would assume it's his experience helping build it that's the basis of the claim. (I don't work at Tilde so I can't tell you if it's been shipping with yarn, but it would shock me if it wasn't.)

We're not using Yarn at Tilde yet, but I've been using it on Yarn itself and when working on Ember packages, and it's worked well. As far as performance, we have good benchmarks tracking yarn's performance in a whole bunch of different scenarios (https://yarnpkg.com/en/compare)

Re: Yarn – A new package manager for JavaScript

#246

Post by bandrami »

fuzzy2 wrote: post #184
bandrami wrote: post #131

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…

You say tooling, but then talk about libraries. I think both are just as numerous for nearly all popular programming languages. It’s just that JavaScript is currently “hot shit”, so all this stuff is a lot more visible. There are tons of libraries for C, many of which aim to do the same, only faster/smaller/scalable/whatever. There are many compilers, both open and closed source. And there are documentation tools, sy…

You say tooling, but then talk about libraries.

Because, from this outsider's perspective, it seems like most of the tooling is library management (rather than, say, profiling or linting -- does javascript even have a linter? -- or debugging).

Re: Yarn – A new package manager for JavaScript

#248

Post by paradite »

bandrami wrote: post #131

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…

Let's consider Microsoft Office. It is a massive software and such as massive software requires a lot of (internal) dependencies and toolings.

Now imagine Office 365, the same software with the same functionalities, except running in the browsers. The task is to essentially write Microsoft Office (front-end logic) entirely in JavaScript (or TypeScript), with the additional problems of dealing with browser compatibilities issues, which are just as hard as OS compatibilities issues.

Then, imagine all the software going to the "cloud". JavaScript now has to have the capability of re-writing all these software originally written in C++, C#, Java... all sorts of languages. It is quickly becoming a superset of all ecosystems where everyone is trying to migrate their software to. So it is not surprising that people are inventing more and more tooling to make it more powerful to suit their needs.

Re: Yarn – A new package manager for JavaScript

#249

Post by evv »

jlongster wrote: post #191
emerongi wrote: post #96

Earlier quoted context omitted.

> Yarn pulls packages from registry.yarnpkg.com, which allows them to run experiments with the Yarn client. This is a proxy that pulls packages from the official npm registry, much like npmjs.cf.[0] Time will tell whether they only want to be proxying NPM or will allow direct pushing to their own registry. If they do, JS ecosystem might see another big shift. [0] http://blog.npmjs.org/post/151660845210/hello-yarn

That big shift will have to happen first. I don't see them ever making their own registry unless 99.99% of people are using yarn and are having a lot of problems with the current npm registry. While I see a lot of people using yarn, I'm not sure about 99.99% and I think npm's registry itself is pretty good. So I don't think interests will ever align to create a new registry. Nobody wants to do that. That would have s…

Why would it be a bad thing to support additional repositories? Personally, I don't like how centralized the JS ecosystem is.

For example, if I refer to 'left-pad', it would default to 'npmjs.org/left-pad'. If the author goes rougue, I think it would be great to enable people to publish and consume 'thirdparty.com/left-pad'

Disclosure: I'm a FB employee with no knowledge of our plans in this regard

Re: Yarn – A new package manager for JavaScript

#250

Post by erikpukinskis »

grayrest wrote: post #207
bandrami wrote: post #131

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…

> Are people really making projects with dozens (hundreds? more?) of dependent libraries? Yes. > Are there aspects of the language or runtime that reward multiple layers of configuration management? A significant fraction of the node community likes to split their project into really, really small packages and treat them as if they're independent even if they come from the same source repo and tend to get used togeth…

What do you find maddening about micro packages? I hate depending on a giant stack of frameworks (slowing installs, builds, adding behavior surface area) when I just need a function or two, so micro packages are a joy for me.
Post reply on HN