Riot.js – A 1kb client-side MVP framework(moot.it)
moot.it
Riot.js – A 1kb client-side MVP framework
https://moot.it/blog/technology/riotjs-the-1kb-mvp-framework.html
37 comments
You say that like it's a bad thing. I like the idea that riot.js is small enough that it 'outsources' it's meaty functions to jQuery (a library you most likely have in your project already). It means fewer bugs and less work for you! More time to enjoy life. There are tons of very smart developers working on jQuery,why replicate their work on riot.js?
If your project doesn't use jQuery feel free to use the right tool for the right job - I can't remember the last time I worked on a web project that didn't have jQuery.
If your project doesn't use jQuery feel free to use the right tool for the right job - I can't remember the last time I worked on a web project that didn't have jQuery.
I'm pretty sure Jeremy was not criticising the jQuery dependency, since his framework (Backbone) also depends on it. He is just stating that there's nothing actually in riot.js, it just proxies to jQuery.
The project might as well just be a blog post with what I'd consider the only useful and non-hyperbolic aspect which was:
> What people refer to as spaghetti is in fact a mixture of model and view code. To avoid it, simply separate your model code from the view with observables.
Fine. I agree that people shouldn't falsely miscredit jQuery for causing spaghetti code and understanding basic separation is valuable. Unfortunately the following line is one of hyperbole:
> You don't need a framework for that.
Which I have a problem with for 2 reasons:
1. That is not all frameworks do. They also reduce the amount of boilerplate, repetitive code you have to write. Riot.js does not appear to do so (significantly). Look at the amount of code in the TodoMVC example's model [1]. That would be dramatically less code when using Backbone.
2. Nobody needs a framework. But frameworks establish conventions and conventions are very valuable for collaboration as well as general discussion of patterns and ideas.
And as for:
> Current frameworks persuade false beliefs with shiny websites and finely crafted marketing without transparent, scientific analysis. They solve hypothetical problems and cause new problems instead. Unfortunately, large communities are dealing with irrelevant issues.
Seriously? I want to swear and throw things, and I'm not even a framework author.
[1] https://github.com/moot/riotjs/blob/master/todomvc/dist/todo...
The project might as well just be a blog post with what I'd consider the only useful and non-hyperbolic aspect which was:
> What people refer to as spaghetti is in fact a mixture of model and view code. To avoid it, simply separate your model code from the view with observables.
Fine. I agree that people shouldn't falsely miscredit jQuery for causing spaghetti code and understanding basic separation is valuable. Unfortunately the following line is one of hyperbole:
> You don't need a framework for that.
Which I have a problem with for 2 reasons:
1. That is not all frameworks do. They also reduce the amount of boilerplate, repetitive code you have to write. Riot.js does not appear to do so (significantly). Look at the amount of code in the TodoMVC example's model [1]. That would be dramatically less code when using Backbone.
2. Nobody needs a framework. But frameworks establish conventions and conventions are very valuable for collaboration as well as general discussion of patterns and ideas.
And as for:
> Current frameworks persuade false beliefs with shiny websites and finely crafted marketing without transparent, scientific analysis. They solve hypothetical problems and cause new problems instead. Unfortunately, large communities are dealing with irrelevant issues.
Seriously? I want to swear and throw things, and I'm not even a framework author.
[1] https://github.com/moot/riotjs/blob/master/todomvc/dist/todo...
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.
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.
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.
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.
I thought the same thing about the `store` variable in the `Todo` object. Not sure what we're missing.
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:
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...
> Current frameworks persuade false beliefs with shiny websites and finely crafted marketing without transparent, scientific analysis.
It is all marketing. Notice how shiny Angular/Ember's site is? Open source mindshare is not determined by technical superiority! There is plenty of marketing, hype, and fashion that controls it.
Big paintbrush here, but many devs don't seem to care a lick about how composable things are. They just want to learn someone's 'opinionated' API, and then bet their entire design on it. They'd rather dig through error messages, and obscure edge cases instead of learning how to structure their code so they don't need to rely on frameworks for everything. When faced with a new platform, they'll jump into whatever everyone else is using at the time, rather than starting with the core tech and building up until they hit a need.
Frameworks are great for MVPs, though.
It is all marketing. Notice how shiny Angular/Ember's site is? Open source mindshare is not determined by technical superiority! There is plenty of marketing, hype, and fashion that controls it.
Big paintbrush here, but many devs don't seem to care a lick about how composable things are. They just want to learn someone's 'opinionated' API, and then bet their entire design on it. They'd rather dig through error messages, and obscure edge cases instead of learning how to structure their code so they don't need to rely on frameworks for everything. When faced with a new platform, they'll jump into whatever everyone else is using at the time, rather than starting with the core tech and building up until they hit a need.
Frameworks are great for MVPs, though.
> It is all marketing. Notice how shiny Angular/Ember's site is?
You realise how absurd it is to say that just because a project has a nice website it is all marketing? I genuinely thought you were being sarcastic and agreeing with me before your next sentence!
> Open source mindshare is not determined by technical superiority! There is plenty of marketing, hype, and fashion that controls it.
There's a degree of hype around anything that requires publicity to bring it to people's attention, but that doesn't justify trashing valuable projects with lazy generalisations. I have watched dozens of Angular and Ember talks and demos by this point and have never once thought "wow this is a load of hype and fashion, nothing to see here". Listen to Yehuda and Tom from Ember being interviewed and tell me those aren't guys that genuinely want to make app development better.
> Big paintbrush here...
No kidding! I'm not aware of any devs that intentionally wish to make their lives a misery in the way you suggest.
You realise how absurd it is to say that just because a project has a nice website it is all marketing? I genuinely thought you were being sarcastic and agreeing with me before your next sentence!
> Open source mindshare is not determined by technical superiority! There is plenty of marketing, hype, and fashion that controls it.
There's a degree of hype around anything that requires publicity to bring it to people's attention, but that doesn't justify trashing valuable projects with lazy generalisations. I have watched dozens of Angular and Ember talks and demos by this point and have never once thought "wow this is a load of hype and fashion, nothing to see here". Listen to Yehuda and Tom from Ember being interviewed and tell me those aren't guys that genuinely want to make app development better.
> Big paintbrush here...
No kidding! I'm not aware of any devs that intentionally wish to make their lives a misery in the way you suggest.
Sorry! I'm not trashing these projects at all. They're very impressive. (Aside: I don't think it's healthy to be as invested as you are in random Internet comments.)
But, as you said, there is hype/publicity with OSS. I wanted to emphasize that is not a pure meritocracy, even within OSS. If people aren't ready for your project, then it won't be adopted, regardless of how good it is. It is very similar to consumer technology.
Regarding composability: what are your thoughts on communities (like Clojure's) that consciously reject the notion of One True Framework?
But, as you said, there is hype/publicity with OSS. I wanted to emphasize that is not a pure meritocracy, even within OSS. If people aren't ready for your project, then it won't be adopted, regardless of how good it is. It is very similar to consumer technology.
Regarding composability: what are your thoughts on communities (like Clojure's) that consciously reject the notion of One True Framework?
> Aside: I don't think it's healthy to be as invested as you are in random Internet comments.
Probably :) Of course though, I do think we should all be aware there are people on the receiving end of these comments we casually fire at frameworks that have worked crazy hard on those projects. (Listen to this episode of The Changelog with the maintainer of Capistrano if you want to hear some evidence of the effects of this [1]). Vague, dismissive comments can sometimes be the hardest to hear.
And yeah, I suppose sweeping generalisations are a massive bugbear of mine. At my previous job whenever I heard one heading my way I knew I was usually in for a ton of work to correct them so that we could _just do sensible work_. I think I have PTSD from that experience. :)
I physically shudder when I hear the word 'bloat', for instance. (It's usually followed by some amount of ignorant tosh from someone who hasn't learned what that 'bloat' is there for).
[1] http://thechangelog.com/110/
Probably :) Of course though, I do think we should all be aware there are people on the receiving end of these comments we casually fire at frameworks that have worked crazy hard on those projects. (Listen to this episode of The Changelog with the maintainer of Capistrano if you want to hear some evidence of the effects of this [1]). Vague, dismissive comments can sometimes be the hardest to hear.
And yeah, I suppose sweeping generalisations are a massive bugbear of mine. At my previous job whenever I heard one heading my way I knew I was usually in for a ton of work to correct them so that we could _just do sensible work_. I think I have PTSD from that experience. :)
I physically shudder when I hear the word 'bloat', for instance. (It's usually followed by some amount of ignorant tosh from someone who hasn't learned what that 'bloat' is there for).
[1] http://thechangelog.com/110/
I hear you.
I think I'm discussing the celebrity culture around these frameworks more than the frameworks themselves. I don't have a problem with them technically, they're a bit beyond what I could make. But I don't want to see classical notions of program design phased out in favor of "just use X." The ideas of what makes software malleable, pleasant to maintain, and grow are quite old.
I think I'm discussing the celebrity culture around these frameworks more than the frameworks themselves. I don't have a problem with them technically, they're a bit beyond what I could make. But I don't want to see classical notions of program design phased out in favor of "just use X." The ideas of what makes software malleable, pleasant to maintain, and grow are quite old.
Agreed.
The component.io ecosystem encourages using only functionality that you actually need instead of bundling a heavyweight library like _ or $.
It would be great to use a small component (like riot.js say) with other nimble components.
It would be great to use a small component (like riot.js say) with other nimble components.
Well, it would be more than a little difficult since riot does nothing without the support of jQuery.
And, you know, the reason it's < 1k is that it doesn't really seem to do anything jQuery can't do with about the same amount of boilerplate.
And, you know, the reason it's < 1k is that it doesn't really seem to do anything jQuery can't do with about the same amount of boilerplate.
plain jQuery is harder to maintain and scale hence why the javascript frameworks were built in the first place
Wrong. Frameworks were build to add structure to the application by taking advantage of the MVC or MVP pattern. By having all the view/model/presenter code stuffed together is the problem and is definitely hard to maintain.
how would you build a web component in riot.js? I would compare the complexity to an angular directive or ember web component. How could riot.js help me structure a phonegap/cordova app in which adding a library like jquery isn't necessary with tools like AngularJS that doesnt depend on it?
Since I was used as proof of the effectiveness of "puffery", I went to find out what that English word means: "promotional statements and claims that express subjective rather than objective views, which no 'reasonable person' would take literally".
Well, I don't claim to take all my decisions based on pure reasoning. Intuition has a lot to do with my technology choices, because it's built on all my prior experiences and knowledge. I've learned that often keeping it simple is a good thing. There´s a tendency to over-architect and over-abstract, and the cognitive overload of the full stack, end-to-end, is significant.
For front-end JavaScript applications, I've been favorable to AngularJS and Knockout. I've looked into Backbone but it promotes a style of programming I'm done with and I want to have no relation to ever again, so I wouldn't consider Backbone an alternative either way.
So I don't feel diminished or discouraged by negative remarks to say that I'll try Riot's style in the next small app I'll build. It's targeted at mobile, it already depends on jQuery, and I was worried to add another large (for 3G) dependency to it.
Well, I don't claim to take all my decisions based on pure reasoning. Intuition has a lot to do with my technology choices, because it's built on all my prior experiences and knowledge. I've learned that often keeping it simple is a good thing. There´s a tendency to over-architect and over-abstract, and the cognitive overload of the full stack, end-to-end, is significant.
For front-end JavaScript applications, I've been favorable to AngularJS and Knockout. I've looked into Backbone but it promotes a style of programming I'm done with and I want to have no relation to ever again, so I wouldn't consider Backbone an alternative either way.
So I don't feel diminished or discouraged by negative remarks to say that I'll try Riot's style in the next small app I'll build. It's targeted at mobile, it already depends on jQuery, and I was worried to add another large (for 3G) dependency to it.
And sadly, with great pain, I rest my case.
---
But hey, if you want to try out a hot new framework that Fits in A Tweet™, I've got something special for you.
Announcing Revolution.js
It's a mere fraction the size of Riot.js, and provides over 100 times the functionality. Despite the unbelievable size, all the building blocks are there: a template engine, router, event library and a strict MVP pattern to keep things organized.
Revolution.js is simpler and faster — in fact, on a completely different scale. In fact, it's so small and so fast that I can share it with you right here:
At this point you might ask — "Hey, wait a minute, what's the deal? Isn't that just wrapping jQuery, and adding nothing?". To which I would answer, yes, exactly.
This is a Revolution against the status quo! Revolution is a manifesto for vanilla JavaScript and jQuery.
---
But hey, if you want to try out a hot new framework that Fits in A Tweet™, I've got something special for you.
Announcing Revolution.js
It's a mere fraction the size of Riot.js, and provides over 100 times the functionality. Despite the unbelievable size, all the building blocks are there: a template engine, router, event library and a strict MVP pattern to keep things organized.
Revolution.js is simpler and faster — in fact, on a completely different scale. In fact, it's so small and so fast that I can share it with you right here:
function Revolution() {
var a = arguments;
return jQuery[a[0]].apply(jQuery, a.slice(1));
}
At this point you might ask — "Hey, wait a minute, what's the deal? Isn't that just wrapping jQuery, and adding nothing?". To which I would answer, yes, exactly.
This is a Revolution against the status quo! Revolution is a manifesto for vanilla JavaScript and jQuery.
Issue #1:
Arguments object has no method `slice`.
Steps to repro:
Invoke the constructor.
I'll send a PR as soon as this makes it to Github.
--------
In all seriousness though, I completely agree with you.
Arguments object has no method `slice`.
Steps to repro:
Invoke the constructor.
I'll send a PR as soon as this makes it to Github.
--------
In all seriousness though, I completely agree with you.
The revolution will be open sourced. https://github.com/ChrisAntaki/revolution
I seriously thought you could do better than this. I was expecting trolly responses from other framework communities but not from Backbone. I prefer reasoning and proper conversation instead of this hate speech that the framework communities are all over. I was hoping you were closer to a scientist.
So far no reasonable arguments why Backbone is better. Is it just larger, slower and less effective? I was expecting you to argue against those points that are now clearly visible to everyone.
So far no reasonable arguments why Backbone is better. Is it just larger, slower and less effective? I was expecting you to argue against those points that are now clearly visible to everyone.
This looks like hate speech:
> Current frameworks persuade false beliefs with shiny websites and finely crafted marketing without transparent, scientific analysis. They solve hypothetical problems and cause new problems instead. Unfortunately, large communities are dealing with irrelevant issues.
You're telling jashkenas (indirectly) that he "persuade false beliefs", "without scientific analysis", that he's solving "hypothetical problems" and "dealing with irrelevant issues" and plenty of other things like that... and what response do you expect from him?
> I was hoping you were closer to a scientist.
You already told him he's not a scientist, see above.
P.S.: I don't follow any "religion". I use framework or plain JavaScript depending on the project, and I find it sad when anyone promotes their solution as the only good one.
> Current frameworks persuade false beliefs with shiny websites and finely crafted marketing without transparent, scientific analysis. They solve hypothetical problems and cause new problems instead. Unfortunately, large communities are dealing with irrelevant issues.
You're telling jashkenas (indirectly) that he "persuade false beliefs", "without scientific analysis", that he's solving "hypothetical problems" and "dealing with irrelevant issues" and plenty of other things like that... and what response do you expect from him?
> I was hoping you were closer to a scientist.
You already told him he's not a scientist, see above.
P.S.: I don't follow any "religion". I use framework or plain JavaScript depending on the project, and I find it sad when anyone promotes their solution as the only good one.
It's not hate speech.
The blog entry states that you can implement the Todo MVC app with 1kb of extra code on top of jQuery and the end result is smaller, modular and faster. This is big news.
The statements on the post are indeed bold but I think they are still valid. They should deserve a better response IMHO. This seriously questions the relevance of current client-side frameworks.
Without constructive criticism should we just agree that others are bigger, slower and less productive ??
The blog entry states that you can implement the Todo MVC app with 1kb of extra code on top of jQuery and the end result is smaller, modular and faster. This is big news.
The statements on the post are indeed bold but I think they are still valid. They should deserve a better response IMHO. This seriously questions the relevance of current client-side frameworks.
Without constructive criticism should we just agree that others are bigger, slower and less productive ??
- 1kb + jQuery is bigger (or almost the same size) as the other ones without jQuery (except Ember.js).
- Comparing template engines only (with the riot solution having less features) doesn't give a complete picture for comparing speed. There are dozen of other parts to make a web app. The template is only a small part. Benchmarks aren't even a good way to compare speed. It's how the user feels when using the resulting app and interacting with the UI that matters.
- TodoMVC is a very small app for comparing productivity. E.g. your router implementation doesn't take into account IE bugs, and researching such bugs instead of using a proven solution can be less productive.
I agree with you that modular and maintainable web apps can be developed with jQuery only, and even plain JavaScript only. I dislike, as much as you do, "Backbone developers", "AngularJS developers", "Ember.js developers", etc. who can use only one framework, can't properly structure an app without using a framework, and claim that the framework they use is the only good one to solve any problems and build any type of app.
A good developer should be able to choose the proper solution for a particular problem. There's no one size fits all solution for every problem.
- Comparing template engines only (with the riot solution having less features) doesn't give a complete picture for comparing speed. There are dozen of other parts to make a web app. The template is only a small part. Benchmarks aren't even a good way to compare speed. It's how the user feels when using the resulting app and interacting with the UI that matters.
- TodoMVC is a very small app for comparing productivity. E.g. your router implementation doesn't take into account IE bugs, and researching such bugs instead of using a proven solution can be less productive.
I agree with you that modular and maintainable web apps can be developed with jQuery only, and even plain JavaScript only. I dislike, as much as you do, "Backbone developers", "AngularJS developers", "Ember.js developers", etc. who can use only one framework, can't properly structure an app without using a framework, and claim that the framework they use is the only good one to solve any problems and build any type of app.
A good developer should be able to choose the proper solution for a particular problem. There's no one size fits all solution for every problem.
[deleted]
As the author of Backbone I can understand your rage. I think that instead of bashing Riot you should focus on reasoning the existence of Backbone instead. Riot is clearly not just a jQuery and people can realize that.
Riot is just jQuery though. The riot's own source code is literally useless. I agree with the ideas that you can structure your application without frameworks like backbone though
From the repo: "Riot is a manifesto for vanilla JavaScript and jQuery."
I think that's really the point. Rejecting the idea of these big frameworks and promoting vanilla JS.. Rejecting the myth that without big frameworks your code is unmanageable.
I think that's really the point. Rejecting the idea of these big frameworks and promoting vanilla JS.. Rejecting the myth that without big frameworks your code is unmanageable.
[deleted]
[deleted]
Genius!
Nice one Jeremy :D
[deleted]
> There's almost literally nothing here
I think that's the point.
I think that's the point.
Actually, while I was reading Riot's home page, I was wondering if it was some kind of joke...
EDIT: ok, now I understand. It is a joke, because all this long article boils down to just one sentence, repeated throughout the article itself: "You don't need a framework for that."
EDIT: ok, now I understand. It is a joke, because all this long article boils down to just one sentence, repeated throughout the article itself: "You don't need a framework for that."
> (And if this is all an elaborate joke, then I'm an ass for falling for it ;) But that's not the sense I get.)
Actually I think it is a joke. Kind of. It's an elaborate argument for a philosophy (basically: eschew frameworks, use jQuery for DOM and events, manage your own MVP structure).
They go on to say "You don't need a framework" (repeatedly), and "Riot is a manifesto for vanilla JavaScript and jQuery".
I see it as a functioning demo to present an opinion about how apps should be written. Viewed like this, the whole "world's fastest framework" thing seems tongue-in-cheek. Their use of the familiar "Unveiling a new framework" device is a conceit to push a philosophy. It's allegorical.
I admit that starting off with silly benchmarks undermines the point a lot :)
Actually I think it is a joke. Kind of. It's an elaborate argument for a philosophy (basically: eschew frameworks, use jQuery for DOM and events, manage your own MVP structure).
They go on to say "You don't need a framework" (repeatedly), and "Riot is a manifesto for vanilla JavaScript and jQuery".
I see it as a functioning demo to present an opinion about how apps should be written. Viewed like this, the whole "world's fastest framework" thing seems tongue-in-cheek. Their use of the familiar "Unveiling a new framework" device is a conceit to push a philosophy. It's allegorical.
I admit that starting off with silly benchmarks undermines the point a lot :)
Just to clarify... Obviously it's not a pure allegory; there is an actual JS library being offered here. But I think the author intends it more as a reference implementation of some boilerplate to get you started with his DIY philosophy. I do think he's taken it too far by directly benchmarking it against frameworks, which are conceptually different things. It's all a bit mixed up, and this has caused a hypey and flamey conversation. But get past all that, and it does make an interesting point – that you can (surprisingly easily) achieve several things that we normally associate with frameworks, without a framework.
Thanks for the feedback. Maybe I can use some of that on my next update. These implementation details and issues are rather easy to address.
I would not write my own event library from scratch if I can take advantage of jQuery. Can you elaborate what's wrong with proxying?
I would not write my own event library from scratch if I can take advantage of jQuery. Can you elaborate what's wrong with proxying?
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.... :)
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.... :)
Riot has less boilerplate than Angular on the Todo MVC implementation.
This is utter BS.
Riot's TodoMVC - 59 LOC html, 185 LOC js.
Angulars TodoMVC - 70 LOC html , 145 LOC js. ( I DINT even discount the extra lines used for comments and stuff - which angulars has quite a lot of ! ) . https://github.com/tastejs/todomvc/tree/gh-pages/architectur...
The other implementation is 71 html and 162 js. https://github.com/tastejs/todomvc/tree/gh-pages/architectur...
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.
Riot's TodoMVC - 59 LOC html, 185 LOC js.
Angulars TodoMVC - 70 LOC html , 145 LOC js. ( I DINT even discount the extra lines used for comments and stuff - which angulars has quite a lot of ! ) . https://github.com/tastejs/todomvc/tree/gh-pages/architectur...
The other implementation is 71 html and 162 js. https://github.com/tastejs/todomvc/tree/gh-pages/architectur...
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.
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.
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.
Most of the complexity in UI projects is in the Presenter (aka backbone view). Not the model or template, which are much more easier probles to tackle - but its the Presenter where all the complexity lies. e.g. parent/child aggregations, one presenter calling another presenter's functions (like re-render, etc), custom teardown behavior, and so on...
I totally appreciate this effort. But if I were to try the same thing, instead of creating a Model structure (which could easily be handled with plain JQuery itself), I'd put more thought on the Presenter.
But hey, I didn't, and this guy did, so much appreciated indeed. This is certainly an inspiration, time for everyone to think "What does your project need?" vs "What does the framework provide?".
I totally appreciate this effort. But if I were to try the same thing, instead of creating a Model structure (which could easily be handled with plain JQuery itself), I'd put more thought on the Presenter.
But hey, I didn't, and this guy did, so much appreciated indeed. This is certainly an inspiration, time for everyone to think "What does your project need?" vs "What does the framework provide?".
Well, you are doing exactly that -- correcting the positioning of an open source project. However I would like to point out that statement "beautiful demonstration of marketing" in a strict subset of English language would evaluate to False, if I am allowed to make such comparisons.
Marketing is so much more than just positioning of a brand. Big promises of Riot.js is exactly that -- positioning. And positioning is identifying and attempting to occupy a market niche for a brand.
Marketing hate is a pet peeve of mine and a reason for my ramblings on this topic.
Marketing is so much more than just positioning of a brand. Big promises of Riot.js is exactly that -- positioning. And positioning is identifying and attempting to occupy a market niche for a brand.
Marketing hate is a pet peeve of mine and a reason for my ramblings on this topic.
[deleted]
I'm sure people study the source code of the frameworks a lot these days. Most of the things are related to structuring code in an understandable way. MVC and MVC are design patterns and do not necessarily need a framework.
MVC is not a design pattern or an architecture. It's just a way of organizing code. Inside the individual implementations of the model, view and control you may have varying design patterns, which is why we have so many different MVC frameworks/implementations.
Another quick note: what you're calling a View in riot.js is actually a Template and your Presenter is probably more of a View than a Presenter.
Another quick note: what you're calling a View in riot.js is actually a Template and your Presenter is probably more of a View than a Presenter.
DOM/HTML represents the "passive view": http://martinfowler.com/eaaDev/PassiveScreen.html in MVP and the Presenter layer makes all the manipulation of the view & widgets.
This is almost identical to Backbone which can also be interpreted as MVP, see:
http://lostechies.com/derickbailey/2011/12/23/backbone-js-is...
This is almost identical to Backbone which can also be interpreted as MVP, see:
http://lostechies.com/derickbailey/2011/12/23/backbone-js-is...
I would not call this a framework but a jQuery plugin with a hip name
> There's almost literally nothing here
True. There's 0.85kb + license.
True. There's 0.85kb + license.
This*1000.
There isn't very much to see here, if anything. A few meaningless microbenchmarks, and some "plain old JavaScript objects" that hijack jQuery's event subsystem so they can emit events just like DOM elements. We've been doing imperative, evented programming in the browser for years now.
Even if you're inclined to argue that this style of programming doesn't lead to a giant mess (and I'm inclined to believe that it does, even if you are the most disciplined of programmers) I still don't see the benefit of adding this 1K of JavaScript to my page at all. I can duplicate $.observable with a vanilla jQuery object.
To call this the "most powerful client side framework for building large scale web applications" is downright laughable.
Even if you're inclined to argue that this style of programming doesn't lead to a giant mess (and I'm inclined to believe that it does, even if you are the most disciplined of programmers) I still don't see the benefit of adding this 1K of JavaScript to my page at all. I can duplicate $.observable with a vanilla jQuery object.
To call this the "most powerful client side framework for building large scale web applications" is downright laughable.
This isn't just 'imperative, evented programming' though. It gives a clear answer on how to separate your code into concerns, although I agree that there isn't much forcing you to follow good practices.
The problem with the typical 'jquery-type' programming was that apps were essentially an ad-hoc collection of (sometimes massive) event handlers. I think the problem boiled down to:
* there wasn't much experience and consensus on how to organise javascript code (split it into module etc.)
* the DOM is global, meaning you can register event handlers to anything from anywhere (To make matters worse events bubble up and down the DOM tree)!
It seems like people immediately resorted to extremes to solve these issue - basically trying to abstract away the DOM and even javascript completely - whereas the solution could be something much simpler and subtler.
The problem with the typical 'jquery-type' programming was that apps were essentially an ad-hoc collection of (sometimes massive) event handlers. I think the problem boiled down to:
* there wasn't much experience and consensus on how to organise javascript code (split it into module etc.)
* the DOM is global, meaning you can register event handlers to anything from anywhere (To make matters worse events bubble up and down the DOM tree)!
It seems like people immediately resorted to extremes to solve these issue - basically trying to abstract away the DOM and even javascript completely - whereas the solution could be something much simpler and subtler.
The current crop of frameworks do feel like they're trying to abstract away the browser a little bit. They have the feel of something like JSF1 (java), they get the job done but the abstraction is so thick that it's difficult to integrate things like jquery without jumping through a few hoops. A lighter framework that achieves the same things without all the fuss would be very welcome. The danger is that the abstraction is too thin and you end up writing half a framework yourself to plug the gaps but maybe riotjs has managed to get closer to the sweet spot.
I apologize if I'm missing something, I'm not a data visualization expert, but what the heck is going on with that graph? http://content.screencast.com/users/sequoia.m/folders/Jing/m...
I think the size of the bar is actually ms/x so because Riot.js does more x's in the same period of time, the bar is shorter.
The bars are relative to data in it's own category (eg. 200x), you're comparing apples to oranges.
mmm. Well there's no scale & no explanation of this method so it's not really clear what's going on. I get what is meant now, but there really should be a scale here to make it clear or at least an explanation.
Thanks for the short way of explaining how it works. Will add this exact clarification on the site.
I think it's rather disingenuous to call this a "1 kb" framework when it depends on jQuery (83,612 bytes as of 2.0.3). I don't know about the other frameworks, but the current stable version of angular is 81,447 bytes and does not depend on jQuery, and is significantly more expressive.
I really love the minimal approach and a lot of it echoes my experience as well.
One thing that I would love to see (mostly because I haven't found good solutions for it myself) is how CSS fits into the whole thing. The way I see it, CSS touches several aspects in the MVP pattern. There is the view part, which is strictly how things look on the screen but there is also the presenter part, which includes thing like, 'now show this thing', 'animate this, and when it is done, do this'.
I love the refreshingly minimal approach, although jQuery dependency ruins some of the excitement, but still, great work guys!
Thanks. jQuery dependency is intentional since the library promotes the use of jQuery on the presenter layer.
I really like this outlook.
Most developers don't bother about the presentation layer and they think that jQuery is a pain but most front-end designer and developers rely on it.
Great step.
Most developers don't bother about the presentation layer and they think that jQuery is a pain but most front-end designer and developers rely on it.
Great step.
This looks really pretty good. I think I would miss things like ng-each, but I guess not that's not -too- hard to re-implement using $.data('each'). Maybe.
I will consider using this for a site I'm building right now, see what happens.
[Retracted.]
... but, if you're going to test Underscore templates for speed, you need to use the `variable` setting to avoid the `with` block.
... but, if you're going to test Underscore templates for speed, you need to use the `variable` setting to avoid the `with` block.
The actual loop with 200, 500, 2000 and 5000 iterations is here:
https://github.com/moot/riotjs/blob/master/compare/speed/ind...
The $.each has only 4 iterations and has no effect on the stats.
https://github.com/moot/riotjs/blob/master/compare/speed/ind...
The $.each has only 4 iterations and has no effect on the stats.
I used the `variable` setting but it was actually slower. I used it as you teach on the website:
_.template("Using 'with': <%= data.answer %>", {answer: 'no'}, {variable: 'data'});
I could do this with pre- compilation. Possible?
_.template("Using 'with': <%= data.answer %>", {answer: 'no'}, {variable: 'data'});
I could do this with pre- compilation. Possible?
I don't think that's fair since a templating engine could easily avoid the actual with statement but provide same convenience. Optimization should be done in the implementation (which is fully possible here) and not at the cost of API ergonomics.
> a templating engine could easily avoid the actual with
> statement but provide same convenience
If you've got a patch that is able to do otherwise, I'd love to see it ;)
I wasn't aware that the benchmark comparison was about micro-templating, it includes libraries like handlebars.
I am sure you realize you can just walk the AST for what identifiers are being used in the template code and forward declare them in the generated code so that reference errors are not caused.
I am sure you realize you can just walk the AST for what identifiers are being used in the template code and forward declare them in the generated code so that reference errors are not caused.
If you allow arbitrary JavaScript, then I'm sure you realize that you can't "just walk the AST" ;)
At compile time, you have no idea which identifiers are incoming data values — to be supplied by the caller of the template function — and which identifiers already exist in scope.
At compile time, you have no idea which identifiers are incoming data values — to be supplied by the caller of the template function — and which identifiers already exist in scope.
Let me put it in code terms. In the following template script:
<div>@hello</div>
var ___html = "";
var hello = hasown.call(data, "hello") ? data.hello : "";
___html += '<div>' +
safeString(hello, HTML_GENERIC) +
'</div>';
return ___html;
Thanks. I'll add that in on the next update.
[off topic] i find very distracting that the title in the page changes when "Someone is writing..." a comment.
This is the second article I've read on this site, and the second time that I've noticed after about 5 minutes that my computer's fan sounds like it's about to take off. Disconnect gets stuck in some kind of loop on their site and I feel like it's because of that feature (edit: because I've never seen that feature or that Disconnect freakout on any other site).
I like how this looks, I definitively want to try it out.
With that being said :
> Here's the shocking part: a 1Kb library requires the least keystrokes to build the Todo MVC application
I'll decide on my own if it's shocking or not. Also I don't care that much about keystrokes, there's nothing wrong with verbose/expressive languages. I want my code to be readable and maintainable, and then concise if possible. This project looks cool but I wish its creator(s) was/were a bit more humble.
With that being said :
> Here's the shocking part: a 1Kb library requires the least keystrokes to build the Todo MVC application
I'll decide on my own if it's shocking or not. Also I don't care that much about keystrokes, there's nothing wrong with verbose/expressive languages. I want my code to be readable and maintainable, and then concise if possible. This project looks cool but I wish its creator(s) was/were a bit more humble.
I still find it really surprising that I was able to write the Todo APP in least amount of keystrokes by using only 1kb of "framework" code.
And I totally agree that the goal should be readability and maintainability – this is what the post is mostly about.
And I totally agree that the goal should be readability and maintainability – this is what the post is mostly about.
Except, that's not true - the Angular TodoMVC code is smaller and more expressive, and Angular's JS is actually smaller than Riot + jQuery.
I get what you're trying to do here but please don't resort to misleading statements to prove your point. This community sees right through it and every time you say things like this, you lose credibility.
I get what you're trying to do here but please don't resort to misleading statements to prove your point. This community sees right through it and every time you say things like this, you lose credibility.
Do you have a link to the other framework implementations of the todo app? I'm fairly sure that an angular implementation should be less code than the riot version.
I love minimal code. When you try to do minimal, often what you end up doing is stripping away everything you don't need -- extreme YAGNI -- and getting to the core of something. Even if the result ends up being too minimal, it's often extremely educational.
To remove the jQuery dependency I'd suggest looking at this: http://minifiedjs.com/
To remove the jQuery dependency I'd suggest looking at this: http://minifiedjs.com/
It looks like the meat of $.observable is mostly just passing thru to jQuery https://github.com/moot/riotjs/blob/master/riot.js#L29-L54 I don't really have an opinion on whether this is good or bad but it's worth noting that jQuery is doing the heavy lifting here.
A couple code notes:
* why, in the observable function, are you switching functionality not by the name of the function called ('on','emit', etc.) but by the index of that function name in the array on line 32? This strikes me as brittle because adding to or rearranging that array would cause the whole function to fall apart. It's also harder to read- I'm looking at `if(i == 2)` rather than `if( fnName === 'emit' )`. Does this yield a significant performance gain or is it just to juice the final "weight" of the library (<1kb)? I ask because it sure as heck makes the code harder to read.
* Using `name` & `names` as variable names makes the code harder to read, as it doesn't give any meaningful context about what the variable stores (besides the fact that it probably represents a thing that has a "name"). It looks like in this case it represents event names but more descriptive variable names would eliminate this ambiguity & it would make no difference to the code weight after minification.
I bring these things up because this lib looks cool & I like the "you can easily read the whole source" point, but this obsession with brevity (that's what it looks like at least) causes code readability to suffer & greatly diminishes the benefit of being able to "easily read the whole source." Make the code more readable & more people will use the project & contribute. :)
A couple code notes:
* why, in the observable function, are you switching functionality not by the name of the function called ('on','emit', etc.) but by the index of that function name in the array on line 32? This strikes me as brittle because adding to or rearranging that array would cause the whole function to fall apart. It's also harder to read- I'm looking at `if(i == 2)` rather than `if( fnName === 'emit' )`. Does this yield a significant performance gain or is it just to juice the final "weight" of the library (<1kb)? I ask because it sure as heck makes the code harder to read.
* Using `name` & `names` as variable names makes the code harder to read, as it doesn't give any meaningful context about what the variable stores (besides the fact that it probably represents a thing that has a "name"). It looks like in this case it represents event names but more descriptive variable names would eliminate this ambiguity & it would make no difference to the code weight after minification.
I bring these things up because this lib looks cool & I like the "you can easily read the whole source" point, but this obsession with brevity (that's what it looks like at least) causes code readability to suffer & greatly diminishes the benefit of being able to "easily read the whole source." Make the code more readable & more people will use the project & contribute. :)
How can someone just beat Resig's or Jashkenas' code performance "that easily"?
https://github.com/moot/riotjs/blob/master/riot.js#L12-L21
By only supporting simple single property accesses. All that this can do is print values from an object — no loops, conditionals, filters, methods, or anything else — like the others support. Think string interpolation, not templates.
By only supporting simple single property accesses. All that this can do is print values from an object — no loops, conditionals, filters, methods, or anything else — like the others support. Think string interpolation, not templates.
Yeah. The idea is to support variable substitution (string interpolation) only. The loops are supposed to be done on the Presentation layer.
You should remove the need to wrap the replacement strings in {} so the templates don't need to be rewritten. As it stands now, you're requiring people to write a template once, than rewrite it, and then debug the final result. Better to just use basic HTML.
By doing less.
How hard would it be to remove the jQuery dependency? It looks like it really only needs $.on/$.off/$.one/$.emit, which could surely cut the actual size down a lot from 94kb.
Someone needs to get started on breaking JQ down into it's component pieces. So much in there that I never use.
Here is the entire source: https://github.com/moot/riotjs/blob/master/riot.js
* jQuery not shown
TL;DR: "You don't need a framework for that"
1kb, plus jQuery's 50. This must be a joke...
Indeed. The whole reason for the existence of all these frameworks riot is being compared is to to simplify development.
Angular has no dependancies. Knockout also has no dependancies, so it's actually 13k > than riot.
For anyone who really serious about going minimal, here are some alternatives to jquery to build on.
9.7kb http://zeptojs.com/ 3.4kb https://github.com/rpflorence/snack 5.0kb https://github.com/julienw/dollardom/ 10kb http://xuijs.com/ <1kb https://github.com/honza/140medley
What a riot!
Angular has no dependancies. Knockout also has no dependancies, so it's actually 13k > than riot.
For anyone who really serious about going minimal, here are some alternatives to jquery to build on.
9.7kb http://zeptojs.com/ 3.4kb https://github.com/rpflorence/snack 5.0kb https://github.com/julienw/dollardom/ 10kb http://xuijs.com/ <1kb https://github.com/honza/140medley
What a riot!
It looks like a nice little library. Unfortunately, most of these "micro super fast i can build a todo app in 4 lines of code" things aren't enough anymore.
Most of us aren't building "Todo" apps. We're building bigger apps which require - or are more suitable - for a framework like Angular/Ember. That's just my 2 cents.
Most of us aren't building "Todo" apps. We're building bigger apps which require - or are more suitable - for a framework like Angular/Ember. That's just my 2 cents.
Moot is a complete discussion system built with Riot / MVP. There is no other app than Todo MVC to make comparisons.
Seems really nice, but I would not call this a framework. Just like Backbone, it is more of a library than anything else.
The lack of framework-ness is what makes it interesting: you're not handing your entire app's architecture to a framework and hoping for the best. This library knows its place, and it is happy to be there, instead of spreading itself all over your code and claiming it is helping you.
[deleted]
I like this idea, you can in fact build a MVP framework without writing a 1kb library, assuming he's not counting the dependencies (jQuery), you can aswell use Hogan/Mustache/Underscore templates, a router libarary, an observer library and jQuery.
I just dislike the use of "new" in javascript...
I just dislike the use of "new" in javascript...
This is a nice academic exercise but isn't very useful for real world apps. The logicless "views" alone make building anything complex impossible.
One of the reasons this is so light is that it forces you to write boilerplate code for models. I use libs to eliminate boilerplate, not force it upon me.
One of the reasons this is so light is that it forces you to write boilerplate code for models. I use libs to eliminate boilerplate, not force it upon me.
Completely ignoring the technical aspects of the framework. The branding being used looks like a rip-off of Riot the design and development studio in England. http://riothq.com
THEY'RE BOTH RIPPING OFF OWS http://occupywallst.org/! Power to the people.
I think this looks great. Thought I'd let you know I found a typo though. In the jQuery section, last paragraph, "Riot takes a puristic approach and does not allow you to do mix any logic inside HTML views."
Precompilation renders template rendering speeds...moot.
What a weird factor to use for choosing a template engine. Also there already is a popular unit test framework called riot.js
What a weird factor to use for choosing a template engine. Also there already is a popular unit test framework called riot.js
> Precompilation renders template rendering speeds.
Not 100% sure what you mean but if you measure the time to render a HTML fragment 100 times the total time is 1 x pre-compilation + 100 x rendering. The pre-compilation has virtually no effect on the total time.
Not 100% sure what you mean but if you measure the time to render a HTML fragment 100 times the total time is 1 x pre-compilation + 100 x rendering. The pre-compilation has virtually no effect on the total time.
I mean that if you do the HTML parsing to JavaScript portion as part of your deploy, instead of in the browser at render time, then all you're measuring is string concatenation and HTML render times, which should always be the same. Template rendering speeds in that case mean nothing.
Exactly - with the proliferation of Grunt in most modern webapp builds, it is incredibly simple to pre-compile your templates in your production builds. In fact, it's so fast (and I get useful stacktraces when my tpls have errors) that I started precompiling templates in development, too.
I find the bottleneck is 99% the browser's HTML parser and 1% the actual templating library.
If somebody had any tips on how to bring down the "Parse HTML" time spent in the Chrome inspector (see Timeline), I would be interested to know. Tips other than, of course, "parse less HTML".
I find the bottleneck is 99% the browser's HTML parser and 1% the actual templating library.
If somebody had any tips on how to bring down the "Parse HTML" time spent in the Chrome inspector (see Timeline), I would be interested to know. Tips other than, of course, "parse less HTML".
I think that was his point.
There's always room for microframeworks, thank you.
I'm going to go ahead and assume this is satire.
Uh MVP (Minimum Viable Product) vs. MVP (Model View Presenter). That will be confusing.
(still nice project of course)
(still nice project of course)
On HN (or another startup / business-oriented board), I'd agree it's a bit confusing.
In terms of UI development, the Model-View-Presenter pattern has been around (and fairly mainstream) for a couple of decades now, so the target audience will probably assume correctly.
In terms of UI development, the Model-View-Presenter pattern has been around (and fairly mainstream) for a couple of decades now, so the target audience will probably assume correctly.
Meh, I wasn't confused 'cuz it said "framework," but I guess I'm more of a hacker than a startup junky. ^_^
Would be nice to have Angular, Backbone and Knockout included in the speed graph.
Backbone's Underscore was included.
@tipirai Could you please put up more posts on usage and the documentation?
I'll do that on my next post. I just wanted to push out the general idea first.
key feature of many frameworks is that they break if you don't follow them carefully, limiting damage from 10x developer's hacked together code. does riot provide similar functionality?
Developing with Riot is completely different from other frameworks. It's just 3 functions and after 1.0 the API will be hardened. It's more of a design pattern than a framework. The application developer is the biggest culprit for breaking things.
Calling this a framework is a bit of a stretch isn't it? I don't see how a few helper functions that rely on a very large library constitute a framework for doing anything at all.
Yeah. I guess it's more of an library, but it promotes the use of MVP design pattern / way of coding – and can thus be interpreted as a framework. I might change it to library if it makes more sense.
That's the same thing with Rails.
You don't follow a rule, it doesn't allow you to do it. You need to go by the book there, so why not here?
You don't follow a rule, it doesn't allow you to do it. You need to go by the book there, so why not here?
Rails is much more than just 4 methods.
Oh I didn't know Cristopher Poole is a programmer!
Okay, he isn't.
Okay, he isn't.
1kb (+ 93kb for mandatory jQuery dependency)
This sort of thing is a beautiful demonstration of marketing, big promises, and bombastic rhetoric in open source. But one of the best things about open source is that you don't have to take such claims at face value. If you actually look at the source, you'll find:
https://github.com/moot/riotjs/blob/29ae687ca0633b703e124331...
* A funny syntax for string interpolation. (Not templates)
* A strange bug relating to "popstate", ignoring browser support for folks on IE.
* A simple proxy to jQuery's `on`, `off`, `emit`, and `one` functions. (Why not just use jQuery events directly?)
* A simple proxy to "pushstate" and "popstate". (Ditto)
... and that's about it.
Calling this, "The fastest, smallest and most powerful client side framework for building large scale web applications," is pretty funny stuff — but I guess it might also be true. There's almost literally nothing here except for jQuery.
That said, if this were rewritten as a "you don't need a library to do MVC" blog post, then more power to it — it would be right on. But at the moment, it's a pretty spectacular piece of puffery — the sad thing being just how effective this sort of thing can be: http://cl.ly/SFzy. "Riot.js" might be a particularly egregious example, but similar tactics can be found all over the place. As a community, it would be nice if we could spend a little more time reading source, and seeing what libraries actually do and what can be done with them, and less time just drinking down the PR.
(And if this is all an elaborate joke, then I'm an ass for falling for it ;) But that's not the sense I get.)