6 ms·

While I'd usually prefer to be nice in the mornings ... starting off with those benchmarks got my goat. So. This sort of thing is a beautiful demonstration of

While I'd usually prefer to be nice in the mornings ... starting off with those benchmarks got my goat. So. 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/29ae687ca0633b703e124331f6395052b051355b/riot.js 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 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.)

tipiirai 13y ago
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?
- aidos 13y ago
  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.... :)
  - tipiirai 13y ago
    Riot has less boilerplate than Angular on the Todo MVC implementation.
    - chrisrhoden 13y ago
      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.
    - brunoc 13y ago
      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.
    - ganarajpr 13y ago
      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/architecture-examples/angularjs-perf 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/architecture-examples/angularjs 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.
sergiotapia 13y ago
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.
- ojr 13y ago
  plain jQuery is harder to maintain and scale hence why the javascript frameworks were built in the first place
  - tipiirai 13y ago
    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.
    - ojr 13y ago
      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?
- nilliams 13y ago
  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.js https://github.com/moot/riotjs/blob/master/todomvc/dist/todo...
JLehtinen 13y ago
> There's almost literally nothing here True. There's 0.85kb + license.
courtneycouch0 13y ago
> There's almost literally nothing here I think that's the point.
vdaniuk 13y ago
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.
- deleted 13y ago
  [deleted]
tipiirai 13y ago
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.
- rubiquity 13y ago
  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.
  - tipiirai 13y ago
    DOM/HTML represents the "passive view": http://martinfowler.com/eaaDev/PassiveScreen.html 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-not-an-mvc-framework/ http://lostechies.com/derickbailey/2011/12/23/backbone-js-is...
rimo 13y ago
I would not call this a framework but a jQuery plugin with a hip name
danmaz74 13y ago
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."
facorreia 13y ago
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.
- jashkenas 13y ago
  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: function Revolution() { var a = arguments; return jQuery[a[0]].apply(jQuery, a.slice(1)); } New frameworks like Riot.js persuade false beliefs with shiny websites and finely crafted marketing without transparent, scientific analysis. They solve hypothetical problems and cause new problems instead. 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.
  - deleted 13y ago
    [deleted]
callum85 13y ago
> (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 :)
- callum85 13y ago
  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.
callum85 13y ago
> (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 :)
rdsubhas 13y ago
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?".
EvanYou 13y ago
This*1000.

tipiirai 13y ago

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?

aidos 13y ago
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.... :)
- tipiirai 13y ago
  Riot has less boilerplate than Angular on the Todo MVC implementation.
  - chrisrhoden 13y ago
    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.
  - brunoc 13y ago
    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.
  - ganarajpr 13y ago
    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/architecture-examples/angularjs-perf 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/architecture-examples/angularjs 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.

sergiotapia 13y ago

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.

ojr 13y ago
plain jQuery is harder to maintain and scale hence why the javascript frameworks were built in the first place
- tipiirai 13y ago
  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.
  - ojr 13y ago
    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?
nilliams 13y ago
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.js https://github.com/moot/riotjs/blob/master/todomvc/dist/todo...

JLehtinen 13y ago

> There's almost literally nothing here True. There's 0.85kb + license.

courtneycouch0 13y ago

> There's almost literally nothing here I think that's the point.

vdaniuk 13y ago

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.

deleted 13y ago
[deleted]

tipiirai 13y ago

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.

rubiquity 13y ago
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.
- tipiirai 13y ago
  DOM/HTML represents the "passive view": http://martinfowler.com/eaaDev/PassiveScreen.html 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-not-an-mvc-framework/ http://lostechies.com/derickbailey/2011/12/23/backbone-js-is...

rimo 13y ago

I would not call this a framework but a jQuery plugin with a hip name

danmaz74 13y ago

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."

facorreia 13y ago

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.

jashkenas 13y ago
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: function Revolution() { var a = arguments; return jQuery[a[0]].apply(jQuery, a.slice(1)); } New frameworks like Riot.js persuade false beliefs with shiny websites and finely crafted marketing without transparent, scientific analysis. They solve hypothetical problems and cause new problems instead. 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.
- deleted 13y ago
  [deleted]

callum85 13y ago

> (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 :)

callum85 13y ago
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.

callum85 13y ago

rdsubhas 13y ago

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?".

EvanYou 13y ago

This*1000.