You can actually sue them if they do call you after you tell them not to for $1200 per violation. Is also illegal for them to call mobile phones. This technology actually cropped up because collection agencies are getting backlash from using robo dialers. I'd argue collection agencies are much more regulated than telemarketers. Google the FDCPA law.
On the contrary, I find that people stuff too much on the model because of rails. I've found that I much prefer very simple models to describe very fine grained parts of the data and use the controller for much of the tying of things together. You kinda of treat models as 'data components' if you will, mixing and matching them where needed in the view
That's the "Massive ViewController" anti-pattern (or just massive controller, if you're not in Apple land).
Classic MVC is really MVc, with controllers only handling a small set of interactions that are not directly between the Model and View, for example dialog boxes and such.
One problem with a "Big-C" approach to MVC is that whereas models and views are at least potentially reusable, the controllers are dependent on both M and V, and thus both proliferate and are not reusable.
This may be a bit off topic but I've found sqlite to be quite a powerful csv parser. Once posted you can manipulate the data in lots of ways. When you're working with reports that need to get back into some sort of table format, it's very intuitive and easy for SQL people.
As a React user, I'd be really curious to see what these benchmarks look like when you're dealing with larger, more complex projects. I was under the impression that React scales well when dealing with lots of nested components and diffing the updates for each.
It "scales well" because of shouldComponentUpdate. That lets you avoid building huge chunks of virtual DOM as your app becomes very large.
The trick is that the same exact optimization is available in Elm and Angular 2 (with different names) so the same argument applies there as well.
The "Do these results generalize?" section makes an argument as to why the numbers you see on a simple TodoMVC app should generalize to apps of any size. When everyone has the equivalent of shouldComponentUpdate, the question becomes: when you finally DO need an update, how fast is it? That can be measured in small apps.
