visage|SDK for HTML5 — face tracking in JavaScript countUp.js — dependency-free, lightweight JavaScript “class” to create animations with numerical data Semicolon.js — the most useful JavaScript library for cargo cult programmers International Telephone Input — adds a flag dropdown to any input, which lists all the countries and their international dial codes next to their flags
So what do you make of these recent going ons?
Is node-webkit the next big thing? Are you still confused by closures? Do you have your own list of resources to share?
I keep stumbling across React by I can’t seem to find the time for it, just like the author of the What is React? article.
The fact that it completely mocks the DOM and only touching the real thing when it needs to, that’s one thing that I find reason enough to get into it.
Also, nice article about Google Dart, very interesting read.
Do you have any thoughts about whether this would be a good or a bad thing?
At first glance it seems an exciting development, but on the other hand it runs the danger of fragmenting the ecosystem and as Mr Eich says, two VMs, with their own GC and both attempting to interact with the DOM sounds a bit like a recipe for disaster.
I’m not Dart fan as of yet, who knows, maybe I’ll never really dive into it.
And what I’d really like to try is TypeScript, if only there were some other tools beside Visual Studio that integrates it so well and that would allow me to really consume it, because is still so JavaScript-ish.
But I believe any of these two build up for the next JavaScript, and that’s a very good thing. No need to worry, panic or get mad here.
I’ve not had a chance to look at all of those patterns yet (there are a lot).
Would you mind giving a concrete example of one or two which should be replaced.
Sorry, Pullo, just reached a point I guess. Programming is not a cult, you’re required to seek and to question, you’re required to showcase and to prove.
When it comes to such differences, sometimes readability can trump performance, sometimes terseness can trump readability.
One can’t just throw “should” because it’s simply never true for everybody at once, but one should make a valid point as to why some use cases may benefit. Call it programmer’s politeness.
In the case of if-else vs. switch, there is no relevant conclusion. The performance difference is too small, browser results are not one-sided and the agreement is to use whatever serves you best.
Some interesting points are that switch could be implemented as a look-up table, while if-else has the liberty to augment the conditional on each branch.
Finally, while one could emulate certain parts of the other, and while the reverse may also be true, there is no strict equivalence between if-else and switch.
I’ll be looking at react also, it’s the first concept I know of that is challenging the idea of templates building a big string and updating the DOM directly.
if (value == 0) {
return result0;
} else if (value == 1) {
return result1;
} else if (value == 2) {
return result2;
} else if (value == 3) {
return result3;
} else if (value == 4) {
return result4;
} else if (value == 5) {
return result5;
} else if (value == 6) {
return result6;
} else if (value == 7) {
return result7;
} else if (value == 8) {
return result8;
} else if (value == 9) {
return result9;
} else {
return result10;
}
Is better written using a lot less code as:
switch(value ) {
case 0: return result0;
case 1: return result1;
case 2: return result2;
case 3: return result3;
case 4: return result4;
case 5: return result5;
case 6: return result6;
case 7: return result7;
case 8: return result8;
case 9: return result9;
default: return result10;
}
or even as:
var retArray = [result0, result1, result2, result3, result4, result5, result6, result7, result8, result9];
if (value >= 0 && value <= 9) return resArray[value];
else return result10;
I haven’t looked at all the patterns but while all the ones I looked at that they say are bad basically are bad, not all of the ones they offer as better alternatives are necessarily the appropriate alternative. There are some quite good patterns there though as well.
Admittedly the original author wasn’t at all clear. I myself had to re-read it a few times to understand what he was trying to show with his code, especially since that long chain of if-else you quoted was, according to the author, a “binary search”, which of course it isn’t. I finally realized that the author was giving us a kind of before-and-after picture.
Before:
if (value == 0) {
return result0;
} else if (value == 1) {
return result1;
} else if (value == 2) {
return result2;
} else if (value == 3) {
return result3;
} else if (value == 4) {
return result4;
} else if (value == 5) {
return result5;
} else if (value == 6) {
return result6;
} else if (value == 7) {
return result7;
} else if (value == 8) {
return result8;
} else if (value == 9) {
return result9;
} else {
return result10;
}
TBH I think I prefer the series of if-else over the hybrid.
Though the example is simple so I imagine in some cases where the conditionals are testing for a lot of different things (not “ranges of values for which to test”) a hybrid would be better. eg.
Even though the code I quoted was the before - the after should have been one of the two alternatives that I posted - the switch statement or the array and not the less efficient and much harder to read alternative that was provided.
One further thought on that pattern for comparing a value to numbers.
If we know that the value will always be an integer between 0 and 10 then no comparisons are needed at all to return the appropriate one of the eleven values - you can do it in the return statement:
