If you have a chance to check out the site, or play around, we'd love to hear any feedback :)
I've got some questions, if you've got the time...
* Why YUI? When I think of YUI, I tend to think "overkill". Obviously you've done a ton of work on this since 2009; is there anything you couldn't have accomplished building this on top of jQuery (just as an example)?
* Does AlloyUI play well with others? For instance, if I wanted to incorporate one or two of your widgets in a UI built on top of Bootstrap or Foundation, would I run into trouble? What of MV* frameworks (Ember, Angular, etc.), or just plain-vanella jQuery?
* Testing this out on an iPad I found that some widgets seem to work well (calendar), but others (photo crop) not so much. Do you intend to target touch devices?
* You have a code editor, and a toolbar that seems intended for a rich text editor, but I don't see a rich text editor included. Do you have plans to add a rich text editor? Especially because YUI3's rich text editor is very limited out of the box, this would seem to be a great addition.
this is long solved.. i read your post twice and if you take this statement away, your argument for YUI seems to unravel. The statement also seems to demonstrate you think it's YUI vs jquery which is not an interesting comparison.
I'm interested in a pro-YUI argument when compared to Backbone, Knockout, Ember, Angular, ExtJS, etc, in the context of "enterprise intranet" apps. In my particular case we need to be able to work with arbitrary markup and widget toolkits such that our design team has minimal constraints due to stack choices, but I'm also interested in the case where the design team is able to be constrained, if that makes the argument easier.
We get this question alot :) We (Liferay) actually were based on jQuery from 2006-2009. We had even hired Paul Bakaus full time in sponsoring jQuery UI, Eduardo was also a contributor (and I had done a website design for the jQuery website around early 2007), so we were pretty big fans (and still are to be honest).
Our biggest frustration was mainly with the slow progress in building components with jQuery UI. There were at the time a lot of components missing. We looked at a couple of different libraries (dojo, Sencha/ExtJS, etc), but we also looked at YUI3, which was in developer preview at the time, and the thing that impressed us was the Widget layer, the much easier DOM/event layer and the lazy loading capabilities built in. The YUI team itself, and their long history of awesome documentation, involvement with their users, and their plans for YUI3 also influenced our decision.
To your question specifically though, what we loved about YUI3 was just how lightweight you could go. Basically, the seed file itself is ridiculously small, so if you only need a piece or two of functionality, you don't need to run a giant library.
In Liferay, we have an environment that is run normally in enterprises, but it's used for everything from public facing websites, to intranets, etc. An installation can have any number of applications with their own set of dependencies, so we wanted a library that we could easily scale in each direction.
Also, we had situations such as third party developers wanted to run different plugins that shared the same name (for instance, sortable). YUI3 has built in sandboxing, so you could have two instances running different modules with the same name, co-existing on the same page.
The thing I think YUI doesn't get nearly enough credit for is their lazy loading and combo loader. There are a lot of lazy loaders out there (requirejs, labjs, etc), but the thing that has frustrated me has been the fact that for production, you're encouraged to run a build script for production to combine all of the files.
However, in our platform, we have multiple apps that may or may not be on the page, plus plenty of dynamic pages that may or may not be visible depending on permissions, etc.
So we had situations where we had to keep adding modules to a growing public seed file for plugins that might only be visible to 10% of users.
YUI's loader instead analyzes what modules are already on the page, and fires off a single request for the rest of the modules it doesn't have.
There are things I miss from jQuery (I really do think it's DOM/Event API are the simplest and best around), but ultimately, there are always those tradeoffs around complexity, performance, and developer power that need to be weighed.
> * Does AlloyUI play well with others? For instance, if I wanted to incorporate one or two of your widgets in a UI built on top of Bootstrap or Foundation, would I run into trouble? What of MV* frameworks (Ember, Angular, etc.), or just plain-vanella jQuery?
As an FYI, AlloyUI 2.0 is actually built on Bootstrap as well (for the markup/CSS portion, not the JS :) - our modules use Bootstrap markup and CSS).
So you shouldn't have a problem with running Bootstrap. I'm not sure how compatible Bootstrap and Foundation are (personally, not a big fan of Foundation's presentational class name's such as "radius" and "round", so I don't play around with it much).
The only problem we've ever run into is when people want to run Prototype or some similar library where they're modifying the host objects, and it causes our modules to break. But if we had to, we could still get around it.
> * Testing this out on an iPad I found that some widgets seem to work well (calendar), but others (photo crop) not so much. Do you intend to target touch devices?
Touch is something we're actively working on improving. YUI has a lot of great built in stuff around touch, but our ultimate goal is to optimize the interaction of the individual modules for the specific devices (which is where the YUI loader comes in handy, because we can selectively load JS modules depending on the device/browser).
> * You have a code editor, and a toolbar that seems intended for a rich text editor, but I don't see a rich text editor included. Do you have plans to add a rich text editor? Especially because YUI3's rich text editor is very limited out of the box, this would seem to be a great addition.
Within Liferay, we actually have done a lot of work around the rich text editor, because we have been wanting to use it for a long time to replace our use of CKEditor.
However, after a lot of work on it, we realized that it's not quite ready for what we wanted.
It's amazing for a basic editor, but we wanted to add inline contenteditable support, improve the accessibility, etc.
We ended up using CKEditor 4, since it had all of the stuff we wanted built in (and the performance and UI was much improved). Building a decent rich text editor that is supported cross-browser and accessible seems like an easy task to talk about, but it's pretty herculean and requires someone focused on it full time.
We are planning on submitting our existing improvements to YUI, but depending on their plans for it, I'm not sure when it will make it in.
Long term, though, we are interested in building out the YUI3 editor to being a contender.
Hopefully that helps answer more questions than it raises, but if it does raise more questions, feel free to ask away :)
I do have one additional question: would you all consider releasing the work that you have done on your YUI3-based rich-text editor, even if it isn't production-ready?
My team has been working with CKEditor for the last couple of years, and we find it pretty frustrating. So much so that we are debating switching to the YUI3 editor, even if it means much more work. We haven't experimented with CKEditor 4 yet, though. Regardless of what specific path to take, we plan to replace our rich text editor in the comming months.
It would be very interesting to see a viable alternative to CKEditor and TinyMCE emerge, and we would definitely consider contributing.
I'll let you know though :)
We ended up using basic JSPs or servlets, depending on the portlet use case, with the bulk of UI done with jQuery and custom components provided by a designer company.
Edit: Wow, I really like the diagram builder. I've been looking for something like this for almost a year.
For this reason I refuse to use a non-complete library (where as lots of UI elements are missing such as this one). If I'll have to fill the missing parts with other frameworks I won't use it at the very beginning.
I think people underestimate the importance of a snappy fast interface. We use bootstrap + handlebars and get really fast response, at the cost of having to build a lot ourselves.
1) The loader. The ability to load modules on demand help a lot with reducing the initial kweight of your page. The loader supports very easily concatenation of scripts which has a huge impact in perceived performance. It also does conditional loading, which means that it doesn't load compatibility code for old browsers when it isn't necessary.
2) You also get the flavor of templates you like. They come bundled with Handlebars and Template.Micro, a very light and fast template engine similar to Underscore templates.