NetBen I'd better make a blog myself instead of trolling other blogs…

Internet Explorer is in trouble

Over a decade ago, I found myself baffled at the fact that the roles where reversed. It suddenly became more enjoyable to develop for Internet Explorer (5) then for Netscape Navigator. What the hell happened? IE gained momentum and next to aggresive warfare with Netscape, Microsoft pionered a rather spiffy browser which became a defacto standard for modern day browsers. Netscape became insignificant as a development target, you developed for IE or bust. The innovation ended with IE6 in 2001 and all was well.

IE6 was good and innovation for the holy trinity (JS/CSS/HTML) remained perceivably stagnant for 5 years. The craving for innovation however was still there and during those 5 years Flash filled that niche providing standards for rich media.

Then came Firefox

Whilst Firefox 1.0 was launched in 2004, it became mainstream and thus meaningful (in my opinion) in 2006 with FF2 approximatly 1 year after Jesse James Garret coined the term Ajax based on the endeavours from a spiffy search engine company and obviously the work at Adaptive Path. From then on JavaScript became more interresting and caused a boom in rich interaction development, developers realised that in theory, what Flash offered could also be done with just the holy trinity. Well.. some things needed to change first.

Webstandards

WHATWG pionered HTML5 back in 2004, which W3C adapted in 2007. ECMA had ES4 draft ready which Macromedia/Adobe adapted for flash, only to be abandoned in late 2007 in preference for Harmony (2008). Meanwhile CSS was the only technology that had seen continuous development all this time, though didn't receive browser support till the other two technologies started to awaken from the perceived slumber.

It's important to point out, that innovation for browser technologies hasn't remained stagnant at all, we just needed a new competitor for IE to put everything in motion. IE was tardy and that's going to cost microsoft dearly.

The beast woke up and started flailing.

Ofcourse, Microsoft has a lot of smart people working for them and the internet revival starting in ~2004 and peaking again in 2006 caught their attention. So we got IE7 in 2006 and IE8 in 2009, *opinion* but their intent was mainly to enter round 2 of the browser wars and safe as much of their market share as they can */opinion*. The signal I received here was that Microsoft started to take competitor browser vendors seriously, but they made one huge mistake.

Microsoft did not jump on the standards bandwagon as much as they should and created even more legacy, neither did they create a continuous upgrade scheme and waged round 2 of the browser wars with the wrong strategies. Through failure they learned and IE9 is looking great, in fact, it looks like IE9 might make up for all the ground they lost.

Webstandards are the boxing gloves in this new round of browser wars, Microsoft had doned on their embeded features and OS integration gloves.

So whats the trouble?

Innovation in the holy trinity picked up momentum in the last few years, I had to adjust my personal estimates of when they will become significant for commercial development. My new prognosis is that HTML5, CSS3 and ES5 will become mainstream standards in 2 to 3 years based on the speed technological advancement and more importantly, implementation is going. My estimates and prognosis might carry no weight in the web community, but I think anyone who has to make educated estimates as to what technologies to use in enterprise environments will conclude the same.

When looking at browser statistics, all Microsoft browsers since 5.0 (yes even IE5.0) are still in use today, they're all going to break. They will all be perceived as total and utter garbage and this will reflect on Microsoft and the IE trademark. With IE8, Microsoft is miles behind and IE9 enters the scene way too late. The majority of the IE users will not upgrade to IE9, that's a proven fact and they will all experience a worsening web experience and blame Microsoft.

The 'modern' browsers have had an active upgrade scheme, so the majority of their users are used to upgrading whenever a new version is out, some browsers even automated this upgrade process. Best of all, they're not integrated into the operating system (signifying the power of loose coupling yet again).

History repeats itself, NN was a great browser with many innovations, but websites where build for IE5+ because it was easier to develop for and with aggressive tactics from Microsoft had the biggest market share. Now the shoe is on IE because developers want to move forward and seeing the aggresive action undertaken against IE6 by developers, this will happen. Microsoft painted themselves into a corner and will be in trouble.

What can Microsoft do?

Create and implement an upgrade strategy NOW! Re-educate their user base to upgrade frequently and even more important, work on reducing upgrade costs for companies and organisations.

Whilst most developers are easily anti or pro Microsoft, I personally feel that Microsoft is an important player in our industry wether I like their products or not. It's in our interrest to see Microsoft do the right thing and remain a major player, especially now they appearantly lost the reckless part of their killer approach (pushing Netscape out of the market was their biggest mistake for self preservation imo.) and take on a more participant approach. Companies need competition to stay on top, Microsoft proved that while profitable, eliminating the competition equals social and innovative suicide and will cost dearly later on.

The last thing I want to see for the industry I love, is for example Google winning this round of browser wars and see yet another 5-10 years of internet dark ages.

Presenting objection.js

Quote from 'Design Patterns' from the gang of four.

Favor object composition over class inheritance.

With JSoo I wanted to provide tools for OO JS, but I was still thinking in terms of pseudo classical inheritance. Foolishly I created JSoo to be a prototype constructor and registry and loader. Well the register and loading part of JSoo made it's way to mikado which is still under development and the OO part went into Objection. I had to write Objection since I wanted a cleaner and clearer way of dealing with objects in preparation of ES5.

Presenting objection.js.

Objection is a tiny OO toolbox (just under 2kb minified) that can change the way your write your JS programs and you should at least give it a try if only to prepare yourself for ES5 goodness.

First of all, it offers #create though a teensy bit different from the ES5 (Object.create) implementation. If there's a initialise (or initialize) method on the to-be-cloned object, it will be invoked (without arguments) once the object is created offering an alternative to the pseudo classical constructor. Initialise should only be used to add new property instances to the new object where you don't want property references from the old object (ie. array/object properties). Most arguments passed to constructors are usually property setters, so augment the object through #create rather then using constructor arguments.

Example:

var Mammal = {
   initialise: function(){
      this.sounds.roar = 'some mammals can roar';
      this.roar();
   },
   roar: function(){
      alert(this.sounds.roar);
   }
};
 
var cat = Obj.create(Mammal , {
   sounds: {
      roar: 'miauws'
   }
}); // alerts 'miauws'
cat.roar(); // alerts 'miauws'
 
// intentfully omitting propertiesObject to illustrate that mammal.initialise gets invoked.
var dog= Obj.create(Mammal );
dog.roar(); // alerts 'some mammals can roar'

Why is this better then pseudo classical inheritance and constructors? First of all, we just describe the Mammal object as an object, not as a function and attaching properties to it's prototype. Instead of 'new' we call Objection.create() (Obj is an alias) at which point we can decide to leave the new instance as is or augment it with extra properties through a property descriptor (2nd argument) or we can mixin properties from another object alltogether. So we use reusable packets of properties rather then constructor arguments.

I just added the initialise/initialize method behaviour to mitigate one major ambiguous feature. All inherited/cloned properties are references by default, meaning that an object or array property on the parent object will be exactly the same as on the child object. This feature also manifests itself in the pseudo classical way of creating objects. I might dedicate a post on this in the future.

Another nice method in Objection, is the adapter method, which creates an adapter object to remap method names or add method combiners without changing the original object.

var incompat = {
   halloWereld: function(){
      alert('hello world!');
   },
   dagWereld: function(){
      alert('goodbye world');
   }
};
 
var compat = Obj.adapter(incompat, {
   'hello' : 'halloWereld',
   'bye' : 'dagWereld',
   'helloAndBye' : function(){
      this.halloWereld();
      this.dagWereld();
   }
});
 
compat.hello(); // alerts 'hello world!'
compat.bye(); // alerts 'goodbye world'
compat.helloAndBye(); // alerts 'hello world!' and 'goodbye world'

Possible uses for the adapter method, is to make all thos Selector engines that all choose different method names (grrr) plugable into all your programs. Simply remap 'select', 'find', 'query' to 'qsa' or whatever you find logical for a selector method

Obviously, we also want to check if an object inherits from another object and though we can use 'isPrototypeOf' to do this. I've always found inheritance an obscure name, I mean, a ferarri IS a car, a cat IS a mammal...

var Mammal = {};
var Insect = {};
var Fish = {};
var Cat = Obj.create(Mammal);
var Dog = Obj.create(Mammal);
var Felix = Obj.create(Cat);
 
// #is
Obj.is(Felix, Cat); // true
Obj.is(Felix, Dog); // false
// #isAll
Obj.isAll(Felix, Cat, Mammal); // true
Obj.isAll(Felix, Insect, Cat); // false
// #isSome
Obj.isSome(Felix, Insect, Cat); // true
Obj.isSome(Felix, Dog, Insect); // false

Clear as rain isn't it?

And now finally, the #factory method, I'll just post the example right away.

var BasePizza = {
   orders: function(nr){
      this.total = this.total + (nr * this.price);
      this.ordered = this.ordered + nr;
   },
   ordered: 0,
   total: 0
};
 
var pizzaFactory = Obj.factory(BasePizza);
 
pizzaFactory.addType('hawai', {
   pineapple: true,
   ham: true,
   price: 12
});
 
pizzaFactory.addType('peperoni', {
   peperoni: true,
   price: 10
});
 
pizzaFactory.addType('delux', {
   olives: true,
   broccoli: true,
   anjovis: true,
   extraCheese: true,
   price: 14
});
 
var bart = pizzaFactory.create('hawai');
bart.orders(1);
 
var lisa = pizzaFactory.create('delux');
lisa.orders(1);
 
var homer = pizzaFactory.create('peperoni');
homer.orders(3);
 
var total = bart.total + lisa.total + homer.total; // 64

I could go on and on about possibilities and how this way of programming makes much more sense, instead, I'll just offer up some links and safe more indepth info for future articles.

Further documentation can be found here:
http://wiki.github.com/bgerrissen/objection/

Downloads:
http://github.com/bgerrissen/objection/downloads

Enjoy

Mea culpa, it was obvious.

Kind guys in prototype IRC channel pointed me to this article http://yura.thinkweb2.com/named-function-expressions/ which explains what's happening.
qFox from fronteers IRC also kicked me in the groins for not knowing the difference between expressions and declarations.

Basically, declarations are compiled before anything else inside a scopeblock, causing the "functions float to top" feature.

1
2
3
4

test(); // alerts "Hello world!"
function test() { // declaration
   alert("Hello world");
}

This ofcourse creates ambiguous code and should not be done if you want your code to be clear and appearant.
Instead declare functions as part of an expression by assigning them to variables or properties.

1
2
3
4
5

test(); // alerts undefined
var test = function test() { // expression
   alert("Hello world");
}
test(); // alerts "Hello world!"

The fact that it seems to work in FireFox is because they foolproofed it and now I get it, I feel they shouldn't have.
Though the declaration spec creates ambiguity, it's the spec, it does exactly as ordered and a browser should not fix developer mistakes and incompetence.
(Yeh, I was incompetent myself for not knowing this! I admit it! sigh)

I read a lot of books, written a lot of JS code and read oogles of JS articles on the web and this little piece of (in hindsight) common wealth information always eluded me. So leaving my rather newbish blog post up so other devs who run into this, will have yet another article to explain what they're encountering.

If/else + functions = madness

My code style might not be perfect, but the following code should be pretty straight forward in what to expect right?

if(true) {
   function test() {
      alert("SUCCESS!");
   }
} else {
   function test() {
      alert("FAIL!");
   }
}
test();
// alerts "SUCCESS!" in FireFox (3.5.7)
// alerts "FAIL!" in IE8, Opera 9.62, (win) Safari 4.0.4
// need to install and test this in google's Chrome still!

Whats going on here???!

I first encountered this "feature" in Safari and thought it was a local incident, though to my suprise, I reproduced it in other browsers as well!

Function literals float to the top of the scopeblock, however functions inside a failed clause, should be ignored by the interperter.
Am I missing the reason why so many browser vendors implemented it this way?
Is FireFox/Mozilla actually the odd duck here? And if so, for the love of god, why?
Is this a recent development? A discrepancy introduced by engines competing eachother over speed?

Also kinda weird that after years of JavaScript, I encounter this now...
Or is this something I never encountered before untill I started bloating my code for better readability, structuring and reducing if/else expressions?

Sure, we can mitigate this easily by changing our coding style and never declare functions through the literal notation, assigning anonymous functions to variables.

if(true) {
   var test = function() {
      alert("SUCCESS!");
   }
} else {
   var test = function() {
      alert("FAIL!");
   }
}
test();
// alerts "SUCCESS!" everywhere =/

But that's just plain daft... using function literals is pretty straightforward and everyone will trip constantly over this discrepancy when trying to write clean/clear code.
Now I have to explain to Java developers learning JS that they should avoid using function literal declarations...

Will investigate further.

What is JavaScript, really? Part 1, the runtime.

I am currently in the process of preparing to teach some Java/backend developers JavaScript and intend to try my damn hardest to teach them the potential JavaScript can bring to any environment. Unfortunatly that entails going into low level JavaScript to first explain the difference between an expressive dynamic script language and a rigid compile language. We frontend developers use JavaScript daily and never really sit back and think about what it is that we're actually working with and thus the language persists of having a reputation of being arcane, illogical and certainly not better then a good compiled application. That's just plain wrong, but how do we explain that!

Don't compare!

Comparing JavaScript with any compile language is a farce though, it's apples and bananas, in fact, comparing JavaScript with other dynamic languages is also equally ridiculous as most other script language still compile into bytecode or simply isn't muteable at runtime. No, what really sets JavaScript apart is not so much the language, but it's marriage with the runtime interperter (engine). Frontend developers complain about various runtime engines (usually IE's) and never really stand still to marvel at the brilliance of those engines, wether they support JavaScript entirely or not.

JavaScript ROCKS!

I mean, here we have an environment where we can plug in our programs and on runtime adapt the program entirely changing it's behaviour and logic on the fly! It goes far beyond the realm of write and run. A lot of credit for this goes to the engine, however the standards on which JavaScript is based creates a perfect marriage of language and runtime. For example, without muteable objects, applications that make use of extreme dynamics would be bloated hogging too much memory, take away lambdas and all throw-away-execute-once methods would be persisted on objects, again hogging more memory. And then there are closures, lovely, brilliant closures, without closures lamda's wouldn't even be half as effective as you would always be forced to create methods instead of functions to adress other objects.

JavaScript SUCKS!

All this expressive power and potential however comes at a cost. Obviously not compiling to bytecode and interpeting commands at runtime sacrifices performance, the algorithms you can and should perform are restricted to relative simplicity limiting the things you can do with JavaScript and it's runtime. Is that bad? No, not really, we go from a process taking nano seconds to miliseconds and whilst huge computations (3D or even 2D rendering for example) remain out of grasp for JavaScript, it's still more then good enough for most mundane tasks. For example, you simply do not need immense processing power for 3D and 2D x,y,z calculations whilst leaving the rendering to native or more specialist API's, which coincidentally can be added to the JavaScript runtime.

So how does it compare?

Ok, time to compare apples and bananas as I feel it's needed to fully understand. Languages that compile to bytecode and pretty much have everything predefined inside a container, are overkill and too rigid for mundane tasks. You can get pretty far with compiled programs, but that means having a huge initial code base for simple functionality, forcing you to use predefined components in places where flexibility is required. Components are adapted to support more functionality and flexibility and become unwieldy and ambiguous to work with. So basically, with compile languages it only makes sense to make ok looking applications, otherwise it would simply cost too much time to develop.

Whereas in JavaScript, this becomes as easy as pie (if you learn it properly) since you are not restricted by the conventions most compile languages impose on a developer and whilst all this expressive power creates at first glance, ambiguous confusing code, it's really not that hard to maintain once you can let go of all the conventions and restrictions other languages put on you. So JavaScript liberates you in the right places.

In conclusion

Whilst JavaScript is currently being ported to the backend and desktop, it's my opinion that this is a mistake if you can't make it talk or integhate to/with compiled programs. I see JavaScript more as a language that tells other program API's what to do, preprocessing and reformating user defined options before inserting the data or commands into an compiled application. This is where the dynamic runtime shines and where the compiled runtime becomes restrictive. In browsers JavaScript is the language developers use to push other application API's around like the DOM, Flash, and even the browser itself. It can do the same with serverside API's whilst integrating directly with the clientside API's and with some imagination, JavaScript can be used as a logic operator between multiple platforms simplifying interfaces to bare essentials.

I will have a hard time teaching JavaScript properly to java/backend developers... Part 1 is about showing them it's not *another* programming language, but a rich addition to *any* programming language. Time to kick them out of their sandbox!