is an easy to use repository for all of your frontend javascript. I wrote that description about a year ago. As I dug into the idea, I abandonded it. Whie my intentions were good at the time, my technical plan was bad. I was planning on loading all of those scripts separately into the page. While they would be on a CDN, loading a bunch of script files separately is a bad practice - the more HTTP requests your page makes, the slower it's going to be. The best practice is to minify and concatenate all of your javascript so they can be served in one request. To avoid supporting bad web development practices, I abandoned DownJS
Today, however, there are numerous tools that can very easily solve this problem. Not only are the technical requirements of DownJS now very possible, but there have been many great examples of The Right Way to do package management. Now is the time for DownJS to take off.
On the technical side, DownJS would do a simple concatenation of minified files (or unminified - they would be served the same way the were uploaded). Javascript is a wild child, though, so there's some important pieces that need to be considered.
1. Order Matters Packages would be concatenated in the order that you request them. So if you want ["jquery", "angularjs", "backbone"], they will be concatenated in that order.
2. Speed Matters Obviously, this whole thing doesn't do anyone any good if I'm concatenating on the server every time a request is made. DownJS will concatenate files on the first request, and store that specific combination on S3. Files will likely be named with some identifier that makes it obvious what packages they include and what order they are. I originally thought I would just do "jquery-angular-backbone.js", but I then realized that I need to consider different versions of these files. Instead I will probably use version specific IDs, like "123-938-532.js". That translation will be done on DownJS's server side (this should be a cheap translation operation, not slowing down requests).
An additional upside to concatenating and storing these files on S3 is that, if the user wants, they can request that file directly without including DownJS's script. This would further increase load times. The user would be able to "build" script combinations on the website to generate the unique S3 URL.
3. Package Management Matters You can see on the current website that the original plan was to just allow users to upload named script files to DownJS's servers. This is pretty gross, in retrospect. Using NPM and RubyGems as inspiration, DownJS will include a command-line package management interface that allows developers to manage packages and versions.
This will likely be the biggest project I've attempted, and I want to do it right - I want to make sure I'm providing the most value to frontend developers. Please give me your feedback. You can contact me on Twitter, on DownJS's Github Issues page, or in the Hacker News discussion.
Yeah, I think something like this would help. browserify-cdn has the same goals for the CommonJS side. Also checkout what jspm is doing.