Javascript has become an integral part of modern websites, allowing developers to create interactive, app-like experiences. While the ecosystem has seen some consolidation over the years, there are still quite a few choices you could make. Let's talk about two typical approaches for Rails: "multi-page" and single-page apps.
The "Multi-Page" App
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 videos/index.html.erb view.
Javascript plays two main roles:
- 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.
Single Page Apps (SPAs)
SPAs are a pretty radical departure from the multi-page paradigm. They essentially take partial page replacement to the extreme - the Javascript framework handles almost everything. Let's look at an example setup:
In the above example, we host our frontend on a separate server. When someone enters a URL, our frontend server will return a single page, and the Javascript takes over:
- the framework handles and simulates "routing" as well. The TLDR; is that it decides what to render for
/videos/cats. - 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.
Examples of SPA frameworks include React (with some companion libraries), VueJS, EmberJS and AngularJS. React and VueJS are repeated here because they can operate in both paradigms: as "sprinkled" Javascript, or as a full framework.
So, what to choose?
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.
Top comments (1)
Very well-explained topic, specially the asset pipeline part.
Other important opinion that you mentioned that I totally agree: Not every case will need a SPA.
I see people "building ferraris to cross the street"