ext vs jquery vs together

[qwirker]

Hello,

So I'm brand new to the Ext world, so new I've only really just browsed some of the examples. And some of those example UIs are truly awesome. Then I noticed some adapters and got a little confused (which isn't very hard for me).

I've used spry, yui, and prototype, but then discovered the joy of jquery and never looked back. In my mind I lump all these libraries together as the same and just consider jquery the best of them. At first I thought Ext too would fall into this category. But I'm not so sure once I saw the adapter, do Ext and JQ compete or compliment?

I mean personally I would never mix YUI and JQuery in the same project unless there is a very very good reason (and usually there isn't).

I guess my basic question is how does Ext relate to JQ in terms of primary function or intent? Also, is mixing Ext & JQ encouraged or just supported?

Sorry for my ignorance, just looking for the use-case I guess, and it's just not gellin'.

-q

[mschwartz]

Think of jQuery or the Ext-Base adapter as the low level DOM manipulation library, and ExtJS as the set of widgets that run on top of any of those you mentioned.

[evant]

The adapters allow you to use other libraries to provide the basic DOM functionality. It's more of a historical thing, when Ext started out it didn't have its own base library (which it now does).

[Bulle Bas]

The adapters allow you to use other libraries to provide the basic DOM functionality. It's more of a historical thing, when Ext started out it didn't have its own base library (which it now does).

I wonder why Ext-Base does only have one function for collections; Ext.each. In prototype there a lot of utility functions for collections (http://api.prototypejs.org/language/array.html).

[MartiCode]

I wonder why Ext-Base does only have one function for collections; Ext.each. In prototype there a lot of utility functions for collections (http://api.prototypejs.org/language/array.html).
+1. Actually Ext should define Array.forEach as an alternative to Ext.each, this would be more natural to write and since Javascript 1.6 this is a standard method for arrays, so modern browsers would do it even faster.

[mschwartz]

https://developer.mozilla.org/En/Core_JavaScript_1.5_Reference:Objects:Array:forEach

[Bulle Bas]

Thanks for your answer. But what about the other methods:

* all
* any
* collect
* detect
* each
* eachSlice
* entries
* every
* filter
* find
* findAll
* grep
* inGroupsOf
* include
* inject
* inspect
* invoke
* map
* max
* member
* min
* partition
* pluck
* reject
* select
* size
* some
* sortBy
* toArray
* zip

They are all functional programming coolness. Is this something which is planned, or is there some reasoning against it?
I can understand that you don't want to pollute the native array object, but something like Ext.partition or Ext.Collection.partition seems reasonable to me...

[mschwartz]

Look at MixedCollection in the API docs.

[Bulle Bas]

Look at MixedCollection in the API docs.

Yeah thanks, I wouldn't have found it. Ext-base would be a more natural fit imho, since ext-base would then be a more complete replacement of prototype/jquery/etc.

[Artur Bodera (Joust)]

Thanks for your answer. But what about the other methods:

* all
* any
[...] They are all functional programming coolness. Is this something which is planned, or is there some reasoning against it?
I can understand that you don't want to pollute the native array object, but something like Ext.partition or Ext.Collection.partition seems reasonable to me...

Let me bring you the bottom-line. Ext is developed in the paradigm of not polluting global namespace and not messing with runtime or built-in objects.

That's why Ext (almost) never alter the Array, Object, String, Function or Number built-in JavaScript classes. That's why Ext devs will never add Array.all() Array.any() or similar functions directly to Array (which is platform-defined, i.e. Mozilla engine built-in class).

Instead, Ext JS has it's own namespace: Ext. Why is that good? Because it will work flawlessly in combination with any number of other frameworks, tools and libraries.

jQuery overrides and augments the above built-in classes to add new functionality.

Ever tried to include both Prototype an jQuery on the same page? You'll know what I mean. Now add 10+ other libraries and add-ons to this, and you'll have a mess and never-ending conflicts. Ext is Enterprise-friendly and big-fat-complex-apps friendly :-)


Ext = "A foundation you can build on"
jQuery = "write less, do more"


btw: I currently use both jQuery and Ext in my new project. I use jQuery for simple, fast UI augments and "eye-candy" effects (scrolls, bounces, roll-outs, blinks, foldables etc.). I use Ext for everything else, including grids, lists, buttons, and other GUI elements. They work together flawlessly. Use gzip, JS merging and YUI compressor for best loading performance.

As for partitions and the mentioned functions, I believe most of it is implemented in Ext.data.Store. Collections are used mostly for bulk operations.

ps: http://ajaxian.com/archives/security-focus-javascript-global-namespace-pollution

[mankz]

Not entirely true, ExtJs does actually augment a bunch of the builtin JS classes such as Number, String, Array, Function, Date and so on. It's all well documented in the docs section, and I don't see it as a big problem. Sure, if you start using multiple libraries then there's a risk, but with all that Ext provides I don't see why you'd need any other library.

Check this page for a full review of how global the most popular ajax libraries are:
http://ajaxian.com/wp-content/uploads/globalpollution.png (http://mankz.com/code/globalcheck.htm)

[Artur Bodera (Joust)]

Not entirely true, ExtJs does actually augment a bunch of the builtin JS classes such as [...]

That's why I've put "almost" :-)

Thanks Mankz. I was hoping you'd drop by this thread :-) You're right, there is 56 of them, and they are augments of Function, String and Date. Still, it's got nothing to do with stack/collection/partition Bulle Bas has asked about. So Ext would "almost" be a good example of namespace separation and built-in class preservation.

Performance-wise there is little or no loss when using namespace-based methods instead of .augmented() ones. Problems arrise when using 2 or more libs that augment the same classes but with their own implementations using different arguments.

ps: http://mankz.com/code/globalcheck.htm is great =D>
ps2: In some cases when the browser window is resized the "frameworkscanner" window will go up beyond browser window, and there will be no way to move it down (without reloading the page)

[Bulle Bas]

Yes-yes, I totally agree not to pollute the global namespace. I've been working with prototype and i love all those convenient functional power, but allways wondered in what mess I would end if I mixed it with a second lib.

@mankz: fantastic, forgot about this one. Very usefull! This tool should be widely known.

[Mike Robinson]

I would frankly suggest that you want to pick one way to do things, and then work within that one framework for that application ... so that you always have only one "set of moving parts." Frameworks, of any sort, always reach quite deeply into the guts of JavaScript and build a considerable amount of infrastructure around a central set of technical assumptions. If you tried to mix these things together, well, even if you did succeed in doing it, I think that you (or your [former?] employer) would rue the decision for many years to come. The costs and risks of the arrangement would out-weigh the benefits thereof, e.g. in terms of long-term maintenance and support of your creation.

[Artur Bodera (Joust)]

I would frankly suggest that you want to pick one way to do things, and then work within that one framework for that application ...

I second that.

The only reasonable exception, that I found most common, is using 2 frameworks for different portal areas. Currently with me these are usually Ext and jQuery. Ext sits in admin panel, and other management pages with need of complex GUI (panels, grids, data management, REST, toolbars etc.).

For the rest of the portal, which is mostly read-only and viewed by anonymous users I use jQuery which brings eye-candy without the overhead. As stated on the forum and guides on multiple occasions, you do not need 600k+ Ext library just to create a button hover animation or make a roll-down menu. That's where jQuery and prototype come in. They are also pluggable, so you can load additional toys on the fly for select pages (think jQuery Tools or Sparklines).



When you go even deeper, there is a little catch. I've been mostly creating 100% ext-based apps, that were 100%-html free. Every piece of UI was created inside the app code and migration to AIR took me 5 minutes. The problem I've encountered is usability and UI standards. Web is an interesting place.

According to my observations, for non-technical folks, running a 100% Ext JS app is equivalent of running a windows app. Even if it's browser-based, most users forget about it in few minutes and they see and expect windows-like experience, opening dozens windows and throwing them around. Of course I bow to Jack and "The Team" who made it possible.

The problem appears when people DO NOT expect windows-like experience. Then problem manifests with such silly things as using browser back button to undo an action or close a window. But it's much more serious. Think Flickr and Google - they create what used to be called DHTML, that is web-experience augmented with AJAX. Every button, ugly table and plain-old <button> screams for a makeover, but people get it! They have no trouble using Gmail, hundreds of thousands every day are uploading to flickr and youtube, and even more are blogging with wordpress.

Now compare the UI of gmail, wordpress and Ext-based app. Wordpress is a complex one, but it's web-like feel makes it easier to use for beginners (?). On the other hand, if you create a webmail app which pops up in a window with all Ext-glory, they feel like having Outlook 2003 back from the grave. Which is good, because most people know outlook. Except for those who dont....

The crash happens, when trying to merge these two. How to create an Ext-based user panel, with simple use cases like browsing user's assets, change password, edit profile etc. If you make it windows-like, you'll make MS windows and old-school users happy. If you stick to the glossy, gradient, big-fat-buttons and pretty tables with colorful icons and animated accordions - you'll make it pretty and web-friendly. Younger audience will have a blast, non-technical get a better learning curve and "general web audience" will get it in minutes.


It's funny, that internet browser+ExtJS tries to be an operating system.
It's funny, that operating systems try to be browsers (webOS).
It's disturbing, that even with all it's power which I crave, Ext works best in complex, geeky or Enterprise-like apps.


I wonder what would Ext become, if it implemented better theming engine - now think Windows 2000 versus Windows XP (Vista) - the same kernel but in colorful mask.

[MartiCode]

It's funny, that internet browser+ExtJS tries to be an operating system.
It's funny, that operating systems try to be browsers (webOS).
It's disturbing, that even with all it's power which I crave, Ext works best in complex, geeky or Enterprise-like apps.

I wonder what would Ext become, if it implemented better theming engine - now think Windows 2000 versus Windows XP (Vista) - the same kernel but in colorful mask.
Your post is dead on and I've had the exact same train of thought : Ext mimics desktop apps but desktop apps are moving away to "augmented Web site" look and feel.
I also would like to be able to build app without HTML, with the level of abstract Ext provides, but that "feels" more Web-like.

[hendricd]

+1. Actually Ext should define Array.forEach as an alternative to Ext.each, this would be more natural to write and since Javascript 1.6 this is a standard method for arrays, so modern browsers would do it even faster.

Actually, the ext-basex adapter already provides Gecko Array.proto.forEach emulation for all other browsers, plus:


var arr = []; forEach(record.data, function(value, name){ a.push({name:name, value:value})});which permits global iteration of virtually anything.

But, do not expect Javascript's 1.6 version of forEach to replace Ext.each, as there is an important difference in the implementations:

Ext.each will iterate an entire range of Array indexes -- regardless of content, whereas Javascript 1.6 version DOES NOT (the value at the Array index must have been defined first).

Run these in your FB console


var a = [1,2,3];
a[5] = 5;

console.info('Ext.each says:');
Ext.each(a, console.log);

console.info('Gecko says:');
a.forEach(console.log);
Different indeed.

Careful what you wish for. ;)

[MartiCode]

Actually, the ext-basex adapter already provides Gecko Array.proto.forEach emulation for all other browsers, plus:
This is great (I guess I can remove my own version now :D )
(Edit: nevermind, I thought this was in core)



Ext.each will iterate an entire range of Array indexes -- regardless of content, whereas Javascript 1.6 version DOES NOT (the value at the Array index must have been defined first).Thanks for that gem of wisdom! Also I don't think forEach allows for "early" stop by returning false in the callback function.

[Mike Robinson]

Your post is dead on and I've had the exact same train of thought : Ext mimics desktop apps but desktop apps are moving away to "augmented Web site" look and feel.
I also would like to be able to build app without HTML, with the level of abstract Ext provides, but that "feels" more Web-like.
Without argument, Ext presents a 'web application' look-and-feel ... as it was no doubt carefully designed to do. If that is not suitable for a given application or audience, then a different platform should be used.

I will maintain the opinion that, in any application, you should use one platform throughout, because otherwise you are obliged to maintain two disparate code-bases in parallel to one another; hence, you are doubling your own work. This is not generally advisable.

[mschwartz]

Thanks for that gem of wisdom! Also I don't think forEach allows for "early" stop by returning false in the callback function.

It does not.

[MartiCode]

Without argument, Ext presents a 'web application' look-and-feel ... as it was no doubt carefully designed to do. If that is not suitable for a given application or audience, then a different platform should be used.
I don't know, the default theme for example is pretty "heavily decorated" (drop shadows, gradients, etc.) that seems closer to a desktop application. Classic web apps however are usually very minimalists, a drop-down menu can be just a text with a triangle pointing down, some actions are represented by links rather than buttons, etc.

Web apps usually follow the concept of a "editable document" - actions are offered around informations (ie: a small "delete" link that appears when you hover your pointer over the element to delete) whereas Ext and desktop application are more action-centric (toolbars and menus that you use to load/view/edit/save data).

[Artur Bodera (Joust)]

Web apps usually follow the concept of a "editable document" - .

That's exactly what I've said before. Ext apps are trying to look like desktop apps, while at the same time, many desktop apps are moving to the web :) :-/