views:

82

answers:

3

All of my projects include very similar tasks and quite recently I've been thinking I should write a library to handle most of the heavy lifting so I can write short, simple, easy to read code that interacts with the library to get the jobs done. Looking at other frameworks, specifically jQuery & YUI, they work in different ways. jQuery mostly seems to extend & simplify the DOM using a global object/function whereas YUI uses namespaces and modules. I understand that this is because they have different goals as libraries and each have their merits.

Most specifically, I'm looking for answers to the following questions:

  1. Is it best to use namespaces, eg gui.scrollbar.attach(), or a global method such as $(domObj).attachScrollbar()?
  2. Is it best to include individual parts as seperate js files or as a single js file where components are copied/pasted? I know the eBay Shopping API SDK has many .js files in seperate folders, wouldn't this suffer a significant performance hit?
  3. Is there any other advice you would give to someone looking to create a javascript library?

I've marked as community wiki because I didn't want to risk the question being closed - I'm genuinely seeking advice here.

Thanks

EDIT I should have originally stated that I'm not re-inventing the wheel, I'm looking to simplify many common tasks between Windows Desktop Gadgets, so I don't need the cross-browser compatibility of other libraries and their core functionality doesn't really apply to what I'm doing. I tried to keep the question general and not specifically relating to desktop gadgets, so that this question would be useful for others.

A: 

Is there any reason why you can't use one of the many libraries out there already? This seems like a case of reinventing the wheel. These libraries have been around for years and have already tackled many of the issues that you will surely run into when trying to write your own.

In terms of some of your questions:

  1. This is really a matter of preference IMO. As long as you get your functions out of the global namespace that is the major thing. However, this design choice will drive many others down the line.
  2. It is best to include all core functionality in one file and then to chunk the rest into files that are required for a bit of functionality. You want to keep the number of files down, but you also don't want the user to have to download a lot of stuff that they don't need.

Having said all that, I restate that you should look at using one of the libraries already out there unless you have a very good reason not to. Keep in mind that you will need to test in all old browsers as well as any new browsers that come out. jQuery, YUI, Prototype, Mootools, extJS are a few of the most popular

Keith Rousseau
I was expecting the ol' "re-inventing the wheel" answer and probably should have mentioned that I don't need x-browser compatibility and this framework isn't specifically for web pages par se.
Andy E
+3  A: 

Simple answer to your question: write your library using an existing one.

I have some javascript files written in jQuery just for such purposes.

More specifically,

  1. If you are going for java-style object oriented-ness, go for namespaces. I prefer the jquery way of writing plugins.
  2. If you are writing your own "toolkit", it would be best to copy and paste the dependencies (minified) into your source code. This way
    a. you avoid the overhead you mentioned
    b. you prevent unnecessary dependencies creeping up externally.

Cheers!

Here Be Wolves
+1  A: 

Concerning your first question, the two options are really the same IMO. Instead of a global object like YAHOO or gui, you have a global function like $. In both cases you have a global variable that holds your namespace.

Alsciende
This occurred to me as I was writing it, but they are still different approaches so it still applies, `$` is pretty much a function that has other methods set to it. Namespacing usually has a global namespace with child namespaces in more of a tree-like fashion.
Andy E
Yes. I would add that it's most important that you don't leak items into the global namespace: have one entry point.
Sean McMillan