HyperTextMatters
2 February 2006
 
Why Python makes sense for web development
Forgive me for rehashing such a hackneyed idiom, but I can explain why Python makes sense for web development in one statement:

data = {"foo": "bar"}

Executing the above in Python, followed by: print(data["foo"])
results in the output:  "bar"

This would be mind numbingly straightforward except for the following exercise, which should be able to be completed by even more readers than the above, because they don't have to have Python installed.

Copy the statement: data = {"foo": "bar"}

In between script tags within the head tags of an HTML document, then set the onload attribute of the body tag to: alert(data["foo"])

This too results in the output: "bar"

Furthermore, not only do Javascript and Python share the same general syntax for defining the above literal representation of an associative array -- Javascript "objects" and Python "dictionaries", but they also share the same syntax for defining literal ordinal arrays:

arr = ["foo", "bar"]

Now, in either language, accessing: arr[0]
results in: "foo"

It gets better.  These structures can be arbitrarily nested within one another.  JSON, or "Javascript Object Notation", starts with an associative array as its outermost structure, but there's no reason to not start with an ordinal array:

superbowls = [{}, {"winner": "Green Bay", "loser": "Kansas City", "score": "35-10"}]

After defining the above in either language, the statement: superbowls[1]['winner']
results in the same output in both: "Green Bay"

Javascript and Python do not necessarily allow all types of data to represented identically, so in order to take advantage of their commonalities subsets of each would be required.  As a for instance, in Javascript booleans can be represented by the barewords true and false, whereas in Python the same values would be represented by the capitalized versions True and False.  Both languages however evaluate 0 as false and non-zero integers as true, so this case is easy enough to work around.  It won't always be so easy, but still it seems promising and worthwhile.  One carefully constructed Javascript/Python data structure could be used to configure both client side and server side functionality, debunking the myth that the two tiers must be engineered in two entirely different manners, thereby doubling development costs, etcetera.
Posted by htmatters at 8:13 PM | Comments (0)
6 January 2006
 
EIBTI for Javascript: explicit is better than implicit
Javascript's "prototype" driven nature allows programmers to alter the behavior of built-in types thusly:

String.prototype.isEmpty = function() { return /^\s+$/.test(this); }

Just because you can, doesn't mean you should though.  For instance, a method you add to String's prototype might require two arguments, but a future update to the language itself might add the very same method with the arguments reversed.

Consider this alternative:

function FormValue(str) { this.str = str}
FormValue.prototype.isEmpty = function() { return /^\s+$/.test(this.str); }
var test = new FormValue(" ");

Note you must explicity instantiate a FormValue instance, rather than implicitly operating on a String (primitive).  Consider this a feature.  For instance, Python has popularized the acronym EIBTI, or "explicit is better than implicit."  No wonder MochiKit, "a production-quality framework that brings powerful and well-known Python idioms to JavaScript," rightfully leaves String.prototype alone.
Posted by htmatters at 11:55 AM | Comments (2)
9 September 2005
 
Javascript Meets Ruby
Javascript meets Ruby, in the context of Kiko, a new online calendar application.  Specifically, Kiko has implemented a Javascript port of Ruby on Rails' "ActiveRecord" subproject, for implementing the "model" facet of an MVC (model-view-controller) application.  If record/model have you thinking data/database you'd be correct, and if you're thinking AJAX so Javascript can talk to the backend, you'd be correct again; see http://www.kiko.com/jsactiverecord/ for an abstract/tutorial and source code, a snippet of which is:
 
var me = types.user.create({email:"", password:"pass"});
 
Note, that is not XML being passed but rather a Javascript "object literal", or JSON.  No wonder Kiko, though barely a month old and still in beta, is being held up as a shining showcase for cutting edge Javascript technology.
Posted by htmatters at 6:36 PM | Comments (0)
22 August 2005
 
Javascript: Ten Years Squandered
Several technologies integral to the explosion that is "the web" are ten years old as of 2005, including ColdFusion, Java & PHP.  But let's not forget Javascript -- or, on second thought, let's.  Because Javascript came into being to enable client side form validation, and after ten years we are hardly closer to doing this correctly than in 1995.  AJAX is not the answer -- other than for simple logins where interaction with server side data is necessary anyway -- because AJAX introduces potential network latency and thereby defeats the original purpose.  JSON, being parsable on both the client and server, gets us partway, but not all the way there, as regular expressions, which are vital to form validation, are prohibited.  And that's too bad for JSON, because with vision beyond being yet another data exchange format, it could rival AJAX for buzz and utility.
Posted by htmatters at 11:29 PM | Comments (3)
19 July 2005
 
eval'ing JSON
JSON's unfortunate reliance on Javascript's eval() method calls for a new standard: JSON++
Posted by htmatters at 7:12 AM | Comments (2)
19 June 2005
 
AJAX' Achilles Heel
maps.google.com with Javascript disabled
AJAX -- "Asynchronous Javascript and XML" -- is certainly getting a lot of attention lately.  Too bad it, and the so-called XmlHttpRequest upon which it relies, are misnamed: XML is not necessarily required.  Of much greater consequence, however, is that AJAX applications may not work if the user disables Javascript.

Try it yourself: disable Javascript in your browser, then visit maps.google.com, which arguably started the AJAX buzz.  You will receive the message that "JavaScript must be enabled in order for you to use Google Maps".

Enablement of Javascript is outside of the control of the developer and cannot be relied upon, except perhaps for a private intranet application.   For a public website however you should consider alternative strategies alongside of, or instead of, AJAX.  We will consider such a strategy next month.
Addendum, Dec 2005: The image below is a screenshot, dated Aug 2005, of visiting maps.google.com with Javascript disabled. Now instead they provide verbiage ("Your web browser is not fully supported by Google Local.") followed by this unhelpful link

Posted by htmatters at 6:27 AM | Comments (39)
22 May 2005
 
Grokking the Virtual Machine
This month we consider Javascript's syntactic cousin, Lua:  

a = {}
a["b"] = "c"  

This code is valid in both Lua and Javascript; the first line creates a Javascript "associative array", or in Lua, a "table".  In both languages these constructs serve as "objects", so both of the following are valid statements for retrieving the "b" property of "a":  

a["b"]
a.b  

Other similarities include that functions are first-class values in both languages: they can be stored in variables, passed as arguments, and returned as results.  Furthermore, both languages support "lexical closures", which allow "data hiding" (see last month's column).  

Lua may well be the lowest-level of the C-based scripting languages: it is a "register-based" virtual machine, and has some hooks directly into C.  Lua originated in Brazil but, designed especially for embedding, is popular worldwide, particularly with game programmers.  Look into Lua, and become a better Javascript programmer!
Posted by htmatters at 3:56 PM | Comments (0)
22 April 2005
 
Data Hiding with JavaScript
Did you know that JavaScript supports "data hiding" inside user defined objects? Consider the differences between how the two properties myVar1 and myVar2 are declared inside the following constructor function:  

function MyObject() {
  this.myVar1 = "public";
  var myVar2 = "private";  
  this.getMyVar2 = function() {      
    return myVar2;
  }
}  

myVar1 can be directly accessed because it was defined using "this", but myVar2 cannot because it was defined using "var"; myVar2 can only be accessed via a "method", e.g. the inner function "getMyVar2", as demonstrated below:  

var myObj = new MyObject();
alert(myObj.myVar1);        //returns "public"
alert(myObj.myVar2);        //returns "undefined"
alert(myObj.getMyVar2());   //returns "private"  

Think of "this" as the equivalent of the "public" access modifier in other object oriented languages, and "var" as the equivalent of "private". Read more about this technique at: http://devpapers.com/article/291
Posted by htmatters at 3:45 PM | Comments (0)