A case for Turbolinks, Stimulus and React

Single page apps are pretty cool. I like them a lot and they are fun to create.
However, they can get quite heavy in terms of code size, and loading time. You also have to jump through many hoops to get server side rendering. These things can be worth the time an effort, but not always.

I think there is a case to be made for a many tool solution.
That is:

• Turbolinks
• Stimulus
• React

Here's what are transitioning to at DropConfig.

We have a lot of pages that just list things. List your organizations, list your repos, list your configs. Why are we bringing the big guns to bear on this? Why bloat a simple listing page with as much react as possible? Previously I'd have to drag in React, and Redux as well as Material-UI. It's a lot of things for a simple listing page.
This is where Stimulus and Turbolinks come in handy.

Turbolinks

On our backend, in node, we use ejs to render listing pages.
The server just returns plain HTML. We then rely on Turbolinks to make the page loads feel more like an SPA. But we never send anything from our Server but plain HTML. This keeps our pages really light and they render fast!

There's a few big wins, in my opinion, in writing plain HTML templates

• Making a simple HTML template on your server where the data already lives is far easier than doing it in React.
  • No calls to fetch JSON and loading states.
  • No Redux for state management etc.
  • The same JSON REST APIs we make can we used to render the templates server side.
• Better battery life and speed on mobile because we aren't running nearly the same amount of JavaScript.
• If a user doesn't have JavaScript enabled they can still view parts of our site.

Stimulus

Stimulus is used for mundane operations on the DOM. Things like menu toggles, modals, etc. It's a really nice and simple too for such things. It's worth a look at least. Basecamp uses it. (And Turbolinks)

React

So where does React come in? Well we have a configuration editor. It has a lot of data and a lot of moving parts. That would be tough to do with Stimulus and Turbolinks so we rely on React to handle it for us. With the ease of code splitting in modern tools like webpack, the user doesnt have to download all that extra bulk until they want to edit a configuration.

In case you don't think there is any precedent for this, consider GitHub. This is more or less how their entire frontend functions. While I don't think they use stimulus and I know they use pjax instead of Turbolinks, it is the same sort of concepts.

Side note: Check out Tailwind CSS it fucking rocks. Maybe I'll write about it someday.

Thanks for listening to me ramble.

Feel free to ask me any questions. I know some things about some other things.

Check out DropConfig you might like it.

Comments

[rhymes]

I really want to explore Turbolinks + Stimulus for server side rendered web apps. Thanks for the nudge!

React (or similar alternatives) used in specific pages make sense!

I wish more people stopped to consider more what they want to achieve instead of diving in SPAs from day zero :)

Thanks for the article Clay!

[Clay Murray]

Totally we started out doing an SPA. But it was megabytes of content to download each page. And if there was an error in our JS then nothing renders at all! I love this method for the robustness of it. If my stimulus has an error. The page still loads and the user can at least see something.