>>8517I really don't like Javascript's prototype inheritance system... so I don't use it.
function MyFunc( arg0, arg1 ){
var self = this; // because "this" is like kicking dead whales down the beach in JS.
self.inheritFrom = OtherFunc;
self.inheritFrom();
self.memberVar = 42;
function privateFunc(){
/*...*/
}
self.memberFunc = function(){ /*...*/ };
}
A faux "subclass" can assign a "parent's" inheritFrom property to itself then calls it as the parent constructor which creates the other features.
Interestingly, this isn't only faster to type in my benchmarks this style can be faster since the interpretor will find the property on the function without having to walk up to the prototype to get a reference.
The way "this" works in JS is nutty, IMO. It seems to be at odds with how closures work in that if you take a function property from one object/function and assign it to another then the "this" in that function becomes the object it's assigned to when called. The "self" pattern above allows one to reference the original instantiating object (like a "this" that obeys closure scoping).
Also, vid related.
Nowadays I use JS very little, to interface with the DOM / audio / graphics systems and do all my browser side coding in ASM.js. It's much faster has no GC bullsoykaf (which one rarely needs anyway since event driven execution lends itself to procedural or functional programming models). I'm so glad that all the browser vendors are on board with Web Assembly, which will FINALLY give us a low level bytecode and allow us to not be chained to the bullsoykaf JS language -- Or, more correctly: We can already compile other languages down to Asm.js/Web Asm (which Firefox turns into [mostly] machine code). However we still have to make calls out of the ASM.js to interact with browser features. Web Assembly will eventually allow us to bind directly to those features and remove JS from the loop altogether. That means we'll be able to write code in any language and not need to screw with trans-language calling semantics or other such inefficiencies.
Who cares if JS is "Lisp in C's clothing" (the worst of both worlds) when you can just use Lisp or C itself right in the browser instead?
Unfortunately Sun dropped the ball with Java which was going to be the web application language with Applets. Javascript was just to do light weight glue between the DOM and Applets, hence the name. If Sun had made Applets a lean mean browser embedded VM rather than drag a full featured everything-and-the-kitchen-sink API into the web (along with the huge attack surface and load time that represents) -- If they had made Applets like J2ME -- Then we'd ALREADY have a bytecode language for the web with JIT compliation, etc.
Par for the course with moronic web crap, we'll get the feature smart people know we need eventually but we'll go about it so backasswards that it'll be chock full of complexity (and vulns) rather than designing things correctly from the outset.
Not that I like Java as a language either or their stack based VM (register based VMs are superior since they better match the hardware); However, I can compile C or Lisp or C++ or any other language down into JVM or Web Assembly or Perl Parrot bytecode. Having a choice beats the pants off of "we use JS not because it's good, but because it's there".
I'm already doing next to none of my webdev in JS, and JS's role will only diminish in the future. Hurray!
