AlloyUI – a framework built on top of YUI3

YUI gets a bad rap because of YUI2. YUI3 was a ground-up rewrite that addressed all of the overkill from 2 and them built an awesome library that includes things like modules and models/views, as well as things you expect like DOM, really great custom events, animation, etc. It's a really great foundation when you are building a complex JS-driven application UI. Having worked in front-end development since before there were JS libraries, I almost never choose anything else. JQuery has a lot of the same stuff now via 3rd party libraries, but often I've seen the production schedules of those various 3rd parties lead to cases where you need a newer version of one but can't upgrade because it would interfere with another.

YUI3 also forces you to use at least the basics of good coding patterns and practices, where jQuery gives you nothing in that regard. My experience with the average designer/pseudo-developer person who is writing JavaScript is that they can use a bit of handholding when it comes to crafting maintainable code on projects.

Thanks for compliments and questions. To answer (I tend towards the loquacious, so forgive me): > * 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)?

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

JavaScript-wise, all of our modules are segmented and only attached to a YUI instance, so there won't be any conflict between us and any other library (we don't create globals, we don't modify host object, etc).

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