AlloyUI – a framework built on top of YUI3(alloyui.com)
alloyui.com
AlloyUI – a framework built on top of YUI3
http://alloyui.com/
23 comments
Oh, yes, the Liferay UI library built on top of YUI. I avoided it like the plague when I had to work with Liferay.
Hey guys, Eduardo and I started AlloyUI at Liferay back in 2009.
I'm sorry to hear about your experiences, and I completely understand. When it was just the two of us, in addition to handling the entire UI for Liferay, we also wrote 60 components in a few months, so we were pulled a little thin.
We have since expanded the team, and we've made a lot of improvements in both the documentation as well as the components themselves.
If you have a chance to check out the site, or play around, we'd love to hear any feedback :)
If you have a chance to check out the site, or play around, we'd love to hear any feedback :)
Hi Nate, this looks really useful, thanks for your work on this, and for releasing it.
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.
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.
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.
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.
"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."
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.
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.
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 :)
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 :)
Thanks for your very detailed response!
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 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.
Sure thing, that shouldn't be a problem at all :)
I'll check and see where the bulk of the work is currently at. Go ahead and shoot me (@natecavanaugh) a message on twitter, or to Iliyan (@ipeychev) who wrote the code for it and would know where to pull down the relevant files. There might have been a pull request for it at some point, but I can't recall if it was for this or a different component.
I'll let you know though :)
Thanks again!
I'll let you know though :)
Thanks again!
Same here, at the time they hardly had any documentation, not sure how the situation improved.
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.
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.
totally agree with sheldon's here.
Wow this library looks great. Some of the widgets like the image cropper and schedule look amazing. Thanks fot he post.
Edit: Wow, I really like the diagram builder. I've been looking for something like this for almost a year.
Edit: Wow, I really like the diagram builder. I've been looking for something like this for almost a year.
I expect to see more from a UI library, instead of a bunch of "would be cool to add" modules. When you use a UI library in your project you somehow get married to it. For everything that UI library doesn't provide you have to use other libraries, then it becomes a mess.
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.
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.
Which libraries do you find to be "complete"? Just curious
[deleted]
Most of these widgets already come bundled with Bootstrap (http://twitter.github.io/bootstrap/javascript.html) and it's done better; see http://alloyui.com/examples/button/, for example, you get a checkbox then it's converted to a button after being displayed for a brief period.
I overall agree that bootstrap seems to cover most of these controls in a better way; that said, I think AlloyUI has css3 buttons that don't exhibit the 'loading' effect you described [click on css3 tab in the link you gave]
Are there some extended examples? I'm not quite sure whether this is closer to JQuery UI (i.e. some widgets for normal web pages) or ExtJS (desktop-like Intranet apps). Looking at documentation for e.g. the DataTable, it seems it's closer to the former. (Where I wouldn't be looking at YUI3 right now, as compared to e.g. Angular or Ember. I would be "in the market" for a decent enough ExtJS replacement though...)
You can look at the YUI User Guides[1] for more in depth documentation of the components that AlloyUI shares with YUI.
[1] http://yuilibrary.com/yui/docs/guides/
[1] http://yuilibrary.com/yui/docs/guides/
I've never used seriously used YUI, but this actually seems like a really nice library. I'm impressed with the breadth of it. The Rosetta Stone is also a great idea which really takes away a lot of the fears of using a different library.
+1 to the rosetta stone. I'd love to see more libraries including something like that.
The breadth of this library is really remarkable. It feels slow, though.
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.
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.
YUI and Alloy actually have a few tools that help you write snappy interfaces.
1) The loader[1]. 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[2], a very light and fast template engine similar to Underscore templates.
[1] http://yuilibrary.com/yui/docs/yui/#dynamic-loading-with-use
[2] http://yuilibrary.com/yui/docs/template/#using-templatemicro
1) The loader[1]. 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[2], a very light and fast template engine similar to Underscore templates.
[1] http://yuilibrary.com/yui/docs/yui/#dynamic-loading-with-use
[2] http://yuilibrary.com/yui/docs/template/#using-templatemicro
3 years back, when we had to use it with Liferay, the experience wasn't really great. Hope it has improved now; need to check.