This post is pretty old, and might contain outdated advice or links. We’re keeping it online, but recommend that you check newer posts to see if there’s a better approach.
All blog postsFinally a #riotjs list of good practices.. bravo!” — Gianluca Guarini, RiotJS
Lately, we’ve been doing a lot of projects with Riot.js, a “React-like user interface micro-library”. We discovered that it aligns nicely with our approach for smaller projects, but has some drawbacks when apps become more complex. To keep our Riot projects maintainable, we published a style guide that we intend to maintain and improve.
So what about Riot's pros and cons?
The good
- Easy to learn: since Riot is a small framework (only 9kb) there’s not much to learn about it. Furthermore, it’s mostly vanilla JavaScript and HTML — no new syntax like React’s JSX that you need to learn.
- High performance: Riot has a fast runtime compiler, that’s also available as part of your JS build step. Apart from that, Riot makes use of a simplified virtual DOM which makes HTML updates and changes very fast.
- Love for modules: we like component based development. Riot is built around UI modules, called tags, that provide modularity out of the box. Appended with some of our own practices, it’s a breeze to exchange Riot tags between projects.
The bad
- State management is hard: there is no (opinionated) way to manage state within a component or between components. There is no step between a state update and re-render, and when updating a tag, all its children will be updated also. This increases the need for plumbing every time you add complexity to a Riot app. Alternatively, you could implement another library like Redux to keep state, which has its own implications and challenges.
<my-tag>
<div class={ active: isActive } onclick={ toggle }>
{ title }
</div>
this.isActive = false;
toggle(e) {
this.isActive = !this.isActive;
}
</my-tag>- Magic syntax: the Riot team made peculiar choices with regards to keeping to standards. There is some ES6-like syntax used in code examples that is not found anywhere else. Also, Riot interprets your tag contents as JavaScript instead of HTML by default. In the example above, HTML attributes have no quotes. The
togglefunction definition would throw an error in any linter and there’s no<script>tag around the JavaScript. Quirks you can easily work around, but a possible stumbling block for novice developers. And bad for reusability of your code. - Maybe not strict enough: An app built in Riot is just a big object, living in the global scope, that you can easily traverse and manipulate. Even its internals are accessible. When running into problems it becomes tempting to build hacks and workarounds using these ‘features’. Unexpected side effects because of this are all too common in Riot.
The style guide
The best way to work around these pitfalls is to put guidelines in place. It will allow you and your team to build stable and robust apps, even if the underlying architecture is as loose as Riot’s. We wrote a style guide just for this reason.
