Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 25

Thread: moo-ext - opinions

  1. #11
    Sencha User JeffHowden's Avatar
    Join Date
    Mar 2007
    Location
    Forest Grove, OR
    Posts
    1,038

    Default

    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?

  2. #12
    Sencha User
    Join Date
    Mar 2007
    Posts
    7,854

    Default

    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).

  3. #13

    Default

    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.

  4. #14
    Sencha User
    Join Date
    Mar 2007
    Posts
    7,854

    Default

    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?

  5. #15
    Sencha User
    Join Date
    Apr 2012
    Location
    Austin, Texas
    Posts
    4

    Default

    Quote Originally Posted by dselkirk
    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 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.

  6. #16

    Default

    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.

  7. #17
    Sencha User
    Join Date
    Apr 2012
    Location
    Austin, Texas
    Posts
    4

    Default

    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.

  8. #18
    Sencha User jack.slocum's Avatar
    Join Date
    Mar 2007
    Location
    New York, NY
    Posts
    6,956

    Default

    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.

  9. #19
    Sencha User jack.slocum's Avatar
    Join Date
    Mar 2007
    Location
    New York, NY
    Posts
    6,956

    Default

    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?

  10. #20

    Default

    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.

Page 2 of 3 FirstFirst 123 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •