4 ms·

Riot does templating, routing and separation of concerns rather beatutifully, I would say. Those are the things most frameworks are build for. What do you see m

Riot does templating, routing and separation of concerns rather beatutifully, I would say. Those are the things most frameworks are build for. What do you see missing? The amount of Todo MVC code in Riot is actually smaller than in Backbone but like I say on the post the focus should not be on the code size but on simplicity – and this is why Riot advocates MVP a lot. Actually Backbone also seems like a MVP framework to me.

ssmoot 13y ago
It seems the Presenter example is pretty broken (unless I'm just stupid). I don't see a `todo` variable defined anywhere, but it's used in several places. Perhaps `var model =` was just missed in a rename? Also, the "toggle all" function uses a `filter` variable that's undefined AFAICT. I'm not trying to knock the framework. I like what I see. Just a little hard to follow along when I'm not sure if the code is wrong, or my understanding of it is.
- sanderjd 13y ago
  I thought the same thing about the `store` variable in the `Todo` object. Not sure what we're missing.
nilliams 13y ago
Okay, here're a few examples. There are probably more: I've used $.bbq plugin for 'basic' routing (similar API to riot). It wasn't enough. I was writing tons of boilerplate and my routing logic was fragmented and hard to follow. Sure, this comes down to lack of convention, but that's as I said, a benefit of frameworks that establish said conventions. I'm also not much of a fan of Backbone's router by the way. Ember's on the other hand, looks bloody fantastic. I've tried every templating language under the sun. The idea of creating portable/pure HTML/logicless templates (whatever you want to call them) so that your 'HTML developer' can work with them is a fool's gold. If your 'HTML developer' is likely to misunderstand or break your HTML because it contains logic in it, they're just as likely to do the same when there are implicit rules in your templates. If anything, explicit template tags, like say an {{#each}} tag makes them far more likely to tread carefully when dealing with them. But in reality I've found this is all a non-existent scenario. The (JS) developer is going to be the one writing the HTML and translating a designer's vision into the web-app code. That developer is likely to need to refactor templates/partials several times over the lifetime of the app. So whether the designer creates their style-guide as HTML & CSS or not, you don't want them working on the actual app's templates. It seems to make way more sense to have them working on static playground version of the app's markup. Collections. Boilerplate. Backbone's Collection and Models are really great and the create/add/save stuff cuts down on a lot of repetitive code. The Underscore functionality you get on Collections are fantastic for opening up your console and exploring your app with powerful things like: App.Models.people.pluck('age'); // spit out ages in array App.Models.people.where({ age: 18 })[0].set('age', 19); // see what happens in your view as a result App.Views.funkyInspector.model.set('active', true).save(); // see what happens in view/xhr as a result... Riot doesn't give me this. Basically you're not doing enough for me!

ssmoot 13y ago

It seems the Presenter example is pretty broken (unless I'm just stupid). I don't see a `todo` variable defined anywhere, but it's used in several places. Perhaps `var model =` was just missed in a rename? Also, the "toggle all" function uses a `filter` variable that's undefined AFAICT. I'm not trying to knock the framework. I like what I see. Just a little hard to follow along when I'm not sure if the code is wrong, or my understanding of it is.

sanderjd 13y ago
I thought the same thing about the `store` variable in the `Todo` object. Not sure what we're missing.

nilliams 13y ago

Okay, here're a few examples. There are probably more: I've used $.bbq plugin for 'basic' routing (similar API to riot). It wasn't enough. I was writing tons of boilerplate and my routing logic was fragmented and hard to follow. Sure, this comes down to lack of convention, but that's as I said, a benefit of frameworks that establish said conventions. I'm also not much of a fan of Backbone's router by the way. Ember's on the other hand, looks bloody fantastic. I've tried every templating language under the sun. The idea of creating portable/pure HTML/logicless templates (whatever you want to call them) so that your 'HTML developer' can work with them is a fool's gold. If your 'HTML developer' is likely to misunderstand or break your HTML because it contains logic in it, they're just as likely to do the same when there are implicit rules in your templates. If anything, explicit template tags, like say an {{#each}} tag makes them far more likely to tread carefully when dealing with them. But in reality I've found this is all a non-existent scenario. The (JS) developer is going to be the one writing the HTML and translating a designer's vision into the web-app code. That developer is likely to need to refactor templates/partials several times over the lifetime of the app. So whether the designer creates their style-guide as HTML & CSS or not, you don't want them working on the actual app's templates. It seems to make way more sense to have them working on static playground version of the app's markup. Collections. Boilerplate. Backbone's Collection and Models are really great and the create/add/save stuff cuts down on a lot of repetitive code. The Underscore functionality you get on Collections are fantastic for opening up your console and exploring your app with powerful things like: App.Models.people.pluck('age'); // spit out ages in array App.Models.people.where({ age: 18 })[0].set('age', 19); // see what happens in your view as a result App.Views.funkyInspector.model.set('active', true).save(); // see what happens in view/xhr as a result... Riot doesn't give me this. Basically you're not doing enough for me!