It looks like a nice little library to me and I think it would probably be a really reasonable choice for a lot of apps. It stays close to what people are already familiar with (jquery). It handles a pain point in terms of model data change notifications.
I wouldn't take the criticism to heart. The bit about bragging about how fast and small it is will always create friction - especially when another big library is needed to make it useful.
Also the result isn't as expressive as, say, Angular. You say that's a good thing:
"Current data-binding frameworks promote the use of spaghetti on the HTML layer. Suddenly the onclick attribute is back! (I'm looking at you, Angular)."
But you neglect to mention that the tradeoff is all the boilerplate you're going to have to write.
Also, you'll have to pry two-way data binding from my cold dead hands.... :)
Stop claiming that your "framework" allows writing less loc.
There are sooo many useful constructs that all these frameworks provide. I generally abhor Backbone for its "minimalistic" approach. But looks like even jashkenas is taking issue to what you are doing here.
You are saying that / claiming that - me / we are soo damn good that we can do in <1KB what a whole bunch of developers have not been able to do in xKB where x is a larger number.
First, no it does not. The fact that there are fewer letters does not mean that there is less boilerplate. If you want an accurate measure, you need to count up actual lines of boilerplate in the code.
Second, even if it did (again, it does not), it comes at the cost of reduced functionality. You can claim that these are unnecessary features, but, for instance, the entire template is not re-rendered on each change in Angular, only the affected piece. If you think that that's the right way to write apps in riot, then that means that every line in your app dedicated to restricting changes to a part of the view is boilerplate.
That may be true, but Todo MVC is a minuscule "application"! It can be used as a way to compare libraries and frameworks in a very superficial way but when you're writing a large web application with many screens, a lot of state, many widgets, lots of routes, various persistence mechanism, etc.
It doesn't have enough features to require or demonstrate the abstractions needed to eliminate boilerplate.
That being said I like what you did with Riot which is basically use plain JavaScript as much as possible. And I also like to you bring attention to the fact that jQuery doesn't cause spaghetti: programmers cause spaghetti.
I wouldn't take the criticism to heart. The bit about bragging about how fast and small it is will always create friction - especially when another big library is needed to make it useful.
Also the result isn't as expressive as, say, Angular. You say that's a good thing:
"Current data-binding frameworks promote the use of spaghetti on the HTML layer. Suddenly the onclick attribute is back! (I'm looking at you, Angular)."
But you neglect to mention that the tradeoff is all the boilerplate you're going to have to write.
Also, you'll have to pry two-way data binding from my cold dead hands.... :)