I also found Riot very practical, mostly because I got up and running very quickly. I had a well-structured Riot app done faster than grasping all that ReactJS boilerplate.
And this was possible even though the Riot documentation was sub-optimal in some places, to say the least - the holes in the documentation were compensated by the fact that most things are simple and straight forward.
I don't know how good this concept scales to huge applications, but I can confirm that writing a non-trivial SPA in Riot was a charme.
Neverthelss, I do miss some things the Riot for the overall architecture and information flow. But I learned that ReactJS doesn't have these either. As with React, Riot should be combined with Flux, or a lightweight alternative such as Redux.
>Neverthelss, I do miss some things the Riot for the overall architecture and information flow. But I learned that ReactJS doesn't have these either. As with React, Riot should be combined with Flux, or a lightweight alternative such as Redux.
As long as you remember that you're doing Model-View-Whatever, you can structure a riot (or react/vue for that matter) application fairly lucidly and without too much friction. You want the application state (~Model) to reside in a separate container, and the riot/react/whatever custom tags (~Views) should be fairly lean and strive only to display and trigger operations on the state (i.e. either call functions exposed by the state object, or trigger/listen to state events), while storing as little state as needed locally. If you're lazy like me, you can make the app state container a global - otherwise just pass a pointer to it to every tag (Flux).
Redux helps with the minimization of local state by emphasizing pure functions, and thus encourages the required minimal state to be passed in as function parameters when needed (and in the localest scope needed). That's really the genius of it, imho - functional purity keeps the state tidy.
Riot's (optional) solution is an "observable" functionality which can be attached to any object (e.g. the state container itself or a child thereof), and tags and other objects can then listen to events on those objects and update themselves accordingly (pretty classic pattern - but being minimal and "vanilla" is the point of Riot anyway), and so I find myself using this and not going with Redux, for the sake of productivity, even though it's a little bit sloppier than Redux.
And this was possible even though the Riot documentation was sub-optimal in some places, to say the least - the holes in the documentation were compensated by the fact that most things are simple and straight forward.
I don't know how good this concept scales to huge applications, but I can confirm that writing a non-trivial SPA in Riot was a charme.
Neverthelss, I do miss some things the Riot for the overall architecture and information flow. But I learned that ReactJS doesn't have these either. As with React, Riot should be combined with Flux, or a lightweight alternative such as Redux.