Science Zingers for Marsday, 20100309
Posted in Science Etcetera on March 9th, 2010
Science Stuff for Moonday, 20100308
Posted in Science Etcetera on March 8th, 2010
Science Paths for Venusday, 20100305
Posted in Science Etcetera on March 5th, 2010Visit msnbc.com for breaking news, world news, and news about the economy
Science Wonders for Jupiterday, 20100304
Posted in Science Etcetera on March 4th, 2010
Yangtze River Dolphin
What’s the Right JavaScript Framework, If Any?
Posted in Geeking Out on March 3rd, 2010
JavaScript Frameworks
I recently checked out Google’s AJAX Libraries, which, aside from being inaccurately titled, provides a means for web developers to access functionality in a wide variety of popular JavaScript frameworks and toolkits without having to host the libraries themselves. Simply include the base Google library, and then use it to load whatever framework you want to access in you code. It’s not for me, as I’m a total control-freak when it comes to production implementations of my code, and I don’t like having my web pages hang up trying to access URIs on outside domains, which definitely happens to the code I run locally using this tool; however, it does provide a convenient playground for testing out different JavaScript frameworks and toolkits.
You can do anything with JavaScript, but you have to program around its shortcomings. How JavaScript functions depends on the ECMAScript engine running it, with Firefox running TraceMonkey, Chrome running V8, and Internet Explorer running Trident, it makes it difficult to write code that runs the same in all browsers. Then there’s JavaScripts’ object-orientation strategy, which uses prototype chains for inheritance, confusing most OO programmers. Finally, there’s some major oversights in JavaScript functionality, like the fact that it lacks a trim() function.
There are two types of JS Frameworks, those that extend JS functionality for the advanced programmer and those that simplify coding for the novice. If you’re an advanced programmer, it’s nice to have true object-orientation in your JavaScript. If you’re a novice, it’s nice to be able to whip out some fancy special effects with just a few lines of code. What follows is my understanding and impressions of these frameworks as I used Google’s Libraries to play with them.
Beginner Toolkits
The Dojo Toolkit, Yahoo! User Interface Library, jQuery UI, and Script.aculo.us are three toolkits brimming with easy-to-implement effects to enhance a webpage without resorting to plugins like Flash or Silverlight. Underneath these toolkits are frameworks. For instance, Scriptaculous is built on the Protoype framework, and jQuery UI on the jQuery framework. Aaron Newton’s jQuery vs MooTools has a great explanation of the difference between a toolkit and a framework:
Part of this consideration is the notion of a framework vs a toolkit. MooTools is a framework that attempts to implement JavaScript as it should be (according to MooTools’ authors). The aim is to implement an API that feels like JavaScript and enhances everything; not just the DOM. jQuery is a toolkit that gives you an easy to use collection of methods in a self-contained system designed to make the DOM itself more pleasant. It just so happens that the DOM is where most people focus their effort when writing JavaScript, so in many cases, jQuery is all you need.
Each of these toolkits provide their own unique features. For instance, YUI provides sophisticated event timing, categorized into “available,” “contentready,” and “domready,” allowing for executing JavaScript functions when document objects become available, when the object and its children become available, and when the entire document is available to improve the performance of your web page. Nifty, but also a bit esoteric, a reminder that, when we buy into a framework, we are also buying into a development methodology.
One problem I have with all of the larger, bells-and-whistles JavaScript toolkits is that I find myself browsing their libraries of plugins, trying to find some way to work their dazzling features into my web pages; when, in reality, the way I develop, the features I need to implement simply emerge, and I go looking for scripts as I need them. If I adopt a feature-rich framework, then I’m going to be out of luck the moment I need functionality it doesn’t include.
Another thing to consider is how intrusive the toolkit is. If you’re planning on including 50 to 100 kilobytes of framework code in every web page on your site, how much more code is needed to exercise its functions?
Here’s Dojo’s fade-out effect:
dojo.require("dijit.form.Button");
function basicFadeoutSetup() {
function fadeIt() {
dojo.style("SomeElementId", "opacity", "1");
var fadeArgs = {
node: "SomeElementId"
};
dojo.fadeOut(fadeArgs).play();
}
dojo.connect(dijit.byId("basicFadeButton"), "onClick", fadeIt);
}
dojo.addOnLoad(basicFadeoutSetup);
Here’s the YUI version of the fade-out effect:
YUI().use('anim-base', function(Y) {
var anim = new Y.Anim({
node: 'SomeElementId',
to: { opacity: 0 }
});
var onClick = function(e) {
e.preventDefault();
anim.run();
};
Y.get('SomeElementId .yui-remove').on('click', onClick);
});
Here’s the jQuery UI version of the fade-out effect:
$("SomeElementId").hide('highlight');
Finally, we have Scriptaculous’ fade effect:
$('SomeElementId').fade();
On the one hand, the Dojo and YUI examples appear to offer much more customization in the implementation of their features, while the jQuery UI and Scriptaculous examples offer simplicity and ease of implementation. If you need something customized with the latter two toolkits, you’ll need to code around them. While with the former two toolkits you’ll need to customize them their way.
And that can be a real problem. If you are a novice JS developer and you adopt Dojo or YUI, you will never become an advanced JS programmer. You might become an advanced Dojo or YUI programmer, but those are much more narrowly defined skill sets, which are less marketable to companies with established development environments.
Advanced Frameworks
Sam Stephenson’s Prototype framework and the MIT Licensed MooTools are true JavaScript frameworks intended for advanced programmers. Both frameworks overcome the awkwardness of JavaScript’s prototypal inheritance by enabling class-based inheritance to make it function more like a mainstream object oriented language.
You won’t find fade() functions in these frameworks, but you will find enhanced means of accessing the objects in a web page (DOM) (jQuery goes so far as to provide a means to query the DOM for arrays of objects). You will also find useful functions such as trim() and cross-browser, streamlined methods for making AJAX calls. With Prototype and MooTools, you’ll still need to write your functions, but with the adoption of the methodologies within these frameworks, you should find your coding streamlined and more robust.
As thin and streamlined as these frameworks are, they still include much more functionality than most JavaScript developers need in their average web page. If I need a trim() function, I’ll go get one somewhere online. If I need mainstream object-orientation, I’ll use Prototype on the page where I need it. The problem with these frameworks is that, if you’re smart enough to be using them, you’re probably smart enough to not be using them.
Conclusions
Here’s an example of what it takes to roll your own fade-out effect:
var TimeToFade = 1000.0;
function fade(eid)
{
var element = document.getElementById(eid);
if(element == null)
return;
if(element.FadeState == null)
{
if(element.style.opacity == null
|| element.style.opacity == ''
|| element.style.opacity == '1')
{
element.FadeState = 2;
}
else
{
element.FadeState = -2;
}
}
if(element.FadeState == 1 || element.FadeState == -1)
{
element.FadeState = element.FadeState == 1 ? -1 : 1;
element.FadeTimeLeft = TimeToFade - element.FadeTimeLeft;
}
else
{
element.FadeState = element.FadeState == 2 ? -1 : 1;
element.FadeTimeLeft = TimeToFade;
setTimeout("animateFade(" + new Date().getTime() + ",'" + eid + "')", 33);
}
}
function animateFade(lastTick, eid)
{
var curTick = new Date().getTime();
var elapsedTicks = curTick - lastTick;
var element = document.getElementById(eid);
if(element.FadeTimeLeft <= elapsedTicks)
{
element.style.opacity = element.FadeState == 1 ? '1' : '0';
element.style.filter = 'alpha(opacity = '
+ (element.FadeState == 1 ? '100' : '0') + ')';
element.FadeState = element.FadeState == 1 ? 2 : -2;
return;
}
element.FadeTimeLeft -= elapsedTicks;
var newOpVal = element.FadeTimeLeft/TimeToFade;
if(element.FadeState == 1)
newOpVal = 1 - newOpVal;
element.style.opacity = newOpVal;
element.style.filter = 'alpha(opacity = ' + (newOpVal*100) + ')';
setTimeout("animateFade(" + curTick + ",'" + eid + "')", 33);
}
Of course, you would hide the above code away in an include file, and invoking the fade effect would simply require:
fade('SomeElementId');
But including the above code, even uncondensed, would require only a small fraction of what including any of these frameworks would necessitate in condensed form. Plus you have the strength of understanding your code and how it works. You don't always have the time to spend a week rewriting someone else's script to fit the specifics of your situation or writing your own from scratch, but if you do, you will be rewarded for it. The script will become your own.
Frameworks and toolkits have their uses, and I don't want to disparage them; however, two rules come out of this analysis for me. First, developers who are novice enough to use a feature-rich toolkit will hurt themselves by adopting one, because they won't be learning mainstream JavaScript. Second, developers who are skilled enough to make use of an advanced framework probably don't need one, but could benefit from analyzing them for techniques to use in their own code.
I'll continue to play with these frameworks from time to time in order to learn new techniques and best practices, but I'll stick to my current strategy of copy-and-pasting code from a wide variety of online sources. The best JavaScript framework, to my mind, remains the World Wide Web.
Further Reading:
Science Snippets for Mercuryday, 20100303
Posted in Science Etcetera on March 3rd, 2010
Science Smidgens for Marsday, 20100302
Posted in Science Etcetera on March 2nd, 2010
2,000 Years of Artificial Life in Art
Posted in Geeking Out on March 1st, 2010In his book Chess Metaphors, about chess, neuroscience, and artificial intelligence, Diego Rasskin-Gutman devotes a short section to the popular myths, literature, and films dealing with characters creating artificial humans from motivations like desire, necessity, curiosity, and power. More fascinating than the motivations for producing AIs, is the evolving origins of where the artificial life comes from in fiction:
8 AD
One of the myths retold in Ovid’s Metamorphoses is of King Pygmalion who, when he grows disenchanted with real women, sculpts a statue of a woman with whom he falls in love. The Goddess Venus brought the statue to life in response to Pygmalion’s prayers, and the King married her. There were other examples of artificial life in Greek mythology, but this is the most compelling throughout the following millennia, inspiring numerous works of art, including George Bernard Shaw’s 1913 play Pygmalion, which was later remade as the 1956 musical My Fair Lady
1800s
As the legend goes, the 16th century rabbi of Prague Judah Loew ben Bezalel created a Golem out of clay or soil, bringing it to life with the word “emet” on its forehead. When the Golem had terrorized those prosecuting the Jews sufficiently to have them relent, the rabbi killed his creation by erasing the letter “e” from its forehead, leaving “met,” Hebrew for “death.” Although there is divine intervention involved in the creation of this artificial being, everything is under the rabbi’s control.
1818
A story of artificial life without anything divine in its origin’s is Mary Shelly’s Frankenstein, where Dr. Frankenstein fashions “the monster” using ambiguous means; however, Dr. Frankenstein’s background in chemistry and other sciences certainly contributed to his success in creating life. The monster is an outcast, abandoned by the fearful doctor and alienated from other people due to his frightful appearance. So a second trend appears in the myths of artificial life, that the more involved a human is in the creation of life, the more inhuman that life becomes.
1921 and 1927
This trending of artificial life into malevolence continues with Karel Capek’s play R.U.R. (Rossum’s Universal Robots), where artificial humans, mass produced at a factory, revolt and drive the human race to extinction. The Machine from Fritz Lang’s Metropolis also serves as a cautionary tale, engineered by Doctor Rotwang, the robot impersonates the leader of the workers and uses their trust to inspire a revolt. In the first example, the artificials use their overwhelming numbers to overthrow humanity, in the second, a single artificial uses its resemblance to humanity to manipulate it. The robots grow increasingly insidious as they grow powerful.
2001
Although not in Rasskin-Gutman’s examples, the robots in the film Artificial Intelligence: A.I both blend in with humanity and are mass-produced; however, Spielberg and Kubrick’s future AIs are highly benevolent beings, curious and generous. They lament the extinction of the human race that we brought upon ourselves, and try to understand us by resurrecting humans out of space-time. Although this new myth has yet to withstand a few decades of time to see if its message will stick in cultural memory, it does signal a new direction for human perceptions of artificial life, from divine gifts, to manufactured monsters, and now manufactured gods. “The secret of life is sought in a gradient of divine intervention to human intervention, which is also a temporal gradient,” Rasskin-Gutman notes, “representing the triumph of science over religion.”





















