Tag Archives: mozilla

Talking about Servo in Hackference Birmingham 2016

I visited Birmingham for the very first time last week, to give a talk at Hackference. Apparently the organiser always swears that it will always be the last hackference, and it has been “the last one” for the last four editions. Teehehe!

I spoke about Servo. They didn’t record the talks but I did an screencast, so here’s it:

📽 Here are the slides, if you want to follow along (or maybe run the demos!). The demos come from the servo-experiments repository, if you want to try more demos than the ones I showed.

If you watched this talk at ColdFrontConf, this one has more clarifications added to it, so complicated aspects should be easier to follow now (specially the explanations about layout calculations, optimisations, parallelisation and work stealing algorithms).

People enjoyed the talk!

Someone even forked one the dogemania experiment to display other images:

And Martin got so intrigued about Servo, he even sent a PR!

I didn’t get to see much of the city, to be honest, but two things caught my attention:

a) it was quite empty even during ‘rush hours’
b) people were quite calm and chill

That’s perhaps why Jessica Rose is always saying that Birmingham is The Absolute Best place. I will have to find out some other time!

A very funny thing / activity / experiment happened in the slot before my talk. It was a reenactment of the BBC’s Just A Minute show, which I have never watched in my life. Essentially you have 4 participants and each one has a little device to “stop the show” when the active participant messes up. The active participant has to speak for a minute on a given topic, but they cannot hesitate or repeat words, so it starts getting challenging! This was organised and conducted by Andrew Faraday, who also helped run the Web Audio London meetup a while ago and is always an interesting nice person to talk to.

So this, this was hilarious beyond anything I expected. I guess because I didn’t expect any funny thing in particular, and also because I didn’t have any preconception of any of the participants being a “funny person” per se, so the whole comedy came from the situation and their reactions. It had some memorable moments, such as Terence Eden’s “unexploded item in bagging area” (in relation to the Samsung Galaxy Note 7 exploding fiasco, plus the very annoying voice that anyone who’s ever used a self-service checkout till in the UK will recognise 😏).

After so much laughing, I was super relaxed when the time for my talk came! Every conference should have Andrew doing this. It was excellent!

Other interesting talks and things:

  • Felienne Hermans’ on machine learning and bridge playing AIs built with DSLs built with F# – I basically don’t know much about any of these subjects, so I figured this could be an interesting challenge. You can watch this recording of this talk from another conference, if intrigued.
  • Martin Splitt’s aka geekonaut talk on WebGL – if you have the chance to watch it, it will be quite informative for people who want to get started in WebGL and learn about what it can do for you
  • I’m certainly not a Web Audio beginner, but I tend to watch those talks anyway as I am always curious to see how other people present on Web Audio. Hugh Rawlinson‘s presentation on Web Audio had a few interesting nuggets like Audiocrawl, which showcases the most interesting things in Web Audio. He also worked on meyda, which is a library to do feature detection using Web Audio.
  • Jonathan Kingsley gave one of the most depressing and hilarious talks I’ve seen in a long time. IoT is such a disaster, and the Dyn DDoS attack via IoT devices, just a couple hours after this talk, was so on point, it almost seemed deliberate.
  • Finally Remy declared his love for the web and encouraged everyone to get better and be better to others – and also stressed that you don’t need to use all the latest fashions in order to be a web developer. It’s good when renowned speakers like Remy admit to not to like frameworks, despite also seeing their strengths. A bit of balance never hurt anyone!

The conference had a very low key tone, let’s say that it was a bit “organise as you go”, but due to the small scale of the conference that wasn’t much of a problem. As I mentioned before, everything was pretty chill and everyone was very approachable and willing to help you sort things out. It’s not like a had a terrible problem, anyway: my biggest problem was that my badge had been temporarily lost, but no one told me off for not wearing a badge while inside the venue, and I eventually got it, heheh. So yeah, nice and friendly people, both attendees and organisers.

I also liked that everything was super close to the train station. So there was no need for additional transportation, and we could use the many food places in the station to have lunch, which was super convenient.

Oh and Jessica as MC was the best, I really enjoyed the introductions she prepared for each speaker, and the way she led the time between talks, and she was really funny, unless presenters that think they are funny (but aren’t).

If you have the chance, attend the next Hackference! It might the last one! 😝

Here are other conference write ups: from Dan Pope and from Flaki (who stayed for the hackathon during the week-end).

Moving to the DevTools team

As of this week I am working in the DevTools team.

This isn’t entirely surprising, given that I’ve been collaborating with this team a lot in the past (proof!) and also that I care a lot about making sure web developers have the best tools so they can build the best web ever.

I will be managing a few folks and also plan on getting some bugs fixed myself (famous last words? 😏). I also am going to give the talks I agreed to give, so I will still be attending Hackference (Birmingham), CSSConf Asia (Singapore) and JSConf AU (Melbourne).

I’m very excited both about the future and about working with this team full time! Yasss!

It is bittersweet to leave my former team as my colleagues are very cool, but we keep working closely together, and I intend to keep using my devrel-ing skills to announce all the cool stuff coming out of my new team. We will keep building cross team synergies! 😝

🌞 Onward! 🌞

Talking about Web Audio in WeCodeSign Podcast

I recorded an episode for the WeCodeSign podcast. It’s in Spanish!

You can download / listen from their website.

We actually talked about more than Web Audio; there’s a list of links to things we mentioned during the episode. From progressive enhancement to Firefox’s Web Audio editor, to the old PCMania tracking stories, to Firefox for iOS… lots of things!

I was really pleased with the experience. The guys were really good at planning, and did a great job editing the podcast as well (and they use Audacity!).

Totally recommended—in fact I suggested that both my fantastic colleague Belén and the very cool Buriticá are interviewed at some point in the future.

I’d love to hear what they have to say!

Throwback to the last time I recorded a podcast in Spanish–at least this time I wasn’t under a massive cold! 🙃

dogetest.com

This summer, Sam and me are exploring Servo’s capabilities and building cool demos to showcase them (and most specially, WebRender, its engine “that aims to draw web content like a modern game engine”).

We could say there are two ways of experimenting. One in which you go and try out things as you think of them, and another one in which you look at what works first, and build a catalogue of resources that you can use to experiment with. An imperfect metaphor would be a comparison between going into an arts store and pick a tool… try something… then try something else with another tool as you see fit, etc (if the store would allow this), versus establishing what tools you can use before you go to the store to buy them to build your experiment.

WebRender is very good at CSS, but we didn’t know for sure what worked. We kept having “ideas” but stumbled upon walls of lack of implementation, or we would forget that X or Y didn’t work, and then we’d try to use that feature again and found that it was still not working.

To avoid that, we built two demo/tests that repeatedly render the same type of element and a different feature applied to each one: CSS transformations and CSS filters.

CSS transformations test

This way we can quickly determine what works, and we can also compare the behaviour between browsers, which is really neat when things look “weird”. And each time we want to build a new demo, we can look at the demos and be “ah, this didn’t work, but maybe I could use that other thing”.

Our tests use two types of element for now: a DIV with the unofficial but de facto Servo logo (a doge inside a cog wheel), and an IFRAME with an image as well. We chose those elements for two reasons: because the DIV is a sort of minimum building block, and because IFRAMEs tend to be a little “difficult”, with them being their own document and etc… they raise the rendering bar, so to speak 😉

All together, the tests looked so poignantly funny to me, I couldn’t but share them with the rest of the world:

and Eddy Bruel said something that inspired us to build another test… how many doges can your computer render before it slows down?

I love challenges, so it didn’t take me much to build the dogemania test.

It can ridiculise my MacBook retina very quickly, while people using desktop computers were like “so what’s the fuss, I get 9000 doges with no sweat?”

It was also very funny when people sent me their screenshots of trying the test on their office screen systems:

Servo engineers were quite amused and excited! That was cool! We also seemed to have surfaced new bugs which is always exciting. And look at the title of the bug: Doges disappear unless they are large and perfectly upright. Beautiful!

To add to the excitement, this morning I found this message on my idling IRC window:

7:22 PM <jack> http://dogetest.com
7:22 PM <jack> we all love it so much i thought it needed it's own domain :)

So you can now send everyone to dogetest.com 🎉

Thanks, Jack!

Web Animations: why and when to use them, and some demos we wrote

There’s been much talk of Web Animations for a long time but it wasn’t quite clear what that meant exactly, or even when could we get that new thing working in our browsers, or whether we should actually care about it.

A few weeks ago, Belén, Sam and me met to brainstorm and build some demos to accompany the Firefox 48 release with early support for Web Animations. We had been asked with very little time, but we reckoned we could build at least a handful of them.

We tried to look at this from a different, pragmatic perspective.

Most graphic API demos tend to be very technical and abstract, which tends to excite graphics people but mean nothing to web developers. The problem web developers face is not making circles bounce randomly on the screen, it is to display and format text on screen, and they have to write CSS and work with designers who want to play a bit with the CSS code to give it as much ‘swooosh’ as they envision. Any help we can provide to these developers so they can evaluate new APIs quickly and decide if it’s going to make their work easier is going to be highly appreciated.

So our demos focused less on moving DIVs around and more on delivering value, either to developers by offering side by side comparisons (JS vs CSS code and JS vs CSS performance) or to end users with an example of an style guide where designers can experiment with the animation values in situ, and another example where the user can adjust the amount of animation to their liking—we see this as a way of using the API for improving accessibility.

You can also download all the demos from the repo:

git clone https://github.com/mozdevs/Animation-examples.git

And should you use CSS or should you use JS? The answer is: it depends.

Let’s look at the same animation defined with CSS and JS, taken straight from the CSS vs JS demo:

CSS:

.rainbow {
    animation: rainbow 2s alternate infinite;
}

@keyframes rainbow {
    0% { background: #ff004d; }
    20% { background: #ff77ab; }
    50% { background: #00e756; }
    80% { background: #29adff; }
    100% { background: #ff77ab;}
}

JavaScript:

let el = document.querySelector('.rainbow');
el.animate([
    { background: '#ff004d', offset: 0 },
    { background: '#ff77ab', offset: 0.20 },
    { background: '#00e756', offset: 0.5 },
    { background: '#29adff', offset: 0.80 },
    { background: '#ff77ab', offset: 1 }
], {
    duration: 2000,
    direction: 'alternate',
    iterations: Infinity
});

As you can see, this is fairly similar.

CSS’s syntax for animations has been with us for a while. We know how it works, there is good support across browsers and there is tooling to generate keyframes. But once the keyframes are defined, there’s no going back. Modifying them on the fly is difficult unless you start messing with strings to build styles.

This is where the JS API proves its worth. It can tap into live animations, and it can create new animations. And you can create animations that are very tedious to define in CSS, even using preprocessors, or just plain impossible to predict: imagine that you want custom colour animations starting from an unknown colour A and going to another unknown colour B. Trying to pregenerate all these unknown transitions from the beginning would result in an enormous CSS file which is hard to maintain, and would not even be as accurate as a newly created animation could be.

There’s another advantage of using the Web Animations API versus animating with a library such as tween.js—the API is hardware accelerated and also runs on the compositor thread, which means incredibly smooth performance and pretty much perfect timing. When you animate DOM elements using JavaScript you have to create lots of strings to set the style property of these DOM elements. This will eventually kick a pretty massive Garbage Collector, which will make your animations pause for a bit: the dreaded jank!

Finally another cool feature of these native animations is that you can inspect them using the browser developer tools. And you can scrub back and forth, change their speed to slow them down or make them faster, etc. You cannot tap into JS-library-defined animations (e.g. tween.js) unless there’s support from the library such an inspector, etc.

Essentially: Web Animations cheat by running at browser level. This is the best option if you want to animate DOM elements. For interpolating between plain values (e.g. a three.js object position vector x, y, z properties) you should use tween.js or similar.

If you want to know more here’s an article at Hacks talking about compositors, layers and other internals, and inspecting with DevTools. And with plenty of foxes!

The full API isn’t implemented in any browser yet, but both Firefox and Chrome stable have initial support already. There’s no excuse: start animating things already! I’m also excited that both browsers shipped this early support more or less simultaneously—makes things so much easier for developers.

With mega thanks to Belén for pushing this forward and to Sam for going out of his internship way to help us with this 🙌🏼