New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

merge bower into npm, why aren't we using npm? #1520

Closed
jokeyrhyme opened this Issue Sep 16, 2014 · 41 comments

Comments

Projects
None yet
@jokeyrhyme

After reading through #1102 (comment) , it occurred to me that Bower and npm have distinctly different designs, strengths and weaknesses.

NPM stands for "no problem, meatbag" so there's nothing Node.JS or even JavaScript specific about it. There's some recent-ish precedent for using it for front-end packages:

I listened to http://nodeup.com/seventy , and the npm maintainers seemed open to pull requests that address reasons why people use bower over npm, in order to unify the community.

If possible, I think it would be terrific to have a serious discussion about:

  • why do people choose Bower?
  • why do people choose npm?
  • is much interest on this side regarding a unified community?
  • what would need to be implemented in npm in order to meet the needs of the Bower community?
@stuartpb

This comment has been minimized.

Show comment
Hide comment
@stuartpb

stuartpb Sep 16, 2014

The only benefit I see from using Bower is that it installs its modules in a separate directory. But, then, I guess cherry-picking front-end modules out of node_modules is what grunt/browserify is for.

IMHO, package.json could use a few extensions for a better npm that's less reliant on the overburdened npm registry (I wrote about this before, somewhere on the mailing list): perhaps it could be extended to read an object of node_modules and frontend_modules.

The only benefit I see from using Bower is that it installs its modules in a separate directory. But, then, I guess cherry-picking front-end modules out of node_modules is what grunt/browserify is for.

IMHO, package.json could use a few extensions for a better npm that's less reliant on the overburdened npm registry (I wrote about this before, somewhere on the mailing list): perhaps it could be extended to read an object of node_modules and frontend_modules.

@jokeyrhyme

This comment has been minimized.

Show comment
Hide comment
@jokeyrhyme

jokeyrhyme Sep 16, 2014

The npm registry seems more stable recently than it's ever been, but that is definitely a weakness of having a centralised registry. npm is gaining scopes which pave the way toward mixing modules from multiple registries.

The npm registry seems more stable recently than it's ever been, but that is definitely a weakness of having a centralised registry. npm is gaining scopes which pave the way toward mixing modules from multiple registries.

@jokeyrhyme

This comment has been minimized.

Show comment
Hide comment
@jokeyrhyme

jokeyrhyme Sep 16, 2014

From README.md:

There are no system wide dependencies,

There's no need to install npm packages globally, that's optional.

no dependencies are shared between different apps,

I think this follows on from above, so this is also not really a problem for npm.

and the dependency tree is flat.

There's continuing discussion about this in the npm community: npm/npm#4761

In fact there's a label for issues that contribute to improving the use of npm in adjacent JavaScript and front-end communities: https://github.com/npm/npm/labels/i-wanna-be-the-very-best

From README.md:

There are no system wide dependencies,

There's no need to install npm packages globally, that's optional.

no dependencies are shared between different apps,

I think this follows on from above, so this is also not really a problem for npm.

and the dependency tree is flat.

There's continuing discussion about this in the npm community: npm/npm#4761

In fact there's a label for issues that contribute to improving the use of npm in adjacent JavaScript and front-end communities: https://github.com/npm/npm/labels/i-wanna-be-the-very-best

@sheerun sheerun added the discussion label Sep 28, 2014

@jokeyrhyme

This comment has been minimized.

Show comment
Hide comment
@jokeyrhyme

jokeyrhyme Nov 4, 2014

Interesting to read about identified issues with using NPM for dependency management for front-end projects, and how they'll be trying to solve them:
http://blog.npmjs.org/post/101775448305/npm-and-front-end-packaging

Interesting to read about identified issues with using NPM for dependency management for front-end projects, and how they'll be trying to solve them:
http://blog.npmjs.org/post/101775448305/npm-and-front-end-packaging

@donaldpipowitch

This comment has been minimized.

Show comment
Hide comment
@donaldpipowitch

donaldpipowitch Nov 5, 2014

I really like the statements from the npm blog. It seems npm is open to a collaboration for more custom solutions like Bower. It seems Bower could be fully integrated with the following assumptions:

  • npm CLI will be modularized in the future: Bower can take what it needs (maybe even shrinkwrapping for free) and add or change stuff that doesn't fit (custom bower directory with flat dependencies).
  • package.json explicitly allows metadata: Things that bower.json needs ("main" must be an array, "resolutions" for conflicts) can be a bower-prefixed part of package.json.
  • Use npm's ecosystems feature for scoped search: Bower will be synonymic to frontend-compatible assets with a certain metadata format.

I really like the statements from the npm blog. It seems npm is open to a collaboration for more custom solutions like Bower. It seems Bower could be fully integrated with the following assumptions:

  • npm CLI will be modularized in the future: Bower can take what it needs (maybe even shrinkwrapping for free) and add or change stuff that doesn't fit (custom bower directory with flat dependencies).
  • package.json explicitly allows metadata: Things that bower.json needs ("main" must be an array, "resolutions" for conflicts) can be a bower-prefixed part of package.json.
  • Use npm's ecosystems feature for scoped search: Bower will be synonymic to frontend-compatible assets with a certain metadata format.
@sheerun

This comment has been minimized.

Show comment
Hide comment
@sheerun

sheerun Nov 5, 2014

Contributor

@donaldpipowitch About your question in #1588

Will you consider to change Bower into a subpart of npm in the future?

"subpart of npm" means utilizing npm as much as possible and use npm's upcoming features like ecosystems.

So you're asking whether we want npm to be subpart of bower, not the other way.

I think it's interesting concept, and bower could re-use some parts of npm ecosystem. Why not. For example we could add npm packages as an additional provider. We won't use npm's resolution process though, because npm doesn't support git / svn sources and flattening dependencies.

Please describe in what other ways you imagine this "integration".

Contributor

sheerun commented Nov 5, 2014

@donaldpipowitch About your question in #1588

Will you consider to change Bower into a subpart of npm in the future?

"subpart of npm" means utilizing npm as much as possible and use npm's upcoming features like ecosystems.

So you're asking whether we want npm to be subpart of bower, not the other way.

I think it's interesting concept, and bower could re-use some parts of npm ecosystem. Why not. For example we could add npm packages as an additional provider. We won't use npm's resolution process though, because npm doesn't support git / svn sources and flattening dependencies.

Please describe in what other ways you imagine this "integration".

@donaldpipowitch

This comment has been minimized.

Show comment
Hide comment
@donaldpipowitch

donaldpipowitch Nov 5, 2014

So you're asking whether we want npm to be subpart of bower, not the other way.

Sorry, for misleading you. I sometimes have problems explaining things correctly (non-native speaker).

We won't use npm's resolution process though, because npm doesn't support git / svn sources and flattening dependencies.

It looks like the future modularization of npm allows to override such behavior if needed.

Please describe in what other ways you imagine this "integration".

As describes above: utilize npm's ecosystems and switch from bower.json to package.json with bower-specific metadata. This would allow package maintainers to stop supporting two different registries and manifest files.

So you're asking whether we want npm to be subpart of bower, not the other way.

Sorry, for misleading you. I sometimes have problems explaining things correctly (non-native speaker).

We won't use npm's resolution process though, because npm doesn't support git / svn sources and flattening dependencies.

It looks like the future modularization of npm allows to override such behavior if needed.

Please describe in what other ways you imagine this "integration".

As describes above: utilize npm's ecosystems and switch from bower.json to package.json with bower-specific metadata. This would allow package maintainers to stop supporting two different registries and manifest files.

@nickmccurdy

This comment has been minimized.

Show comment
Hide comment
@nickmccurdy

nickmccurdy Nov 5, 2014

The npm blog just had an awesome post on npm and front-end packaging. It mentions a lot of ideas for both npm itself and new front-end packaging solutions using npm, and also mentions bower specifically. Hopefully this will have some more useful information, and I'd be happy to join this discussion since it seems like a great idea to integrate the two tools together.

The npm blog just had an awesome post on npm and front-end packaging. It mentions a lot of ideas for both npm itself and new front-end packaging solutions using npm, and also mentions bower specifically. Hopefully this will have some more useful information, and I'd be happy to join this discussion since it seems like a great idea to integrate the two tools together.

@sheerun

This comment has been minimized.

Show comment
Hide comment
@sheerun

sheerun Nov 5, 2014

Contributor

As far as I can tell ecosystems will be only useful for searching certain classes of package. They'll be like tags for npm packages. I don't know how to utilize them, especially they'll be "constantly changing".

The only way I see such integration could more or less work out:

  1. Npm allows for installation of packages from only one ecosystem
  2. Package can be added to ecosystem only if all its dependencies also belong to given ecosystem.
  3. Ecosystems allow to add metadata to package.json of already published packages.

As for package.json: bower used to support both component.json and package.json but it turned out to be bad idea, so bower created bower.json. See #62 or #98 and much more.

@nicolasmccurdy This post was already mentioned in this thread.

Contributor

sheerun commented Nov 5, 2014

As far as I can tell ecosystems will be only useful for searching certain classes of package. They'll be like tags for npm packages. I don't know how to utilize them, especially they'll be "constantly changing".

The only way I see such integration could more or less work out:

  1. Npm allows for installation of packages from only one ecosystem
  2. Package can be added to ecosystem only if all its dependencies also belong to given ecosystem.
  3. Ecosystems allow to add metadata to package.json of already published packages.

As for package.json: bower used to support both component.json and package.json but it turned out to be bad idea, so bower created bower.json. See #62 or #98 and much more.

@nicolasmccurdy This post was already mentioned in this thread.

@sheerun

This comment has been minimized.

Show comment
Hide comment
@sheerun

sheerun Nov 5, 2014

Contributor

For backward compatibility we'd need also something like "ecosystem aliases". For example in npm's registry package would be visible as bower-underscore, but in bower's ecosystem as underscore.

Does npm allow to add metadata to whole packages? Not only their versions?

Contributor

sheerun commented Nov 5, 2014

For backward compatibility we'd need also something like "ecosystem aliases". For example in npm's registry package would be visible as bower-underscore, but in bower's ecosystem as underscore.

Does npm allow to add metadata to whole packages? Not only their versions?

@seldo

This comment has been minimized.

Show comment
Hide comment
@seldo

seldo Nov 6, 2014

Hi! Interested to see this thread.

Some minor points of clarification and answers to questions:

  1. package.json does support git as a source: https://www.npmjs.org/doc/files/package.json.html#git-urls-as-dependencies
    Not SVN right now, but it's coming (in the form of svn:// URLs)
  2. the "ecosystem alias" is an interesting idea, though obviously in the case of packages like underscore which already exist in npm in exactly the same form as they do in bower, that wouldn't be necessary ("npm install underscore" brings in a package that has a bower.json today).
  3. Yes, package-level metadata exists.
  4. We don't support flattening dependencies yet; that's the value we think bower adds.

Here's how a Bower ecosystem would work: the Bower project would create a module called, e.g. bower-validate, something very close to which I imagine already exists, which reads a package.json (or a bower.json) and checks that all the fields it needs are present and contain legal values. Bower publishes that module to npm and we turn it into the validator for an ecosystem called bower. After that, every time a new package is created or updated, bower-validate will be run against it, and if it passes, that package will turn up in searches of the Bower ecosystem.

bower-validate is completely arbitrary code. It can statically analyze the JSON, recursively analyze the sub-packages, make an API call, whatever it wants (which is why adding a new ecosystem to npm will be a manual process). It can be as strict or as loose as the Bower project decides makes sense.

Thereafter, anybody can publish a Bower-compatible package to npm using npm publish, and npm will take care of serving the packages, indexing them in search, and rich user-management stuff like multiple maintainers, etc..

For its part, Bower could use npm's (still under refactoring) modular components to download packages (either from npm's registry, or from git or arbitrary URLs just as at present) and to maintain the local cache of packages to prevent lots of duplicate downloads. Bower would take care of the installation step, i.e. putting the packages into the flat structure.

Potential advantages of this hypothetical arrangement:

  • Bower would no longer have to maintain a separate registry and search site (it would still have the ability to define "what is a bower package")
  • authors would no longer need to maintain separate bower.json and package.json files
  • authors would get richer administration abilities than are available on the current bower site (e.g. not requiring PRs for various things)
  • there would be a single place to find both server and client-side packages, and richer search
  • npm users would be able to install bower packages into non-bower contexts if they wanted to, and (maybe) vice versa

I'm not familiar enough with the package.json vs. bower.json issues to know how problematic the metadata conflicts are, and I'm sure there are other potential problems and bits where I lack full understanding of how bower works, but I'm interested to hear what you think of these ideas so far. Basically, we would like to make npm-the-registry a platform to build Bower on top of, playing to the strengths of both, without requiring bower users switch to npm-the-cli.

seldo commented Nov 6, 2014

Hi! Interested to see this thread.

Some minor points of clarification and answers to questions:

  1. package.json does support git as a source: https://www.npmjs.org/doc/files/package.json.html#git-urls-as-dependencies
    Not SVN right now, but it's coming (in the form of svn:// URLs)
  2. the "ecosystem alias" is an interesting idea, though obviously in the case of packages like underscore which already exist in npm in exactly the same form as they do in bower, that wouldn't be necessary ("npm install underscore" brings in a package that has a bower.json today).
  3. Yes, package-level metadata exists.
  4. We don't support flattening dependencies yet; that's the value we think bower adds.

Here's how a Bower ecosystem would work: the Bower project would create a module called, e.g. bower-validate, something very close to which I imagine already exists, which reads a package.json (or a bower.json) and checks that all the fields it needs are present and contain legal values. Bower publishes that module to npm and we turn it into the validator for an ecosystem called bower. After that, every time a new package is created or updated, bower-validate will be run against it, and if it passes, that package will turn up in searches of the Bower ecosystem.

bower-validate is completely arbitrary code. It can statically analyze the JSON, recursively analyze the sub-packages, make an API call, whatever it wants (which is why adding a new ecosystem to npm will be a manual process). It can be as strict or as loose as the Bower project decides makes sense.

Thereafter, anybody can publish a Bower-compatible package to npm using npm publish, and npm will take care of serving the packages, indexing them in search, and rich user-management stuff like multiple maintainers, etc..

For its part, Bower could use npm's (still under refactoring) modular components to download packages (either from npm's registry, or from git or arbitrary URLs just as at present) and to maintain the local cache of packages to prevent lots of duplicate downloads. Bower would take care of the installation step, i.e. putting the packages into the flat structure.

Potential advantages of this hypothetical arrangement:

  • Bower would no longer have to maintain a separate registry and search site (it would still have the ability to define "what is a bower package")
  • authors would no longer need to maintain separate bower.json and package.json files
  • authors would get richer administration abilities than are available on the current bower site (e.g. not requiring PRs for various things)
  • there would be a single place to find both server and client-side packages, and richer search
  • npm users would be able to install bower packages into non-bower contexts if they wanted to, and (maybe) vice versa

I'm not familiar enough with the package.json vs. bower.json issues to know how problematic the metadata conflicts are, and I'm sure there are other potential problems and bits where I lack full understanding of how bower works, but I'm interested to hear what you think of these ideas so far. Basically, we would like to make npm-the-registry a platform to build Bower on top of, playing to the strengths of both, without requiring bower users switch to npm-the-cli.

@donaldpipowitch

This comment has been minimized.

Show comment
Hide comment
@donaldpipowitch

donaldpipowitch Nov 6, 2014

Thank you @seldo for participating in this discussion. I ♥ these ideas.

Thank you @seldo for participating in this discussion. I ♥ these ideas.

@sheerun

This comment has been minimized.

Show comment
Hide comment
@sheerun

sheerun Nov 6, 2014

Contributor

the "ecosystem alias" is an interesting idea, though obviously in the case of packages like underscore which already exist in npm in exactly the same form as they do in bower, that wouldn't be necessary

Yes, some ecosystem aliases could match global registry names. Also, maybe bower could use npm: prefix for ecosystem aliases to import npm packages and create its own underscore package. You see, often github tags don't match what's uploaded to npm. So bower's and npm's underscore is not necessarily 100% compatible. I'd vote to create build farm for bower's packages and let bower manage and build its own packages. In case of build farm it would help if npm made ecosystems versioned, so we can rebuild our packages from time to time and improve bower-validate what could potentially remove some package from ecosystem.

I like idea of bower-validate, except I'm not sure if it needs to be called automatically. I think it would be better if we also had manual control over what packages are allowed (on the other hand validation script could check our registry if package is allowed, but we should be able to re-trigger validation).

@seldo Could you send me links to npm components you're mentioning? For bower we desperately need: generalized dependency resolver (implementing some kind of DCSP), dependency downloader, dependency caching manager (preferably storing cache in .tar.gz, to avoid too many files).

Thereafter, anybody can publish a Bower-compatible package to npm using npm publish

I don't think bower wants that. I think what we want is pass to our ecosystem only packages that can be built by 3rd party (e.g. we want to allow developers to download sources and build package themselves), and optionally create our own build farm that caches builds (like homebrew) and publishes them to npm. Developer would only create a tag on github. Bower would download tag, validate it, build it and publish / e-mail developer something's wrong. I think we need more fine-grained control over bower's ecosystem, including mentioned versioning.

I'd be happy to answer any ideas about this integration from bower's perspective.

Contributor

sheerun commented Nov 6, 2014

the "ecosystem alias" is an interesting idea, though obviously in the case of packages like underscore which already exist in npm in exactly the same form as they do in bower, that wouldn't be necessary

Yes, some ecosystem aliases could match global registry names. Also, maybe bower could use npm: prefix for ecosystem aliases to import npm packages and create its own underscore package. You see, often github tags don't match what's uploaded to npm. So bower's and npm's underscore is not necessarily 100% compatible. I'd vote to create build farm for bower's packages and let bower manage and build its own packages. In case of build farm it would help if npm made ecosystems versioned, so we can rebuild our packages from time to time and improve bower-validate what could potentially remove some package from ecosystem.

I like idea of bower-validate, except I'm not sure if it needs to be called automatically. I think it would be better if we also had manual control over what packages are allowed (on the other hand validation script could check our registry if package is allowed, but we should be able to re-trigger validation).

@seldo Could you send me links to npm components you're mentioning? For bower we desperately need: generalized dependency resolver (implementing some kind of DCSP), dependency downloader, dependency caching manager (preferably storing cache in .tar.gz, to avoid too many files).

Thereafter, anybody can publish a Bower-compatible package to npm using npm publish

I don't think bower wants that. I think what we want is pass to our ecosystem only packages that can be built by 3rd party (e.g. we want to allow developers to download sources and build package themselves), and optionally create our own build farm that caches builds (like homebrew) and publishes them to npm. Developer would only create a tag on github. Bower would download tag, validate it, build it and publish / e-mail developer something's wrong. I think we need more fine-grained control over bower's ecosystem, including mentioned versioning.

I'd be happy to answer any ideas about this integration from bower's perspective.

@stuartpb

This comment has been minimized.

Show comment
Hide comment
@stuartpb

stuartpb Nov 11, 2014

I actually have another proposal lightly mocked up for how I'd like to see a unified package manager work. It'd benefit from being able to have npm's recursive retrieval logic accessible as a function call (rather than just doing cd node_modules/whatever && npm install), so I'll want to stay in the loop for developments on the modularization front there.

I actually have another proposal lightly mocked up for how I'd like to see a unified package manager work. It'd benefit from being able to have npm's recursive retrieval logic accessible as a function call (rather than just doing cd node_modules/whatever && npm install), so I'll want to stay in the loop for developments on the modularization front there.

@kevinSuttle

This comment has been minimized.

Show comment
Hide comment
@kevinSuttle

kevinSuttle Dec 10, 2014

Really glad to see the work being done between Bower and NPM to better the FED tool chain ecosystems. Can't wait to get to a resolution.

Really glad to see the work being done between Bower and NPM to better the FED tool chain ecosystems. Can't wait to get to a resolution.

@jokeyrhyme

This comment has been minimized.

Show comment
Hide comment
@jokeyrhyme

jokeyrhyme Feb 14, 2015

http://blog.npmjs.org/post/110924823920/npm-weekly-5:

With npm@3, your node_modules directory will be a lot flatter. All of your dependencies and most of your subdependencies (and (sub)+dependencies) will be sitting next to each other at the top level. Only when there are conflicts will modules be installed at deeper levels.

Nice!

http://blog.npmjs.org/post/110924823920/npm-weekly-5:

With npm@3, your node_modules directory will be a lot flatter. All of your dependencies and most of your subdependencies (and (sub)+dependencies) will be sitting next to each other at the top level. Only when there are conflicts will modules be installed at deeper levels.

Nice!

@jokeyrhyme

This comment has been minimized.

Show comment
Hide comment
@jokeyrhyme

jokeyrhyme Apr 10, 2015

Possible related discussion: #1600

Possible related discussion: #1600

@patrickkettner

This comment has been minimized.

Show comment
Hide comment
@patrickkettner

patrickkettner Apr 10, 2015

Member

how is that related?

Member

patrickkettner commented Apr 10, 2015

how is that related?

@jokeyrhyme

This comment has been minimized.

Show comment
Hide comment
@jokeyrhyme

jokeyrhyme Apr 10, 2015

@patrickkettner well, shrinkwrap is something npm does, and it's functionality that is wanted in bower. I figured it was worth linking to as far as the npm/bower discussion goes...

@patrickkettner well, shrinkwrap is something npm does, and it's functionality that is wanted in bower. I figured it was worth linking to as far as the npm/bower discussion goes...

@patrickkettner

This comment has been minimized.

Show comment
Hide comment
@patrickkettner

patrickkettner Apr 10, 2015

Member

I believe that is about using npm's shrinkwrapping feature for the bower binary, not including a feature in the library itself.

Member

patrickkettner commented Apr 10, 2015

I believe that is about using npm's shrinkwrapping feature for the bower binary, not including a feature in the library itself.

@jokeyrhyme

This comment has been minimized.

Show comment
Hide comment
@jokeyrhyme

jokeyrhyme Jun 25, 2015

NPM 3 is in beta, and will be released soon:
http://blog.npmjs.org/post/122450408965/npm-weekly-20-npm-3-is-here-ish

NPM 3 installs dependencies as flat as possible, unless there are conflicts:
https://github.com/npm/npm/blob/multi-stage/CHANGELOG.md#flat-flat-flat

Once NPM 3 drops the "beta" flag, there'll likely be little reason to favour Bower.

NPM 3 is in beta, and will be released soon:
http://blog.npmjs.org/post/122450408965/npm-weekly-20-npm-3-is-here-ish

NPM 3 installs dependencies as flat as possible, unless there are conflicts:
https://github.com/npm/npm/blob/multi-stage/CHANGELOG.md#flat-flat-flat

Once NPM 3 drops the "beta" flag, there'll likely be little reason to favour Bower.

@nicklasb

This comment has been minimized.

Show comment
Hide comment
@nicklasb

nicklasb Aug 2, 2015

I would recommend you people to take a look at jspm/SystemJS, it really makes up for all the differences. And uses, a suggested, some extra fields in package.json. However, it does have its own registry. The upside is that it means packages doesn't have to be in npm, it can take them directly from github. If a package is npm-compatible, it is likely to work with jspm.

But the big point is that it takes care of the module loading and management without manually maintained config files like RequireJS.

nicklasb commented Aug 2, 2015

I would recommend you people to take a look at jspm/SystemJS, it really makes up for all the differences. And uses, a suggested, some extra fields in package.json. However, it does have its own registry. The upside is that it means packages doesn't have to be in npm, it can take them directly from github. If a package is npm-compatible, it is likely to work with jspm.

But the big point is that it takes care of the module loading and management without manually maintained config files like RequireJS.

@donaldpipowitch

This comment has been minimized.

Show comment
Hide comment
@donaldpipowitch

donaldpipowitch Aug 2, 2015

Right, but jspm is focused on JS, right ? I always liked Bower for being language agnostic, so it can be used with Less easily. But I really hope these non-js cases are solved with npm in the next years.

Right, but jspm is focused on JS, right ? I always liked Bower for being language agnostic, so it can be used with Less easily. But I really hope these non-js cases are solved with npm in the next years.

@nicklasb

This comment has been minimized.

Show comment
Hide comment
@nicklasb

nicklasb Aug 2, 2015

Not sure what you mean by language-agnostic. There is no client side code on the web that isn't Javascript. Even less less.js. (pun intended)

While jspm can serve any file, it has plug-ins for most things. Even less. Puns galore. :-)

nicklasb commented Aug 2, 2015

Not sure what you mean by language-agnostic. There is no client side code on the web that isn't Javascript. Even less less.js. (pun intended)

While jspm can serve any file, it has plug-ins for most things. Even less. Puns galore. :-)

@patrickkettner

This comment has been minimized.

Show comment
Hide comment
@patrickkettner

patrickkettner Aug 2, 2015

Member

Language agnostic means css, html, plaintext, C, java. It just serves an
endpoint.

On Sun, Aug 2, 2015, 1:57 PM Nicklas Börjesson notifications@github.com
wrote:

Not sure what you mean by language-agnostic. There is no client side code
on the web that isn't Javascript. Even less less.js. (pun intended)

While jspm can serve any file, it has plug-ins for most things. Even
less https://github.com/Aaike/jspm-less-plugin. Puns galore. :-)


Reply to this email directly or view it on GitHub
#1520 (comment).

Member

patrickkettner commented Aug 2, 2015

Language agnostic means css, html, plaintext, C, java. It just serves an
endpoint.

On Sun, Aug 2, 2015, 1:57 PM Nicklas Börjesson notifications@github.com
wrote:

Not sure what you mean by language-agnostic. There is no client side code
on the web that isn't Javascript. Even less less.js. (pun intended)

While jspm can serve any file, it has plug-ins for most things. Even
less https://github.com/Aaike/jspm-less-plugin. Puns galore. :-)


Reply to this email directly or view it on GitHub
#1520 (comment).

@nicklasb

This comment has been minimized.

Show comment
Hide comment
@nicklasb

nicklasb Aug 2, 2015

Oh, I know what the expression means, I was not understanding in what way jspm wasn't.
Sorry, could perhaps been clearer.

nicklasb commented Aug 2, 2015

Oh, I know what the expression means, I was not understanding in what way jspm wasn't.
Sorry, could perhaps been clearer.

@donaldpipowitch

This comment has been minimized.

Show comment
Hide comment
@donaldpipowitch

donaldpipowitch Aug 2, 2015

If I'm not wrong jspm has one main file while Bower always supported an array of main files. Very handy, because my Web Components, directives, whatever often come with a JS and Less file (sometimes even more). That's one thing why I initially liked Bower...

If I'm not wrong jspm has one main file while Bower always supported an array of main files. Very handy, because my Web Components, directives, whatever often come with a JS and Less file (sometimes even more). That's one thing why I initially liked Bower...

@nicklasb

This comment has been minimized.

Show comment
Hide comment
@nicklasb

nicklasb Aug 2, 2015

Well, a jspm-package has one main file, an entry point. But that doesn't mean it can't load multiple files.
For example an ES 6 import "packagename/css/cssfile.css!" imports a css file(if you have the css plugin).

And you can obviously always manually load it directly from the jspm_packages/ folder in a <link href="/jspm-packages/packagename/css/cssfile.css" rel="stylesheet" type="text/css" media="print">.

A package in jspm/npm/github can contain any kind of file just like bower can. Or am I not understanding what you mean?

nicklasb commented Aug 2, 2015

Well, a jspm-package has one main file, an entry point. But that doesn't mean it can't load multiple files.
For example an ES 6 import "packagename/css/cssfile.css!" imports a css file(if you have the css plugin).

And you can obviously always manually load it directly from the jspm_packages/ folder in a <link href="/jspm-packages/packagename/css/cssfile.css" rel="stylesheet" type="text/css" media="print">.

A package in jspm/npm/github can contain any kind of file just like bower can. Or am I not understanding what you mean?

@donaldpipowitch

This comment has been minimized.

Show comment
Hide comment
@donaldpipowitch

donaldpipowitch Aug 3, 2015

I think you understand what I mean, but your examples show the problem: if I start to manually import certain files I loose a lot of the benefits of a package manager. If this would be enough we could have used npm all the time.

I think you understand what I mean, but your examples show the problem: if I start to manually import certain files I loose a lot of the benefits of a package manager. If this would be enough we could have used npm all the time.

@jokeyrhyme

This comment has been minimized.

Show comment
Hide comment
@jokeyrhyme

jokeyrhyme Aug 3, 2015

@donaldpipowitch (and @nicklasb @patrickkettner): is there an issue filed against NPM for your use case and what is missing? I'm sure there are people in the NPM community who sympathise with you but won't find these comments here in the Bower project (do link back here if you file anything).

@donaldpipowitch (and @nicklasb @patrickkettner): is there an issue filed against NPM for your use case and what is missing? I'm sure there are people in the NPM community who sympathise with you but won't find these comments here in the Bower project (do link back here if you file anything).

@nicklasb

This comment has been minimized.

Show comment
Hide comment
@nicklasb

nicklasb Aug 3, 2015

But I don't want to automatically load all files, as that would be detrimental to performance and increase server load. I want to load them when I need them.

That is why I have the import-statements in the code, and that is one of the main benefits of SystemJS and modules.
Also, with good integration, the import statements tell my IDE what to show to me. ES 6 modules and import statements are a huge feature, something I have waited years for to get on the front end.

Using jspm you can then not only install (jspm install jquery) the module, a config file is automatically generated that is used in deployment to satisfy run time dependencies. That is another thing I like about it, the clear distinction between run time and design time dependencies, not that that is a major feature or anything.

nicklasb commented Aug 3, 2015

But I don't want to automatically load all files, as that would be detrimental to performance and increase server load. I want to load them when I need them.

That is why I have the import-statements in the code, and that is one of the main benefits of SystemJS and modules.
Also, with good integration, the import statements tell my IDE what to show to me. ES 6 modules and import statements are a huge feature, something I have waited years for to get on the front end.

Using jspm you can then not only install (jspm install jquery) the module, a config file is automatically generated that is used in deployment to satisfy run time dependencies. That is another thing I like about it, the clear distinction between run time and design time dependencies, not that that is a major feature or anything.

@nicklasb

This comment has been minimized.

Show comment
Hide comment
@nicklasb

nicklasb Aug 3, 2015

@jokeyrhyme : I am not trying to get sympathy, but clearing up what I feel is something of a misunderstanding, having multiple main entry points, which I do not really see the point with, especially with ES 6 and all is not something I would push for.
(Edited)

nicklasb commented Aug 3, 2015

@jokeyrhyme : I am not trying to get sympathy, but clearing up what I feel is something of a misunderstanding, having multiple main entry points, which I do not really see the point with, especially with ES 6 and all is not something I would push for.
(Edited)

@Enelar

This comment has been minimized.

Show comment
Hide comment
@Enelar

Enelar Oct 9, 2015

Sorry for being impolite, but could you clarify strong and weak points of both for end-user?
I read whole thread. But im not sure, is flat-tree good or bad, and when, and so on.
I think wiki page will be great.

Enelar commented Oct 9, 2015

Sorry for being impolite, but could you clarify strong and weak points of both for end-user?
I read whole thread. But im not sure, is flat-tree good or bad, and when, and so on.
I think wiki page will be great.

@PowerKiKi

This comment has been minimized.

Show comment
Hide comment
@PowerKiKi

PowerKiKi Oct 9, 2015

@Enelar if you don't have a strong opinion on the matter go with npm 3 (npm install -g npm@latest) and forget about bower. Multiplying package manager in your project is not a good idea for your workflow and chances are very high that you will require npm for something anyway (build tools such as grunt/gulp or other things).

@Enelar if you don't have a strong opinion on the matter go with npm 3 (npm install -g npm@latest) and forget about bower. Multiplying package manager in your project is not a good idea for your workflow and chances are very high that you will require npm for something anyway (build tools such as grunt/gulp or other things).

@Enelar

This comment has been minimized.

Show comment
Hide comment
@Enelar

Enelar Oct 9, 2015

@PowerKiKi well, thanks for quick respond. That was ultimatum. Like "this repository IS DEPRECATED".
Rather than being rude, and taking your advice, i will humble wait for comparison, or trying to dig it by my own.

Enelar commented Oct 9, 2015

@PowerKiKi well, thanks for quick respond. That was ultimatum. Like "this repository IS DEPRECATED".
Rather than being rude, and taking your advice, i will humble wait for comparison, or trying to dig it by my own.

@jokeyrhyme

This comment has been minimized.

Show comment
Hide comment
@jokeyrhyme

jokeyrhyme Oct 10, 2015

@Enelar: start with NPM, as @PowerKiKi says pretty much every JavaScript-related project is going to need something from there anyway
Only use bower as well if you have a problem that can't be solved with NPM alone.

Bower had a flat-tree from the beginning, and NPM only just got it with v3.x. Flat tree is more convenient for front-end development (if you have to put URLs in HTML link and script tags, etc). So bower and NPM are now even on this score.

I can't remember, but I think Bower handles unpublished projects via direct git URLs a little bit better than NPM. The NPM folks want to improve this, I'm not sure if they are working on it actively or not. If you only use published versions of packages then this doesn't apply to you.

People here aren't being rude or wishing that bower developers would give up or anything horrible like that. The objective consensus is that NPM is rapidly catching up to bower in terms of front-end friendliness, and likely has already caught up for the majority of projects. NPM wouldn't be as awesome as it is today without the competition from Bower.

@Enelar: start with NPM, as @PowerKiKi says pretty much every JavaScript-related project is going to need something from there anyway
Only use bower as well if you have a problem that can't be solved with NPM alone.

Bower had a flat-tree from the beginning, and NPM only just got it with v3.x. Flat tree is more convenient for front-end development (if you have to put URLs in HTML link and script tags, etc). So bower and NPM are now even on this score.

I can't remember, but I think Bower handles unpublished projects via direct git URLs a little bit better than NPM. The NPM folks want to improve this, I'm not sure if they are working on it actively or not. If you only use published versions of packages then this doesn't apply to you.

People here aren't being rude or wishing that bower developers would give up or anything horrible like that. The objective consensus is that NPM is rapidly catching up to bower in terms of front-end friendliness, and likely has already caught up for the majority of projects. NPM wouldn't be as awesome as it is today without the competition from Bower.

@donaldpipowitch

This comment has been minimized.

Show comment
Hide comment

Well said!

@calidion

This comment has been minimized.

Show comment
Hide comment
@calidion

calidion Jan 24, 2016

Member

I don't think the mixing of frontend and backend into one package management will make life any easier.
bower still has its value to go.
I think time will prove.
if i want to use bootstrap in my frontend project, and i don't need bootstrap been installed when i run npm install to start my node project.

they are totally different things.

Member

calidion commented Jan 24, 2016

I don't think the mixing of frontend and backend into one package management will make life any easier.
bower still has its value to go.
I think time will prove.
if i want to use bootstrap in my frontend project, and i don't need bootstrap been installed when i run npm install to start my node project.

they are totally different things.

@benallfree

This comment has been minimized.

Show comment
Hide comment
@benallfree

benallfree Jan 28, 2016

I think @calidion is correct, it's been two years since NPM started talking about ecosystems and it must be a taller order than the community anticipated. Bower is ready now, available now, and perfect for representing the frontend ecosystem :) The pain points highlighted earlier are very accurate.

I think @calidion is correct, it's been two years since NPM started talking about ecosystems and it must be a taller order than the community anticipated. Bower is ready now, available now, and perfect for representing the frontend ecosystem :) The pain points highlighted earlier are very accurate.

@almereyda

This comment has been minimized.

Show comment
Hide comment
@almereyda

almereyda Feb 9, 2018

Given the explanations in https://bower.io/blog/2017/how-to-migrate-away-from-bower/ this issue could be renamed to Migrate away from bower to yarn.

almereyda commented Feb 9, 2018

Given the explanations in https://bower.io/blog/2017/how-to-migrate-away-from-bower/ this issue could be renamed to Migrate away from bower to yarn.

@sheerun

This comment has been minimized.

Show comment
Hide comment
@sheerun

sheerun Feb 14, 2018

Contributor

Yeah, Yarn is now possible way to go

Contributor

sheerun commented Feb 14, 2018

Yeah, Yarn is now possible way to go

@sheerun sheerun closed this Feb 14, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment