Live data from Hacker News

Riot.js – A 1kb client-side MVP framework

moot.it

81–90 of 147 posts

Re: Riot.js – A 1kb client-side MVP framework

#81
post #53

Earlier quoted context omitted.

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 n…

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.

Re: Riot.js – A 1kb client-side MVP framework

#82

Earlier quoted context omitted.

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,…

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…

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!

Re: Riot.js – A 1kb client-side MVP framework

#83

Earlier quoted context omitted.

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

[deleted]

Re: Riot.js – A 1kb client-side MVP framework

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

Re: Riot.js – A 1kb client-side MVP framework

#85

Earlier quoted context omitted.

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…

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,…

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

Re: Riot.js – A 1kb client-side MVP framework

#86

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…

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.

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.

Re: Riot.js – A 1kb client-side MVP framework

#89

Earlier quoted context omitted.

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.

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.

Let me put it in code terms. In the following template script:

    @hello
The generated code can be like (not including runtime lib):

    var ___html = "";
    var hello = hasown.call(data, "hello") ? data.hello : "";

    ___html += '' +
                safeString(hello, HTML_GENERIC) +
                '';

    return ___html;
Which gives same effect as `with`.

Re: Riot.js – A 1kb client-side MVP framework

#90

Earlier quoted context omitted.

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,…

> 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 a…

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

Post reply on HN