Jam - The JavaScript package manager | Hacker News Reader

Jam - The JavaScript package manager

groundcomputing.co.uk

89 pointscaolanm33 comments

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

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?

Why does your server code and your UI code share the same base directory?

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.

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.

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.

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

Socketstream is a framework in active development based on exactly that idea.

The grandparent was talking about Node, which doesn't tell you how to organize directories like Rails.

Another project to check out: 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).

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.

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

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.

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!

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

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.

Perhaps package managers are just fun to write? :-)

What previous attempts are you referring to?

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) or Jam (or both if they become interoperable) will become the solution for this stuff.

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?

It runs on node, which executes javascript in a development environment.

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

I use node, but I use a normal editor, not the browser

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?

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

Well, not exactly. From wikipedia: "Node.js consists of Google's V8 JavaScript engine, libUV, and several built-in libraries." So node installs a version of the V8 engine in your dev environment, so it can run js on the server without a browser.

That's why jam requires node - it's written on javascript and uses node packages so it can work with the filesystem, and do other server/dev environment things that js in a browser can't do.

When you develop with node, it's just like doing development for any other language.

Edit: in case this wasn't clear - you aren't working in a node environment. In this case, node is simply used because it can execute javascript in a server environment. So jam can be written in js and do filesystem stuff if it runs using the node utility. Jam simply runs on node, but a project using jam doesn't necessarily need to be a node application.

Thanks for that explanation. One last question: why would you do 'jam install backbone'? Are people developing all their client-side code in the node environment as well?

[Or, it seems like maybe node in this case is just a dependency for jam, which is simply a tool used to make all your JavaScript development easier, without introducing any extra runtime dependencies.]

I believe jam is targeted for the client side, similar in functionality to googles closure compiler.

There are two sides to Node. One is the HTTP server environment you're thinking of. The other is just as a generic JavaScript execution environment, with packages for filesystem etc..

How is this different from ender.js (which has been around for a while)?

A short summary of pros / cons of each would help.

Libraries like this are useful.

Ender sounds similar and has been out for quite some time: http://ender.no.de/

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

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.

Reply on news.ycombinator.com