PDA

View Full Version : moo-ext - opinions



dselkirk
31 Jan 2007, 1:29 PM
I thoroughly enjoy yui-ext. Its simply just a great library (thanks jack). I'm currently utilizing it to build a new CMS for our company which is quite destinctive.
http://don.atomicmotion.com/cms/
Feedback would be great and please bare with that particular server, kinda slow.

With larger applications like this I find myself concerned about size, load time and wishing for other functionalities. So, I have started porting yui-ext to utilize mootools, thus moo-ext. Mootools provides a really enhanced libary but with a minimal foot print. I have already ported a number of scripts and it has drastically reducing some of there sizes. It also has various other differences I just find easier to use than YUI (cough $, hehe).

I wish to know if anyone else thinks this might be a good idea and if they wish to assist in the port.

Cheers

Animal
1 Feb 2007, 12:08 AM
I've changed the way I think about web apps. I think this one I'm working on is going to be single page. The JS and CSS BorderLayout, navigation etc will be loaded once. All JSPs will be loaded into a ContentPanel in the center Region.

So the js loading hit will be only at application startup.

With the new "X-Requested-By" (I think that's what it will be called) header coming up in the next release of YAHOO.util.Connect, my page handling tag will be able to know whether to output a full HTML document with head, CSS, JS, layout and body, or just a fragment containing the body.

I'll have a document click handler to handle clicking on links which will cancel the event and load the page into the content area.

brian.moeskau
1 Feb 2007, 2:37 AM
Can you give some more examples of things you have ported and why?

Also, Jack intentionally stays away from global functions (cough $ ;)) for the most part as they tend to cause conflicts with other libraries. Besides, if you just want a shorthand to save typing, you can always do this in your code without actually "porting" another function into Ext:


var $ = YAHOO.ext.Element.get; // .33 syntax, or...
var $ = Ext.get; // .40 syntax
I don't know much about mootools, but Jack's element stuff does a lot of work under the covers to boost performance (dynamically-compiled selector functions, element caching, etc.) so that multiple calls to Ext.get perform extremely quickly for the same element -- make sure that you aren't actually giving up useful functionality by replacing Ext functions!

Also, I'll close with the obvious -- once you start down the road of porting overlapping functions between libs, then you're setting yourself up for a serious maintenance headache. I hope you have good enough reasons to justify the effort!

HarryC
1 Feb 2007, 3:34 AM
While on the subject of others libraries, what do people make of dhtmlsuite: http://www.dhtmlgoodies.com
It seems to have (copy?) many of the UI features that Jack has built.

As for the discussion about the size of the footprint that YUI and YUI-EXT warrants, I think it is something developers ignore at times. But things link On-Demand Javascript (http://www.glennjones.net/Post/808/ModularJSONOn-DemandJavaScriptinterface.htm), PHPIED (http://www.phpied.com/javascript-include-ready-onload/) and Ajile (http://ajile.iskitz.com/) seem to me sensible ways around these issues. I feel this is something that would benefit yui-ext.

PS. I can't get the links to work. [edit] I've put in the standard BBCode URL example below this line and it shows nothing.

Visit phpBB! (http://www.phpbb.com/)

dselkirk
1 Feb 2007, 6:42 AM
Good points. This is why I posted this, so i can get some feedback like this.

Animal: The X-Req sounds interesting but one of my biggest fears with this library is subpages. I load a page and it simply has to load all the required scripts again. Sure you can optimize and cut down the calls but its gonna happen. Im sure someones going to mention that its cached. Not to first load and not if you have caching disabled (alot of people do). Then you can get into that iframe loader another guy had post, sorry but that was just a headache in a can. don't know, maybe i'm just missing something.

bmoeskau: I basically was having to rewrite numerous scripts of server compatibiliy (better response handling, etc.). Not to mention the addition of newer functionalities. When I started building the CMS I originally wanted to build it in mootools but it had not yet been released so functionalities still being ironned out. The maintance and size is a definite convern thus is also why I would like to get some opinions first before I dive in 2 deep. Thanks on the alias creation example but I think I'm ok :wink:. The global function and other libraries is a good arguement but how often does anyone use more than one library(like yui-ext) with another. Yes, JQuery but it has not become unnessecary since Jack has implemented the dom functionality. This brings be to my points at the end.

HarryC: The similarities are scary. not as nice though

I think the largest reason I have started this is for the fact of communitee size. Let one complete communitee maintain the core elements and we maintain the gui elements. I think thats what we all ready want out of this library. The ability to build robust web applications without a worry of performance or maintenance. double up the use base workin on it and you can get an even better product with the addition of even more functionality. yui-ext did start as an extension of yui. why take on more than needed. my opinion.

Animal
1 Feb 2007, 7:05 AM
That DHTMLgoodies stuff is very similar to Ext.

I do like the way they've done theiw "Windows". The buttons are floated to the right in the header so that you can enable/disable close/maximize/minimize.

Ext's BasicDialog is going to have to become a Window...

brian.moeskau
1 Feb 2007, 9:46 AM
DHTMLGoodies has been around for a while, but it looks like their "application" suite is a repackaging of some of their old stuff with some newer stuff thrown in (the layouts, in particular, seem to be a pretty blatant rip-off of Ext :x ) Some of their stuff (the non-ripped-off stuff?) is not nearly as nice, plus I'm not sure whether or not they actually offer a core API to work with, and if so, how good it is.

Regarding lib size and people having caching turned off etc., it's a valid concern, but at this point, those same people would not be able to use any newer Google app, any modern online email app, etc. The way I look at it is that most reasonable people are willing to turn on javascript/cookies/caching in order to get the benefit offered by modern web apps. Personally, I'm not killing myself worrying about that particular aspect.

ilazarte
1 Feb 2007, 10:38 AM
I wish to know if anyone else thinks this might be a good idea and if they wish to assist in the port.

Cheers

Is this really necessary?

1. YUI core (utilities.js) (83K)
2. Yahoo Ext (yui-ext.js) (250K)

that's a lot of power- it includes the all the awesome ext widgetry and raw utilities in 300K.
if you're designing a cms for 56K then maybe it's justified, but otherwise, I think you're probably wasting your time.

tryanDLS
1 Feb 2007, 11:34 AM
Is this really necessary?

1. YUI core (utilities.js) (83K)
2. Yahoo Ext (yui-ext.js) (250K)

that's a lot of power- it includes the all the awesome ext widgetry and raw utilities in 300K.
if you're designing a cms for 56K then maybe it's justified, but otherwise, I think you're probably wasting your time.


I would agree. You're building a Web application for a specific target that will undestand the complexity and size. While the 'smallest possible download' goal may apply when you're building web pages (not apps) for the masses, I think it no longer applies in the application building world. You can't build a web app that looks and functions like a desktop app in 100K.

Jack continues to strive to reduce the footprint of Ext, and I'm guessing that yahoo will do the same with yui, because the noise ratio about code bloat in their stuff is probably much higher.

dselkirk
1 Feb 2007, 11:44 AM
Thats very true and I am not debating the functionality. But your also forgetting images, customized scripts, implementing scripts, etc. Also, since when has yui-ext been 250k, current trunk built with jsbuilder is around 350k. The CMS listed above has been optimized for better performance and loading and yet its still fairly large.

Images (17 files) 151 kb
Scripts (14 files) 487 kb
Style Sheets (6 files) 52 kb
Total 692 kb

So its a toss up, you load a majority once or attempt little bits hear and there. Either way your still working with a lot. I'm not even done yet and I'm already reaching a fairly significant sizes. As for the caching people it think its a fairly valid concern. Not so much for people turning off caching but for all those cleaning programs being utilized to help prevent spam.

To give a better example of size comparison. I have done a basic port of the DomHelper. The below are the uncompressed sizes of corresponding required files.

Mootools
Moo.js 4.26 kb
Utility.js 3.30 kb
Array.js 6.53 kb
String.js 5.00 kb
Function.js 5.93 kb
Element.js 20.9 kb
DomHelper.js 8.43 kb
Total 54.35 kb

YUI-EXT
utilities.js 69.1 kb
yutil.js 23.3 kb
Element.js 88.0 kb
DomHelper.js 16.7 kb
Total 197.1 kb

How many clients care about complexity and size. There interested in functionality and ease of use. That is what got me interested in yui-ext. It was robust, functional and fairly sturdy. Isn't there a way we can have both.

JeffHowden
1 Feb 2007, 12:00 PM
A significant portion of this argument is moot as these files (css and js) are text and therefore zip up very nicely. So, my question to anybody concerned about a 300kb js payload, are you gzipping all your web server responses?

tryanDLS
1 Feb 2007, 12:03 PM
Looking at uncompressed files sizes is irrelevant - that difference could be based on the amount of documentation in the files.

For example, in the .33 build, DomHelper.js is 17K and DomHelper-min.js is 7K. The .33 build is only compressed with jsmin. Using something like sourceshrink and/or gzip, these numbers will be further reduced.

The size of the trunk build is also not relevant - it includes stuff you're not D/Ling to the client (e.g. jsbuilder).

dselkirk
1 Feb 2007, 12:47 PM
This is funny. Your basically making it sound even better to port. Hey, we can get the existing down to 7 kb's. Since the other comparison was a 3rd of the size does this mean you would choose to use the file 7kb or 2kb. Sure there is a lot we can do to further reduce the file size but again the same arguement can be used for a mootools version. If you had an option, which would you choose, larger or smaller.

I beg your pardon but I really don't know why you say the the uncomressed sized or trunk sizes are irrelevant. They are as stated points of comparions. The 350kb reference I used was for the actualy yui-ext.js built with jsbuilder directly from the trunk. Only scripts, no jsbuilder. As for the amount of documentation, good argument so I checked. Using jsbuilder to compare final sizes of the same scripts as mentioned before.

Mootools - 21.8 kb
yui-ext - 112 kb

five times smaller this time! At least we know which has more documentation. hehe.

tryanDLS
1 Feb 2007, 1:12 PM
You're comparing apples and oranges here. yui-ext.js from the .33 D/L is 275K - I don't know where you're getting 350KB. This file includes the base library plus all the widgets - dialog, layout, grid, button, etc.

The mootools components you mention look to be only base utility functions - can you build your layout with that? Can you make an XHR request that? Can you build a complex grid from XML?

Maybe I'm missing the point. You can get into the same pissing match that tried to start on the blog regarding domquery vs jquery. Maybe mootools components are smaller, but what can you do with them? Are they faster? Are they easier to use?

brian.moeskau
1 Feb 2007, 1:16 PM
If you had an option, which would you choose, larger or smaller.
If that was the only question, then of course, the answer would be simple. BUT, the question is between larger vs. smaller -- only with the additional effort involved with porting and maintaining a forked version of Ext. So it's not a question of whether smaller is good, it's a question of whether or not the difference would be worth the effort that you're proposing.

In my opinion, it seems like a case of diminishing returns. Yes, you can squeeze a little more byte savings out of it, but A) Jack is constantly revising the lib to consolidate code, add shorthanded functions, etc. and B) if I was to contribute effort, I'd rather spend my time adding additional value to the library rather than rewriting stuff that already works.

If you want to port some functionality from mootools that's not currently in Ext, that is one thing -- I'm sure everyone would be in favor of that. But forking perfectly good code and using file size as the main justification is probably not going to fly.

dselkirk
1 Feb 2007, 2:01 PM
tryanDLS: the 350 is the from the current svn trunk, not the 33 download. But I'm certain that the same would apply. Also you might notice that I only included the libraries to allow the domhelper to operate. Its true that the yui utilities does provide additional functionality like the ajax calls. But if we really wanted to get picky the whole mootools library with additional widgets as well with jsbuilder is only 73kb versus the 112 kb for just domhelper, element and utilities. Sure yui-ext has a lot to offer, why else would this discussion be happening. That is the point, take the best of both and merge them. What do you think yui-ext started as, it was something better than yui. Lets do the same, something better than yui-ext and mootools alone.

bmoeskau:
excellent points. I certainly don't think that a maintained fork would be appropriate. Frankly I didn't know how or where this would finally result. As this topic states I was looking for opinions. I guess in the perfect world the port would be done and would be backwards compatible, to a point of course. Then it would replace at some point. By the sounds of some of the tense responses it doesn't sound like something to many people would like. Most likely it would be developed as a completely seperated library with no ties to yui-ext. Not what I would want.

Your reference about squeezing a few more bytes doesn't really translate to 5x smaller. Short hand functions would simply add to the size. I'd rather spend my time not developing one large piece but rather just the amazing gui aspects that we all love. The rewrite code that already works argument doesn't really apply when everyone was using jquery and jack then built his own.

My only argument here is not about size but its fairly significant as some of the previous posts state. Its the fact of improving an already great library. Focus on building great gui widgets, better dialogs, more enhanced grid functionalities, etc; rather than building everything in between. Why else would any of us use a library to build something rather than start from scratch, to save time and allow us to focus on other areas.

Sorry guys, its certainly not my intent to stir up trouble. I'm simply asking why can't we improve this already great library?

I guess no one agrees.

brian.moeskau
1 Feb 2007, 2:14 PM
Everyone wants to "improve the library." Not too many people are interested in porting stuff out of it into mootools or another lib though. If you see areas in Ext that can be made smaller or more efficient, then by all means make some suggestions for improvement. But if you continue suggesting copying code out of Ext into yet another separate library, you probably won't get too much interest I'd guess.

jack.slocum
1 Feb 2007, 3:51 PM
That dhtmlgoodies stuff is a blatant rip off and I have sent an email to the author. Although the js code in yui-ext is distributed with a BSD license, the graphics are not. In fact, they are explicitly licensed for unlimited and unrestricted use with yui-ext.

I generally don't care but they forgot one key thing - some kind of attribution. Taking someone elses hard work and pawning it off as your own without some kind of attribution is unethical.

jack.slocum
1 Feb 2007, 4:17 PM
ext-core "packed" as mootools is weighs in at 30kb. Yeah, only 30kb. YUI utilities packed weighs in at 21kb. So for 51kb you get all kinds of functionality mootools doesn't have. Oh yeah, you are generally looking at significantly better performance across the board.

Ext is not distributed "packed" because packing JS is not the best way to do it. Gzipping is the best way and gets it even smaller. JS that is packed and then gzipped ends up the same size as the original JS gzipped. So why and the additional overhead of unpacking on the client? With that said, in the next release I will distributing a packed version of Ext for people who don't have access to gzip.

Here are some core vs moo comparisions:


DomQuery vs Mootools $$
DomQuery supports 10x as many selectors and combination of selectors, while mootools supports 5 very basic selector constructs. Yet DomQuery is 5-10x faster.

Element vs. Mootools DOM Extension
The Ext Element object wraps around a node to add additional functionality. This mean creating an Element object is very cheap, so cheap you can create 1000s of them in under 100 milliseconds. Mootools does it by copying functions and properties directly to the node. This is expensive (and slow).

With an Ext Element you can say el.foo = someObject and store a reference to someObject without worrying about memory leaks. With moo, sticking objects directly on the DOM node is a sure way to leak memory.

Ext also provide a composite element variation which allows you to work with collections of elements as 1. I don't think Mootools even has this functionality.

The Ext Element object has SO much more functionality than the mootools DOM Extension, again I don't think it's a fair comparison even though Ext again is faster.

DomHelper vs mootools ?
DomHelper is the fastest dom builder out there. I don't even think mootools has one?

Ext EventManager vs mootools ?
Normalized browser events. Again this is a no show in mootools.

Ext Observable vs mootools ?
Not present in mootools.

Ext Template vs Mootools ?
Another ext core feature not found in mootools.

Ext.Layer vs mootools?
Another ext core feature not found in mootools.

IMO comparing the size of a base library (mootools) that doesn't have the best design (how many global $xxx functions can you have?) is like comparing a Honda s2000 (great car, small, kinda fast) vs a ferrari (larger but faster and more features). Which would you rather drive?

dselkirk
1 Feb 2007, 7:52 PM
Jack, thank you. That was a great comparion and you made some great points. Also note that I am not comparing you library to mootools. I'm simple seeing what we can do with it (example size). Trying to see if we can save time and effort not maintaining more than needed. Aparently that is an issue with some of you. I have presented some valid information and some surprising size comparisons. I think Jack has also done the same. What is the point of have a forum unless we can do this. So cheers for listening and I appreciate some of you feedback.

jack.slocum
1 Feb 2007, 8:06 PM
I appreciate the discussion and an effort to make Ext run with mootools is not a bad idea (in fact it's something I am considering). Not exactly mootools or any other library, but a compat layer that will allow it to work with any library, not just YUI. Some things, e.g. YUI drag and drop, will need to be adopted and recoded to make it work. If there's enough interest, I could make this happen. There will always be some overlap (Ext will always use Element and libraries like mootools and jQuery have their own functions) but it shouldn't be too bad.

--

I have contacted the developer of dhtmlgoodies.com and he was very nice. He has agreed to replace the images with his own and also added an attribution and link to yui-ext.com. I wanted to point that out since my previous post was quite harsh.

HarryC
2 Feb 2007, 4:39 AM
I think it was understandable that your first post about dhtmlgoodies was a bit harsh (I don't even think it was particularly) as it's going to be a shock when you see your work copied. I've used some parts of dhtmlgoodies over the years and it's a really nice little site with some good work although not quite up to the amazingly high standards here. I mix things from YUI-EXT and there and other sites and was rather surprised when I checked that site and noticed the similarities between their recent updates and some of Jacks' work. I didn't intend by pointing things out to cause any problems and I'm glad you got a friendly resolution from them.

I think it's great that everybody can learn from each other and improve their work; but people do have to give credit where it is due.

WhiteKnight
13 Mar 2007, 5:21 AM
I noticed today, that yui-ext (at least the new alpha?) now supports other "base-libs" than YUI. That was great news, since I'm using mootools as "base" in my projects, but since I saw yui-ext the first time, I wanted to use it.
But as long as there is the need for another "base-lib" I cant do that, so I just wanted to state, that I would be happy to see a compat-layer for the use of mootools as "base-lib" in the future. :)
Keep up the good work!

Cheers - WhiteKnight

fabrizim
21 Mar 2007, 4:25 AM
If anyone is interested - I started creating an adapter for mootools.

Thread: http://www.yui-ext.com/forum/viewtopic.php?t=3626

Page: http://www.joomlicious.com/ext-mootools-adapter/

Hopefully this will help others!

Regards-
Mark

alwaysvip
7 Oct 2007, 11:52 PM
Mark,

Have you stopped working on a Mootools adapter?