[mvdanj]

Its disheartening to see so many duplicate efforts to solve the same problems everyone faces. Instead of supporting an existing open-source project that attempts to solve the problem in pretty much the same way (jspm), a conglomerate once again builds their own from scratch. I do not think the underlying motivations for doing so are questioned enough. Sure there is control, but it is of course anyway-you-slice-it an aggrandizement of their brand. We should be ashamed as a community to support the idea of yet ANOTHER client side dependency management system. How oh how did we ever solve this problem before Facebook came along and made Yarn in late 2016?

[tomdale]

I don't think it's fair to compare jspm and Yarn. jspm is an interesting project, but is tightly coupled with SystemJS. Telling everyone to rewrite their apps to use SystemJS and jspm is a huge lift.

Yarn, on the other hand, has focused on npm compatibility from the get-go. The entire point is to be a drop in replacement, with no changes (or maybe very very minimal changes) required to gain a lot of benefit.

In this slice of the industry where everyone is told they have to rewrite to the latest thing every year or two, I find it very refreshing to see Yarn's focus on backwards compatibility, improving existing infrastructure, and having a clear, painless adoption path.

[mvdanj]

I don't agree with any of your statements, and I think they are inaccurate.

jspm aims to be type-agnostic with respect to modules (supports all major types, hence why it is called a universal module loader). jspm certainly doesn't advocate rewriting your modules (you can use exports, AMD, ES6, whatever). In fact, when the browsers natively support module loading, systemJS will go away (which is really just a polyfill for this functionality).

jspm also has npm compatibility.