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.
There are some general docs that apply to the entire library.
| Ajax | docs | tests |
| Ajax rails | docs | tests |
| Cookie | docs | tests |
| Dom | docs | tests |
| Drag | docs | tests |
| Extend | docs | tests |
| Event | docs | tests |
| Json | docs | tests |
| Mutate | docs | tests |
| Scroll | docs | tests |
| Style | docs | tests |
| Rails plugin | docs | tests |
These are some possible future directions for new Fork libraries.
Yahoo! UI has a nice feature in the connection utility to submit multi-part forms (ie. file uploads) in a hidden iframe. This technique predates Ajax but to the user this appears like an Ajax request. Ajax requests cannot upload files. Fork will have a library for iframe form submission.
I haven't had much need for an animation library but want to work on this. I know that I want the animation library to be very modular or generalized since only a couple animations may be needed for a particular site.
Client-side form validation is not DRY since the server has to do this also. In the Rails world client-side validation is not done for this reason. I am asked to do client-side validation frequently for work and would like to add a library to help with this common task.
There are not any generalized position reporting functions to determine where an element is on the page. Position reporting is a very difficult problem. I tested four libraries (Yahoo! UI, Flanagan, JavaScriptToolbox, and Prototype) in four browsers (Internet Explorer, Firefox, Opera, Safari) with two test cases (nested scrolling divs, table cells). None of the libraries was successful in all cases. Position reporting is also a very expensive process. The good news is position reporting functions are rarely needed with clever design which leads to more reliable and faster web pages. Even dragdrop behavior rarely needs position reporting functions. Position reporting functions are still on my list of things-to-research-more list.
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.
The best resource on the Internet for JavaScript language and browser scripting discussion is comp.lang.javascript.
For questions specifically about Fork use the Fork JavaScript Google Group.
If you want to ask me a question about Fork not suited to the group send me an email: petermichaux@gmail.com