Monday, January 22nd, 2007

Fork: One more JavaScript Library

Category: JavaScript, Library

Fork is the latest JavaScript library to be put out there.

Fork is a general purpose, namespaced JavaScript library with Ajax, Events, DOM manipulation. There are a few bonus lines of code specifically for use with Ruby on Rails but Fork can be happily used outside of Rails also.

Why create yet another JavaScript library?

There are many JavaScript libraries out there. Why add another one to the list? To create a quality library with a liberal license.

I like Ruby on Rails. The Rails default Prototype JavaScript library does not suit many development situations and contains code that makes developing for a wide selection of browsers difficult or impossible. Prototype has some great ideas in it’s mix but the implementation quality has been questioned many times. Prototype has influenced many JavaScript libraries and some of Prototype’s best ideas have also influenced the Fork API. Because Fork is a namespaced library, you may be able to use both Fork and Prototype simultaneously as you transition from one to the other.

I like the Yahoo! UI library. Of the JavaScript libraries I’ve used it has the best API. The YUI library has many valuable nuggets of information about browser bugs and workarounds. The approach of YUI suits browser scripting well. However there are more than a few places in the code where I’m left scratching my head and thinking “why did they do that?” Probably that is how every developer looks at another developers code. The YUI API is the starting point for much of the Fork API.

Most libraries seem to develop too quickly. I like the general debian attitude of careful growth because the browser execution environment is wildly varied and deserves a certain degree of conservatism in the JavaScript we send to it.

I am looking forward to unfork.

Posted by Dion Almaer at 10:00 am
9 Comments

++---
2.6 rating from 50 votes

9 Comments »

Comments feed TrackBack URI

Gimme a break. This library adds very little value to what is already out there, and is supported by what, 1 guy who rolled his own? Seriously, new ideas are great, but in this space at this time CONVERGENCE is more important that another dude rolling his own lib in the corner.

Yes, I am looking forward to “unfork” too, Dion.

Convergence is happening with the Ajax Toolkit framework, et al, but one lone ranger ‘forking off’ and relentlessly pushing his own rather than applying ideas towards advancing one of the robust open source technologies is misguided at best.

(as an aside, this guy really needs a forum of his own rather than haunting the prototype mailing list)

Comment by Fork This — January 22, 2007

@Fork This,

Your comment reminds me of the meme floating around right now of “Why write another text editor? WriteRoom (et al) is a waste of time.” If the creators of TextMate or skEdit had had that attitude, we’d be out two great text editors.

I think it’s too early to dismiss Fork out of hand. Prototype and YUI both have issues. What’s wrong with someone trying to address them? Yeah, maybe he could try to get traction within those more established frameworks, but maybe it’s actually more efficient to bang out something that works better, then lobby for inclusion of the concepts once you have it working in the wild. Working code trumps all!

One last point, we’re not talking about the file format for Microsoft Word. If this guy’s library works better than the others, use it. I guess I don’t see why we “need” convergence.

Comment by Andrew Hedges — January 23, 2007

“Why create yet another JavaScript library?” … because it is fun to do?

Comment by M. Schopman — January 23, 2007

yeah..i like to see other libs than fat prototype,YUI,GTW. keep it up!

Comment by handcoder — January 23, 2007

Writing client side code is vastly different than writing server side code. With server side code it is fine to just bring together (converge) all your favorite libs together for a vast selection of tools. But the client side is completely different matter, bringing together multiple tools leads to large downloads for users, and certainly one of the key issues that many people have with some of the popular libraries. They may have most of what you want, but they include a lot of what you don’t want. I appreciate those that are looking to innovate and bring together alternative libraries that may be thinner.

Comment by Ajax 2.0 Developer — January 23, 2007

I agree with ‘Fork This’… I see little reason to try this library. There are more mature libraries with the same features, supported by backers with deeper pockets (less risk, longer lasting).

Comment by anonymous — January 23, 2007

The point about big downloads is a good one. Isn’t it moo.fx that lets you choose which features you want included, then even “compresses” the file? That seems like a great approach and one that these other libraries will hopefully adopt over time.

Comment by Andrew Hedges — January 23, 2007

Dojo Toolkit enables you to do the same thing via “requires”… with code that looks similar to this.

dojo.require(“dojo.widget.FisheyeList”);
dojo.hostenv.writeIncludes();

Comment by Mark Holton — January 23, 2007

…with Prototype, you also do not have to include, for instance, all of the Scriptaculous pieces. You could, if you like, simply include “Effects.js”, and “DragDrop.js”, rather than the entire Scriptaculous.js library.

Prototype.js is approx 62kB

Comment by Mark Holton — January 23, 2007

Leave a comment

You must be logged in to post a comment.