"The big epiphany for me was when I realized that the server has its own MVC, and the browser has its own MVC."
While I'd still advocate DRY over this POV (unless of course DRY leads you here naturally), I will agree this is a generally valid viewpoint, because you've got the server-client model built in there instead of glossed over. And you are now the first person who has gotten me to be generally agreeable about MVC used in the web world.
Which raises the interesting question of building a framework that builds this idea into the core, with server-side MVC, client-side MVC, and some sort of defined crossover instead of the usual hacky stuff that emerges from single-MVC.
I am doing a simialr thing. Except ASP.NET MVC 4 Web API on the server and Angular.js on the client. It feels very natural and simple to me. What I find odd is Angular.js works very similar to Silverlight, and my whole setup has similarities to Silverlight with RIA services. Yet SL+RIA never felt natural at all and was very difficult. I've not narrowed down where the difference lies.
Angular is very impressive. There are lots of small things that make it nice to use. Among them:
The lexical/nested scoping in the templates is just perfect. I've reviewed the documentation of all competing frameworks, and I couldn't figure how to do it in any of them. Since it was a primary requirement for my app, I went for Angular.
The service-based architecture, and the automatic service injection in controllers, based on parameter names are pretty nice too, as is the fact that you can pass arbitrary parameters to filters.
In a calendar widget that displays a month, I pad the `month` array with days of the surrounding months in order to get complete weeks. I wanted to have these days styled differently. `dayName` and `idem` are custom filters.
<ul id="calendar">
<li ng-repeat="day in month.days"
class="day {{day.day|dayName}} this-month-{{day.month|idem:month.month}}">
<div class="date-number">{{day.date}}</div>
Events go here.
</li>
</ul>
While I'd still advocate DRY over this POV (unless of course DRY leads you here naturally), I will agree this is a generally valid viewpoint, because you've got the server-client model built in there instead of glossed over. And you are now the first person who has gotten me to be generally agreeable about MVC used in the web world.
Which raises the interesting question of building a framework that builds this idea into the core, with server-side MVC, client-side MVC, and some sort of defined crossover instead of the usual hacky stuff that emerges from single-MVC.