Hi Mark, On 11/29/06, Mark Holton <[EMAIL PROTECTED]> wrote: > > Dojotoolkit is the best I've found, and I've looked at nearly all of them...
People I have talked with about Dojo have run as fast as they can away from it because of code quality. I have looked at Dojo and the most disturbing thing I saw was that demo pages load very slowly. Dojo seems like the ultimate example of growing too fast and buggy. > it also has all of the bullet points you mentioned.. and is extensible. > Just as importantly, it has a lot of industry support and will be long > lasting (not developed in the corner by 1 or two people). They all start with a small group. > I don't mean to burst your bubble, I'm sure you worked hard and it's > probably nice code, and if it works for you, great... but would like to say > good luck to those developers trying every js library that pops up (which > seems to be some sort of wheel-reinvention virus going around). It can be a > huge time sink. I'm personally sticking with those that are very likely to > persist -- namely, Dojo and Prototype. imho, I think a lot of developers > would be wise to add to foundations that are already solid, with solid > support, rather than reinventing the wheel. I'm not trying to reinvent the wheel. Other people have shown the idea of a wheel is useful. I'm carefully making a circular wheel. That would be an improvement enough but I also want the wheel on high quality bearings. Why Gmail when Hotmail existed? Why Rails when Struts existed? Why Mephisto when Typo existed? I think if you take a look at the Fork code you will see it is headed in a high quality direction that other libs are not. Peter > On 11/29/06, Peter Michaux <[EMAIL PROTECTED]> wrote: a> > > > If you work with Rails but are unhappy with Prototype . . . > > > > I'm excited about the launch of my new JavaScript library called Fork > > at http://forkjavascript.org with the MIT license. Below are snips > > from the front page of the Fork site... > > > > Fork is a JavaScript library with Ajax, Events, DOM manipulation, etc. > > Fork is a general purpose library with a few bonus lines in the Ajax > > library specifically for use with Ruby on Rails however the library > > can be happily used outside of Rails also. > > > > advantages > > > > * an aspiration for the highest quality code > > * author documentation > > * in-browser unit/integration tests > > * namespaced code > > * does not augment JavaScript built-in prototypes > > * does not add a layer of sugar on top of JavaScript to make > > writing JavaScript like writing in another language > > * Is minimizable with jsmin > > * MIT License > > > > 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. I want Rails to have a better JavaScript > > library. I (and many others!) think the Rails default Prototype > > JavaScript library has many seriously poor design decisions and is > > poorly coded. Suggestions to improve the Prototype code sit on the > > Rails trac seemingly forever and author Sam Stephenson does not > > interact openly with the community of Rails and Prototype users. > > Because Prototype does not play well with other JavaScript libraries > > it isn't necessarily possible to use Prototype in combination with > > Fork. This fact likely will never change because of Prototype's > > fundamental design. On the other hand, Fork does plays well with other > > respectful libraries. > > > > 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 code 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?" Maybe 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. API's are fixed from the > > first alpha version and code is not allowed to morph for the early > > part of it's life. 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. > > > > Most JavaScript libraries settle for "good enough" and don't seem to > > aspire to the high level of quality to which the Fork library aspires. > > By keeping an eye on other JavaScript libraries the good parts can be > > brought into the Fork code. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
