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

351–360 of 486 posts

Re: Yarn – A new package manager for JavaScript

#351

Post by aikah »

stincity wrote: post #290

I get NPM for backend development but I don't understand why frontend developers require NodeJS just to utilize it's package management. It really does not make any sense to me considering that NodeJS is server side javascript. If my backend is Python or Go or .NET or Java or whatever, now I'll need NodeJS for the frontend and only for NPM (and now this). It's a reason why I don't enjoy dealing with "modern" frontend…

developers use node to compile whatever version of javascript they are using with a version that will run in most browsers without issues. It's also useful when concatenating and minifying assets. It's called an asset pipeline where you build a release, just like when you compile and package your Java,.NET or Go code before deploying it. Now of course javascript is a dynamic language and should not need all that stuff ... in theory ... but for some reasons developers love complexity. You can design the most simple system the most simple language, developers will find way to add layers of layers of complexity one way or another ... before going back to square one. It's interesting you are talking about Go. right now Go is quite simple, You bet your ass it will look like Java in 10 years just like Javascript is becoming more and more complex with tons of tools, transpilers and what not.

Re: Yarn – A new package manager for JavaScript

#352

Post by flukus »

bandrami wrote: post #246
fuzzy2 wrote: post #184

Earlier quoted context omitted.

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).

> does javascript even have a linter?

Yes, thousands of them, npm alone has 1200 results for linter:

https://www.npmjs.com/search?q=linter

Re: Yarn – A new package manager for JavaScript

#353

Post by aikah »

Klathmon wrote: post #186
bcherny wrote: post #168

I use JS+Node+NPM for my day job and many side projects. Initial thoughts: - Why didn't Facebook contribute the updates to NPM directly? - They are coupling a package manager and registry proxy; the latter has many existing implementations already - The differenced between Yarn and NPM+Shrinkwrap do not seem substantive; NPM made the design decision to use a sometimes non-deterministic install algo in NPM3 to speed u…

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.

Re: Yarn – A new package manager for JavaScript

#354

Post by flukus »

pluma wrote: post #114
epmatsw wrote: post #17

This looks awesome. But I have to wonder why create a whole new project rather than fork or upstream these changes to NPM? It doesn't seem like it's doing anything fundamentally different or outside of NPM's scope of responsibility.

Because the npm client is a hot mess? The official npm cli is quite old and evolved along with all the different coding styles and architecture choices of the node and JS ecosystems. It's also full of dependencies on originally purpose-built modules that suffer from the same problems. This compounds various issues, resulting in long-standing bugs like `npm publish` sometimes not actually including all files in the ta…

It's not old at all, it's first release was 2010.

Re: Yarn – A new package manager for JavaScript

#355

Post by dimal »

bandrami wrote: post #246
fuzzy2 wrote: post #184

Earlier quoted context omitted.

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).

JSLint, JSHint, ESLint. Each of which built on the good aspects of its predecessor and evolved as new requirements came up. There are a _ton_ of tooling libraries for JavaScript. Just google "X JavaScript" for any tooling you'd expect, and you'll usually have several options. Of course, on the flip side, people will complain that there are too many options. Blah blah blah. No matter what the JS community does, people will criticize.

Re: Yarn – A new package manager for JavaScript

#356

Post by Klathmon »

aikah wrote: post #353
Klathmon wrote: post #186

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.

Come on now, I said that it's like the unix philosophy in many ways, not that it's unix...

- Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".

Which is what this thread is about.

- Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.

JS has wonderful stream support, and it's used everywhere in many tools. This is probably where JS is the weakest out of these.

- Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them.

I mean, if JS isn't this taken to the extreme, i don't know what is...

- Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them.

This also describes JS to a T. Tons and tons of tools, each often only usable by a small number of people in niche situations.

Now i'm not saying that JS is as well designed as unix, i'm not saying that it's exactly the same as unix, i'm not saying that Unix doesn't do things better, or that JS doesn't have it's warts. I'm just saying that it's the "unix philosophy" taken to the extreme. It might not be good, it might not last, but it's working out pretty well for many people right now.

Re: Yarn – A new package manager for JavaScript

#357

Post by Lazare »

tigershark wrote: post #288
erikpukinskis wrote: post #250

Earlier quoted context omitted.

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.

Reading the article it seems to me that this micro packages approach is what slows down everything. I never, ever have seen all these problems in even not-so-state-of-the-art dependency managers like maven or nuget. Seriously up to now it was impossible to have a build server isolated from the internet if you didn't want to check-in all the dependencies??? Simply crazy. I really can't understand how people can even t…

> this micro packages approach is what slows down everything

Not really. The npm client is just flaky, very slow, buggy, has some major design flaws in its v2 incarnation, and has a completely different set of major design flaws in its v3 incarnation.

The core architecture works fine for small packages.

> Seriously up to now it was impossible to have a build server isolated from the internet if you didn't want to check-in all the dependencies

Of course not, although I admit the linked article implied it was if you didn't read closely. There's a wide number of solutions, including running a private registry, or a copy of the public registry, or a local cacheing proxy of the public repository, or a custom npm client that hits a local cache, etc. Some of the solutions work quite well, and in fact yarn itself is just a re-implementation of some existing solutions.

> I really can't understand how people can even think to use a dependency manager system that doesn't satisfy the essential requirement of having your CI server sandboxed.

As the article noted, Facebook was sandboxing their CI server and using NPM; they just didn't like the existing solutions. (Nor should they; they were a bit naff.) But that doesn't mean (nor is anyone claiming) that there were no existing solutions. Yarn looks great, but it's an extremely incremental change.

Re: Yarn – A new package manager for JavaScript

#358

Post by gell_mann »

This is a somewhat unrelated question. I'm a systems programmer (I spend most of my days in the land of C and Go). I do understand the basic concepts of web apps and how you develop one. I have even built a few websites using Rails.

Can somebody please explain to me: 1) How does npm fit in in the process of developing a web app. How does it manage the js files / libraries and where does it place them? 2) How is yarn going to make your life easier

Please go easy on me.

Re: Yarn – A new package manager for JavaScript

#359

Post by Lazare »

bandrami wrote: post #246
fuzzy2 wrote: post #184

Earlier quoted context omitted.

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).

JS has several linters, although ESLint is the one to pick if you're looking for one.

Re: Yarn – A new package manager for JavaScript

#360

Post by beefsack »

Is it just me, or does Facebook seem to create new competing tools and technologies more often than the other majors?

My inner-cynic makes me feel like everyone at Facebook is really young, as I've noticed a trait of inexperienced developers is to try to create new things over finding and improving existing tools.

In reality it could be something as simple as Facebook releasing more FOSS software than others, or maybe their releases having more visibility.

Either way, feels like Facebook like to pave their own way, for better or worse.

Post reply on HN