I certainly disagree that Dojo's code base is low quality, and I believe many others would disagree with that statement as well. Best wishes with your library. I'm sticking with what I know are two very robust, and extensible libraries.
On 11/29/06, Peter Michaux <[EMAIL PROTECTED]> wrote: > > > 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 -~----------~----~----~----~------~----~------~--~---
