11 ms·

Jam - The JavaScript package manager

89 points by caolanm 14y ago

jeromegn 14y ago
I've been building projects with Node.js (+ using npm), and here are my two cents: - One of the best changes to npm was to install modules locally instead of globally by default. I wish jam also did that, global installs are troublesome. - Isn't package.json going to conflict with my npm's package.json? I definitely don't want to polute my back-end's packages with front-end only stuff. Basically, I'd like more sensible defaults. Change the package.json to some other filename and install packages locally by default. I'm also unsure why it would put files inside /jam, I don't want to change my configuration to use some obscur and badly named "jam" folder. I believe people like the vendor/javascript or public/javascripts conventions, that would be a better default in my opinion. Otherwise, I like the initiative. In the past we've been using Jim (https://github.com/quirkey/jim https://github.com/quirkey/jim) which works more like bundler. Now we just do it manually for lack of a better solution. I don't think this is it yet, but it's close.
- caolanm 14y ago
  Dependencies are installed locally to your project, but not for each package individually, if that makes sense. On the client-side you really don't want to be shipping 5 versions of jQuery! - I agree that it's an awesome way to do things for Node.js, but it just doesn't translate well to the browser. As for package.json, yes there may occasionally be conflicts with NPM, but in many cases they should be compatible since they are based on the same spec. Perhaps allowing you to override with "jam.json" would be a good idea for times when they would conflict?
- MatthewPhillips 14y ago
  Why does your server code and your UI code share the same base directory?
  - deleted 14y ago
    [deleted]
  - lipponlabang 14y ago
    Well surely any two files in any file system shared a common base directory don't they? Either the root directory, or one further down the tree.
  - prezjordan 14y ago
    What exactly is wrong with that? In Rails, you have app/controllers and app/views. UI code and server code sharing the same base directory.
    - bendemott 14y ago
      Does seem potentially problematic if you don't want to be exposing server-logic. Especially when the developer may not know what software will be ultimately serving the static files over http.
      - prezjordan 14y ago
        As a newbie webdev, what would you suggest? Making an API-based web application? (the backend would serve and receive JSON and the front-end would simply play around with it) Or am I completely misunderstanding this.
        MatthewPhillips 14y ago
        That's a reasonable way to build an application, and one that I personally prefer, but there isn't a silver bullet. But if you're building a Node app your server js and your client js don't need to commingle. Make a src/js/client directory, and stick your package.json in there (if you want to use this tool).
        NinetyNine 14y ago
        Socketstream is a framework in active development based on exactly that idea.
    - MatthewPhillips 14y ago
      The grandparent was talking about Node, which doesn't tell you how to organize directories like Rails.
dimarco 14y ago
Libraries like this are useful. Ender sounds similar and has been out for quite some time: http://ender.no.de/ http://ender.no.de/
WiseWeasel 14y ago
I'm not sure I get it. This seems to run in your development environment, in order to manage your dependencies and output your JavaScript code to a minified version ready for deployment, but it's in JavaScript. What kind of development environment executes JavaScript? What kind of workflow is this geared towards? Is that a nice way to develop?
- wetmore 14y ago
  It runs on node, which executes javascript in a development environment.
  - WiseWeasel 14y ago
    Ah, I guess I had never really connected the dots, that to use node, you have to do your development in the browser. This is all starting to come together. ; ) [Or not, apparently.]
    - deleted 14y ago
      [deleted]
    - jchrisa 14y ago
      I use node, but I use a normal editor, not the browser
      - WiseWeasel 14y ago
        So then is there a step where you execute your node (and I guess Jam if you're using that) code in order to generate production client-side code from the node and jam-dependent code? Or is all of this for server-side code where the node and jam libraries would be installed?
        aidenn0 14y ago
        This is confusing b/c there are 2 javascript environments involved. Let's pretend that instead of being written in javascript, it was written in ruby/python/c. Now it would look like this: "A (client-side) javascript package manager written in ruby/python/c" It's not for managing node.js packages, it's for managing client-side .js packages, and it just happens to be written in javascript to be run by node.js
jlongster 14y ago
Another project to check out: https://github.com/volojs/volo https://github.com/volojs/volo Volo is arguably more established and written by the same guy who wrote require.js. It's still early in development, but is already very good. EDIT: From a quick glance, it seems like volo works better with existing javascript libraries too. Volo's add/install command simply uses github's search API to find any existing project and can install it (it also supports other URL formats).
ephoz 14y ago
How is this different from ender.js (which has been around for a while)? A short summary of pros / cons of each would help.
danellis 14y ago
Unfortunately choice of name, perhaps, as it clashes with this: http://www.perforce.com/documentation/jam http://www.perforce.com/documentation/jam
- TwistedWeasel 14y ago
  yeah, the jam build system is a great tool and has been around a long time. Seems like people should do some more research before naming their projects.
  - caolanm 14y ago
    You can call it JamJS if it makes you feel better ;) Obviously, I'd have preferred to avoid a naming conflict had I known about this project but it's getting pretty difficult to find unique names for JS projects these days. There's already a 'jam' in NPM!
  - ams6110 14y ago
    There was also a client/server RAD tool call JAM which I used for a brief period in the 1990s when I worked in a financial services IT shop. Seems it still exists, though I've never heard of anyone else using it. http://www.prolifics.com/jam.htm http://www.prolifics.com/jam.htm
deleted 14y ago
[deleted]
iamleppert 14y ago
Kudos to the author but I don't like yet another package system (this one specifically hosted on packages.jamjs.org). What happens when that goes down, or the author calls it quits, or spammers take it over etc? IMO it's much better to adopt the existing npm ecosystem as Ender has done.
zaphar 14y ago
Every two years or so someone comes up with a new javascript package manager. Obviously something about the javascript ecosystem makes this hard because someone constantly attempts to solve the problem over and over again. What' wrong with the previous 3 or 4 attempts. I'm honestly curious. I don't live in the world of javascript very much anymore so I don't know what all the issues are.
- kaolinite 14y ago
  Perhaps package managers are just fun to write? :-)
- kn8 14y ago
  What previous attempts are you referring to?
gringomorcego 14y ago
is there a point to using this outside of node.js and npm? I'm not a big js person btw.
- caolanm 14y ago
  Yes, definitely. You shouldn't need to know anything about Node.js beyond installing it. Jam is for managing front-end code and would be useful in any application with a lot of client-side JavaScript.
kn8 14y ago
This looks very promising! JavaScript badly needs a package manager and the community badly needs to agree on a module format (AMD). Do you think that will happen? How can we make that happen? Every other language has package managers.. ruby has gems and bundler, node has npm, java has maven. That makes it so easy to develop any application or library that can be used by any other application or library. ClientSide JavaScript finally has an amazing way to manage dependencies and build modular applications (AMD). All it needs now is a good package manager for being able to split large applications into individual components and manage external library dependencies. I want to be able to configure jQuery, Backbone, jQuery plugins, Backbone plugins, any other JS library, my own subcomponents as dependencies, use them via AMD's require and optimize in a smart way when building (e.g. only build in a single copy of the given library and warn if multiple versions are required). I'm really hoping Volo (https://github.com/volojs/volo https://github.com/volojs/volo) or Jam (or both if they become interoperable) will become the solution for this stuff.

89 points by caolanm 14y ago

I've been building projects with Node.js (+ using npm), and here are my two cents: - One of the best changes to npm was to install modules locally instead of globally by default. I wish jam also did that, global installs are troublesome. - Isn't package.json going to conflict with my npm's package.json? I definitely don't want to polute my back-end's packages with front-end only stuff. Basically, I'd like more sensible defaults. Change the package.json to some other filename and install packages locally by default. I'm also unsure why it would put files inside /jam, I don't want to change my configuration to use some obscur and badly named "jam" folder. I believe people like the vendor/javascript or public/javascripts conventions, that would be a better default in my opinion. Otherwise, I like the initiative. In the past we've been using Jim (https://github.com/quirkey/jim https://github.com/quirkey/jim) which works more like bundler. Now we just do it manually for lack of a better solution. I don't think this is it yet, but it's close.

caolanm 14y ago
Dependencies are installed locally to your project, but not for each package individually, if that makes sense. On the client-side you really don't want to be shipping 5 versions of jQuery! - I agree that it's an awesome way to do things for Node.js, but it just doesn't translate well to the browser. As for package.json, yes there may occasionally be conflicts with NPM, but in many cases they should be compatible since they are based on the same spec. Perhaps allowing you to override with "jam.json" would be a good idea for times when they would conflict?
MatthewPhillips 14y ago
Why does your server code and your UI code share the same base directory?
- deleted 14y ago
  [deleted]
- lipponlabang 14y ago
  Well surely any two files in any file system shared a common base directory don't they? Either the root directory, or one further down the tree.
- prezjordan 14y ago
  What exactly is wrong with that? In Rails, you have app/controllers and app/views. UI code and server code sharing the same base directory.
  - bendemott 14y ago
    Does seem potentially problematic if you don't want to be exposing server-logic. Especially when the developer may not know what software will be ultimately serving the static files over http.
    - prezjordan 14y ago
      As a newbie webdev, what would you suggest? Making an API-based web application? (the backend would serve and receive JSON and the front-end would simply play around with it) Or am I completely misunderstanding this.
      - MatthewPhillips 14y ago
        That's a reasonable way to build an application, and one that I personally prefer, but there isn't a silver bullet. But if you're building a Node app your server js and your client js don't need to commingle. Make a src/js/client directory, and stick your package.json in there (if you want to use this tool).
      - NinetyNine 14y ago
        Socketstream is a framework in active development based on exactly that idea.
  - MatthewPhillips 14y ago
    The grandparent was talking about Node, which doesn't tell you how to organize directories like Rails.

dimarco 14y ago

Libraries like this are useful. Ender sounds similar and has been out for quite some time: http://ender.no.de/ http://ender.no.de/

WiseWeasel 14y ago

I'm not sure I get it. This seems to run in your development environment, in order to manage your dependencies and output your JavaScript code to a minified version ready for deployment, but it's in JavaScript. What kind of development environment executes JavaScript? What kind of workflow is this geared towards? Is that a nice way to develop?

wetmore 14y ago
It runs on node, which executes javascript in a development environment.
- WiseWeasel 14y ago
  Ah, I guess I had never really connected the dots, that to use node, you have to do your development in the browser. This is all starting to come together. ; ) [Or not, apparently.]
  - deleted 14y ago
    [deleted]
  - jchrisa 14y ago
    I use node, but I use a normal editor, not the browser
    - WiseWeasel 14y ago
      So then is there a step where you execute your node (and I guess Jam if you're using that) code in order to generate production client-side code from the node and jam-dependent code? Or is all of this for server-side code where the node and jam libraries would be installed?
      - aidenn0 14y ago
        This is confusing b/c there are 2 javascript environments involved. Let's pretend that instead of being written in javascript, it was written in ruby/python/c. Now it would look like this: "A (client-side) javascript package manager written in ruby/python/c" It's not for managing node.js packages, it's for managing client-side .js packages, and it just happens to be written in javascript to be run by node.js

jlongster 14y ago

Another project to check out: https://github.com/volojs/volo https://github.com/volojs/volo Volo is arguably more established and written by the same guy who wrote require.js. It's still early in development, but is already very good. EDIT: From a quick glance, it seems like volo works better with existing javascript libraries too. Volo's add/install command simply uses github's search API to find any existing project and can install it (it also supports other URL formats).

ephoz 14y ago

How is this different from ender.js (which has been around for a while)? A short summary of pros / cons of each would help.

danellis 14y ago

Unfortunately choice of name, perhaps, as it clashes with this: http://www.perforce.com/documentation/jam http://www.perforce.com/documentation/jam

TwistedWeasel 14y ago
yeah, the jam build system is a great tool and has been around a long time. Seems like people should do some more research before naming their projects.
- caolanm 14y ago
  You can call it JamJS if it makes you feel better ;) Obviously, I'd have preferred to avoid a naming conflict had I known about this project but it's getting pretty difficult to find unique names for JS projects these days. There's already a 'jam' in NPM!
- ams6110 14y ago
  There was also a client/server RAD tool call JAM which I used for a brief period in the 1990s when I worked in a financial services IT shop. Seems it still exists, though I've never heard of anyone else using it. http://www.prolifics.com/jam.htm http://www.prolifics.com/jam.htm

deleted 14y ago

[deleted]

iamleppert 14y ago

Kudos to the author but I don't like yet another package system (this one specifically hosted on packages.jamjs.org). What happens when that goes down, or the author calls it quits, or spammers take it over etc? IMO it's much better to adopt the existing npm ecosystem as Ender has done.

zaphar 14y ago

Every two years or so someone comes up with a new javascript package manager. Obviously something about the javascript ecosystem makes this hard because someone constantly attempts to solve the problem over and over again. What' wrong with the previous 3 or 4 attempts. I'm honestly curious. I don't live in the world of javascript very much anymore so I don't know what all the issues are.

kaolinite 14y ago
Perhaps package managers are just fun to write? :-)
kn8 14y ago
What previous attempts are you referring to?

gringomorcego 14y ago

is there a point to using this outside of node.js and npm? I'm not a big js person btw.

caolanm 14y ago
Yes, definitely. You shouldn't need to know anything about Node.js beyond installing it. Jam is for managing front-end code and would be useful in any application with a lot of client-side JavaScript.

kn8 14y ago

This looks very promising! JavaScript badly needs a package manager and the community badly needs to agree on a module format (AMD). Do you think that will happen? How can we make that happen? Every other language has package managers.. ruby has gems and bundler, node has npm, java has maven. That makes it so easy to develop any application or library that can be used by any other application or library. ClientSide JavaScript finally has an amazing way to manage dependencies and build modular applications (AMD). All it needs now is a good package manager for being able to split large applications into individual components and manage external library dependencies. I want to be able to configure jQuery, Backbone, jQuery plugins, Backbone plugins, any other JS library, my own subcomponents as dependencies, use them via AMD's require and optimize in a smart way when building (e.g. only build in a single copy of the given library and warn if multiple versions are required). I'm really hoping Volo (https://github.com/volojs/volo https://github.com/volojs/volo) or Jam (or both if they become interoperable) will become the solution for this stuff.