Riot.js 3.0 released

On November 22, 2007 , Riot.js , a minimalist library for creating web interfaces, was released. As the authors write on the home page of their site, Riot.js is the “Simple and elegant component-based UI library”. And she is really very simple and elegant.

I am a big fan of this invention. It does not clog my brain with unnecessary logic, rules and principles. It gives me a very simple API for creating components nested in each other and makes it possible in a really short time to implement what I need.

For me, programming and APIs of various popular libraries has always been something like math. Based on what does all math work? On the basis of pure and minimalist formulas, brought to perfection. During the existence of this science, humanity has been able to bring various complex ideas to short and pure expressions. And the good libraries and frameworks in the world of programming are doing the same thing. They provide software engineers with a simple and straightforward API to solve problems. We all know jQuery with its short and concise methods for working in the browser and its motto " write less, do more ". Or, say, many people know about such a wonderful library as Sugar.js for adding a reasonable portion of sugar to your global JavaScript objects. And Riot.js - exactly the same thing, only on the topic of web components, taking into account all the latest trends in the evolution of web technologies.
')
In conjunction with the Pug-template engine , your web components based on Riot.js might look something like this:

login-form .login-title  p     : .login-form form(method='POST', action='/auth/login') .login-field .login-label label(for='email') E-mail input(type='email' name='email') .login-field .login-label label(for='password')  input(type='password' name='password' id='password') .login-button button.senddata(type='primary')  .login-links span.link.clickable(onclick="{ openPasswordForm }")  ? span.link.clickable(onclick='{ openRegisterForm }')  script. /* JS    */ var tag = this tag.openRegisterForm = function() { RegisterForm.open() } tag.openPasswordForm = function() { PasswordForm.open() } style. /*    */ 

This is practically standard HTML along with standard JS, while it allows you to break your code into independent components and encapsulate their logic and presentation in separate and clear entities, as well as in React.js, for example. There are just a few points that you need to know about Riot.js work in order to start writing on it. This is not a dock for Angular 2.0 (I don’t even want to sit and read this whole mountain of documents. How long will it take to do this?).

Version 3.0 did not bring any major changes. Practically everything remained to work in the same way as it worked before. The library just became even more licked and refined. A lot of minor and subtle problems have been fixed.

A few words about the problems of Riot.js

All this of course is wonderful, but if I don’t talk about the problems that you may encounter while working with this library, I won’t be truthful enough with you. Like it or not, Riot.js is slower than its competitors (the only thing is that version 3.0 seems to be more productive, and the second branch of the library is checked in these tests. You should also keep in mind that the Riot.js team is currently aiming to increase the rendering speed components and considers it their goal for the near future).

Where can this cause problems? Well, let's say, we have problems with the server rendering of a single module in which we have 5-6 levels of nesting of components on the project we are developing here. So it is necessary, otherwise it is impossible to write this module. Our server on the Digital Ocean rendered this module for about 20-30 seconds per request. This is very much. But to buy some dedicated server on Hetzner only to solve this problem, somehow did not want to. As a result, we rewrote this particular component into React.js, after which the server rendering of this component began to work out in 5-10 seconds, which is already an acceptable option for us at the moment (we use server rendering only for search bots, so the usual users do not wait 5-10 seconds before the start of the page, for them the content is simply rendered in their browsers).

At the same time, if we talk about performance further, then I have been looking in the direction of Inferno for a long time: look again at the library performance table . This library almost goes one to one with tests based on vanilla JS. To be honest, this is really impressive. Perhaps try to write complex interfaces on it? Among other things, its obvious advantage is the almost complete compatibility of its API with React.js. That is, to start working with Inferno, you do not have to learn anything if you already know React.

I would also like to note that React may be more preferable to choose if you are going to write an isomorphic application that will render content to clients from the server, as it allows you to render content on the server using the renderToString method, thanks to which your React component is on the side the browser will only hang its event listeners on the DOM created by the server, relieving the user's browser of additional load, which Riot.js does not currently support: you can render your content from the server side, but it ce the same then will be re-rendered library also on the browser side.

As we found out, Riot.js is slower on complex components with more nesting levels. But agree, we do not often write web interfaces of such complexity?

Although we rewrote one module of our project on React.js, I still consider Riot.js a priority library for developing frontend components. The reason is that it provides a simpler and more concise syntax. It contains a very small set of functions, but at the same time there are as many of them as needed. Riot.js does not clog my head with complex abstractions, rules, restrictions and other avian language. It just gives me a clean API to solve my problems. And what should I need more in my work?