(sergi mansilla) So I'm going to talk about Firefox OS-- not only about Firefox OS, but the importance of HTML5 on mobile.

Thanks for having me.

It's a beautiful, typical Amsterdam day.

They say you haven't lived until you get to your you talk all soaked after a bike ride.

I miss that.

It started to be too beautiful here.

So Firefox OS, how many of you have a Firefox OS phone here? Really? Wow! That's more people than I expected.

I expected nobody to have one.

So after the talk, five more people will have a Firefox OS phone because I will give away five phones.

But it all depends on who Paul chooses, so the-- out of the questions you will ask about my talk, five people will be chosen and will get a phone.

Geeks [inaudible].

So as Paul said, I live in Amsterdam.

That's funny because the organizers offered me to stay in the hotel conference anyway-- the conference hotel anyway.

And I said, no, I'd rather sleep in my bed.

And then I thought, would I rather sleep in my bed? What hotel was it? And I didn't ask in time.

So maybe I missed out on a cool hotel bed.

Anyway, that's my Twitter.

I rant on Twitter like most of you.

That's my GitHub where my projects are.

Projects are mostly JS, JavaScript, some Firefox OS now.

Before, I worked at TomTom.

I bet that most people didn't know that TomTom UIs were made in-- or the last ones at least were made in JavaScript, WebKit-based ARM built.

So after that I worked at Cloud9 ID making a cool ID online, mostly for JavaScript, but now for all languages.

Cool thing about-- curious thing about TomTom, the first is the stock-- their stock valuation for last three years.

The first arrow points out when we introduced to the market.

We finally released the WebKit devices.

The market loved it.

And when stock went up.

The second arrow is when I leave the company, and I don't want to draw any conclusions really, but it's quite a coincidence that everything went down at that point.

Actually, later on, they introduced-- they switched from WebKit to Android.

And I think that wasn't the best decision.

I'm probably a reason why its stock went down.

Anyway, at the present, I work at Telenor Digital for Firefox OS.

So what that means is I basically work for Mozilla, and I get paid by somebody else.

Telenor is this Norwegian telco that has many markets over the world, and they're very interested in deploying lots of Firefox OS phones.

Back to the theme of the talk.

We have problems.

We're here in a front-- in Fronteers Conference, right? Everybody is a front-end developer, yet most phones have HTML5 as a second class citizen.

And we're OK with that apparently.

The main problems of the current market and the current mobile market is-- I'm going-- I put these four brands on top.

They are the most known, although I don't even know what BlackBerry is doing now.

I don't know if they continued or not.

Who has a Blackberry phone? Good.

So what's the problem with mobile right now, especially for developers? The current web mobile platforms are write once, run once, which means that if you are going to make an app for Android, that's going to be awesome.

They have great frameworks, great tooling.

But your app is going to run on Android and nothing else.

You want to do an app for iOS, you have to make it for iOS.

And that means different incompatiblity obviously, different language, different environment, different tooling, different everything.

If you-- let's say-- are a big company and want to have presence in every single phone or most customers, you will have to make an app for Windows and an app for BlackBerry.

And that, again, is different APIs, different everything.

Even if Windows Phones and BlackBerry are HTML5 compatible, they have their own API.

So you still have to learn stuff that you shouldn't really have to learn.

And why would a developer have to do-- have to rewrite the app four times or five, depending on what platforms you support.

for the same app? it seems a bit-- a little bit overkill.

Of course, you also have the store restrictions.

Each platform has its own policies, its own stores telling you what can go in and what cannot, its own is waiting times.

So that doesn't make it easier for developers.

And, also, you have to pay fees and whatnot.

This is just an example that was perfect for the talk.

This is the 1Password app, a pretty popular app for storing your passwords.

These are current screenshots of the app in iPhone and in Android.

Both apps are extremely different from each other.

The Android one looks notoriously worse.

They don't seem to care too much.

And that's finally what happens when you have these differences among platforms.

The main-- what happens is that either companies put less effort on some of the platforms because they-- metrics or whatever, they think that some users are less important than others.

Or they just don't have the resources to have all these developers working on different apps, time or resources.

So the end result is this.

The user suffers in the end.

Most people-- many iOS users are happy with the state of the-- it's a loop, so it's really bad.

Most users think that they're happy with the current state of things.

But reality says otherwise.

So you probably guessed what I'm going to say.

The solution is HTML5 because it's universal in all.

This is true.

But it-- there's some details to be added.

So HTML5 is also being used as a massive buzzword just like the cloud in this Dilbert comic.

Everyone is talking about HTML5, and we don't really-- we're losing our sense of what HTML5 really means.

What do people mean? Do we-- do they mean just the markup language? Do they mean its web pages? Do they mean all the technologies that there are? So when I talk about HTML5 in this talk, I'm going to talk about a set of technologies and tools that don't-- that include the markup language, but also include the two other technology-- most popular technologies, CSS3 and JavaScript, and also include all the rest of the technologies that are being added into browsers lately.

WebRTC, Web Components, these are big ones that are going to be extremely important in the mobile world in the following year or two.

Of course, you have Canvas, SVG, ASM.js, WebGL.

All these are-- these technologies are going to change the way we make apps.

So that's what HTML5 is going to be for me.

There's also-- oops-- another reason, which is ubiquity.

Almost-- there's only one device on this screen that doesn't support HTML5, and it's not the Windows Phone.

So in this screen, you can see all the devices.

And we know that.

Most of us have several devices at home, different brands, different technologies.

And they all support this single technology that is HTML5 in some different levels.

Perhaps your TV has a-- supports a smaller subset than what your iPhone supports or the other way around.

But the common denominator is that HTML5 mostly works in all these devices, right? So-- but we're not taking advantage of that.

We keep programming for native platforms time and again.

And we still don't find nothing really wrong with it.

You don't hear people complaining too much.

There we go.

Also, we have standard APIs.

Whenever you program for HTML5, especially if you're a web developer, you have to learn one set of APIs that are for sure going to be exactly the same in each browser that is standards compliant.

You don't have to go crazy.

You don't have to look at different manuals, different devices-- how different devices handle it.

You know that if you program a HTML5 standard and your browser supports it, you're good to go.

There's less fragmentation.

Admittedly, there's some fragmentation that different devices' browsers support different subsets.

And that can still be a pain.

But guess what web developers are good at doing? Web developers, for ages, we have been amazing at doing cross browser development, right? We never called it fragmentation.

We called it our job.

Our staff had to work on several browsers starting for-- starting with the first five with Netscape and Internet Explorer and now expand to four other browsers and deal with all kinds of problems.

And I think that in the mobile world, these problems are not even that bad.

So, yeah, there is some fragmentation.

But it's-- you can go over it.

You can't go over fragmentation between Android 4 and Android 2.

You have to choose what to implement for what phone.

And, also, we're not only talking about fragmentation in the Android world.

If you extrapolate to the mobile world, you have fragmentation between four different major phones.

And this fragmentation is not going away.

They're not going to make any pact and make their frameworks and applications compatible.

The main advantage to-- or one of the main advantages as well is that you can-- your freedom, you're not constrained to the frameworks tooling environment that Android or iOS or Microsoft give you.

You can choose whatever you want.

And now we're in a golden age of JavaScript development in which we have all these amazing frameworks that take different paradigms and allow you to program your application as you want.

If you like MVC, MVC.

If you like functional reactive programming, you can do it that way too.

If you just need something simple and you want to use JQuery, just quick and dirty, you can do it.

That's no problem at all.

There's no restrictions.

You have a blank slate, and you can choose from your technologies to your tooling.

You can use whatever editor you want.

If you like IDs or you like it editors, whatever you want.

There's nothing that restricts you.

In other platforms, you have to use what they say because it works better.

You have to use their build system.

You have to use either Xcode, Eclipse, or IntelliJ whatever you use, which are good tools.

But they-- you have to use those.

You have no other option.

And now there's several bullshit argument-- whenever you talk about this with people, especially with native developers, it always come.

The first argument always comes-- that always comes is performance.

Performance in HTML5 apps is obviously lower than native apps.

There's no point in discussing that.

Native apps are native.

And HTML5 is running on a browser and is interpreted.

Even if browsers did [inaudible] things out and it's gotten pretty fast, of course, it's going to be slower on paper.

But that doesn't mean that your applications will feel slower or will run slower effectively.

I don't think so.

Some time ago-- I'm sure that many of you are familiar with it-- Mark Zuckerberg came out on stage.

And he was-- his words were misinterpreted in a way.

But, basically, he said that Facebook for iOS switched to native because HTML5 was not ready yet.

The performance was not ready, and they could not make it work as they wanted, so they switched to native.

And, of course, Tech Crunch and all these people picked up and started saying, HTML5 is dead in mobile.

It's not going to work.

But a week later or two weeks later, Sencha a JavaScript company actually with offices in Amsterdam, came up with this Facebook app in HTML5 for iPhone.

What they did is Facebook clone with exactly the same features as Facebook native app that was, in fact, faster, especially when scrolling and doing all kinds of stuff.

As you can see in this video, same phone, same two apps, and it's equally fast.

Why were they able to do that? Because they put a lot of work, because the main problem that we have nowadays is that many web developers jump right away into the mobile world just using their current knowledge without adopting it, in particular, to phones.

All they do is make a liquid layout and make it fit in the screen, but use the same code base as they use for the desktop.

Of course, desktop is a very powerful environment.

It has nothing to do with mobile.

So Sencha used some smart tricks that their framework does for them automatically in which they use iframes for its view.

And that made it fast because it used different threads.

You should read the blog post.

It's pretty interesting.

So the point being, yeah, it can be as fast as it, but you have to know your environment.

You have to know how to make it fast.

The other example that made the rounds in the internet was this JavaScript.

This is C++.

Here's the Unreal game engine.

Basically, C++ engine transcompiled to JavaScript using [inaudible] which is a very, very interesting project that takes source cord-- source code and imports it to Java-- transpiles it to JavaScript.

And this is using ASM.js.

ASM.js is the subset

of JavaScript-- it's already in Firefox built-- that gets native speeds.

So this is-- this game is just JavaScript.

And it feels like the native version.

So that's where we're going.

So all this-- and this is WebGL.

So even if performance arguments matter right now, they're not going to matter in a matter of a year.

They're not going to be important.

The second bullshit argument you hear a lot is about JavaScript, the language itself.

Usually JavaScript is-- I'm in a very comfortable spot here because all you guys use JavaScript, and probably you don't have to be convinced about that.

And I'm not going to fight this battle about JavaScript being good or not.

I like it.

There's this-- we all have this love hate relationship with it.

We love it most of the time.

But, every now and then, we have some-- why is it like this? JavaScript has its warts.

But I still find it a bad excuse that the language gets blamed instead of trying to embrace it and say, this is the most used language in the world.

Let's see what is behind.

In any case, JavaScript is going to change very soon.

JavaScript Next is around the corner.

And most browsers-- modern browsers are implementing JavaScript Harmony, or good parts of it, so you can already use some of the goodies.

And soon, we'll have classes.

We'll have a module system.

We'll have optional types, [INAUDIBLE], so all kinds of stuff.

But even if you would be unconvinced by that, right now, we also have all these languages, super high quality languages, very well-maintained the transpile to JavaScript with tooling support, with all kinds of stuff.

Each of these languages is aimed at one particular kind of developers to make them feel comfortable with the environment.

So we have Dart for Java developers, more close to Java.

ClojureScript, a more functional [INAUDIBLE] developers.

TypeScript, which is pretty awesome, actually coming from Microsoft, which is basically JavaScript, but a superset of it, adding classes and typing.

Very convenient for big projects because it will do type checking at compile time.

Objective-J for iOS developers.

Opa, LiveScript, all these a re functional.

CoffeeScript, we all know.

So these are massive.

There's a massive amount of languages.

In fact, I went to alt.js

before the conference, and I ran this code just to see how many languages that transpile to JavaScript are there.

And there's 269 only in that page.

These are all different languages in JavaScript.

Some have thread.

Some have-- mean for each need, you can-- if JavaScript is not your thing and you can definitely deal with it, there's no excuse for not programming-- for not using HTML on mobile.

You can still use any language, which is an amazing amount of freedom.

Yeah, these are bits of code if you want to see the names of it.

The third bullshit argument is looks.

And that's-- actually, I agree with it.

Most web apps for mobile look really bad.

But is that a real argument? I don't think so.

I think that the looks is just that people-- developers of web apps usually don't put enough effort on making it look good since they're web apps.

There is something in the mindset.

It's like, oh, it's a web.

It's not as-- it doesn't have to be as finished as other apps.

These two screenshots are from a web application called Forecast IO-- Forecast.io.

If you go to a web page, it will work in any device in any browser.

And it will adapt.

It will be beautiful.

And if you try it in your phone, it will just look amazing.

And it looks native.

At no point do you feel that it is not a native app.

Everything is smooth, snappy.

It uses cool effects everywhere.

In fact, it's a very, very good weather app.

It shows real time maps of the clouds, all kinds of stuff.

You would not know that it's a web app.

And the other thing they did is put a lot of effort making it perform and making it look good.

And there you go.

You have an app that runs on every device beautifully.

There are some real arguments though against making web apps for phones.

And the main one is there's no phone APIs, so that's quite a show stopper.

If you're convinced, like I'm going to develop this HTML5 app-- I'm really convinced about using JavaScript and HTML to make my app.

You're going to use it, and then you want to access the camera at some point.

You can't.

There's no way from your JavaScript browser in the system to access phone APIs to make it call, to make it vibrate, to send an SMS, to access the sensors.

Of course, many of you have used PhoneGap most likely or Appcelerator.

These guys are trying very hard, and they're doing great work, especially PhoneGap, to make a bridge between HTML apps and native apps.

So it basically allows you to write your app, and through their own APIs, access the underlying phone services and APIs, which is awesome.

And PhoneGap has an extremely good service to the community over the years.

But PhoneGaps main mission has always been to eventually disappear, to not be necessary.

To not be necessary because we'll have a way in which web apps don't have to be a second class citizen in the mobile world and that we can just program right away in HTML, accessing these APIs.

There's also a disadvantage to relying to this company is that it's still a company.

It can go away.

They cannot be as fast-- they cannot be possibly as fast as the phone maker releases they're APIs.

So when there's a new iOS, they have to work very hard to quickly implement all the new APIs in the new PhoneGap version.

And, sometimes, they can't do it timely.

And, sometimes, they cannot access the APIs at all.

They have to do crazy workarounds and stuff like this.

So it ends up with HTML5 apps still being second class citizens.

It requires much more depth, much more effort.

It requires to use build systems.

Even at the beginning, they were not allowed in the App Store-- in the Apple App Store.

That changed, but it could change again.

You are subject to all these companies.

It's a very fragile environment to rely on.

So here comes Mozilla.

And Mozilla is seeing that-- what is happening.

Mozilla is seeing all these companies creating wall gardens.

And I don't know if you remember the 2000s.

I hope so.

I would feel very old otherwise.

In the 2000s, Mozilla realized what was going on.

What happened is that Netscape browser was just going away very quickly, and people were using IE, IE5 or IE6.

And, actually, IE was a good browser for the time.

The problem is that it was the only one.

Microsoft decided whatever to do with it.

It decided new APIs, created ActiveX, a pain of many developers afterwards, and they were just creating their own environment.

They were creating a massive wall garden in which they would eventually own the web if everybody would go like this.

So Mozilla decided to break that and to create standards compliant browser and to push standards.

That browser was Firefox.

Their code name was Phoenix at the beginning.

And it took a while for it to get users.

But in the end it did, right? Their mission was very similar to Firefox OS.

Their mission was about get-- letting other browsers implement new standards and makes down the main thing.

The mission of Firefox was never to be very popular as a browser.

The mission was to make other-- to make everybody standards compliant, to force Internet Explorer into being standards compliant, so the same with Firefox OS.

Mozilla created Firefox OS as a new mobile OS.

Of course, they want to sell many.

And, of course, they want people to use it.

But the main thing to take home about Firefox OS is that it pushes web API standards.

So Mozilla is working with the W3C to make this-- the APIs, the camera API, the microphone API, everything that can be accessed in a device, to make it a W3C standard that everybody can implement.

There's no wall gardens.

Mozilla has its marketplace, but you don't have to use it.

And you can-- your guaranteed that your APIs, their APIs, and all these won't change.

The standards don't change easily.

So how do you go with starting to make Firefox OS apps? So it's pretty easy.

You just-- basically, the minimal Firefox OS app is you take any website.

You use some web API if you want, and you put a manifest file.

And that already is an official app in Firefox OS.

So, basically, you've all done Firefox OS apps already.

They're just not very good.

They don't work great.

Let's say it that way, in Firefox.

So how would you go-- what would be the first thing you're do on Firefox OS? I'm sure that you're all familiar with HTML code.

You're all familiar with event listener.

So in this whole part of code, if you see-- right.

There's not a single thing that you don't know except for these navigator.vibrate in the middle

of all. If you see

here, it's a very simple HTML structure script.

We add an event listener to Windows-- it says device proximity-- that listens to the device proximity event.

So whenever that happens, we pick up the event.

And if the values less than 10, we call vibrate.

What that makes, in any web page, if you go to Firefox OS in that web page, you take the phone.

You get it close to you.

And when it gets closer, it will vibrate.

That's all it does.

It does that with that amount of lines.

I didn't need anything else.

You don't need any build.

You just have this web page.

You put in Firefox, and that's it.

You need a manifest web, like a package JSON for Firefox that describes more or less what you're app does, put some icon.

And if you need permissions, you ask for it.

But that's all.

And we have all kinds of APIs.

Here, I pointed out which ones are already approved by the W3C.

But you will have from-- you can access absolutely every aspect from the phone-- in the phone with only JavaScript and, usually, with only one line, just from logging amounts to geolocation to vibration to web payments for apps, ambient lights, proximity, notifications.

These are the normal apps-- the normal APIs-- which means that anybody can use them, and you don't require special privileges.

Then, you have the privilege APIs in which you have to be in the App Store to be able to use, accessing contacts, device storage, and all this more sensitive stuff.

And then you have certified APIs, which only apps that ship with Firefox can use right now.

But they will open it up to more apps in the future, which includes like calling people, sending SMS, getting Wi-Fi information, shutting down the Wi-Fi, opening-- using Bluetooth.

This is an example of how you would do a notification, just create notification.

You have the title.

You have the content and an icon, an optional icon.

And that's it, just normal JavaScript.

This is how you send an SMS, just sms.send, the number,

and the message itself.

And you put an unreceived handler for whenever this SMS is received and do whatever you want, just normal JavaScript.

This poor guy asked in Yahoo Answers, if it's bad when your computer vibrates? "I just bought an Acer computer with Vista three days ago.

I don't know.

But, sometimes, it starts to vibrate and shakes my mouse a bit.

Is it broke or something?" It usually would be broke.

But if you use the vibrate API, it's just the navigator.vibrate

1,000 will vibrate for a second.

If you put a pattern, it will vibrate for this particular pattern.

So it's just one line.

And, in fact, the cool part is that a thing that Chromium actually implements a vibrate API.

I don't know why they would need it in a desktop computer.

But you could use it if you want.

I don't anything will vibrate though.

Of course, there's a security concerns.

And you don't want anybody to just use your phone or send SMSes or use your context API.

So on your packages and on your web manifest, you just have to declare what are you going to use.

And that's what the App Store will use to see what you're app does.

So this is all good, but I haven't said anything about, to me, what the best feature is.

And it is that Firefox OS is amazing for developers.

There's not anything-- not a difference with how you develop a web page.

You have your Tools.

You have your Inspector.

You have your debugger, your profilers, your-- everything that you want to make the same apps that you do for the web, but they run on the phone natively.

And, actually, I want to show you a video that was released very recently by Dave Camp, which is the-- who is the boss, the head of Dev Tools in Mozilla.

Let me see.

OK.

There we go.

No.

Let me see.

Do you guys see it right? It's a bit-- Sorry about that.

There we go.

Oh, shit.

It's running already.

Sorry.

So the video starts with a responsive view that is already in your-- so everything I will show is already in your Firefox browser in the Nightly.

So it starts with a responsive view, which is a special view you have in Tools in which you can declare the size of the viewport you want.

And it will simulate any viewport.

So he was developing this calculator app in Firefox the browser normally, like you would do in any browser.

No Firefox OS involved.

So he's changing the view size and all.

And then he's like, OK, I want to try this on the simulator, on the Firefox OS simulator that also comes as an add-on for Firefox browser.

First, he fires the App Manager, which is already in the Nightly.

He adds two apps.

First, he adds a bugzilla-todos.

And then he adds the calculator app.

Once he's added it, he will try it on the simulator.

So clicking a button fires up the simulator on the app that he selected.

He installs it by hitting Update on each app.

The apps are ready there in the system.

And now he can just fire it up and click Debug.

And whenever he hits Debug, the app fires up and, also, an inspector instance fires up.

So from that moment on, you can-- he stars modifying the CSS of this calculator.

He is definitely a developer, not a designer.

So Don't judge him for It.

So he turns the background pink.

He will change some more stuff in the calculator to make it a little bit more bearable.

And then from the same Inspector Tools, he will save to the original file.

Once it's saved, he does some more stuff.

But he closes it up.

He closed the simulator.

And now, this-- what you see there on the left is a video of the phone, which he just connected to the computer he has.

But that's a real Firefox phone.

And what he does from the same App Manager, he will just update the phone.

He connects to the phone, and now he has access to all the apps that exists in the phone.

He can launch any app.

He can debug any phone-- any app inside the phone itself from the Firefox browser.

See permissions of every app.

You can have access to everything.

But, anyway, he goes to the apps that he just created at the beginning, and he uploads them on the phone.

You can see them appearing-- the icons appearing.

And now he does the same as they did before.

He just hits debug.

Calculator comes up.

You have your app running on the phone.

You have your Inspector running on your computer.

And he-- as you see, you can see that he types in there in the calculator, and it changes real time on the Inspector itself.

So you can just seamlessly develop anything and see the results immediately on both sides.

He changes the text of the Clear button, changes immediately in the phone.

Doing that, in that-- developing like that is really, really enjoyed.

It's super nice.

You didn't have to care about-- he's showing an alert in the console as well.

So you have the same access as you would have in a normal browser web application, but in your phone.

And nothing changes.

You just have a phone connected.

That's how it should be in my opinion.

And in makes developing on that phone a real joy.

So, yeah, real developer bliss in all fronts, that's the best.

The simulator, you can just download it as an add-on to your Firefox.

You don't even need the Nightly.

And it comes with a complete Firefox OS system, so you officially don't need a phone.

Eventually, you always need a phone to make sure everything works.

But the simulator is really good.

It runs its own Gecko and everything.

So you can, right away, start trying it out.

More resources.

Everybody has made sure, between Mozilla and partners, to create a lot of quality documentation.

So in buildingfirefoxos.com, you

can find CSS, stencils, icons, transitions, ready to use, the recommended ones, all kinds of DSD downloads as well for creating vector-sized icons and stuff like this.

Mozilla has just-- not just, but recently released Brick.

I don't know how many of you are familiar with web components yet.

I think there was another talk in this conference about it.

So Brick is Google's polymer, but by Mozilla using X-Tags, which is their own technology as well.

Anyway, they created this platform, which you only have to mention like elements like a flipbox You just make a flipbox You say what is in each side of the component.

You throw it in your page, and it will just super perf-- it will create a very performant component that will just rotate whenever you click on it.

And like this, all the components, you can imagine, like menus, all kinds of utilities.

And we created as well, at Telenor, many apps and boilerplates.

So this is an Angular app running on the simulator that just creates a template for a normal app with lists and stuff that you click on, things that you very often use in an app.

And it's ready to use if you fancy Angular.

And that's what we used to make apps.

It's pretty convenient, and it runs very fast on Firefox.

And, of course, we're creating more documentation.

Everything is in the-- is in our website.

So you can find all kinds of stuff to get started.

It's super easy and very nice things.

You don't need even a phone or anything to publish your app in the App Store right away.

Mozilla also has its Developer Hub, which contains more of the same, more icons, more design, how to build stuff, how to build particular features that might not have been cooked into the latest Nightly.

And they have their own marketplace.

Before, I said that you don't even need to be in their market.

And you don't.

You can host your own app.

You can have your own marketplace.

Like, vendors will have their own marketplaces.

But Mozilla has their official one.

And if you want, it's really convenient to be there.

But if you want to be there, the only thing that your app has to do is to not crash and to not pose any security problem.

And if that works, they will accept it.

There's no filters, like the App Store, which means that, perhaps, at the beginning, we'll see more less beautiful apps because their more lenient accepting it.

But the thing is eventually, it's good for developers.

And the best part of all, many people have Androids.

Many of you have Androids.

Firefox OS works on Android right away.

If you install the Firefox browser, you can run any app made for Firefox OS, and it will access Android internals.

So you can just use Firefox OS to run apps in the marketplace, to test your own apps, and whatever you want.

And I think that's all I got.

So thank you very much.

[APPLAUSE] Should I goes there? Yeah.

Thanks guys.

That was awesome.

Appreciate that.

The talk was fantastic.

Thanks.

You found the trick to make sure that I am-- I have very large scroll bars in my Twitter client.

A lot of fun.

But everyone asked fantastic questions, and thank you very much for everyone in that awesome engagement there.

That was a lot of fun.

And everyone was really, really into it.

How-- All right.

So one of the first-- So I'm just going to ask a bunch of questions.

And, after, I'll announce who I picked.

But, first question is, how can Firefox OS help to influence Apple and Google to treat web apps as first class citizens? Yeah, that's a good question.

The thing is Firefox OS is going to go through several phases.

Right now, one of the problems they have, usually, is that whenever I show a Firefox OS prototype phone or one of the first phones that we developed, Firefox is trying to release that phone as a first phone in developing markets.

So people will jump right away from feature phones to their first smartphone, which will be Firefox OS.

In order to sell in this market, you have to make very cheap phones, hardware phones.

And these are the phones that we have to demo.

Or that-- yeah.

I mean this is the only hardware we have.

So we go to conferences in Europe or the States in which people have amazing phones, like the latest iPhone 5S.

And then you show Firefox, and they're like, yeah, this can't compete.

It's a bit slower.

Yeah, that's the point is not to compete against Firefox or Android.

It's to create awareness to create user base and to make web APIs available so that it eventually happens.

So Google seems more open to the idea of web APIs.

And, in fact, they're implementing some in Chrome, the ones approved by the W3C are slowly making their way in.

Also, Google has the Chrome OS, which is a very similar concept to Firefox OS.

And Google, being a web company, I think that they will eventually lean towards a web operating system.

And if they do that, it will be silly to not use the standards that Mozilla is helping create.

So I think that eventually will happen.

I think that Android will also follow its course, but I don't know.

I think that eventually Google will bet on Chrome OS.

That's just my opinion.

Apple is much more different.

Apple has no intention of buying in the web since their app strategy is extremely successful.

They make good money, and they like to have their own wall garden.

But the thing that-- if web standards-- if web API standards become important, Google and Firefox start using it, and people start programming in it, Apple will have to yield at some point and accept them.

Perhaps, at first, parallel to their apps, to their App Store.

But it will have to happen or developers will just choose other performance because they're much easier to develop and they run everywhere.

That's a good answer.

A bit technical, so for actually building Firefox apps, what is the story regarding the debugging and profiling tools? And how do you-- what is the approach to basically building a performant Firefox OS app? Do you just start in Firefox and build something that works fine in desktop Firefox? Or what is the best way to approach that and make something that's fast and responsive? Right.

So since you can use the same tools and the same debugger for mobile and desktop, it doesn't matter if you start on desktop or not.

Usually, it's the most convenient because you don't need-- when you're starting an app, you don't need to right away switch to a simulator and start using what will be the real environment.

But, basically, you can use what Firefox offers in terms of debugging and profiling, which is pretty good.

I think that the only thing it needs for now is a memory profiler like Chrome has, which is awesome.

But it will come.

The Dev Tool's team is working a lot, and they're releasing stuff literally every week.

So you have the same exact environment as you have when you develop web pages.

So the answer is just you debug it as you debug your web page and as you make sure that its performant.

So you can draw CSS regions to see what is being repainted.

You can see reflows.

You can run Profiler in particular functions.

You can do what you do for your web page.

Nice.

Another question.

I guess there's a bit of-- the question is, how will Firefox OS get traction in more saturated markets? So the current concern, I guess, that was raised is it's a bit of a chicken and egg situation where a developer might feel like their going to wait until there's more presence in that market.

What is-- how do you tell a developer how to address that? Right.

So, yeah, I think that that will depend a lot on the telco partners as well.

They are the ones who have the power of making high numbers of phones available in a particular market, like they're doing in Spain.

Spain is the only Western country where Firefox phones are being deployed by Telefonica.

And I think is very successful so far because they are aiming at teenagers, like dropping the prices like crazy.

So it's getting a user base.

It will take a while, I think in the Western markets, to get real traction and to be at the levels of Android or iOS.

But I think it's-- first of all, developing an app for Firefox OS if you have a web page already or an HTML5 app is relatively easy.

You just have to throw in a manifest, and you will have something already working there.

But, yeah, I think that it will take a bit, but it will happen as soon as we have more high end hardware coming through the markets.

And one question, actually, just from me.

A web app on the web, can I essentially install that to the Home screen? Yeah.

Do I need-- I need a manifest in place t do that? Yes, for the-- well, I mean you can put a normal web on the Home screen.

But if you want to use, let's say, some API in the phone, you need the manifest.

Got it.

Cool.

That's great.

How quickly will updates to Firefox OS be pushed to phones.

Three months.

You can count on-- we are-- Is that for everyone with Firefox OS that they're going to get updates? Yeah.

Well, it depends.

It's the same story a little bit then what happens with Androids.

So if you get the Google phone, the Nexus, you get updates as soon as Google releases them.

If you have a Samsung, maybe you have to wait until Samsung decides to release it.

So it's going to be the same with vendors.

But Mozilla is really-- I don't know if they put the [inaudible] or not.

But one of the main points of stress is that vendors cannot take long until they put a new version.

So the idea is every three months, we'll have a new major version coming.

Now, we-- the 1.1

which just released.

By Christmas, more or less, we will have 1.2.

And usually, vendors should follow up in the following week.

So more or less every three months.

So it's up to the telco to ship the OS out? If you are-- [INTERPOSING VOICES] ---with a telco phone.

If you use one of Mozilla phones that are there, like ZTEs or you install your own build, which is pretty easy a well, you don't have to wait for anything.

But if you get it from the Vodafone shop and you don't want to-- you're not an expert user or a developer, yeah, you have to wait until they update it.

What's the situation with Firefox OS coming to tablets? And I guess, how does Mozilla see the tablet story, like the Open Web and Firefox OS coming to the tablet versus what the story is on phones? Right.

So this-- I don't know that much about the issue.

I know that APC.io is

creating [inaudible] computers with Firefox OS.

And I think that Foxconn released a tablet with Firefox OS already.

They modified their own some components.

So Firefox OS-- I mean there's no reason why it shouldn't run on a tablet since it's HTML5 and it's liquid layout and responsive layout.

But I think that it's still very early though.

Although, if you have an ARM processor and you run on an Android boot process, you can just do it and see.

I don't that Mozilla is focusing on that this year.

But I think, next year, we will see a lot of that.

Cool.

Last question.

Is Web Intents something that Mozilla is going to push more and use internally for communicating between apps and opening up the handlers? Yeah, you can use-- it's called Web Activities inside Firefox OS.

And they're trying to make it a standard.

But, yeah, and-- That's implemented already in Firefox OS? Yeah.

Yeah.

since the very first version.

So you have-- that's the-- the cool part is you don't need to even have a certificate or doing any security stuff.

You just say, like, if you're app needs an image, you just get a web activity for images.

And then it will pop up, who is a provider for images, like, the camera, the image library app.

And you can-- the user can choose.

And since the user can choose at that point, you don't need any permission to do it.

Cool that's great.

All right.

Well, thank you, Sergi.

And this was great.

Thank you so much.