Why is Instagram not a website (yet)?

Rem was wondering about this yesterday in Twitter:

A couple years ago I had to do some analysis of popular apps (basically peeking inside their guts, so to speak). What we found is that Instagram used a lot of native libraries for dealing with video and audio.

Rem suggests that Instagram could be almost 100% a website nowadays, and not the strange hybrid it is. I would love to see that, but the web platform needs a lot more features we don’t have yet, for example:

  • reliably being able to select which camera to use, and also being able to focus
  • encoding into a certain type of video format, in a performant non-draining-your-battery way
  • manipulating videos in real time, sounds included
  • accessing the ‘photoroll’ easily

You can access a camera stream with getUserMedia, but for privacy reasons you cannot see details about the devices so your code cannot know if they’re back or front cameras, and so the UI cannot respond appropriately. When running in phones, which use better camera hardware than webcams, we cannot access the camera settings from JavaScript (we can, with Firefox OS, but the APIs haven’t been standardised as no other vendor was interested in implementing them).

As usual, video is a huge issue in the web. Encoding is complex and expensive in battery terms, but thanks to MediaRecorder it is becoming more accessible. Still the formats MediaRecorder outputs are only viewable in browsers (vp8/webm); if you encode a video using the browser you have to convert it locally to something else like mp4 if you want to upload it to sites like Twitter, and unless you’re a tech-savvy person and have installed VLC or similar you cannot even watch the video you generated in your desktop if using the default video viewers in your system.

Similarly, handling video and audio post processing in real time is possible with WebGL + Web Audio but recording is not supported in anything other than Firefox. Chromieum/Opera won’t give you a stream from canvas or record a stream from a Web Audio context either.

And being able to access the photoroll in mobile or a directory in desktop would require that the APIs for exposing directory listings are available so the app could do things such as building thumbnails of the images, but they aren’t.

It’s not impossible—it’s “just” a matter of implementation and adoption.

If apps such as Instagram were 100% web based, and had a reliable chance of working reasonably well on every device, there would be no distinctions between device operating systems, and we could just focus on the device features (price, camera quality, battery life, storage, design…). This would be huge for the users and quite probably for the app makers which would need only one team to build the app, not one per operating system.

But would it be huge for Google and Apple?

Meanwhile, in Mozlandia…

Almost every employee and a good amount of volunteers flew into Portland past week for a sort of “coincidental work week” which also included a few common events, the “All hands”. Since it was held in Portland, home to “Portlandia“, someone started calling this week “Mozlandia” and the name stuck.

I knew it was going to be chaotic and busy and so I not only didn’t make any effort to meet with non-Mozilla-related Portlanders, but actively avoided that. When the day has been all about socialising from breakfast to afternoon, the last thing you want is to speak to more people. Also, I am not sure how to put this, but the fact that I visit some acquaintance’s town doesn’t mean that I am under any obligation to meet them. Sometimes people get angry that I didn’t tell them I was visiting and that’s not cool 🙁

Continue reading “Meanwhile, in Mozlandia…”


If you want to write code that looks nice and crispy in high density displays, you have to take the device pixel density into account. This is exposed to us in JavaScript as the window.devicePixelRatio property, which returns a number that describes how many physical pixels does it take to represent a device independent pixel. The more pixels it takes, the finer the display will look, and the harder it is to actually “see” individual pixels (as in, individual, physical light dots) in the screen. This is famously known now as the “Retina” effect, but not only Mac products exhibit this behaviour-most relatively high end phones with “touch screen” usually have a display density higher than 1.

The interesting bit here is that you can’t assume that once a document is opened in your browser, the devicePixelRatio will stay constant. If you drag the window to a screen with a different density, this value will change–as seen in this video where I am dragging my test page window between the Retina display of the laptop, with ratio = 2, and the external monitor whose ratio is 1. For comparison, devicePixelRatio is 3 on my Nexus 5, 1.5 on a Firefox OS Flame, and 1 on a Geeksphone Keon.

Try it out, and maybe leave a comment with what you got!

There isn’t any event triggered when this value changes, so that’s why in this test case I set a periodic interval to keep updating the value:

setInterval(updateDPR, 50);

function updateDPR() {
    p.textContent = window.devicePixelRatio;

Perhaps not the most efficient piece of code, but this is also a bit of a corner case maybe, and a test page, so just don’t copy it literally 🙂


Invest in the future: build for the web!

I spoke at GOTO Amsterdam a few weeks ago. I was really thrilled to be back in the Netherlands after so many years! So thanks to Sergi Mansilla, who curated the HTML5 track, and the organisation in general for bringing me there!

The talk wasn’t recorded, but I made a screencast just in case you really want to listen to me. I am also posting the outline/notes I wrote, and they differ in places because I don’t read them during the talk (I don’t even have them handy) and I sometimes went a bit off topic, but that’s the beauty of improvisation!

Here are the slides, and the slides source code just in case you wanted it too.

On to the notes-expect some MASSIVE GIFs and amazingly clever photomanipulation! tee hee hee!
Continue reading “Invest in the future: build for the web!”

What does the Battery API report on a desktop computer?

I was discussing with Chris Mills how to build an example for Web APIs that was clear enough yet showed some sort of API usage in action. He had chosen the Battery API which is, effectively, simple enough. But I had a question: what does this API report when you run it in a device without battery?

Nothing better than building an example, so that’s what I did.

On a laptop

It reports the battery level and discharging / charging, plus the time left, if not at the maximum level already.

battery api on a laptop

On a desktop

It reports battery level at 100%, charging, and 0 seconds to charge.

battery api on a desktop

Mystery solved!

A final note/remark: while going through the API docs I found it so very synchronous and unpromise-y! If this API was written nowadays it would probably be done with Promises or some sort of asynchronicity by default. I wonder if that will be retrofitted.