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.

Write a blog post too!

Write a deep dive into how you use Liferay projects in your technology stack. Or let people know useful tips and tricks for a particular functionality. The Liferay community needs you!

Login or Create an account