Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

moot.it

Post reply on HN
Print view View original

51–60 of 147 posts

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

#51

Post by tipiirai »

ojr wrote: post #49
sergiotapia wrote: post #42

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…

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.

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

#52

Post by vdaniuk »

jashkenas wrote: post #37

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/29ae687ca…

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.

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

#53

Post by aidos »

tipiirai wrote: post #41
jashkenas wrote: post #37

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/29ae687ca…

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

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

#54

Post by esailija »

jashkenas wrote: post #38
esailija wrote: post #25

Earlier quoted context omitted.

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 I'm afraid that's not possible. If you look at other micro-templating libraries that allow arbitrary JavaScript values, you'll find that there are two options. Either you can support naked variables, and you have to use "with" to bring them into scope ... or you have to prefix all of your variable accesses off a "data" o…

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.

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

#55

Post by nilliams »

sergiotapia wrote: post #42
jashkenas wrote: post #37

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/29ae687ca…

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

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

#57

Post by tipiirai »

jashkenas wrote: post #37

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/29ae687ca…

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.

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

#59

Post by felxh »

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

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

#60

Post by jashkenas »

esailija wrote: post #54
jashkenas wrote: post #38

Earlier quoted context omitted.

> a templating engine could easily avoid the actual with > statement but provide same convenience I'm afraid that's not possible. If you look at other micro-templating libraries that allow arbitrary JavaScript values, you'll find that there are two options. Either you can support naked variables, and you have to use "with" to bring them into scope ... or you have to prefix all of your variable accesses off a "data" o…

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.

Post reply on HN