Tuesday, February 17, 2009

A CPAN for JavaScript

While there have been attempts to create a CPAN (comprehensive module directory) for JavaScript it has failed just as this has failed for pretty much every language but Perl.

In the last days I've been thinking about a new approach to create such a repository while also solving the problem of high performance JavaScript loading at the same time:
  • Create a central site (such as an application hosted on Google AppEngine) that does the following things:
  • Host any JavaScript file published to it
  • Serve as a reverse proxy server for JS files hosted on other web servers
  • Provide a simple mechanism to associate dependency and versioning meta data with JS files
  • Make any combination of JS files downloadable through a simple URL that serve all data in a single request
This is, of course, only a very rough sketch. The central idea is that sources are never actually installed anywhere but always downloaded on demand when an application requests them. While creating its own set of trust-issues and security holes this would easily solve the installation problem by eliminating it :)

What do you think?

3 comments:

John said...

There has been a lot of talk about module systems in JS lately (especially within the SSJS group). This sounds really interesting. One might be able to circumvent some of the security problems by putting in provisions for also loading data from regular URLs and not only from the central repository.

Peter Svensson said...

I like the simpleness of the idea. I don't think that it needs more features than that. If more are needed they could be either added as people clamored for them or added by another service leveraging this. Simplicity == win

Cheers,
PS

jhuni said...

Well sure there isn't a good hosting service for JSAN but that doesn't make it a bad framework for defining modules. Joose doesn't treat itself as a JSAN distribution, I mean where is the META.json file? I am certainly not going to use Joose because it appears the people there haven't figured themselves out. Besides why include 40 kb of code when I can get all the useful features in 1 kb? Maybe if they supported JSAN so that you can load the extravagant features on demand.