On Fri, 31 Jul 2015 at 11:50 Behrang Saeedzadeh <behran...@gmail.com> wrote:

Hello Behrang,

JSPM and SystemJS, IMHO, are not as elegant as the way Maven (Java) or
> Bundler (Ruby) can manage dependencies.
>

I am not contesting that, but it's worth describing what qualities of Maven
you're asking for.


> Group ID: com.google.guava
> <http://mvnrepository.com/artifact/com.google.guava>
> Artifact ID: guava
> <http://mvnrepository.com/artifact/com.google.guava/guava>
> Version: 18.0
> <http://mvnrepository.com/artifact/com.google.guava/guava/18.0>
>
> The short form notation is com.google.guava:guava:18.0.
>

With JSPM, package descriptors are of the form:

github:theefer/theseus@0.5.0
npm:theseus@0.5.0
etc.

The descriptor contains the registry resolver (e.g. github, npm, or any
custom one). The package name can contain namespacing, as in the github
example, if the registry supports it. The version is explicited and
supports semver.

Guava itself might depend on other dependencies, but you don't have to
> explicitly require them in your project. As long as you specify you require 
> com.google.guava:guava:18.0,
> all its dependencies are added to your project automatically.
>

JSPM/SystemJS also resolve, install and automatically import a package's
dependencies automatically.


> Most open source libraries are available in the Maven Central repository
> which is enabled by default. Users can additionally specify other
> repositories that Maven should query in order to find libraries with
> specific coordinates.
>

This is similar to what registries give you in JSPM.


> In SystemJS, baseURL looks similar to the notion of a Maven repository,
> but it is not as elegant: you can't have multiple baseURLs (if I am not
> wrong)
>

I'm not sure what you mean by that. If you're talking about your example
where you have a list of registries and fallback to the next if a package
isn't found in one, that seems rather like an anti-pattern on the web (esp
if these are going to be calls from your browser).

If it's just about not having to specify which repository contains a given
package, you're right, JSPM requires you to specify that, but it's really
not that much of a burden, and it also makes the resolution more
deterministic and robust given the variety of ways people package even the
same project to different repositories (e.g. AMD/CJS/UMD, build/sources,
etc).


> and dependencies are specified relative to the baseURL, not as absolute
> coordinates and not versioned.
>

Not sure what you mean by that but everything *is* versioned in JSPM and
you can lock the entire dependency tree (something that's less common in
Maven AFAIK).

Versions can be specified either at the top-level config, or even at the
import level, e.g.:

System.import('npm:lodash@3.10.0').then(function(_) {
  console.log(_.max([1, 2, 3, 4]));
});


> The call to System.import('com.modernizr:modernizr:2.8.3') will first
> query cdn.w3c.org for com.modernizr:modernizr:2.8.3. If found, it will
> use that, if not it queries cdn.google.com and then cdn.example.com until
> it finds it or fails.
>

You may be able to write a custom registry resolver that does something
like that, if you really think that's a good idea.


> Similarly the call to System.import('com.jquery:jquery-ui:1.11.4') will
> do the same thing, but as jquery-ui depends on jquery, it will also
> download that.
>

That'd already be the case.


> One benefit of this compared to what is already out there is that at the
> moment if Site A uses CDN 1 for loading jQuery v1 and Site B uses CDN 2 for
> the same version of jQuery, the browser has to download both versions. But
> with this approach, as long as both sites depend on 
> com.jquery:jquery-ui:1.11.4
> it only has to be downloaded once.
>

That's only true if they both happen to provide the list of repositories in
the same order. If not, they would each download jquery-ui from the first
in the list and hence download it twice. The only way to avoid that would
be to lookup if jquery-ui is in the browser cache for any of the
repositories in the list -- obviously this is not allowed by the browser
for security reasons.

Best,

PS: this discussion doesn't seem particularly relevant for es-discuss (?),
so if you want to reply it may be best to do so in private to me to avoid
unnecessary noise.

-- 

------------------------------
Visit theguardian.com. On your mobile and tablet, download the Guardian 
iPhone and Android apps theguardian.com/guardianapp and our tablet editions 
theguardian.com/editions.  Save up to 57% by subscribing to the Guardian 
and Observer - choose the papers you want and get full digital access. 
 Visit subscribe.theguardian.com

This e-mail and all attachments are confidential and may also be 
privileged. If you are not the named recipient, please notify the sender 
and delete the e-mail and all attachments immediately. Do not disclose the 
contents to another person. You may not use the information for any 
purpose, or store, or copy, it in any way.  Guardian News & Media Limited 
is not liable for any computer viruses or other material transmitted with 
or as part of this e-mail. You should employ virus checking software.
 
Guardian News & Media Limited is a member of Guardian Media Group plc. 
Registered 
Office: PO Box 68164, Kings Place, 90 York Way, London, N1P 2AP.  Registered 
in England Number 908396


_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to