Stimulus 1.0: the humble JavaScript framework for HTML that you already have
- Transfer
From a translator: David Heinemeyer Hansson wrote a short text about why he and his Ruby on Rails team developed their own Javascript framework. The original text is placed in the repository of the new project
updated February 4 : The original article was officially published on the Basecamp blog. Updated link to original and title
We write a lot of Javascript in Basecamp , but we do not use it to create "JavaScript applications" in the modern sense. All our applications render server-side HTML, then we add javascript splashes to bring them to life.
This is the path of the majestic monolith . Basecamp runs on many platforms, including native mobile applications, with a single set of controllers, views, and models created under Ruby on Rails. Having a common interface that is updated from a single place is the key to ensuring that the small team works well, despite the many supported platforms.
This allows us to be productive, as in the good old days. Returning to the days when a single programmer could make considerable progress without getting stuck in layers of abstractions of distributed systems. The time before everyone began to think that the holy grail is limiting the server side to just producing JSON for Javascript applications on the client.
This does not mean that there is no point in such an approach for some people in some place. But as the main approach to many types of applications, and of course, such as Basecamp, this is generally a regression in terms of simplicity and productivity.
Also, this does not mean that the distribution of one-page JavaScript applications did not bring any benefit. They brought speed, more dynamic interfaces and freedom from reloading the entire page.
We also wanted such a feeling for Basecamp. To make it look as if we followed the herd feeling and rewrote everything with client rendering or switched to fully native applications on mobile.
This desire led us to a double solution: Turbolinks and Stimulus.
Turbolinks up, Stimulus down
Before I move on to Stimulus, our humble JavaScript framework, let me briefly recount the purpose of Turbolinks.
Turbolinks comes from the so-called pjax developed at GitHub. The basic idea remains the same. The reason that a full page reload seems slow is not that it is hard for the browser to process the HTML sent from the server. Browsers are really good and fast at that. The fact that usually HTML content is larger than similar JSON is also unimportant (especially considering gzip). No, the main reason is that CSS and Javascript must be reinitialized and reapplied to the page. Regardless of whether the files are cached. This can be slow if you have decent CSS and JavaScript size.
To get around this reinitialization, Turbolinks keeps the process constant, just as single-page applications do this. But, basically, this is an invisible process. It catches links and loads new pages via Ajax. The server still returns full HTML documents.
This strategy alone can make most of the actions in applications really fast (if the server is able to respond for 100-200ms, which is possible with caching). For Basecamp, this accelerated page navigation by 3 times. This gives the application the very feeling of responsiveness and dynamism that was most of the pros for single-page applications.
But Turbolinks is only half the story. Below the level of full page change are minor updates within a single page. Showing and hiding elements, copying to the clipboard, adding a new entry to the todo list and other interactions that we do in modern web applications.
Before Stimulus, Basecamp used a mixture of different styles and patterns to add these features. Part of the code was just in jQuery, a similar in size part was in vanilla JavaScript and a somewhat large object-oriented system. They all worked together through explicit event handling, relying on data-behavior attributes.
It was easy to add a new code like this, but it was not a complete solution and we had several existing home-made styles and patterns in parallel. This made it difficult to reuse the code and teach new developers some sort of unified approach.
Three core concepts at Stimulus
Stimulus wraps the best of these patterns into a modest little framework that revolves around three basic concepts: controllers, actions, and targets.
It is designed to progressively improve the HTML for which it is intended. So that you can take a simple template and see what behavior affects it. Here is an example:
PIN: You can read this and get a pretty good idea of what is going on. Even without knowing anything about Stimulus and looking at the code of the controller itself. It is almost like pseudo code. This is very different from reading a piece of HTML, which has an external JavaScript file hanging event handlers here. It also provides entity separation lost in many modern JavaScript frameworks.
As you can see, Stimulus is not worried about creating HTML. Rather, it hooks itself onto the current HTML document. And HTML in most cases is rendered on the server either by loading the page (first call), or through an Ajax request that changes the DOM.
Stimulus is focused on manipulating an existing HTML document. Sometimes this means adding a CSS class that hides, animates, or highlights an element. Sometimes this means rearranging elements in groups. Sometimes it means manipulating the content of an element, for example, converting UTC time, which is cached with the content, to local, shown to the user.
In these cases, you want Stimulus to create new DOM elements, and you are definitely free to do so. Maybe in the future we will even add some sugar to make it easier. But these are secondary scenarios. The main focus is on manipulating, not creating elements.
How Stimulus differs from mainstream JavaScript frameworks
This makes Stimulus very different from most modern JavaScript frameworks. Almost all of them focus on turning JSON into DOM elements through some kind of template language. Most use these frameworks to give birth to a blank page filled exclusively with elements created through JSON-to-template rendering.
Stimulus is also different in state matters. Most frameworks have ways to maintain state inside JavaScript objects, and then render HTML based on that state. Stimulus is the exact opposite. The state is stored in HTML so that controllers can be thrown out between page changes, but they are reinitialized as soon as the cached HTML reappears.
This is a significantly different paradigm. I am sure many experienced JavaScript developers who have worked with modern frameworks will mock. But no, leave me alone. If you are happy with the complexity and efforts that are required to keep the app in a whirlpool, say, React + Redux, then Turbolinks + Stimulus will not appeal to you.
But on the other hand, if you have a feeling that the thing you are working on does not require the level of complexity and separation of applications that are implied in modern technologies, then you are likely to find salvation in our approach.
Stimulus and related ideas from the real world
At Basecamp, we have been using this architecture on several versions of Basecamp and other applications for several years. GitHub used a similar approach with a wonderful effect. This is not just an alternative to mainstream understanding of what a modern web application looks like, but also surprisingly competitive.
In fact, it looks like the secret ingredient we had in Basecamp when we did Ruby on Rails. The feeling that modern popular approaches are overly straightforward, so we can do more with less.
Moreover, you do not even need to choose. Stimulus and Turbolinks work great in conjunction with other heavier approaches. If 80% of your application does not fit into a complex installation, try our two-component build for this. Then deploy heavy equipment for the part of the application where you really benefit from it.
In Basecamp, we make use of several more complex approaches where necessary. Our calendaring functionality uses client-side rendering. Our text editor, Trix, is a fully assembled word processor that doesn't make sense like a bunch of Stimulus controllers.
This set of alternative weight loss frameworks is as much as possible. To stay within the request-response paradigm for most interactions that work just fine with this simple model. Then we turn to expensive tools, where it makes sense to achieve maximum effect.
First of all, this is a set of tools for small teams who want to compete in coverage with larger teams using more labor-intensive, mainstream approaches.
Give him a chance!