New front-end libraries at React peripherals
Today we wanted to offer you an interesting text about how the front-end is developing in our time, or rather, according to the author, after React. Probably, the post could be more voluminous, so if the author writes a sequel, we will also try not to miss and translate. Welcome to cat!
Having barely appeared, React immediately changed the rules of the game. He ushered in a new era in client-side development. Its unidirectional data stream, JSX, and declarative way of defining representations were just crazy. React quickly gained immense popularity, and even today, 6 years later, it remains one of the most popular frontend libraries.
However, the front-end ecosystem is developing rapidly; a lot of interesting projects are being developed in this area. I am constantly looking for the next technology that will once again change the rules of the game. I like it when yesterday’s outsider goes into aces, completely undermining our usual approaches to work – as React did 6 years ago.
The joy of finding a new technology that helps you become more productive than ever before is priceless. It is very important to study what else besides React exists around, even if you consider yourself to be a React specialist. A good developer chooses the tools necessary to solve the problem. He must know many paradigms, languages and tools.
Recently, I did some research, experimented and found some really interesting libraries and new web standards that, in my opinion, have potential. Everything that I will talk about in this post is available for use in production today. These technologies cannot be called a “front line”, but so far they have not received wide distribution.
Svelte
Let's start with completely new frameworks that inculcate new ways of thinking, rather than transforming something that already exists. This is Svelte. This is a new paradigm in the client ecosystem.
So why is Svelte unique? Mostly for two reasons. First, insanely small packages are created in it, because the runtime environment is not included in them. Svelte advocates call this a “zero execution environment." The React runtime weighs about 100 kb, and this amount is added in excess of the package of each React application.
The second important strength of Svelte is its syntax. It is so minimal, as if there was no syntax at all. We will come back to this.
Svelte borrows a lot from React and Vue. If you have experience with React, you already know a lot, and you will hardly need time to master Svelte.
Let's look at some code to give an impression of Svelte.
To define a new component, a new file is created and the name of this file will be the name of the component. This file will have an optional script section, an optional styles section and, importantly, the HTML template itself. Svelte does not use JSX, but uses its own template language.
The counter is {counter}
A bit like Vue, but simpler.
The syntax … and there is no particular syntax, it is just pure JavaScript. Want to set a status? Just increase the variable counter.
Not this.setState. No hooks useState. Just javascript. With such small examples, it is difficult to evaluate all the minimal syntax. I programmed this for several hours, and it turned out superproductively, because to solve the problem I had to write so much less code. It seemed to me like I was running, and someone else was pushing me in the back. Like I'm cheating. Such minimalistic syntax is a decision made by the creators of Svelte quite consciously. They themselves explain in a post Write less code why. Here is a great quote from this article:
… with an increase in the code base, the time to develop a project and the number of bugs increase quadratically, rather than linearly. – Write less code
The most important component of a web framework is its documentation. React is famous for its wonderful documentation, many learn it only on the docks. Svelte's documentation is also really good, as far as I can see. As a newcomer to Svelte, I like the examples in the documentation for this framework most of all:
In many cases, I roughly know what I need. For example, change the state of a component, add event handlers, get some global status (as in Redux). Next I need to quickly see how this is done. The examples section is an example of this kind. I don’t have to google articles on any blogs or watch listings on Github. Just browse the section you want. The beauty!
There is even something similar to Gatsby and Next.js. The thing is called Sapper, you start coding on it very quickly. Allows you to create single-page applications with static generated HTML pages, which is what Gatsby / Next.js resembles.
Svelte also has an alternative to Redux, called stores. They are incredibly minimalistic. The storage is created like this:
import {writable} from 'svelte / store';
export const count = writable (0);Then the repository can be updated like this.
count.set (0);There is no stereotypical code at all, and all this feature is completely built into Svelte – no additional dependencies. Now remember how much trouble with the addition of Redux in the React project.
How does the React team relate to Svelte?
The React team is not as enthusiastic about Svelte as I am. They believe that the performance improvement associated with abandoning the runtime environment is negligible. Only in very specific cases, for example, when working with built-in widgets, etc. such a game is worth the candle. In addition, we also have Gatsby and Next, therefore, according to the React community, a slight increase in speed means even less (sorry, I don’t remember where I read it. If you find me, let me know on Twitter, I @karljakoblind). In this case, I argue that any speed improvement matters, and brushing off the 100 kb savings on each package just because “it’s only useful with widgets” is a bad argument. To make the web great and affordable, we must do all sorts of performance optimizations that we can. If you have ever been involved in fine-tuning an application to improve its performance, then you know how much even the smallest improvements mean. It is the sum of all the small improvements that add up to a super-fast download, which happens like magic.
So, should I try Svelte?
Next time, when I start a project that would work well on React, I will seriously think about whether to use Svelte instead. Studying Svelte, I was surprised how productive this framework is, even if you don't read the documentation. All I did was work through examples and practice a little with Sapper – and still it seemed to me that the work was more productive than with React. I think such a high productivity is somehow related to the minimalist syntax. It is also very valuable that, without any additional work, we get such compact packages. Applications that load quickly are very popular with both our users and Google!
Does Svelte have any flaws? Honestly, only one comes to mind. The fact is that Svelte is still new and not very widely used. Therefore, his community is limited, and, perhaps even more important, there are not so many (yet?) Companies that need Svelte specialists. If you are a junior developer and are looking for work, then I think it’s wiser to learn React first. However, if you are a senior developer (or a junior, and you have a lot of time), I strongly recommend looking at Svelte.
More details
svelte.dev – official site
Video: Rich Harris – Rethinking reactivitity
Web components
Maybe web components are the next great technology? I think she definitely has potential. So what are web components?
Web Components are a set of w3c standards for creating new custom HTML tags. Using these standards, you can create anything from widgets to large applications.
And in most major browsers, this new standard is supported:
In Internet Explorer, such features are supported by polyfills.
By creating a web component, you are creating a new native DOM element. The situation is not like in React, where a “virtual DOM element” is created, which is subsequently implemented in the DOM.
The nicest aspect of Svelte was that it cleans up the runtime environment, and the same goes for web components. When creating a native DOM element, you do not need a runtime environment; a normal browser is enough to launch the application.
Since these are just DOM elements, any web page can use them. You can create widgets or entire applications that will then be embedded in existing applications. It doesn’t matter what you program on – Angular, React, Vue or something completely different. This is about the most common DOM elements, such as a tag .
This opens up completely new opportunities and new approaches to the architecture of large offers for the client side. One example of this is microfronts.
You can write web components directly, but from a development point of view, this is not a good practice. Better to use a framework that compiles to the level of web components. Two popular frameworks of this kind are Stencil.js and Polymer (from Google).
When using web components, their packages are very compact, since there is no runtime environment. Take a look at the following benchmarks:
Have you noticed the Svelte mentioned in this list? Svelte can compile to the component level, and the package it generates is very small.
However, it’s even more interesting to take a look at how smaller all the packages of web component frameworks are compared to packages of “classic” frameworks, for example, React and Angular.
What about web components in React?
Although React can also compile to web components, it does not support them, according to custom-elements-everywhere.com.
However, full support may follow; perhaps the React team is just about to take this step, only having thought it through properly before launching it. One of the reasons for this evasion is that web components use an imperative style, rather than a declarative one, as in React. Maybe someday in React full support for web components will appear, or maybe not. In the meantime, if you intend to create web components, use a different library instead of React.
Should I use web components?
It seems to me that web components are most useful when you use them in the microfront architecture. If you work in a large organization, where many teams operate at once, using different client libraries, then working together on code in different teams can be a nontrivial task. In this case, the approach to working is different than with React. React specializes in orchestrating an entire application, rather than creating widgets. As you can see, React and web components can coexist peacefully with each other.
Web components have about the same disadvantages as Svelte. If you are typesetting a resume when you are about to get a job, then web components cannot be called a priority. At a minimum, no priority over React. My experience suggests that companies are not so demanding (yet?).
Final thoughts
In the development of the frontend, a lot of everything cool and interesting is going on. React is just one of the frameworks, and you just need to navigate what is going on outside it.
If you are a senior developer and specialize in front-end, then, of course, you select the best tools for work. This is often React, but perhaps web components are better for your next project.
