I've developed my application with Riot's observable library and using the proposed model-view-presenter architecture.
Along the years I've learned about ExtJS, Dojo, Backbone, Knockout, Angular and others. What I like about Riot is that I can actually understand exactly what's going on in my application's architecture without going through so many layers of abstraction and endless lines of code. Its event-oriented nature reminds me of developing for Flex using PureMVC. It results in loose coupling without resorting to magic.
I'm not using Riot's router (I use jQuery Mobile's integrated router instead).
About the template library, it got more useful after including support for object hierarchies, but I've mostly switched to Handlebars to take advantage of its support for collections and conditions. I understand the argument about keeping all presentation logic in JavaScript inside the presenter, but for my application at least, it seems that keeping the view in HTML+DSL results in tighter code.
Of course application requirements vary widely, and I agree that some could benefit for instance of components and two-way data binding. But in my case, simpler is better.
This is how MV* libraries should be built - minimal, very fast, bloat-free, independent of other libraries. VoicePedia was based on Riot.js: http://niutech.github.io/voicepedia/
Along the years I've learned about ExtJS, Dojo, Backbone, Knockout, Angular and others. What I like about Riot is that I can actually understand exactly what's going on in my application's architecture without going through so many layers of abstraction and endless lines of code. Its event-oriented nature reminds me of developing for Flex using PureMVC. It results in loose coupling without resorting to magic.
I'm not using Riot's router (I use jQuery Mobile's integrated router instead).
About the template library, it got more useful after including support for object hierarchies, but I've mostly switched to Handlebars to take advantage of its support for collections and conditions. I understand the argument about keeping all presentation logic in JavaScript inside the presenter, but for my application at least, it seems that keeping the view in HTML+DSL results in tighter code.
Of course application requirements vary widely, and I agree that some could benefit for instance of components and two-way data binding. But in my case, simpler is better.