The web was originally envisioned as a collection of documents linked together. Each time you clicked a link, it would load a new document. Rails was built with this in mind, so if you've done any beginner tutorials, this should be the approach you'd be most familiar with.
In this setup, routing is handled by the backend - Rails decides which pages to serve based on the requested URL e.g. in the above example, we might have set
/videos/cats to route to a
VideosController, which will render a
- sprinkles of on-page interactivity e.g. hiding or showing in accordions
- partial page replacement, mainly via a technique known as AJAX, to make interactions feel speedier and more app-like
Example libraries that can work in this paradigm include JQuery, Stimulus, React or VueJS.
- the framework handles and simulates "routing" as well. The TLDR; is that it decides what to render for
- it makes the required AJAX calls to our Rails backend (e.g.
/api/videos/) based on what's being rendered, retrieving data as JSON. This is somewhat similar to our Rails controllers extracting data from a model.
- based on the JSON data, the framework will create, replace or delete HTML elements on the fly, making for a very fluid experience. A close parallel in Rails would be the rendering of data in views.
For the most part, Rails is "API-only" - we may not even need the Asset Pipeline! This might sound antithetical what Rails is ("everything you need to build fantastic applications"), but as with anything in technology, there are tradeoffs that make this worth considering:
- The greater separation of frontend and backend in SPA setups lead to increased complexity, but also allows for a separate frontend and backend team that move individually.
- SPA frameworks offer a more "declarative" programming paradigm, making it easier to create complex interactions, at the cost of a steeper learning curve.
- SPA frameworks generally enable more fluid web-apps as you'd potentially make smaller JSON-only requests and never need to load full pages (at least after the first), though Rails has a few tricks up it's sleeve to close this gap.
If you're new to Rails and web development, I'd humbly suggest to lean toward a "multi-page" setup. You'd have less complexity to maintain and a gentler learning curve. SPAs can come later (in fact, you might not even need to host your own backend to work with an SPA).
We'll take a look at different options for "multi-page" apps in the next post. You can follow me on Twitter to be the first to know when it's ready.