View Full Version : Disappointed

18 Dec 2006, 10:57 AM
We all really like YUI and specially YUI.ext because of its great looking widgets and examples. However more and more I feel myself avoiding YUI.ext because of its hard coupled classes. Don't get me bad, I just want to tell you how I feel sometimes disappointed because I want to use YUI.ext, but because it offers alternatives to YUI I have to choose one, and honestly I prefer to stick with YUI.

It is disappointing because YUI.ext is great! I feel that more and more features are added and it gets bigger and bigger, not mentioning the dependency hell between the widgets. Maybe a loader could solve this, but honestly I would like to see less dependency and more YUI "extensions" than "alternatives". Two examples are the BasicDialog and Resizable components.

- Why BasicDialog is not build on top of YAHOO.widget.container?
- Why Resizable is not build on top of YAHOO.util.dragdrop?

I was working with the BasicDialog and worried about the amount of libraries I needed to load (plus the YUI core libraries), and I couldn't set dynamic dialogs with BasicDialogs (maybe it is possible, I'm not proficient in javascript), and also I need YUI's SimpleDialogs and in the end was using YUI's container plus a few kb to get something similar to BasicDialog. It's disapointing that '.ext' doesn't mean really '.ext'. I choosed what gives me more options for less kb; I think this would be different if BasicDialogs were build on top of containers. If I would use *only* BasicDialogs, but again this makes '.ext' meanless.

Again, don't get me bad. This is just an opinion. I can't decide it of course, but this is something I would like to see in future YUI.ext versions:

- cut features; don't add every possible option an user ask; less is more; please cut features;
- cut dependency; please cut dependency;
- cut kb; please cut kb;
- focus on YUI extensions based on YUI existing libraries rather than new alternatives;
- of course, also offers widgets that are not available in YUI.

I hope this makes a little sense and can be somewhat helpful. :-)

18 Dec 2006, 12:44 PM
Ok this just me, not Jack, talking but the point of this project was to 'extend' YUI and do something useful. YAHOO has a bunch of pretty demos of boxes animating back and forth and a couple simple dialog boxes, but not much more. This may have improved recently, but frankly I rarely look at their stuff anymore b/c there's nothing beyond the basics.

I don't see coupling as an issue, and where it was, Jack has made changes to decouple (e.g. Buttons and Toolbars). Buttons, Toolbars, Grids, Dialogs, Panels are not coupled.

Dialog and Resizable are not built on top of the YAHOO components b/c
a) YAHOO stuff was/is too heavy, or
b) were less functional or did not exist when the yui-ext code was written

I think BasicDialog by itself is more functional and easier to implement than having YAHOO container+Simple Dialog plus whatever else it needs. There's really no reason to use both - it just complicates the interface you have to learn. If you want the fancy gui piece of YUI dialog buttons, you can probably do that with yui-ext dialogs via CSS - Frankly replicating a windows dialog with exclamation mark or question mark isn't real high on my list of priorites.

'cut features' makes no sense - why not just stop the project and wait for YAHOO to add more stuff. 'Less is more' may apply to the application and choices you provide in YOUR app, to YOUR users, but as an application developer, I want as many tools in my toolbox as possible. I'll decide how many of them to add to any one application.
I don't want 'less features'. The more features that are available, the better. If that means I can eliminate a bunch of ASP.Net generated stuff, so much the better.

Part of the attraction of this library is that it is growing/improving faster than the YAHOO library itself. It's also better documented and the samples are much more applicable to the real world. YAHOO has done relatively little in the last few months, which is suprising given that they certainly have more developers involved than yui-ext.

'cut dependency' - once again I don't see this as an issue - the yui-ext dependency on yui has actually gotten smaller over time. I no longer use their dialog at all.
I don't think I'm using any of their CSS anymore either, except maybe fonts-css. And soon, I'll scrap their tree object in favor of the yui-ext version.

The obsession with size (e.g. kb) is misplaced. Using compression (JSMin combined w/GZIP), the code is pretty small and once downloaded doesn't need to be re-downloaded unless you have caching issues or the code base changes. Using the 'build your own yui-ext', you can make the lib even smaller if you want. You don't need a loader, as this function tells you what pieces are dependent.

Just my $.02

18 Dec 2006, 12:48 PM
However more and more I feel myself avoiding YUI.ext because of its hard coupled classes.

That baffles me. That's one of things I think is a strength of yui-ext, in that the components are built separate from each other allowing them to be pieced together to create the bigger components (or you can use the building blocks to build your own).

For example, rather than hard-coding in the same resize functionality into everything, there is a component that handles resizing. Since BasicDialog supports resizing, it should use the existing component. That's code reuse and the main reason for using OO to develop components.

Using BasicDialog again as the example, it's total weight is 13.6kb. That's pretty light considering it supports resizing, custom buttons, auto tabs and other features not found in the YUI containers. Yes, the YUI containers DO have features not found in BasicDialog, but 47kb worth?

I feel that more and more features are added and it gets bigger and bigger, not mentioning the dependency hell between the widgets.

I don't think dependency is a bad thing when you consider the alternative of duplicating the same functionality across components (like the base YUI library does over and over). Again, the power is that the same components yui-ext uses to piece together BasicDialog and other components, you can use to piece together your own custom components. Meanwhile the standard YUI lib uses duplicate/cut-n-paste when going beyond the basic utility libs.

Why BasicDialog is not build on top of YAHOO.widget.container?

3 main reasons are 1) file size, 2) limitations, 3) performance.

1) container.js is 64kb compressed and much of the functionality provided by it is built into the core of yui-ext. I can either write one class that is 13kb or write a class on top of a 64kb include. That to me seems like a no brainer.

2) All the YUI containers use display:none and cause problems with the grid and tab components. display:none is also very slow.

3) All the container classes are slow when displaying anything other than basic html. For example, when I initially created my comments system I used a standard YUI dialog. However, clicking on a comment marker had a very noticable delay (even with just a few comments), so it had to go.

I want to use YUI.ext, but because it offers alternatives to YUI I have to choose one, and honestly I prefer to stick with YUI.

That is your decision of course. I would disagree with it, as I think the benefits of using yui-ext should be apparent. Just for one example, look at the YUI resize dialog functionality vs the BasicDialog resize functionality. One looks like something hacked into code that doesn't support it (YUI) and one looks polish and built-in. The hilarious part of that is the total code to get it into BasicDialog was a couple lines, while the YUI takes a bit more. That's the benefit of using small components to piece together larger ones.

Why Resizable is not build on top of YAHOO.util.dragdrop?

Dropdrop doesn't support a variety of things in Resizable, such as dynamic proxy resizing and preserve ratio. Resizable has a total weight of 8kb, and maybe 1/2kb of that is logic that YUI DD could provide (mouse down handlers). I learned my lesson with SplitBar - there is no benefit to building it with YUI DD. One look at functionality VS size (8kb for Resizable vs 6kb for SplitBar, yet Resizable does so much more) and you can see there is no benefit. YUI DD is also terribly slow. The Tree component I am building (yes another "replacement") had to write an entire abstract/delegated DD instance to overcome the YUI locationCache performance issues.

I couldn't set dynamic dialogs with BasicDialogs (maybe it is possible, I'm not proficient in javascript)

autoCreate:true. It also let's you provide a DomHelper config instead of "true" to customize the markup used to create the dialog.

I need YUI's SimpleDialogs and in the end was using YUI's container plus a few kb to get something similar to BasicDialog. It's disapointing that '.ext' doesn't mean really '.ext'. I choosed what gives me more options for less kb; I think this would be different if BasicDialogs were build on top of containers. If I would use *only* BasicDialogs, but again this makes '.ext' meanless.

What do you need a SimpleDialog for? That functionality could be duplicated easily with BasicDialog.

I agree though, the library has moved beyond being an ".ext". The idea is to provide a solid *real world* foundation for building applications and the only dependency is utilities.js. The funny thing about that is Yahoo follows the same idea. All their new sites use the YUI utilities, but you never see the components used on any of them (at least that I have found).

- cut features; don't add every possible option an user ask; less is more; please cut features;

Trust me, I do.

- cut dependency; please cut dependency;

Again, I still don't get this one. Having a 13kb file depending on 8kb + 5kb small components or maybe 5kb depending on a 64kb seems like a no brainer.

- cut kb; please cut kb;

I try. I am even naming my variables with shorter names now. :)

- focus on YUI extensions based on YUI existing libraries rather than new alternatives;

My primary focus is on what people request. If they want a new Tree because the YUI one sucks and they are willing to sponsor development, I am going to build one. :)

With all that said, I DO very much appreciate you taking the time to make this post. Like I said above, development direction is driven by user input and your input is valued.


18 Dec 2006, 1:58 PM
I disagree that YUI-ext have better docs and examples. YUI's narrative docs are amazing and the API docs also has information about the dependencies and class hierarchy. The examples are self-explanatory or at least you know exactly which files you need. YUI-ext also has great docs and examples, but they are not as straightforward (it's me, probably) and you have no clue of which components are really needed until you don't get your widget running. *BUT* YUI-ext has wonderful docs and examples, I just don't agree that they are more educative/informative than YUI's.

When I talk about dependency, I don't mean YUI->YUI-ext dependency, but the dependency between YUI-ext components. It is not easy to figure what is missing when you just need dialogs with content loaded using YUI's connection, and not everybody agrees that a 275KB include is a misplaced concern.

Perhaps this is all about my javascript incompetence to build some dynamic dialogs with dynamic content and stay below 150KB of files. I do think KB is important for public sites, and I'll lost X% of visitors depending on how long my pages take to load.

Jack, you have made good points about the dependency and YUI duplicating functionality; I'm convinced now that splitting and sharing is probably a good direction to take; however I still think that sometimes a no-dependency simpler option should be given (quick example, maybe nonsense, but it is not hard to find others: BasicDialogs buttons. By default it could use ordinary buttons with a hook for the buttons component. I hope this makes sense; I wish I had an example that involved more KB :-) ). Perhaps a 'smart' loader would make easier for people to start with YUI-ext (loading scripts only when needed). Also I didn't knew about Yahoo sites and utilities.js. Nice point as well, and I'll try to build a toolset with utilities.js + YUI-ext.

So I'll give BasicDialog another try. I love it after all.

Thanks, guys.

18 Dec 2006, 7:18 PM
By default it could use ordinary buttons with a hook for the buttons component.

Supporting multiple button types takes code, which increases KB and complexity. The JS itself is only 2kb for buttons.

With that said, you *can* use standard buttons. ;) "addButton" will accept a DomHelper config.

dialog.addButton({tag: 'button', html:'Submit'}, myHandler);

or you could just add a footer to your dialog, and add the buttons in like normal, and attach handlers with normal JS:

<div class="ydlg">
<div class="ydlg-ft"><input type="submit" value="Submit" /> ... </div>


var dialog = ...;
getEl('form-id').on('submit', function(){

YUI's narrative docs are amazing

It's hard to argue with that. But the thing that their docs lack is doing anything real world with the code. I believe there is a reason for it. Standard YUI code is very lengthy, time consuming and verbose. For example there old menu bar example was 100s of lines to make a menu bar? I think they just don't think about the end user - the developer. Another example, have you ever worked with the Calendar control? The way it accept input dates (strings in a weird format, and nothing else) and provides the date to event handlers as a multi dimensional array of integers. Who came up with that idea? Or the CustomEvent signatures, with an array of params. It's these little things that I think make coding with a library either enjoyable, or a nightmare. The base functionality is there, but how it's presented to the developer is often unfriendly.

For the dependency issue, the only reference I can give is the "Build your own" dialog. It lists all the dependencies for each component, and allows you to build a download for just want you need. The user interface isn't the best to use as a reference though, but that will be improved very soon.

One more side note, yui-ext gzips to around 60kb. That's the whole 275kb file, which you probably don't need all of it.

18 Dec 2006, 10:32 PM
"Are you human?" That's a new and interested stuff. good job, always!

Different people always have different opionion because usually people often think in their own perspetives. I cannot support YUI-ext any more. I know YUI is good but I really do not want to use it any more. Jack does not have a slider gadget so I have to use YUI's slider. For such a simple slider I have to load 64kb YUI library. If Jack have a slider built on his YUI-Ext library, I believe I only need a slightly bigger JS. So why Jack should cut features, rather than expand it?

Anyway, I am Jack's fun now and I have totally discarded all other choices, even .NET, or MS Ajax for website UI and web pages. I only use .NET for website back-end operations in server side such as XML, data access, login, validation and so on.

I have a dream. I hope Yahoo can buy YUI-Ext or recruite Jack as the core member of YUI team. If it happens, then either you or me need to debate cut or expand.

Integration is a good thing, is it right?

19 Dec 2006, 1:25 AM
I have a dream. I hope Yahoo can buy YUI-Ext or recruite Jack as the core member of YUI team. If it happens, then either you or me need to debate cut or expand.

I was hoping to be convinced to use YUI-ext and you guys have done a great job with a lot of good points. :-D Perhaps "Lost" would be a better title for this thread. I was trying to decide about this or that, and in terrible doubt if it would be nice for me to drop YUI-ext (because we know, it is sooo nice), and Jack gave me a good insight suggesting the combination of YUI's utilities.js + a YUI-ext toolset. I've turned my head back, guys. It's probably everything I needed after all. Thanks for the thoughts and I hope there's at least a valid point in my concerns. :-)

About the docs. One thing that I miss in YUI-ext's compared to YUI's is a list of inherited properties/methods/events for each class. It helps a lot to navigate and find the method you were looking for when working with a specific class. Maybe I've overlooked this? If not, that's an improvement that would be worth to have one day (from a novice perspective, this really helps).


19 Dec 2006, 1:17 PM
Take a closer look at the docs. Rather than a hideous unreadable blob of inherited methods, they appear inline with the other methods for the object. The blue up arrow indicates it's an inherited method. On the right of the method (or property) is the name of the class where it's defined (and a link to that method).

Using this approach, documentation cascades up. When you go to an object you have all the documentation right there, instead of searching through the inherited method blob and then having to click the method (and leave the current class) to see the docs for that method. IMO, this is HUGE improvement.

19 Dec 2006, 2:51 PM
I was confused by a BasicDialog method that I saw in this forum but not in the docs and later I discovered that it came from Element (duh! what a shame). Of course it is great to have everything related to the class in the same page. It makes a difference indeed. Good, good. :-D

19 Dec 2006, 11:23 PM
There's a learning curve to both YUI and YUI-ext. The difficulty I've had in adopting the yui-ext portions is having to (re)learn Javascript, which I've avoided quite a bit until about 6 months ago.

Let me give you a historical perspective, if I may. I've been writing applications for 20+ years now, dating back to my mini and mainframe days. I've been writing web applications since NCSA Mosaic was in alpha mode and ran ONLY on X Windows running Motif. I saw the power of HTTP and HTML and started writing applications for it. When Netscape was released, it implemented the then unknown Javascript client-based scripting language. The language was very thin, and when Internet Explorer came out, it muddy the waters greatly with Javascript due to Microsoft's implementation of JScript. Things worked very differently between the two browsers, and it made doing anything extensive in Javascript pretty much impossible without having two complete codebases, which I avoided.

The idea of ajax has been around for a long time. I implemented a web interface back in 1996 that performed asynchronous updates to the web browser. In those days we had to embed an applet in our page in order to do the updates, and use shims to get the data out of the applet and into Javascript. With the "standardization" of the DOM now, and with much more stable and standard Javascript implementations available, it's finally possible to do some of the things that Yahoo and Jack have been building toward.

Think of it like this: We're in the infancy of the whole class library system for client-based web user interfaces (call it Web 2.0 if you will - I really don't like the term, but it's gaining popularity.) There is currently no baseline standard for a class library for user interfaces. If you look at Yahoo's UI library, you'll find the basic building blocks for inline functionality. But it's missing huge chunks of functionality that prohibits one from building a web interface that looks and smells like a desktop application. The "grids" in YUI, for example, are just CSS styles that most of us web developers had already implemented in one way or another with style sheets. What Jack is building, from my perspective, is a framework for building real applications that look like desktop applications and not web extensions with mini widgets on them.

Let's look at a few of the interfaces that are enablers:

BorderLayout - The functionality provided by BorderLayout, with builtins for toolbars, splitters, tabs, scrolling areas, etc. is incredibly sophisticated and requires so little user code to implement, it's almost obtuse. There are certainly a few hiccups here and there in it (I personally would like to see an abstraction of the styles for the UI, but that's just me) but overall it provides functionality that is nearly non-existent anywhere in the YUI.

Grid - This doesn't exist in the YUI at all, and it's really what Jack started with. His grid is pretty much commercial quality as it is right now. I see the grid as the final enabler for about 10 different applications I've been considering writing. It's a perfect component for things like webmail interfaces, file browsers, SQL viewers, etc. There are a couple commercial widgets out there that provide similar functionality, but with the addition of the inline editing and the ability to embed it directly in a layout, all I can really say is "wow."

Resizeable - While it might have made sense to start with one of the YUI classes for this, sometimes you're just better off building it from scratch. Jack's implementation is better than most that I've ever looked at, and that says a lot because I've looked at a bunch.

The real beauty of what Jack is accomplishing, and how his libraries differ from things like the Google libraries, is that everything is in Javascript. You don't have to mess around with generating true Java classes and having to deliver to Javascript. I've avoided the Google library specifically because of this, even though there are some nifty things available in the Google classes.

So bringing it all back, the learning curve is really in understanding Javascript and its idiosyncracies, scoping, and other things like that. With Jack's library I've already implemented most of a full ajax log viewer for viewing PIX logs, for example. The alpha version of my viewer had some IT guys just in awe of how polished it is.

I will say, however, that there is a considerable lack of "how to do it" style examples available. That was probably my biggest hurdle to get over with the yui-ext library. The blog entries are great, but there are a few assumptions that are made on the examples, most dealing with the lack of documentation of how to tie it all together. The examples are good, but they don't go completely into exactly how to build a web page, which libraries to suck in, which style sheets to use, which styles require modifications in order to implement specific functionalities, and probably a lack of backend code for doing things like building a dynamic report on the backend and how to deliver that to a grid. However, once you get past these hurdles, you'll find that you'll end up with templates that you can replicate to your applications and it's all downhill from there.

Keep at it Jack, and thanks for all the hard work.

20 Dec 2006, 9:07 AM
I think that YUI-ext's documentation is excellent. The samples too are good but I feel what's missing is a library of How To's. There are too many usecases to write documentation for. There's a wealth of info and solutions to common problems in this forum but digging through them can be painful. Tips and FAQ's are scattered around too.

Having a community driven Wiki with a series of moderated HowTo's would definitely take YUI-ext to the next level. I look at AppFuse as the ideal model : http://raibledesigns.com/wiki/Wiki.jsp?page=Articles

Sometimes FAQ's just don't cut it and its much more useful to a (new) user to read through mini-tutorials to learn stuff. For example a HowTo on a 'Master-Detail page' or a HowTo on 'Editable Pageable YUI-ext Grids with a Hibernate backend' (something which I was gonna blog about anyway).

These HowTo's would address real world usecases and not narrowly focussed library / widget functionality (The API docs are good for these).

My 2c,

20 Dec 2006, 2:42 PM
Thank you for the great post. I agree 100% with the lack of documentation of the styles and how to tie everything together. In my latest blog example, I am trying to show it a little, but there was some plumbing code omitted for simplicity. It's this plumbing code that is generally "undocumented".

I think your suggestion goes along with dfenwick's observation and would help to clear up some of the "voodoo". I am still trying to find people who know enough and can contribute to building of the wiki. So far with no success.

I do try to devote as much time as possible to documentation and examples, but at the same time I do have to continue coding like a madman, doing some consulting, etc to make sure I can support my family.

This is a great thread, and I am glad it strarted.

22 Dec 2006, 5:36 AM
Well, as you may have noticed, I was very confused when I started this thread :-), and mainly because I didn't understand YUI-ext's development focus. I was starting to work with YUI and expecting tools to work with it in YUI-ext, but in many fronts YUI-ext just take its own excelent way. I was disappointed because YUI-ext shines much more than what I was doing with YUI, and in doubt if I was making a good option. I wasn't ;-). Now I'm very happy with what I achieved using YUI's utilities + YUI-ext's widgets in so short time. Thanks for your great work, Jack. Despite my confusion, I never had doubts that it was wonderful. ;-)

That said, I would gladly be a volunteer to contribute with some pieces of code and documentation in a YUI-ext wiki, and for these purposes I suggest DokuWiki (very light, easy to use, nice syntax, uncluttered and focused on documentation).

22 Dec 2006, 3:58 PM
Thank you that would be great. Dokuwiki looks perfect. I will get it set up over this weekend hopefully - depending on family commitments. :)

22 Dec 2006, 5:41 PM
If you want a wiki, I could probably get you a Confluence license (see www.atlassian.com for more info on Confluence wiki). Native J2EE wiki which is very pluggable :) We'd be more than happy to host it for you for free if you need java hosting :)

22 Dec 2006, 6:38 PM
Confluence is a much more robust option, and if time and resources were available I would go for it (licenses are free for open source projects). I think DokuWiki would fit better YUI-ext because of its lower requirements, easy customization/maintenance and general purposes. I can see a Dokuwiki install working in a BorderLayout very easily. :-) It is also extensible thanks to a big community, has a sweet syntax, is very fast and uses less server resources than most of the other engines. There is also MediaWiki, but I think it is also bigger than the needs. As you see I really like DokuWiki but, well, these are all good options. :-)

22 Dec 2006, 8:59 PM
It's set up. You should have gotten an email. Let me know if there were any problems. Thanks.

22 Dec 2006, 9:15 PM
Wow, this was fast. Everything seems to be working. Nice, thanks. :-)