[rguzman]

This is really useful and good, esp since the source is on GH. Thanks for putting it together, OP!

That said, lines of code is really the wrong metric to gauge the merits of the frameworks. Fewer lines of code may mean better abstractions, but it also may mean more 'magic'.

A metric that may be more useful would be to have one developer write half the project and have another finish and then compare the time they take to the time they take to do the same project with angular.

[atrk]

I think LOC is actually a great proxy measurement of productivity. 3x the code is 3x the code that can break and 3x the code you have to wade through while debugging or adding features.

I see what you're getting at with "magic" abstractions, but it's like comparing Python and C. I don't know everything that happens under the hood in Python off the top of my head, but I also don't care. I could learn it if I needed to (e.g. needing to use the FFI, or if I find a framework bug). Not knowing is not the same as not being able to know.

[phleet]

The difference here is that in Python vs C, you almost _never_ actually need to know what's going on under the hood[1]. Whereas in every framework I've _ever_ used, I eventually need to dig into the guts of them because of some leaky abstraction. For instance, automatic data bindings are great until you want to do animation[2].

I do agree that LOC for a _non trivial_ application is a reasonable measure, though I disagree that Angular:Backbone is Python:C.

[1]: Serious performance optimization is the exception here, but in building CRUD apps, this honestly did come up infrequently, and usually the right thing to do was to improve algorithmic complexity or fix slow DB queries, not fix python constructs that were unexpectedly slow.

[2]: I haven't spent much time with Angular specifically, but definitely remember this being difficult in other automatically bound frameworks, like Meteor in its initial release.

[ulisesrmzroche]

automatic data bindings for animation are still great though, and its internals should definitely always be hidden from user-land, but I totally agree with you, performance and ease-of-use vary wildly in javascript-land and needs to get better.