Stateful Web

kalil@rootstrap.com

github.com/kaozdl

bruno.vezoli@rootstrap.com

github.com/brunvez

The Begginings

In the early days, web pages were mostly static sites that displayed static content.
People coded HTML directly

and what they wrote was the final result that the user got to see when it enters the page

Server Side Rendering

To allow more interactivity we switched the paradigm to server side rendering.
Now templates for websites were written with other languages embedded in HTML.

The server processed this and it showed the user the site.

Enter JQuery

JavaScript initially thought for adding some logic to styles, began the process of becoming what it is today.
JQuery introduced techniques like Ajax

Allowing to partially reload pages to create more interactive experiences

Rise of the SPA

This caused an huge paradigm shift.
Sites switched from being multiple server generated pages, to a being a single page that consumed data from an API after years of competing frameworks today we have React.js, Vue.js, Angular and Ember as examples of this.

SPA Drawbacks

Major Drawbacks

Tons of megabytes of JS sent to the client
Site needs to load lots of JavaScript before being interactive
Arbitrary separation between front-end and back-end
Requires more developers
Longer development times due to api design overhead
It's difficult for third parties to scrap your site (hurting SEO)

JS Fatigue

Most of these are a must today, but, how many do you need?

The web keeps evolving

Websockets

Persistent connections
Servers can push info to clients
Server can keep track of clients
Servers are aware of the state of the clients

We can centralize the state of an application on the backend and send HTML updates to the frontend trough an open connection to have a web app that looks almost like a native one

Chris McCord

Enter LiveView

The Idea

Use only a small ammount of JS
Render most of the site on the server instead of the client
Update the HTML in the server and patch the dom via websockets

This Idea took off

Stimulus Reflex

Stimulus JS

Stimulus is a JavaScript framework with modest ambitions. Unlike other front-end frameworks, Stimulus is designed to enhance static or server-rendered HTML—the “HTML you already have”—by connecting JavaScript objects to elements on the page using simple annotations.

These JavaScript objects are called controllers, and Stimulus continuously monitors the page waiting for HTML data-controller attributes to appear. For each attribute, Stimulus looks at the attribute’s value to find a corresponding controller class, creates a new instance of that class, and connects it to the element.

With the basics covered let's get back on track

Stimulus Reflex

We extend the capabilities of both Rails and Stimulus by intercepting user interactions and passing them to Rails over real-time websockets. These interactions are processed by Reflex actions that change application state. The current page is quickly re-rendered and the changes are sent to the client using CableReady. The page is then morphed to reflect the new application state. This entire round-trip allows us to update the UI in 20-30ms without flicker or expensive page loads.

With StimulusReflex, small teams can do big things faster than ever before. We invite you to explore a fresh alternative to the Single Page App (SPA).