The Difficult Road To Vine Via Web

One of the coolest and most rumored app of these days looked so fun, and conceptually simple, that I could not resist to challenge myself trying to reproduce it via HTML5 and all possible experimental things I know that are working these days for both desktop and mobile.

Wine

This is the name I have chosen for this experiment, and this is the very first warning: it does not work as it should, is not the equivalent, it cannot substitute the native App: too bad, but probably the reason vine team didn't even try to propose such broken experience.

Well, Something Is Working!

Guess who's this idiot with a Koala hat in a leaving room:



That's correct, "it's a me" through the wine experimental project and a Chrome browser. But let's talk a little bit about technologies I have used, OK?

• Client (in order of dependencies)
  • experimental.js and Queue
  • HTML5 getUserMedia({video:true, audio:maybe})
  • Recorderjs for the maybe and Canary only audio stream.
  • something else such XMLHttpRequest and FormData, but these aren't important
• Server (in order of importance)
  • node.js
  • polpetta
  • ffmpeg
  • gifsicle

If you want to know how to install the environment and play with the project, once again, the repository explaining how to :-)

How Does It Work

Well, you launch the server, you connect to that page, you press the video up to 6 seconds. If you release your finger or your pointer, it stops recording. when the top bar is filled up, each frame will be rendered as image and sent to the server, together with the audio, where some magic happens and the result is a video in mp4, ogv, and webm formats, plus a nice fallback as animated gif so that every single body can see again those 6 seconds, nice? Now, time to talk about all possible problems I had during its development ...

Everything You Know About getUserMedia() Is A Lie

This has been the biggest headache during the creation of this prototype.
All articles I have read, included this excellent one in HTML5 Rocks, which is marking the article valid for Opera and Firefox too, do not work ... really, as simple as that: that stuff does not work!

The Right Way To Attach A Stream

In my proudly created spaghetti code I ended up with a Frankenstein monster such:

function attachStream(media, stream) {
  try {
    // Canary likes like this
    media.src = window.URL.createObjectURL(stream);
  } catch(_) {
    // FF and Opera prefer this
    // I actually prefer this too
    media.src = stream;
  }
  try {
    // FF prefers this
    // I think it should not be needed if the video is autoplay
    // ... never mind
    media.play();
  } catch(_) {}
}

So, the most advanced browser is apparently behind the schedule because Firefox Nightly and Opera Next just refuse to work through the URL.createObject() approach.
However, I found Firefox behavior a non-sense because of the required play(), completely against the logic behind the autoplay video attribute.

Bad News Is ...

my code ain't gonna work for long time neither, things are changing, so keep reading and smile ^_^

AudioContext and AudioStream Is Nowhere!

Correct, another myth of these HTML5 days is the audio stream. Nightly is able to expose it inside the stream but I could not manage to retrieve it and handle buffers in and out. Nightly has also another really annoying problem, the redundancy of the microphone recording the audio itself ... a noise you'll spot if you don't mute manually your computer speakers.
I had to video.muted = true in order to avoid such disturbing noise, something present in Canary too but if the volume is not 100% is much less easy to reach that point. Canary seems to be more clever here! Opera does not seem to work neither with this audio stuff.
The best one seems to be Apple Safari browser: nothing works but they have the best documentation!

Surely It's Me

I might have done something wrong, but if browser vendors keep implementing and changing standards behind the scene how can this be developers fault?
Here an example, I ask how come getUserMedia() is so much NOT available?
The answer was this one!

Because Microsoft recently scuttled ongoing standardization efforts with a surprisingly valid counterproposal I'm afraid.

DAFUQ?!

I love all efforts from Microsoft, Firefox OS, Chrome OS, if any, and all others trying to propose standards ... but I don't understand any vendor that is trying to kill a reasonable one until the best proposed one ever will be rolled out ... I mean, can I haz that meow?

Until Things Are Usable

I feel like somebody is having fun screwing standards from time to time and every abandoned proposal that looks good to developers has the same destiny:

• stick forever in some library because in those days, that was the behavior
• make the new proposal not powerful regardless, since it came out of a hybrid, not perfect one, that everyone probably already adopted, as it is for localStorage and WebSQL, things that just work as developers need to do more, things still there, just randomly there
• fragmented on the Desktop, fragmented on the mobile more than ever and where on mobile, updates do not basically exist. On mobile, we keep changing Hardware generations, and not software!
  iOS here is a partially lovely exception, able to update longer, but my iPad 1 is stuck behind iOS 5.X, you know what I mean ... right ?

I really feel Christian Heilmann when he says that what matters is reachability and everything else is a futile discussion.
I probably have same feelings, better summarized, as web developer, in this personal thoughts:

It does not matter if it's touchstart or pointerEventDown event guys, what's important is that it f*#$!(in works when a person put a finger in his device screen and this person bought that device thinking is touch-able ... YES, THE BROWSER TOO!

Also, because people don't, and should, ever care about software, that's our problem, and should never be people limitation with the hardware and the software they like, they use, they need, they want ... but we keep smiling, right? ^_^

The Web Has Never Been This Broken

And this is the beautiful lie behind HTML5: it's utopia that never worked in reality!
Articles and examples that work only for this browser, the thing we have complained about for years about IE thinking "dude, if you don't know how to create a site don't write it works only for IE you lamer"!
Problem is, we are not going anywhere even on mobile, where guess what, platform fragmentation is growing much more than desktop one. On Desktop we have 3 OS Families, Windows, OSX, and Linux generic distro (I feel you Gentoo, Fedora, Redhat, Ubuntu, Debian, Kubuntu guys ... sorry to group you there).
On mobile, we have newcomers all over so iOS, Android 2.2/1.3/3.0/3.1/4.0/4.0.1/4.1/4.2 and here you have the coolest device ever, and Firefox OS plus that sneaky Opera Mobile, I mean mobile, not mini, the best, fastest, most updated, browser ever for both Symbian and Android 2.X!

Wasn't This About Wine?

Right ... you are right, I stop here wining about the fact that indeed, Opera Mobile is the only mobile browser able to work, even in Android 2.3, regardless low performance it just look and feel OK there, so if you want to try this you can try with Opera Mobile and enjoy the project.
Chrome Mobile doesn't getUserMedia(), so doesn't FirefoxOS, neither anything else I could try (come on, you are not trying with a windows phone, right? They killed the current standard proposing something else ... cooler, but more to wait for!).
So, the end of this story is that I have created a project which aim is to simulate a native App, and I miserably failed. Not because performance were not good, since once again it works via Opera Mobile in my Galaxy Ace, an Android 2.3 smartphone really simple, really functional, really usable thanks to a decent battery life due to low hardware specs, so ... again, it's not a performance issue, and you can test it, it's more about mistakes, rush, and wrongly accepted proposal from those that are deciding standards ... for good, sure, but if WebSQL was universally available, cross browser/platform speaking, how much more we, web developers, could have we done?
Think about it, that could have been the best thing ever to build No-SQL concept on top, but never something like this about IndexedDB:

Because this technology's specification has not stabilized, check the compatibility table for the proper prefixes to use in various browsers. Also note that the syntax and behavior of an experimental technology is subject to change in future version of browsers as the spec changes.

And this after at least 2 years ... now ask yourself honestly if current getUserMedia() was already available cross browser, how many creative things could have been created already?

At Least These!

• web based alarm systems, video can be captured into canvas, canvas can scan images, canvas can detect suspicious movements comparing diffs between previous image and current one in a place that supposes to be quite
• no need to call the specialist that will install the expensive hardware, the cable, the camera, and everything else, if we can program quadcopters via node.js, JavaScript is good and fast enough to monitor the house, the garage, the entrance, and tell you everywhere you are in the world, what's going on plus, if you need to, it can send you pictures while quadcopting around :D
• create a Skype like application without needing Skype at all ... OK, Skype offers an amazing service and we cannot even think to compete on web, but still ...

End Of The Rant

I am pretty sure John Resig, who's already using Vine since the very beginning, would actually agree with this Web situation .. or maybe not, since his story-rock API main goal was to uniform all this mess ... but should we keep relying third parts API rather than awesome, ultra skilled, exceptional people, in charge of the future of the Web?

Anyway, Wine Works With...

So once you have installed everything, all you have to do is to start polpetta in that folder and connect through these browser to that address: Chrome Canary, Firefox Nightly, Opera Next, Opera Mobile, or any other browser you think should support this app, and it will not ... keep smiling!!!! ^_^

Thanks for your understanding, I am developing web mobile since 2009, since Android 1.5, and the thing is: it never got truly better, it just kept changing and fragmenting!
Probably the reason I love my job, and the constant challenge it offers on daily basis but I'd like to do more there ...