Hacker News Reader

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.

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?

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

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.

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.

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:

    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!

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

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

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

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.

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.

why use riot when you could just pull in a router, an event emitter, and a model?

Exactly :).

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.

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.

Nice one Jeremy :D

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.

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.

The revolution will be open sourced. https://github.com/ChrisAntaki/revolution

Genius!

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.

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.

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

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

> There's almost literally nothing here

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

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

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?

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

Riot has less boilerplate than Angular on the Todo MVC implementation.

First, no it does not. The fact that there are fewer letters does not mean that there is less boilerplate. If you want an accurate measure, you need to count up actual lines of boilerplate in the code.

Second, even if it did (again, it does not), it comes at the cost of reduced functionality. You can claim that these are unnecessary features, but, for instance, the entire template is not re-rendered on each change in Angular, only the affected piece. If you think that that's the right way to write apps in riot, then that means that every line in your app dedicated to restricting changes to a part of the view is boilerplate.

That may be true, but Todo MVC is a minuscule "application"! It can be used as a way to compare libraries and frameworks in a very superficial way but when you're writing a large web application with many screens, a lot of state, many widgets, lots of routes, various persistence mechanism, etc.

It doesn't have enough features to require or demonstrate the abstractions needed to eliminate boilerplate.

That being said I like what you did with Riot which is basically use plain JavaScript as much as possible. And I also like to you bring attention to the fact that jQuery doesn't cause spaghetti: programmers cause spaghetti.

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 has less boilerplate than Angular on the Todo MVC implementation.

why are you lying and thinking you can get away with that ?

Because I'm counting file size and not line numbers. That simple.

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

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.

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.

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

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.

This*1000.