Fork is alive.

[Peter Michaux]

A couple months holiday are over and I've resolved to making the next
version of Fork my side-project priority. Fork v0.2 is hopefully not
in the too distant future.

Part of the reason Fork hasn't been updated since more than two years
ago is it just keeps working for me. I don't encounter bugs that need
fixing. I know at least 40,000 people are using a site based on Fork
and they've never encountered a bug in Fork. At least they haven't
told me if they did. I'd like Fork v0.2 to have the same reliability
and that means a huge investment in manual browser testing.

Another part of the reason is, before adding more to the pile, I
wanted to remove some of the bad. I've already overhauled the entire
structure of the Fork repository. Looking at the things I've change
and the things I want to change the underlying theme seems to be
"simpler."

Gone is the Rails app that I used to use to develop Fork. Now it is
just Apache with under 20 lines of Perl CGI scripts. It is just as
easy to develop this way and will use less memory in production since
the Fork site is not (yet) high traffic.

Gone are workarounds for old browsers like Safari 2 and Firefox 1.
These browsers now gracefully degrade where there once was a
workaround.

Gone is support for Internet Explorer's quirksmode. I've never had
trouble adding a doctype to a page. When in quirksmode, IE will
degrade gracefully in parts of the Fork API.

Gone are are Deep.object.name.spaces in the API. That was a mistake in
Fork v0.1's design due to fad influence. Now simple namespaced
function names will do just fine. For example, FORK_addListener. I'm
not sure that "FORK_" will be the prefix but it will be a prefix of
some sort.

Welcome a heavier emphasis on feature testing. Other libraries don't
provide application programmers the necessary indications to create
sites that degrade gracefully or use progressive enhancements. Fork v2
will have more robust feature testing and help developers more.

Welcome a function to find elements using simple css selectors. This
sort of function is very popular. I don't like seeing those jumbo css
selector function implementations. The Fork selector function handles
simple css selectors which means it is small and fast. It also means
your JavaScript is less brittle in the face of HTML edits.

I'm not sure what to do about the drag and drop code yet and I've been
puzzled for a long time. I have used the Fork v1 drag and drop code
with great success. The drag and drop code is more like nuts and bolts
with which you can construct. I'm not sure if a higher level api is
desirable, necessary or practical.

Perhaps there will be a jQuery-like wrapper like Dustin Diaz wrote for
YUI!. [http://dedchain.dustindiaz.com/] Taking the wrapper approach
means the core of the library can stay the same but people who like
that kind of API can have it too.

Will the "Fork" brand continue or should it be re-branded? It has
crossed my mind.

Peter

[Peter Michaux]

A rough cut of a custom build tool with a automatic dependency
resolution and a minification option is up.

http://alpha.forkjavascript.org/download.html

There is lots of broken stuff on the alpha site but if there is any
feedback about the custom build tool please speak up.

I'm moving information from the Fork v0.1 site into the Fork v0.2 site
as the days go by.

Peter