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