>Well you didn't disprove my assertion (I was obviously talking about front end frameworks) by citing a front end framework that came with an extensive testing framework. So why on earth are you saying something without backing it with facts?
Let me help settle which of you two is the liar then.
Ember comes with tooling for unit-tests and so does Qooxdoo (which also includes Selinium support out of the box).
And that's just two of three i'm familiar with.
>No the problem is that Javascript doesn't have pointer variables
There you go: pass-by-reference semantics (i.e. pointer variable)
var flow = function( init ){
return function( v ){
if( v !== undefined ) init = v;
return init;
}
}
> It has nothing to do with angular but everything to do with the way Javascript works.
No, it has to do with the ad-hoc programming language shoehorned into dom-nodes. Javascript has lexical scoping, Angular does not, because its control-flow lives in your dom. It also doesn't have encapsulation or proper step-debugging this way. But none of that has anything to do with Javascript. If all that logic lived in a .js file lexical scoping would be possible and recommended.
Let me help settle which of you two is the liar then.
Ember comes with tooling for unit-tests and so does Qooxdoo (which also includes Selinium support out of the box). And that's just two of three i'm familiar with.
>No the problem is that Javascript doesn't have pointer variables
There you go: pass-by-reference semantics (i.e. pointer variable)
> It has nothing to do with angular but everything to do with the way Javascript works.No, it has to do with the ad-hoc programming language shoehorned into dom-nodes. Javascript has lexical scoping, Angular does not, because its control-flow lives in your dom. It also doesn't have encapsulation or proper step-debugging this way. But none of that has anything to do with Javascript. If all that logic lived in a .js file lexical scoping would be possible and recommended.