Fork JavaScript 0.1.0 is official!

To Peter... congrats. Maybe you should think about making your lib v1.0 soon. People seem to get that warm fuzzy feeling when it's 1.0+. Anyway, all the best.

Thanks. I don't want 1.0 to be too far into the future but I also don't want to diminish the value of that landmark release. There won't necessarily be nine releases before 1.0.

im actually right now working with something similar, except ive got myself a different approach. The end result would be something like this:

var SuperClass = {
  __name: "Super",
  __constructor: function( arg1, ... ) {
    [Construct Code]
  },
  [More Methods]
}
Class.create( SuperClass );


var ChildClass = {
  __name: "Child",
  __constructor: function( arg1 , ... ) {
    [Construct Code]
  },
  [More Methods]
}
Class.create( ChildClass );
ChildClass.extend( SuperClass );

var CC = new ChildClass();

... and so one, ChildClass now inhereting everything from SuperClass. There is a few javascript qierks utilised in this, but nothing that's not supported in most ECMAscript 3.0 supporting browsers.

Cheeriyo!

Peter,

This is really exciting! I've been a big evangelist for prototype for a while now and was all jazzed about it just yesterday after I found their new site and new 1.5.0 version.

If Fork delivers on its promise of merging the best of prototype and Yahoo! YUI, I'll be beside myself!

Nice work so far. I'll be checking things out in more detail soon and, of course, linking to your site. I smell a blog post comparing prototype and Fork in the near future...

Cheers,
-Andrew

I'm impressed by the extensive testing and very verbose commenting in the code. Nice work.

I'm also working on my own general-purpose library, and while looking into all the libs out there I've come to a conclusion - everyone is doing pretty much the same things, in slightly different ways, but the set of functionality is pretty much the same.

So the conclusion I've reached is: Isn't it time for a Javascript Library API?

If some API could be agreed upon, then library authors could work on their own implementations and tweaks, but everyone would be creating compatible code. You could easily pick and choose which implementations you want to use for Events, Ajax, etc. And instead of learning the API of a specific library/framework (in addition to the js core) you would learn the general Javascript Extended API and be able to use any compliant library. Wouldn't that be great?

Even better would be a big group of people combine their skills to create the perfect implementation of the API. For example, your code looks good but you're missing some things that I would consider key. For example (focusing just in the style lib):

isSupported() requires document.getElementById, even though that really isn't required to use setStyle(). It also creates a div object each time it is called, rather than remembering the last result.

_getStyle() never changes el.style[prop] as a fall-back.

get/setStyles don't handle the "float" attribute correctly, or handle non-camel-case property names ("background-color")

getStyle() doesn't normalize rgb() values returned by Firefox, for example, to #ffffff hex values used by IE, for example.

These aren't failings in your library, just things other libraries consider that you have either missed or chosen not to deal with or dealt with in a different way.

Anyway, good work. I'm going to look over some of your code to see if you've found browser quirks that I'm not considering in my own code.

Matt,

I'm impressed by the extensive testing

The only reasons for not testing in a wide set of browsers are time pressure or lack of interest. I don't think those are good enough. Open source is supposed to try for better.

very verbose commenting in the code.

Having to reverse engineer bug fixes in both Prototype and Yahoo! UI was painful when a short author comment would have clued me in to their intention. If it doesn't serve any other purpose, Fork as a reference implementation for other JavaScript libraries would be a good result of this project.

Nice work.

Thanks.

I'm also working on my own general-purpose library, and while looking into all the libs out there I've come to a conclusion – everyone is doing pretty much the same things, in slightly different ways, but the set of functionality is pretty much the same.

So the conclusion I've reached is: Isn't it time for a Javascript Library API?

If some API could be agreed upon, then library authors could work on their own implementations and tweaks, but everyone would be creating compatible code. You could easily pick and choose which implementations you want to use for Events, Ajax, etc. And instead of learning the API of a specific library/framework (in addition to the js core) you would learn the general Javascript Extended API and be able to use any compliant library. Wouldn't that be great?

That would be great; however, I don't know if JavaScript programmers could agree on something large scale like this. For example, from what I've seen, the Prototype, Moo Tools, JQuery, and Mochikit groups are very concerned with how their code looks and how they feel when they write it. They like a very OOP looking API and in some cases will achieve that at any cost. I have definitely gone more the way of Yahoo! UI with namespaces and that makes a big difference to an API. There there are folks that don't like the pseudo-namespacing possible in JavaScript and insist it is a waste of time.

It would be possible to have just one base library. For example, take Fork and build any API on top of it. If someone really wanted to he could plunk Prototype's sugar on top of Fork. If someone did this I think he would be missing some of the point of Fork but JavaScript is so flexible it could be done.

One base library is questionable too. If I was going to write for only Firefox over slow connections I would strip Fork down but keep the same API which is like your suggestion. I've thought about having two versions of the Ajax library for Fork with the same API. One full featured and one stripped down without timeouts or abort. This is very similar to the position reporting functions Richard Cornford has eluded to on comp.lang.javascript. These kinds of thoughts are along the same lines as yours and I think that within one library, with good documentation, such a fixed API with several implementations could be a good idea.

Even better would be a big group of people combine their skills to create the perfect implementation of the API.

Please come on over to the Fork Google group and join in. I would like Fork to have the interest of JavaScript programmers that like to discuss minutia. Some other libraries don't seem to take criticism well.

For example, your code looks good but you're missing some things that I would consider key.

If a common API could be determined each library would probably only implement a subset of interest.

For example (focusing just in the style lib):

isSupported() requires document.getElementById, even though that really isn't required to use setStyle(). It also creates a div object each time it is called, rather than remembering the last result.

document.getElementById() is required if setStyle() is to take a string argument to find the appropriate element. This would be a large point of argument if a common API was to be defined. Should functions only take elements as arguments or also take id strings. This could be argued for years.

The result for isSupported() is remember in every library as this property is redirected to a new function either on file load or the first time the function is called.

_getStyle() never changes el.style[prop] as a fall-back.

I think you mean "reads" not "changes". No it doesn't read the simple inline property. In the testing I found that browsers will lie frequently when reading properties of el.style. Even if the browser doesn't support a particular style property it will report that it is set when reading it from el.style but if reading the computed style the browser will not lie and return undefined.

get/setStyles don't handle the "float" attribute correctly, or handle non-camel-case property names ("background-color")

I haven't had a need for this sort of API. It is not difficult to write "cssFloat" instead of "float". Similar "backgroundColor" is just as easy as "background-color". While I'm writing JavaScript I have been able to stay with just camelCase which is much easier on my mind. Any common examples where this is absolutely essential?

getStyle() doesn't normalize rgb() values returned by Firefox, for example, to #ffffff hex values used by IE, for example.

I haven't tackled this yet but it is a good idea. Internet Explorer will even return "green" if that is how the background color was set. Ticket

These aren't failings in your library, just things other libraries consider that you have either missed or chosen not to deal with or dealt with in a different way.

Anyway, good work. I'm going to look over some of your code to see if you've found browser quirks that I'm not considering in my own code.

If you see anything I've missed please post on the Fork Google group.

A reason you might want to do a get/set style is because of inconsistencies between browsers:

• opacity
• cssFloat (DOM) vs. styleFloat (ie)

Also, it means you only have to remember the CSS names and ignore the DOM names unless you need to play with the raw DOM objects.

In addition, it'll act as a kind of documentation since it'll list all the css names and their matching DOM names. Which is kinda my problem with Prototype and even YUI. Figuring out how to use it sometimes is a pain. That cssFloat vs. styleFloat thing took forever to figure out because I didn't know to search for it.

Ciao!