Animating like you just don’t care with Element.animate

In Firefox 48 we’re shipping the Element.animate() API — a new way to programmatically animate DOM elements using JavaScript. Let’s pause for a second — “big deal”, you might say, or “what’s all the fuss about?” After all, there are already plenty of animation libraries to choose from. In this post I want to explain what makes Element.animate() special.

What a performance

Element.animate() is the first part of the Web Animations API that we’re shipping and, while there are plenty of nice features in the API as a whole, such as better synchronization of animations, combining and morphing animations, extending CSS animations, etc., the biggest benefit of Element.animate() is performance. In some cases, Element.animate() lets you create jank-free animations that are simply impossible to achieve with JavaScript alone.

Don’t believe me? Have a look at the following demo, which compares best-in-class JavaScript animation on the left, with Element.animate() on the right, whilst periodically running some time-consuming JavaScript to simulate the performance when the browser is busy.

Performance of regular JavaScript animation vs Element.animate()To see for yourself, try loading the demo in the latest release of Firefox or Chrome. Then, you can check out the full collection of demos we’ve been building!

When it comes to animation performance, there is a lot of conflicting information being passed around. For example, you might have heard amazing (and untrue) claims like, “CSS animations run on the GPU”, and nodded along thinking, “Hmm, not sure what that means but it sounds fast.” So, to understand what makes Element.animate() fast and how to make the most of it, let’s look into what makes animations slow to begin with.

Animations are like onions (Or cakes. Or parfait.)

In order for an animation to appear smooth, we want all the updates needed for each frame of an animation to happen within about 16 milliseconds. That’s because browsers try to update the screen at the same rate as the refresh rate of the display they’re drawing to, which is usually 60Hz.

On each frame, there are typically two things a browser does that take time: calculating the layout of elements on the page, and drawing those elements. By now, hopefully you’ve heard the advice, “Don’t animate properties that update layout.” I am hopeful here — current usage metrics suggest that web developers are wisely choosing to animate properties like transform and opacity that don’t affect layout whenever they can. (color is another example of a property that doesn’t require recalculating layout, but we’ll see in a moment why opacity is better still.)

If we can avoid performing layout calculations on each animation frame, that just leaves drawing the elements. It turns out that programming is not the only job where laziness is a virtue — indeed animators worked out a long time ago that they could avoid drawing a bunch of very similar frames by creating partially transparent cels, moving the cels around on top of the background, and snapshotting the result along the way.

Example of cels used to create animation frames

Example of creating animation frames using cels.
(Of course, not everyone uses fancy cels; some people just cut out Christmas cards.)

A few years ago browsers caught on to this “pull cel” trick. Nowadays, if a browser sees that an element is moving around without affecting layout, it will draw two separate layers: the background and the moving element. On each animation frame, it then just needs to re-position these layers and snapshot the result without having to redraw anything. That snapshotting (more technically referred to as compositing) turns out to be something that GPUs are very good at. What’s more, when they composite, GPUs can apply 3D transforms and opacity fades all without requiring the browser to redraw anything. As a result, if you’re animating the transform or opacity of an element, the browser can leave most of the work to the GPU and stands a much better chance of making its 16ms deadline.

Hint: If you’re familiar with tools like Firefox’s Paint Flashing Tool or Chrome’s Paint Rectangles you’ll notice when layers are being used because you’ll see that even though the element is animating nothing is being painted! To see the actual layers, you can set layers.draw-borders to true in Firefox’s about:config page, or choose “Show layer borders” in Chrome’s rendering tab.

You get a layer, and you get a layer, everyone gets a layer!

The message is clear — layers are great and you are expecting that surely the browser is going to take full advantage of this amazing invention and arrange your page’s contents like a mille crêpe cake. Unfortunately, layers aren’t free. For a start, they take up a lot more memory since the browser has to remember (and draw) all the parts of the page that would otherwise be overlapped by other elements. Furthermore, if there are too many layers, the browser will spend more time drawing, arranging, and snapshotting them all, and eventually your animation will actually get slower! As a result, a browser only creates layers when it’s pretty sure they’re needed — e.g. when an element’s transform or opacity property is being animated.

Sometimes, however, browsers don’t know a layer is needed until it’s too late. For example, if you animate an element’s transform property, up until the moment when you apply the animation, the browser has no premonition that it should create a layer. When you suddenly apply the animation, the browser has a mild panic as it now needs to turn one layer into two, redrawing them both. This takes time, which ultimately interrupts the start of the animation. The polite thing to do (and the best way to ensure your animations start smoothly and on time) is to give the browser some advance notice by setting the will-change property on the element you plan to animate.

For example, suppose you have a button that toggles a drop-down menu when clicked, as shown below.

Example of using will-change to prepare a drop-down menu for animation

Live example

We could hint to the browser that it should prepare a layer for the menu as follows:

nav {
  transition: transform 0.1s;
  transform-origin: 0% 0%;
  will-change: transform;
nav[aria-hidden=true] {
  transform: scaleY(0);

But you shouldn’t get too carried away. Like the boy who cried wolf, if you decide to will-change all the things, after a while the browser will start to ignore you. You’re better off to only apply will-change to bigger elements that take longer to redraw, and only as needed. The Web Console is your friend here, telling you when you’ve blown your will-change budget, as shown below.

Screenshot of the DevTools console showing a will-change over-budget warning.

Animating like you just don’t care

Now that you know all about layers, we can finally get to the part where Element.animate() shines. Putting the pieces together:

  • By animating the right properties, we can avoid redoing layout on each frame.
  • If we animate the opacity or transform properties, through the magic of layers we can often avoid redrawing them too.
  • We can use will-change to let the browser know to get the layers ready in advance.

But there’s a problem. It doesn’t matter how fast we prepare each animation frame if the part of the browser that’s in control is busy tending to other jobs like responding to events or running complicated scripts. We could finish up our animation frame in 5 milliseconds but it won’t matter if the browser then spends 50 milliseconds doing garbage collection. Instead of seeing silky smooth performance our animations will stutter along, destroying the illusion of motion and causing users’ blood pressure to rise.

However, if we have an animation that we know doesn’t change layout and perhaps doesn’t even need redrawing, it should be possible to let someone else take care of adjusting those layers on each frame. As it turns out, browsers already have a process designed precisely for that job — a separate thread or process known as the compositor that specializes in arranging and combining layers. All we need is a way to tell the compositor the whole story of the animation and let it get to work, leaving the main thread — that is, the part of the browser that’s doing everything else to run your app — to forget about animations and get on with life.

This can be achieved by using none other than the long-awaited Element.animate() API! Something like the following code is all you need to create a smooth animation that can run on the compositor:

elem.animate({ transform: [ 'rotate(0deg)', 'rotate(360deg)' ] },
             { duration: 1000, iterations: Infinity });

Screenshot of the animation produced: a rotating foxkeh
Live example

By being upfront about what you’re trying to do, the main thread will thank you by dealing with all your other scripts and event handlers in short order.

Of course, you can get the same effect by using CSS Animations and CSS Transitions — in fact, in browsers that support Web Animations, the same engine is also used to drive CSS Animations and Transitions — but for some applications, script is a better fit.

Am I doing it right?

You’ve probably noticed that there are a few conditions you need to satisfy to achieve jank-free animations: you need to animate transform or opacity (at least for now), you need a layer, and you need to declare your animation up front. So how do you know if you’re doing it right?

The animation inspector in Firefox’s DevTools will give you a handy little lightning bolt indicator for animations running on the compositor. Furthermore, as of Firefox 49, the animation inspector can often tell you why your animation didn’t make the cut.

Screenshot showing DevTools Animation inspector reporting why the transform property could not be animated on the compositor.

See the relevant MDN article for more details about how this tool works.

(Note that the result is not always correct — there’s a known bug where animations with a delay sometimes tell you that they’re not running on the compositor when, in fact, they are. If you suspect DevTools is lying to you, you can always include some long-running JavaScript in the page like in the first example in this post. If the animation continues on its merry way you know you’re doing it right — and, as a bonus, this technique will work in any browser.)

Even if your animation doesn’t qualify for running on the compositor, there are still performance advantages to using Element.animate(). For instance, you can avoid reparsing CSS properties on each frame, and allow the browser to apply other little tricks like ignoring animations that are currently offscreen, thereby prolonging battery life. Furthermore, you’ll be on board for whatever other performance tricks browsers concoct in the future (and there are many more of those coming)!


With the release of Firefox 48, Element.animate() is implemented in release versions of both Firefox and Chrome. Furthermore, there’s a polyfill (you’ll want the web-animations.min.js version) that will fall back to using requestAnimationFrame for browsers that don’t yet support Element.animate(). In fact, if you’re using a framework like Polymer, you might already be using it!

There’s a lot more to look forward to from the Web Animations API, but we hope you enjoy this first installment (demos and all)!

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Treat Open Source Like a Startup

What am I getting myself into?

I was never an open source contributor. I had never even filed a GitHub issue. I considered myself an entrepreneur who simply happened to be technical.

But when the startup I wanted to build needed something that didn’t exist, I followed an unprecedented whim and paused everything I was working on. I pulled a hard left, and I wound up spending three months working full-time on a project that I needed ASAP. Equally as motivating, I knew that other developers needed it too.

So, I switched hats. I became an insanely focused, sleeping-isn’t-allowed developer.

The outcome was an animation engine that drastically improved UI performance and workflow across all devices. See it at It’s a powerful JavaScript tool that rivals the performance of CSS transitions. The trick? Simple: In contrast to jQuery (which was initially released in 2006), I was building an engine that incorporated 2014’s performance best practices from the ground-up. No legacy layers; no bloat. Not a Swiss Army knife; a scalpel.

But, throughout my solitary confinement, I was genuinely concerned that I was building something for a customer base of one — myself.

I eventually came to realize that switching hats was actually the wrong approach. I was never supposed to take my startup hat off. (Since normal people don’t wear two hats at once, this is where my metaphor breaks down.)

This is the story of that realization.


Let’s momentarily jump ahead three months — to the time of Velocity’s release. Pardon me for a moment while I gloat:

  • Within three days, Velocity reached the top of Hacker News and programming subreddits a total of four times.
  • Within nine days, Velocity amassed 2400 GitHub stars.
  • Within two weeks, Velocity topped the CodePen charts with multiple demos reaching 10,000 views each (, and
  • Countless business, front-end platforms, and web agencies migrated to Velocity (examples:,,

How was this possible? Because I treated Velocity like I treated my businesses: First, there’s development. That’s 10%. Then, there’s marketing. That’s 90%.

The perspective shift I underwent midway through development was to commit to the following mantra: However much time I wound up spending on development, I would spend even more time on marketing.

After all, that was the time-split I experienced with my startups. I didn’t see a single reason why it should be different for this project. User acquisition is user acquisition.

Ultimately, if you develop a startup or an open source project intended for public use, and nobody uses it… you failed. It doesn’t matter how clever it was. It doesn’t matter what technical challenges you overcame.

Unfortunately, however, the peculiar reality of OSS growth hacking is that there’s a stigma attached to it: The act of marketing invokes pitching, rubbing shoulders, begging, and bribing. It’s stereotypically personified as an overeager, two-bit hustler wearing a cheap shirt and an even cheaper tie. This clashes with our ideals of open source — which itself is stereotypically personified as a headstrong and idealistic code warrior wearing a cheap shirt and an even cheaper haircut.

I’ll quote GitHub’s Zach Holman to get to the root of the dichotomy, “We like to think that open source is pure; that it’s unadulterated. That marketing an open source project is silly. That’s just silly.” –

To put it bluntly, if you want your open source project to have an impact, you need to step out of your coder bubble. After all, if you build something amazing — and you market it effectively — you’re doing everyone a favor. Not just yourself.

The best part is, the more people that know about your work, the more people there are to contribute: Bugs get discovered sooner. Useful features get pitched more often.

And don’t worry — being seen publicly marketing your project doesn’t frame you as an egotistical developer. It frames you as someone who’s passionate. If you take the time to appreciate the fact that more people benefiting from your hard work is a major motivation in your pursuit of open source, then you’ll realize that hustling on behalf of your project fits exactly within your pre-existing ideals.

Open source growth hacking

If you look closely at the current open source landscape, those who most often reach the top of GitHub’s charts are developer figureheads with pre-existing followings, and major companies sharing components of their internal stack.

Looking at this month’s GitHub’s trending chart, the top ranking projects that aren’t educational resources (link collections, tutorials, etc.) include: Pop (Facebook), Atom (GitHub), Quill (Salesforce), Velocity (Me!), Mail-in-a-Box (individual), Famous (Famous), syncthing (individual), betty (individual), Isomer (individual), Bootstrap (Twitter), Angular (Google), PourOver (NY Times).

There’s a fair representation of individuals in there, but it’s typically corporations that dominate open source marketing. The reality, however, is that these corporations employ developers that are no better than you or I. There’s no inherent natural selection driving the popularity of their projects versus yours

Fight to get your project out there. Or sit back and watch the marketing teams of huge companies drown your voice out.

Velocity.js CodePen Demo

That’s enough with waxing poetic and analyzing the current landscape. Let’s dive into the meaty details: How exactly did I market Velocity?

  • I pre-wrote advanced drafts for major web development blogs to consider publishing. By presenting the editors with the full goods upfront — not a pitch, not an outline — I minimized their workload, making it very easy for them to say “yes.” I also made sure to wait until I had enough GitHub stars (from Hacker News coverage, etc.) before pitching. And, most importantly, I had a strong thematic focus for each article: One article was exclusively about performance, and the other was exclusively about UI workflow. In both cases, I minimized the amount of attention spent pitching Velocity, and focused instead on educating readers about the respective topic. Blogs don’t want to publish a giant ad on your project’s behalf; they want content that their readers will thank them for.
  • I found out where my power-users were. This advice is common in the startup world: Find your core 1,000 early adopters. It’s no different with open source. Who were the users that craved for a performant animation engine — that would do amazing things with it then show off their exploits to the world without me prompting them to? Web animation demo-sceners — that’s who; the passionate, hard-core devs who explore the intersection of technology and design. And, where do they hang out? I reached out to the demoers whose work I greatly admired, and I gave them access to a pre-release version of Velocity. Sure enough, they eventually pumped out something amazing for me to share.
  • To ensure that new developers always stumble into Velocity.js — even far past the point that I’m still proactively marketing the project — I embedded Velocity into every popular web developer resource that I could find. I pull-requested and the popular GitHub repo for front end bookmarks. I pitched the Treehouse video blog guys. That was all just the start. I also have upcoming codecasts on Velocity’s workflow that code schools will be presenting to their students. Simply put, I made sure that every developer trying to master web animation would at some point hear about Velocity.
  • Most importantly, I wrote great documentation. To quote GitHub’s Zach Holman once again, “Documentation is marketing. The best part is that documentation is linkable. It’s indexable. It’s tweetable. Particularly if you have a nice, coherent one-page overview of your project that lets people jump in and immediately ‘get’ it.” To expand on Zach’s thoughts, I would frame an open source project’s documentation as what a landing page is to a startup. And make no mistake, you do have to pitch; you can’t merely document your API and call it a day. The developers reading your documentation are no different than anyone else; they have limited time, and they need to be convinced that your project is worth considering.

When you have great documentation, posting to Reddit and Hacker News will take care of itself. Developers recognize their peers’ hard work, and they’re happy to spread the word.

On this topic, do you know what the best-kept secret about open source marketing is? That it’s 100x times easier than startup marketing. It’s less work, and you’ll see success with a much greater degree of certainty. Why? Because developers — as compared to the average web user — are more willing to listen, are more willing to retweet, and are generally less skeptical of your marketing claims. Whereas most web users are tired of being pitched with trite social media products, developers are always on the hunt for better tools. Similarly, the web development press is much easier to get a response from than the mainstream tech news press is. The former is scrounging for good content to share with their users whereas the latter is drowning in a sea of half-backed startup pitches.

Because of the marketing efforts I put into Velocity, and because of the project’s ensuing success, I have become highly motivated to continue working on open source projects.

I am only just getting started: Velocity is the first in a trilogy of libraries that aim to change the way we visually interact with software. If you’re interested in staying on top of my UI exploits, say hello on Twitter: @Shapiro.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Automating typing in screencasts with AppleScript or how to look like a hollywood hacker

Update: The awesome that is Stuart Langridge also created a way to do what we describe here with a plugin for Sublime Text 2. Read his blogpost to learn how

We’re busy creating a lot of screencasts for the Firefox Developer tools at the moment and it isn’t as easy as the final products make it out to be. One of the biggest issues is typing along as you speak. First of all, this is hard to do. Secondly, people keep forgetting to use an external microphone on a headset which makes the screencast sound like a bad drum and base session.


Fret not, for my esteemed colleague William Bamberg came up with an ingenious way to work around the problem. All of this is on a Mac, so if you don’t have one, please add the info how other systems can do the same on the Wiki.

The trick is to use AppleScript to automate the typing of a certain piece of text in an editor.

You write a script using the AppleScript Editor and save it, then you use a tool like FastScripts to assign it to a keystroke and voilà, you look like a hacker in a hollywood movie.

This is the script I am using to type the content of the file /your/script.js in Brackets (I tried my normal weapon of choice – Sublime Text 2 – but it does too many clever auto indenting and closing of braces things that do mess up the output).

set fc to read POSIX file "/your/script.js" as «class utf8»
set the text item delimiters to (ASCII character 10)
set mylines to text items in fc
repeat with currentline in mylines
end repeat
on write_string(the_string)
  tell application "System Events"
    tell application "Brackets Sprint 15" to activate
    repeat with the_character in the_string
      keystroke the_character
      delay 0.05
    end repeat
    key code 36
    key code 123 using command down
  end tell
end write_string

You can see the result in this screencast.

This, as anything, can of course be improved and I learned along the way that AppleScript is just not for me. For someone who writes code in other languages it seems just odd – it is the uncanny valley between programming and natural language.

In any case, it should be helpful. And if everything breaks, make sure to do some extreme pair programming – that works in the movies.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

These apples don’t taste like oranges – let’s burn down the orchard

When I see comparisons of HTML5 to native apps I get the feeling that the way we measure failure and success could give statisticians a heart attack. Take Andrea Giammarchi’s The difficult road to vine via web as an example. In this piece Andrea, who really knows his stuff tries to re-create the hot app of the month, Vine using “HTML5 technologies” and comes to the conclusion – once again – that HTML5 is not ready to take on native technologies head-on. I agree. But I also want to point out that a 1:1 comparison is pretty much useless. Vine is only available in iOS. Vine also was purposely built to work for the iPhone. In order to prove if HTML5 is ready all we’d need to do is to find one single browser on one single OS, nay even only on one piece of hardware to match the functionality of Vine.

sobbing mathematically

Instead we set the bar impossibly high for ourselves. Whenever we talk about HTML5 we praise its universality. We talk about build once and run everywhere and we make it impossible for ourselves to deliver on that promise if we don’t also embrace the flexible nature of HTML5 and the web. In other words: HTML5 can and does deliver much more than any native app already. It doesn’t limit you to one environment or hardware and you can deliver your app on an existing delivery platform – the web – that doesn’t lock you in to Terms and Conditions that could change any time from under you. Nowhere is written though that the app needs to work and look the same everywhere. This would actually limit its reach as many platforms just don’t allow HTML5 apps to reach deep into hardware or to even perform properly.

What needs to change is our stupid promise of HTML5 apps working the same everywhere and matching all the features of native apps. That can not happen as we can not deliver the same experience regardless of connectivity, hardware access or how busy the hardware is already. HTML5 apps, unless packaged, will always have to compete with other running processes on the hardware and thus need to be much cleverer in resourcing than native apps.

Instead of trying to copy what’s cool in native and boring and forgotten a month later (remember Path?) if we really want to have HTML5 as our platform of choice we should play it to its strengths. This means that our apps will not look and feel the same on every platform. It means that they use what the platform offers and allow lesser able environments to at least consume and add data. And if we want to show off what HTML5 can do, then maybe showcasing on iOS is the last thing we want to do. You don’t put a runner onto a track full of quicksand, stumbling blocks and a massive wind pushing in the opposite direction either, do you?

HTML5 needs to be allowed to convince people that it is a great opportunity because of its flexibility, not by being a pale carbon copy of native apps. This leads to companies considering native as the simpler choice to control everything and force users to download an app where it really is not needed. Tom Morris’ “No I’m not going to download your bullshit app” and the lesser sweary I’d like to use the web my way thank you very much, Quora by Scott Hanselman show that this is already becoming an anti-pattern.

Personally I think the ball is firmly in the court of Android to kill the outdated and limiting stock browser and get an evergreen Chrome out for all devices. I also look for Blackberry 10 to make a splash and for Windows phone and tablets to allow us HTML5 enthusiasts to kick arse. And then there is of course Firefox OS, but this goes without saying as the OS itself is written in HTML5.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Like MDN? Run a WordPress site? Promote MDN!

Promote MDNDo you like MDN and run a WordPress site? We made a WordPress Plugin to Promote MDN. You can install it thru your WordPress admin dashboard.

It is based on WordPress developer extraordinaire freediver‘s SEO Smart Links plugin. Promote MDN automatically links keywords and phrases on your site to MDN – including past content! The keywords and phrases are determined by a special Promote-MDN page on the MDN wiki. It comes with reasonable defaults so it should Just Work right out of the box, but you can configure many features:

  • Set exceptions – Include or exclude links in headers or RSS feeds; Prevent linking certain phrases or on certain pages.
  • Set limits – Link in moderation. Only link as many keywords as you want as many times as you want.
  • Add your own keywords – We’ll maintain a good list; make it even better with your own favorite keywords and url’s.

It’s initially available in English, Deutsch, Español, Nederlands, Polski, Português (do Brasil). You can help us translate it on the MDN Verbatim site.

We’d love to hear your feedback on the dev-mdn mailing list or in #mdndev on IRC. And the code is wp-promote-mdn on github if you want to send us bug reports and suggestions, or of course – pull requests! 🙂

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

MDN Hack Day Tour would like to thank…

Attention UK hackers: MDN Hack Day London takes place this Saturday May 12, at the newest Mozilla Space, on lovely St. Martin’s Lane. Designers, developers, and friends are all invited to register. Hacky goodness guaranteed.

Many Thanks Yous, One Mozilla

It was a whirlwind week and a half for the crew of the Mozilla MDN Hack Day Tour in Latin America. Over the course of 10 days we visited four cities in four countries in the Conosur, the southern part of South America. We met hundreds of developers in Buenos Aires, Argentina; Montevideo, Uruguay; Sao Paulo, Brazil; and Santiago, Chile. Thanks to everyone who took the time to listen, to talk with us, and make us feel welcome.

Our message was well-received: The Web is the platform and it’s built from open technologies. On this trip, we were eager to introduce some of the new projects Mozilla is working on now to keep the Web open as more of the world goes mobile. As a non-profit committed to promoting openness, innovation and opportunity on the Web, Mozilla works best with inputs and participation from communities everywhere.

Boot to Gecko Demo by Hernan Colmeiro

In South America, we were a small team, carrying passports from Argentina, Canada, Sweden, Venezuela and the U.S. We spoke in a mix of Spanish and English. Personally I wish more of us had spoken Spanish, but because of my own language limitations, I was extra listen to Spanish-speaking presenters at each of our events.

We talked about HTML5 & friends and new Javascript APIs. We introduced exciting new Mozilla open source projects like Boot-to-Gecko (B2G), our open web phone project that’s just getting started; the soon-to-be-launched Mozilla Marketplace for HTML 5 apps (presented by Mozilla Labs’ Shane Caraveo), and Mozilla Persona, a new identity system for the Web (presented in Spanish by Dan Mills).

In Argentina and Uruguay, Telefonica’s Andres Leonardo Martinez Ortiz introduced BlueVia, the developer program and platform from Telefonica, Mozilla partner and MDN Hack Day sponsor. In Buenos Aires, Kevin Dangoor spoke about the developer tools Mozilla is building and Buenos Aires-based add-ons developer and evangelist Hernan Colmeiro spoke about the beauty of add-ons. In Santiago, Chile, Hernan wowed developers with a Boot-to-Gecko demo.

There were dozens and dozens of individuals who helped make our tour a success, including Mozillians I work with every day and people I’d never met till we arrived in their country. The big risk in writing long thank-yous is that I will unintentionally to forget to mention someone essential, so please accept my apology in advance and don’t hesitate to use the comments.

Buenos Aires

We came to Buenos Aires for MozCamp LATAM, Mozilla’s first community gathering held in Latin America, co-hosted by the amazing, multi-national Mozilla Hispano community and their Portuguese-speaking neighbors from Mozilla Brazil.

Mozilla Hispano Community Day

On the Friday before MozCamp we organized a day-long Hack Day for developers from Buenos Aires. Over 150 developers attended a morning of talks and demos, followed by an afternoon of project hacking. After lunch, a lively group gathered around Add-ons developer Jorge Villalobos, while other attendees were riveted by Philikon’s demo of the Boot-2-Gecko phone.

MDN Hack Day would not have succeeded without the outreach, organizational support and hospitality of Felipe Lerena, Guillermo Movia, and Santiago Hollman of the Moz Hispano community. And I’ll add a special shout-out to the Mozcamp LATAM planning committee: Mary Colvig, Chris Hofmann, Santiago Hollmann, Gloria Meneses, Ruben Martin, Reuben Morais, Guillermo Movia, and the unflappable Katherine Naszradi. This couldn’t have happened without your support!

MozCamp Latam


The crew left Buenos Aires on a sunny Monday afternoon, and crossed the Rio de la Plata by Buquebus ferry, arriving in Montevideo at nightfall, after a choppy 3-hour crossing.

The next morning I met up with old friend and colleague Evan Henshaw Plath, and new friends Diego Algorta, Elena Vilar and the Cubox Labs team who’d been helping us organize, promote and host MDN Hack Day in Montevideo. They work together in a classic 1920s home converted to a co-working space in a leafy residential neighborhood. I met our evening’s speakers, along with Frenchman Jean-Paul Massonnier, an awesome designer, who’d created a poster that was pure Mozilla. I drank delicious coffee and chatted with developers in the kitchen overlooking a garden where coders kicked a football around in the sunshine.

MDN Hack Day 2012 - Montevideo Poster

We headed over to Cafe La Diaria. La Diaria is a subscription-based independent newspaper that is now the 2nd most widely read paper in Uruguay. It is run cooperatively and distributed by employees, with a commitment to the highest journalistic standards. Cafe La Diaria is a venue and community space in the old downtown of the city. Here we met our hosts Damian and Antonieta, who cooked up delicious pizza at the break. Cubox’s Nicolas Barrera gave an entertaining and enlightening talk about responsive design, and Fernando Briano, Cuboxer and noted tech blogger served up a presentation on the web as a tool for Social Change.

In addition, there were two lightning talks: On his last night in Montevideo before moving to Berlin, MDN demo contributor and Developer Derby winner Alvaro Mourino (aka Tuxie) stopped by to talk about our Dev Derby and encourage people to participate. Dario Clavijo, a tech blogger and IT professional in Montevideo, spoke passionately about the importance of free and open software. It was his first ever lightning talk and we were honored to hear from him!

Sao Paulo

Robert Nyman, El Sueco, made the trip to Brazil by himself, since the rest of us yanquis were lacking visas. He’s his report:

“The next leg of the tour, helpfully organized by local company Caelum, [was] a Mozilla one-man show from me giving two talks in Sao Paulo:

  • HTML5, the Open Web and what it means to you
  • JavaScript APIs – The web is the platform

In addition to that, local developer Gabriel Oliveira spoke about CSS3, and from what I could understand, he showed some really interesting things!

There were about 40+ attendees this very rainy night in Sao Paulo, and while there weren’t many people, I was really happy to see the nods of approval in the audience during my talk, when I expressed Mozilla’s values and approach to the web and moving forward. After my presentations, we stood around for a long time discussing the web, -webkit prefixes, H.264 support and more. People seemed to be understanding and pragmatic, and I believe there were some really talented people there.

Additionally, I got to spend some time being guided around by local community members Fábio Magnoni and Clauber Stipkovic, who I got to know in person at MozCamp in Buenos Aires, and had interesting discussions!”

Santiago, Chile

Our final Hack Day of the LATAM tour took place in Santiago, Chile on an overcast Saturday evening. We met in a comfortable classroom at the University of Chile’s Escuela de Economía y Negocios. Jano Gonzalez, a Ruby blogger and all around nice guy made the arrangements. His friends Paulina and Rodrigo took some of the team on a tour of the city.

More than 50 attendees came out to hear from us. Pizza Hut (!) delivered pizza during the break. Hernan Colmeiro came out from Buenos Aires to introduce Add-ons and to demo Boot-to-Gecko. And Jonathan Gonzalez, no relation to Jano, introduced the Monkey Project, a fast and scalable web server for Linux.

Monkey Project, presented by Zeus

We had a strong showing of lightning talks: including presentations delivered in English, with slides in Spanish; presentations in Spanish, with slides in English; a compelling pitch by Ricardo about why you should overcome your shyness and get up at events to give talks about the stuff you know; a hilarious parody of a framework that was probably NSFW, but I didn’t understand enough of the Chilean slang so I can’t be sure; and an introduction to Poderopedia, a database that aims to map the relationships between political and financial power in Chile. We also met some entrepreneurs from the Startup Chile accelerator, and on Monday a couple of us had a chance to visit their lively space.

In conclusion

Huge thanks to the rest of the team – everyone was upbeat, professional, collaborative, and more fun than a barrel of monkeys: Shane Caraveo, Hernan Colmeiro, Dan Mills, Robert Nyman, and a special shout-out to Shezmeen Prasad, event organizer extraordinaire, who invited me along. Props also to Jeff Griffiths, who put it all together behind the scenes, from somewhere in Canuckistan. Gracias!

Photo credits: Prima Leon, thunder, and freshelectrons.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

WebAPI tech lead: ‘We want Web pages to be able to access hardware on your computer, like camera, sensors and haptic feedback’

Jonas Sicking, photo by Tristan Nitot

This time, Tristan Nitot interviews Jonas Sicking, WebAPI tech lead, and discusses how the Web can become a mobile platform, and what this means for Web developers around the word.

Tristan – Jonas, Mozilla has shown a very cool new project at the Mobile World Congress, Boot To Gecko, and said “the Web is the Platform”. How does that relate to your work? What do you do to improve the Web?

Jonas – I’m the tech lead of the newly started WebAPI team. We started the WebAPI team at the same time as we started Boot to Gecko because we knew that in order to make the web platform fully competitive with other mobile platforms we needed to make sure that it had the same capabilities. Web pages haven’t traditionally been able to access hardware on your computer, like camera, sensors and haptic feedback. But with B2G we needed to make that happen. The WebAPI team was started for this purpose.

Tristan – So you’re basically bringing access to new capabilities to the Web? I’m sure Web developers are going to be very excited by this!

Jonas – That’s certainly our hope :).

Tristan – But what about security? I’m not sure that I want every Web app to be able to say where I’m located. Or have the ability to send text messages on my behalf without me knowing it!

Jonas – Security has always been a top priority at Mozilla, and WebAPIs are no exceptions. When we offered the geolocation feature from Firefox on the desktop, a lot of thinking was done so that we give control to the user, while keeping the best user experience possible. This is our line of thinking when it comes to newer WebAPIs. For example, we never want to ask the user a security related question that they might not fully understand and make the wrong choice.

Tristan – Many people probably wonder why Mozilla is doing this… Can you explain?

JonasThe web is amazing in many wonderful ways. It has enabled millions of people to do new things on-line. Both as far as producing content and as far as consuming content goes. In large part because it’s built as an open platform with no restrictions on how its used. For example you can “view source” any web page that you like, you don’t need to get expensive development environments from anyone and you don’t need anyones permission to publish what you built. We want to bring these benefits to application developers too. Imagine if you can look at how someone else’s web app works and learn from it, and all you need to do to write the new killer app is to fire up a text editor, write it, and publish it on a web server. Additionally, if all that it takes is that, that means that we’ll enable all the amazing web developers out there to also become application developers.

Tristan – What does that mean for Web developers?

Jonas – It means several things. First of all, the websites that you are writing today will have new capabilities, such as access to device hardware. It also means that you can turn your website into an app which starts as fast as a native app on the user’s computer or device and that runs even if the user has no Internet connection. It also means that your app will run on desktop, tablet and mobile, with no need to write separate versions of your code for separate platforms.

Tristan – In short, with little training, Web developers can write apps that will run everywhere, from desktop to tablet to smartphones… But what’s actually the difference between a Website and a Web app?

Jonas – The idea is that you’ll just write a website like you’ve always done. Then add a little bit of meta information which describes what icon and name you want to use, what permissions you need, and which URLs need to be cached on the device. Now your website can run as an app as well.

Tristan – A totally different topic now: how did you get involved with Mozilla?

Jonas – I first got involved in the Mozilla project in 2000. At the time I was in school and working part time as a web developer. I started helping out for two reasons, first of all, as a software developer Mozilla was a very cool project to get to be part of. I got to work with a lot of smart people on a piece of software that a lot of people were using (back in those days that was Netscape). It was really cool how I could, as a student in Sweden, work together with people in silicon valley on building great software.

The other reason was Mozilla’s focus on web standards. As a developer it was very annoying how inconsistently IE5.5 was implementing web standards and I saw a chance to make things work better in Mozilla. That way I would get to use those features as a Web developer. As any web developer knows, working around limitations in web browsers is one of the more painful things about the job and so it felt great to be able to remove those limitations.

Ultimately what has made me stick around is this second aspect. Mozilla’s commitment to building a great platform for users and developers is something that has always spoken very strongly to me. It feels great knowing how much we help bring the web forward.

Tristan – So much that you’re now a Mozilla employee since 2005! I guess that you see your work now as something in line with what you started doing back in 2000?

Jonas – Exactly. The world is going mobile. More and more people are getting smartphones and very soon the number of smartphones in the world is going to vastly outnumber the number of desktop and laptop computers. We need to ensure that when this happens the web remains open and that you’re not forced to interact with it through apps running on proprietary stacks. I have a lot of faith that the web will be able to stand strong and remain open. Just how open depends on how successful we will be competing with these proprietary stacks. There’s a lot of similarities with the push we did for web standards back when Microsoft weren’t that interested in following them. The goal is to have an open standardized platform that works great for users and developers. The mobile platform should be no less open.

Tristan – Any call to action for our readers who develop Websites?

Jonas – Keep developing great web applications. Please experiment with any of the new APIs, and other web technologies, that we create. Reading is a great way to hear about new improvements to the web platform that are coming from Mozilla (including a category dedicated to WebAPIs). Develop mobile websites that run great on small screens. We’ll soon be releasing versions of Firefox which support installable web apps; once that happens, please experiment with them and let us know what you think!

Tristan – Thank you Jonas for your time, thank you for what you’re doing in making the Web the platform of choice for apps and mobile, and everything you’ve done in keeping the Web open since you’ve got involved with Mozilla!

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)