Single Page Applications (SPA)
Frontendless Rails frontend
Edit
#ruby-on-rails
#hotwire
#stimulus-js
#turbo
#viewcomponent
#single-page-applications-spa
Summarized using AI

Frontendless Rails frontend

Vladimir Dementyev • April 12, 2021 • online

In this presentation titled "Frontendless Rails frontend," Vladimir Dementyev explores the evolution of web development, particularly focusing on the capabilities of Ruby on Rails (Rails) as a comprehensive framework for building modern web applications. He discusses how, over the years, web development has shifted from a full-stack approach where developers utilized HTML, Ruby, and JavaScript seamlessly within Rails, to a more segmented approach involving separate front-end frameworks and back-end services.

Key Points Discussed:
- Nostalgia for Full Stack Development: Vladimir shares his experiences working with Rails a decade ago, highlighting the simplicity and productivity of full stack development where one could build applications without extensive knowledge of front-end libraries.
- HTML Over The Wire: He describes the core principle of Rails full stack development as prioritizing server-rendered HTML, suggesting that the server is the sole truth, thus unifying the development ecosystem within Rails.
- Evolution of the Frontend Ecosystem: The talk covers the evolution from simple AJAX and jQuery to modern front-end architectures dominated by frameworks like React and Angular. He emphasizes the transitions in JavaScript tooling, including npm and webpack, that have changed the building of web applications.
- New Developments in Rails: Dmitry introduces newer technologies like Hotwire, Turbo Drive, and Stimulus JS that combine to support the HTML over the wire approach, allowing developers to create fast, server-rendered applications without relying heavily on client-side JavaScript.
- Example Applications of Turbo: He illustrates the usage of Turbo Drive and Turbo Frames, which enhance user experience by replacing or reloading parts of the webpage instead of the entire page, optimizing both server and client interactions.
- Stimulus JS as a Companion Tool: The effectiveness of Stimulus JS in managing interactivity within Rails applications is explained. Utilizing data attributes to control behavior streamlines development and reduces dependency on larger frameworks.
- Reactive Programming with Websockets: The idea of pushing updates to clients without client-side state management is introduced through looks at libraries like CableReady and Stimulus Reflex, which allow real-time updates through websockets and HTML over the wire.
- Organizing HTML Templates: Dmitry stresses the importance of organization within HTML templates, suggesting the use of view components to manage Rails applications like front-end components, thereby improving maintainability and testing.
- CSS Solutions: He discusses modern CSS frameworks, recommending Tailwind CSS and others to integrate seamlessly with Ruby on Rails applications to advance productivity in style management.

In conclusion, Vladimir asserts that the new era of Rails full stack development is upon us, emphasizing that developers can build dynamic, interactive web applications primarily using Rails, thereby reclaiming the productivity that characterized early Rails development. He invites the audience to embrace these innovations for a renaissance in Rails development, unshackling from compartmentalized workflows.

Frontendless Rails frontend
Vladimir Dementyev • April 12, 2021 • online

Everything is cyclical, and web development is not an exception: ten years ago, we enjoyed developing Rails apps using HTML forms, a bit of AJAX, and jQuery—our productivity had no end! As interfaces gradually became more sophisticated, the "classic" approach began to give way to frontend frameworks, pushing Ruby into an API provider's role.

The situation started to change; the "new wave" is coming, and ViewComponent, StimulusReflex, and Hotwire are riding the crest.

In this talk, I'd like to demonstrate how we can develop modern "frontend" applications in the New Rails Way.

RailsConf 2021

00:00:05.339 Hey everyone, welcome to my RailsConf talk called "Frontendless Rails Frontend." My name is Vladimir, and I work for a company called Evil Martians.
00:00:11.820 As a backend engineer, at least from the legal point of view, I’m mostly working with Ruby and a bit of Golang these days. I’m not dealing with front-end at work at all because web development today has a clear separation between backend and frontend engineers. Everyone does their job and does it well, but that’s what we have today.
00:00:27.599 Most of you, I think, might remember that ten or even five years ago, when I started working on Ruby on Rails projects, I was involved in everything: HTML, Ruby, JavaScript. Oh, actually CoffeeScript. I was able to build a product alone; I didn't need anyone else. I miss those times a little bit.
00:01:00.000 Today, I'd like to raise and try to answer the following question: could Rails full stack development be a thing in the 2020s? Let’s start with another question: what is full stack?
00:01:19.500 One definition is that there is a single person who can do everything, but I doubt that's a correct definition for full stack development. Instead, I'd like to say that full stack development is when you develop within a single ecosystem, and in our case, that ecosystem is Rails.
00:01:36.720 Let’s take a quick look at the past and remind ourselves how our ecosystem looked like when we were building Rails applications without needing to learn front-end frameworks and all that modern stuff. Also, let’s explore what happened to that way of building web applications.
00:02:00.780 First of all, the core principle of Rails full stack development is "HTML Over The Wire." The server is the only source of truth and is responsible for what end users see—so it’s power to the server. That’s how we can describe this way of building layers of web applications.
00:02:17.280 So let’s take a look at what tools we used to build the front-end part of our apps. First of all, we had HTML preprocessors to make it easier to write HTML, and we used Ruby helpers to craft HTML using Ruby code. Do you remember helpers? Something like that? Can you figure out what’s going on here? I can’t because, well... I don’t understand what’s written. Hopefully, we no longer write such things nowadays; at least we don’t have to.
00:02:51.300 Then, we added a bit of interaction by writing some JavaScript, or more precisely, CoffeeScript, because it was kind of JavaScript for Rubyists. We usually used jQuery and some plugins, for example, to handle AJAX requests and obtrusive JavaScript, which made it simple to turn links and forms into asynchronous communication tools—like performing an AJAX request instead of reloading pages.
00:03:27.599 We were also able to execute JavaScript in response to events, which felt like some kind of magic that Rails provided. Then we had Turbolinks, but no one knew how to use them properly except for perhaps Basecamp. As for styles, we used Sass to manage styles because it was much more Ruby-friendly than plain CSS.
00:04:14.099 Finally, we used Bootstrap to make all websites look alike, managing dependencies by installing gems using our good old Bundler. I’d simply put scripts into the vendor/assets folder. At the top of this iceberg, we had the asset pipeline and, more precisely, the Sprockets library, to take care of all this stuff: to build them together, optimize them, and minimize whatever was necessary. Those asset pipelines were the best for this job among all web frameworks, not just Ruby frameworks.
00:05:01.759 But things have changed. JavaScript ecosystems evolved, and the evolution began. First, npm appeared, and later Yarn, solving the problem of managing dependencies. Then JavaScript standards, such as ECMAScript, evolved to newer versions and made CoffeeScript less relevant. Webpack took asset compilation to the next level, and various tools built on top of it changed the way we write CSS, making it more powerful.
00:05:47.880 After that, front-end frameworks appeared, and React won the battle among them, becoming the number one even today. Finally, most applications transitioned into single-page applications, leaving Rails with the single responsibility of providing APIs. That’s where we are today: we have separate teams, larger development costs in terms of both time and money. That’s something we’d like to change—bringing back our Rails comfort zone.
00:06:56.100 And the question is whether it’s possible at all. Of course, it is, because we have examples like GitHub and Basecamp. They’ve been following the classic Rails way for many years. You might say those two are too old and too big to migrate to a modern front-end stack and that it would be too expensive for them. I get it.
00:07:34.560 But what about something that was just released about a year ago? Hey, we can use Rails as a core stack with just a couple of things to build the modern client-side experience. This new magic is called Hotwire, which brings the HTML-over-the-wire approach to the next level.
00:08:10.740 However, I'm not going to discuss Hotwire today because we have three or maybe four talks dedicated to it in the program, and even one workshop. Instead, I wrote a blog post that you can check later if you want to know my thoughts about Hotwire. So let’s move to the main part of the talk.
00:08:34.920 What I want to show is how the HTML-over-the-wire approach could evolve with modern front-end technologies. Let’s consider the scale on both sides and start with the core principles: who is responsible for rendering the UI? The server or the client?
00:09:01.340 One approach might be better than the other, but they are just two ways of doing the same thing and they're equally viable. Then we have single-page applications on the right—this is how most front-end-based applications are built.
00:09:28.440 How can we counter this? Turbolinks, or as we call it today, Turbo Drive, is the answer. Let’s recall what Turbolinks (or Turbo Drive) is. Turbo Drive allows for converting any HTML-based application into a single-page application by intercepting navigation events like link clicks and form submissions. Instead of reloading the page, it performs an AJAX request and replaces only the body with the response.
00:10:11.100 Now, scripts and styles are not reloaded for every navigation event, which makes loading pages faster, and it also keeps track of its own cache to enhance perceived performance for the end user.
00:10:55.200 Turbo Frames is the latest addition to the Turbo ecosystem in Hotwire, allowing us to reload just part of a page instead of the whole thing, which speeds up the first rendering. Let’s look at an example of using Turbo Frames—here we can see a to-do list app with items and the ability to mark them as completed or delete them, built with Turbo Frames and no JavaScript.
00:11:41.160 At the controller level, we only need to render partials instead of templates, and we wrap the contents in a special Turbo Frame tag with a unique identifier. This allows Turbo Frame JavaScript to replace the content of the element currently on the page or remove it completely if the contents of the Turbo Frame are empty. That’s it—just a couple of minor changes, and we can write interactive applications with no JavaScript!
00:13:00.120 Next, we have front-end frameworks that bring a lot of interactivity, reactivity, architecture patterns, concepts, and conventions. However, with only HTML and an HTML-first approach, we can add only simple JavaScript functionalities to enhance our HTML, like mentioned obtrusive JavaScript, but it is limited in functionality.
00:13:47.379 We need something more, and that’s where Stimulus comes in. Let’s talk a bit about Stimulus JS and why it’s a good companion for Rails development. For example, if we have hideable banners in the application that show tips to our users, the user can close them by clicking on the corresponding button. A decade ago, we’d have used jQuery to write this functionality, dealing with unrelated events and CSS classes, along with libraries like Turbolinks and jQuery UJS to ensure patterns worked properly.
00:14:40.579 However, with Stimulus, we focus only on what matters. Our JavaScript code is concise; we just need one function to implement the removal of the element, and everything else is controlled by the HTML using data attributes to activate this functionality in Stimulus.
00:15:50.100 The main benefit of Stimulus is its usage of modern browser APIs, such as the Mutation Observer API, which eliminates the need for tracking changes like we had to with jQuery and Turbolinks. Stimulus plays well with the server because you don't have to worry about any hacks to track loading or reloading. It allows you to attach behavior to an HTML element, turning it into a component. You implement the behavior itself in JavaScript by writing a controller.
00:16:39.000 Now, imagine building something more complex like a date picker or a search autocomplete input. We can write such components from scratch using JavaScript, but that would turn us into JavaScript developers. Alternatively, we can borrow existing components from some framework, such as React or Vue, and wrap them using Stimulus locally, thereby isolating everything.
00:17:43.200 For one of the projects, I started using Stimulus for interactive forms with dynamic fields, and I chose to use Vue for that and employed Stimulus to manage the mounting of Vue components into the HTML. The server still handles rendering and crafting HTML, and we continue utilizing Rails form helpers; we only add data attributes to activate them.
00:18:52.020 In this instance, the view component remains isolated. We do not introduce any state management or complex operations into our client-side code, keeping it simple. Stimulus simply helps manage external components' lifecycle. You can find a complete example in the open-source demo project we published to showcase this approach.
00:19:56.220 Let’s take a quick break.
00:20:00.000 I think I just talked too much JavaScript for a moment, so let’s go back to HTML and Ruby and our scale. The next thing is reactivity. Let’s define reactivity as an application's ability to react instantly to various events—both internal actions from users and external stimuli from the system.
00:21:07.740 In other words, users don’t need to hit the reload button to see the latest state of the data. How can we accomplish this without keeping state on the client when everything is on the server? We can push changes to clients through WebSockets.
00:21:59.880 Here, we can introduce an evolution of the HTML-over-the-wire approach, which is HTML over WebSocket. I’ll mention Phoenix LiveView, which popularized HTML over WebSocket, inspiring others to create similar solutions.
00:22:37.440 I won’t go into detail about how LiveView works; I've put the main ideas on the slide, so feel free to check them later. Let’s move on to projects inspired by it within the Ruby and Rails worlds. One such project is Stimulus Reflex.
00:23:09.420 Technically, Stimulus Reflex is a bit older than LiveView and its core part, CableReady, has been around for over three years. However, only after LiveView appeared and garnered hype did the development behind Stimulus Reflex get some momentum.
00:24:16.440 Let’s first look at CableReady: it's a small, single-purpose library that helps send HTML or DOM manipulation instructions from the server to the browser, enabling remote DOM manipulation controlled by the server. It reduces the actions Cable offers as a transfer and marks the DOM library on the client-side to update HTML as efficiently as possible.
00:25:22.620 For example, in our to-do list app, when we want to delete an item, there are no changes required in the HTML part of the application. We still use our remote call by clicking the delete button, but instead of returning HTML in our response, we broadcast a remove command to the corresponding stream with a specified selector for the current item.
00:26:11.220 This command could actually be expressed as a jQuery example from ten years ago. So, removing an object query requires no JavaScript; everything is done through CableReady. It not only supports removal but also over thirty commands, allowing extensive client-side manipulations to be executed from the server.
00:26:50.220 Now let’s look at Stimulus Reflex. It consists of two parts: Reflexes, which describe how to handle user actions, and CableReady to deliver HTML and commands, updating the DOM. The whole architecture can seem a bit complicated, so I recommend taking a look at an example. Again, our example stays consistent, but now it updates in real-time for all users—to make it reactive.
00:27:21.840 With the HTML, we only need to add data-reflex attributes, which resembles what we did with Stimulus. As indicated by the name, Stimulus Reflex uses Stimulus internally to activate reflexes, rendering the reflex attributes actionable. We need to write a class—in our case, the list reflex—implementing the corresponding methods.
00:28:41.400 Each method can perform multiple tasks. For instance, we can use CableReady as before and send custom modification commands responding specifically to the current user. In the example, we show the flash notification by broadcasting a partial HTML with a selector to replace contents. The community around Stimulus Reflex is majorly stable, well-documented, and very welcoming.
00:29:31.200 I find it a joy to work with and the people behind it. Moreover, it works seamlessly with any cable, which adds to its appeal. Stimulus Reflex isn’t the only framework adopting the HTML-over-the-wire ideology; I also want to highlight a couple more projects.
00:30:20.460 First, there's Motion, which offers a one-to-one correspondence between server-side components and DOM elements, making it an interesting project that's still evolving. Then we return to Turbo Streams, which I mentioned earlier from Hotwire—Turbo Streams are essentially like CableReady but with five factions, and they can be initiated with zero JavaScript.
00:31:36.120 To start using Turbo Streams, all you need is to add a specific element using a helper on the page to subscribe to the stream. Subsequently, you can send a similar DOM modification command like add, replace, or remove from your controller. This is again similar to CableReady but serves more in the Rails context.
00:32:39.900 We can see how the server and HTML over the wire (or over the socket) work effectively together. But now we face another challenge: we have a lot of HTML, a lot of partials for different scenarios, and we need to keep them organized.
00:33:16.260 Do we have any architecture patterns in Rails for managing HTML templates, like we see in front-end frameworks? I’m not sure, so maybe we should take inspiration from them. As a few years ago, Evil Martians demonstrated our Evil Front methodology to manage templates, heavily inspired by one of the main React principles: thinking in components.
00:33:44.940 Components are the answer, and now we have them in Rails applications through ViewComponents. Let me show you an example of using the ViewComponent gem by GitHub.
00:34:01.680 A ViewComponent consists of several parts. The first is a Ruby class that represents the necessary logic, functioning as a mix of presenters, helpers, decorators, or even page objects. It contains all the logic you need to draw a template.
00:34:51.840 Then there’s the template itself. Here’s how you use it in pure HTML templates: you render the component, providing the appropriate data. This keeps it isolated from the main rendering context, while also making it reusable as just a Ruby class, allowing you to apply inheritance and isolate testing.
00:35:42.240 Moreover, ViewComponent permits you to keep all related files together, not only Ruby logic and HTML representation, but also styles and JavaScript needed to activate this controller. Additionally, you can integrate Stimulus controllers, reflexes, and previews in a single folder—this isn’t possible out of the box, but you can extend ViewComponent to allow it.
00:36:24.840 Furthermore, you can eliminate repeated initializers and attributes in your code. I prefer keeping my ViewComponents clean and simple. Some developers even created a gem called ViewComponent Cantrip, which provides useful hacks to make writing ViewComponents more convenient than the default approach.
00:37:23.580 ViewComponent is not the only library that addresses this issue; various other libraries provide a similar ViewComponents approach for Rails that you can explore.
00:38:02.400 Now, we’ve compared interactivity, organization, architecture, and all that fun, but we’ve totally overlooked CSS. Another strength of front-end frameworks is the ability to leverage CSS-in-JS approaches, and in Rails, we still have CSS frameworks available.
00:38:53.860 We have CSS frameworks like Bootstrap that can be used but there are many other options available today.
00:39:06.420 I want to highlight three of them that I really liked during my work in production projects. The first is Bulma, a CSS-only mobile-first framework that I've already used along with Stimulus and Vue. The examples you saw earlier were built with Bulma, and it's great for rapid development.
00:39:55.140 Another framework is Tailwind CSS. I’m sure many of you have heard of this utility-first CSS framework that has taken the front-end world by storm. It doesn’t provide components out of the box, though Tailwind UI offers a component library.
00:40:13.980 Instead, it offers utility classes to allow you to write styles quickly and efficiently, making it ideal for prototyping while also enabling optimized builds through its integrations. I appreciate Tailwind's playground functionality, which allows you to create markup in the browser and then transfer it to your projects.
00:41:09.780 Finally, let me mention Shoelace—a library focused on customizability and accessibility that provides web components built with both CSS and JavaScript. It offers typical UI elements like alerts, forms, buttons, and dropdowns, making it very powerful for building internal tools or admin dashboards.
00:41:43.200 But again, CSS frameworks work well; the real question is how we can write isolated styles. Although we don’t have CSS-in-JS in Ruby on Rails, we can utilize PostCSS to help manage our styles effectively. It plays nicely with ViewComponents, and let me demonstrate how I bind them together.
00:42:40.860 For example, if we have a component called Flash Alert, we can keep the CSS and JavaScript within that component. In our CSS file, we write classes without worrying about specificity, since PostCSS will automatically ensure uniqueness.
00:43:16.920 Utilizing the appropriate helper classes in the HTML template, we resolve these internal names to global names that are made unique through our conventions.
00:43:48.540 The resulting HTML looks like this: instead of using generic class names like 'container' or 'body,' we have unique identifiers like 'C-flash-alert-container' and 'C-flash-alert-body.' This way, we maintain clear and non-conflicting styles in our Rails app.
00:44:16.880 In summary, I don't have anything to put on the scale, so let's discuss the outcome. We've reached the end of the talk, and I hope I was able to demonstrate that the HTML-first approach could be competitive. It makes sense to utilize this methodology in various contexts, proving that the Timeless way exists.
00:44:57.920 As someone who actively applies these practices in production and side projects, such as tools and applications, I can assure you that it allows for increased productivity while not depending on the cooperation of other engineers when it's not necessary.
00:45:43.920 You don’t always need a front-end engineer to create yet another form or admin interface. With Rails and the tools I mentioned, you can build visually appealing, interactive applications.
00:46:02.040 We’re just at the beginning of this new era, a Renaissance of Rails full-stack development, so stay tuned, join the movement, and thank you for your attention!
Vladimir Dementyev
@palkan
Explore all talks recorded at RailsConf 2021
+65