Suggesting that frameworks are too complicated because they "add tens of redundant methods, adding complexity for the end user" is ridiculous. The number of methods in something doesn't always add to the complexity - in a lot of cases a framework vastly reduces the difficulty of using something by abstracting away the hard stuff so the user doesn't need to worry about it. That's pretty much the point of a framework. Further though, using an established framework improves things through the "many eyes" principle - if tens of thousands of people have used a piece of code, chances are it's going to be pretty damn bulletproof and it'll have a swathe of documentation backing it up (as official docs, blog posts, StackOverflow questions, etc). No startup can even dream of competing with that.
Specifically in the case of moot.it, perhaps as a thing that's dropped into a website to provide a discussion forum having tight code is a bonus, but if you're writing something for other people to extend then using a well known framework as a starting point is a very, very obvious choice.
> if you're writing something for other people to extend then using a well known framework as a starting point is a very, very obvious choice.
This is precisely why we chose to build on top of Backbone.js. It has huge market saturation and easily understandable principles, but could benefit a lot from some of the killer features of Angular and Ember.
Rarely does a framework do everything you need. In the eventuality that you create another app you'll want a custom platform to build off of. It simply makes sense to base that custom platform on top of something stable and vetted by the community.
I think the 'redundancy' here is more just unnecessary complexity.
Eg, the primary value of Angular is binding DOM -> data. As a developer, I want to specify:
- The template for the DOM
- The data
That's all. I don't care about $scope.$apply, a second module system (even if it's better) or anything else I have to read about.
Ractive.JS (The Guardian's framework) does this. It's just mustache templates you bind to data, and when the data changes, the relevant parts of the DOM do.
The 'how to' fits in a tweet, it's backed by a major media company and the lib is 32 kilobytes.
Ractive.JS doesn't need $scope.$apply because it uses it's own model system. AngularJS doesn't use it's own model system, the model is a plain old JavaScript object. The author of 'Frameworkless JavaScript' criticizes the Ember way of using a "complex model system".
$scope.$apply exist because of limitations in JavaScript. Apparently this will be fixed in ES6, so ES6-version of AngularJS theoretically won't need $scope.$apply.
Ractive.JS's data-binding looks similar to Ember.js, which also has it's own model system to learn (learning complex frameworks was criticized in the article).
Ractive uses POJSOs. Each binding has a POJSO (ie, an Object, nothing magical, no new inheritance system or unrelated class-based OO system) and a template (in mustache format). That's all.
You can make the binding live specifying 'magic: true' which requires ES5 (a reasonable requirement for modern web apps).
The thing is it's better set things manually so the boundary between your DOM data and other parts of the application become clear. There's no chance of mistaking this.set('keypath', data) with something else.
I don't think the model should care about the view. It should be possible to change the model without caring about view, or even knowing if a view exists. A view should be able to use the model, but the model shouldn't care.
It's just data for ractive.js to display on the DOM. There's no assumption on whether this is a Model, a View Model or whatever pattern you adopt for your app.
+1 Damn right. I love Ractive.js. I could train my developers by pointing them to the interactive tutorial and they can pick it up in two hours or so. There's very few concepts to learn.
+1 for ractive. If all one needs is data binding , Ractive is enough. Angular is too complexe and too heavy in my opinion(though i like its expression language).
Specifically in the case of moot.it, perhaps as a thing that's dropped into a website to provide a discussion forum having tight code is a bonus, but if you're writing something for other people to extend then using a well known framework as a starting point is a very, very obvious choice.