Native HTML5, the new IE6, and bla bla bla ...

I don't know about you guys, but I am kinda bored by all these news and tweets against Microsoft ... don't get me wrong please, you may have realized over these years I have rarely been that nice with M$ products, but there is time to complain, and time time to move forward and appreciate, at least, what we have now compared with what it was 10 years ago.

IE6 is Death, Long Life to IE6

Back in time, IE6 was the kick ass browser every web developer was dreaming about:

• tons of security issues to hack in order to have access to any sort of private data (btw ... it's still like that ...)
• hybrid JScript/VBScript engines with different privileges for each language and none of them based concretely over a standard
• the predecessor of what we call today Ajax
• hybrid box model able to understand the worst markup we can possibly imagine so ... wannabe developer friendly (I'll be back to this point later)

... and so on ... with all its glory ...

Why NO future IE will be the next IE6

Now, over last 10 years many things happened:

• Firebird changed its name: Long life to Firefox
• Webkit made its path down to any sort of device
• Chrome became the must have browser
• Opera reached version 11.50-beta-HW-accelerated-maybe
• we are not alone anymore ... !

We are not living anymore in that era where WEB was letting us think about spiderman, internet was working only inside intranets, and no competitors were showing off yet.
We live in a different segment of the browsers timeline, a space where web surfers are more concious, less passive, and specially less ignorant ... we live in a time-frame where internet is almost everywhere and it's even portable in our pockets ... is IE there? We never cared about it, and this is the future!

Feel Free To Choose!

The Antitrust somehow forced Windows OS to let the user chose one out of 3 browsers ... I mean, more than this I wonder what do we expect ...
I have never seen such technique in any other Operating System ... but we still complain whatever IE will block people forever ...
Moreover, even if there is no choice, nobody in my family is using Internet Explorer, unless it's at work and hopefully to use work related services, not to go on Facebook or the HTML5 version of Youtube ... you know what I mean ...

Legacy Support: The Beginning Of The End

The most common excuse we can ear from a Company about the usage of IE6 is this notorious "legacy code" buzz word. For all those non techy people out there, when you ear this word this is the translation: "We don't have money to update our slow and deprecated infrastructure and we don't have enough competent people able to migrate data and business logic into something better that could bring only more value to our infrastructure and our daily basis work. Since as I have said at the beginning we don't have money, we cannot temporarily hire external Companies that would be able to do that as well ... uh, I forgot to mention we are simply out of the market 'cause we are stuck in year 2000 or earlier and new technologies ... which new technologies?".
Moreover, if we want to be reached with our online services by these companies and their employees, it is not just about the browser!
All PCs in these companies are most likely relict unable to perform any good with latest "special FXs" we all would like to put in our web ( transitions, shadows, WebGL, etc ... )

In an Ideal Web World

This is how the web development would have been in the ideal world every developer is dreaming about:

• write once run everywhere exists
• jQuery would have never been created
• hobbyist and wannabe web developers, the specie more than ever growing these days mainly thanks to precedent point, would be the only web developer category so ... engineers, go and get a real job!
• browsers won't have a name since they all act the same and there is no difference except some performances number

I am kinda joking but let's face reality. "Web For Everybody" does not mean that all browsers will be the same, it means that we must be good enough to be able to bring the web in as many browsers as possible ... this is our job, and if everything would be the same, our job would be the most boring ever ... isn't it?
The reason me and many other thousands like me are challenged on daily basis are indeed limits we keep facing in different environments.
These limits may be extremely hard to solve, cross platform speaking, but thanks to latest technologies, thanks to latest browsers, and thanks to our hard work, we can already bring what we really want in every platform: this is our job!

IE9, IE10, and the Native HTML5

I honestly do not mind about marketing words, neither users mind that much. They eventually update their browsers and if no happy, they change it again: easy.
What I do mind is that IE9 supports for HTML5 is good enough to bring fresh new content and design in every house.
What we can show today in this browser and others is unbelievable if we think we had to deal with bloody PNG alpha channel and IE6 for ages!
Why do we complain that much then?
I do believe the only day we should really complain is the day we have used all possible techniques, fallbacks, and alchemies we could imagine to shrink 100% of IE9 potentials, the same we have done over these years with IE6 ... isn't it?

Premature Complaining VS Research

The main reason people adopted libraries such jQuery is the ability to bring "unthinkable" features even in older browsers. Hacks for rounded corners, DOMContentLoaded, canvas shims, Flash fallbacks, Sockets, PNG32 support, and many others have been all over the place in latest years ... and what do we do now?
Rather than appreciate the fact we don't need them anymore and focus on what we really need next we would like to cuddle ourself behind the excuse "as usual, IE lacks behind".
Now, honestly, ask yourself how many times you have been dealing with WebSockets, Database API, WebWorkers, WebGL, and all newest technologies we may already complain about without having a clue what the hell are these useful for ... and without considering that we will always have a way to fallback.

Is WebGL missing? Not Really, Not Now

Is not that since the browser has it, everybody can use it ... is much more. WebGL opens doors to the GPU and I bet +80% of web developers out there have zero knowledge about OpenGL ES 2.0 potentials and GLES shaders language.
Apple clearly confirmed they have no intention to put WebGL support in their devices, and the reason is kinda logic: it is easy to put the GPU in an infinite loop and drain the battery or make the device unstable.
Microsoft had different reasons to do not invest much into WebGL: DirectX
Chromium invested time to create Angle which aim is to convert OpenGL ES 2.0 calls into DirectX and make WebGL possible in Windows OS as well.

Different Fallbacks

If we really care about WebGL, if we really need to put such heavy content in our web pages or our advertisements ( shaders + textures + runtime parse/translate/compile ) we can always fallback into shims through Silverlight or Flash Player, as soon as it will implement Adobe effort to bring hardware accelerated 3D content within.

Wasn't Flash Death? ... NO!

... and thanks gosh will hopefully never die! Flash has been our best friend for all those missing features now partially re-implemented in HTML5 and Flash has been always one step forward.
All those shims about storages, databases, files uploads, canvas, sockets and all the magic behind some library scene ... flash is not good but it's not that evil as well.

So, What's Next?

If it's about IE9 limits, we can simply wait that day we have discovered all possible ways to do what we need to do while if it's about WebGL we need some kick ass 3D developer with excellent knowledge of these 3D APIs: Silverlight and Molehill, aka Flash Player Incubator.
With these kind of developers out there we could have possible shims for WebGL or, even better, a jQuery3D library able to make WebGL development easier and, hopefully, without GPU loops and memory exhaustive problems.
Finally, what I really would like to see out there, is less "oh my god we are stuck forever again" and more "hey, I have spot this limit, let's figure out how to break it".

My 2 cents and happy holidays everybody, I'll be back in few days.

Fragment and Vertex Shaders: My Way To Load

I have finally received the fifth and amazing version of the OpenGL SuperBible book and I have already started digging into it, really well done for what I can tell.

The book is mainly focused on "real OpenGL development", something surely more suitable for tough C/C++ developers rather than Web Monkeys like me but since the book includes an OpenGL ES 2.0 related part, and since latter spec is basically what we can find in WebGL, it's always better start learning what's next knowing history and background of the used technology ... and here I am :-)

Something Already Wrong

I am not completely sure about "who started this techniques", John Resig with his micro template inside script nodes with a type text/html may be the indirect responsible for a sort of growing "monster" we can see in almost every WebGL related example ...

HTML Embedded Shaders, the Web 3.0 NO-GO

Let me pass the therm, but 3D websites are not that far away from reality. Minefield, Chrome, WebKit, and probably others, are working hard with Khronos and WebGL and I do believe official support will come later this year with next browsers releases ( ... hoping IE9 final won't "block the world" avoiding WebGL support ... )
Back in the topic, the common examples technique is a step backward in 1999 where runtime loading did not exists (aka: Ajax or scripts injection) and an HTML page was a trash bin for any kind of rubbish.

A Better Technique

We are in 2010 and we want use latest technologies, so why should we use old and deprecated one? Let me show this simple getShader function alternative:

// our shaders base path
loadShaders.base = "shader/";

// our shaders loader
function loadShaders(gl, shaders, callback) {
    // (C) WebReflection - Mit Style License
    function onreadystatechange() {
        var
            xhr = this,
            i = xhr.i
        ;
        if (xhr.readyState == 4) {
            shaders[i] = gl.createShader(
                shaders[i].slice(0, 2) == "fs" ?
                    gl.FRAGMENT_SHADER :
                    gl.VERTEX_SHADER
            );
            gl.shaderSource(shaders[i], xhr.responseText);
            gl.compileShader(shaders[i]);
            if (!gl.getShaderParameter(shaders[i], gl.COMPILE_STATUS))
                throw gl.getShaderInfoLog(shaders[i])
            ;
            !--length && typeof callback == "function" && callback(shaders);
        }
    }
    for (var
        shaders = [].concat(shaders),
        asynchronous = !!callback,
        i = shaders.length,
        length = i,
        xhr;
        i--;
    ) {
        (xhr = new XMLHttpRequest).i = i;
        xhr.open("get", loadShaders.base + shaders[i] + ".c", asynchronous);
        if (asynchronous) {
            xhr.onreadystatechange = onreadystatechange;
        }
        xhr.send(null);
        onreadystatechange.call(xhr);
    }
    return shaders;
}

With above minifier friendly function we can avoid shaders on the page. The natural advantage is that we can properly organize shaders in a structure like this one:

root

    shader

          vs // vertex shaders

             ShaderName.c

          fs // fragment shaders

             FragmentName.c

Having a proper extension means that we can edit these files with highlighted syntax and we can edit these files a part, without looking for id or scripts inside an HTML page. Fragment and Vertex Shaders are our "application templates", so why on earth should we include them in the layout? Via loadShaders we can use cached shaders, share shaders, etc etc, and here some usage example.

vra gl = canvas.getContext("experimental-webgl");

// synchronous order, one shader
var myFragmentShader = loadShaders(gl, "fs/myFragment");

// synch, more shaders
var shaders = loadShaders(gl, [
    "vs/what",
    "vs/ever"
]);
// [whatShader, everShader]


// asynchronous loading
loadShaders(gl, ["fs/what", "vs/ever"], function (shaders) {
    var
        fragmentWhatShader = shaders[0],
        vertexEverShader = shaders[1];
    ;
});


// asynch in "don't care mode, just cache them"
loadShaders(gl, ["fs/what", "vs/ever"], true);

Features

• Synchronous or Asynchronous loading


• Multiple Loads (unordered compilation for each result)


• Ordered Results, (order respected accordingly with paths)

If I have forgotten something please point it out but even more please, whatever you like or not this solution, do not include shaders in your HTML page (OK, OK, gotcha, for some example it may make life easier but ... you know how people get examples ... right?)

Cheers :)