Tag Archives: javascript

“Hands-On Web Audio” at London JS meetup

I gave my “Hands-On Web Audio” talk at the London JS meetup, held at the offices of Just Eat. It was broadcasted as a Hangout, and also recorded so you can replay or see if you couldn’t attend:

If you want to play along, the slides are live here and here is the source code as well. Disclaimer: depending on your computer, they might be a bit too much in both Firefox or Chrome. There seems to have been a regression and the intro sound is extremely stuttering in “slower” computers (slower as in “a MacBook Retina”).

It was a bit awkward because their big screen was actually six TVs and most of the content in my slides is centered vertically on the slide, which coincided with the middle of the frames, so it was quite unreadable. That is why you’ll hear a number of comments akin to “oh this is very inconvenient” from me, during the talk.

After I finished the talk itself, we had a round of questions, and I also showed how to debug web audio with the Web Audio editor in Firefox DevTools.

Feedback on the talk seems really positive and I’m happy people got interested in playing with the Web Audio API and making dubstep! YES!

Great talk! I left inspired to go play. I’d used some features of the audio API before but Sole’s enthusiasm and dubstep obsession triggered a string desire to get creative with it again.

Spectacular demo by Soledad. She really knows what she’s talking about

I’m really happy that people were happy and interested in the API 🙂

Side note, 1

A few people asked me about the slides: how are they made?! are they WebGL?! can they use the system to make their own slides?

Answer: they are WebGL, and they use three.js underneath. Right now the system is quite hardcoded, but I’m happy to announce that I’m working on refactoring the code so anyone can build their own 3D slide deck, using their own demo scenes. So I guess I am building a slide deck framework… 😬 #sendhelp

You can have a look at the project here, but don’t send me requests yet, kthx. An online demo is available as well. Right now it can only render basic H1-H4 and P nodes… in 3D! Not bad!

Side note, 2

I was really excited that I made it to the meetup (!), because I forgot my phone home that morning. I found out when I was in the office already, and I didn’t want to go back. So I printed the map and started cycling to the meetup place. Except I didn’t know very well the area, so I got lost twice. Not too bad though, I stopped and produced my paper map and let people look at me with weird looks (“she’s looking at a paper map!”). Anyway, I used:

a) my brain, instead of trusting everything to a GPS enabled device
b) those little maps in the street showing where you are

and I made it!

The way back was easier as I knew the area before. I tracked my route using my fitbit, and was really pleased to see that I had reached almost 30km/h on my humble Brompton.

It was coincidentally also Cycle To Work day yesterday, so I was doubly pleased that I cycled to work and also to meet up.

Should there be a Cycle To Meetup day too? I think so 😏

Progressive enhancement does not mean “works when JavaScript is disabled”

This topic came up last Sunday when we were recording an episode for WeCodeSign, but the episode will take two weeks to be published, and it will also be in Spanish, so unless you are able to follow my quickly spoken Spanish, you will miss my Important Insights™ on this topic. Which is why I’m writing about it here.

Apparently there’s a misconception in which progressive enhancement has been fully equated with “works when JavaScript is disabled”. That is not the case, but I could see how someone who hasn’t been programming their entire life and is lost on the fire between the two sides will be really confused.

Continue reading Progressive enhancement does not mean “works when JavaScript is disabled”

ColdFront 2016

I spoke at ColdFront in Copenhagen last week. I joked that I just accepted the invitation because I wanted to go back to Copenhagen, and it actually wasn’t far from the truth as it’s a lovely city and I had a great time when I went there for At The FrontEnd last May: going through the airport is easy, the trains and metros are spotless and easy to buy tickets for, the city is beautiful in its flat Nordic way (Stockholm and Oslo are quite hilly), lots of interesting design stuff to look at, people were super kind and nice to me at every single point, attendees were really polite and so on and so on. How would you not want to go back to a place like this?

So when Kenneth reached out to see if someone could talk about Servo and given that I was working on Servo this summer, it sounded like the Perfect Plan.

Fast forward a few months, and I was in Copenhagen again.

I unfortunately had to miss the first talks of the day as Perfectionist Sole was obsessing over her talk and her slides, but what I saw was really interesting. It was a very good exercise of curation.

Bruce Lawson delivered a very interesting talk loaded with facts about how to deliver the web for everyone—not just rich people on the Western world! Lots of technical insights about Opera Mini optimisations and infrastructure (this was fascinating), lots of research insights as to how do people with unreliable expensive networks use their phones and data plan, etc. Building Proper Web Apps (my new rebranding for PWA, haha) is the answer to these issues. So… learn your tools for a brighter, speedier and more reliable future!

Then there was the break in which we tested our laptops with the A/V system. It turned out that the system was having some fun and introducing random glitches and red jitter so things could occasionally look funny. I was happy with the aesthetics but “sadly” the technicians fixed it during lunch—while we were enjoying the tacos and rye bread sandwiches outside!

It was then the turn for Mathias Bynens who talked about ways in which your browser can be fingerprinted via timing attacks, and other terrible things that left all of us really scared. Good talk explaining complex topics quite clearly.

I talked about Servo and how it is solving many problems, one at a time. More to come…

Glen Maddern talked about strategies to avoid ending with “😈 Demonic CSS 😈”. He suggested a number of design ideas and even ‘tricks’ that you can actually use in most browsers (like currentColor), without having to add CSS preprocessors to a project. I think a gist could be: Just because you can write complicated stuff doesn’t mean you should. He also has started a series of screencasts where he talks about similar front-end topics in his funny and approachable way, be sure to check it out: Front End Center.

Finally Estelle Weyl talked about the need to go back to basics—again, to know your tools—for front-end developers. She asked urged people to reconsider bringing in another JS framework into a project if whatever they wanted to accomplish could not be done in a simpler way with “vanilla” JavaScript, and showed a few examples of ways front end developers are reimplementing things that the browser already provides support for, due to ignorance.

At the end of the talks, the two main organisers Kenneth and Daniel went on stage to tell us a bit about the history of the conference, how they started it, the debt they accidentally incurred in last year and how unhappy their accountant was, the terror of not selling tickets, and how this would be the last conference as Kenneth now lives in Vancouver and it’s very hard to organise a conference when you live so far away.

At this point everything got very emotional but fortunately Daniel and Kenneth hugged and said thanks, before we all broke down and started to cry. Then we clapped to thank them, Kenneth and Daniel took a deep breath and asked us to reposition to take the JS family photo, and we were off to the closing party which was at a well stocked brewery like 40 metres away (I had an alcohol free drink following my self-pledge).

It was lovely to talk with all the people there… I mean—I didn’t talk to all of them, but to the ones I talked to! Plus the weather was quite nice and we could be outside instead of yelling at each other inside the loud brewery.

Sadly, there won’t be another Cold Front so if you want to relive this, check the talks when they are published in their website. Or watch the talks from previous years in their YouTube channel!

Thanks for the lovely conference!

Article about the MediaRecorder API in .net magazine

MediaRecorder article picture

I wrote an article on the MediaRecorder API for .net magazine issue 283.

This isn’t an exhaustive article, just a little advance on what the API can do, as part of the Standards section that tracks new and upcoming APIs. If you want to learn more about the MediaRecorder API, there’s the way more detailed Hacks article I wrote: Record almost everything in the browser with MediaRecorder, or maybe you can watch one of the talks I’ve given on the subject, like this one.

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:


.rainbow {
    animation: rainbow 2s alternate infinite;

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


let el = document.querySelector('.rainbow');
    { 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 🙌🏼