Tip:
Highlight text to annotate it
X
[applause]
Caridy Patino: Thank you. Thanks for coming tonight. We wanted to give you a little bit
of introduction about Axis. Specifically I will be talking about some of the design decisions
that we made along the way, some of the things that we learned as a team, and also some of
the feedback that we provide back to the Cocktails platform. We will talk a little bit more about
that.
I wanted to start with Axis. Codename was SearchX – still we are trying to change
our mind and the name, so maybe I will mention SearchX along the way. Personally, I had a
lot of fun creating this application and this product. I think the team in general enjoy
a lot being able to work on a project that from day one was set to be deployed for mobile
applications. It’s kind of being able to deploy these into different type of screens
and so on, so for our team it was the first time to work on social projects, that kind
of project, and changing this mentality into more like mobile first. It was kind of fun
in general. We learned a lot during the last year, so it took around a year to pull all
these together.
From day one, one of the things that we wanted to do is to avoid using any kind of desktop-like
framework, or frameworks that were meant to be used in desktop, were created for desktop
applications, because we wanted to create a mobile application. It’s kind of difficult
to start using a technology that already has a huge technical debt when you look at it
from the mobile perspective. Imagine that you tried to just re-use whatever we have
in search – and we have a lot of technology there, we have a lot of platform and pieces
that we can potentially re-use – but using those pieces means that we are going to start
from scratch having a huge technical debt from the mobile point of view. It’s kind
of difficult to start from that perspective. We wanted to start from scratch by also looking
into mobile platforms and mobile products that were built at Yahoo! or outside Yahoo!
to try to use the technology that suits the most for this kind of product.
We decided to get involved with the Cocktails folks. They’re around there. We started
looking into the Cocktails umbrella. As Ryan mentioned, Cocktails is not a product, it’s
not a project, it’s a set of products and platforms that you can use to create these
mobile applications. Let’s talk a little bit more about Cocktails and some of the products
and platforms that they offer today, and also the fact that Cocktails is becoming the de
facto platform for mobile applications at Yahoo! and hopefully outside Yahoo! in the
near future.
As part of the Cocktails umbrella, the first project that is probably more close to our
area is the Mojito Application Framework. It’s a JavaScript application framework,
and it was built on top of YUI. At Yahoo! we all, in the frontend engineer area, we
all use YUI for a long time, and we have been evolving at the same time that the library
has been evolving, so we know a lot of stuff about YUI. We are comfortable using YUI in
our projects, so it was easy for us to just go that way because of that single thing.
But not only that, it also used Node.JS as the platform to run Mojito applications in
the server side, and we will talk a little bit more about that. But you know, Node.JS
is new technology, it’s fun to use, people really enjoy to hack into it and, in general,
it has a lot of potential to become a major platform in the future. We really want to
get into that kind of project where you use this kind of new technology. Also, it uses
Express to do pretty much the on the line serving for static assets and so on. In general,
it’s a composition of open source projects.
The other project that is under the umbrella is Manhattan, and for now I will just say
that Manhattan is just a hosting infrastructure for Node.JS applications. Hopefully we can
share more about Manhattan in the future. I will just give you a snap pic of what Manhattan
looked like from the server side stack perspective. You just have Manhattan, some Node.JS V8 to
support the JavaScript that runs in the server, and then a bunch of other projects that are
open source. We also have Handlebars, we are in the process of adding Handlebars there
as well. Then you have the Mojito layer, and on top of that you can put your application.
Cocktails is abstracting this area in the server side.
Another project is the Mojito Shaker – we have Diego there – which is a static asset
rollup manager for Mojito applications. You create these applications and when you get
ready to put it into production, you just use Mojito Shaker to take care of all the
hassle to get it ready for production. We are still working on it for Axis. Hopefully
we can get it in production really soon. It is also open source, so you can go and get
it.
Let’s get into the main subject: Axis and the making of Axis as a project. One of the
first things that we got into was this mythical proverb that you can write once and deploy
it everywhere and so on. We have been seeing that for a long time in other technologies
and other infrastructures, which is very cool, but it’s kind of difficult to get to that
point where you can actually create software that can be deployed everywhere without too
much hassle. From my perspective, make no mistake, there is no silver bullet in our
industry today. In other words, can you imagine maybe a car that works exceptionally well
under any conditions? It’s kind of hard to imagine that. Maybe if you remove the ‘exceptionally’
from there you get a car that works well. Maybe. It’s kind of hard to imagine that
kind of platform infrastructure without having to put a lot of effort just to configure that
piece of software to be able to run everywhere.
In the case of Axis, what we did was we were trying to create some sort of browser to be
able to search and to have this search experience. We knew we have to use some native pieces
because we need to control the loading process, we need to load applications into our application,
load web pages into our application. It’s kind of silly to think that you would not
use the native pieces to be able to enhance that browsing experience, so we knew we have
to use some of those. We decided to abandon this mentality of trying to create something
that works everywhere just like a web application, but we didn’t want to just do it all native.
As Ryan mentioned, it’s not even an option for us. It’s too painful to get to the point
where you have multiple applications and different devices running natively.
What we did was basically what we do best: divide. We are very good at looking at, at
the frontend you look at this kind of layout. This is the layout of Axis. When you look
at it, something that comes to your mind probably is how can I split this thing into logical
pieces? That’s the way that we think. We did, we split it into logical pieces. But
what if we think about those widgets, or areas, or web parts, or whatever you want to call
it, what if you think about that in terms of small independent pieces? Some sort of
small applications – imagine that this is a big application and you have small pieces
in it. Then you can just look into each individual piece and analyze them independently, not
in the context of the whole application but just in the context of that particular piece
that you are trying to analyze.
That single twist changed the way that we approach this problem from the beginning.
It was no longer black and white, it was no longer native versus web. In general, it just
became multicolor choices. We decided to go for a different approach. We just wanted to
be able to combine the native and the HTML to bring the best experience for our users
based on the capabilities of each different device.
Eventually we get into a different type of question. As you can see here, HTML5 applications
ship as part of the iOS application that you put into the app store, into the bundle, or
HTML5 applications that you load over the network. You see I put local network activity
at the top there. It’s a different kind of beast. They’re different, they’re not
the same, and you have to be able to differentiate them and try to understand what are the use
cases that they can solve at any given time.
When we started looking at this and trying to analyze each individual piece in Axis and
trying to figure out which one is better for what we want to do, the answer was quite amazing
for us. Mojito can produce both from the same source code. Basically you have the ability
to create this application, and eventually you have to decide if you want to build it
and put it into the bundle that you will put in the app store on the Android market or
any other application store, or you have the ability to just put it into your servers and
serve it from there. In other words, we have the option to defer that decision without
actually impacting the design that you have initially. That was quite a revelation for
us. Basically, we decided to get a little bit more time to get our head around this
concept and eventually we made a decision. The difference is just Mojito build versus
Mojito start, and you can go into the documentation and look at it. It’s a really nice way to
produce different versions of your application.
Then for each individual piece that I showed you before, we just have a question of deciding
between using native layer or using HTML and putting it into the bundle, or just creating
an HTML application that runs over the network. That’s the kind of decision that we have
to make for each of the pieces that I highlighted before.
On the same lines, another question came up like all right, if we have all these individual
pieces and they are really individual, how can we share logic between them? When we talk
about sharing, we usually refer to reuse and reduce complexity. You want to reduce the
complexity of the software by reusing some of the pieces and trying to gather some of
the logic into logical pieces. Usually that means, in terms of reusing, that you have
a lot of interdependencies, which is good in some cases but in some cases is not that
good.
The other thing is that reduce also means that you will zoom out rather than zoom in,
and what I’m trying to say is that you’re creating the software, you’re creating individual
pieces, and those pieces have to be connected somehow. Those pieces might have some share
of logic. Maybe they’re logging the user information across all different applications
or something like that. You rather have to spend a lot of time to try to understand the
whole software to be able to change a piece of it, and that’s a limitation when you
bring people on board, when you bring people to your project, how they can ramp up really
fast.
In Axis and Mojito we follow the NPM approach, where each individual piece can control its
own dependencies. We don’t want to have this kind of high dependencies of coupling
between different pieces, and Fabian will be talking more about that in one of the presentations
today.
We also know that recycling, not so much. We just produce software, and eventually,
two years from now, someone else will come and they will change everything and they will
drop your code. Maybe three years, maybe five years or so, but no more than that.
Reuse, but in our case we decided to reuse without coupling pieces. We want to reuse
some pieces, yeah. We will use NPM for that. We want to reduce the interdependencies and
reduce the time to ramp up, not reduce the time to produce the final software.
The new word here is replace. In our case, we really want to be able to produce this
application called Axis that is a composition of different applications and at any given
time, for any specific device, we can just change one of these applications, make changes
and you have a new version of one of these components without affecting the rest. We
don’t want to spend time having all these connected applications or pieces that are
hard to modify in the sense that you have to have full knowledge of the whole stack
to be able to change something.
How the hell are we going to connect all these so-called independent pieces? You have all
these independent pieces there. They have their own dependencies and so on. How can
you connect them? The answer to that is Y.CL, and Eugene will be talking more about it after
this presentation. This is pretty much the constructor that we use to connect all these
pieces. Pretty cool. It’s open source already. He will be talking more about it.
I want to give you more details about these HTML5 over the network kind of applications,
some pros and cons on that. The number one benefit of using this kind of application
– and we use a lot of them in Axis – is the ability to reduce the fragmentation. We
know it is a big deal. We know when you ship your application to the app store you might
end up having multiple versions of that application, and eventually you will have a huge legacy
that you cannot just drop, and you cannot force your user to upgrade. So this is a big
deal. It’s a big deal for products that will change rapidly over time, and Axis is
one of those kinds of products.
Ultimately, all this fragmentation just gets reflected on testing and QA processes, and
you end up having a product that is so big in terms of testing and QA processing that
you cannot move faster, you cannot move forward. That’s one of the things. The other thing
is that you don’t need to issue an update of your application. It is a reality: people
just don’t update their application, they don’t care about that. They don’t know
what back-fixing means, they just don’t do it. You end up having all these applications
there.
In Axis, since we use that kind of application that I mentioned, we also have problems. It
is not all good. One of the problems is that some of these webviews that are running these
applications coming over the network, it might be they’re running for days. The user doesn’t
close the application, they just switch between apps, and even when you get into a plane you
just put plane mode, you don’t close, you don’t turn your phone off. It’s kind of
difficult to control what is the version that your user is running and for how long they
have been running that piece. It’s kind of difficult to manage that. You might end
up in this position where you also have different versions of your web application. Even when
you think that you’re safe, you’re not.
Another thing is that as frontend engineers we know about the web, so it’s easy for
us just to ramp up in this kind of application. We know how to serve graphic, we know how
to load HTML, CSS, JavaScript. We know how to optimize that. It’s kind of easy for
us just to get used to this kind of application for our team, mostly frontend engineers that
have been working for quite some time doing web applications. It was more natural for
us.
A very important thing is even for a small company, if your product is going to require
a lot of experimentation and you need, for example, segmenting the traffic that you are
receiving, or maybe you want to produce different versions, you want to test new things, we’re
doing research. It is a requirement from the product point of view that we need to be able
to test new things. We need to ship new features every way, we need to tweak pieces and see
how they behave. For us it’s kind of difficult to abandon the web. We already have a huge
amount of tools and other kinds of infrastructure just to analyze metrics and to be able to
move forward in terms of testing and experimenting. It is all about control. You really need control.
This kind of application is probably the best shot.
One of the big pains of this kind of application is the hassle to deal with the network and
the network problems. In this case, this is a snapshot of Axis. If you try to open it
and you don’t have a network connection, you might be getting this kind of loading
icon and it doesn’t do much. You don’t control the network connection, you might
end up having bigger problems. In our case, in Axis we have this reiteration process,
so the webviews that we load over the network, we don’t have them visible, they are not
visible, and whenever we know for sure that they are ready then we make them visible.
That’s one of the solutions that we use.
This is another problem that is very common today. If you use an iPhone or an iPad you
might get into this situation where you have an application that is trying to load stuff
over the network and eventually one of them fails. In this case, we all know what’s
going on here: the CSS is not loading. It fails to load. In desktop and in the browser,
the user knows how to fix this thing. They know there is a button there that they just
click on it, refresh, and they are back in business. In an application this is a little
bit different. We don’t have a reload button there, we cannot put a reload button in every
single webview that we create, so it’s kind of a pain to solve this kind of problem.
In Axis, what we are doing as part of the reiteration process, also include a checklist.
We have maybe a CSS or something like that that will allow you to check the state of
one of the elements. You know if the element is really heating on up, so you can know if
the CSS is there or not. In the same lines, we have this checklist that allows us to understand
what’s going on in that webview and even issue a reload if needed. If we feel that
it’s not ready, it’s taking too much time, we can probably reload it.
Another bad thing is that webviews that load remote content, they are not first class citizens
in iOS. We have no Nitro, so it’s a little bit slow compared with Safari. iOS can wipe
out things without giving you a clue about it, so they can just wipe the local storage
or the cache or whatever they want, depending on the condition of that device. In Axis,
we work around some of these limitations. That’s pretty difficult.
But to date, loading over the network is still the safer and easier way to load content and
to have control over that content. Ideally we will get Mojito support for this use case,
and Satyen and Matt and other people at Yahoo! are working hard to try to bundle these into
Mojito and try to be able to ship this HTML application into the app store as part of
the bundle, and being able to also go and get a new version of that application over
the network in a SIP file and just get it ready locally in the device. It’s kind of
the way that we want to move forward. It is also very difficult because it’s like a
gray area, and Apple doesn’t give you too much choice there.
The next topic is what we call optimization versus adaptation. When using the hybrid approach,
like the one we are using having these native components and these HTML components, you
kind of open the door for adaptation and optimization. Mojito is right on the money on these two
subjects, in these two areas. Not too many frameworks are actually looking into these
at the scale that Mojito is doing it, and I wanted to dig in a little bit more on that.
Let me give you an analogy on that. You go and buy the car that you like, and you ask
for the right tires for you, for your situation, for your location and so on. You get a car,
you start driving, and you don’t like the way it feels. Or maybe you are travelling,
maybe you are moving to a different location, so you might be having problems with it. What
can you do? You already bought it. You’re kind of stuck with it. You might want to adjust
the pressure of the tires, and maybe you can use a different kind of air depending on the
situation. Maybe you just need to use snow chains, and that will keep you going depending
on the conditions. So you change the way that your car behaves.
In Mojito optimization… In Mojito in general, it really enables you to think about performance
as a product feature. The way it does it is basically, in Mojito optimizing is just about
customizing the way that your product behaves, per runtime and per request, these two factors.
We will talk a little bit more about that. It is about producing the right HTML, CSS
and JavaScript. You have this application that is coming over the network, you need
to ship CSS, JavaScript and HTML to the client, and you have to do that per runtime, per request.
These are the two things that we know: we know about the request that comes in, and
we know about the situation where this application is running on the server that we control.
These are the two things that we can control. In Mojito you have multiple runtimes and producing
code for each runtime is not hard. You just need to follow some rules and some configurations
here and there, but it’s fairly easy to do it.
But more important is the use of Mojito context. This is the entry point for you to Mojito.
You need to understand how the context works. For example, we can base it on that request
that comes in, base it on that server that you are running on. We can give you the local,
maybe we can give you information about what kind of environment you are running on, what
kind of device is this user using, base it on the request information. What kind of runtime
are you using? Usually server, you are running over the network application. You can even
go and do more customization and say yeah, I also want to know the network, I want to
know if the user is running AT&T Verizon because I want to brand my product and base it on
the network that the user is running on. You can even have CPU information, memory information,
because you control the server, you are running that application over the network. You can
have all kinds of configurations depending on your requirements.
In Mojito you have to optimize per context, and optimizing per context means that you’re
producing, again, the best HTML, CSS, and JavaScript depending on these two conditions,
the request and the runtime.
Let me give you an example really quick. This is a definition for one of our Mojits. We’re
saying here the master definition, which is the generic values, default values, we have
this configuration, this ScrollView, and you probably saw in the video that you can just
swipe in Axis to get more content. We wanted to be able to customize the way that this
scroll behaves, and for those that have been using YUI ScrollView, you probably know about
these two properties. You have the acceleration and bounce. What we have here is you have
a default value, but we want to customize that value for mobile applications. We know
that for mobile the bouncing should be a little bit smaller, because it feels better when
you try it out. In that case we are just customizing this thing for a mobile device. Maybe we want
to include some meta just for that kind of device, and so on.
What you can see here is that you are abstracting part of the logic that you usually put into
the software into the configuration of that software. Mojito enables you to reduce the
complexity of your code by relying on this multi-dimensional configuration computed automatically
per request. I think this is new in the industry.
Another example is what you do in the event of a traffic surge. You’re getting a huge
amount of traffic for whatever reason. Social network send links and you can get a pretty
big amount of traffic in just a short period of time, so it is a hard problem. It is a
hard problem that everyone has in the industry today. How can you solve it? You can put more
money on it. You can just let them die. Eventually the traffic surge will finish and your server
will come back eventually. You can degrade your servers, and that’s what we usually
do at Yahoo! Or you can delegate some process to the client side. Let the client carry on
this particular process. These are the kinds of you things you can do in Mojito. I think
no other framework out there allows you that kind of flexibility.
This is an example of that. I have this master configuration that says that for every single
request, by default use server side rendering when we produce this content that you can
scroll. What we are doing is saying hey, by the way, for mobile devices, don’t do the
rendering because we are rendering thirty cars in that search layer, but for mobile
you have only a small viewport so you probably display only one. We don’t want to spend
rendering thirty of them just when we can render one of them in the client side. But
that’s a general configuration, and on top of that you can say by the way, if my servers
are running hot, make sure that you also render everything delegating that rendering to the
client side. That kind of stuff that you can do, stuff that we use in Axis today.
And of course, you can control the dimension of your application. You have full control
over what you can configure and what are the dimensions that you want to control and so
on.
One more example on that. This is the way that you define dimensions. Dimensions is
a finite structure, and in a sense you just need to define what are the dimensions, the
name of each of these dimensions, and what are the possible values that these dimensions
can have. Maybe you just want to know if the user is running on Verizon or AT&T. Maybe
you just want to define the device that you will support. Maybe you just want to include
TV there.
The other side of these subjects is the adaptation. Adaptation in Mojito – and YUI for that
matter – really enables you to think about adaptability as a product feature. How can
we build an application that you ship into the webview, browser, or anything that runs
a Mojito application in the client side, and how can these applications behave accordingly?
Adaptation in Mojito is about customizing the UI per screen size, per connection speed,
per feature detection, and so on. We have different capabilities in each of these devices.
It is about responsive UI. In our case, for Axis for example, we have more than 500 mocks
and concepts. You can see them distributed between different devices. In general, iPod
is the big one. But in general, as a product requirement you have different interactions
depending on the type of device that you are running on, which means that you need to change,
even though you’re trying to create or reuse code across all different strings, you have
to customize that, you have to customize the behavior of that.
In Mojito, YUI covers a lot in terms of adaptation. YUI already supports conditional loading based
on the capabilities of the device. You just load cache-offline, it doesn’t matter if
you don’t have support for that, for local storage. Or you just click on it, it doesn’t
matter if it is a click or a touch or whatever, orientation change and so on. Maybe you just
want to get a query from a different component. Eugene will be talking more about that.
You can basically adapt per screen size. Maybe you use CSS media queries. Or you can just
adapt per orientation, or connection speed. This one is interesting. You can basically
monitor every time that you make a call to an API or something, and check the latency.
Eventually you can get a sense of what the connection speed is for that particular user.
What are you going to do with that? It all depends on your software, but in our case,
we might want to optimize the amount of requests that we make. Maybe we are going to call our
server side saying by the way, this user is running in 3G, make sure that you render pieces
in the server side, mash that up, and send a single response. Stuff like that are do-able
in Mojito.
Memory. iOS will give you warnings through the native layer telling you hey, you’re
running low in memory, make sure that you clean something there. The next warning is
not a warning, it will just crash the app.
Let’s do a quick recap on some of these concepts. Axis is running on Yahoo! Cocktails.
It’s all about Cocktails. Even though we have some meaty pieces, it is in the context
of Cocktails. Axis is some kind of hybrid application. It’s composed of independent,
small pieces that can be implemented in native or HTML. It all depends on what are the conditions,
and what we want to do with that particular device. We can even have a different type
of device running the native version or HTML version. It all depends on what we want to
do, what we want to achieve.
HTML5 parts were written on Yahoo! Mojito, so all the HTML that we have is Yahoo! based,
it’s just a Mojito application. A different Mojito application actually. It is open source,
it is created on top of YUI and Node.JS, so it’s pretty good.
Axis leverages Mojito context to be able to optimize and adapt those HTML pieces depending
on the conditions, the requests, the runtime, the device type, and so on. Axis also leverages
CL – this is the communication layer that I mentioned before – as the main infrastructure
to connect all these pieces, even if the pieces are just a native base. We have this infrastructure
to be able to connect all together, and Eugene will be giving you the talk on that subject.
This is all I have for today.
[applause]