

Jam - The JavaScript package manager - caolanm
http://groundcomputing.co.uk/code/jam

======
jeromegn
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.

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

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

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

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

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

~~~
TwistedWeasel
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
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!

------
zaphar
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
Perhaps package managers are just fun to write? :-)

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

------
WiseWeasel
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
It runs on node, which executes javascript in a development environment.

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

~~~
wetmore
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.

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

~~~
quarterto
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..

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

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

------
dimarco
Libraries like this are useful.

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

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

~~~
caolanm
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.

