Wednesday, April 29th, 2009

Ajax Framework Analysis Results

Category: Ajax

Matt Raible has posted on the analysis the he has done for a client on choosing an Ajax framework. This is the age old question “which Ajax framework should I use?” It is agonizing. It is hard. It isn’t pretty. We created a dartboard:

Matts take compares Dojo, Ext JS, GWT, and YUI using various criteria that you can see here (including his ratings):

What you quickly see is that it is fairly hard to choose between the popular frameworks (and this is a specific subset that was narrowed down, hence no jQuery, Prototype, Mootools, etc).

I am interested in seeing what other criteria people use to choose.

Posted by Dion Almaer at 6:44 am

2.5 rating from 117 votes


Comments feed TrackBack URI

And again … Ajax/JavaScript Framework != RIA Frameworks. He compared RIA Frameworks, but sadly RIA is not a fancy buzzword like Ajax, so he choose the right name for his comparison to get some visitors ;)

If you can not decide for a framework by your personal code style and your experience with JavaScript, use the dartboard (or invest time and play with the frameworks)!

Comment by digitarald — April 29, 2009

Job Trends: dojo, yui, gwt, ext js,+yui,+gwt,+ext+js&l=60188

Comment by Les — April 29, 2009

All frameworks mentioned, as well as the ones that haven’t, have the ability to do everything described in the chart. After this it comes down to as digitarld mentioned, “your personal code style and your experience with JavaScript”.

The key thing I look for is how long the framework takes to load, how fast it renders components, consistency in the API, level of details the API docs get down to — which i prefer than constantly having to sift through different api docs, books or the source code, just to see how i use a damn widget or instantiate a class with the proper params — how dynamic the site is (i.e. is it a single page app, or will it be page by page with a few dynamic components?) and whether or not the server will be sending json, xml or html to the client for XHRs

Comment by constantology — April 29, 2009

Job Trends: dojo, yui, gwt, ext js, jquery

And I agree with digitarald, the guy’s post just doesn’t seem to have much real value. I’m happy that they chose a framework they can work with but I find it interesting that the tail-end of the post is complaining about the chosen framework.

Comment by travisalmand — April 29, 2009

Another one:

I guess we should dump everything for prototype.

Comment by travisalmand — April 29, 2009

The dart board is a great illustration.

Comment by Diodeus — April 29, 2009


Keep in mind that jQuery and Prototype are not widget libraries. jQuery UI is a week offering. It doesn’t even include the Tree or Grid widget (the last time I checked).

Comment by Les — April 29, 2009

Job trends are meaningless. A good developer can switch ajax frameworks depending on project needs. What matters is which framework is best for a particular project, and that decision is very project-specific.

Comment by Joeri — April 29, 2009

@travisalmand, following your reasoning we should stick with plain HTML:)

Comment by lukaszqr — April 29, 2009

I find the ExtJS analysis to be off. It’s incredibly flexible/extensible, easily matches up to Java teams (ExtGWT), the documentation/wiki is great, it’s very easy to whip up an application, and the new Ext 3.0 has lots of charting options (

Comment by ajaxery — April 29, 2009


I concur. I use ext every day at work writing a massive web application. After a year of hardcore ext development, I can’t imagine a better framework to work with on a large scale RIA.

Comment by thnkfstr — April 29, 2009

@ajaxery; Thx! Thats about what i had in mind too.
The ExtJS documentation is way better then eg. the Dojo one. (IMHO) And the productivity (web & app) is way higher then working with Dojo or GWT. At least for me. ( i have no exp. with YUI )

Comment by Novalis — April 29, 2009

adding on to my previous comment:

The biggest downside to ext IMO is the learning curve. It’s a bit steep.

Comment by thnkfstr — April 29, 2009

@thnkfstr, I think ExtJS is kinda easy to use and almost logical as well … which problem with learning curve? I extended native components the second day without big problems while the first time I’ve seen Dojo I though: shut! I want more control over their components!
Something in Ext you’ll think in any case, then you’ll discover how simple is to implement your own stuff. Finally, the library with “all we need” already there does not exist (otherwise the Web would be a truly boring place!) so “we have to learn JavaScript in any case”

Comment by WebReflection — April 29, 2009

@lukaszqr – About the job trends, that was my subtle attempt at making that point. As Joeri stated, switching should be not be a huge burden especially since a large number of them do roughly the same things in slightly different ways.

@les – That’s true, jQuery UI still seems to have more work ahead of them. But as with most decent framework communities there are plugins that are in development to serve those needs.

Comment by travisalmand — April 29, 2009


My opinion on ext’s learning curve is based on observing new hires at my workplace. A lot of them seem to be coming from jQuery backgrounds and most have had some difficulty picking up ext. We are working on with some heavily customized grids and layouts though, so that may be part of the problem.

I’ve not seen a new hire coming from a background of Dojo or any other widget library. I assume the learning curve wouldn’t be as steep for them.

Comment by thnkfstr — April 29, 2009

Why use a framework at all? There is no code like your own code, at least if you know what your doing. Speaking from an employer’s perspective, I would rather hire someone based on their solid understanding of JavaScript rather than the pretty little layer of abstraction of their favorite favorite library.

Comment by RyanMorr — April 29, 2009

@ryanmorr – I agree to a point. But on a large enough project you eventually end up creating your own framework and you have only duplicated the code already created by someone else who will let you use it for free.

If the project is small than sure, rolling your own code will probably be more efficient in the long run. I use jquery quite a bit these days, but I also use raw javascript when the entire framework is not needed.

As for hiring a javascript guy over a jquery guy, I agree, javascript guy all the way.

Comment by travisalmand — April 29, 2009

At first my criteria was whichever I came across first. Then after using or trying to use a range of them, like ExtJS, jQuery, MooTools, Prototype JS, YUI, I have ended up reusing the good features of Protoype plus other cool ideas and features I found when using these tools, created my own widget library and dependency management with server-side code, and am quite happy with the outcome.

These simple benchmarks people show every once in a while can be deceiving and can change over time with new developments in browsers. So I am much happier with Prorotype once seeing it perform quite of badly on Windows in one of those comparisons (taskspeed) and then seeing it perform quite a lot better on Linux with newer versions of browsers (webkit, chrome)…

Also, while people might like hacking away their own OO mechanisms for JavaScript, I love the way Prototype handles it and am willing to waste a few milliseconds because of it. ;-)

Seriously. Calling things like MyCoolClass.superclass.constructor.apply(this, arguments);

Is just too redundant if one has an easy fix for that. Prototype’s $super might not be Miss Beauty but it works as far as I have tried it.

Also, I am sorry to say, but after trying YUI 3 and seeing some of the feedback YUI 3 is getting from users surprised by its approach, I think it will not work that great for everyone.

Also, after seeing the code of Bespin, it looks quite ugly still. I have a feedback on Bespin. Accented characters are not working on it on Linux at least. Also today I tried to run the frontend on this Linux (Ubuntu 9.04) desktop and after pressing the Enter key it was doubling the effect on the editor. So it would jump one, two lines after pressing it. And the backend needs up-to-date instructions for how to get it running out-of-the-box.

Finally on Bespin as well, I fear it might be a little overkill as it currently is being developed. Instead of a very cool text editing area based on the canvas, with all the rest probably including scrollbars being left to what the browsers have to offer by default, productive hours are being spent on hacking a much bigger system and the complexity is scary by itself. I would rather have Bespin use canvas just for the text editing area and work on making it work even on Linux ;-) than to have such mountains of programming tasks in a language that often people hate either because of its features or because of all the incompatibility issues surrounding it.

Comment by jpedrosa — April 29, 2009


seriously? you want to roll your own custom paging grid with drag and drop columns, group by view, editable cells, etc?

good luck with that. I’ll stick with ext.

Comment by thnkfstr — April 29, 2009


Row your own gird, with icefaces I can do that in half a day.

Comment by michelle21 — April 29, 2009

Strange, I’ve always thought YUI had top-notch documentation (one of it’s primary strengths, actually)..

Comment by simplehack — April 29, 2009


I wouldn’t call it a duplication of code, when you can understand exactly what every line of every component is doing and- changes come very easy.

If you understand the code behind the framework (including any plugins) and are perfectly comfortable making changes to the base library or plugins themselves than be my guest, use a library, at least you know what your getting into. My problem is with the developer who thinks they know JavaScript because they know jQuery. Once something breaks, they are all over the help forums for a problem they don’t understand. The dependency kills them. In a certain respect, JavaScript libraries have spawned too many lazy developers not willing to sit down and learn the language for themselves.


You don’t know how to do that? In the grand scheme of things I decided it was better to learn how to fish than have someone do it for me, and I gotta say catching fish has never been easier or more satisfying.

Comment by RyanMorr — April 29, 2009


One of my first web projects involved writing a scrolling table with fixed column headers from scratch. Nothing special. After messing around for a couple hours with overlapping tables to get the appropriate fixed header effect, I was satisfied. It was a rewarding experience reinventing the wheel in that case.

So sure, I agree with your basic point that doing things yourself is satisfying and rewarding.

I can’t imagine your philosophy working too well in large scale RIA (think 30-40 pages, ~100 supporting dialogs) development though. It may sound ‘ideal’ to hire a JS guru that can whip out any custom component you can dream up, but that’s not nearly as practical as hiring a couple ‘less talented’, but adequate JS developers who can appropriately apply a library to meet a customer’s requirements in a fraction of the time it takes a guru to whip up something from scratch.

Comment by thnkfstr — April 29, 2009

On a large project with fixed deadlines, the only way to get it down quickly is to use a framework that supplies widgets to handle most of the common coding tasks, ie. autocomplete components , menu’s etc.

Sure we use yui, jquery etc. The difference is we build a wrapper around them using the frameworks api and let the framework handle all the ajax interaction we would normally have to use xmlhttprequests or iframes to do.

Comment by michelle21 — April 29, 2009

@travisalmand – “But on a large enough project you eventually end up creating your own framework and you have only duplicated the code already created by someone else who will let you use it for free.”

On a really large enough project, you’ll develop your own framework on TOP of an existing framework. But maybe thats just me :)

Comment by genericallyloud — April 29, 2009

Glad to see so many talking about Ext. We’ve been using it for a couple of years now, and like so many others I’ve heard raving, we’re on the bandwagon too. Ext is probably the richest framework out there, the documentation is excellent, and most importantly, due to developers’ expertise in JavaScript and API design, Ext is evolving smoothly and strongly, and rapidly, without upgrade problems.

The best frameworks teach you how to write good code in that language, while at the same time giving you the convenience you need in creating high quality web pages quickly. Ext qualifies big time. I think the reason Ext users are so happy is because they know they are hitched to a high quality framework that moves as fast as we do in meeting today’s demands for the best user experience on the web.

Comment by sonofman — April 29, 2009

I’m afraid my experience isn’t as diverse as most of these other comments, so take what I say with a grain of salt.

I started using prototype about 8 months ago, it was the first framework I had dealt with, since prior to that I had avoided frameworks thinking it added too much unused bulk to the page. I still think that, Prototype made my life so much easier in so many ways that I include it anytime I have to do more then just basic style changes.

I kept seeing really good libraries being made for MooTools, so I decided when i rebuilt my website last month to build it using Moo. At first it was awesome and made a lot of stuff much easier then prototype. Then I tried to do some ajax form submissions, and it completely fell apart. MooTools just does not have the same level of power and flexibility when it comes to forms that prototype has to offer. Or, atleast if it does I couldn’t find documentation on how to do it. I switched back to prototype and rewrote everything that had used Moo functions.

jQuery gets an insane amount of attention, but the bulk of it and the performance tests I’ve seen with it strongly discourage me from wanting to use it. The examples I’ve seen written with jQuery feel like it is trying to treat JS like something it isnt, using it as a page building system rather then as an extension to JS and the DOM.

When Dojo first started showing up I watched a presentation here on Ajaxian given by one of the Dojo leads. About ten or 15 minutes in he said something along the lines of “Dojo was built so that you don’t have to know HTML to create websites.” I stopped the presentation right there and wrote Dojo off forever. I strongly dislike frameworks that are meant for people who hate making webpages, it’s why I refuse to touch CakePHP.

I know it’s very opinionated of me to say this and I’ll probably take flack for it, but if you don’t know/like HTML, you shouldn’t be developing for the web.

Comment by Chiper — April 30, 2009

I see a lot of *very* debatable things WRT Ext JS here…

* Project health/adoption – Why is Ext JS lower than the others? You might be able to convince me that’s fair based on adoption, but health-wise? I don’t buy it. I know, I’m going to hear the “because it’s not open-source” argument, but that’s not correct: purchase a license and you’re covered. If this really means “free versus not free”, then fine, but otherwise I don’t buy it.

* Richness of widget/component library – Can you seriously compare Ext JS to YUI and come out with the opinion that they are on par? I think you’d have to be utterly blind. I don’t mean that as a negative comment on YUI, simply that the analysis is flawed, IMO, if you see Ext JS and YUI’s widget richness as being equal. I think they clearly are not, Ext JS is better, clearly I think.

* Flexibility/extensibility – This is pure hogwash. Ext JS should it no way, shape or form be lower than *ANY* of the other libraries. It is extensible in the extreme, and in a far cleaner and logical way than most other libraries. I’m not arguing that there aren’t equals out there, but I don’t think you’ll find any superior, which is not what this analysis concludes.

* Productivity – To say that Ext JS is less productivity than virtually any other framework says to me that you haven’t spent more than 10 minutes with it. I have junior developers at work who are using Ext JS for the first time and are pulling off things that they otherwise either wouldn’t be able to or would take MONTHS of time to do. Ext JS is again, if not the best in terms of productivity, certainly right near the top.

* Ease of deployment – Err, how exactly is ANY JavaScript framework less easy to deploy than a framework that needs a compile step ala GWT?

* Quality of documentation – I’m not here to bash Dojo, but I don’t think their docs are on par with Ext JS’s. Now, I want to be clear: the difference is nowhere near as big as it used to be, kudos to the Dojo team for improving the situation there leaps and bounds from what it once was. But, even still, I don’t think objectively you can reach that conclusion even still.

* Charting capabilities – Not a critique of the analysis per se, but Ext JS v3 *does* include charting capabilities, and it is due out in a little over a month. It’s fair that this wasn’t considered in the analysis, but I thought it was also fair to point out that it’s right around the corner, for anyone trying to make their own value judgment today.

Overall, I really get the sense that someone had a preconceived notion about GWT being the one they wanted to see at the top of the list and they tailored the analysis to give that outcome.

What really scratch my head though is seeing YUI ranked higher than Ext JS. This to me makes the whole analysis very questionable because as good as YUI is, and I do think it is quite good, Ext JS is a fair bit better IMO. Seeing Dojo==Ext JS is also a little questionable to me, but that’s at least a fair, debatable conclusion. I don’t see how YUI>Ext JS is though, and come to think of it, I wouldn’t even agree that YUI>Dojo (the only thing I’d consider is YUI>GWT, I might agree with that, but that’s not the conclusion of the analysis).

Comment by fzammetti — April 30, 2009

Ugh… I’ve got to remember to not click submit before proofreading my gibberish at 2 in the morning… way more grammatical errors in that last post than I’d like to admit. Hey guys, how about an edit option?!?

Comment by fzammetti — April 30, 2009

@RyanMorr: I built my own rich grid component, and eventually decided fishing myself just isn’t worth it. If your business is a restaurant, it usually doesn’t pay off to catch the fish yourself. If your business is building actual features, rolling your own framework is usually not cost-effective.

We switched from a home-rolled framework to ExtJS because it saves development time. While ExtJS does a few things a little differently than I would like, overall it is much quicker to develop in because most of the things we need are already there and are well-designed. The original front-end for our grid component took 3 months to develop, while porting it to ExtJS took 3 weeks, and one week of that was time spent learning the ins and outs of the ExtJS framework and grid component.

@fzametti: don’t be mad because java guys prefer GWT. It’s a valid point to prefer GWT, in their case. Development and deployment is easier for them because they can integrate with their java build tools.

Comment by Joeri — April 30, 2009

@RyanMorr – hehe. After you’ve had a bit more experience with high end javascript applications you will learn better.

@Chiper – as you stated, your experience isn’t very diverse, so it’s understandable that you make incorrect judgements.

ExtJS widgets/User interface is fantastic. But as a framework/toolkit, it is immediately ruled out entirely, because its licensing is a joke. Unacceptable.

jQuery is good for beginners and light/small/basic web pages. It’s good for programmers who aren’t very good with web development.

Mootools – we all know about mootools ;) not really in the same league. The only reason anyone knows the name is the young children geeks spamming the toolkit in every forum. Again, good for people who aren’t very good at high end web develompent.

Dojo is the best most scalable toolkit available.

Comment by Gavin — April 30, 2009

@Gavin: the Ext licensing model (dual license GPL / proprietary) is used by a gazillion projects. Qt and mysql are two well known examples of that same model. Do you consider Qt and mysql “ruled out” also?

Comment by Joeri — April 30, 2009

@joeri – Based on Gavin’s last post I wouldn’t credit much of anything he has to say.

First he insults two people for their valid opinions. That’s just a sad attitude to have.

Don’t like the licensing of Ext? Then don’t use it, but don’t downplay it’s usefulness for some people.

jQuery isn’t as advanced and complicated as you like? Then don’t use it, but insulting people who do is a very poor attitude.

Mootools? Same as my jQuery thought above.

Then we get to the truth, gavin is just a fanboy for dojo. Which is funny because he just put himself in the same league as the mootools fanboys he just complained about.

Everyone should just try several frameworks to find the one that fits their needs the best for their project, be it a low-end web page project for the local candle maker or Gavin’s high-end projects.

Comment by travisalmand — April 30, 2009

1) Like the very first comment said: “Ajax/JavaScript Framework != RIA Frameworks” Please don’t compare jquery/prototype with extJS/Dojo.

2) Let’s not argue about what is the best Framwork. This surly is a matter of tase. Matt Raible is just trying to help people in finding the right Framework. I think his evaluation of ExtJS is way off. In mine ExtJS would do much better then Dojo and YUI. So let’s hope people will make up there own minds and not use the pregiven evaluation of his.

Comment by Novalis — April 30, 2009

Joeri, please do not compare mysql to ExtJS. MySQL is a proper company. MySQL is used by Google for free since its not sold as a product, but its a service. The same applies to Ext however they try to extract the most $ they came making up their own baseless rules and interpretations of the GPL license. Throw in all the nonsense of FLOSS, and you have a whole mess.

Did you read this post :

Moreover, Ext releases new major versions even when minor additions have been added. The have major version upgrades more frequent than any other library available. They do this to keep milking users of upgrade costs. Ext 1.1 -> Ext 2.1 –> Ext 3. I’m sure we’ll have an Ext 4 branch in a couple of months. So users, please be aware of the hidden costs involved before considering Ext. The cost is not *just* of a single license. Ext fanboys can flame me now, but will understand what’s going after some time. There is a very nasty patten and ugly history.

Comment by fargueta — April 30, 2009

Fargueta, please don’t take an anonymous blogger’s word about what the GPL means as a guide, especially one with an axe to grind. If you want clarifications on the GPL’s meaning, contact the FSF. From what I understand of the GPL v3, that blog post is mistaken.

As for the upgrade cycle … that’s very typical for pretty much every commercial developer tool. If you’re not taking into account upgrade cost in your evaluation of possible toolkits, you’re doing yourself a disservice.

Comment by Joeri — April 30, 2009


When Dojo first started showing up I watched a presentation here on Ajaxian given by one of the Dojo leads. About ten or 15 minutes in he said something along the lines of “Dojo was built so that you don’t have to know HTML to create websites.” I stopped the presentation right there and wrote Dojo off forever.

I would like to know what presentation you are talking about; at no point should anyone at Dojo be talking about the idea that we build the HTML for you. We don’t believe in that approach any more than you do.

What we *do* believe in is making sure our tools provide you, the developer, with the most power and flexibility possible along with making sure what we give you satisfies all our requirements (including i18n and a11y).

For the record also (since it drives me nuts sometimes), what the comparison is doing here is for Dijit. Dijit is built on top of the Dojo Core but it is NOT Dojo. (Had to get that off my chest).

WRT to whoever posted that link to ExtJS’s chart stuff–is there somewhere else you can see the capabilities? The link you posted contains almost all the inherited props and has almost nothing about what you can actually do with those charts.

Finally, WRT to the many links to Indeed, I’ll give you another one:

All the previous links were in absolute numbers but it’s instructive to watch the growth of the trends as well.

Comment by ttrenka — April 30, 2009

I should clarify on the “We don’t believe” comment…

Dijit is designed so that you can create a template, in HTML and CSS, that is reusable. This means that you can mark a node (usually a DIV) as a placeholder for a Dijit, and Dijit will either fill in or replace that node with the contents of the template.

In some respects, this may have been what whoever it was doing the presentation was referring to.

However, that doesn’t mean we try to insulate you from having to know or develop your own HTML; Dijit is most certainly not like something like GWT.

The Dojo Core is also (as of 1.3) providing methods like create that gives you the programmatic ability to inject HTML into a document; still, this is not the same as taking care of everything for you.

Hope that helps.

Comment by ttrenka — April 30, 2009

@Joeri : you are as anonymous to us as the blog poster, so your “understanding” of GPL v3 really doesn’t matter. For all we know, you could be part of the Ext team given the nature of your posts.

If there was nothing to hide why delete post rather than address the issue with facts. Having 2 major releases in a year, with critical fixes not being supported in the previous versions is certainly not typical of every commercial development tool.

Comment by andrewwell — April 30, 2009


The charting examples for Ext are not live, but you can find them in the SDK.

Comment by ajaxery — April 30, 2009

@ttrenka: I have to apologize, I went back and read a transcript of a chat I had after watching that presentation and I completely miss-remembered the quote. The actual quote was

We don’t want them to have to learn Javascript necessarily.  Using Dojo widgets should be like writing HTML tags.

This, obviously, isn’t the same thing, quite the opposite in-fact. I still find the idea offensive, but I did misquote and I am sorry.

Comment by Chiper — April 30, 2009

Yes, agreed 100% about the GPL, I was merely pointing out that one guy says A, another says B, and the only way to know for sure is to ask the FSF because it is their license.

As far as deleting the post, I don’t know if they did, and I don’t know what their reason was, so I’m not going to comment.

To the ext haters: what did the ext team do to you personally to make you hate them this much? I really want to know. Mail me at or answer here

Comment by Joeri — April 30, 2009

Only problem I have with using Ext is that it’s actually recommended not to use a doctype. So much for standards, let’s run everything in quirks :(.

Comment by whutevr — April 30, 2009

My problem with Ext is that they don’t participate in any performance comparisons (at least I didn’t see any). Ext widgets look good, but how is the performance? I’d like to see some numbers compared to other leading toolkits.

Comment by Les — April 30, 2009


Ah, I see. Yes, with Dijit that’s true but that’s not the only way to do it. We’ve found that there’s a lot of desire to be able to quickly prototype an application using declarative syntax, and that’s what that was referring to. You can still do all of that work in Javascript (and we kind of recommend you do anyways, when moving to production).

The basic idea is to let you quickly develop apps by just adding a few attributes to existing HTML tags.

Comment by ttrenka — April 30, 2009

Joeri, it appears that you are so blinded by Ext that you just can’t digest the legitimate points raised. Discussing this further seems pointless as it’s unlikely to change your view point. Just realize that there is a world outside of Ext where the air is fresh and clean.

Comment by fargueta — April 30, 2009

Here’s another typical example of the deceitful ways of the Ext guys. The Ext guys claim that Ext used in a web app requires the server side code to be released under GPL too. (yeah, right!)

The question asked by the user a simple one, but they simply refuse to answer publicly. The question was addressed to Abe, but every other Ext sidekick has replied trying to avoid answering the actual question except Abe.

Comment by fargueta — May 3, 2009

Since nobody mailed me, I’ll respond here.

@whutevr: I agree about their statements regarding doctypes (quirks mode may be an easy target, but it’s a lousy target). I also disagree with their use of browser sniffing instead of feature detection.

@Les: It’s true that they don’t bother much with base code performance. I get why they don’t though. My personal experience (and this extends beyond ExtJS) is that benchmark performance is almost completely unrelated to web app performance. The bottlenecks in real-world web apps have to do with server-side load and sequentiality in the loading of resources. The yahoo exceptional performance rules don’t bother with optimizing javascript algorithms, and the reason is that for most applications exceptional performance can be had even with slow javascript algorithms. My experiences so far with building extjs apps bares this out, although in all honesty I have yet to ship one (still in development for another three months).

@fargueta: I’m disappointed you don’t want to have a serious discussion. I’m also disappointed nobody else wants to have that discussion, since nobody e-mailed me. I remain open to anyone genuinely interested in having a serious discussion about the extjs licensing questions. In support of that, I’ve emailed the FSF with concrete questions as to whether or not using extjs (or any other GPL javascript toolkit) requires you to release your source or buy a commercial license instead. I’ll post the response back here.

The reason I’m so ardently arguing in favor of extjs is that I think technically it is the best javascript framework on the market (open source or commercial), and I feel that this level of excellence deserves respect and a full and intellectually honest debate about the merits and downsides. Even if they’re wrong about everything, they deserve a better discussion than what this thread has given them so far.

Comment by Joeri — May 3, 2009

Leave a comment

You must be logged in to post a comment.