However, that post by Ted Dziuba had me wondering. Is he right? Probably. He seems like a very smart man and considers many things I didn’t even think off. However, that fibonacci example had me confused. Why did that call take so long. Many days have passed since the original post and I never spent more than a few seconds wondering.

Until tonight. I was wondering what the general consensus was about NodeJS and came across a number of posts referring to Ted’s writing. This one in particular had me taken in. Here, Joshua Kehn takes the analog of the given fibonacci example and translates it to a few other programming languages. The result? Every other language shows this massive waiting behavior. After reading this I had to find out: WHAT IS GOING ON!?

How can figuring out the 40th number of the fibonacci sequence take several seconds!? So I wrote a quick test in Javascript (read: I copy-pasted Ted’s code) and ran it in the browser.

function fibo1(n){
	if(n < 2){
		return 1;	
	}	
	else{
		return fibo1(n-2) + fibo1(n-1);
	}
}
var result = fibo1(40);
document.write('Result : ' + result);

3.08 seconds. Holy shit… At this point I was hooked. How!? Why!? This looks like reasonable code… Let the computer calculate what needs to be calculated and return the result as soon as possible, right… Can’t be more than about 50-60 function calls… I took the liberty to count the number of function calls…

var fcalls=0;
function fibo1(n){
	fcalls++;
	if(n < 2){
		return 1;	
	}	
	else{
		return fibo1(n-2) + fibo1(n-1);
	}
}
var result = fibo1(40);
document.write('Result : ' + result + '&lt;br/&gt;Function calls: ' + fcalls);

331 160 281 function calls!? That’s 331 million function calls. Are you freakin’ kidding me!? For the 40th number in the fibonacci sequence. WHAT THE HELL!?

At this point I was doubting my own skills in writing a valid step counter in Javascript before actually believing that this many function calls were actually being executed. However that would explain the 3 second delay… Wait, what!? 3 seconds? To execute a mindblowing 331 million function calls? (It is worth noting that Sheldon Cooper was wrong: Once your mind is blown, it can be re-blown.)

But… Joshua correctly stated a mistake by Ted, which is that Ted’s fibonacci algorithm is incorrect. Let’s fix that…

var fcalls=0;
function fibo1(n){
	fcalls++;
	if(n < = 2){
		return 1;	
	}	
	else{
		return fibo1(n-2) + fibo1(n-1);
	}
}
var result = fibo1(40);
document.write('Result : ' + result + '&lt;br/&gt;Function calls: ' + fcalls);

Hey! Look at that! Only 204 668 309 function calls! That’s a solid 130 million calls less. The execution time dropped by a second too! Only 2.1 second execution… Still: That’s a long time and that is still an INSANE amount of calls.

At this point I decided I was done with this crap. This implementation sucks royal rastaballs. Whoever thought the above was clever programming needs to stay off the drugs and reconsider his carreer choices.
I remember writing fibonacci generators in high school, almost 10 years ago, and they didn’t take long. In fact: They were instantanious. Tell you what: I’ll just try it the old fashioned way… The human way.

function fibo2(n){
	var current = 0;
	var previous1 = 0;
	var previous2 = 1;
	for(var i=0;i < n;i++){	
		//previous 1 + previous2 = current
		previous1 = previous2;				
		previous2 = current;
		current	 = previous1 + previous2;
	}
	return current;	
}
var result = fibo2(40);
document.write('Result : ' + result);

Hey, look at that! Almost no execution time! The result was there like *snap* that. In fact Javascript tells me it took between 0.000 and 0.001 seconds…  And the fibonacci result is the same… What does that tell us?

Well, of course: The fibonacci example was a demonstration that NodeJS will in fact block. But how is that different from any other language. In fact, the only thing proven here is that NodeJS (actually the V8 Javascript engine) computes fairly quickly compared to PHP for example.

What I’d like to add here is that OF COURSE by writing BULLSHIT code, you can make any runtime block, stumble, freeze and turn to complete utter bollocks. What the fuck is the matter with you? If this is your argument, then frankly you should’ve kept it to yourself because the rest of the world already knows this.

This doesn’t only apply for NodeJS, it applies to ANY PROGRAMMING LANGUAGE: Writing crappy code will return crappy performance. This is nothing new: It’s common sense. Programming is a mental challenge and it will always stay that way. If you try to prove something by pointing out that bad programming results in bad performance, then perhaps you should reconsider the usage of the word ‘braindead‘ in some more appropriate context.

I’m sorry but the fibonacci example in Ted’s post is a ‘bad example’ to prove a valid point. Yes, NodeJS will in fact block. However the example seemed more like an example of how bad code can provoke bad performance. That’s not an argument. That’s a fact.
By writing good better code, I fixed the example and it runs fine now. And yet that doesn’t invalidate Ted’s point about blocking. (See why this is a pointless argument?)

I just wanted to have this out in the open. Made me nuts when I figured this out. And I still maintain I have no opinion about NodeJS and how bad it might be.

You can see a testpage with the different calculations here.

Let me start by saying that I am a passionate Actionscript Creative (if someday I might grow up, you can call me a Flash developer but not just yet) and I absolute love the web as it exists today. I love HTML and CSS. I even like Javascript (a bit) (it’s not my favorite, but we get along pretty good). So don’t go off thinking I’m taking sides.

What are we talking about today?

Earlier this week, Serge Jespers wrote about Adobe vs the open web, which kinda looked like a Flash vs HTML5 article from a distance (because let’s face it: The Adobe platform on the web is mainly the Flash platform). I had a lot of conversations about that in the past and the one thing I have come to conclude is that you can’t actually compare those to each other.
Not even remotely.

So to what should we compare it then?

People keep referring to the features that the Flash Player offers and which the developer might want to use. And then their statement goes on with ‘You can’t do that with HTML!‘
Of course you can’t! There are thousands of things you can do with Flash, which you just can’t pull of with HTML, CSS or Javascript. But if you really want to compare Flash and HTML, you gotta do it right:

Flash Player vs FireFox ( or IE or Safari or Opera or any other browser)
Timeline and Actionscript vs HTML and Javascript (and CSS if you really want)

(Please, stop throwing those vegetables at me… Thank you.)

Comparing the Comparables

So now you’re looking at me, thinking I am completely nuts… So let me clarify…

The Web Browser

A piece of software that allows you to browse the web and renders HTML and CSS into a beautiful layout (depending on the website that is) for your viewing pleasure.

The Flash Player

A browser plugin that allows you to view .SWF files and render them as described in the bytecode (or wherever) into a vector based movie.

This is a very brief description, and despite that I think you could already conclude their first difference (and what they got in common).
Both the Flash Player and the browser are built to display content, and render that content using a specific set of rules. They are both the same on a different level.

W3C and ‘Web standards’

I really like how ‘Web standards‘ is such an often used term (which sounds so professional and simple at the same time), and yet I am unable to describe exactly what it means (even after reading the Wikipedia explanation, I understand but don’t quite know it…). But I bet you, you already know where I’m heading… Exactly. There are rules being written, just to make sure everybody is writing valid code, and every browser displays it the same. Silly to say: Not everyone is writing valid code and nearly no browser displays exactly the same. I’m not bashing the W3C people here (although this might really look like it). In fact, I admire them for their effort. But in spite of that: The problem is there. Everybody is building browsers; websites look different on each and every one of them – even if the HTML/CSS you wrote is 100% valid.

Adobe and the Flash Player

Adobe is (mainly) the only instance developing, evolving, releasing and publishing the Flash Player (mobile devices and such left out). A lot of people think that this is a bad thing. Only one company in charge of whatever is going to happen with our beloved browser plugin? Hell yea!!
I can see how open-sourcing the Flash Player might help evolving the capabilities (features AND efficiency) but the payoff would be ‘Crossplayer compatibility issues’.
Imagine how you would publish your SWF, upload it to the server, and then test it in different Flash Players. (This is actually where my previous point of ‘Browser vs Player’ should start making sense)

So there’s our second conclusion. Browsers can be built and released by about anybody whereas the Flash Player is developed and maintained only by Adobe. Both do have ground rules to which you better stick when creating content but seen as only 1 company is creating the Flash Player and a lot of people are creating browsers, the browser implementation of those rules differs and results (may) vary. (Flash content which is not perfectly ‘valid’ will just result in a ‘movie not loaded’ message…)

Soooo…

Comparing ‘Flash’ to ‘HTML’ is wrong. The Flash Player is more like a browser, but on a different level (it runs as a plugin inside the browser). Comparing them is just plain senseless.

Okay… Still… SWF kicks HTML’s ass!

That’s a plausible one… but I don’t know any self-respecting webdeveloper that would agree (same goes for the opposite). If you’re on the same page as I am you’ll agree that it’s a situation depended statement.

If you want to build a game, Flash is the right choice.
If you want to create an experience to promote your latest product, Flash might be the right choice.
If you want to build a message board, Flash is undoubtedly the wrong choice.

Back to basics

In it’s early years Flash was meant to be used as ‘animated vector graphic’. For the sake of simplicity let’s just say: ‘the enhanced version of an image’. Of course today the capabilities and the use-cases of Flash have long exceeded this basic idea.

But doesn’t it feel strange to deliver information using a technology that was meant to be used as an ‘entertaining addition’?
Google doesn’t present its search results using an image or a Flash movie, right?
I can hear you go “Yea duh! That’s because Flash isn’t intended to be used for that kind of application“. Exactly…

‘The problem is choice’

It’s not about what you like most… It’s not about what is ‘the best’. It’s about what is ‘better in this case’. Right now, if somebody asks you to put a video on their HTML site, you’ll use a Flash Videoplayer (because right now Flash is the best choice to deliver video on the web: Everybody (about 99%, Adobe?) has a Flash Player installed, no (additional) codecs are needed, and not everyone is able to view HTML5 in their browser yet). That’s a no-brainer. You could go for Windows Media/Quicktime plugins but Flash would be the better choice in this case.

But if people are being asked to build a datadriven application, they’ll have a different idea about what to use. Some keep it simple and stick to basic HTML tables. Some others go nuts using jQuery and other Javascript libraries to enhance the dataviewing experience and useability of those tables. Others push it even further and choose a Flex based solution. All 3 of them will get the job done, that’s for sure, but what is the better choice in this case ? (Personally I’d go with the jQuery enhanced version)

The use of Flash or HTML each come with their own pro’s and con’s. And this is where people start arguing…

Pro’s and Con’s

Google can’t index Flash sites

Bad implementation of 'Alternate Content'

That’s true, although they’re working on it, it’s for from being ready (Google apparently has a special Flash Player that indexes Flash Movies. The only thing I can say about that: I don’t know about any of my previous Flash sites being indexed by Google yet…) . You could make use of the alternate content feature when embedding your Flash movie in the website. That way Google can actually index the content of the website, and bring the user to your website (where he/she can then view the Flash based version). But you have to implement the alternate content. And: No. ‘You need Adobe Flash Player to view this site‘ is no alternate content (read: Bad Alternate Content). And talking about alternate content: I haven’t seen many Flash sites being built to be able to ‘gracefully degrade‘. What if you users just don’t have the requested Flash version (company computer networks often disallow installation of new software). How do you enable them to use your website/webapplication? Right: Progressive enhancement. But building a Flash website, and not providing decent alternate content (read: alternate HTML/JS version of the Flash application) is not it!

People with accessibility issues can’t rely on screenreaders and such on a Flash based website.

As far as I know, today it is possible to help screenreaders understand what Flash is doing, and what the user can do. However: You have to implement this in your website.

You can now manage the browser history in a Flash site

Sure, and by all means: SWFAddress is great! But you have to manage it and that’s where it boils down to: It’s standard browser behaviour! You shouldn’t have to manage that.

Let’s face it: Flash breaks the regular web. So choosing Flash because it’s prettier isn’t the right choice. Choosing Flash should ALWAYS be a result of weighing the pro’s and con’s; not a result of you (or your client) liking Flash sites better than standard HTML sites…

Grand conclusion

(I’ll start this one with a disclaimer. Unlike Serge Jespers, I’m not paid by Adobe so this is really my opinion and not the one of my employee )

For now (and even for the HTML5-era): Flash will always offer a bigger and probably faster featureset than HTML (video, audio, audio analyzing, drawing, shape morphing, complex animations, special effects, levels of interaction perharps, etc…) but as long as you don’t really have to rely on Flash’s special features, stick to plain old HTML and CSS.

Flash and HTML are no opponents. They should be seen as couple that complement each other. Both should be used for what they’re best at. There is no winner, there’s no best. There’s only ‘better in this case‘.

Het idee was ooit ontstaan bij gesprekken over Flash-sites, AJAX-sites, Google-vriendelijke sites, en de snelst mogelijke en goedkoopste oplossing om deze RIA-oplossingen zo dicht mogelijk bij elkaar te brengen. Nick had de smaak te pakken en is er enkele maanden geleden in zijn vrije tijd aan begonnen. Gelukkig is hij koppig genoeg, zodat hij een paar weken geleden met een brede smile op zijn gezicht liet zijn hoe het ermee stond… Ik keek ernaar… Ik was onder de indruk…

Onlangs ging hij live met zijn nieuwe portfolio waarop je de Javascript class al in volle actie kan zien.

Enkele features:

• 1 site bouwen: geen extra XML, geen bijkomende PHP functionaliteit, niets. Elke HTML site kan een AJAX site worden in enkele simpele stappen.
• Het is simpel.
• De site wordt niet destructief bewerkt door het AJAX script òf de implementatie ervan. Als je browser de AJAX functionaliteit niet aan kan, surf je gewoon door de standaard HTML site, zonder te bemerken dat er in feite ‘meer onder de motorkap’ zit.
• Het script kan omgaan met ‘incorrecte’ HTML. Dit wordt niet aangeraden, maar de class is robuust genoeg om dit soort fouten te hanteren.
• Je site blijft Google vriendelijk: ondanks het feit dat je bezoekers allerhande cool shit zien gebeuren, blijft Google een standaard HTML site zien, die goed kan geïndexeerd worden.
• Deeplinking: gezien Google je site kan indexeren, kan je content van je site dus ook volwaardig naar voor komen in de zoekresultaten. Deze zoekresultaten zullen je naar de juiste pagina op de website brengen, vanwaar het AJAX script jou weer met eye-candy kan bedienen.
• Crossbrowser: Internet Explorer, Firefox, Safari, Opera. Zelfs op de iPhone kan de website inclusieve AJAX features ten volle naar voor komen.
• Error-handling en browser selection: Als er fouten gebeuren probeert de class dit zelf op te lossen. Hetzij door correctie, hetzij disablen van de class zelf, en de gebruiker zonder AJAX features verder laten surfen. Als de browser geen AJAX ondersteund schakelt de class zichzelf uit.
• Animaties: Niets is leuker dan bewegende onderdelen om de gebruiker te laten weten dat de site verstaan heeft wat er gevraagd werd. De class preload de afbeeldingen en maakt vloeiende transities van één pagina naar de andere.

En dit zijn er slechts een paar. Er zijn nog heel wat features. Meer hierover op Nick’s blog.

Voorbeeld: byDust.com
Documentatie: byDust.com

Ik ben erg onder de indruk, en zal deze class binnenkort zelf inbouwen in mijn eigen site.
Lees er meer over op Nick’s blog (Engels).

Om de tut te volgen heb je alleen een text-editor nodig (Notepad is al genoeg. Ik gebruik Dreamweaver ). Een Flashmovie kun je tijdens de tutorial zelf downloaden.

Basis kennis van HTML en ‘weten wat de Canvas in Flash is’ is vereist.

Tutorial:

We willen een Flashobject in een HTML pagina laten weergeven, en de onderliggende HTML gebruiken, om het achtergrond kleur te bepalen van het geheel.

Maak een nieuw html document aan en sla het op als ‘index.htm’ .

We willen nu kunnen bepalen waar we onze Flash willen laten weergeven. Hiervoor maken we een DIV object aan in HTML waar we later onze Flashmovie inladen.

Voeg dit toe aan de BODY in je HTML:

[html4strict]<div id=”flashDIV” style=”width:500px; height:400px; margin-left:-250px; margin-top:-200px;position:absolute;top:50%;left:50%; background-color:#FF0066;”>
Download de Adobe Flash Player om de FlashMovie te zien!
</div>[/html4strict]

In bovenstaande regel zie je meteen ook wat CSS staan. Dat is mijn manier van werken als ik iets wil centreren in het browservenster. Meteen ook een achtergrondkleur ingesteld oor deze DIV. #FF0066 for a better world
Om verder te gaan willen we nu (op een verantwoorde wijze) Flash in deze DIV gaan laden.
Mensen die Microsoft Internet Explorer 6 of Windows Internet Explorer 7 gebruiken zijn ongetwijfeld al op websites gestoten waar men eerst op een Flashobject moest klikken om het te activeren. Dit is een kwestie waar men veel naar verwijst als ‘Het Eolas Patent‘. Het gebeuren rond Microsoft en Eolas had als gevolg dat alle ‘ActiveX objecten‘ in de Microsoft browsers eerst moesten geactiveerd worden. Dit valt op te lossen door SWFObject of andere JavaScript oplossingen te gebruiken. Het fijne hieraan is dat we meteen ook verantwoorde markup in onze broncode hebben.

Download SWFObject.js en zet het in dezelfde map als je index.htm bestand.

Als de HTML pagina geladen wordt moet de browser weten dat we het SWFObject.js bestand willen gaan gebruiken. Dit doen we door de volgende tag in de HEAD-tag van ons HTML document te steken.

De volgende regel moet in de HEAD van je HTML document.

[html4strict]<script type=”text/javascript” src=”swfobject.js”></script>[/html4strict]

Nu hebben we nog een Flashobject nodig dat we in onze DIV willen laden.

Download deze Flashmovie en unzip deze ter hoogte van je index.htm. Je .SWF bestand staat dan in dezelfde map als je index.htm bestand.
Nota: Deze Flashmovie is niet door mij ontworpen of gemaakt. Ik eis geen rechten op.

Nu brengen we onze Flash en de DIV samen, door gebruik van SWFObject.

De volgende code komt onder de DIV in onze HTML.

[html4strict]<script type=”text/javascript”>
var so = new SWFObject(“dodgesquad.swf”, “flashmovie”, “500″, “400″, “8″, “#000000″,”true”);
so.write(“flashDIV”);
</script>[/html4strict]

Als we dit resultaat nu in een browser bekijken zien we een FlashMovie, met 3 actieve mannetjes, maar de achtergrond is nog altijd zwart (het achtergrondkleur ingesteld in Flash). Hiervoor gaan we een extra parameter meegeven aan het SWFObject.

Maak van:

[html4strict]<script type=”text/javascript”>
var so = new SWFObject(“dodgesquad.swf”, “flashmovie”, “500″, “400″, “8″, “#000000″,”true”);
so.write(“flashDIV”);
</script>[/html4strict]

het volgende:

[html4strict]<script type=”text/javascript”>
var so = new SWFObject(“dodgesquad.swf”, “flashmovie”, “500″, “400″, “8″, “#000000″,”true”);
so.addParam(“wmode”,”transparent”);
so.write(“flashDIV”);
</script>[/html4strict]

Als we nu naar het resultaat kijken zien we weer de 3 actieve mannetjes, maar deze keer is de achtergrond pink! Het achtergrond kleur is nu #FF0066, wat we ingesteld hebben in onze DIV.style

Dit is de volledige source code die je nu zou moeten hebben.

[html4strict]<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>
<html xmlns=”http://www.w3.org/1999/xhtml”>
<head>
<meta http-equiv=”Content-Type” content=”text/html; charset=utf-8″ />
<title>Tutorial: Transparante Flash</title>
<script type=”text/javascript” src=”swfobject.js”></script>
</head>

<body>
<div id=”flashDIV” style=”width:500px; height:400px; margin-left:-250px; margin-top:-200px;position:absolute;top:50%;left:50%; background-color:#FF0066;”>
Download de Adobe Flash Player om de FlashMovie te zien!
</div>
<script type=”text/javascript”>
var so = new SWFObject(“dodgesquad.swf”, “flashmovie”, “500″, “400″, “8″, “#000000″,”true”);
so.addParam(“wmode”,”transparent”);
so.write(“flashDIV”);
</script>
</body>
</html>[/html4strict]

Het resultaat kun je hier downloaden of hier bekijken.

Ik hoop hiermee een aantal mensen mee verder te kunnen helpen. Veel succes en vooral veel plezier!