Zohar Arad

The Blog

The Broken Web

Preface

As usual, opinions vary, and you, as well as I, are entitled to our opinions. This post is one of those rants that might tick you off. If that’s the case, I truly apologize and hope you can see beyond the frustration and harsh tone into the abyss of open discussion.

Let’s talk about the broken Web.

It all began with a small project

I was working on a prototype version of an HTML5 audio player the other day, and wanted to find a good library that bridges the gap between the varying audio-coded support of different browsers.

Yes, there’re Sound Manager 2, jPlayer, Buzz, SoundJS, MediaElement and others. I did, however have a couple of small additional requirements:

  1. No jQuery (or any other library) dependency - I intended the final code to work on both mobile and desktop, and thought using Zepto instead of jQuery on the mobile version will make a lot of sense
  2. Solid HTML5 audio API emulation - Since MP3 support on FF / Opera requires a Flash bridge, I wanted the library to seamlessly emulate the HTML5 audio API in the Flash bridge, to be able to take full advantage of whatever is available in HTML5 (audio events for example)
    Without boring you with all the tests and details, I ended up choosing the fabulous MediaElement library, which comes with a full-fledged jQuery player & UI or as a bare bones audio library to use as one sees fit.

During this tedious soul (and code) searching, I did stumble upon two very sore points which seem, in my mind, to break the Web.

The ugly face of Codec war

Forget about browser war. Media codec war is in full rage, and has been long before Chrome reared its open-source head and joined the battle.

In one camp, are the open-source enthusiasts, like Firefox and Opera, who righteously support open source codecs like Ogg/Vorbis, Opus and WebM/Vorbis.

In the other camp, are the closed-source dictators like Apple’s Safari and Microsoft’s Internet Explorer who support MP3 and AAC.

And, in the middle we have Google’s Chrome, which supports just about anything you throw at it.

So far, nothing is new under the sun and we, the developers, are doomed to either encode audio in multiple formats or devise clever contraptions to bridge this idiotic gap.

To add insult to injury, there’re claims of noticeable differences in sound quality between the aforementioned formats. AAC is supposedly better than MP3. Ogg/Opus is claimed to be much better than Ogg/Vorbis and given the right podium, I’m confident Microsoft will swear by its own WMA format as superior to the rest (which, by the way, is an excellent audio format, so I hear).

The outcome of these petty rivalries and indecision is twofold.

First, people like me, who want to provide high-quality, browser-based, audio-driven applications, slowly and surely learn to hate those who stand in our way. Curious why Web developers hate Microsoft and Apple or are frustrated with Firefox? Here’s one of the reasons. Want to know why we love Chrome? Same reason but in reverse. The thing is, we one day might end up deciding not to support your poor excuse for a browser, because we can, while you go on producing silly ads about “the browser you love to hate”. Why not take that money and do something positive with it?

Second, the same users browser vendors chase after are the ones being punished. Either by poorer audio quality, plugin dependency or the very remote risk of infringing on those precious patents browser vendors hold so dear.

The solution to all this closed-source / open-source, good-mediocre-bad, audio-codec nonsense is simple. The Web is open. Media on the Web should be open. Move your arse for a change and do something real for your users. Decide on the best open-source candidate and integrate it to your browser. And, in the meantime, adding WebM/Vorbis or dare I say Ogg/Vorbis support to your browsers won’t kill you. Keep on supporting your cherished closed-sourced codecs to your hearts content, and let us developers and end-users the freedom to create and enjoy beautiful things.

There… I’ve said it and feel a bit better now, and that’s even without touching on the same topic in the mobile browser world.

jQuery isn’t Javascript

I used to dislike jQuery a lot (and still struggle with it sometimes, although I’m learning to love it and see its appeal to Javascript developers). Being a vanilla JS and MooTools man initially, not only did I not see what all the fuss was about, but I also got the notion that jQuery is dumbing people down a bit by hiding a lot one the one hand, and not encouraging clear, best-practice coding standards on the other hand.

However, before you go all berserk, I am not criticising jQuery or you personally. This was just a preface.

One of the most significant outcomes of jQuery’s well-deserved success, is that people start developing for jQuery instead of Javascript. Just take a look at Twitter Bootstrap and Zurb Foundation. Both depend on jQuery to drive their Javascript plugins. There’s even a debate on Bootstrap’s Github page about adding support for Zepto instead of jQuery, which is, in my opinion, quite reasonable, since Zepto seems like a natural choice for mobile platforms, which Bootstrap aims to support.

And why all this sudden interest in jQuery you ask? Well, mobile Web is all the rage these days. Despite jQuery’s awesomeness, to me, it doesn’t feel like a natural first-choice for mobile Web applications. I want something smaller, nimbler and more polite. A “jQu” or an “ery” but not both.

But, but, but…. jQuery is everywhere!!! Everyone uses it! It’s awesome. It’s the goddess of Javascript and comet of browsers.

Yup… and it’s also 32KB without the trimmings.

As I was searching for that omnipotent HTML5 audio library, I suddenly began noticing how many developers couple their code with jQuery. Although it does have merit, mainly in cases of complex UI and DOM manipulation, a lot of simple things don’t need a Javascript library. Moreover, the assumption jQuery is common enough to target it and only it, is a bit bias.

To me, it feels as if some people are simply too lazy to write vanilla Javascript or consider smaller, unobtrusive libraries (check out http://microjs.com/ for a few ideas). It’s almost as if the jQuery phenomena encourages people to shy from vanilla Javascript. In some ways it reminds of of the Rails phenomena, which helped you write Websites in Ruby very quickly, but didn’t necessarily make you a better developer (and in some cases made you a bit worse).

As a side note, it’s a bit saddening to see how MooTools, which aims to change you write Javascript, didn’t catch on, while jQuery did, and thus changed the way people both write and perceive Javascript nowadays.

Putting MooTools and Rails aside for a moment (this is a grown-up talk about mature languages like Javascript), what stroke me next was that if jQuery is so damn popular, and people obviously prefer it to vanilla Javascript, there must be something a little broken in the official Javascript API.

Let’s admit it, writing $ is much more concise that writing document.querySelectorAll, and writing $.get is much more readable that the multi-line XMLHttpRequest object spaghetti.

I must say, that in that light, Javascript’s vanilla APIs (DOM, XHR, DOM Events to name a few) seem both antiquated and cumbersome in comparison to their jQuery et al counterparts. If we put aside older browsers’ ill-implementations of Javascript, there’s still no excuse to write addEventListener() instead of on() for example.

This not only fixates the need for libraries like jQuery, MooTools and Dojo, that do a wonderful job in hiding those cumbersome APIs behind friendlier implementations, but it also discourage Javascript developers from getting to know the language fully and truly.

Try asking Javascript developers if they know what event bubbling or “this“ mean and see what they tell you.

Although unrealistic, perhaps the solution is to go with the flow, and adapt the Javascript APIs to a more modern, human-readable version that will one day negate the need for facades like jQuery. It’s either that, or change the C++ coding style to something a bit more jQuery-like, in the hope those who write the Javascript VM stop inventing long, camel-cased API methods.

One can only sigh and hope…

Comments

Proudly published with Hexo