Five AJAX Frameworks Reviewed

prostoalex writes "Dr. Dobb's Journal reviews 5 AJAX frameworks: Dojo 0.3.1, Prototype and Scriptaculous 1.4, Direct Web Reporting 1.0, Yahoo! User Interface Library 0.11.1 and Google Web Toolkit 1.0. Each framework was tested in two basic scenarios — writing a 'hub' (titled collapsible link list frequently seen on sidebars of many Web sites) and a 'tab panel' (horizontal tabbed navigation bar). During the process, Dr. Dobb's Journal reviewers noted that 'Dojo provides more features and HTML widgets than YUI and Prototype' but eventually 'settled on the Yahoo! User Interface Library.'"

Comments

Frameworks

[AKAImBatman]

Am I the only one who usually finds frameworks to be pointless for serious web development? It's not that they're necessarily bad, but that they pack in dozens of features that you don't necessarily need (potentially bloating the size of your page download by tens to hundreds of K) or even want. In many cases, the frameworks have a ton of little "gotchas". For example, Prototype has a set of functions that are supposed to make it easy to show and hide elements. The only problem is that if you define the "display" element in the style sheet (say, to make an element invisible by default) you can't change the element's state. This is because the Prototype library works in a stateless fashion, assuming that the default value for "display" is the way to make an item visible. Which may not be not be true.

Other libraries have some cool GUI widgets, but often those are actually too much for a project. In some cases they even require you to build the entire project out of their widgets! That's nice if you're writing the next Outlook on the Web, but not so nice if you're trying to add interactive elements to an existing webpage. Especially if you like the more open HTML design rather than the cluttered pseudo-GUI design.

In general, I've found that these libraries may be kind of nice if you're not too familiar with DOM/CSS and want to perform some neat effects. (Scriptaculous in particular does some nice effects without a whole lot of difficulty. Just watch the download size!) But if you're doing a complex website, you'll probably be better off with a custom library for now. At least until some standard practices emerge among professional sites.

Now if you want to talk about libraries that patch minor browser issues like no DOM 2 Events, lack of Object.toSource, unified XMLHttpRequest instantiation, etc., then I'd have to jump in and add glowing support for such pieces of code. The key is, though, that they're very passive libraries. You include them, and they make sure that your code works the same everywhere. Which is a bit different than being forced to structure your project around a framework. If there's one thing I love about Javascript, it's that everything is virtual. ;)

Re:Frameworks

[teknopurge]

Am I the only one who usually finds frameworks to be pointless for serious web development? Yes.

Frameworks are what professionals use - the enforce well-formed code and design patterns. Find me a J2EE project that doesn't use Struts/Shale/WebWork/etc. and I will show you inefficiencies.

Re:Frameworks

[Rasit]

Am I the only one who usually finds frameworks to be pointless for serious web development? It's not that they're necessarily bad, but that they pack in dozens of features that you don't necessarily need (potentially bloating the size of your page download by tens to hundreds of K)[...]

So write a script to remove all the unused functions. At least thats how we do it were I work.

Re:Frameworks

[profplump]

And I could show you inefficiencies and poorly-formed code and design patterns in projects that do use Struts/Shale/WebWork.

That's not to say that frameworks aren't useful for some purposes, but "enforcing well-formed code and design patterns" is not one of those reasons, nor is failing to use frameworks evidence of bad design.

Re:Frameworks

[LiquidCoooled]

Father: "Here son, a 3 foot marble cube you wanted, and look your Grandma bought you a chisel"

vs

Father: "Heres a box of lego, it will go nicely with the big duplo bricks you got last year"

Re:Frameworks

[suv4x4]

Am I the only one who usually finds frameworks to be pointless for serious web development?

You and your soul-buddies who don't understand that by the time they "have it just right", what you just wrote is already outdated and no one cares about it.

The most crucial two things to succeed today, are:

1. having something to offer that people need, and they don't get;

2. do it FAST, since there are 1000 other geniuses like you who thought of the same thing, and will fill the niche before you manage to write and offer your solution.

Frameworks offer you the second, you need to think of the first yourself. Once you have customers/visitors and then the framework you used starts showing weaknesses (mind you, a "weakness" isn't opening your View Source and being overly anal about how the code *looks*), you'll have the time and resources to improve your service/site/solution/product/whatever.

Re:Frameworks

[AKAImBatman]

Frameworks are what professionals use - the enforce well-formed code and design patterns.

Funny thing, though. We "professionals" (I like the insinuation there, BTW) use the right tool for the right job. Sometimes the right tool is NOT someone else's framework. Sometimes, you're actually creating inefficiencies by adding layers unnecessary to the project at hand. Only an amateur selects a server-side framework before knowing the requirements of the project. The "professionals" will use off the shelf if it makes sense or build their own if better results can be achieved.

In the case of Javascripting, you've got a lot of factors working against you. The first is size. You can't afford waste, because you're trying to ensure that the page renders as fast as possible. Dumping 100K+ from the scriptalicious framework just to fade out a single box isn't very effective to your budget. Especially since the same effect can be achieved in a few hundred bytes by using a custom framework.

The second factor working against you is reusability. Javascript is not very well designed to handle this area. Object Oriented concepts we take for granted in Java (interfaces, abstract classes, private methods, final assignments, etc.) are not enforceable in vanilla Javascript. So you have to either be really clever (sounds like trouble), or work through standardized practices.

The third factor working against you is maturity. These frameworks are of varying levels of maturity because such web technologies are anything but old-hat yet. There are plenty of situations they are untested in, potentially leaving you debugging someone else's code rather than moving your project forward. Thus a framework may actually increase your project time if you're not careful.

And with that, there's one last note I'd like to point out. Frameworks are far too often chosen as a crutch rather than a time-saving component. Make sure that when you chose a framework, it's because you know it will do the job you need it to. Not because you heard it's the latest craze (bad), or because you have no idea how to implement the functionality it provides (even worse).

Re:Frameworks

[Checkmait]

To be blunt, no you are not the only one. :-)

Re:Frameworks

[Anonymous Coward]

I created a fix for that gotcha in prototype, and the details are...involved. The framework is on sourceforge and it's called IWF (Interactive Website Framework) http://www.sourceforge.net/projects/iwf/

Anyway, there's tons of crap you'll never need in it -- so rip out what you do! It also has the ability to do basic animation, opacity toggling and dissolving, etc. Of course it adds to the bloat, but it's intended for you to pluck out what you need and can the rest...

To do the toggling you speak of (even when styles are defined in a style sheet / style tag / whatever):

function iwfShow(id, reserveSpace, displayMode){
var el = iwfGetById(id);
if (!el) { return false; }

if (reserveSpace){
var disp = 'visible';
if (iwfExists(displayMode) && displayMode != null){
disp = displayMode;
}
iwfStyle(el, 'visibility', disp);
} else {
var disp = 'block';
if (iwfExists(displayMode) && displayMode != null){
disp = displayMode;
}
iwfStyle(el, 'display', disp);
}
}

function iwfHide(id, reserveSpace){
var el = iwfGetById(id);
if (reserveSpace){
iwfStyle(el, 'visibility', 'hidden');
} else {
iwfStyle(el, 'display', 'none');
}
}

function iwfStyle(id, styleName, newVal){
var el = iwfGetById(id);
if (!el) { return false; }
var ret = '';
if (el.currentStyle) {
ret = el.currentStyle[styleName];
} else {
try {
ret = document.defaultView.getComputedStyle(el,null).get PropertyValue(styleName);
} catch(e) {
}
}
if (iwfExists(newVal)){
if (el.runtimeStyle){
el.runtimeStyle[styleName] = newVal;
ret = newVal;
} else {
ret = el.style[styleName] = newVal;
}
}
return ret;
}

function iwfExists(){
for(var i=0;iarguments.length;i++){
if(typeof(arguments[i])=='undefined') { return false; }
}

Re:Frameworks

[AKAImBatman]

Funny thing, though. I've seen more than enough situations where the framework is obsolete by the time it's done. Take Portlets for example. Seems like a beautiful idea. Web pages are composed of sections, therefore they should be built in sections, right? Right. 5-7 years ago, that is. When I built custom frameworks to good effect that did the same thing.

Today, you often need to go back to looking at the entire page. Why? Because the cutting edge developments require that the page be looked at as a complete memory model. If you try to take the HTML Component approach, programmer 1 may stomp all over programmer 2's Javascript or document ids by accident. Thus it suddenly makes sense to unify those pieces into libraries akin to more traditional programming methods.

Right tool. Right job.

Re:Frameworks

[Anonymous Coward]

For server side code I've been playing around with the Eddy Framework. For client side YUI all the way, but any word on why such an older version of YUI as looked at?

Re:Frameworks

[truthsearch]

Why not just use frames?

(Kidding, kidding...)

Re:Frameworks

[jeks]

Size, size, size...

I do not know why GWT was dismissed from the above test (claiming a new "Java API" had to be learnt, as if the other frameworks do not require some domain specific API knowledge). What I know is that GWT makes use of modern compiler optimisation theories to remove dead code (AVAIL and LVA comes to mind), to make the best decisions when it comes to code elimination. Go ahead, write your custom "l33t haxxor javascript" to keep on beating an already dead horse (bad) or reinvent the wheel (even worse).

You are probably the kind of person who think you can manually improve the register allocation by handwritten code over de facto graph colouring register allocation techniques, also implemented by compilers. Either that, or you are completely unaware of all the behind the scene computations made possible by a high level language such as JavaScript, in which case you have no idea how much "control" you are giving up. In that case, I suggest going back to asm.exe and load up a couple of networking libraries for TCP/IP, a scheduler library for multi-threading the GUI/network code, some screen drawing libs, maybe even a widget library, a nice HTML library, then some JavaScript sugar on top. Oh, wait!!! That is a lot of bloat, better make a custom library that implements only the necessities... See you at the asylum!

Re:Frameworks

[AKAImBatman]

You laugh now. But what if I told you that previous versions of EyeOS did exactly that? I wish I was joking.

I don't know about the current version, though. It seems to do some sort of weird page-refresh thing.

Re:Frameworks

[AKAImBatman]

Either that, or you are completely unaware of all the behind the scene computations made possible by a high level language such as JavaScript, in which case you have no idea how much "control" you are giving up.

Funny thing, though. "Control" was never a term I used. I never even insinuated that it was a problem.

Let me learns you something here, my young friend. There is a time for everything. A time to laugh, a time to cry, a time to make war, and a time to make peace. There is also a time for frameworks that meet your project specifications, and there is a time to eschew such frameworks as not being a good choice for what you need to do.

Now hear me out for a moment here. How many publicly available Google projects use GWT? When you come up with the correct answer (a lot of folks have the wrong answer to that question) you may find yourself with something to ponder.

Re:Frameworks

[suv4x4]

Today, you often need to go back to looking at the entire page. Why? Because the cutting edge developments require that the page be looked at as a complete memory model. If you try to take the HTML Component approach, programmer 1 may stomp all over programmer 2's Javascript or document ids by accident. Thus it suddenly makes sense to unify those pieces into libraries akin to more traditional programming methods.

I'm not sure how this negates the framework model. It's exactly a framework that could provide you always with a unique id, or avoid the need of an id.

I'm not familiar with Portlets and couldn't understand your example.

Re:Frameworks

[PietjeJantje]

Am I the only one who usually finds frameworks to be pointless for serious web development? It's not that they're necessarily bad, but that they pack in dozens of features that you don't necessarily need

This was my problem in the open source project, partly Ajax driven, I'm involved in. Exactly for this reason it sported custom coded Javascript from the start. I don't want to load 50K+ javascripts, and I don't want one big script with crap I don't need. If you have some fairly basic stuff which doesn't change much, it's much more efficient to hand-code your own javascript. Also, when this problem arose, and it is still true, these libaries are relatively brand new, and I found it silly to commit a codebase to any of them. However, if you do all your own coding, there are problems such as cross-browser compatibility, and also there is a certain threshold of complexity when you find you're factoring out the same code and problems, and one should consider a switch. But it is a dangerous point which should be a warning sign by itself, because it could imply your stuff is getting too bloated.

It turned out jquery (jquery.com) was the best choice in our case, it addresses exactly my worries by sporting a size of just 20KB, all extras come in modules, and it's very powerful. I'd rather have a 10K version, but there you have it, you can't have it all. How it (or I) work, is to load the core when the page is loaded, and only insert additional scripts (mostly dynamic, i.e. when you click something) when needed. Similary, Yahoo! has a fine, modulized lib which is extremely well documented.

Last but not least it must be noted that all of these frameworks use MIT/BSD style licenses, and I'd like to thank them all for their great tools and generosity.

Re:Frameworks

[drix]

In fact your very own logic argues for the use of a JS framework. Anything you write that relies on Prototype is going to be far more mature and reusable than something you cobbled together on your own. When I say "mature", I mean it in the holistic sense. It's very, very unlikely that you are you going find some trivial error in the core Prototype library. It's virtually certain that you would do so if you write your own. Maybe you will get them worked out by deployment time, maybe not. Second, Prototype has a rich and consistent API, and anyone who has experience writing applications on top of it could easily pick up your code and reuse it. Finally, you make no mention of cross-browser compatibility, which makes me wonder how much experience developing these sorts of applications you really have. Words cannot describe how much time you save when your starting point is something that works out of the box in IE, Firefox, Safari and Opera. You could sink literally hundreds of hours into testing your application on various platforms. Fortunately, you don't have to, because someone already did. Why reinvent the wheel?

Re:Frameworks

[jeks]

"Young friend", I take that as a compliment. Yet you are the one with an ID a couple of hundred thousand greater than mine. Do not despair, I shall assume you are quite old (since I am) and evidently slow (do not falter, I shall be too, soon enough).

You do make a good point regarding in-house production uses of GWT (it is 0, as we both know) but that does not set it very much apart from the other frameworks tested. There is GPokr though, which you may find yourself enjoying while pondering over your next irrelevant proverb to verbatim.

Re:Frameworks

[moochfish]

I disagree. If your goal is to write a website for mom, it is overkill to look at Prototype (maybe). However, anybody who is comparing frameworks is probably way beyond the simple stuff.

As for the bloat issue, this is where libraries like Scriptaculous are doing it right by keeping classes of components in separate libraries. Second, this is why browsers cache JS files. Third, if you want cool effects that are cross-browser compatible, you simply have to accept that such effects come with bloat. If bloat is a show stopper, then you probably shouldn't use fading transitions with scaling div boxes anyway.

And if the argument is that these add way too much *unused* bloat, this comes back to the "mom's website" argument I made above. If people want to use machine guns to hunt cockroaches, that's their call. Unlike with a machine gun, if Prototype is too much, you can always cut out the small pieces you need. That's right -- people seem to conveniently forget that if they only really need one small, tiny part of a much larger library, they're always free to simply cut and paste that component out (MIT license is a great thing, huh).

What? But you need the rest, just in case? Then don't complain about the bloat you are willfully accepting. But in all honesty, Prototype's foot print is tiny -- about the size of an extra image banner -- and it gets cached.

I have been using Prototype extensively lately, and I have found it as a major time saver. By using it, I don't have to remember the various undocumented "gotchas" across browers. I'd much rather deal with the well documented show/hide issue than trying to figure out how to make transparent text in all of the browsers. On that note, did you know Prototype tries to prevent the very "gotchas" you talk of? For example, stopping event propogation is the same method no matter what browser you are using, and the Element.setStyle/getStyle methods correctly convert the 'opacity' property depending on the browser being used. So for whatever "gotchas" you are using to discredit Prototype, I think you are conveniently ignoring the hundreds of others that Prototype strives to fix, silently, without the developer ever knowing.

And lastly, about the notion of writing your own custom library -- that's hardly an option for most people. First of all, most web developers are not JavaScript experts. In fact, I've almost never seen someone use exception handling in JavaScript, short of in libraries like these. More importantly, even if you were some kind of JavaScript guru, are you going to test all of your methods in all of the browsers out there? Can you guarantee your AJAX calls work the same in all browsers? What happens if I trigger a second one during the first one? Is your implementation really more efficient than Prototype's? How long is it going to take to design this custom library? Is it extensible? Does it respect the global namespace? Does it play nice with other JS files I include? Does it work in strict/quirks mode? Like I said, writing such a library isn't an option for most people. Prototype is as close as it gets to a "patch" library, which is why so many other frameworks are built on it. That, and it has been extensively tested, which is a requirement for most companies rolling out technologies like it.

Re:Frameworks

[chromatic]

Object Oriented concepts we take for granted in Java (interfaces, abstract classes, private methods, final assignments, etc.) are not enforceable in vanilla Javascript.

I won't defend the difficulty of relying on other packages in JavaScript, but Java's idea of OO is by no means the only way. Arguably, it's not the best way either--structural subtyping is a curious decision, at best.

Re:Frameworks

[Watts Martin]

Hmm. While I often find myself agreeing with you in Slashdot posts, I have to throw in a whole lot of "well, sometimes" flavored salt in with this one.

Yes, frameworks are always inefficient compared to something tailor-made for a specific case (or even just the set of cases that you customarily deal with across multiple projects). But execution efficiency has never been what (honest) frameworks promise you; what they're after is development efficiency, which is quite a different matter.

Just focusing on Prototype (not Scriptaculous), by using it I can screw around with Ajax in a clearly-defined, well-tested fashion that frees me from worrying about all the mysterious browser incompatibilities that it knows about and already accounts for. I get a lot of very useful extensions that aren't directly related to Ajax (enumerations, getElementsByClassName, just the $, $A, $F, etc. shorthands!). In development time, this can be a pretty big win: a homegrown library can certainly get to Just Where You Want It, but it's not going to start out that way. You're going to spend a much bigger chunk of your development time doing the debugging and tweaking and noodling of your library than the guy using Prototype will, and you're probably going to do more hammering on it to adapt to each new project, unless/until it gets to a point where it's effectively been generalized into, well, a framework.

Yeah, prototype.js is about a 65K hit, and effects.js from Scriptaculous would be another 33K if you loaded it, too; for our friends stuck with modems, that could be another 20 seconds, although for everyone else we're talking about, well, one or two seconds. And only the first time it gets hit during that session (before it's cached).

No, you don't want an unnecessarily porky client-side library piggybacking your HTML, but I'm not convinced the "bloat" they add is always unwelcome. I think the charge of forcing you to structure a project around them is also a little overstated -- Prototype has a few oddities, like the problem with the CSS 'display' attribute you mentioned, but it's hardly the equivalent of CakePHP or Rails in terms of "do it our way or we'll make life hell for you." (Which isn't really a knock against either of those frameworks, but you'd better know you're going to be doing it Their Way going in.)

Re:Frameworks

[protohiro1]

You are not using YUI. YUI exactly what you are asking for. YUI is a libary, not a framework and it does exactly what you are asking for. (I also am kind of down on frameworks, good for RAD, not great for scaling full on apps) Look into YUI Dom, Event and Connection. Lightweight, cross browser libraries that solve problems for you. DOM addClass, removeClass and getElementsByClassName are key. Event has great add/remove listener that helps you centralize managing events. YUI connection is kick ass ajax, etc, etc. Hit up developer.yahoo.com and enjoy. We use these in production. On a site that gets ten million page views a day. Now, YUI widgets...not the best thing ever and kind of heavy...but the libaries rock.

Re:Frameworks

[Anonymous Coward]

Professionals recognize Web 2.0 applications are just the latest faddish crap. Yet another excuse to reinvent the wheel. I'll pass thanks.

Re:Frameworks

[Heembo]

Am I the only one who usually finds frameworks to be pointless for serious web development? No, you are right on. I build code for fortune 10's and other very large entities. I am part of a small elite team of Java architects who work fast. Java, yea, we use a very bare-bonus MVC utility library. But overall, we have proof of concepts that the rest of us repeat to ensure that all of our code is consistent as if coming from one developer. Then we pier review our code. Then run it by security scanners. We then beat it all up (especially ajax stuff) in QA. Then release. It works.

For Ajax, especially when you want to win on the evil triad of Firefox, IE 7 & and Safari, custom coded CSS/Javascript using the simple AJFORM library seems to be the best way to work fast and win on the client.

Thats a small elite team; when you have a large project with a great number of average developers, this kind of development breaks down and then you need the crutch of a framework. But even then, a average developer can do some REALLY bad stuff within a framework. Any framework. Moral: small senior teams that use solid libraries beat out large average teams with frameworks any day.

Re:Frameworks

[HaMMeReD3]

Initally I wrote a whole document as to why dojo is actually good, but I'll try to sum it up in less words.

1. Platform Independance
2. Roadmap/plans on dojo really outline how they care about code quality and developing a flexible/extensible solution.
3. I only use about 20% of dojo, but it has probably saved about a year of development time, I used to have a "do it myself" attitude, but after extensively developing under dojo, that opinion has changed to "don't reinvent the wheel" which is especially true when there are people improving the wheel for you free of charge.
4. Allows a great separation between dojo code and my proprietary code. I have not yet had to even touch a single line of code within dojo, because I've been able to workaround any problems via inheritance or my own custom widgets stored in my own namespace away from the dojo code.
5. Things aside from widgets have been proven time and time again to be incredibly useful, e.g. formbind binds a a form to a ajax request, allowing you to directly turn that entire form into a ajax request (no page redirect) with just one line of code. dojo.event.connect allows me to wire up all my onclicks, hovers, etc very easily. dojo.lang.hitch allows me to force scope on a function which might otherwise be out of the scope I would expect it (e.g. xmlhttprequest callbacks, some event handlers, etc)
6. Great build tools that seriously optimize code/execution time at release time. I've dabbled in it and it's increased my load time (with a non-optimal build) from like 10 seconds to under 1 second (which is acceptable for the enormous scale of the application, which is contained in a single page).

I'll stop there, but dojo is priceless to my development, I would have spent countless time redeveloping all the tools I use from it, and half of them I wouldn't have even considered using, instead I'd be using some primitive half baked stuff I hand wrote that wouldn't come close to the quality of the work the dojo team puts into there code.

Re:Frameworks

[billcopc]

You hit the main reason why I've avoided Ajax frameworks so far: bloat. The latest Prototype.js is 94kb... that's about three to four times the size of my current pages (with images). Most people only use a teeny fraction of Prototype's functionality. I'd be happy if they could make it modular, e.g. one include for Ajax features, one for rounded corners, etc. That way you can pick and choose just what you need, and even concatenate them into a custom bundle to cut down on HTTP requests. Having one monolithic JS library just means every single page load slows down to a crawl. The download size isn't the main issue, because that gets cached/compressed, but the user's browser has to parse and initialize the library for each request.

Re:Frameworks

[Paradise Pete]

The "professionals" will use off the shelf if it makes sense or build their own if better results can be achieved.

How many projects have you deployed using a framework?

Re:Frameworks

[rickla]

No he's not the only one. Frameworks and design patterns are some of the most abused "tools" ever. Maybe you do a prototype, but when you hit a limitation you can spend a lot of time on learning how to customize and extend the framework. The other problem I've had is revisions. Spring particularly was painful. Developer A needed a fix. The version with the fix changed something fundamental (not compiler detectable, something like calling order), and things break. Tough to manage. Give me a good collection of isolated parts. Hibernate, xdoclet, things like that. Far more leverage there I think.

Re:Frameworks

[dstoflet]

The route these libraries/frameworks are taking is allowing you to build and thus include only the js you need for your particular use case. For instance, the best JS lib IMO is Ext http://extjs.com/ which has a dependency builder where you specify the framework you want to use (YUI, JQuery, or Prototype) and the capabilities you need (e.g just Core, DD, or choose from umpteen UI components).

At any rate the Dr Dobbs article was pretty poor, seriously outdated and lacking much in the way of details.
Dojo is nice, but I found it to be too slow and recently I think they realized they needed to re evaluate some design decision and set a clearer path on where they are taking dojo in the future. They have not released much in the last 6 months (a minor dot release to 4.1 I believe). It does have the great feature of graceful degradation cause it can take existing markup and convert to supa nice UI widgets, but this requires it to traverse the whole DOM and look for 'dojo' widgets. There are workarounds, e.g specifying the element ids for your widgets to be dojo-ized though. Still though, pages (really when using UI JS frameworks they are not pages anymore but applications) with a lot of dojo widgets can be very slow to render. In addition dojo has some rough edges such as poor docs, too many grids that make it feel like there is a lack of direction etc. I look forward to the next major release though, Dojo certainly has a ton of potential.

But the kick ass JS library right now is Ext http://extjs.com/. Its well documented, very polished, has just about any widget you need, a super nice data abstraction for the grid/editable grid/combo box, and simplifies DOM manipulation and XHR. All the while being written in very nice OO JS style (yes I said OO and JS, for those you are ignorant of JS capabilities take a look at http://www.litotes.demon.co.uk/js_info/private_sta tic.html and http://phrogz.net/JS/Classes/OOPinJS.html

Re:Frameworks

[Anonymous Coward]

You certainly could prune out what you don't need to get the file size down.

These libraries are nice though since they have a lot more testers than you have. If there is a bug in version X of browser Y on platform Z, they'll see it before you will. The library will code the workaround in it and you just use the visible function.

Secondly, you'll only load it once. That's the beauty of ajax. You load the page once and then only fetch the rest of the content/code as needed. You should rarely have to download the same data twice. Of course the client should cache between subsequent page loads, but you don't have to actually ever leave the first page you go to.

On an ajax application I wrote, I implemented a client side function and data cache. You send an initial block of code to prepopulate the cache with stuff you expect them to use and then load the rest on demand. Because you are loading the code and data via ajax, you can use gzip compression without worrying about the annoying gzipped javascript doesn't work bug on some browsers.

The only time you actually have to load a new page is if you do file uploads and you can use an iframes hack to get around that. Everything else can be done via ajax.

You can even get around the forward/back/bookmark problems by storing some state information in the "anchor" part of the url (the part after the #)

Re:Frameworks

[Anonymous Coward]

libaries

Boy, your face must be as red as a strawbrerry.

Re:Frameworks

[Anonymous Coward]

Like you I code my Web Apps in C++. Awesomely efficient.

Who needs a framework? Losers.

Re:Frameworks

[putaro]

Us old guys were busy working back when /. started so we didn't find it right away and get low number ID's.

Re:Frameworks

[Fujisawa Sensei]

Struts

Struts is great, if you want to handcuff good OO Design, and just use the Struts features. As far as I'm concerned the only thing that make Struts even remotely useful is the Validation framework. The rest is crap for junior web developers who don't know how to use a web.xml and Model-2 MCV; it cripples the rest of us.

Re:Frameworks

[achillean]

It's not that they're necessarily bad, but that they pack in dozens of features that you don't necessarily need (potentially bloating the size of your page download by tens to hundreds of K) or even want.
I can't speak for all frameworks, but Dojo allows you to build your own custom dojo.js with whatever features you'll need. So it's really not a big problem if you don't want to have all their UI widgets, but like their event system. I wouldn't be surprised if most professional frameworks allow the developer to customize the features of the framework. Here's the link to a tool that builds the custom dojo.js for you:

http://build.dojotoolkit.org/0.4.2/web/buildscript s/webbuild/

Re:Frameworks

[yomahz]

they pack in dozens of features that you don't necessarily need (potentially bloating the size of your page download by tens to hundreds of K) or even want

Imagine for a moment that the year is 3801. Our top computer scientists have invented this super algorithm that would find repetitive patterns in text and replace them with a token, thus decreasing data size. Then imagine that the very same algorithm could be implemented in popular web clients and servers. Now that would be quite a time to live in!

If only... If only...

Re:Frameworks

[AKAImBatman]

You have no idea how much server-side GZipping futzes up AJAX and Flash apps in IE. Absolutely no idea.

Re:Frameworks

[Anonymous Coward]

Well, these are the essential questions to answer. But we need to answer this question for the frameworks too.

Re:Frameworks

[Achoi77]

It appears you got a specific arguement for GWT, whereas GP was talking about frameworks in general. GWT sounds like a dream come true when you need to build a pretty serious app - but honestly, how often are you going to run into that situation regarding web developers? It sounds like more the exception to the rule.

The issue stated with the other js frameworks is that it provides a breeding around for lazyness, which results in terrible terrible code designed by people that are clearly unsuited for the task(which is clearly not what GWT is aimed at). Think of it from the business perspective. Most 'web developers' you'll come across don't have an ounce of programming in their body. The ones that are qualified are likely 1) overqualified or 2) working and expensive. (I use the term 'web developer' as someone that states on their resume DOM/javascript/ajax experience)

On top of that, serious js developers likely already have a total grasp of js to begin with and is only looking at the various frameworks for RAD purposes only. So who does that leave? People that are not interested in grokking the dom, or browser quirks, or even the js syntax, and the business analyst equivalent of 'script kiddies.' :-( The market is ripe with them.

Re:Frameworks

[koreth]

So you're suggesting that once the fad is over, we will go back to plain HTML forms with submit buttons, twiddling our thumbs waiting for the whole page to reload to update one piece of data?

I'll take the fad!

Re:Frameworks

[yomahz]

You have no idea how much server-side GZipping futzes up AJAX and Flash apps in IE. Absolutely no idea.

The truncation problem referenced in the article refer to problems that have been fixed a while back:

http://support.microsoft.com/kb/871205

I cannot find anything on the etag/gzip problem other than the article you referenced but my testing with fiddler and IE7 cannot replicate the problem. I'm too lazy to start my IE6 VM and test with it but I don't really care. If I spent my time ruling out technologies because IE (or any other browser) has had a periodic bug with it, I wouldn't be witting software for browsers anymore.

Re:Frameworks

[Marcos Eliziario]

No. Soon we will quit trying to make 3270-with-fancy-graphics(a.k.a web apps) work like the users wanted it to work and we will all switch to JFC/Swing/WebStart or WPF, except for the applications that are WEB applications.

Re:Frameworks

[mongus]

Well, I tried to get it down to 10K but my compressor only got it down to 15K. Feel free to use it. For best results, feed the compressor the uncompressed version.

Re:Frameworks

[Anonymous Coward]

I like this one: http://twilightuniverse.com/projects/sack/

Small and simple. Does what I need.

Re:Frameworks

[mha]

Object Oriented concepts we take for granted in Java (interfaces, abstract classes, private methods, final assignments, etc.) are not enforceable in vanilla Javascript.

Maybe you should have a look at Douglas Crockfords excellent courses on Javascript and the DOM at http://developer.yahoo.com/yui/theater/ After viewing his presentations I decided to use the Yahoo library (YUI) without having actually tried it (by now I have) - simply because of the power of the presentations (which are all about JS, not the YUI in particular). I've been programming with Javascript on and off for a decade, but after Crockford I knew I never knew a thing about Javascript. Anyone who claims JS doesn't have powerful object orientation should go and see the Crockford videos!

Re:Frameworks

[mha]

... and by the way, the YUI is at version 2.2.2. Prototype is 1.5.1. I don't know about current versions of the others, but it seems to me that this review is VERY OLD and hardly newsworthy!

Re:Frameworks

[random0xff]

I never understood why the size of a Javascript framework is an issue. 100K, that's about two jpeg images, right? And they're usually cached by the browser, right? Is that really such a big deal?

Re:Frameworks

[PietjeJantje]

Very nice. Compressing my own script worked great. Compressing jquery-lastest.js (to 16K) and calling it from my own script didn't work well though "jQuery.each is not a function"

Re:Frameworks

[Anonymous Coward]

No, but once these "professionals" realise that the "World Wide Web" is not the same thing as the "Internet" and figure out that not everything has to be done over HTTP with an application that isn't suitable, we'll start to see real client/server and distributed applications that actually work and are useful.

Re:Frameworks

[cytg.net]

"Frameworks are what professionals use"
Sure, proffesionals use guns too .. bombs and weapons of mass destruction too ...
We're not too worried about the proffesionals, its the amateurs thats dangerous.
And while 99.9% of proffesionals are indeed amateurs, you can surely calculate the explosiveness of the construct.
Im sick and tired of halfassed frameworks.. been for years.

So to the topic writer beforehand's question:
Am I the only one who usually finds frameworks to be pointless for serious web development?
- NO, you are not the only one ... dont bloat what should not be bloated, and imprint this on your forehead, cause its the best adivce, close to divine intervention, you'll ever get as a developer..

KISS, keep it simple and stupid.

ponder about this one too for a few seconds ;
Everyone knows that debugging is twice as hard as writing a program in the first place. So if you are as clever as you can be when you write it, how will you ever debug it? -Kernighan

Re:Frameworks

[ray-auch]

Then we pier review our code.

ROFL.

You might want some peer review on your comments as well as the code...

Re:Frameworks

[Heembo]

Thank god I get paid to CODE and not SPELL. After some peer reviews, I'm ready to jump off pier, I swear.

Re:Frameworks

[Anonymous Coward]

I agree with that, but sometimes what the frameworks do is overkill.
Example, in a website I was doing, I was using Dojo, and the main contents was a ContentPane object in which I display the contents as such:

contents.setContent( render_page_blah(foo) );

But some pages where there was lots of contents I noticed a bit of leaks when contents were being replaced. I didn't have the time to dig into the dojo source to see what's going on, so I added this bit of code at the top:

var contents = document.getElementById("contents");
contents.setContent = function(html) {
      this.innerHTML = html;
};

And that made things a lot faster with no more leaks.

Re:Frameworks

[mattpointblank]

I agree. I'm rewriting my site to include a few fancy Web 2.0 features (really nothing more than some Lightbox stuff and perhaps a digg-style counter/votebox thing) and it's been a mission to find a lightweight framework. I tried a combo of Prototype and Scriptaculous but was horrified at the sluggish loadtimes, so moved onto MooTools which is much faster and achieves similar results.

Re:Frameworks

[Tim C]

Frameworks are what professionals use - the enforce well-formed code and design patterns.

Speaking as a programmer with 8 years professional experience, that's bullshit. Nothing can enforce well-formed code, except perhaps frequent code reviews by a competent, fascist reviewer (with the power to force people to rewrite stuff properly or replace them with people who will/can).

Frameworks have their uses, and can make some things much easier (and other things much harder or even impossible). I'd also strongly disagree that they are "usually... pointless for serious web development", just as I'd disagree with a similar blanket statement about using library code in more traditional applications programming. To say that they enforce well-formed code though is utterly ridiculous. No framework can do that, just as no language can. It is possible to write crap code whatever technologies you use.

Re:Frameworks

[Chatterton]

4 words: Impress First Time Users.

I don't see much other reason as you point it with the browser cache.

Re:Frameworks

[stronger]

You pointed many common issues and annoyances with general purpose frameworks. I strongly agree with some of them. The main problem in a larger perspective is that most frameworks tends to do too many things at a time. In my opinion there are three or four main areas that frameworks should focus on.
1. Infrastructure. A good transmission and request routing architecture is needed. This covers handling requests, XMLHttpRequest stuff, timeouts, cancellation, queuing, repeating, ordering and error reporting. A good infrastructure library should provide easy to use communication channel to and (often underestimated) from server.
2. UI library. Tight coupling user interface (widgets) with Ajax libraries is in my opinion frequent design flaw of frameworks.
3. Model classes. Often tied closely to format provided by UI or communication layer. General purpose model classes should be kept separate at all cost.
4. Other libraries, like newsletter or access control, should be kept separate as well.
The more are these areas tied together, the faster you hit the limit of a framework. Bearing that, it is amazing how much are general purpose all-in-one frameworks overhyped. They all bring a promise of delivering ultimate solution with no extra coding, which is in _many_ (no, I don't know how many) cases difficult to achieve (if ever possible).

And now some advertisement blurb. Skip if not interested.

I run sourceforge project Tigermouse PHP/AJAX framework, which aims to be enterprise-grade ready web application framework. This is why I tend to keep its parts loosely coupled. Each part can be easily replaced using the same interface (or adapter). Keeping codebase small allows you to integrate almost any existing library into it, but that means some extra coding (that breaks the unspoken promise I mentioned above).

Re:Frameworks

[Vicarius]

I never understood why the size of a Javascript framework is an issue. 100K, that's about two jpeg images, right? And they're usually cached by the browser, right? Is that really such a big deal? With 100k just for a framework you still need more for actual code, images, and content. It adds up and your pages start loading way too slow to be acceptable. You are taking for granted your high-speed internet connection that you had for years. Many people (US included) are still on dialup, slow satellite connection, or some type of wireless network.

Re:Frameworks

[DuckDodgers]

And I could show you inefficiencies and poorly-formed code and design patterns in projects that do use Struts/Shale/WebWork.

In my experience (I admit I'm no software development guru), the frameworks make for clean code in most cases. The exceptions are uses that are not planned for in the framework, or features that are poorly documented. Then you have a hugely kluged workaround or hack to the framework code itself to permit something that might otherwise be straightforward to implement.

And of course, there's the learning curve. It took me about two weeks to move from C++ to Java. JSP EL, Taglibs, Struts, XDoclet, Ant, and Hibernate collectively required more than a year of working and researching before I could call myself modestly competent. I had foolishly hoped that moving from C++ app development to Java web work would be easy - only to find that over half my work is adding or changing XML configuration files, writing JSP code and JSP expression language code, and changing Java comment annotations, and not working with Java directly.

Re:Frameworks

[Meostro]

It's not that they're necessarily bad, but that they pack in dozens of features that you don't necessarily need (potentially bloating the size of your page download by tens to hundreds of K) or even want.

This exact point has been raised about most of the frameworks out there, even beyond those listed in the article. I can't speak from experience for all of them, but I agree 100% for both Dojo and the YUI libraries. Even Yahoo's own developers realize that YUI is a little bloaty. Dojo has changed their roadmap to address this problem in particular, as well as most of your other main complaints about frameworks (gotchas, "standard" practices). They already have the framework split up in such a way that you can get some of the better parts without having to take the annoying ones - you build and/or dojo.require() only the pieces that you need. Currently there are some dependency chain problems that contribute to bloat, requiring any one widget generally will bump your Dojo size up 80-100k.

If you're doing a complex website, you'll probably be better off with a custom library for now.

This will always be true, but you can sometimes get the benefit of a framework without having to pay the full penalty of committing to it. Start with framework X and see how hard it is to build your app in The X Way (The Scriptaculous Way, The GWT Way, etc.) See how much it bloats your code and how many stupid workarounds there are for "features" that complicate your life. Try to use as little as possible, and make sure you alias it through your own library so you can swap to another framework if you get fed up with the existing one. Lather, rinse, repeat.

Eventually you'll find some combination that gives you that power-for-the-byte feel, where you get a lot of use out of certain functions without having to pay a huge size/complication penalty. Most of the time you'll find that you can write function Foo to do exactly what you need in 10% of the lines of code that the library does, and which will run faster as a result. This happens because, to a certain extent, the library HAS to be everything-to-everyone and has to handle all of the edge cases that your implementation doesn't.

For my current company, the answer was Dojo sans widgets. While originally we had used Dojo all-out and even thrown in 3 or 4 YUI libraries, we had to cut down our codebase just to make the download reasonable (hint: 1MB of JS will cause you problems. 2MB is practically pointless). Currently we use the transport and helper features of Dojo, and most everything else is rolled by hand. That 12K YUI library we were including for drag & drop support ended up being 12 lines of JS because we have a more tightly constrained problem than "allow anything to drag anywhere".

PS: It may be addressed in TFA (TLDR), but why did they evaluate old versions? GWT is at 1.3, YUI is at 2.2.0, Scriptaculous 1.7 came out in January and Dojo is currently at 0.4.2 - 0.4 was released in October!)

Re:Frameworks

[profplump]

In my experience (I admit I'm no software development guru), the frameworks make for clean code in most cases. The exceptions are uses that are not planned for in the framework, or features that are poorly documented. Then you have a hugely kluged workaround or hack to the framework code itself to permit something that might otherwise be straightforward to implement.

Could it just be that people who choose the right framework for their project are more likely to write clean code in the first place, as evidenced by their ability to choose the right framework, if any? I don't doubt that there's a correlation between good code and appropriate framework use, I just doubt the causality that was implied.

Re:Frameworks

[mongus]

Thanks for the heads up! The bug that you encountered has been identified and corrected. The new compressor even squeezes another 220 bytes out of jQuery! :)

Re:Frameworks

[Anonymous Coward]

A-ha, a typo! No bare bonus for you! ;-)

Re:Frameworks

[Dog-Cow]

You have the mentality of a piece of shit. Anyone who feels that a /. uid means anything other than they have a /. account is a meaningless waste and should simply be eliminated.

Re:Frameworks

[drew]

Good questions, although it's worth pointing out that (as of the last time I tried using it, which was some months ago now) Prototype does not play nicely with other JS files and did not respect the global namespace, which is one reason why we don't use Prototype where I work. (Our libraries are also smaller, and more modular)

Re:Frameworks

[xero314]

The second factor working against you is reusability. Javascript is not very well designed to handle this area. Why do you ruin any otherwise intelligent post with this complete nonsense. Javascript is very well suited for reusability as all prototypical languages are. Prototypical inheritance and Duck Typing make Javascript objects, including constructors some of the most reusable components in software. Miss understanding these elements and being stuck in the static typed, classical inheritance model is no reason to go bashing all other approaches to component reuse.

Object Oriented concepts we take for granted in Java (interfaces, abstract classes, private methods, final assignments, etc.) are not enforceable in vanilla Javascript. As I implied above, you are right that some of these things are not available, but why should they be, they only hamper the ability to reuse code. At best they make reuse safer, but normally it just makes reuses harder, and more confusing. Think about it. Abstract classes allow you to make a class you can't instantiate, making it difficult to use since you are required to extend it to use it. Final assignments make direct extension impossible in many cases. private methods, or functions that are not accessible out side the defined scope without explicitly passing them, are certainly available in Javascript and with a lot more flexibility than private methods in most classical models. Add in closures and function pointers and you see that JavaScript reuses is not the issue, but a developers understanding of how to use those features is. Damn, you're making me want to go home and work on a native ECMAScript compiler.

You can't afford waste, because you're trying to ensure that the page renders as fast as possible. Dumping 100K+ from the scriptalicious framework just to fade out a single box isn't very effective to your budget. Actually what you are doing is not making sure that any one particular page loads quickly but that all functions the user may wish to use operate in a timely manner. If you are writing a single page (or small number of pages) and all you want to do is to "fade out a single box" then using a complex AJAX library is a bad choice, but I don't think anyone has said otherwise. On the other hand if you are writing a web application, the only thing really warranting and AJAX library (these are more like libraries than frameworks, at least the few I have looked at), then you can use browser library caching to your advantage. You can either make the initial page take the full hit for the library load or you could load a subset of the library upfront and load the rest in the background or as needed. Once it is loaded it should not need to be loaded again even if you have page transitions and loads (which I could never understand in an AJAX application, but to each there own).

Seriously I bash web apps on a regular basis but bashing these specific libraries for reasons like them being overkill is really just missing to point, or misusing the libraries.

Re:Frameworks

[jeks]

That's an interesting way to contribute to a discussion.

It may be worthwhile to know that statements as your's are fascist by nature. Killing or having someone "eliminated" for having a different opinion than your own is not a very healthy outlook on life -- unless of course, you are a fascist.

Now, my opinion is not any different than your's in that I find the id:s as meaningless as you do. I also think it's pretty rude to belittle others implying they are inferior in age or experience when no such conclusions can be drawn (as was the case in this thread). It was only an attempt to take a more pragmatic approach to that discussion, although I can understand how that looks quite stupid in the end. Although, in comparison, your statement puts you way deeper in the "piece of shit" league.

Re:Frameworks

[Anonymous Coward]

JSDC - JavaScript Data Components has some(or maybe all, i am not sure) of those things..

Also, it has pretty interesting client-side dataset/database thing going.
Check out the docs:
http://jsdc.sourceforge.net/docs_reference.php

Anyway, it strictly javascript and is made to lessen the load of servers and anything but bloated.

Re:Frameworks

[reed]

++jquery! It's real easy to use.

I think that Dojo is actually generated from some kind of templates or something, and what is actually included in the output Javascript can be customized. (They include a few diffent downloads with different things available). It would be great if you could do the same thing with jQuery, or even if the .js file had some comments that allowed a script to hack out certain pieces.

One advantage of jQuery's one .js file (as opposed to different modules with different features in them) is that the browser only has to download it once, even if different pages use different features.

Re:Frameworks

[zig007]

You would probably like JSDC.

JSDC, Javascript Data Components(http://jsdc.sourceforge.net/docs_refere nce.php) has some really interesting stuff.

I'd say it's somewhere in between a library and a framework..It doesn't force you into anything.
It is actually not very GUI-oriented, it is more application-centric. If you know what i mean.

It features:
* Client-side datasets with nested transactions(or maybe it is more of an undo history), master-detail.
* Input verification
* Data-aware treeviews, tableviews and other stuff
* A quite interesting non-blocking animation class.
* A simple code generator
* And more.

Check it out!

Re:Frameworks

[zig007]

Hell, why not try the link without them spaces??
http://jsdc.sourceforge.net/docs_reference.php

And yes, obviously it has some Ajax stuff to.
Forgot to mention, i am currently making a specification for some client-server communication to enable a client to make multiple edits, undo:s and whatnot and then posting the changes to the server...You know like a real desktop client.
It should not be as hard as it sounds since JSDC stores edits in its undo-history.
It SHOULD not be much harder than just posting that data to the server and have a stub translating it into simple inserts, updates or whatever.

Re:Frameworks

[zig007]

Elite? Shouldn't that spell l33t?

Myself, on the other hand, is part of a positively minute CRACK TEAM OF CODING COMMANDOS that in a constantly record-breaking pace makes fortune 2-company-software that is so good that it makes our fathers able to easily kick the fathers of elite team members asses.

While writing this, i noticed that my 9-month old daughter solved a couple of np-complete problems using only the autonomous neurons of her right index finger. I remember having to use my entire hand myself.

Re:Frameworks

[Heembo]

Right, thanks for your insight and your daughters as well. I see you are teaching her a lot about charm that will serve her will in life.

What I'm saying is, a small team on senior coders do not need the crutch of a framework. And you will get a better product, lighter more agile JavaScript for Ajax (CSS/Javascript custom coded per the parents post), and faster delivery time.

Re:Frameworks

[zig007]

You're welcome. I learned a lot from your humble post.

A small team of senior coders can choose weather they should use frameworks or not.
When projects grow beyond what small teams(or even one company) can produce, frameworks stop being optional and discipline becomes critical.

When the specifications alone reach more than 2000 pages(try making stuff for something like a larger bank, for example) and includes demands of transactions per seconds, there is no agility left, i promise you.

Re:Frameworks

[Heembo]

Thanks again, I'm really humbled by your depth of emotional intelligence, it's really help me a great deal.

When your specifications reach over 2000 pages, you need one small team to set the architecture, and then several small teams to handle each sub application. When you have one large team of average coders "set loose" to work within a generic framework like Struts or any of the Ajax frameworks, you are shooting yourself in the foot delivering average quality applications. When you build you own biz-specific lightweight set of libraries along with solid proof of concepts for your sub teams, you are much better off, can develop faster and get higher quality. Large companies do NOT "humble agile coders" like you and your team. They want rock star coders who are architects in their own right.

Re:Frameworks

[zig007]

And no fun left either, by the way.

And don't misread me here, I don't mean that banks are great at IT or something, actually they s...never mind..
But it's just that in my experience, the customer implicitly sets the "agility-level" of a project through the level of detail it chooses in the specifications.
I have never really gotten to choose the level of "frameworking" to be done in those kinds of projects. It has always been a clear consequence of the specifications.

Re:Frameworks

[zig007]

Ok, if we only talking about the architecture-part of the project, sure then there are obviously fewer people involved. I am not sure if i'd say small teams, but ok.

Of course the whole team has to be divided into smaller teams. It's just that i found it seldom that the architecture work can be easily contained and defined like that..Other systems but mostly policies, rules and laws tend to grow solutions and their architectures beyond a simple tree of sub-applications. Half the team isn't supposed to know what the other does for some strange security reason, and so on.

And generic frameworks are many times a requirement, the customer says it is "good enough" and don't want to be locked in. They want to be able to tell you to go away. But that is a quite new trend. Kind of.

But regarding rock star attitude:
Nowadays I work in a the financial sector, which means small companies(headcount-wise), and where the customers themselves are the "rock stars" and on occasion makes more money than heads of fortune whatever companies.

If I would go in on a meeting with a big ego telling them how good I am, I would be wasting their time and they would be telling me just that and to get to the point.

They would not even be talking to us if we hadn't a solid history and name. So acting that way would be pointless. Relaxed and professional, that's what they like. According to me.

But that may well be a cultural thing and probably very different depending on the sector.

Anyway, i am at another TZ so i need to go to bed now. Really tired now.

Good night.

Re:Frameworks

[Heembo]

As a rock star coder, I do not tell companies what they need. I listen really carefully first, ask a lot of questions for clarification second and build solutions based on their needs third. And yes, you are right, at time companies have framework requirements, but they end up paying a LOT more and get a " spaghetti code " system that is even more expensive to maintain. I am not a rock star coder cause I satiate my ego, I'm a rock star coder cause I build systems that really help people based on a careful process of analysis of THEIR needs, not mine.

Re:Frameworks

[zig007]

If you write most of the product specifications, yes.
However in the last few years more and more customers have, for many reasons, started to used their own consultants to make the initial specifications, which lessens the amount of listening dramatically.. Which is both a good and a bad thing, better specifications but less ideas from the developer to the client.

Regarding code quality, I would say spaghetti coding and workarounds happens is when a framework doesn't suit the needs of the project. In these cases, we would either one use another framework or make one from scratch. There would always be some form of framework in place. Unless of course it is a really small project.

Regarding self confidence, i have a small country's worth.
I am just careful so that i merely hint that to the customer....
It is so easy to step over the line into bragging and when that happens, the eat you alive. Maybe not always in front of you.

Re:Frameworks

[Heembo]

Ah, you woke up! I've been awake for the last 2 days coding! Rock star, baybeeee!

But seriously, especially this last post of yours, you are right on the money. I was just telling a client today that this project was going to be 75% meetings, design, and product/business analysis, 20% testing and 5% coding. I bring a MBA with me to these meetings who can listen and talk. We are helping the fix processes that this business adapted around a product they have been using, and are trying to write them a new system that maps to their real business processes. We are trying to set them free buy figuring out what they really need.

I tried your advice (honestly) and listened more and talked a lot less - but they though I was sleeping. They WANT me to interject, provide advice, really mix it up with them. They WANT me to step over the line and shake things up. And this is a traditional finance firm. They tried it the old way for years - and they keep getting screwed or need to adapt to some crappy salesforce.com, peoplesoft, interaction, some other turnkey product, or some custom system with limited stability or use. Instead, we are building them a custom product that fits their biz needs exactly that actually works.

An who cares if they eat you alive or talk about you behind your back. What matters is not your ego or balls, but can you get the job done, can you really help these people, can you make a difference, do you really care about what you are doing? That's passion, bub, and sometimes whipping your metaphoric cock out during a meeting is inspiring for everyone.

Especially if you can actually deliver.

Re:Frameworks

[zig007]

You should sleep more or you'll snap one day. I have seen that happen and it isn't pretty, people don't see it coming. Imagine two years(or maybe the rest of your life) of not being able to turn on the lights in the room you're in, because of the headaches. Hm, i can't remember giving you any advice on being passive on meetings. Sounds like a really stupid advise and if anything I have said could possibly be interpreted in such a way, i apologize. Of course one should be totally brilliant at meetings. I'm just saying that to really impress a customer you say brilliant things without emphasis. Like there was no effort and this is nothing like what is to come. And I care about what I am doing, don't get me wrong.

Re:Frameworks

[Hynee]

Sounds like JavaScript needs namespaces. About a year ago, in every PHP discussion here, people complained that PHP needed to support namespaces. At first I protested, then I decided to ask what namespaces were (I had a vague idea) and why they were useful, and var name clashes were the main reason.

Anyway, prefixes for each module/portlet, and minimal use of global objects can do the trick. Web code is like flight software anyway, you just want it to go fast and be reliable, hence the popularity of PHP and its massive library of functions (procedural-programming friendly) coupled with MySQL for it's speed and scaleability. <Insert similar reference to Perl/Python here even though I don't know or care for either>

Re:Frameworks

[Andy Dodd]

This is the first time I've seen a UID lower than mine...

That said, you make the rest of us sub-1000ers look bad.

A low UID is good for one thing, and one thing only - shutting up a "my UID is lower than yours" battle between a pair of 6-digit-plus users. :)

MooTools

[teknopurge]

what about mootools?

Re:MooTools

[ooglek]

I LOVE mootools. I've tried others, and mootools is the best.

Re:MooTools

[Anonymous Coward]

For real. MooTools rules.

Nothing to see here......

[Anonymous Coward]

More Web 2.0 fad crap.

QooXDoo

[ClarkEvans]

I've had solid luck with http://qooxdoo.org/

Security not a consideration?

[Lux]

Curious. With javascript hijacking attacks just discovered a few weeks ago, security was not a consideration in the evaluation at all.

I'm a bit disappointed.

Re:Security not a consideration?

[hansamurai]

I also found it odd that the author uses Dojo Toolkit v 0.3.1 as I believe 0.4.1 has been available for months and 0.4.2 is the current release. Though I don't know the differences between the releases so maybe it's no big deal.

Re:Security not a consideration?

[FLEB]

I do agree that security should have been a consideration. That said (and I'm honestly asking here), are there vulnerabilities (particularily XSS) that can be created purely by adding AJAX components? I suppose that in the case of a package with server-side parts there could be XSS vulnerabilities on the server side, but given that AJAX, like all JavaScript, is restricted to same-domain-only, any leaking or insertion of data would have to come from the same old back-end "didn't sanitize the input" problems.

Re:Security not a consideration?

[foxyLady]

Well, Fortify Software Security Research Group (which I am part of) has recently released a report ( http://it.slashdot.org/article.pl?sid=07/04/02/111 3242 ), where we discuss the new type of vulnerability we named JavaScript Hijacking.

We believe that JavaScript Hijacking is the only type of vulnerability found so far applicable only to Ajax applications. We've also analyzed 12 most widely used Ajax frameworks (DWR, GWT, Microsoft "Atlas", xajax, Prototype, Script.aculo.us, Dojo, Moo.fx, jQuery, Yahoo! UI, Rico, and MochiKit) and determined that all the frameworks that use JSON and/or JavaScript for transferring data (except for DWR 2.0 which was not released at the time) are vulnerable to JavaScript Hijacking.

To summarize, the vulnerability allows an unauthorized party to read confidential data contained in JavaScript messages. The attack works by using a tag to circumvent the Same Origin Policy enforced by Web browsers. Traditional Web applications are not vulnerable because they do not use JavaScript as a data transport mechanism.

Complete report is available here: http://www.fortifysoftware.com/servlet/downloads/p ublic/JavaScript_Hijacking.pdf .

As a side note, DWR 2.0 ( http://getahead.org/dwr/ ) and Prototype 1.5.1 ( http://prototypejs.org/2007/5/1/prototype-1-5-1-re leased ) have been recently released, and do contain fixes that prevent JavaScript Hijacking.

Re:Security not a consideration?

[kilkenny]

As always and specially in relation to Ajax security is a problem.

This is what GWT says:
http://groups.google.com/group/Google-Web-Toolkit/ web/security-for-gwt-applications

Same thing about YUI:
http://developer.yahoo.com/security/

---
check out => http://traceurl.com/rdS?r=1&l=2

Re:Security not a consideration?

[AKAImBatman]

That's a very interesting security exploit you and your colleagues have found there. Allow me to be the first to congratulate you on being both foxy and smart! ;)

I have a minor question, though. I'm currently implementing a JSON-type of interface, but I'm doing things slightly different from the straight-up JSON message described in your paper. Correct me if I'm wrong, but wrapping the JSON request in an XML packet would negate the effects of the exploit, wouldn't it?

For example, if I'm sending this message:

({test: "Hello World!"})

The actual data delivered to the client is in the form of:

<message id="123" system="false">
<![CDATA[({test: "Hello World!"})]]>
</message>

I did this for maximum compatibility between request libraries. (I'm dealing with more than just Javascript requests.) If I'm understanding the exploit correctly, the browser would see this message as a malformed script and fail to load it, correct? Do you see any obvious method of defeating this encapsulation?

Re:Security not a consideration?

[foxyLady]

My user name was created way before i got all that smart :)

Anyway, to answer your question, if you're using XML as your data transport format (just like Rico and xajax frameworks do), then you're safe from JavaScript Hijacking: XML is not valid JavaScript, so it will not be correctly eval()-ed.

Re:Security not a consideration?

[andrew_dupont]

You're likely referring to the JavaScript Hijacking paper from Fortify Software, the one which finds a loophole in a ridiculously contrived scenario that applies to roughly six sites on the planet. The threat they identify is real, but unlikely; it's orders of magnitude less severe than an XSS flaw or SQL-injection attack. Bob Ippolito demystifies the threat.

Nine times out of ten, a security exploit that uses JavaScript as the attack vector must be solved on the server-side, not in the JavaScript itself. This isn't buck-passing; it's just the truth. Nothing I can add to a JavaScript library will intercept a XSS attack, since the vulnerability (unsanitized HTML) lies on the server. Once the malicious JavaScript is on the page, the game is over.

That said: one of the suggested ways to protect yourself from this hijacking flaw is to surround the returned JSON with comment delimiters. Prototype 1.5.1, released on Tuesday, can handle this automatically.

(Disclosure: I'm a member of Prototype Core.)

Re:Security not a consideration?

[AKAImBatman]

Hi Foxy, thanks for your reply!

My user name was created way before i got all that smart :)

Hey, it's not often that I find an opportunity to compliment a lady without sounding like a total dork. So just enjoy the compliment. ;-)

if you're using XML as your data transport format (just like Rico and xajax frameworks do), then you're safe from JavaScript

Thanks for verifying that. I figured I was safe, but every once in a while there is a very clever workaround.

Re:Security not a consideration?

[Lux]

I've actually read a couple of Mr. Ippolito's posts on this topic, and found them to be more entertaining than demystifying. My read is that he's making a stink of this to soothe a bruised ego. He has clearly taken that paper personally, and is responding to it as a personal attack than as a technical issue.

Some choice quotes from his comments:
> NOTHING MochiKit can do is insecure (in this way). Whatever the client sends or decodes is irrelevant. It's a 100% server-side issue. I added comment stripping support so that people would shut up, not because it's useful in theory or practice.

> Brian, are you literate? It certainly doesn't seem like you actually read the post. I'm well aware of what secure code is and how it's done and that's not what bothers me about you, your paper, and the reaction to it. (emphasis added)

While I have added features to make my customers happy, I have never in my professional life told them to their faces that I was only doing something to "make them shut up."

This debate is not technical for this guy. It's personal. Can the attack be modified to work in IE? Can it be generalized to arbitrary objects instead of just arrays? I don't know. I'm more of a server-side guy. But I sure as hell wouldn't take this guy's word for it if he's saying it can't.

No, man, Joel drove them off the cliff:

[smittyoneeach]

Am I the only one who usually finds frameworks to be pointless for serious web development?

http://discuss.joelonsoftware.com/default.asp?joel .3.219431.12

Script# ?

[JoelMartinez]

too bad they didn't look at Script# ... good stuff :-)

Re:Script# ?

[vdboor]

Something I also missed was xajax. They use AJAX as RPC layer, calling a server-side method from JavaScript, and in reverse call methods on the clients back. This is easy to implement in existing pages, and leaves much room for implementation.

Instead of parsing data structures in the client, xajax allows you to send HTML chunks, JavaScript method calls and DOM operations back (making it two-way RPC). The most interesting part is you can reuse all server-side code created in the "web 1.0" days, like HTML template engines. :-)

Re:Script# ?

[adamruck]

Xajax is awesome! I use it a lot at work. I think that xajax would fall into the "library" category more than the "framework" category.

As a .NET developer

[leather_helmet]

ASP.AJAX

MS's toolkit has been great - FF & Safari support is a breeze in most instances, allowing us to develop our applications really quickly

Having downloaded and hacking a few quick demos with the silverlight BETA API, I am looking forward to integrating the CLR in our future releases

Re:As a .NET developer

[ozphx]

Seconded. You can take an existing page, wrap a few regions in UpdatePanels and the whole thing just works without code changes.

And it works in firefox. Whee.

This is how an ajax framework should be done.

Re:As a .NET developer

[Anonymous Coward]

How can this discussion leave out .Net so blatantly when the whole AJAX movement is owed to MS and it's XMLHttpRequest. Not to mention how much crap they took from everyone in the open source browser community when they introduced it. I know the article didn't include .Net in their case study of the company's eval process but the /. comments section should know that .Net AJAX is (IMHO) the best damn AJAX framework by a long run....

k.

Re:As a .NET developer

[RightSaidFred99]

Amen to that. Most of the zombies around here don't really know what's going on with MS, but they are really pushing out some hard core cool shit lately. ASP.NET AJAX, Enterprise Library 3.0 and the several blocks it includes, WCF/WF/WPF trifecta from .NET 3.0, each of which is truly ahead of _anything_ else in their domain, all the stuff coming with Orcas, etc... Let's see some open source zombie crank out the equivelent of an EL3.0 enabled, WCF web service that supports WS-I + WS-Security Kerberos extensions, and runs a state machine based workflow and has SQL server persistence. They can't. A good MS developer could crank out a basic skeleton implementation within 8 hours of work.

I always like reading Slashdot articles about the latest Perl module or little widget toolkit from Google, it amuses me. In the meantime, the Microsoft stuff they constantly bash is light years ahead and far more integrated and easier to use than all the random open source shit you can download and try your luck at. If you work in a large company or can afford to use MS's stuff, there's really nothing like it.

Frameworks versus Libraries

[dmeranda]

This sounds like the classic Framework versus Library debate. Some good reading:

The Dojo mailing list thread "dojo: framework vs library"
http://dojotoolkit.org/pipermail/dojo-interest/200 5-May/000231.html

Joel Spolsky's "Why I Hate Frameworks"
http://discuss.joelonsoftware.com/default.asp?joel .3.219431.12

Arnon Rotem-Gal-Oz's "Frameworks vs. Libraries"
http://www.ddj.com/blog/architectblog/archives/200 6/07/frameworks_vs_l.html

That being said, there are plenty of features in Prototype which are more library-like than framework-like, so it is easy to use parts of it without buying into a whole framework methodology. I don't know much about the other evaluated tools.

Re:Frameworks versus Libraries

[anomalous cohort]

Thanks for the links. IMHO, only the last one is coherent. To abuse on old joke around here, in Soviet Russia, frameworks call you.

What Spolsky (and everyone here) is complaining about isn't really about frameworks versus libraries but more about heavy weight versus light weight. Frameworks can get heavy because they tend to combine lots of functionality in a way that introduces a lot of dependencies, thus increasing coupling (which, in software engineering, is a bad thing). That's where the feeling of having to deal with a lot of stuff that you don't care about comes in. A lightweight framework tends to chunk all this complex functionality into a set of relevant services then uses Dependency Injection as the plumbing to connect the services together. A really great book on this topic is Better, Faster, Lighter Java.

Re:Frameworks versus Libraries

[protohiro1]

As I said elsewhere, YUI is a library, not a framework. It is very small and you can include only what you need. I suggest all the people complaining about frameworks are not even addressing what we are talking about here, which is the fact that javascript libraries make advanced JS development possible, because you don't have to waste you time solving solved problems and you can focus on your app.

My experience with Dojo

[hansamurai]

I have had an experience very close to the author's. My group at work maintains an internal app served with Websphere, just like the author. We have a tree of nodes that recently ballooned in size to 40,000 nodes and this was causing our CSS/javascript tree to choke as it loaded everything once and used the CSS to handle opening and closing of nodes. It would take about 5-10 seconds to load the tree once, but after that it would perform nicely. We wanted a near instant load at start and then whenever you expanded a node it would grab its children from the database and display them then. My coworker and I didn't have any AJAX experience when we started working on this problem so we turned to frameworks.

First think I looked at was the Google Web Toolkit, and dismissed it as quickly as the author. I suppose if we ever rewrite our app from scratch we'll maybe consider it, but not right now. Then I found dojo, and we started using that to implement a dynamic loading tree. I got it working and plugged into our database fairly quickly, but found out it wouldn't help us much. Clicking on a parent to display its children can take anywhere from 1 to 15 seconds depending on the how many children it has, and also basically freeze your browser while it's doing that. It also either had a memory leak or just managed memory inefficiently because the browser's memory footprint would balloon in size as you clicked more and more nodes.

My coworker eventually took it into his own hands and started hacking the dynamic loading himself. I've been busy with other projects so I don't know how he did it exactly, but it's a combination of our old CSS tree and some dynamic loading to speed up the initial load. Clicking on a massive parent can still cause some slow loading, but it was better than dojo. I think dojo is a great toolkit, but when you just want to pull one specific piece out of it, it can be cumbersome and bloated. Also, the documentation sucks and if I needed help, I mostly just read over old bug fixes and such. I forwarded my coworker this article so maybe we'll look into YUI.

Re:My experience with Dojo

[I Like Pudding]

We have a tree of nodes that recently ballooned in size to 40,000 nodes and this was causing our CSS/javascript tree to choke as it loaded everything once and used the CSS to handle opening and closing of nodes.

Are you sure javascript is the problem here?

Thanks for the session id

[Gyppo]

Generally not a good idea to not post URLs with your jsession ID in it. I love when people forward their Evite invite URLs thinking they're sharing the event invite but they're enabling people to reply on their behalf.

Where's MyBic?

[AssProphet]

A Review comparison of MyBic to these frameworks would be nice. Anyone out there that would like to volunteer?

Just don't choose them all!

[ObligatoryUserName]

Earlier this year I got pulled into a project that had been done by a team from everyone's favorite subcontinent. They had used both Yahoo and Scriptaculous /Prototype at the same time!

The site would download quickly enough, but then the page would just sit blank and churn for about 30 seconds before displaying anything.

It was hideous, and it was never getting closer to completion, so we replaced their 108 man-months worth of Ajax coding with 2 man-months worth of Flash development and everyone was much much happier. (It loads in less than 1 second and the management thinks it's cool.)

Re:Just don't choose them all!

[maxume]

Was it digg?

Re:Just don't choose them all!

[Anonymous Coward]

Top reasons I hate Flash or why I choose Javascript over Flash:
1. Navigating through a site and I hit back .. leaving the site. Oops, I've been trained from HTML pages to navigate that way. This angers me to no end.
2. As a programmer, until recently, it was extremely time consuming to do anything that I could do in Ajax quickly. Huge learning curve trying to learn how to use flash.
3. Complex Flash Applications generally use much more CPU and are extremely sluggish compared to Ajax apps (in your case the Ajax programmers didn't know how to code well, 30sec to load .. wow, pathetic)
4. You are more likely to be compatible with javascript/Ajax than flash, since most sites use javascript in the first place to detect if flash plugin is installed.
5. Forget about getting any real Search Engine traffic from an 'all flash' site. (unless it's an internal corporate thing)

Flash will probably always be the best choice for eye-candy animations and video streaming. For management trying to impress someone, that's usually important I guess.

Re:Just don't choose them all!

[ObligatoryUserName]

I know nothing I can say can remove the pain of bad past experiences, but let me clear up your misconceptions.

1. Navigating through a site and I hit back .. leaving the site. Oops, I've been trained from HTML pages to navigate that way. This angers me to no end.

This is really a problem with any single page site, which is what Ajax is - a single page that loads in the different components. The same methods to make the back button work with Ajax can be used for Flash. It's just that not everyone uses these methods with Flash or Ajax.

2. As a programmer, until recently, it was extremely time consuming to do anything that I could do in Ajax quickly. Huge learning curve trying to learn how to use flash.

As someone who has done a lot of Flash and Javascript, I would say that the learning curve is feature-for-feature worse for Javascript because you need to learn about the different browsers, but may be greater overall for Flash because it offers more features. That's a trade off I've been happy to make.

3. Complex Flash Applications generally use much more CPU and are extremely sluggish compared to Ajax apps (in your case the Ajax programmers didn't know how to code well, 30sec to load .. wow, pathetic)

Computation for computation, Flash has better performance than Javascript. At least, I think that's why Mozilla accepted Adobe's donation of the EMCAScript execution engine from Flash. After that's incorporated I would believe that Javascript alone would run faster, but right now that's not true. (Or if it is true, someone better stop Mozilla.)

4. You are more likely to be compatible with javascript/Ajax than flash, since most sites use javascript in the first place to detect if flash plugin is installed.

This is another issue of every site being different, but the fallback for not having Javascript enabled can easily be to show the Flash content. The only reason everyone uses Javascript to embed the files now is because of Microsoft's attempt to screw plug-ins.

5. Forget about getting any real Search Engine traffic from an 'all flash' site. (unless it's an internal corporate thing)

This isn't an issue for me since I usually use Flash for corporate apps that you wouldn't want indexed, but again this isn't something that's inherent to Flash. The issue is that Flash sites often pull in dynamic content. That's what the search engines can't index, and again it's something that's going to be a problem for any Ajax site that does the same. (Google has been indexing Flash for years and Adobe offers a free SDK for developers of search engines. Also, Flash-dependent sites like YouTube are definitely not starving for traffic.

As long as we're talking about pet peeves here are two essential things Javascript/Ajax needs to address that Flash already has.

1) Built in security against cross-domain scripting.
2) Accessibility for the disabled.

"[F]or management trying to impress someone, that's usually important I guess" -- if that someone you're trying to impress is either your boss or your client then there's no guessing about it.

Re:Just don't choose them all!

[Thundersnatch]

The only reason everyone uses Javascript to embed the files now is because of Microsoft's attempt to screw plug-ins.

Microsoft got sued by a patent troll. Like it or not, MS were the good guys in this particular case, and aren't intentionally screwing anybody. Microsoft is trying to do the smart (and decent) thing by starving Eolas of future revenue. Microsoft and its deep pockets "took one for the team".

Re:Just don't choose them all!

[AKAImBatman]

As someone who has done a lot of Flash and Javascript, I would say that the learning curve is feature-for-feature worse for Javascript because you need to learn about the different browsers, but may be greater overall for Flash because it offers more features.

Flash also has cross-browser problems. SWFs don't execute exactly the same on all browsers because many of the functions are handed off to the web browser. Nowhere is this more evident than with the XML.sendAndLoad APIs. They may work fine on one browser, but return unexpected results on another browser due to different caching architectures.

Computation for computation, Flash has better performance than Javascript. At least, I think that's why Mozilla accepted Adobe's donation of the EMCAScript execution engine from Flash.

Computationally, neither Flash nor Javascript have traditionally won any prizes in this area. If you want fast code and nothing else, look to Java Applets. The reason why Mozilla accepted Adobe's donation is because Adobe offered a brand new VM that fully supported the new ECMAScript 2.0 standards. Thus Adobe saved the Mozilla team a great deal of time and effort that they would have had to spend building an updated Javascript engine. The fact that the engine contains a new high-performance JIT compiler is simply gravy.

The only reason everyone uses Javascript to embed the files now is because of Microsoft's attempt to screw plug-ins.

Actually, I think it has something to do with Java being too big to be realistic in a browser, and Flash being too annoying for the average user. I know of more than one person who has ripped out the Flash plugin just so they won't have to see spinny, flashing, animated, and noisy intros or advertisements.

That's what the search engines can't index, and again it's something that's going to be a problem for any Ajax site that does the same.

Generally when you use AJAX, you put most of the content in the page itself. The only content that won't get indexed is the content that you probably don't want indexed in the first place. (e.g. Personal information)

Also, Flash-dependent sites like YouTube are definitely not starving for traffic.

Flash-dependent is not the same as being Flash-exclusive. If you build your entire site in Flash, you've got a nice-looking but ultimately less usable site. If you build your site in HTML and use Flash only where it matters, then you've got the best of both worlds. Youtube does the latter, with only the videos themselves in Flash. Everything else is easily indexable HTML. (Though arguably YouTube could get away with an all-Flash site simply because their primary advertising is word-of-mouth.)

1) Built in security against cross-domain scripting.

Untrue. For example, FoxyLady posted a vulnerability that nails any site that uses pure JSON. That's regardless of whether you use Flash or Javascript. As I mentioned before, connections from Flash go through the web browser, so stateful information can still be exploited through the same methods used in Javascript.

A YEAR old?

[DEFFENDER]

the current release of Dojo is 0.4.2

Why is this article reviewing a release of Dojo that is over a year old? And you might notice that Dojo gets the short end of the stick too.

Re:A YEAR old?

[ValuJet]

Everything seems old. the google web toolkit is 1.0, and they now are on 1.3 and it has matured greatly.

This seems like the equivlent of comparing Oracle 8.0 with SQL server 6.5 and informix 7.1 or whatever. It just isn't a relevant comparison anymore.

Adobe Spry Framework...

[__aaclcg7560]

I'm more intrested in finding out how the Adobe Spry framework compares. I just got a copy of Adobe Creative Suite 3 (academic pricing is so sweet!) where this framework is part of Dreamweaver. With CS3 being so new, doorstoppers ($50+ USD books) are not yet available to explain how to implement this framework.

jQuery, too!

[sbma44]

It takes the magical $() selectors of prototype, expands on them, and somehow delivers it all in 19k.

Re:jQuery, too!

[mythz]

I would also choose jquery over all of them and not just for Ajax. It basically provides the power of CSS for the DOM, which allows you to build stuff like an accordianin in only 10 lines of javascript!

Why dojo 0.3.1?

[Fireflymantis]

Dojo 0.4.2 has been out for a while now, and is vastly superior to any of the 0.3.x releases. Why did they pick such an old revision of the toolkit?

Re:Why dojo 0.3.1?

[MidKnight]

Plus, even 0.4.2 is quickly aging. Dojo 0.9.0 is readying for an alpha release sometime soon, and will be a great step forward for the library. For my money (or rather, the time it takes to learn & leverage a new technology), Dojo is the best thing going in terms of JS libraries, regardless of their AJAX-y leanings.

The learning curve is higher than the others, but the upside is also much, much greater. With a formal 1.0 release scheduled for later this year, and a ton of momentum (both within the community and corporate backing), Dojo is here to stay. And that's a good thing!

Re:Why dojo 0.3.1?

[Anonymous Coward]

I don't know when Dojo 0.4.2 came out but the article begins "In 2006" and later says "The new AJAX-based retirement-plan website was deployed to production in mid-December 2006", so they were doing this a while ago.

Use frameworks only when really need them

[roman_mir]

You have to understand what you are using, as was discussed earlier often frameworks are not needed, simple custom script should be sufficient for most cases. However people do tend to wrap even simplest of things into large complex frameworks, supposedely for introducing commonalities, providing familiar interfaces, whatever. AJAX is just so simple that in most cases any of those would be overkill.

As the article (I RTFAd) states there are many cons and pros using these various frameworks. The main cons were:
1. Not supporting the development model chosen for the project.
2. Not providing enough documentation with the framework.
3. Not providing enough widgets (many widgets still have to be custom made even with the frameworks.)
4. The framework is too large and impacts performance.
5. The resulting code is difficult to maintain.

The pros were:
1. Not having to write the AJAX code by hand.
2. Not having to write some widgets by hand.

I would say there for those cases when it is absolutely decided to go with a framework, do mix and matching. Use the simplest AJAX framework and mix and match it with widget libraries, but not entire libraries, extract what is absolutely necessary, in all cases custom code will have to be created by hand.

Another good option

[cabinetsoft]

is jQuery and it's plugins.

Re:Another good option

[Octopus]

Yeah, pretty lightweight, I've been using it off and on over the last year. Surprised it wasn't mentioned until now.

Old News?

[russcoon]

I'm Alex Russell, Project Lead for Dojo,

We're obviously flattered that our little project got covered in DDJ, couldn't they have reviewed newer versions of the tools they covered?

Re:Old News?

[Line_Fault]

I agree!! Most, if not all, of the tested frameworks were not current versions.

I'm currently doing development using Prototype. The new version works quite well.
I found the documentation here!

They must have been sitting on their results for the last 5 months or so!

Most of the projects mentioned are in a rapid state of development, so old news just won't cut it!!

Re:Old News?

[bahwi]

That's not how print magazines work, articles go in, and when they fill a gap or void or a theme is when they go to print, which can be years later, even for software/tech magazines. Again, only in print. Since they all had older versions reviewed you can kind of figure out when they did the review. Of course, it can also take place over the course of a few months.

Re:Old News?

[Paradise Pete]

couldn't they have reviewed newer versions of the tools they covered?

It does say that they did their comparisons in 2006.

Re:Old News?

[Matt Perry]

couldn't they have reviewed newer versions of the tools they covered?

Regarding your blog post, you almost sound like you're complaining that they are using stalwart versions of the software that they reviewed. I fail to see what the problem is with that. Would you rather that they have reviewed software that was buggy and barely functional? The rest of your blog posting gives me this impression leading me to believe that you think stalwart means old. It doesn't.

Re:Old News?

[russcoon]

Matt,

We (and all of the other toolkits they reviewed) fixed hundreds and hundreds of bugs in the 11 months since the release of Dojo 0.3.1. Like all of the other (well written) toolkits they reviewed, we take stability and quality seriously. Sure it takes them a while to review stuff, and I understand that they have constraints of publishing on a dead-tree schedule. It's even valuable for them to outline the decision process, but the world (and the toolkits) have moved on since.

Regards

Re:Old News?

[Matt Perry]

Yes, I understand what you are saying. I was pointing out that this fact was not clear in your blog post. Stalwart means robust, strong, well built. Your blog post characterized that you were upset that they reviewed such stalwart programs which left me thinking, "as opposed to what?" I was left with the impression that the newer versions that you listed were not as well built as the one they reviewed leaving me to ask myself, "why would I want to use a less stable newer version?" If your blog post were as clear as your response to me then I would not have misunderstood. That is all I meant.

JQuery

[minuszero]

...I find is quite nice :)

http://jquery.com/

They all come up short

[Wabbit Wabbit]

I've used them all, including moo (http://moofx.mad4milk.net/) and the toolman library (http://tool-man.org/examples/) and each one has a little something missing or fails to work well for some browser/OS combinations.

I've had to tweak or extend the code in each case, and in the end I settled on my own ajax class because none of the frameworks had a decent timeout/cancellation mechanism. For "desktop" apps I agree that YUI is the best of the lot, although I've had to roll my own extended modal message box classes because of some deficiencies in the YUI versions (some fixed in the latest rev, some not).

For "fun" GUI effects I've found prototype and its derivatives overrated. YUI works better IMHO.

However, no one beats toolman for list manipulation and editing-in-place, and for quick-and-dirty manipulation of divs as "windows" I rely on a modified version of code from that original venerable bullwark of DHTML coding, the O'Reilly JavaScript and DHTML Cookbook.

The moral of the story?

It's still the wild west out there (here?) No single library is perfect, all have some puzzling and maddening flaws, and if you're good at what you do, it's often better than not to roll your own. It's the only way you'll discover such oddities as the (just-fixed) non-standard behavior of the escape key in the Camino browser, and the lack of click input in Safari for radio button labels or Opera's handling of resized divs containing tables. Yes, these are browser problems, but a major selling point of the monolithic frameworks is that they've been tested, and that these quirks are supposed to be normalized and accounted for.

Lastly, I know the title of the post was AJAX frameworks, but ajax is actually only the smallest part of these systems. Most focus on the visual effects and "window" management features, with the ajax part kind of thrown in. To me, that's also part of the problem. These frameworks are trying to become desktop replacement libraries, only part of which involves ajax, and they're still struggling through growing pains and an identity crisis.

In a way it's all quite fun, like coding C++ was (commercially at least) back in '91, when we were still trying to figure a lot of it out. Hmmm...we're still trying to figure a lot of it out. What was my point again? ;-)

Re:They all come up short

[Anonymous Coward]

probably the best comment in discussion. thx.

Re:They all come up short

[Wabbit Wabbit]

And thanks for reading :) I hope it helps.

Jquery

[VGfort]

Dojo is nice if you want widgets (month selector/accordian/...) but the documentation is rather weak. Personally I like JQuery, good docs and everything in 1 rather small file.

Umm... hello? jQuery?

[YourMotherCalled]

"jQuery is a fast, concise, JavaScript Library that simplifies how you traverse HTML documents, handle events, perform animations, and add Ajax interactions to your web pages. jQuery is designed to change the way that you write JavaScript." - jQuery homepage

jQuery is great because it's really small and really easy to use. I know very little about js and have absolutely no interest in learning all the gotchas related to cross-browser js development so I leave it to jQuery to do that for me. jQuery allows me to use js in a powerful way, easily and quickly.

It's disappointing to not see jQuery in that list as if to say it's any less well made than the others.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Prototype Screencast

[muchawi]

I recently released a paid screencast on Prototype together with one of the core developers. The screencast and a short preview can be seen here:

http://peepcode.com/products/javascript-with-proto typejs

Redundant and silly

[Anonymous Coward]

Each framework was tested in two basic scenarios -- writing a 'hub' (titled collapsible link list frequently seen on sidebars of many Web sites) and a 'tab panel' (horizontal tabbed navigation bar).

Um, so tell me again why neither of these cannot be done in plain html output? You can't. Javascript is not necessary for either of these features. It serves only to complicate that which should be simple. There is nothing worse than javascript for javascript's sake.

Why just AJAX?

[PhotoGuy]

I've been looking into web frameworks lately, a lot of different ones (Java, Perl, Python, Ruby based ones). I finally decided upon going the Ruby-on-Rails, and probably the Ruby ActiveScaffold plugin.

One of the things that turns me off about frameworks in general, is the almost maniacal focusing upon AJAX. AJAX can do a lot of things nicely (Google Earth as the classic example), but for most web sites, all it does is add a slight bit more interactivity to forms. And many of the frameworks I looked at, handled forms nicely, but if JavaScript was turned off or unavaialble (like on some PDA's, Phones, and other environments), they were unusable.

I became very intruiged by Hobo as a Ruby on Rails plugin. Unfortunately, all the (scant) examples are so AJAX-centric, and do not degrade gracefully at all without JavaScript, I have no idea if it can be used effectively in a non AJAX environment. (I could spend a week exploring this, but I'm just going to move on with a framework I know will work.) A damn shame, because Hobo has a lot to offer.

I believe I am finally settling on ActiveScaffold, because it seems to degrade very nicely in the absence of JavaScript, and doesn't seem so heavily dependant upon it. Seems to have a good community around it, and isn't too heavyweight.

(BTW: Many of the Ruby plugins actually use prototype [and scriptalicious, I believe]; in fact, Prototype libraries come as part of Ruby on Rails.)

Re:Why just AJAX?

[Anonymous Coward]

The 'what if they have javascript turned off' argument is just silly. Quite obviously if they have javascript turned off only css selector style dynamicness can be done clientside.

Gracefully degrading might be nice, but it just isn't realistic for any site that used whatever they were using much at all. You'd be better off coding a parallel site that doesn't use anything clientside. You'll have a really hard time making a drag and drop UI degrade into anything usable without writing an alternative UI.

Re:Why just AJAX?

[francium de neobie]

Because there are many situations where you can't just run Ruby or J2EE at the web server. e.g. when you're developing a web admin UI for a router or any cheap embedded devices for that matter.

What about Microsoft?

[MobyDisk]

Why isn't Microsoft's AJAX.NET reviewed? I figured they would be a major player in this, right?

This is not a review

[jd142]

I think people are getting confused by the /. blurb. This article is not a review, it is a case study. This company is describing the process that it went through months ago in determining which software to use. That's why some of the versions are out of date. That's why they quickly discounted software packages that didn't work with their existing infrastructure. If you read the very first paragraph it tells you that they had very specific design constraints and that's why some packages weren't evaluated fully. You simply don't have that in a review.

A case study is supposed to give an overview of the decision making process and the implementation phases of the project. And that's exactly what this does. They goal was never to produce a document that gave an objective evaluation of the products, it was to show the decision making process they went through in their evaluation. No where does the Dr. Dobb's site call this a review.

Re:This is not a review

[Anonymous Coward]

Totally agree, they discount the 2 most innovative, GWT and DWR. This people are clueless

AJAX is the antithesis of security.

[Anonymous Coward]

We're getting to the point now with AJAX that there are just too many levels for a good degree of security to be maintained. Let's keep in mind all of the layers that need to be secured when developing and deploying a web applications:
Level 0) Hardware: we have to make sure our computer systems themselves are secure.
Level 1) Network: we have to make sure that the physical network between our computer systems are secure.
Level 2) Operating System: the OS running on the Level 0 hardware needs to be secure.
Level 3) Operating System Userland Libraries: the userland libraries interfacing with the Level 2 OS kernel need to be secured.
Level 3) Web Server: the HTTP daemon running on top of the Level 2 OS and making use of the Level 3 libraries needs to be secure.
Level 4) Database System: the database system being accessed by the web app needs to be secured.
Level 5) Web App Back-end: the back-end web application handling the AJAX requests, and possibly interacting with the Level 4 DB system, must be secure.
Level 6) Client->Server Network: the network between the client and the web server must be secured (eg. SSL, TLS).
Level 7) Web Browser: the web browser making the AJAX requests requires security, especially in the face of JavaScripts from different sites being run concurrently.
Level 8) Web App Front-end: the JavaScript code making up the front-end of the AJAX application, and running in the client's web browser, must also be secured.

So we've got at least NINE different layers that need to be secured. Now, these layers are provided by different groups, individuals, companies, you name it. The coordination between these groups is limited. Furthermore, what constitutes a security flaw from the perspective of one layer is a normal operation from the perspective of another layer.

All in all, when we start deploying AJAX applications (or web apps in general), we end up with a massively complex layering effect that seriously impacts the security of the entire stack. It becomes very difficult for even a team of administrators, developers and security analysts to properly ensure that such a deployment is sufficiently secure.

There's only one solution: reduce the layering. Yes, that means ditching AJAX, web browser and web servers. If an application must be executed remotely, it's best to use X11, RDP, VNC, SSH or similar technology. That runs the client on the same system as the server, thus eliminating some of the layers. At least then the problem becomes more manageable, if not yet ideal.

Re:AJAX is the antithesis of security.

[accessdeniednsp]

Piping it all over X11, RDP, VNC, or SSH merely shifts the pseudo-problems of your Levels 5 thru 8. How are you going to handle authorization, authentication and access control for these protocols? What about transport-layer vulnerabilities in each? All four of your suggested protocols have had a plethora of vulnerabilities, and they still have a handful even now (we just haven't found them yet).

You have only repeated and restated the existing problem but using different words. The problem hasn't gone away, in this scenario; it has just been shifted and re-dressed.

Re:AJAX is the antithesis of security.

[drig]

Your model is correct, but it really doesn't have to be that complicated. AJAX goes over HTTP. So, you use the same tools for securing AJAX as you do with HTTP. What kind of markup it is shouldn't matter.

In my Java/Tomcat app, I use a ServletFilter to make sure all requestrs are either authenticated or they are marked as public. I have very few public pages (login.jsp and the images it depends on, the license agreement, etc.). An AJAX request is still considered a request. If you're not authenticated, we reply with a 401 status code, which my JavaScript picks up and sets window.location=login.jsp. We apply a standard ACL to the requested data, just like we do with any normal web page. *My* AJAX is as secure as the HTML pages, and I didn't have to worry about a very complex model.

It's really not that tough to deal with AJAX securely, which makes it even stranger that the reviewer of this article didn't even mention it (disclaimer...I only scanned the article...it was big).

DWR

[kevin_conaway]

The name of the software is Direct Web Remoting

How can we take this seriously if they don't know the name of the software they are evaluating?

Re:DWR

[coug_]

I've actually had the opportunity to use DWR recently, and if you're developing a Java servlet-based application, it's mind-numbingly easy to set up and use. Basically, you tell it which Java objects you want to call methods on, which ones you want to be able to marshal back and forth, and it basically gives you a Javascript interface to all of your code, and it even generates a web page where you can pass in values to the functions and it will do its best at displaying the results of the method call. I thought the fact that they dismissed it because "it didn't fit into our architecture" was pretty lame.

Re:DWR

[zootm]

DWR is great, but the article doesn't actually review it; if you read, they reject it right at the beginning because it doesn't fit into their architecture (read: they're not using Java). They probably shouldn't have mentioned it at all.

DWR = Direct Web REMOTING

[spanielrage]

WTF - this article might as well have been written last summer. DWR version 2.0 is now out and has been in beta for a while.

The 'R' in DWR does not stand for for Reporting, but rather "Remoting". Both TFA and the ./ post are incorrect.

Not really out-of-date...

[dustymugs]

If you check the first page of the article, you'll notice it says that the project started in 2006 (who knows as to exactly when) and went production mid-December of the same year. So, there wouldn't be anything new (released 2007) in the first place.

Lets get hypothetical for a moment, and look at when the frameworks' versions noted in the article were released (these are estimates based upon announcements, datetime stamps, etc)...

Dojo 0.3.1 released ~06/12/2006
Prototype/Scriptaculous 1.4 - probably Prototype version, I'd say Scriptaculous is either 1.5 or 1.6 release ~3/2006 - 4/2006
DWR 1.0 released ~8/29/2005
YUI 0.11.1 released ~07/17/2006
GWT 1.0 released ~05/25/2006

If we take the most recent release date (07/17/2006) as the start date of their project and they took about a month (~8/17/2006) to evaluate the frameworks, the versions available by 8/17/2006 are...

Dojo 0.3.1 released ~06/12/2006
Scriptaculous 1.6.2 release ~8/15/2006
DWR 1.1.3 released ~7/11/2006
YUI 0.11.2 released ~07/24/2006
GWT 1.1 RC1 released ~08/9/2006

Comparing what would have been available based upon the "guessed" start date of the project, there really isn't anything new or overtly glaring. Except maybe for DWR.

So people, when reading this article don't think of it as a review of what is available now but rather a case study/retrospective/white paper of what they did.

Re:Not really out-of-date...

[AndrewMTurner]

(from authors)

You hit the nail on the head. The article was about the process we used to select the best tool for our job, in the time frame that we were in (2006). We wanted to help other developers with the process, not try to do a complete review of Ajax libraries.

Article Title -- AJAX: Selecting the Framework that Fits
Last sentence of Intro paragraph -- ...we hope you benefit from the process we used to evaluate AJAX libraries and develop our first AJAX-enabled application.

Authors,
Andrew & Chao

Ajax security

[mrkitty]

http://www.cgisecurity.com/ajax/

Re:Ajax security

[kilkenny]

As aforementioned security is a general Ajax issue. A good read about GWT and security can be found here:
http://groups.google.com/group/Google-Web-Toolkit/ web/security-for-gwt-applications

---
check out => http://traceurl.com/rdS?r=1&l=2

Re:No jquery?

[xutopia]

For reference here is how to do it with Prototype: $$('a').each(function(a){ a.className = 'test'; a.show() }); Indeed Jquery does look more concise.

Anything but Yahoo UI!

[Sparr0]

I have had to butt heads with YUI on more than one occasion while working on Gallery2 (a php photo gallery system). It is evil in the worst ways. Often I will give up after chasing functionality through a dozen function calls and still be nowhere near the code that I need to find to decipher the undesirable behavior in question. I admit, opening a popup element with open_popup(x,y,source) might be a bit too much to ask, but when I get literally *TWELVE* levels deep in the function call list and still haven't found a single bit of code that actually DOES anything to the page, there is something wrong.

Goodie.

[Anonymous Coward]

This will create more sites that are either nearly blank or completely nonfunctioning in my browser because I have javascript off by default. Unless the site looks like it'd *really* be worth it (it usually isn't), I quickly navigate away.

Please stop making the web something it wasn't meant to be with a bunch of hacks upon hacks. If it can't be done with XHTML+CSS (plus whatever server-side stuff you want, of course), forget it.

Re:Goodie.

[EoN604]

Ahahahahahaha. How's your cave going, caveman? Is it cavey? Seriously, anyone who has javascript turned off in this day and age is a moron.

Anyone used Adobe's Spry framework?

[Timbotronic]

Spry is still in pre-release but up to version 1.5 and looks to be getting pretty good too. It's also fully open source under a BSD license.

We're currently looking at a few AJAX options at work too so I'd appreciate any feedback from anyone who's evaluated it particularly against jQuery and the others in TFA.

Shameless Plug : Library

[cyclomedia]

It's work in progress* at the moment but i have a basic AJAX Library up at http://cyclomedia.co.uk/projects/ajax/

all it does is encapsulate the request/response with a couple of handy additions:

1. ability to pass any custom object through to the callback function

2. built-in response codes, so a response that starts "200\n" is a "Good" response, you can also return error codes

2.1. this means a http error wont botch up your nicely formatted site and

2.2. it's immune to the cross-site <script src=...> attack, even if you're sending a raw JSON object because the response code botches up the compiler

There's also a bitchin 2d-array library too with like a zillion functions and a new secret project too that'll revolutionise the interweb, probably.

Each of which do NOT use prototyping, instead taking the c-style approach of passing your object in as the first argument to the function, which means it's very easy to reduce the script size by just chopping out the functions you dont use.

* which means rather embarrasingly that the manual is a little sparse out of date, but there are working examples up there you can rip the source from

RichFaces and Ajax4JSF

[kiwi_damo]

If they were serious about sticking to the Java way of doing it and using WAS why didn't they look at RichFaces and AJAX4JSF? These companion project are very mature and offer a fantastic way of getting AJAX into your Java web apps.

They work even better if you combine them with JBoss Seam.

This isn't much of a "review"

[rollthelosindice]

If you actually read the article, its a pretty sad excuse for a review. Of the 5 frameworks, 2 of them are dismissed immediately because they didn't meet the exact coding styles of their development team for this specific project.

The other 3 aren't really reviewed either, except to describe how well or poorly they matched up with how the author's development team already developed code for their projects. This article is more of a story about one development team's choices during their process of developing a new site for their company than it is a review.

yeah, you're the only one

[KMonk]

Better be careful about bloating your page by 10s to 100s of KB. Oh God, why haven't you provided unto us some sort of fast, readily available internet access !?!?!?! Perhaps through the same system that delivers our cable television content? What an idea, venture capital here I come! Frameworks are good. Don't use the crappy ones and you'll be fine. Dojo, for example, you can feed and parse JSON from and just pick and choose the bits you like. I use it with Struts2.

AJAX frameworks are NOT pointless

[francium de neobie]

There are many little funny things that just happens when you're coding a web application in JavaScript without a framework/library/toolkit helping you. Unless you're really an AJAX/JavaScript wizard, coding an AJAX-enabled web application on your own and mixing online code receipts is a very dangerous thing to do.

Browser inconsistencies
This is the most obvious one, but only the entry to the rabbit hole. If you are not familiar with the example (maybe not exactly the same, but any AJAX web developer worth his salt should have seen one like that) I give below, then please, PLEASE, do yourself, your fellow developers and your users a favor, resist the urge to hack things together for once, use a mature AJAX framework.

An important part of AJAX is that you need to update what is displayed on the web browser in the client side (by JavaScript), without refreshing the page. This implies that you're very likely to have to create and destroy DOM nodes on the fly. Now, how do you create a radio button in JavaScript?

How about...

var node = document.createElement("input");
node.type = "radio"
node.name = ...
node.value = ...

That's what you would do if you follow the DOM standard. But sorry, this does not work. Try to create a radio button with the above code segment in Internet Explorer 6, you'll get a broken radio button - you can't select it. The correct way to create a radio button by DOM manipulation is described in this MSDN article:

newRadioButton = document.createElement("<INPUT TYPE='RADIO' NAME='RADIOTEST' VALUE='Second Choice'>")

Memory leaks
The last one was easy. Do you know you can make a web application that leaks memory like a sieve in Internet Explorer 6 by making a simple circular reference like the following one?

var node = document.createElement("div");
node.someAttr = node;

If you're a good programmer, I might have sounded an alarm in your head right now - any circular references involving DOM nodes in IE6 results in memory leaks that persist after URL changes or page refreshes - unless you use an AJAX toolkit that takes care of the issue for you. Have you assigned a DOM as an attribute value under another DOM node in the past? Yes? Then you'd better check your web application for memory leaks with Drip, now.

What's more, it's not just assigning DOM nodes as attributes that would result in memory leaks, closures in JavaScript can also form circular references and cause memory leaks. What makes closures particularly dangerous is that circular references with closures are not easy to spot. For example, the following code segment leaks:

var node = document.createElement("div");
var clickHandler = function(){};
node.onclick = clickHandler;

Looks innocent enough, but you've already formed a leaky circular reference here. node->clickHandler->node.

For more information about memory leaks under IE6, read these:
Mihai Bazon's blog entry
MSDN's lengthy and confusing description of the problem


The XMLHttpRequest object is not as simple as you think
Much of the magic of AJAX comes from the XMLHttpRequest object (or its ActiveX equivalent, or an iframe, etc.), right? Sure. If you're only doing something simple via AJAX (like, updating the server time), then you can just copy an XMLHttpRequest code snippet from sites like this and hack away, right?

You really DO understand neo-mainframe development

[oldwarrior]

>>in Soviet Russia, frameworks call you.

Flash Components much the same

[Anonymous Coward]

I work in some Flash development and I remember the day I wanted a scrollbar for some text. I just dragged the handy-dandy scrollbar out of Flash's Components library and it worked like a charm! I exported it and, to my surprise, the file weight had jumped significantly. "It's just a scrollbar," I thought. "How can there be Ks worth of code to do that?" Turns out when you drop any of Flash's prefactured Components onto your stage, it includes some base library that's HUGE. That base library isn't just for scrollbars, it's for everything in the Components library. The developer in me couldn't live with that approach, so I rolled my own scrollbar.

Why not do 6

[darrenkopp]

Why would they leave out asp.net ajax?

Re:Why not do 6

[darrenkopp]

ah nevermind. i just got to the "pure javascript" part. Although all the js files for asp.net ajax could be used, it would probably be a LITTLE more work (not a whole ton) to make it work with their system. ASP.NET ajax is streamlined for use with .net.

Re:No jquery?

[kthejoker]

Prototype has an addClassName function, so you can also just do

$$('a').addClassName('test');
$$('a').show();

I don't think addClassName returns the element list, but I don't have an environment to test it in handy.

suid != userAge

[Anonymous Coward]

Post-it right on your monitor.

Check out JSDC

[Anonymous Coward]

It sure ain't bloated and is somewhere between a library and a framework..

http://sourceforge.net/projects/jsdc/

Docs
http://jsdc.sourceforge.net/docs_reference.php

Dont you dare pass over JSDC 1.3!

[zig007]

Especially since it is my pet project.

JSDC, Javascript Data Components(http://jsdc.sourceforge.net/docs_refere nce.php) has some really interesting stuff.

I'd say it's somewhere in between a library and a framework..It doesn't force you into anything.

It features:
* Client-side datasets with nested transactions(or maybe it is more of an undo history), master-detail.
* Input verification
* Treeviews, Table views and other stuff
* A quite interesting non-blocking animation class.
* And more.

Check it out!

Re:Dont you dare pass over JSDC 1.3!

[zig007]

Ok, so that link's got a space in it. This one works.
http://jsdc.sourceforge.net/docs_reference.php

I gather some of you haXx0rz# out there already figured that out, though.

jQuery

[reed]

I've found jQuery to be very easy to use, especially for simple stuff. I was up and running with jQuery in about 30 minutes, though I had to implement some UI logic myself-- with Dojo that was already built, but it didn't do what I wanted, so I spent a while struggling with it before giving up.

jquery -- http://www.jquery.com/

It's interesting, it basically just does two main things well: 1. provides a nifty function for getting a handle on a DOM element using either XPATH or CSS selector syntax, fairly painless once you figure out the selector/path syntax, and 2. has some functions for sending JSON or XML requests to the server and getting the response sent to a callback function (that's the AJAX part).

Unbloated Javascript library

[fforw]

Some posts here have mentioned the large size of most javascript libraries.. I personally had the same problems and wrote myself a minimal javascript library with only:

• HttpRequest related functions
• IE compatibility layer for style classes and events
• a DOM builder
• firebug simulation
• a few helper functions

The whole thing is about 8kb for the js-compressed version (about 4kb if you also serve it gzipped) and is available under a BSD-like license from my blog site