Baffling Results from my Javascript Class(-ishness) (Ninjas explain!)

[dasacc22]

Ok, So recently I've taken an interest in javascript. By interest I
mean taking it more seriously as a language. One of the first things I
wanted to do was to see if I should adopt a framework like mootools to
allow for classical inheritance type of stuff or if I should develop
using the prototypal javascript inheritance. This lead me to really
dig in deep to javascript scope and all of its nuances, especially
considering prototype.

Along the way, pecking away at my smjs console (aptitude install
spidermonkey-bin), I eventually wrote this function class() {} as I
was trying to see what I could get away with in poking at the scope of
functions and their prototypes. I was particularly annoyed with a
seperation between the constructor and that which was prototyped and
the foresight required, which Im going to lack since Im new to the
game. Anyway, heres the function,

<pre>function class() {
var that = arguments[0];
for (var x=arguments.length-1; x&gt;=0; --x) {
m = new arguments[x];
for (var i in m) { that.prototype = m; }
}
}</pre>

effectively, this allowed me to write my prototypes in the constructor
as well as extend functions. It was all in the name of learning and I
wasn't considering it practical. So basically I wrote stuff like

<pre>function object() {
this.init = function(kwargs) {
for (var k in kwargs) {
this[k] = kwargs[k];
}
}
}

class(A, object)
function A(kwargs) {
this.init(kwargs);
}

var a = new A({name: "Daniel", age: "24"});</pre>

I was also playing around with object constructors (unsuccessfully)
curious as to if i could implement magic methods that could be
inherited and run automatically, but yeah, that went no where so i was
all but about to abandon this whole excursion when I decided, before I
do, I wonder how much more memory my function class() {} uses and how
much slower it is from doing it the standard way. By standard, I mean
what I basically learned from perusing the net and from MDC javascript
1.5 Engineering Model Example. Heres what I have for the "standard"
way

<pre>function object() {}
object.prototype.init = function(kwargs) {
for (var k in kwargs) {
this[k] = kwargs[k];
}
}

function A(kwargs) {
object.prototype.init.call(this, kwargs);
}

var a = new A({name: "Daniel", age: "24"});</pre>

Now my profiling isn't very scientific I suppose, I used top and timed
the execution from within javascript, but the results are consistent.
What I basically did was this

<pre>var date1 = new Date();
var milliseconds1 = date1.getTime();

load('test2.js');
var l = [];
for (var j = 0; j &lt; 5000; ++j) {
l.push(new A({name: &quot;Daniel&quot;, age: &quot;24&quot;}));
}

var date2 = new Date();
var milliseconds2 = date2.getTime();

var difference = milliseconds2 - milliseconds1;
print(l.length)
print(difference)</pre>

where load('test2.js') was the "standard" way and load('test4.js') in
a seperate file was my way. The first thing that caught me off guard
was that memory consumption was the exact same. I was half expecting
my method to take more memory b/c the function definations existed in
two places, but I guess the javascript runtime compiler doesn't cause
this to happen, so yippie freaggin do da. Now what left me baffled was
that my way was consistently faster then the standard way. Here are
the time results, running 10 in a row

* all times are in milliseconds
=== Standard ===
54
58
49
55
55
53
53
49
53
52

=== My Way ===
42
41
42
45
45
42
42
48
48
48

The numbers were close, so then i decided to increase the number of
objects created to perhaps provide a more significant and visible
difference. So I increased the number of objects from 5,000 to
500,000.

=== My Way ===
5716
4257
4229
4331

=== Standard Way ===
7601
4866
4913
5564

Its as if the javascript compiler runs faster instantiating an object
property and linking it to a prototype then it does when just
instantiating a prototype property. And it doesn't require any extra
headway in memory to do it.

If theres any javascript ninja's that can explain whats going on,
thatd be simply awesome.

 

[dasacc22]

Its as if the javascript compiler runs faster instantiating an object
property and linking it to a prototype then it does when just
instantiating a prototype property. And it doesn't require any extra
headway in memory to do it.

If theres any javascript ninja's that can explain whats going on,
thatd be simply awesome.

Ah, I just realized it while making pancakes. the .call() method is
causing the extra execution time. Modifying the "standard" to look
like this

function object() {}
object.prototype.init = function(kwargs) {
for (var k in kwargs) {
this[k] = kwargs[k];
}
}

function A(kwargs) {
this.init(kwargs);
}
A.prototype = new object;

var a = new A({name: "Daniel", age: "24"});

causes it to be consistently the same as the stated "my way"

 

[Michael Haufe (\TNO\)]

Ok, So recently I've taken an interest in javascript. By interest I
mean taking it more seriously as a language. One of the first things I
wanted to do was to see if I should adopt a framework like mootools to
allow for classical inheritance type of stuff or if I should develop
using the prototypal javascript inheritance. This lead me to really
dig in deep to javascript scope and all of its nuances, especially
considering prototype.

If you want to take it seriously as a language, don't use a crutch
like the above listed libraries. They try to hide the language from
you among other things.
I think you need to reevaluate how you approach the language. Don't
pretend there are classes, and don't try to fake them.

 

[David Mark]

If you want to take it seriously as a language, don't use a crutch
like the above listed libraries. They try to hide the language from
you among other things.

Ain't that the truth. But the typical users of these libraries don't
believe it. I recently saw a comment from one of those ardent library
defenders that mocked the idea that only a small group of people (e.g.
CLJ) actually understand browser scripting. It's beyond bizarre that
these same people put all of their trust in very small groups of
people who have demonstrated year-in and year-out that they don't get
it at all. The proof is the change logs (and the accompanying
discussions).

They may think that the language is irretrievably broken (it's
certainly not) or they think the varying DOM implementations _are_ the
language, but I think the above-mentioned proof is the key to
understanding this strange behavior. Seeing their JS "idols" struggle
mightily against the IE6/7 "menace", year after fruitless year (to the
point where factions are calling to "degrade" IE6) reinforces the
misconception that writing a reliable cross-browser script is
impossible.

It's all a charade. If you twiddle with a script long enough, making
absurd and unfounded inferences along the way, you can make it work in
a handful of browsers (in at least their default configurations).
Notice that the "major" libraries degrade (on paper) all but the
latest versions of the major browsers. The message to all the users
who are stuck with "lesser" browsers is that it is _their_ fault.
It's not a lesser script or lesser programmers or lesser management.
It's lesser browsers (that are mostly 99.9% the same as the next
batch).

Speaking of degrading, what ever happened to doing it gracefully?
That's impossible to do with these libraries. You just have no way to
tell if a method call will work or result in an error (or the myriad
shades of gray in-between). Somehow this deal-breaker has been
overlooked. Once again, the users of "lesser" browsers are left to
flounder in their own "foolishness".

Then there is the idea that a Web page should download huge,
outrageously complicated scripts to perform simple and basic tasks.
Typically they use a tiny percentage of the features provided. QA
testing is involved and expensive, so it is quite foolish to
constantly swap out unnecessarily complex scripts. If the typical
library developers had an ounce of competence between them, the
typical "Ajax site" would never have to upgrade anything.

And if things change and somebody does come up with a general cross-
browser script that makes sense for the majority of Websites, it won't
validate any of the last few years. The Ajax craze has resulted in a
prolonged stagnation, not a movement. I suspect the general malaise
will eventually kill browser scripting. Applications on top of
documents using kiddie scripts that can't even _read documents_ (or do
much of anything) reliably? It's a circus and think the tent will
eventually collapse (taking out a lot of clowns in the process).