I'd be really interested in the views from people who were much more into JS than I am. I've used Angular for a couple of small cases now and I like it, but have been hearing lots of good stuff about React (and even Om, I'm quite Clojure inclined). How does this stack up against React in terms of power, brevity, etc?
Maybe I'm missing something, but that comparison looks like apples versus oranges, or more specifically JavaScript-side versus HTML-side. The React example looks like the JS-side only, while the Riot example looks like the HTML-side only. What am I missing?
edit: I see a touch of embedded script (i.e. handleSubmit) in the Riot example, but not nearly enough to replicate the JS code in the React example. And there is a <script> call, but it looks more like an Angular partial than an actual script.
I haven't used React in about 6 months, but I'm pretty certain the Riot code does the exact same thing.
If you haven't used React, it has JSX as syntactic sugar for what would otherwise be a bunch of javascript: see the "render" function in createClass. So a component is written in JS.
With Riot, the JS goes into the template to create a component.
There's a lot of things to like about React, but it requires some boilerplate and a larger API in order to support the amount of freedom it offers in updating (that Riot page goes into this a bit).
If you want something that keeps the HTML and JS separate but still allows components, while having a straightforward API along with a small file size, check out knockoutjs.com
> If you want something that keeps the HTML and JS separate ...
I guess my JS knowledge is small enough that I just expect the HTML and JS to be primarily separated. (It seems like a best practice to me, but I haven't experimented with code that wasn't primarily separated, so I'm sure I'm missing some important insights).
Thank you for making the knockoutjs.com recommendation. For someone, with primarily Angular experience, who is looking to broaden their horizon, which of the three would you recommend as the next framework to learn: React, Riot, or Knockout?
I believe that React would offer you a very different perspective. It also has a strong developer community; React is already being used in a lot of places (although Azure's management interface was just recently redone using Knockout). I've also heard that you can combine React and Angular.
After this, the React tutorial should get you up and going. Once you start working on more complex apps, look into the Flux architecture (an approach to application structure that Facebook uses with React, like you'd use MVC/MVVM/etc otherwise).
They do seem to be getting closer to sanity with each one though. With the advancements in browsers, in a few years the experience of web development may not be completely awful!
This looks amazing! I work with angularjs, been testing reactjs, but this looks simpler and minimal to code ? Probably less documentation or community online ?!
Is that only when defining a custom tag, or when using it as well? All the examples seems to be of nesting when defining a custom tag. If it supports it when using the tag, how do you get access to the nested content?
I'm just curious about performance with fucking large app.
It's always the main issue for me, a todo list can't show use performance. If your framework is fast with 3 items in a list, what's the point with, like, 1000?
Looks nice. React really is more of a pattern or (if you will) a design philosophy, so anything along those lines is appreciated.
However, I don't think being ~10x smaller is enough. It needs to be ~10x better as a whole, which in my view it isn't. The improvements seem more cosmetic than substantial.
I feel sorry for people who have to write native JS at this point. I can't imagine a JS job interview where you didn't have to know of/about yet another framework.
Great to have some innovation on the frontend for once. We're getting closer and closer to a place where we can write flexible, performant interfaces without the heavy frameworks and tooling of native frontend dev.
The virtual DOM is an implementation detail (riot could re-render everything on each change), but it's what makes React fast, and good for handling big apps.
I don't think you can call a lib "react-like" if it doesn't have something like the virtual dom diff. You could say it has react-like syntax, maybe.
That said, I have been following riot for a while and I always liked its minimalistic approach. Maybe I will give it another look now that it is 2.0
EDIT: I somehow missed the big subtitle which says "Virtual DOM" on the website. It clearly states that Riot has something similar to React's. I can't explain know how I managed to not see it. Thanks to everyone who called me out.
I agree that calling it "React-like" seems misleading. When I read about a 'x'-like library I expect something that could actually replace 'x' and provide nearly the same features.
Pete Hunt did a great talk on what actually makes React / virtualdom different from other databinding approaches.[1] Using this definition Riot.js looks a lot more like Angular, Ember et al. to me.
I don't think of something as React-like just because it puts HTML and JS in the same file or combines HTML tags with blocks of JS code.
The difference between React and other databinding methods is that you can use all JS language features (i.e. if, for, while, .filter(), .map(), libraries like Rx.js, etc.) when defining what you want your DOM to look like.
Suppose I want to have a list of items based on some array, which I want to filter based on some predicate, and display the items differently based on their content type.
> I don't think of something as React-like just because it puts HTML and JS in the same file or combines HTML tags with blocks of JS code.
Totally agree. While I do (most of the time) appreciate JSX, it is IMO the least interesting and relevant feature of React. It mostly just lets our company's designers continue to edit view templates that would otherwise be far beyond their training/experience. So that's nice, but it's not what makes React tick.
I somehow missed that (quite incredible, being one of the main subsections), and I simply assumed that you can't cram something like that in 2.5kb - I apologize.
I like the use of a virtual DOM and the custom tags. Custom tags is what makes Angular easy to use. But I would like to see some benchmarks. I'm afraid parsing every single byte of every single html template is slow.
Riot also needs widgets. Lots of lots of widgets for material design widgets for making desktop and mobile apps, and twitter bootstrap like widgets. Good developers are lazy developers. They don't want to make an entire eco system.
In theory Riot is super fast. The DOM is parsed once when a tag is initialized and after that the text nodes and attributes are only updated if the expression results to a different value. The expressions are compiled and cached.
Beware the way you're benchmarking, e.g. immutable structures and pure (& immutable-state-aware) components can make a pretty huge difference in react.
Each component maintains it's own state. Think them as functions with isolated scope. The tags accept arguments via HTML attributes and each tag has a reference to it's parent.
Instance variables and method are assigned to the scope and you have direct access to them on the HTML expressions. Once the scope changes and tag's `update()` method is called the expressions are calculated and DOM nodes are updated. Nested children are also updated.
You can update all tags at the same time with a global `riot.update()` method.
The point of React is to mix HTML and JS together. They deliberately mix templates with logic, which is actually the main inspiration for Riot.
But we felt that what React does could be simplified. We didn't need full diffing and batching of HTML and we didn't like the verbosity on how components are created.
> The point of React is to mix HTML and JS together.
In React, there are no "templates." There's just JavaScript, and then more JavaScript that looks kind of like HTML (JSX). But it's all still JavaScript.
Also, FWIW, I find that one of the largest benefits of React is to have the logic and the representation of the markup inline, together in the same file. It really helps productivity by eliminating the context switching going from js to markup.
> We didn't need full diffing and batching of HTML
^^^ That's the point of React. You don't have to do the diff in your head (or in your code).
Fantastic intro doc. I read the entire thing without really thinking. I like the aim, and I think I could learn to accept the weird looking javascript floating in the root node (though I think it might look easier on my eye if wrapped in a <script> tag, even if that tag is redundant)
But, I would _really_ love to see some render time benchmarks with large (2K+) loops adding/removing deeply nested nodes. This is where React really shines in my opinion, and I'm struggling to believe that Riot can compare with the implementation described.
Very cool project! I have used nearly every framework under the sun and React is, by far, my favorite. It's getting better every release. The concepts it introduces are sound, and I don't think I'd ever do frontend development any other way.
That said, Riot is a very encouraging take on React - and I think it may have a very solid place in apps that need to be very light and fast. Perhaps it's perfect for prototyping. I will try to find a small project for it.
One question; is there any way to render to a string so Riot can be used server-side?
I just looked at the doc and read this thread (at 61 comments).
Same:
* virtual dom
* has its own tag syntax
* Mithril has MSX, but also supports regular JS data structure with m("tag", {attr:val, onclick: func, [more tags, "text"]}
* router
Different:
* Where Mithril allows you to build and transform resulting template structure before virtual DOM generation, Riot mixes HTML tags and JS, builds tags from that which can be composed
* Uses a compiler, Mithril without MSX can work directly in the browser
* Probably other stuff, too, I'm just reading the examples, at least is not supported Ajax/XHR
Speed is a big question. Mithril is plenty fast (there's a benchmark on the home page, and somewhere I saw a TodoMVC comparison which put Mithril near the top few months back).
I have not yet formed an opinion, but RiotJS' size and web component approach intrigue me. More example apps, plz, with client/server communication and CRUD ops.
Me thinks Mithril is fairly minimal, too, but this point can't be completely objective. If API allows to do things I find complicated to do myself, then I happily accept a little bloat here and there.
I will be looking at Riot custom tags and how they might help (or hinder) creating components out of functionality. There is currently an interesting discussion on the Mithril mailing list about these things. Also it's what attracted me to Angular long time back (and what drove me away from it, as well).
I love the differing thought patterns apparent in the length of your and lhorie's response to this question. Like the framework, this response is minimal.
- Riot apparently requires a compile step (at least as far as being able to follow the docs goes), Mithril doesn't
- Riot has no AJAX support, Mithril does (plus promises, plus an idiomatic workflow to work with async ajaxy stuff: `var prop = m.request(...)`)
- I could not find anything about keys in the Riot docs. Keys are a very important part of the virtual dom diff algorithm (basically it's the mechanism that lets you sort tables without rebuilding the whole thing from scratch)
- Riot's router appears to support only hash mode. Mithril's also supports HTML5 mode (which allows you to skip the # symbol), and a querystring mode that is step in between the two in terms of tradeoffs.
- Both Riot and Mithril redraw by default on events, but Riot appears to lack APIs to control when NOT to redraw. This is kind of a big deal with cases like expensive oninput, complex event bubbling behavior, etc.
Other than that, I just have a small nitpick:
> Riot mixes HTML tags and JS, builds tags from that which can be composed
As far as I can tell, Riot components can be nested, but I'm not sure they can be composed per se. Real composition would allow you, for example, to have lazy components (i.e. pass a component A to another component B and evaluate A at a specific point in B's virtual dom tree). A modal is an example of this.
> RiotJS' size and web component approach intrigue me
Mithril supports the `is` attribute, and I saw someone using custom elements with a polyfill ( https://github.com/WebReflection/document-register-element ) and Mithril. It's basically "Web components, the good parts". Worth looking into.
Thanks for the comparison. If you look in the demo code, you'll see you don't necessarily need the compile step, just write your custom tags with riot.tag and use strings for the would-be compiled part.
Should then be trivial to whip up a require.js plugin that leverages riot.tag for working on-the-fly in development, but which compiles during a build/optimize process.
In my experience with Backbone, another relatively small js library, the fact that the library is smaller and "does less for you" also means that you end up in one of these scenarios: you need to figure out how to solve a lot of things that other, larger libraries handle out of the box; or, you need to glue libraries together that provide those solutions; or, you have a bunch of prior experience with the library in question, have solved those problems before, and can bring that expertise (and often that code) to each new project.
These all bring with them their own issues of simplicity (tying libraries together?), maintainability (what happens when I realize my library/framework additions are inadequate, and/or buggy?), and learning curve (instead of learning the API I am learning how to do things with a very minimal API).
To some degree, a small library doesn't solve these problems, it offloads them to you--which isn't necessarily a bad thing. It, like basically everything in software development, is about being aware of the tradeoffs and figuring out the best balance.
But in case of Riot I suppose it's best for you to read the documentation and see whether it does the job for you. I personally think the custom tag approach is a great way to go.
Please don't misunderstand. I was only trying to make the distinction between "somebody's pet project that might work" and "this stuff HAS to work for millions of views and hundreds of devs every day"
The group releasing it has a drop in forums/commenting system called "Muut" that is fantastic. We needed a private forum system and it was one of the easiest integrations I've ever done. Really solid work.
I would say that a grid would be a great showcase, especially with custom column renderers and/or editors. That's a real stress test for any GUI system, update code, templating etc.
I've been funding CSS Grid implementation work for 2+ years so that eventually no one needs a framework for grid layout. Go play with it in Chrome and help squash bugs :)
221 comments
[ 2.7 ms ] story [ 179 ms ] threadIt's inspired by React so the views are build differently than in 1.0.
> This is the biggest change from Riot 1.0 to 2.0. JavaScript and HTML are now part of the same module.
https://muut.com/riotjs/compare.html
edit: I see a touch of embedded script (i.e. handleSubmit) in the Riot example, but not nearly enough to replicate the JS code in the React example. And there is a <script> call, but it looks more like an Angular partial than an actual script.
Riot components are HTML (mixed with expressions) + JavaScript.
Perhaps the HTML root element makes it look like "HTML-side only".
If you haven't used React, it has JSX as syntactic sugar for what would otherwise be a bunch of javascript: see the "render" function in createClass. So a component is written in JS.
With Riot, the JS goes into the template to create a component.
There's a lot of things to like about React, but it requires some boilerplate and a larger API in order to support the amount of freedom it offers in updating (that Riot page goes into this a bit).
If you want something that keeps the HTML and JS separate but still allows components, while having a straightforward API along with a small file size, check out knockoutjs.com
I guess my JS knowledge is small enough that I just expect the HTML and JS to be primarily separated. (It seems like a best practice to me, but I haven't experimented with code that wasn't primarily separated, so I'm sure I'm missing some important insights).
Thank you for making the knockoutjs.com recommendation. For someone, with primarily Angular experience, who is looking to broaden their horizon, which of the three would you recommend as the next framework to learn: React, Riot, or Knockout?
Reading this will take a bit of time, but it will help you to understand React's approach: http://jlongster.com/Removing-User-Interface-Complexity,-or-...
After this, the React tutorial should get you up and going. Once you start working on more complex apps, look into the Flux architecture (an approach to application structure that Facebook uses with React, like you'd use MVC/MVVM/etc otherwise).
On the other hand Riot is over 1 year old project and this is a new/improved version.
<parent>
</parent>I'm just curious about performance with fucking large app. It's always the main issue for me, a todo list can't show use performance. If your framework is fast with 3 items in a list, what's the point with, like, 1000?
I'm gonna try
Should be fast, since Riot uses compiled and cached expressions and updates DOM nodes only if there is a change.
If there is a performance bottleneck, it can be fixed.
We'll be doing performance tests and comparisons later.
The main selling point of React is that it is actually tested against millions of users and browser configurations as a part of Facebook UI.
Of course React is much more tested and probably more solid at this point and Riot 2.0 is just released.
But one major benefit for Riot is that there is indeed 24x less code to maintain and so much less weak spots to take care of.
Not that you said so, but it's something one can think when he hears that Riot might be "missing stuff".
The virtual DOM is an implementation detail (riot could re-render everything on each change), but it's what makes React fast, and good for handling big apps.
I don't think you can call a lib "react-like" if it doesn't have something like the virtual dom diff. You could say it has react-like syntax, maybe.
That said, I have been following riot for a while and I always liked its minimalistic approach. Maybe I will give it another look now that it is 2.0
EDIT: I somehow missed the big subtitle which says "Virtual DOM" on the website. It clearly states that Riot has something similar to React's. I can't explain know how I managed to not see it. Thanks to everyone who called me out.
But in React you can arbitrarily change HTML because the render method returns a string to be compared to the earlier situation.
A tag name can change for example (which you rarely need).
I'm pretty sure the render method returns a vdom node (which the library can then diff and merge into the actual DOM)
That's starting from the 42k 1.2.0 distfile.
Riot cannot make random sub-tree replacements. It's best for situations where the tag HTML structure is fixed (no tag name changes for example).
Riot virtual DOM minimizes the work and makes less DOM manipulations than React on each update cycle.
Loops and conditionals can change the structure.
Pete Hunt did a great talk on what actually makes React / virtualdom different from other databinding approaches.[1] Using this definition Riot.js looks a lot more like Angular, Ember et al. to me.
[1] https://www.youtube.com/watch?v=-DX3vJiqxm4
The biggest reason for calling it "React-like" is the basic idea of components, where related HTML and JS are combined together.
> "Build components, not templates"
http://www.slideshare.net/floydophone/react-preso-v2
I think this is the "what" of React and virtual DOM is the "how".
The difference between React and other databinding methods is that you can use all JS language features (i.e. if, for, while, .filter(), .map(), libraries like Rx.js, etc.) when defining what you want your DOM to look like.
Suppose I want to have a list of items based on some array, which I want to filter based on some predicate, and display the items differently based on their content type.
In a React render() function I would just use
to filter unwanted items, and to map the individual items to how I want them to look like.To me it looks like to implement something like this in Riot would require to build / use something that is more like Angular's computed properties.
But I'd like to be proven wrong.
<my-tag>
</my-tag>And you can also manipulate items on every update. I'm sure that at some point there will be a clear use case where React is a better choice.
So far Riot rendering has worked us perfectly.
Totally agree. While I do (most of the time) appreciate JSX, it is IMO the least interesting and relevant feature of React. It mostly just lets our company's designers continue to edit view templates that would otherwise be far beyond their training/experience. So that's nice, but it's not what makes React tick.
Sorry, I don't follow. The Riot.js project site DOES tout "Virtual DOM" as one of its features.
You say it doesn't actually have that?
Riot also needs widgets. Lots of lots of widgets for material design widgets for making desktop and mobile apps, and twitter bootstrap like widgets. Good developers are lazy developers. They don't want to make an entire eco system.
In theory Riot is super fast. The DOM is parsed once when a tag is initialized and after that the text nodes and attributes are only updated if the expression results to a different value. The expressions are compiled and cached.
Any performance bottleneck can be fixed.
Beware the way you're benchmarking, e.g. immutable structures and pure (& immutable-state-aware) components can make a pretty huge difference in react.
Maybe I can just use the TodoMVC app.
Or http://evancz.github.io/todomvc-perf-comparison/ which seems to be an older version of the same bench but has a better output.
I also think that Riot performance can be further optimized.
Slowly getting there...
This looks like a very nice upgrade, in the sense that the previous templating was a bit ugly. I hope the virtual DOM let me handle SVG as well...
https://github.com/muut/riotjs
It's on the download page. Admittedly not very visible.
Thank you!
I still don't get how state works, whether state changes propagate down the components as prop changes like in React, etc.
Instance variables and method are assigned to the scope and you have direct access to them on the HTML expressions. Once the scope changes and tag's `update()` method is called the expressions are calculated and DOM nodes are updated. Nested children are also updated.
You can update all tags at the same time with a global `riot.update()` method.
Hope this helps.
What's wrong with React?
But we felt that what React does could be simplified. We didn't need full diffing and batching of HTML and we didn't like the verbosity on how components are created.
minimalism is where Riot starts from.
In React, there are no "templates." There's just JavaScript, and then more JavaScript that looks kind of like HTML (JSX). But it's all still JavaScript.
Also, FWIW, I find that one of the largest benefits of React is to have the logic and the representation of the markup inline, together in the same file. It really helps productivity by eliminating the context switching going from js to markup.
> We didn't need full diffing and batching of HTML
^^^ That's the point of React. You don't have to do the diff in your head (or in your code).
But, I would _really_ love to see some render time benchmarks with large (2K+) loops adding/removing deeply nested nodes. This is where React really shines in my opinion, and I'm struggling to believe that Riot can compare with the implementation described.
I'm sure there will be a Angular comparison here as well:
https://muut.com/riotjs/compare.html
Ember too, because of HTMLBars (DOM based templating) and FastBoot (later).
That said, Riot is a very encouraging take on React - and I think it may have a very solid place in apps that need to be very light and fast. Perhaps it's perfect for prototyping. I will try to find a small project for it.
One question; is there any way to render to a string so Riot can be used server-side?
https://muut.com/riotjs/faq.html
I just looked at the doc and read this thread (at 61 comments).
Same:
* virtual dom * has its own tag syntax * Mithril has MSX, but also supports regular JS data structure with m("tag", {attr:val, onclick: func, [more tags, "text"]} * router
Different:
* Where Mithril allows you to build and transform resulting template structure before virtual DOM generation, Riot mixes HTML tags and JS, builds tags from that which can be composed * Uses a compiler, Mithril without MSX can work directly in the browser * Probably other stuff, too, I'm just reading the examples, at least is not supported Ajax/XHR
Speed is a big question. Mithril is plenty fast (there's a benchmark on the home page, and somewhere I saw a TodoMVC comparison which put Mithril near the top few months back).
I have not yet formed an opinion, but RiotJS' size and web component approach intrigue me. More example apps, plz, with client/server communication and CRUD ops.
Riot offers following to the (massive) client-side table:
1. Custom tags (with unscary HTML + JS syntax)
2. Minimalism (both size and API surface)
3. Performance (minimizing DOM operations with virtual DOM)
The 3rd item is not battle-tested / benchmarked yet and there is probably room for improvements.
Me thinks Mithril is fairly minimal, too, but this point can't be completely objective. If API allows to do things I find complicated to do myself, then I happily accept a little bloat here and there.
I will be looking at Riot custom tags and how they might help (or hinder) creating components out of functionality. There is currently an interesting discussion on the Mithril mailing list about these things. Also it's what attracted me to Angular long time back (and what drove me away from it, as well).
A few important differences as far as I can tell:
- Riot apparently requires a compile step (at least as far as being able to follow the docs goes), Mithril doesn't
- Riot has no AJAX support, Mithril does (plus promises, plus an idiomatic workflow to work with async ajaxy stuff: `var prop = m.request(...)`)
- I could not find anything about keys in the Riot docs. Keys are a very important part of the virtual dom diff algorithm (basically it's the mechanism that lets you sort tables without rebuilding the whole thing from scratch)
- Riot's router appears to support only hash mode. Mithril's also supports HTML5 mode (which allows you to skip the # symbol), and a querystring mode that is step in between the two in terms of tradeoffs.
- Both Riot and Mithril redraw by default on events, but Riot appears to lack APIs to control when NOT to redraw. This is kind of a big deal with cases like expensive oninput, complex event bubbling behavior, etc.
Other than that, I just have a small nitpick:
> Riot mixes HTML tags and JS, builds tags from that which can be composed
As far as I can tell, Riot components can be nested, but I'm not sure they can be composed per se. Real composition would allow you, for example, to have lazy components (i.e. pass a component A to another component B and evaluate A at a specific point in B's virtual dom tree). A modal is an example of this.
> RiotJS' size and web component approach intrigue me
Mithril supports the `is` attribute, and I saw someone using custom elements with a polyfill ( https://github.com/WebReflection/document-register-element ) and Mithril. It's basically "Web components, the good parts". Worth looking into.
Thanks for the analysis.
Its the motion of the ocean in the library that matters.
1. simplicity
2. maintanability
3. API surface and learning curve
Riot also about minimalism, especially in syntax.
Less proprietary stuff (and keystrokes).
These all bring with them their own issues of simplicity (tying libraries together?), maintainability (what happens when I realize my library/framework additions are inadequate, and/or buggy?), and learning curve (instead of learning the API I am learning how to do things with a very minimal API).
To some degree, a small library doesn't solve these problems, it offloads them to you--which isn't necessarily a bad thing. It, like basically everything in software development, is about being aware of the tradeoffs and figuring out the best balance.
But in case of Riot I suppose it's best for you to read the documentation and see whether it does the job for you. I personally think the custom tag approach is a great way to go.
What has this been used on?
Dojo has also been used on a bunch of huge projects, but nobody gets excited about it...
This looks better though, IMHO.