Tip:
Highlight text to annotate it
X
Andrew Wooldridge: Welcome to our next talk at YUIConf 2013. I'm happy to introduce Eduardo
Lundgren from AlloyUI, and he'll be talking about reintroducing AlloyUI. Everyone give
a big hand for Eduardo.
[applause]
Eduardo Lundgren: Thank you. Okay, today I'm going to reintroduce AlloyUI.
First question I have is how many of you know of Alloy or have used Alloy before? Okay,
nice.
Just a little bit of introduction of myself. I'm Eduardo Lundgren, I'm a past contributor
from jQuery. I started contributing around 2006, and there was like a funny shift to
go to YUI. But it actually was very good. I'm going to explain why.
Then I joined jQuery UI as well, and in there I learned other frontend stuff for focusing
on widgets and these kinds of things. Then I moved to YUI.
Okay, I will start with I work for this company called Liferay and it's a business portal
company. Our product is very large and we have a lot of plugins and clients that can
plug anything they want into the platform. This is very dangerous because as frontends
we should be very careful what we provide to them in order to not cause problems for
them in the future.
In order to make it very safe we have to look to the past and see what we did and what we
are going to do. This is the first version of Liferay. This was like ten years ago. We
only used JavaScript for that version. Then it started evolving, and started having a
drag and drop interface and stuff like that.
Then we decided to use jQuery. By then we had other options. We could go to YUI 2 or
we could use Dojo or any other solution available by then. But we thought why should we use
jQuery? Everyone loves jQuery and it's the most popular project around like five or four
years ago. It's like the Justin Bieber of the web.
[laughter]
We decided we cannot go to something else, we have to use jQuery.
Then okay, everyone liked it and it was doing the job, but the portal started growing and
growing and we thought we need something more flexible. We need better architecture and
something that can be able to extend and improve easily.
Then we decided to create AlloyUI. By then YUI 3 was alpha. It was just a prototype library
I guess, but it was already very promising. We believed that and we started using it.
We had to build all the widgets we have available on the portal, we had to port them to YUI,
we had to study YUI API and do everything on this new framework.
Then we came out with this idea to create AlloyUI. YUI was the choice, perfect. They
had effects, AJAX, MVC, events, DOM, a lot of things that are nice, and then we want
to create calendars, buttons, and a lot of other components.
In order to do that we had only six months to finish. Okay, we are human, and I'm not
proud to say we had only six months. Me and the other frontend guys we worked so hard,
and then we put a lot of components out without any help for designers and anything. Engineers
cannot design, so it was a problem for them. We had a lot of components on top of YUI infrastructure.
It was very nice but it doesn't look as good as we want it to, the look and feel. Then
we came out with this website and we published it.
Then we decided to do a visit to the YUI guys. We went to Yahoo and we were very excited
because they were very excited as well with the project. We didn't know that they were
going to like it and we were very happy they said yeah, that's nice.
Then we published this to our clients as well, on the portal. We expected our clients to
have the same feedback we got from Yahoo, but actually they did the opposite, they just
wanted to stay with jQuery. Then we went to Brazil. We have a branch in Brazil. The frontends
here and there, we made a lot of plans and we thought what are we doing wrong and what
can we improve in order to make a better version of Alloy and make everyone love it and use
it?
We came out with the Alloy 2.0 in January this year. We changed a lot of things in order
to improve and to make sure people like it.
The first thing we decided to do is we wanted to make it easier to use. It was already following
all the YUI conventions, all the YUI interfaces for widgets and everything, but we had a lot
of options in our widgets. Most of them didn't have the full options in them. So we started
to analyze all of them and simplify them.
Also, the size of the project was too big. By then we didn't fork the YUI project, we
created a new project and we used it as our model. But we started adding a lot of stuff.
The project got very large, 1 gig, and to download it was 80. We were starting to make
people scared about using Alloy.
Then we decided what can we do in order to simplify that and also to make people use
Alloy very easily? We created our CDN in Alloy 2 and we hosted all our code. This file, aui.js
is pretty much a YUI seed file plus our models mapping. Then they are available in our CDN,
you can just include and use.
You can be asking yourself, why just not use the gallery? We also are in the gallery. We
have the first versions hosted there. But the second version we decided to host on our
own gallery in order to improve releases and push faster. We have plans to publish this
new version also in the gallery when we figure out what's going on with it in the future.
Also faster builder. We used to use YUI Builder, like the beginning of the YUI project. It's
nice, it did the job, but it was slow. It uses Ant in the background. So we moved to
Shifter. It's also a big change. We had to restructure the entire project with Yogi and
Shifter and it was a lot of work as well to finish everything, to restructure all the
tree and everything. It has gotten faster and people loved it as well.
Documentation also was a problem. People were asking for documentation and examples. They
didn't know how to use our widgets. Then we created this new website. It's a nice website
because it can also be used as a learning point from YUI. We have a lot of examples,
documentations, APIs. We also show the Rosetta stone there. If you go there, a lot of demos
you can click and there are interactive codes. You can just play with them.
We thought let's see if the people will like it, and they actually did. We had 1.2 million
page views this year. I think what we made for the YUI community, which is growing, they
are loving it. We are pretty excited. Also the number of stars in the project grew a
lot. It's like 700 stars in less than 8 months we got. I think we are trying to fix everything
and we are doing something that people are liking. We had 30,000 downloads.
Everything we made in this first phase was trying to fix the mistakes we made in the
past. We didn't want to do that only for Alloy and only for Liferay, we also have been working
with the Yahoo engineers and improving performance and giving back what we have been doing inside
the company inside Alloy.
I've been working with Satyen and the other guys on some performance improvements for
base. You can see the numbers. The new version of YUI has a lot of features that got improved.
Every time they released something we test on Alloy. We have a lot of tests, as well,
right now. We are running Yeti code, so every commit we run a lot of tests to make sure
we don't break anything. Because they have YUI to test inside Alloy, we have Alloy to
test inside Liferay, so we have a lot of different combinations that helps the YUI guys to test
when they do critical changes.
One of the biggest changes in my opinion was we had to redesign everything. I mentioned
before that we didn't have any design on the first version of YUI, and engineers cannot
design very well the look and feel. We needed something so we made several meetings with
Yahoo engineers trying to figure out what to do. We didn't have Pure CSS by then and
we had to pick something.
We ended up choosing Bootstrap. Don't be worried because we only used the CSS in the markup
part of Bootstrap in Alloy. This was actually a good experience because when we moved to
Bootstrap we had to think how can we extend the YUI models, how can we inject the new
information inside the YUI models in order to be able to change the CSS classes that
are being applied to the markup and to the widgets. We found that answer.
In Alloy 2 we have a lot of examples that is just extending it. One of the reasons we
chose Bootstrap is because they have a lot of themes around. We thought if we create
with the YUI JavaScript code an interface that can just plug some Bootstrap without
changing any logic in their implementation, we can just switch the CSS and we have any
theme available and you can use on your portal and on your site if you are using Alloy. We
changed the markups and the CSS classes from different widgets, also ours, in order to
support Bootstrap interface for the CSS.
One example is this gif. This is the YUI buttons being used by Alloy. The only change we made
was we augment the button classes with the new CSS class. When they fix some bug on YUI
we get this for free. You don't need to copy the code or duplicate anything in order to
have these buttons.
Another example is the overall API. The overall API on YUI is very nice. On Alloy we augmented
it actually and created a popover class. This popover, we are using the Bootstrap CSS.
The same we did for tooltips. We have the tooltips available. We also created a tooltip
delegate class which you can apply to a list, and it also uses the overall API behind the
scenes.
Tabs, YUI tabs. We didn't duplicate code, we just augmented its code with the capability
of handling these templates.
Models, and progress bars.
The result of that was very exciting for our product. The first version of Liferay with
Alloy 1 looked like that. It's not very modern. Then we thought okay, let's see after all
these changes in the infrastructure how this is going to look like.
This is the version in development right now, using Bootstrap as a CSS framework for us
and YUI and Alloy behind the scenes. Looks much more modern and more easy to backend
guys who don't know how to design to just copy and paste some markup and use it. We
are very excited with the results we are having.
Also with these changes we made on Alloy 2 we are able to extend the widgets with our
new CSS classes or our new markup. This means that we can also plug other libraries. We
have plans also to at some point try to create a branch or version to Pure CSS or any other
CSS library that makes sense.
Mobile devices were also a good thing. We had to make Liferay available to the devices
in such a way that they don't need to duplicate code. Our developers didn't want to write
code for a mobile and another widget for the desktop. We start to use as much as possible
of HTML5.
One example is let's say imagine you are in a car and you want to select a date or create
an event. In the browser you have this interface that is very nice, you can popover a date
picker, you can click. But in the car you have this mobile, the numbers are not very
big. What can be done to improve it?
I'm going to show some demos of a date picker in Liferay. This is the Liferay version running,
and this is the calendar. I'm going to add an event. This is the input field. When I
open this I have a date picker of Alloy, so I can select a date or I can select a time.
Okay, this is just a regular UI.
But when I go to mobile how can this fallback to HTML5 with the same API? It would be nice
if we can just write one code and just fallback. This is a simulator for an iPhone with iOS7.
When the phone tried to create an event it fallbacks the same code you used for this,
it fallbacks to the native inputs. You keep the same interface, you still instantiate
the widget, you still listen for the same events, but it handles the widget from the
iOS7.
Same for the time picker. Oh, it crashed my... Okay, same for the time picker. You can select
the time and it updates and fires the same callbacks in the back. So we made those changes.
We also made four other inputs natively in Alloy. You have email, date, number, and other
kinds of pickes.
Everyone says that HTML5 is the future, but it's actually not the future, it's today.
We can use it nowadays and we are using Liferay. It's a business portal, we have a lot of clients
still using Internet Explorer, but it's a reality. We create our widget in such a way
that it can fallback from native UI and also your UI that implements using the YUI widget.
We are also thinking about the future in terms of Web Components. That's something working
inside Liferay. We are playing a lot with the specifications with what they have around
in order to make available an interface for custom elements that people can instantiate
Alloy widgets from the HTML5.
We created this website called customelements.io, and you should check in there. There are a
lot of tags we are publishing and people are contributing. Because you want to learn and
we want to improve the API together with the guys that are working on this in order to
make sure we are doing the right decision when we decided to move to this direction.
Let me show you some demos from Alloy in the browser for example. If you download from
GitHub they have the folder with all these demos here.
The first demo I want to show you is the color picker. We created this widget. This is the
popover I showed before. We have a color palette. You can select a color, or you can just pick
some other color. All those widgets are available for you. This demo's out.
Toolbars is one component that is all around a big portal like Liferay. This was a very
hard one to build because imagine you create this widget and each button here is a base
class or a plugin or a widget. It's going to take a lot for your website to handle a
page with all these widgets in the page, so we created some lazy infrastructure in the
back that makes it possible.
If I refresh the page all those toolbars are being rendered in 33 milliseconds. Because
the way we are creating and plugging the infrastructure of YUI in this new version, we are thinking
a lot about performance and how to delay actions in your browser because our clients were asking
for that.
Another component is the scheduler. One client of ours wanted a Google Calendar version but
they didn't want to use the Google Calendar, so we wrote this component for them. I also
integrated the backend, which is like a scheduler component which you can navigate through the
dates. You can have different views like this.
You can create events. Let's say I want to create an event here. You can see everything
connected. This is a popover, this is a toolbar with two buttons. I can type the text here.
I can edit. I can drag and drop, I can resize. It's all connected here, and the performance
is pretty good. We use model list, data source and everything in this component.
You can go to the other views, like day. You can have the same view in the day. You can
go to the month. In the month you can create multiple events like this. It can even drag
and drop the event.
This is all done with the YUI widgets API and the Alloy infrastructure that we are trying
to create. This infrastructure that I'm mentioning, we are pretty much creating class extensions.
You can use this only without Alloy. If you want to get an overlay and augment with a
popover capability you can do it, you just need to use the model and that's it.
This is the tooltip example I showed before. The reason I'm showing this again is because
we also have some class augmentations for positioning, for example. Let's say I have
this tooltip here. When I mouse over it's here, the tooltip, this is in the bottom.
But we have a lot of times the tooltip disappears from the viewport and you have to manually
or pragmatically change that to make sure you see the content.
We have class augmentations that augment the widget position, that figures out the best
position for you in order to make sure it is still in the viewport. Let's say I make
this smaller here. The tooltip doesn't fit anymore here, so when I mouse up it goes to
the bottom. If I mouse up again it goes to the top. This is all integrated with the YUI
API right now.
We have also extensions for the resize. We have image croppers so you can get the coordinates
and crop your image in the backend.
We also made this component for our client. They asked us to create something that they
can create workflows in the frontend. Then we used the API, the graphics API from YUI
which is very powerful, to create this kind of application. This was very complex because
we had to connect divs with SVGs or any other rendering engine that is provided by YUI.
We had to connect all that and integrate like a regular web application.
This is one example of what we were able to do with the YUI graphics API. You can create
new nodes, you can click here and edit the name of your connector. You can do YUI or
something, you can change it. You can delete the connectors. If you inspect this you will
see that it's pretty much SVGs in the middle of divs and everything.
We were able to create this and it's being used by production right now by a lot of clients.
It's very stable. Because of the YUI graphics layer we don't have too many bugs. We trust
in this API. The back part compatibilities are very nice on their side.
We also created some models that I'm even thinking about contributing to the cores,
like date parsing. This component here is a date picker that you can just bind to inputs.
But you can support any languages. You can create a mask and the mask can be parsed back.
You have this date here. If you change it to like 95 it will parse to date and affect
the calendar, and supports all the languages supported by YUI right now. You can have multiple
dates like this. You can use inside a popover with a toolbar. The HTML5 fallback, if you
inspect the events that are firing here, it's firing the same event that fires with the
regular widgets. You just need to implement one time.
Same for time picker. If you type one hour, like 1:30, and go back this parses the date
for you. This also fallbacks to HTML5.
So we have a lot of news on Alloy going on. We have made a lot of changes. If you check
it one time, check it again, and feel free to ask me some questions or send me a Twitter.
I have a lot of stickers for Alloy. If you want some I can give you, just talk to me.
That's pretty much it. Thank you guys.
[applause]
Andrew: Okay, we have about eight minutes for questions, so anybody have any questions
for Eduardo?
Audience member: You mentioned before that the size of the framework you built on top
of YUI used to be really, really big. What's its size now, even if it's hosted? What's
the size of the framework?
Eduardo: Yeah, the size now, if you go on the repo is not 1 gigabyte. I think it's around
18 megabytes, 15 megabytes.
Audience member: So that's a lot smaller.
Eduardo: Yeah, it's a lot smaller, yeah.
Andrew: What was the main thing that helped reduce the size?
Eduardo: It was a lot of decisions we made in the past that was not appropriate. We also
have a Java version of Alloy. We have a lot of tag libs generated by the documentation
from the JS docs. Those tag libs had generated JARs and we were committing a lot of things
that were not supposed to be there. That was one of the biggest reasons.
Besides Shifter, Yogi, boilerplate code that it generates is smaller than the one required
by YUI Builder, a lot of XMLs and stuff. So a lot of different combinations.
Andrew: Do we have any more questions?
Audience member: Hey, great presentation.
Eduardo: Thank you.
Audience member: What's your plan on creating new modules that are supported on mobile?
Even though you showed us a couple of components that are already supported on mobile, I would
like to know what's the plan on that route.
Eduardo: Right now we are beginning the low level components, like date pickers, inputs,
layouts, that part we are trying to support mobile. But we have plans to support more
high level. So for example this scheduler, or the date picker, we want to make sure even
if you want to render them into the mobile we make them responsive. We are already working
on that. You can actually see, if you load them from the mobile you can see they are
partially already responsive.
Our idea is to make anything that we render, like this scheduler, they have a lot of rows
and columns, we want to make sure everything fits well in the mobile. My answer for that
is we will try to make every widget we provide somehow supported on mobile.
Andrew: Awesome. Well everyone give a big hand for Eduardo, and thank you very much
for coming.
[applause]
Eduardo: Thank you. Don't forget to get your stickers.