There’s a gaping void where you might expect comments defending YUI. Quite telling in support of jquery really.
Here comes someone missing the void.
There are two main facts about jquery that I found deeply annoying:
1) the fact that it uses paradigms that are totally the opposite of “common sense”. To me, g = selector.flexigrid() sounds totally absurd. Why should I call a method on a DOM node to create a flexigrid on it? flexigrid(selector) would be the usual strategy: create an object passing the point where to attach as a parameter, which is what YUI does. More to the point, jquery puts the DOM at the center, it uses the DOM and attach javascript stuff on it. The traditional programming approach, followed by YUI, is to use javascript objects to manipulate the representation (on the DOM), exactly the opposite. I don’t want to handle DOM nodes, I want to handle javascript objects. This also means it’s more complex in jquery to extend a javascript class to override behavior, something very intuitive in YUI from whoever comes for example from QT programming, like me.
2) As for flexigrid, the access to internals is so poor that any personalization is utterly impossible, and the code design is awful. Datatable is much more powerful and extensible.
Now, I don’t claim I’m right, I am a total and absolute novice of javascript, so it can be that in some weeks I come back here to say I’m utterly wrong, but as a first impression, this is my opinion, and I wanted to share it. I am currently in the process of ditching jquery for yahoo ui in particular due to jquery annoying (to me) reversed design, and the very limited flexigrid features.
I think that having other opinions from fellow colleagues is important on this point.
http://stackoverflow.com/questions/2000597/jquery-vs-yahoo-ui-design
The replies you got on the post pretty much sum it up. You are complaining about a plugin rather than jQuery as a framework. g = selector.flexigrid() makes perfect sense to me and I absolutely love it.
Well, I’m not complaining, I just personally don’t like it
. And yes, the posts on stackoverflow are right. I do like jQuery when you use the selector to perfom an action (e.g. pure jQuery). The interface makes sense, because you are using methods on the selected entities. It’s like DOM interface on steroids. Totally love it as well. jQuery widget plugins, no. That’s totally counterintuitive to me. When you move at the conceptual level of widgets, it should hide the DOM behind a semantically sound API. The fact is that most of the widget jquery plugins I’ve seen work with this very flat, low semantic interface.
Opinions though…
“When you move at the conceptual level of widgets, it should hide the DOM behind a semantically sound API.”
No. The DOM is a pretty simple and because of this, a really powerful API. Hiding it is a mistake. If you do that, what you end up with is something like .NET or Qt or GTK+, a gazillion of classes, and huge amounts of accidental complexity. You need to embrace the DOM, not turn your back on it.
I came from desktop GUI programming too (GTK+), and it takes some time to getting used to, but really – not having to deal with a huge class library to do simple things is a big win in the long run.
I am sorry, I don’t agree. The DOM is pretty simple, powerful and flexible, exactly as ASM is simple, powerful and flexible. Yet, nobody would program today in ASM just because of these apparent advantages. DOM is a low level interface to a declarative language for browsers. Exclusively working with it implies a considerable risk of violating application constraints. Moreover, there’s a very high chance of a considerable code repetition when you program with DOM-level calls, redundancy which will most likely refactored into higher-level routines, hence you will end up reinventing a “widget set/utility library” again and again.
A similar example would be Qt against X windows calls. Nobody codes Xwin-level to create a dialog. a QMessageBox::warning() does the trick.
Of course, completely preventing a DOM level access would be wrong, but having to forcibly work at the DOM level is just plain painful.
If you want using pagination plugin, pls try it here: http://blog.kenphan.info/view/2010/02/Huong-dan-tao-jQuery-Navigation-Fly.html
That is a simple page used AJAX and JSON. The name is jPager. That jPager is easy install & simply.
This comes at least a year late from the original post, but I’d suggest a close look at jqGrid as an alternative to Flexigrid.
jqGrid here: http://www.trirand.com/blog/
jqGrid is very open, more feature-rich, and has a strong community supporting it – including a very active and approachable principal developer.
The sorting in the examples seems a bit odd. I try to sort by division by clicking the header and I see there is a high number 17 in there but it doesn’t go to the top and in fact disappears strangely. Ah maybe it’s setup for sorting by characters (left to right) rather that integers.
Anyway, very good article as I’m starting off with jQuery but learned about YUI also. The mock report pagination is very cool and I’ll be needing to make something similar sometime soon.
October 13, 2008 at 7:55 am
With all due respect as to the including js files, you could cut it down to a very few for YUI by including utilities.js as it is an aggregate of many of the scripts you have to link in.