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).
Sockpuppet
Drawbacks this approach is bad at
- You may incur high infra costs
- It May not even be suitable for high user traffic
- Not good at animations (use CSS)
- Might taint your business logic
Resources
Thanks for listening!
Stateful Web
By Kalil De Lima
