It’s hard to predict…
The New Rails Way
It seems like the New Rails Way adds the following pieces, at least:
- A way to do a Turbolinks page update from a form submission.
- Very increased use of CSS.
- A statement of purpose.
Let me start at the end, this was something DHH said on Twitter a month or so ago…
The New Rails Way of front-end development, then, is to assume that the overwhelming majority of user actions can can be handled as some composition of simple CSS changes to one or more DOM elements, or the replacement of one or more DOM elements with HTML from a server request. In the rare case where that’s not enough, the idea is to augment with general DOM manipulation logic, and leave business logic on the server side. (The dev.to series walks through how this plays out with the way that Hey.com handles the transition when you mark an email as seen…) The advantage here is that the more functionality that you can implement with very simple CSS or HTML changes, the less code you write, and the more focus you can put on the parts of your app that are legitimately complex.
With that, I think I have three points:
This really is full-circle.
The Rails 1.0 front-end model was a helper that you wrote server-side in ERb that triggered the replacement of parts of the DOM with new HTML from the server based on a user action.
The Rails 6.1 front-end model, after some twists and turns, is made up largely of data attributes that you write server-side in the ERb markup and which largely trigger the replacement of parts of the DOM with new HTML from the server based on a user action.
There does seem to be a slight similarity.
Even when I’ve used Stimulus recently, I didn’t use HTML as the main server API response, but I think with the new tools, I could have cleaned up some logic from my most recent Stimulus project.
It fits Rails architecture
At least, potentially.
Rails is structured mostly in terms of resources, where a resource is often-but-not-always tied to a database table, but is always something that can meaningfully reply to the seven basic CRUD actions for a Rails controller. Rails routing and general structure make resources useful enough that it makes sense to split your application into resources, even if that is not completely natural. (For example, rather than having a
UserContoller#search action, I might have a
UserSearchController#show action, setting up a new resource with a common action rather than putting a custom action in the existing resource).
Anyway, client-side apps in the React/Vue/Angular family aren’t structured that way, those components tend to be smaller and tied to the page layout rather than to the controller action structure.
But in the Nouveaux Turbolinks world it looks like it is at least possible to structure your front-end interactions such that they align with Rails resources – it looks like you’d often be making, for example, show calls to refresh part of a page. I think this might make the logic split between client-side and server-side structures easier to manage.
CSS is a force multiplier
With CSS animations, layout, graphics, before and after elements and the like, you can offload onto the browser’s rendering engine all kinds of visual effects that you would otherwise have to write code for. This feels like a huge win to me, but it’s basically what CSS is commonly used for.
Taking it even a step further, it looks like Hey is, in effect, using CSS to handle some of the responsive view render changes that we would normally expect something like the React engine to handle. I’m not sure how far to take this – there are clearly some data things that CSS can’t handle, but I look at how Hey does the “Previously Seen” header, which involves a :before pseudo-class tied to tied to the first element in a list that has a particular data attribute, which means that changing that data attribute automatically moves the the header, and I think there’s lot of power available there at relatively low cost.
This is still not public yet, maybe some of it won’t be public, or maybe it’ll be harder to use than I think. But right now, it looks like a pretty great way to get the 80/20 rule for front-end coding with 80% of the power for 20% of the cost.
What do you think? Does this way of doing front-end apps interest you?
Next time: Back to Agile, we talk about teams and metrics.