• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Junilu Lacar
  • Tim Cooke
Saloon Keepers:
  • Carey Brown
  • Stephan van Hulst
  • Tim Holloway
  • Peter Rooke
  • Himai Minh
Bartenders:
  • Piet Souris
  • Mikalai Zaikin

Objectives -- Prototype/dojo/jquery etc etc

 
Ranch Hand
Posts: 92
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There are number of toolkits to implement AJAX on an application.

� Prototype
� Dojo
� jQuery
� Yahoo UI
� Mootools
� Ext

How should a developer make a choice among these? How is prototype and script.aculo.us different from others? How are the objectives of Protoype and Script.aculo.us different from the rest of the kits? For What kinds of applications should a developer make a choice to and not to Prototype?

Thanks & Regards
Prithiraj Sen Gupta
 
Author
Posts: 43
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hey Mr. wide-range questions :-),

There are number of toolkits to implement AJAX on an application.
How should a developer make a choice among these? How is prototype and script.aculo.us different from others? How are the objectives of Protoype and Script.aculo.us different from the rest of the kits? For What kinds of applications should a developer make a choice to and not to Prototype?



Hmm, okay. Let's tackle this.

1. How to choose a JS framework

There's no "best framework" out there. As always, there is just "the best framework for your current project," and even at such a narrow scope you may well find several frameworks are equivalent, so it will boil down to which "coding style" suits your liking best.

Each framework comes with its scope, its philosoph and core design decisions, a resulting syntax style and coding idioms, some documentation, and possibly a community.

You should consider the following points when choosing one (in no specific order):

� What do I need a JS framework for? Which frameworks fit the bill, feature-wise?
� Can I assume this framework will rule the whole page, or am I developing in a context where it may collide with other JS libs on the page? In the latter case, which frameworks "play nice" with other libs in the same scope space?
� What does idiomatic JS code look like when using such or such framework? Do I find the resulting code to be readable and elegant, or does it confuse/irritate me?
� How good is the online documentation? Are there many books on it, and what is their quality? Is this mostly reference material or are there good tutorials too?
� Is there a vibrant, active community around the framework? Is it easy to find help? How well are n00bs treated on the forums?
� How actively is the framework maintained? Can I trust bug fixes and patches to be implemented swiftly?
� What is the framework's code quality? Is it robust? Is it fast? Does it come with massive unit testing?

2. How do Prototype and script.aculo.us differ from the others?

Let's take the list you mentioned:

� Prototype is a middleground framework: it's not just "smoothing out browser incompatibilities" (like Dean Edward's Base2 focuses on), it's also providing a core set of features that we feel every webapp needs: stupid-easy Ajax, powerful DOM manipulation and CSS-based extraction, form observation, and enhanced JavaScript types. Prototype goes the pragmatic route by extending the native types directly to shorten the syntax and make it unobtrusive. However, the price to pay for this is that we don't coexist very well with other libraries in the same page space: as soon as they use a for/in loop on native-type objects, for instance, they'll see our extensions (and the fact that they shouldn't use for/in in most cases doesn't alleviate the problem).

� script.aculo.us is a widget/effects framework that focuses on core widgets and visual effects not specific to desktop-like UI: fades, movements and morphs, auto-completion, drag and drop, in-place edition and sliders. They can fit in any page style (and I sure use them in many pages that don't look alike at all�). It's entirely dependent on Prototype, it's Proto's sister library, if you will.

� jQuery is the featherweight of JS libs (only Dean's Base2 is lighter, I believe). It exists in the same goal/feature-space as Prototype/Scripty, but (a) chose to be entirely encapsulated in its own namespace, so it plays well with other libs in the page and (b) has a very different-looking code. In my personal opinion, I find jQuery to be quicker to get started with and tinker with, but harder to "discover." Prototype's API is very consistent and convention-based, and therefore easily "discoverable." I find jQuery to be more of a toin-coss when you try out stuff: just because code looked that way in one instance, or situation A featured extension B on object O, doesn't mean that the same applies in a similar-yet-slightly-different situation.

� Dōjō is a full-fledged SDK, so to speak. It's the JsDK, if you will, it's a full-fledged app development framework, complete with numerous processing algorithms, collection types, and desktop-app-like UI widgets. It's massive, although it went through some significant diet with its 0.9 rewrite and is now a bit more modular (core, digit, dojox). It is mostly designed to be the one framework in the page, and targets webapps that should feel like desktop apps with a very rich set of widgets (trees, tables, check lists and the lot).

� Yahoo! UI has the same scope as Dōjō, but obviously its backing by Yahoo!, even these days, carries major weight. The fact that Yahoo! uses this lib for all its recent needs, on many properties, and provides a CDN for it is certainly a major point. The code quality is generally excellent, and the docs are very good. On the other hand, it's not open-source (in the sense that only Yahoo! develops it with no particular care for external input).

� Mootools: let's just say I'd rather not talk about them, that despite excellent skills within their team they don't add much to the mix, and they tend to make any other framework team want to blow off some steam now and then.

� Ext: they're mostly an "overkit" that you can plug around your favorite framework as a core (an impressive design feat!). They're nice and have cool docs, but I can't really go into details about the lib, I don't know it well enough.

Most of these libraries have pretty good online docs, although jQuery, Prototype and script.aculo.us lead the race offline (books-wise). With Dōjō, they also feature a vibrant community with plenty of help channels and quite a few quasi-official websites in addition of the official ones. They also all offer varying levels of "plugins" or third-party extensions (jQuery has a formal plugin support, Prototype has the Scripteka repository and will soon introduce its own formal extension system, etc.).

3. Differences of objectives / apps for which to (not) use them?

I can't quite vouch for the other ones (I'm sure Bear will be glad to chip in about jQuery, for instance), but for Prototype and script.aculo.us, here are a few things to know.

� We're first and foremost trying to provide a nice, simple, consistent API that lets people script web pages easily and elegantly.
� We're all Ruby lovers, so our language extensions are partly guided by how we're trying to emulate some of Ruby in JS (the libs will work fine with any server-side tech though, not just Rails, for instance).
� We are VERY big on automated testing. Prototype features an enormous amount of unit tests, for instance, and we don't apply any patch that does not come with the proper tests, unless what we're patching is not at all testable in an automated way. So the codebase is very robust.
� We eat our own dog food, obviously: the codebase uses itself all the time.
� We're NOT trying to be a full-fledged SDK or to cater to desktop-like UIs. We believe a web page should look like a webapp, not a desktop app. You'll find plenty of desktop-UI stacks that are based on Prototype, though.
� We're actual open-source, with a MIT-style licence, we welcome (tested) patches through our Trac, RFEs on the Prototype-Core list (Google Groups), and provide nice, noob-friendly help on the RubyOnRails-Spinoofs list (ibid.).

Well, I'd better get back to work. 'hope this helps,
 
author
Posts: 15385
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
These type of questions always come up and there is no way to say what library/framework is right for you.

The only real way to find out what is right for you is to list what your needs are. Do you need controls that you do not worry about, do you need a way to traverse the DOM, do you not want to worry about JavaScript quirks, do you not want to write JavaScript, what type of syntax do you like, etc.

Take that list and go and look at the documentation of the frameworks. Find what meets your needs and play with it. Than look to see what other resourses back it up uch as books, online tutprials, etc.

Personally I have used Prototpe.js, Dojo, Ajax Pro [.NET based], and ASP.NET Ajax[another .net] in production enviornments. My personal site will probably be using JQuery in the next round of changes.

If you are making Ajax calls, please use a library to make the calls. DO NOT write your own. The XHR object has a lot of quirks and the libraries take care of it. You will loose less hair if you use one.

Eric
 
Sheriff
Posts: 67706
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Eric Pascarello:
If you are making Ajax calls, please use a library to make the calls. DO NOT write your own. The XHR object has a lot of quirks and the libraries take care of it.


Eric and I are joined at the hip on this one! It is just so much easier to deal with Ajax through one of the libraries than to try and hoof it on your own. Choose a library that suits your project (Christophe's post makes excellent points) and use it!

You will loose less hair if you use one.

Oh, if only I'd know that years ago!


[ February 13, 2008: Message edited by: Bear Bibeault ]
 
Ranch Hand
Posts: 471
Mac OS X Hibernate Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Oh, if only I'd know that years ago!



Well, no offense Bear, but either it wouldn't have made a difference, or you REALLY had LOTS of trouble with AJAX .
 
Bear Bibeault
Sheriff
Posts: 67706
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Alaa Nassef:
... or you REALLY had LOTS of trouble with AJAX


Actually, IE did most of that.
 
Alaa Nassef
Ranch Hand
Posts: 471
Mac OS X Hibernate Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Bear Bibeault:

Actually, IE did most of that.



Well, I guess that we have to thank God (then mozilla) for firefox
 
Morning came much too soon and it brought along a friend named Margarita Hangover, and a tiny ad.
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
reply
    Bookmark Topic Watch Topic
  • New Topic