Articles by Chris Heilmann

The ongoing discussion about the “readiness” of HTML5 is based on a lot of false assumptions. These lead to myths about HTML5 that get uttered once and then continuously repeated – a lot of times without checking their validity at all.

HTML5 doesn’t perform?

The big thing everybody who wants to talk about the problems with HTML5 is performance. The main problem here is that almost every single comparison misses the fact that you are comparing apples and pears (no pun intended).

Comparing an HTML5 application’s performance with a native App is comparing a tailored suit with one bought in a shop. Of course the tailored suit will fit you like a glove and looks amazing but if you ever want to sell it or hand it over to someone else you are out of luck. It will not be the same for the next person.

That is what native Apps are – they are built and optimized for one single environment and purpose and are fixed in their state – more on that later.

HTML5, on the other hand by its very definition is a web technology that should run independent of environment, display or technology. It has to be as flexible as possible in order to be a success on the web. In its very definition the web is for everybody, not just for a small group of lucky people who can afford a very expensive piece of hardware and are happy to get locked into a fixed environment governed by a single company.

Native applications need to be written for every single device and every new platform from scratch whereas an HTML5 App allows you to support mobiles, tablets and desktops with the same product. Instead of having fixed dimensions and functionality an HTML5 App can test what is supported and improve the experience for people on faster and newer devices whilst not locking out others that can not buy yet another phone.

Native Apps on the other hand do in a lot of cases need an upgrade and force the end user to buy new hardware or they’ll not get the product at all. From a flexibility point of view, HTML5 Apps perform admirably whilst native applications make you dependent on your hardware and leave you stranded when there is an upgrade you can’t afford or don’t want to make. A great example of this is the current switch from Apple to their own maps on iOS. Many end users are unhappy and would prefer to keep using Google Maps but can not.

HexGL – a WebGL powered racing game

Seeing that HTML5 is perfectly capable on Desktop to exceed in performance, from scrolling performance to analyzing and changing video on the fly up to running full 3D games at a very high frame rate and have high speed racing games we have to ask ourselves where the problem with its performance lies.

The answer is hardware access. HTML5 applications are treated by mobile hardware developed for iOS and Android as second class citizens and don’t get access to the parts that allow for peak performance. A web view in iOS is hindered by the operating system to perform as fast as a native App although it uses the same principles. On Android both Chrome and Firefox show how fast browsers can perform whereas the stock browser crawls along in comparison.

The stock browser on Android reminds us of the Internet Explorer of the 90s which threatened to be set in stone for a long time and hinder the world wide web from evolving – the very reason Mozilla and Firefox came into existence.

In essence HTML5 is a Formula 1 car that has to drive on a dirt road whilst dragging a lot of extra payload given to it by the operating system without a chance to work around that – for now.

HTML5 can not be monetized?

HTML5 is a technology stack based on open web technologies. Saying that HTML5 has no monetization model is like saying the web can not be monetized (which is especially ironic when this is written on news sites that show ads).

Whilst on the first glance a closed App-market is a simple way to sell your products there is a lot of hype about their success and in reality not many developers manage to make a living with a single app on closed App markets. As discovery and find-ability is getting increasingly harder in App markets a lot of developers don’t build one App but hundreds of the same App (talking dog, talking cat, talking donkey…) as it is all about being found quickly and being on the first page of search results in the market.

This is where closed App markets with native Apps are a real disadvantage for developers: Apps don’t have an address on the web (URL) and can not be found outside the market. You need to manually submit each of the Apps in each of the markets, abide to their review and submission process and can not update your App easily without suffering outages in your offering.

An HTML5 App is on the web and has a URL, it can also get packaged up with products like Adobe PhoneGap to become a native application for iOS or Android. The other way around is not possible.

In the long term that begs the question what is the better strategy for developers: betting on one closed environment that can pull your product any time it wants or distributing over a world-wide, open distribution network and cover the closed shops as well?

Many apps in the Android and iOS store are actually HTML5 and got converted using PhoneGap. The biggest story about this was the Financial Times releasing their app as HTML5 and making a better profit than with the native one. And more recently the New York Times announced it was following suit with its Web app.

HTML5 can not be offline?

As HTML5 is a web technology stack the knee-jerk reaction is thinking that you would have to be online all the time to use them. This is plain wrong. There are many ways to store content offline in a HTML5 application. The simplest way is the Web Storage API which is supported across all modern browsers (excluding Opera mini which is a special case as it sends content via a cloud service and has its own storage tools). You can also store the application itself offline using AppCache which is supported by all but Internet Explorer. If you have more complex data to store than Web Storage provides you can use either IndexedDB (for Chrome and Firefox) or WebSQL (for iOS and Safari). To work around the issues there are libraries like Lawnchair available to make it easy for developers to use.

HTML5 has no development environment?

One concern often mentioned is that HTML5 lacks in tooling for developers. Strangely enough you never hear that argument from developers but from people who want to buy software to make their developers more effective instead of letting them decide what makes them effective.

HTML5 development at its core is web development and there is a quite amazingly practical development environment for that available. Again, the main issue is a misunderstanding of the web. You do not build a product that looks and performs the same everywhere – this would rob the web of its core strengths. You build a product that works for everybody and excels on a target platform. Therefore your development environment is a set of tools, not a single one doing everything for you. Depending on what you build you choose to use many of them or just one.

The very success of the web as a media is based on the fact that you do not need to be a developer to put content out – you can use a blogging platform, a CMS or even a simple text editor that comes with your operating system to start your first HTML page. As you progress in your career as a developer you find more and more tools you like and get comfortable and effective with but there is no one tool to rule them all. Some developers prefer IDEs like Visual Studio, or Eclipse. Others want a WYSIWYG style editor like Dreamweaver but the largest part of web developers will have a text editor or other of some sorts. From Sublime Text, Notepad++ up to VIM or emacs on a Linux computer, all of these are tools that can be used and are used by millions of developers daily to build web content.

When it comes to debugging and testing web developers are lucky these days as the piece of software our end users have to see what we build – the browser – is also the debugging and testing environment. Starting with Firefox having Firebug as an add-on to see changes live and change things on the fly, followed by Opera’s Dragonfly and Safari and Chrome’s Devtools, all browsers now also have a lot of functionality that is there especially for developers. Firefox’s new developer tools go even further and instead of simply being a debugging environment are a set of tools in themselves that developers can extend to their needs.

Remote debugging is another option we have now. This means we can as developers change applications running on a phone on our development computers instead of having to write them, send them to the phone, install them, test them, find a mistake and repeat. This speeds up development time significantly.

Remote debugging in Firefox

For the more visual developers Adobe lately released their Edge suite which brings WYSIWYG style development to HTML5, including drag and drop from Photoshop. Adobe’s Edge Inspect and PhoneGap makes it easy to test on several devices at once and send HTML5 Apps as packaged native Apps to iOS and Android.

In terms of deployment and packaging Google just released their Yeoman project which makes it dead easy for web developers to package and deploy their web products as applications with all the necessary steps to make them perform well.

All in all there is no fixed development environment for HTML5 as that would neuter the platform – this is the web, you can pick and choose what suits you most.

Things HTML5 can do that native Apps can not

In essence a lot of the myths of HTML5 are based on the fact that the comparison was between something explicitly built for the platform it was tested on versus something that is also supported on it. Like comparing the performance of speedboat and a hovercraft would result in the same predictable outcome. The more interesting question is what makes HTML5 great for developers and end users, that native applications can or do not do:

• Write once, deploy anywhere – HTML5 can run in browsers, on tablets and desktops and you can convert it to native code to support iOS and Android. This is not possible the other way around.
• Share over the web – as HTML5 apps have a URL they can be shared over the web and found when you search the web. You don’t need to go to a market place and find it amongst the crowded, limited space but the same tricks how to promote other web content apply. The more people like and link to your app, the easier it will be found.
• Built on agreed, multi-vendor standards – HTML5 is a group effort of the companies that make the web what it is now, not a single vendor that can go into a direction you are not happy with
• Millions of developers – everybody who built something for the web in the last years is ready to write apps. It is not a small, specialized community any longer
• Consumption and development tool are the same thing – all you need to get started is a text editor and a browser
• Small, atomic updates – if a native app needs an upgrade, the whole App needs to get downloaded again (new level of Angry Birds? Here are 23MB over your 3G connection). HTML5 apps can download data as needed and store it offline, thus making updates much less painful.
• Simple functionality upgrade – native apps need to ask you for access to hardware when you install them and can not change later on which is why every app asks for access to everything upfront (which of course is a privacy/security risk). An HTML5 app can ask for access to hardware and data on demand without needing an update or re-installation.
• Adaptation to the environment – an HTML5 app can use responsive design to give the best experience for the environment without having to change the code. You can switch from Desktop to mobile to tablet seamlessly without having to install a different App on each.

Let’s see native Apps do that.

Breaking the hardware lockout and making monetization easier

The main reason why HTML5 is not the obvious choice for developers now is the above mentioned lockout when it comes to hardware. An iOS device does not allow different browser engines and does not allow HTML5 to access the camera, the address book, vibration, the phone or text messaging. In other words, everything that makes a mobile device interesting for developers and very necessary functionality for Apps.

To work around this issue, Mozilla and a few others have created a set of APIs to define access to these in a standardized way called Web APIs. This allows every browser out there to get access to the hardware in a secure way and breaks the lockout.

The first environment to implement these is the Firefox OS with devices being shipped next year. Using a Firefox OS phone you can build applications that have the same access to hardware native applications have. Developers have direct access to the hardware and thus can build much faster and – more importantly – much smaller Apps. For the end user the benefit is that the devices will be much cheaper and Firefox OS can run on very low specification hardware that can for example not be upgraded to the newest Android.

In terms of monetization Mozilla is working on their own marketplace for HTML5 Apps which will not only allow HTML5 Apps to be submitted but also to be discovered on the web with a simple search. To make it easier for end users to buy applications we partner with mobile providers to allow for billing to the mobile contract. This allows end users without a credit card to also buy Apps and join the mobile web revolution.

How far is HTML5?

All in all HTML5 is going leaps and bounds to be a very interesting and reliable platform for app developers. The main barriers we have to remove is the hardware access and with the WebAPI work and systems like PhoneGap to get us access these are much less of a stopper than we anticipated.

The benefits of HTML5 over native apps mentioned above should be reason enough for developers to get involved and start with HTML5 instead of spending their time building a different code base for each platform. If all you want to support is one special platform you don’t need to go that way, but then it is also pointless to blame HTML5 issues for your decision.

HTML5 development is independent of platform and browser. If you don’t embrace that idea you limit its potential. Historically closed platforms came and went and the web is still going strong and allows you to reach millions of users world-wide and allows you to start developing without asking anyone for permission or having to install a complex development environment. This was and is the main reason why people start working with the web. And nobody is locked out, so have a go.

Yesterday Mozilla attended the HTML5 Developer Conference in San Francisco, California to give a keynote presentation. The very packed schedule of the conference already covered a lot of topics around the subject matter, which is why we considered it worth while to contribute with a talk that told tales from the trenches of advocating HTML5 instead of going into technical details. Under the title of “Broken Promises of HTML5 and what’s next?” we reported some of the findings we had when talking to press and people outside the web enthusiast sphere.

The Slides of the talk are available online and there is a screencast of the live presentation on YouTube.

The organisers of HTML5DevConf promised to release the video recording in the next few weeks.

Here are a few of the points covered to make it more interesting for you to check the 50 minute talk, in case you need more incentive:

Following the press around HTML5 lately we get more and more the impression that we are on the downward slope of the hype cycle about the cool new tech HTML5. The honeymoon period where every shiny HTML5 demo was heralded as the coolest thing and the future of the internet is over and business analysts and developers start feeling disappointed by what HTML5 is portrayed as. A lot of the things that get us as developers excited have been done in Flash years ago and performed better – even on the hardware of the day. The main mistake we seem to make when advocating HTML5 is not think about what makes it unique and how it is different than other approaches to bring higher fidelity to the web.

This talk covers a few ideas we can follow to turn the disappointment around. We will soon deliver a more in-depth article about this and are in talks with business analysts to make that message clearer. Some of the points mentioned here are allowing for re-use of existing knowledge with tools to get Flash developers to create HTML5 content, convert C++ to HTML5 for games using Emscripten (with Bananabread as the flagship demo) and in general not to think about what we can add but instead concentrate on what we can not remove to make our products web products and apps instead of simulating native and mobile apps.

It is up to us to move HTML5 from a flash in the pan to a productive platform, and we can do that by re-using existing knowledge and merge it with the web ideals and the basic principles of HTML5. We will not succeed by trying to replace other platforms that have a lot of knowledge and perform very well indeed.

There is a gap in the toolset of aspiring web makers and professional web developers at the moment: simple deployment. While it is easy to create a web site, set up a blog or even build your first HTML5 app, the deployment is still not as easy as it should be in this day and age. In the past we had to FTP, SCP or upload our content to a cloud provider. Nowadays systems like GitHub pages and Dropbox make the “putting things on the web” much easier, but still not quite a task that just happens without us having to put some effort in.

One of the companies in Mozilla’s WebFWD portfolio, Harp wants to change that. As mentioned on the portfolio:

From the creators of PhoneGap comes a new kind of development platform that leverages the power of Dropbox to give you the easiest development solution imaginable. Simply edit your HTML, CSS, and JavaScript files in your Dropbox folder and the Harp Platform does the rest. Harp is perfect for mobile applications, documentation sites, blogs, and HTML5 presentations. Regardless of your technical acumen, you will find harp to be an indispensable tool.

Harp is built by Rob Ellis, Brock Whitten and Jorge Pedret. In order to learn more about Harp, Chris Heilmann set out to interview Brock about the upcoming product. The video is available on YouTube and following are questions and answers with more details.

1) The site for harp.io is quite full of good promises, can you tell us in a nutshell what problem you are trying to solve with it?

Even for simple tasks todays development environments tend to be complex and more removed from the production system than it should be. Harp changes this by making development and production nearly one and the same so you can focus on shipping the next release of your application. It gives you an environment that doesn’t require any maintenance while still being sufficiently robust for most situations.

2) I’ve seen a lot of similar ideas offered on GitHub and blogs but a lot of them are not that easy to set up for non-developers. Are you trying to fill that gap?

It’s great to see this trend but removing the setup and maintenance process is the most important part in my opinion and these scripts don’t cover that. I feel people have been waiting for someone to take it to the next level and so thats what we’re doing, giving people a service to trust that takes care of this for them.

3) It seems to me that what you do relies heavily on Dropbox. What happens if they drastically change their API or approach? Just last year the whole “everything can be a link” replaced the old public folder.

Harp’s architecture has a clean disconnect from Dropbox and it was actually a somewhat recent decision not to offer Git as an alternate deployment mechanism in Harp. We have decided to start by testing how people respond to using Dropbox but we are prepared to adjustment to adding other tools if need be.

4) Are you thinking of expanding the idea to also allow for collaboration for designers? Seems to me that just using Dropbox is not working really for that.

I’m confident Harp will appeal to the designer crowd though we are not making many assumptions until we get feedback from our users during the public beta. I think we have come up with a core offering that will appeal to many people and we will have to wait and see where to take it from there.

5) What about native app development and packaging? Something like Google’s Yeoman or Twitter’s Bower? Maybe a collaboration with PhoneGap?

Absolutely. We are heavily exploring these sorts of ideas. Tools like Dropbox open up all sorts of new possibilities of automation in the cloud while still keeping things approachable for beginners. Initially though, we are focused on delivering a core product that will facilitate these sorts of features and partnerships moving forward.

6) You claim on the site that you also can “Learn to program” with harp. How does that work?

Harp doesn’t have anything specific for learning to program so that may have been unintentionally misleading. Harp is great though for someone getting started with HTML, CSS, and JavaScript because it removes everything else out of the way. This was an unintended but pleasant side effect.

7) Will any of your code be available as open source as well? Can people contribute?

Definitely. Not being a “lock-in” solution is an explicit goal of the Harp Platform and we love writing open source software. We want people to be able to easily run their applications on their own so we will facilitate that use case by opening up these core components. Actually, some of tools we use already are open source and have contributors. For example “node-dbox“, our library for speaking to the Dropbox API, is on GitHub and has 260 watchers, 44 forks, and 17 contributors.

Smashingconf this week attracted 350 web enthusiasts from all over to come to Freiburg, Germany. Workshops and talks by 16 international experts and speakers promised a good overview over what is happening right now.

Overall the conference was a great experience. Asking attendees why they came to the conference they said they wanted to learn what is new on the web. The mix of speakers and topics covered in the two days should have gotten them well on the way. Watch out for the videos of the event being released soon and meanwhile check the conference coverage on Lanyrd

The very obvious thing that made this conference different was the location. Freiburg is a very idyllic German city and the conference was held in a building that looked like something out of a fairytale from the outside and sported plush red chairs and chandeliers on the inside.

Mozilla’s part in the proceedings was sending Chris Heilmann to give the closing keynote of the conference.

The keynote slides are available in HTML format. Simply click any to go into presentation mode and move with the cursor keys. Fore more information stay in list mode and roll over each slide to see the notes.

There is also a screencast of the talk on YouTube complete with bell sounds of the nearby church.

Smashing Magazine also published the original notes as a post. The event was also filmed and the videos will be out soon. Mozilla projects covered and shown in the talk are: Webmaker, Firefox OS, Developer tools, X-Tag, Emscripten/Bananabread and Thimble.The initial response was pretty overwhelming. Here are the immediate tweets.

We thank the Smashingconf organisers for asking us to come and have no qualms about doing it again next year.

I just spent a weekend in a resort in Mallorca. I was invited by an IT consultancy from Frankfurt to join them at their off-site and give a two hour (re)introduction to HTML5.

The audience and the challenge

The consultancy is very successful in what they do and are very much a Java / native code shop. Their clients are insurance companies, banks and the like which means the topic of HTML5 came up only peripherally in their discussions. With more and more clients looking for iPad apps and other demands for cross-platform solutions they wanted to know more about HTML5, what is possible and what can be done.

This sounded like a great opportunity to go out of my comfort zone and see how good my skills as an advocate for web technology are. Ever the optimist, I also considered this a great opportunity to inspire in a field in which IT is used to make a difference to the lives of a lot of people. So I said yes.

The presentation

Without any preparation (there was no time), without knowing who the audience will be (turns out it was the whole company, including non-technical employees and some contractors) and being asked to deliver the talk in German I found myself in front of a room with about 70 people, set up my computer (which failed to do so the first time, it will go to the farm of old computers soon), happily realised that the WIFI worked and went right into it.

Instead of talking about HTML5 in isolation, I thought it best to show off the web as a development platform and the advancements that happened in the last few years that may not be known. Turns out this was exactly what was needed and I’ve had a lot of 1:1 conversations later on with people who want to seriously give HTML5 a go. Their idea is converting some of the tools used now in the company to move from Java and fixed-size, Photoshop driven interfaces to more flexible solutions using HTML5 and JavaScript. Score, I’d say.

What I’ve done

Seeing that it was more or less an open 2.5 hours show and tell with questions from the audience I have no notes. So here is a list of the things I showed and mentioned which had quite some impact and the techniques how I presented them.

Laying the groundwork

I started by explaining the need for HTML5 (document to app transition) and that with a unified and defined HTML parser, we finally have a level playing field across browsers. I explained that a face to face comparison of HTML5 apps and native apps is not fair as the performance of browsers and webviews is hindered in many cases by hardware and the OS. Which means that browers can not use the same resources native code can which of course is a difference in performance. That said, web apps can be more nimble and update much easier than native ones.

In the spirit of pre-emptive writing I also took the Mark Zuckerberg quote from TechCrunch disrupt a few weeks ago and explained that he didn’t say that HTML5 was a mistake but that the way they approached it was. I also pointed out his quote stating that Facebook’s number of mobile web users are more than the ones of Android and iOS combined.

Techniques

I think the most impactful part of the presentation was that I didn’t prepare any slides but used the browser to show everything to the audience. I used Mozilla Thimble to show live code and the immediate impact of my changes. I used the developer tools in Firefox and Chrome to show how to change a live site and try out some of the new technology in existing pages instead of showing demos that are impressive but don’t apply to the audience.

Platform demos

All in all my aim was to show that HTML5 is an interesting thing to bet on as it is part of the web ecosystem. This means instead of starting with code I showed:

• Collaborative editing using online editors
• GitHub as a place to get code, meet other developers and submit fixes
• Developer tools of browsers to show that now we can test and fix things outside of a code first, deploy, find bug development cycle
• MDN as a resource for demos and documentation
• Browserstack.com to test on browsers and operating system you don’t have

Technology demos

The technology demos were simple, but I got lots of good feedback on them as I kept them relevant.

• Introducing HTML5 form elements and showing that simply adding a number attribute and a required attribute means that this field will always be a number and users can not send the form (in the browser) without satisfactorily having filled the field. This means there is no need for writing client-side validation any longer which is a big headache for non-JavaScript enthusiasts.
• Adding a video element in the page, playing it with a right-click, adding the controls attribute to add controls and adding a CSS transformation (rotation for example) to prove that video is just another page element in a HTML5 world.
• Showing a simple example on how to use MediaQueries to do responsive designs and showing the Responsive Mode in the Firefox developer tools
• Showing a simple hover state in CSS and adding a transition to prove that these days you can make things look smooth very simply without having to add another JavaScript
• Showing how to progressively enhance a simple HTML document using some CSS transitions to make it look much more engaging.
• Showing the simplicity of local storage (using the 123done task list example) and explaining how AppCache and manifest files can turn a web page into a locally cached app.
• Showing how easy it is to plot something in the page using Canvas and explaining that canvas using drag and drop can also allow for image cropping and thumbnail generation.
• Showing that file uploaders can be much more convenient for the end users these days with the Flickr image uploader as an example
• Showing how to make a video interact with web content using Mozilla Popcorn – explaining that this could be used for interactive training materials

Near future gazing

As requested by the audience I also showcased some of the near-future parts of web tech:

• The toycam demo explaining that it uses WebRTC which can be used to get video input and manipulate it using WebGL live in the browser. I also pointed out that WebRTC is not limited to that but could be used for all kind of other data streaming tasks
• Firefox OS, how it is architected and why we do it
• Mozilla’s Web APIs and how they are used in Firefox OS (showing the FFOS desktop build, playing with the dialer and showing that even they keytones are created using JavaScript)
• Explaining Persona and how it allows you to simply verify users on the web without having to ask for a username and password
• Showing off the Banabread demo and explaining how it was done by converting C++ code using Emscripten
• Showing the Mozilla App store preview and how an HTML5 app can be installed natively and run from the Application folder and full-screen

Your turn

All in all I have to say this was thoroughly enjoyable and I got out of it with a sense of satisfaction of having narrowed the gap between the webdesign world and the world of corporate IT a bit more. Give it a go, too, I am sure you’ll enjoy it.

As a warm-up for Mozcamp happening in Warsaw, Poland this weekend the Mozilla DevEngage team together with Reaktor Warsaw gave around 100 developers and entrepreneurs a first look at Firefox OS and the upcoming infrastructure Mozilla is working on to enable Open Business.

Chris Heilmann and Brian King had an hour to bring our messages across before the crowd descended on the Pizza and drinks and more informal but not less animated, smaller discussions ensued.

Reaktor filmed and live-streamed the session, and you can also watch the recording online.

The slides to our talks The road to a truly open mobile operating system and Open Web, Open Business are available on the web.

All in all this was a great evening and we want to thank OpenReaktor for having us and doing a great job in streaming and producing the recording. We had a lot of engaging discussions with the attendees and see what else we can do in the future.

At Mozilla, we are dedicated to keep the web open and independent of a single company or technology. This means that users should have a choice of browsers and technology to use to go online and should not be blocked out because they can’t afford a certain device or are forbidden to change their browser.

In the world of mobile web development there is currently a massive debate going on about the need for support of various browsers seeing that the most successful phone systems both use the same browser engine. This is good, and we need this debate. It is not good though when developers block out users because they concentrate on targetting a browser. Sometimes this is not by choice of the developer – they are simply using tools that do that blocking for them and the usefulness of the tool outweighs the qualms developers have about that.

We are currently talking to library and tool developers and help them support more than one browser engine to prevent this. As a start of that process we wanted to get a glimpse of what people are using right now so we make sure we have the most impact when we help. This is why we conducted an online survey asking developers about their tools for mobile development.

590 developers took the survey and we are thankful for them spending their time giving us a lot to ponder and think about.

We are very aware that this is *not* a scientifically clean research and should be taken with a grain of salt (we haven’t asked how many times people used the tools or how much of their work is building mobile apps) but it gives us a good idea of what is going on.

So without further ado, here are the numbers as charts with a quick commentary:

Platforms

A lot of developers showed their love for the web in this survey, but then again it was a survey initiated by Mozilla. Most likely an Apple-lead survey would have different results. iOS and Android are the follow-up and Windows Phone and Blackberry are less of a concern for the developers who filled the survey. This, of course, could differ greatly were we do to this survey targetted to different markets. Interesting that in the case of Android the amount of “must have” is higher than “focus” – the only platform showing this.

You can compare the results dynamically here.

What platforms are you targeting with your apps – Web
	focus 370 63% must have 153 26% supported 33 6% sometimes 23 4% not at all 11 2%

What platforms are you targeting with your apps – iOS
	focus 261 44% must have 207 35% supported 53 9% sometimes 28 5% not at all 41 7%

What platforms are you targeting with your apps – Android
	focus 182 31% must have 221 37% supported 102 17% sometimes 47 8% not at all 38 6%

What platforms are you targeting with your apps – Windows phone
	focus 10 2% must have 46 8% supported 131 22% sometimes 173 29% not at all 230 39%

What platforms are you targeting with your apps – Blackberry
	focus 8 1% must have 15 3% supported 100 17% sometimes 164 28% not at all 303 51%

People may select more than one checkbox, so percentages may add up to more than 100%.

Libraries

In the world of libraries jQuery and jQuery mobile very much took the lead with more than 200 more uses than the next follower Zepto.js. A lot of feedback was that developers don’t like libraries and use their own hand-rolled solutions on mobile instead. While it is good to see that libraries that work cross-browser are the most used ones (jQuery just announced that they happily support Firefox mobile), the high number of Sencha users is worrying and we’ll see how we can help make their cross-browser support better. Sencha was also mentioned a lot in the “why webkit only” question which shows that it is an important tool for developers.

What libraries do you use to build mobile web apps/sites?
	jQuery 437 74% jQuery mobile 301 51% Zepto.js 116 20% JO 5 1% XUI.js 23 4% Sproutcore 9 2% Sencha touch 88 15% JQTouch 61 10% Mootools mobile 16 3% M project 1 0% Nimblekit 2 0% Lime.js 10 2% Wink 2 0% Uxebu Bikeshed 1 0% Other 152 26%

People may select more than one checkbox, so percentages may add up to more than 100%.

All in all we collected 66 libraries (in order of popularity): jQuery, jQuery mobile, Zepto.js, Sencha Touch, JQTouch, XUI.js, Backbone, Mootools mobile, Lime.js, Sproutcore, Angular JS, Underscore, Bootstrap , Enyo, Modernizr, Dojo, handlebars, JO, Closure, Dojo Toolkit, GWT, Hammer.js, iScroll, require.js, YUI, Chibi, Ember.js, Kendo, Kinetic, Lungo.js, Nimblekit, Prototype, Wink, Adobe Air, Atto, Box2D, ChesterGL, Cobra, Crafty, Cujo, d3.js, Dart , Dojo Mobile, Dojo Mini, enhance.js, Eyebrow.js, fitml, gl-matrix, H5BP, JQMobi, Javelin, Jukebox, Knockout, MProject, Mootools, Openlayers, Path , Playcanvas, pointer.js, Raphael, Sugar.js, TerrificJS, Thorax, Titanium Mobile, Uxebu bikeshed, Wakanda

Conversion frameworks

There is no doubt that Phonegap / Cordova rules this segment of the market followed by Appcelerator. Quite a lot of feedback was also people claiming that native apps should be coded natively. Being a web evangelist, I disagree as you can not convert from native to web but the other way around, but it is interesting to see that developers felt the need to have their say here.

Which frameworks do you use to convert apps to native apps?
	PhoneGap 325 90% Appcellerator 50 14% MoSync 2 1% Other 38 10%

People may select more than one checkbox, so percentages may add up to more than 100%.

All in all we collected 13 conversion tools (in order of popularity): Phonegap, Adobe Air, Apache Cordova, Cocoon.js, Brightcove App Cloud, Mosync, Sencha Native SDK, appMobi, Flex Mobile, Mobileweb, Monotouch and backbone.

Visual editors

Not many developers seem to use visual editors, which is probably because most of them are still in a “beta” or “alpha” stage. It would be interesting to do the same survey with Flash developers who are moving towards HTML5 and see if the numbers are higher. As it stands, Adobe Edge and Sencha Animator are the clear winners, and some of the entries were interesting including one “you got to be kidding me” :).

Do you use any visual tools/converters to build apps? If so, which?
	Adobe Edge 19 36% Sencha Animator 10 19% Other 25 47%

People may select more than one checkbox, so percentages may add up to more than 100%.

All in all we collected 17 editors (in order of popularity): Adobe Edge, Sencha Animator, Adobe Dreamweaver, Adobe Flash, Adobe Photoshop, Codiqua, Construct 2, Hype, Playcanvas , Radi, Rhodes, Telrik, Tiggzi, Tiler, Wakanda, Web Developer Add-on, WebMatrix

Webkit only?

71% of developers filling out the survey said they test for more than Webkit browsers and in the general feedback section of the survey we had a lot of information as to how people are testing and what would make things much easier for them. This makes us happy of course.

Do you test on non-Webkit browsers?
	Yes 421 71% No 169 29%

Reasons to test for webkit only

The main reason here is a lack of time to test on other platforms which is understandable – we can assume that a lot of projects from a planning perspective have 99% iOS/Android written all over them. The “lack of incentive” number is high, too, which is understandable – if you can’t show the numbers, you don’t get the time to support. The high number of “not supported on hardware” is of course another very understandable reason and we wished there would be a way to change this.

Fixed environment defined by client needs		46	24%
Lack of time to support more browser platforms		103	55%
Lack of incentive – I don’t know what the benefit of supporting more is		79	42%
Lack of documentation how to install and debug on non-webkit browsers		43	23%
Bugginess of other browsers on test platforms		31	16%
Lack of support for other browsers on target hardware		68	36%
Other		20	11%

People may select more than one checkbox, so percentages may add up to more than 100%.

Webkit only technology

The question “What technologies/features do you use on Webkit browsers that are crucial for you and not available on others?” was answered by 135 developers and only partly answered what we needed to know. A lot of it wasn’t features of Webkit but general speed and availability reasons that are reliant on the operating system and the hardware. A lot of the answers also simply stated that these browsers come with the hardware which means end users have them and developers don’t have an overhead of installing other browsers or tools. However, quite a few developers praised the predictability of a “one browser platform web” and not having to worry about vendor prefixes and differences in html5 support.

What can mobile Firefox do better?

The question “If yes, what could Firefox mobile provide to make your life easier?” got around 230 answers and is a great resource for us to improve the browser. The message that came across loud and clear was the need for remote debugging for Firefox Android which was just announced here on the hacks blog. It is obvious that developers do not want to have a long gap between writing code and seeing the results on their phones – very understandable indeed. Quite in demand was also a native simulator for the Desktop to avoid the need of having a phone at all. Another thing that stood out was support for older and more hardware.

Anything else?

The “Anything else you want to get heard?” question got 73 answers with a lot of great feedback, especially praise for what is happening right now in the world of Mozilla and some very detailed concerns of developers. We now have a great time going through these answers and will see how we can accelerate a few of the demands in our next browser builds.

Check the results

We’ve uploaded the anonymised answers as a spreadsheet to Google Docs, so feel free to read and dig at your own leisure: Mozilla libraries survey.

A huge Thank You

Last but not least, we want to say Thank you! to everyone who participated. We now have a lot of insightful information and can focus our outreach to frameworks, tools and libraries that will have the most impact when it comes to supporting a cross-browser web. We were also very positively surprised that the trolling and fanboi-ing was kept to a bare minimum – this showed us that the topic really is important for all developers out there.

About a month ago Chris Heilmann of Mozilla went to Miami, Florida to shoot a series of training videos with Rey Bango of Microsoft.

Now these videos are available on Microsoft’s Channel9 as the FoxIE training series.

In a very off-the-cuff discussion format between Rey and Chris we covered a few topics:

• Introducing FoxIE has us introducing the series and frolick on the beach (notice the uncomfortable expression of the ginger in the sun)
• Web tools and browser testing covers ways to ensure cross-browser support during development
• The great divide: coping with modern and legacy browsers teaches you how to treat the elderly (IE6) with respect without blocking the next generation
• Implementing modern web standards talks about how to embrace standards and write predictable code
• HTML5 and modern web development talks about the new and cool and how to use it without blocking people out

If you want to present the Mozilla talks yourself, we uploaded the slides in various formats and the code examples with lots of explanations on how to present them to GitHub:

• Building for real standards
• Modern Web Development

All the videos are available in HTML5 format and to download as MP4 and WMV for offline viewing.

If you are a Firefox user and you start the browser this morning or you type “about:home” in the URL bar we have a surprise for you. Instead of the Firefox logo you’ll see an animation celebrating the global spirit of community. This is just one of many planned enhancements to mozilla.org pages and mozilla communication channels.

To give you a peek under the hood and insight as to how this was made, we asked Bruce MacFarlane from Particle a few questions about the animation. Particle has been working with the top silicon valley companies exploring ways to use HTML5 and CSS since their beginning. They have a unique blend of talent that hovers between creative development and engineering which allows projects like this possible.

1) Hi there, when you get asked to do an animation like that, what is the creative process? Do you make sketches, animate in a tool like Flash or Maya or do you start right away with the code?

I find it helpful to sit with a step-by-step list of what is going to happen and really try to visualize the entire animation, getting a feel for how it will most likely function under the hood. If there’s anything I’m not quite sure how to handle I’ll break that out into a separate proof of concept sandbox file where I can just focus on that one thing and make sure I get it right. After that it’s easy to put all the parts together.

2) What is the main technology behind the animation? Canvas? CSS? And why did you choose it?

The animation was done entirely in CSS to take advantage of it’s ease of use and fluidity.
Although something similar could have been accomplished with Canvas, going that route would have required a lot more setup code and we wouldn’t have been able to take advantage of CSS3′s handy timing functions.

Also, being able to fire animation sequences with class names the same way you would work with basic styling is a huge plus.

In the case of this animation we were able to define just one keyframe that played with scaling and opacity, then applied that to all five flame layers, having the variations coming from just playing with the animation durations and delays.

3) I assume that the start page of Firefox is a special environment. What were the limitations you had to work around in terms of performance and connectivity?

Since the code that runs the animation is being loaded onto a pre-existing page, we do end up having to do a little bit of logic when it loads to adjust some of the initial content and move our new content into position before running the animation.

A Snippet is a single file of code that gets loaded onto a pre-existing page, therefor certain considerations have to be made. To remove additional requests for assets, any images have to be base64 encoded and entered directly in the code. This is much easier than it sounds. There are plenty of websites out there where you can upload an image and have it give you back it’s base64 encoding. I tend to use a couple of simple PHP commands that accomplish the same thing:

$image = file_get_contents('image.png'); 
$imagedata = base64_encode($image); 
echo($imagedata);

Also if an animation has to interact with content that’s already on the screen (and may be positioned relatively, which can cause problems with animations) a certain amount of work has to be done to structure the previous content to work with the new content (wrapping the moving parts in a container that can still move in relation to window size so you can absolutely position elements within that you need to, etc.).

4) When optimising you sometimes find yourself having to do the same tasks over and over again and build tools to do them. Did you use already existing tools or are you building some?

Developing on Macs we end up using the ‘Activity Monitor’ utility app quite a lot which can really help with monitoring memory and CPU usage. About:home snippets are a unique animal in that only Firefox users ever see them. For sites and web applications that are being viewed on a diversity of devices and browsers we have developed some internal tools that help simplify compatibility issues and greatly aid in the quick construction of projects that we’ll be releasing soon.

5) With your experience in this, do you think there is a market for animation tools that have output like the code you did? Do you know of any yet? There were a few around a year ago (Adobe Edge, Animatable…), but I haven’t seen any being pushed heavily.

There are definitely some animations where the keyframes can get so complex that these sorts of tools could help out a lot and save time. We don’t have a favorite yet, but we’re keeping our eyes open.

6) What about legacy support? Is it worth testing and tweaking on older browsers or does it make more sense to have a static image fallback?

It is always important to support a certain amount of legacy browsers, static image fallbacks can sometimes be your only reasonable choice.

7) If developers wanted to start with their own similar animations, what would you say is the biggest time-sink to avoid? What are good shortcuts?

It’s sometimes easy to get bogged down in animations that have a lot of moving parts, and go on for a long time. In those situations I find it helps to break things down into scenes that can be fired off with parent container class names.
Sometimes in those scenes I’ll apply the same animation duration to each element and work within the keyframe percentages to handle timing. This way it’s easy add adjustments to individual elements during the timeline later.

Thanks Bruce.

What do you think? Expect to see more experiments like this showing off new technologies. Anything you’d like to see, or information you’d want us to publish? Just comment below.