My JavaScript book is out! Don't miss the opportunity to upgrade your beginner or average dev skills.

Sunday, October 24, 2010

The Layer ... Of The Layer ... Of The Layer ...

When I read tweets like this one I cannot avoid a quick comment but the reason I am posting, is simply to explain that every time we write a web page/application, we are dealing with at least 4 different layers.
Moreover, this post is complementary for few slides I have introduced at front-trends, specially regarding the "avoid classic OOP emulation when not necessary" point.

Layer #1: JavaScript Libraries

We all know the DOM is a mess, and this is most likely the reason we chose a JS library rather than deal directly with possible problems we can have when we develop an x?HTML page.
Even if many developers don't care, I keep saying that every millisecond gained in this first layer, the page itself, is important.
Moreover, if we have a good understanding of the JavaScript programming language, we can easily realize that all these "Java Pretending Style Frameworks" emulating classic inheritance and OOP are not easier to maintain neither faster for what we need on mobile devices, included Netbooks.
The "easier to maintain" fuzz, associated with "Java style JavaScript", a sentence that does not make sense itself, is only a Java developer point of view.
Well written JavaScript without any "wannabe another language" pragmas, is truly much easier to both understand and write, modify, or fix, while the great magic behind this or that framework/library could become our first enemy when something goes wrong and we would like to understand and debug that magic 'cause we had a problem and we have strict deadline that may not match with a bug lifecycle.
Finally, as easily demonstrated via this test page, we can all spot how much more it costs to simply initialize a new instanceof constructor, compared with proper way to go natively via JavaScript, in that case made easier by this essential script, developed following TDD and tested here cross browser.
Anyway, common sense first and fast production quality, should always be kept in mind when we decide an approach, rather than another one. So, here frameworks play usually quite good role, the one to bring same functionality cross browser.
But what is a browser?

Layer #2: The Browser

As libraries are considered an abstract way to reach same goal in all browsers, browsers are simply abstract applications able to bring the web cross platform.
This is were the browser speed may vary, accordingly with the platform, and were every technique able to speed up render ( DOM+CSS engine such Gecko, Trident, others ) and JavaScript ( engine a part such V8, JavaScriptCore, SpiderMonkey ) is more than welcome. These guys are implementing any sort of trick to make the page and the code that fast, even if they have to deal with different operating systems. And guess what is an operating system?

Layer #3: The Operating System

We are even lucky if the browser deals directly with the operating system graphic API, since many other middle layers could be part of this stack ( flash or third parts plugins, as example ).
You cannot expect that Linux, Mac, and Windows, just mentioning fews Desktop related ( more choices on mobile world ) magically display and provide browser functionalities via the same API. We would need something like a jOSQuery library here to make it happens ... but even worse, every operating system may have another abstract layer able to use, as example, Hardware Acceleration.

Layer #4: The Hardware

Open GL ES 2.0 is simply another abstraction able to transform API calls into specific hardware driver calls which means that starting back from the DOM and the used WebGL or CSS3 with HW support, things have been modified, translated, re-created at least a couple of times.
In few words, if we asked too many things to do on first abstract layer, and being the first the slower one, nothing can be that fast.

As Summary

We, as web or scripting programming languages developers, rarely think that performances on the highest level ever can be that important but unfortunately, that highest level is the slowest one ever so, specially if we would like to reach best frame rate via canvas, WebGL, or CSS3 animations, it's highly recommended to be sure that the strategy/code we are using is the best one for our requirements.
As example, if we spend just a millisecond more to create each object we need for a single frame, we can easily switch from 30fps, a decent visual framerate, to 29 or less, were things will start to be visually slower for our eyes ...
Finally, kudos for Opera Mini and its growing market share, I am pretty sure it will become soon the IE for mobile platforms, making developers life easier, being a portable browser fallback for whatever website or application, hoping will not have all IE problems we all know.


Anonymous said...

Shame that ibm oracle and others do no read your or other js blogs.

Andrea Giammarchi said...

well, that's not my fault :) but all I can say, is that IBM and Oracle are indeed not that into "portable web development"
They are rather Enterprise solutions providers, able to dictate target browsers and minimum required hardware which means they may not care of extreme performances, specially on highest layer ( they do on pico as example ).
But maybe, aren't they simply missing a massive slice of the users market share? ;)

Unknown said...

your Class implementation is very interesting and I like it.
Class abstraction is not the only one we should use, but is an important and powerfull one, especially, combined with Abstract Classes/Interfaces, we can leverage Patterns as described in books... and that's extremely important for medium to large systems because the common ground of patterns helps keeping complexity al least more clear.
classes are good sometimes, but Interfaces are the real power js is missing...

Andrea Giammarchi said...

thanks devsmt, my Class is entirely based on module pattern so that the closure can be used to call directly the "parent" method, passed as argument and pointing to the extended Constructor.prototype

statics are a little addiction that may be useful but the result is extremely performant for both parent calls, initialization, and closure access when and if necessary.

In few words with a slightly different, JavaScript friendly, approach, you can have more than many other Class emulations out there ;-)

Interfaces? These can be well documented and manually implemented (check W3C site as example) , I am not sure we are truly missing them since we can easily use modules to enrich whatever object or prototype ;-)

Anonymous said...

dude, your 'benchmark' is crap

"Dude, We Could Go +24026% Faster!"

dude, adding up the single test percentages is plain stupid.

dude, and the single test percentages calculation is f-d up aswelle, e.g. first test:
for loop +509%
addressed length way: 1826 +4%
classic way: 1755 +485%
reversed way: 300

dude, i stopped reading after that.
and dude, you should stop writing.

Andrea Giammarchi said...

I love constructive trolls!