The future of UI Development and AlloyUI in Liferay 7

Since my last blog post, I have gotten quite a few emails and questions about what the future of front end engineering looks like now that Yahoo has ended new development on YUI.

What I'd like to cover here is a general overview of where we've decided to go and the reasoning behind the direction.

After much thought and discussion, we've decided that AlloyUI 3 will be our final release that is based upon YUI. However this does not mean the end of AlloyUI at all, but is in fact an exciting new chapter.

We have decided that we will be changing our underlying DOM/ajax/animation toolkit to using jQuery. For areas where jQuery doesn't have coverage, we will either leverage third-party libraries as much as possible, or when those are not sufficient, writing and maintaining our own components (about which, I'll go into a bit more detail later in this post). This set of UI components and utilities will be exposed as jQuery plugins, and will comprise AlloyUI 4.

Naturally, there are some questions, but the first one I'd like to address is:

What does this mean for code written with AlloyUI in Liferay 6.2?

For Liferay 7, we will be using AlloyUI 4 and also bundling Alloy UI 3 for backwards compatibility (which can be opted into by setting a property on your portlet, or if needed, included from your theme). This will behave as it has and the code you've invest time into now should work as it did previously. While AlloyUI 4 will not be backwards compatible with AlloyUI 3, they'll be able to safely co-exist within the same page.

What if I'm already using jQuery in Liferay 6.2?

You are also safe going forward, and in Liferay 7.0, you will have many benefits since AlloyUI's components will be exposed as jQuery plugins.

AlloyUI 4 Overview

From a high level, our goals and plans for AlloyUI 4 are to have a strong focus on the needs of modern web development, both in a portal context, and from a general web development context. Things such as mobile-first web development, single page applications and modular components.

There are also a lot of exciting things coming into JavaScript with the ECMAScript 6 specification coming closer to a reality, and we want to help enterprises leverage these new features as much as possible.

Some history (a.k.a. "Didn't you guys used to be based on jQuery?")

Eduardo Lundgren  and I started working on AlloyUI over 5 years ago. At that time, there were shortcomings that we bumped into within jQuery and jQueryUI, and there was a dearth of options for building enterprise applications within the jQuery space. Since then, jQuery has not only filled in many of the issues we had, but it has also become the de facto API of the web.

Even other DOM/ajax/animation micro-frameworks have implemented the jQuery API, and even many specialized libraries, such as d3.js or RaphaelJS have adopted jQuery-like APIs.

Also, the general front-end ecosystem has grown quite a bit since that time as well. Utilities such as LoDash, or Underscore have stepped in to provide common and useful functionality. There is a plethora of MVC/SPA frameworks (and while AngularJS sure has a lot of momentum, Backbone, Ember, and Knockout are still going strong). CSS frameworks such as Bootstrap (which we started leveraging in Liferay 6.2), Foundation, PureCSS, etc., have gotten a lot of traction and maturity, even in many cases including their own set of JavaScript components based on jQuery.

Basically, for a wide range of UI infrastructure pieces, there are a lot of options out there, far more than was the case back in 2009.

How does AlloyUI 4 fit into this ecosystem?

YUI was great because it provided multiple options under one library, with a consistent API and a shared set of foundational utilities and components.

What we want for AlloyUI is to leverage those best of breed options wherever possible, and focus on providing value to our Liferay customers where we feel we can contribute to most.

Not all of these third-party frameworks will fill our needs, or they may not be of the enterprise quality that we expect and our clients demand. We can provide value in these cases by either contributing fixes or enhancements to these libraries, or, if they're not interested in accepting those, in still providing those to the community at large.

There are also some areas that are not covered at all by current libraries. For example, while lazy-loading of JavaScript has become quite popular, there is still nothing at all like YUI's Combo Loader, which dynamically lazy-loads modules. These sorts of enhancements we can write, and provide them as plugins that work with third-party libraries, rather than re-inventing the wheel.

We also want to provide the components we create in a much more modular way, so that people can leverage them individually as well.

Overall, while there are still a lot of details that we need work out, and a LOT of work to be done, we are quite excited about this direction.

As we flesh things out, my aim is for the team and I to blog as much as we can about the decisions and how they may affect you and get feedback from you.

So with that, I'd like to thank you all for your support and passion. If there's anything we can do, or think we should do, please let us know.

Hey Nate & team, great news for our community, mainly because you were able to come to a decision quickly emoticon AUI provides a good abstraction layer, and everyone can use their jQuery fu to continue to do cool stuff.. Looking forward to seeing it in action!
Hey, wait a minute... The 7.0 M1 came out like a month ago. How are you going to backfit all of this work into the 7.0 release?
Hi David,
The milestones are always in progress and meant to show new features as they arrive. Our plan of attack is to keep AlloyUI 3 in place, and migrate individual components and/or portlets one at a time to the new infrastructure. We go as small as we can for each change, until we have no more internal dependencies, and then we will remove AlloyUI 3 from being included by default.
So during the rest of the milestones, both will be included for a time until we are finished migrating.
We've actually done it before when we moved to YUI, except back then we had only Eduardo and I, and had to write 60 components in 6 months on top of YUI3 while it was still in the Preview Release stage (so the API was shifting quite a lot).
This time around, the scope of work is a little bit smaller, and the team much bigger, so while it will be quite an undertaking, I don't think it's impossible at all emoticon
That's good news indeed. emoticon

Is there a release roadmap for Liferay 7.0?
Great news for Liferay UI development..... AlloyUI 4, jQuery based....mmmm
I can't wait!
Nate and team, thanks for your careful and graceful consideration of all the feedback. It's never easy when what feels like mainly a technical decision gets so much attention. I think this will be a good decision for you, Liferay, and the community. At least until the next major event that none of us control.

Unlike David, however, I suggest you relax with a coffee/tea/beverage of your choice. Then get to work ;-)
Awesome news!
Good luck with all the hard work a head and we are looking forward to see the AlloyUI 4 with jQuery.
Good news!! :-) But what version of jQuery are you going to use? If jQuery 2... this means you'll finally drop support for those terribly old versions of IE? I like it! :-D
Great news. Liferay 7.0 will be rocking.
Thanks to Nate and team for quick decision. emoticon
Since beginning, I was wishing to have JQuery instead of alloy UI. This is good step to make Liferay more popular. It make Liferay(Java) developer's job easy. Waiting how quick this can implemented.
I can confirm and add 2 further points regarding UI components in Liferay.
End of YUI and "reorientation" of Liferay UI gives the possibility to solve 2 very important "problems" which we always had:

1. please don't "cement" UI Libraries in FrontEnds like in LR 6.2 where aui is fundemental - in other words we need a clear frontend - use special libraries only element which needs them e.g. dockbar, not the whole frontend

2. UI components should be easily customizable fro custom designs and in history for us it was always a big problem to change the design of the alloy ui widgets, it is much easier to make custom design on jquery widgets
Hi Seref,
Could you clarify what you mean for me?
I'm not sure what you mean by "cement"-ing UI libraries. AlloyUI is needed specifically *because* the individual components rely on it, so any library we use will still function that way.
For instance, in order to support users dragging and dropping of portlets or content, we need a drag & drop library, DOM, manipulation, etc.

I could be misunderstanding what you mean, but could you describe the problem a bit more, and maybe what you perceive as the solution?

Thanks Seref,
Hi Nate,

what i mean: problems like this:

It should always be easily possible to take a normal styled page and port to liferay theme. without any side effects or conflicts.

I have a standard static BootStrap 3 -Theme.
Copy the needed lines 1:1 in the Liferay-Theme Skeleton files e.g. portal_normal.vm and it should be run without any conflicts.
Your "DropZone" css-selectors should be only put explicit to elements where they are needed, also Dockbar related css.

Regarding the usage of aui elements, the frontend designer should also be able to activate aui integration or not - but in 6.2 aui is put e.g. to the root <html> -tag, not only on elements which really need aui.

If you will be in Liferay DevCon in November in Germany maybe we can talk about this individually.
Hi Seref,
Thanks for including that link. I've gone ahead and replied to the forum thread, so you can read a more detailed set of questions, but I can also add some direct ones for you here:

In your usecase, you technically could upgrade to Bootstrap 3, however, there will be those conflicts.
What you're describing as far as placing the aui namespace only around what's needed, there are a couple of possible side-effects:
This may mean entire portlets are wrapped with the aui class, however, because those portlets often rely on some aspect that's covered in bootstrap (for instance, buttons, or icons, tables, etc).
But it also means that if you want to style those applications to match your theme, you'll need to do extra work to overwrite those styles.
This also means that you would have two versions of Bootstrap running on the page, and the styles from Bootstrap 3 could very well leak into those components that are relying on Bootstrap 2.
Also, there's the consideration that the upgrade from Bootstrap 2 to 3 was far more than just styling, as they changed the HTML layer quite a bit as well (from class names to the structure of some elements, and completely eliminating others).

Do you have any thoughts on how this could be resolved? If there is a way that we can give you what you want, or find a happy medium, I am 100% on board.
But in the scenario you're describing, I can't envision how it would happen.

BTW, I will be at the Devcon, so we can definitely discuss more there. However, I am also interested in furthering this conversation here or in the forum thread, if you're willing emoticon

Thanks Seref,
I would like to also ask that internal js functionality be fully documented. For example in 6.2 liferay-navigation-interaction module. It wasn't very clear what actually was needed in order to have drop downs and add your own custom mobile navigation toggle button outside of the dockbar.

Also if Liferay 7 is paired with Twitter bootstrap 3 could the class names not be hardcoded into every JSP. Instead create a hook that replaces place holders in JSP. That way hooks could be created for PureCSS, Foundation, etc frameworks. Liferay likes staying technology agnostic for the back-end it would be nice if it was that way for the front end.
Heya Brad,
For the first point, I agree with you, and it's something we're currently working on.

For the second point, that's actually not really feasible. On the surface it sounds like it could work, but across those libraries, it's not just the CSS classes that are different, but both the HTML structure and the feature sets are all different.
For instance, consider an input group (which you can see here: Here is a comparison for how you would implement it in both Foundation and Bootstrap:
Also, consider that PureCSS doesn't even have this functionality.

While technological agnosticism sounds great in theory, it rarely ever works out well. What ends up happening is that you're limited down to the lowest common denominator of features that are supported by everything you're trying to support.
If you have any other ideas for how it might be accomplished though, I'd love to hear them.
Thanks Brad emoticon
I've tried several times to add a navigation toggle button to my navigation. Here is the code I've tried

I usually end up having to disable the liferay-navigation-interaction js module because it throws errors.

I've noticed that other nav toggles in the portal have data-navid="" attribute to the anchor tag. It didn't seem to work so in my above code I toggled the open class.
Hi Nate,

here you can find a little description about what should be the normal use case:

Some more words describing the image in the link:
- there are two main different "roles" regarding theme development
a.) Designer ( External Agency / Partners ) which have no know how about LR, they also have no idea about potential conflicts, they only design the static website
b.) Liferay Developer: is always interested to "integrate" the static designed website to a Liferay Theme Project, mostly Liferay Developer has not the know how to design the theme as a.)

As a result of a.) there will be a static website with its own css, js, html, media.
The Liferay Developer wants to integrate this result of a.) without changing one line in css / js - but he is also interested that after integration without changing one css and js line, the dockbar and all screens which can be called from dockbar still work out of the box. Important: He is not interested, that after integrating 1:1 the static website, that the dockbar show the customized icons / buttons. The dockbar should be available in LR Standard Design. The customization of dockbar should be separated, the css of the static website should not have any influence on the dockbar. The same is valid for the placing of portlets. The LR Developer only integrates the places for the portlets, contect menus, drag and drop should also work out of the box.

Regarding the usage of LR developed UI components based on Alloy UI / Jquery:
The aim of this components should be to make the life of a Liferay Developer easier to develop own portlets. He CAN use the elements for developing own portlets, so the needed libraries should only be referenced if he is going to use this easiness.
Beside this, its clear that these LR standard UI components will also be customized regarding the design to be usable for the own platform. And who should design it ? The same guys who already designed all elements of the static webpage. For example we were interested to make a catalogue of already existent LR Alloy UI components designed with our specifications, so that our Liferay developers can use LR Ui widgets customized in design to develop portlets which are already in our design. The porlet developers should not be thinking of styling widgets which they want to use easily for the development. The widgets should already have the right design.
To give any idea how to solve such issues normally we need a general overview about all use cases.

But if we say, that what i was written before is the "normal" maybe this would solve a lot issues:

- to prevent CSS conflicts Dockbar CSS selectors and element ids should have own "namespace" or special sleectors - no usage of any general selector
- in every portlet what the developer is going to develop, he should configure whteher he will use Liferay UI components based on (AUI, Jquery) and only if he is activating this feature, the necessary classes and libs will be load, and only in the "scope" if the portlet - for example every porlet project has already the right structure where you can put your own custom css and js files, so if user is activating support of Liferay AlloayUI/Jquery components, the needed css and js files could be generated into this skeleton when creating an Liferay Portlet Project.
- there should be a central css, js file and a plain static "sandbox" html-file with all Liferay UI elements --> these files can than be given away to external agencies which can design and test the elements without the need of Liferay Know How. After finished the only thing the Liferay Dev or Admin shoulöd do is, to overwrite the existing with the new one.

Maybe some of the ideas are "silly" because i have not the whole "image" of the UI-issues on Liferay side. As i told ebfore we can discuss at DevCon.
Hi Seref,
Thanks so much for the detailed response. I agree with you about the common use case of agencies or third-party designers with no knowledge of Liferay's functionality designing a site, and an implementor/integrator connecting everything together. I wouldn't say it's the most common case, but it's definitely common enough that I would like to make it as easy as possible.

One point you made was that there should be a central CSS, JS and HTML file with the Liferay UI Elements, and I completely agree. In fact, we're working on something right now that is a combination of UX Guidelines, UI Reference, and an HTML/CSS API. As soon as we have it ready for external consumption/feedback, I'll definitely do a blog post emoticon

On some of your other points, there are some really big challenges, but I'll try to briefly respond, just to give you something to think about (as maybe you have some ideas), and we can discuss more either here or at Devcon.

In your other comment you said: "The customization of dockbar should be separated, the css of the static website should not have any influence on the dockbar."
This really depends not so much on Liferay, but on the quality of the CSS implementation for that static site.
Static sites often add their own type of CSS reset, such as '* {margin: 0; padding: 0;}' or even more complex ones, and their styling depends on that relationship.
However, similarly, our styling depends on the reset we use via normalize.css.
There is an inherent conflict here. We can't guarantee that the dockbar will be styled correctly if someone has implemented CSS that targets things in an aggressive manner.
A similar issue is when people use JS libraries that follow bad approaches, such as Prototype.js or MooTools, both of which modify the native host objects, and sometimes with an API that's different from the standard.
In those cases, the person who is taking the design to the HTML/CSS/JS implementation needs to know something about the environment they're deploying to, as well as general best practices.

- to prevent CSS conflicts Dockbar CSS selectors and element ids should have own "namespace" or special sleectors - no usage of any general selector
Regarding this point, we generally do this everywhere. We very rarely get too general outside of a specific component.
We may do something like: '.dockbar > div' (as an example) but we scope it, so that any general selectors are only applied within that structure and doesn't leak out to affect any other elements.

You also mentioned this:
"- in every portlet what the developer is going to develop, he should configure whteher he will use Liferay UI components based on (AUI, Jquery) and only if he is activating this feature, the necessary classes and libs will be load, and only in the "scope" if the portlet"

This is an interesting idea, and we've discussed variations of it in the past. Here are a couple of challenges:
1. Duplicating the libs into each portlet will quite quickly become a performance nightmare.
If every portlet had a copy of jquery.js for instance, there would be a reference to each one under that portlets context, which would load the same libraries multiple times, but under a different path, so even if the library is the same version, it won't be cached for any other portlets to load.
2. There's no easy way to sandbox CSS, short of adding some sort of namespace around all of the CSS, and even this has it's own drawbacks.
3. This also has some other possible side-effects or considerations. For instance, a large number of the taglibs leverage AUI components and/or rely on base styling being provided by Bootstrap and the Liferay theme.
In this case, many developers would not consider this using AlloyUI components, but it would implicitly require their support.
I can see in cases, such as if you're using another development framework, such as Vaadin, or a JSF based approach, you may not even need Liferay taglibs, but many developers do leverage them, knowing the goal of the taglib, not necessarily the underlying implementation.

I'm not saying it's impossible, only that there are some challenges to consider, and maybe there are some solutions that we can come up with that can work around these.

To digress a little bit, I have been long considering if the underlying use case is flawed.
This is just thinking aloud, but it seems to me that there is a flaw in the workflow where the designer and implementor don't understand the environment they're building for.
This is similar to me like when a print designer is tasked with designing a website, but has no experience with websites.
Inevitably, what is created is a brochure for the web.
Or similarly, if a designer is tasked with designing a mobile app, but doesn't know which OS it's for, or what the strengths and weaknesses are of that platform.
In all great app designs, the designers and engineers work closely together to build something amazing.
Every medium has it's own challenges, and it's own strengths, and in order to design appropriately for it, they need to understand those constraints.

So a part of me wonders if this workflow is a part of the problem.
However, that all being said, I'm pragmatic enough to realize that for good or bad, it's incredibly common, and I would like to do whatever we can to help minimize the downside and maximize the upside of leveraging this workflow.

Hopefully, having clear guidelines and recommendations will help this, though I'm not sure how common in that workflow it is for the designer/agency to anticipate that they're building something on a platform with guidelines vs. just deploying a plain static HTML page.

Anyways, that's just some thoughts I've been thinking about, but overall, I really like your thoughts on this, and am looking forward to talking more about it with you at Devcon.

Thanks Seref emoticon
Hi Nate,

as I said, I have not the whole "overview" about the use cases and constellations regarding the theme - it's always same, building a speial solution for a special use case is always easier, as creating a solution for several use cases and combinations.

I described only the "minimum" use case and it is good to hear, pardon to read ;-), that you'll try to make this easy as possible.
And I also think, that some of the "problematic" points only exists because both sides ( "non-LR-know-how-designers" and LR developers ) are not informed enough ( e.g. documentation, specs ... ) ... just in this moment I am asking me, is there any "white-sheet" or "black-sheet" with general specifications available, what designers should do or should not do.
For example: if we say that some points are depending from the quality of the css of the static pages designers made with no Liferay know how, we should be able to give them a whitepaper with guidelines and restrictions regarding e.g.non usable css selectors and so on .... i think this will also help to prevent conflicts when transferring theme from the static world into the liferay world.
Moving back to jQuery is Good News for the entire Liferay community. I am looking forward to Liferay 7 to create some cool themes based on bootstrap 3 and jQuery.
Hi Nate,

Great New emoticon
It will take lots of time and effort to migrate all AlloyUI >3 Componat to AlloyUI 4.
Can we crate branch on git for AlloyUI 4 and Ask community to convert it in to JQuery as I am interested in that to migrate module/component to jQuery?

Do you have any document to crate AlloyUI 4 Module/Component ?

Really good new that adopting jQuery. Since last 3 years I am using AlloyUI/YUI now it's time to use jQuery.

Yatin Patel
jQuery is the Justin Beiber of JavaScript world. Heard that at the symposium today. Also change is the only constant in this ever evolving tech space. Can't wait for lr7.
any chance to have a preview of alloyui 4.0 in liferay 6.2.2 ga3 (I guess its release date is before liferay 7.0)
AlloyUI has reached version 3.0,
You can use this version in Liferay 6.2?
If yes how?

Or will be integrated in another Liferay version ? (6.3.x ...)
Or ... AlloyUI 3 will never be released with Liferay ?
We have started the migration of the portlets to use AngularJS and did some initial POC also. What would be the future of Liferay 7.0 with respect to AngularJS ?
This is a good reading, very important to keep in mind. But please could you tell if this will affect the Liferay MVC? Like, we will be able to use something different than alloy.liferay to pass parameters clearly from the JSP to the Action? or.... Are we going to be doomed to develope using Spring portlets? emoticon (kiddin bout the dooming thing)