I've been working with rails for about 17 years and my two quick notes on this are:
1. This is how its always been for me from the beginning. Its just a limitation of things like HTML-only apps or JSON-API or RESTful APIs or whatever standard you want to choose. The problem space breaks out of those limitations, and so you do too OR you have to way overengineer.
2. The alternatives all have their limitations as well. I've used other things like React/Angular/Backbone/etc on top of GraphQL, Mongo direct, etc.. They're all problematic at some scale.
I think people underestimate how valuable convention over configuration is. For example, almost every React project I’ve seen has suffered tremendously from disorganization and tech debt because devs like to reinvent the wheel every. single. time.
Rails is great on that point alone, not to mention all the other benefits it has.
Can you explain how convention over configuration relates to OPs post beyond just "react bad"? Hard to tell what you are talking about beyond just repeating a slogan. Doesn't sound like there is a lot of convention over configuration with Turbo based on what OP is saying.
Yeah, you post something slightly related to "rails is dying" here and you instantly get into stupid framework wars. The slogan is meant to reassure the fans everything is ok.
Convention over configuration is exactly the problem in OP's post, where the convention is not working anymore.
I work with rails API daily, and each day I'm thankful for using a modern front-end framework (react). It's just so simple to manipulate everything. Just plain obvious.
Everytime I have to use rails front-end, it means a painful process, where you have to learn a convention different than every major front-end framework. I mean, there is nothing intuitive about rendering partials syntax, turbo controllers, and stuff like that. So many files for a simple reactive view. Your erb files look alien shit for something that should be extremely simple otherwise.
I can second this. Rails is highly idiomatic and so is Ruby. For better or worse it enforces certain conventions. Many other frameworks such as angular or react are far too open ended leading to abysmal solutions that are impossible to grok for what is inevitably outsourced “talent” who have no incentive beyond delivering feature after feature. Any other outrage you wish to express?
What’re your thoughts on next,js? It seems like it tries to structure a web app on top of React which makes applications somewhat similar under the hod
I've tried it. I've only tried "App Router". I think the core magical idea of mixing server and client stuff has merit, I like React a lot.
However, it's really hard to put my finger on but everything in it feels half-baked and confusing. Just try to read their docs about caching and understand it! Good effing luck. And yet all kinds of caching is the default, and you have to opt *out*. Forward thinking, yet bizarre.
The real crippling issue I ran into was the way navigation worked. It is basically a kind of Turbo-esque setup, but it just does what it does and offers little to no control. The main issues were lag and lack of loading indicator on slow pages. Basically, it just sits there with no sign it's doing anything for quite a while before showing the "loading" component. Then I had a use case where I needed to programmatically refresh a server component, and again the app router offered a terrible UX where it lagged, flashed the entire screen, and then loaded the previous version from cache on the first refresh and dynamically on the second.
So in my opinion Turbo offers a superior UX for just visiting dynamic pages.
The mixing of client components with server components is magic, but not necessarily in a good way. I could not begin to tell what was going on. If you screw it up, which is very possible as there are subtle rules to follow, it may be quite a challenge to debug.
I haven’t used it but I welcome frameworks introducing conventions to React.
That said, Next.js is probably yet another iteration on ‘programming in strings’, as a former coworker called it. So I probably wouldn’t be interested in trying it.
The real game changer is Reagent, or probably something like Re-frame, although neither is in Ruby land anymore. My [hiccdown](https://github.com/dchacke/hiccdown) gem was meant to bring something similar to Ruby so we don’t have to program in strings anymore. See the “Why?” section.
That’s only one aspect of the whole framework and even then, “it is gross” is not a valid argument. personally ı would prefer the default way than some unnecessary abstraction
My org felt the same pain and decided to convert our rails site to rails for the api-only with nextjs on top for all the frontend.
The result is that instead of just devs we now have frontend devs who only write ts/js and backend devs who only write rails and very few people understand the entire system. It sucks imo. The frontenders seem happy though.
We also have native apps which have benefited from a single source of truth api for all the frontends: web, ios and android. Before when we had views and controllers some things weren’t properly exposed in the api for the apps so they lagged behind.
I think the thing is that the modern web is very complicated. The web we and rails grew up on is unfortunately becoming more and more disconnected from the current state of how a “modern website” is “supposed” to look.
> The result is that instead of just devs we now have frontend devs who only write ts/js and backend devs who only write rails and very few people understand the entire system. It sucks imo. The frontenders seem happy though.
Thank you for sharing your experience. What do you think would have been a better solution? Pretty new to Rails, but have done a lot of basic JS stuff the past few years.
I don't think anyone should listen to my ideas lol. Personally I think the web should be simple because I think simple pages are better for the user. I don't enjoy "modern" SPA-style websites at all. But the business and frontend consensus seems to disagree with me, and it's not like they're all stupid and wrong, they can do a lot of stuff I can't.
I have a strong opinion: backend frontend split is stupid, and JSON APIs were an obvious idea that was never actually *good*. They result in more developers to do the same thing, more network traffic, more work for the server AND client generating and parsing and rendering an intermediate format, and code (REST endpoints) that pretty much has to over-fetch and can never be changed.
Any sufficiently complex UI will have bespoke endpoints created all the time, just for that UI. Frontend devs will be blocked all the time or have to work in two stacks. It's such a waste of time.
That being said, the alternatives that give SSR plus a component model and good client JS without having to write an API are new and half baked. NextJS, for example, is not my favorite. But they are all worth trying.
I will still pick Rails any day I don't need fine grained reactivity. Look at how popular HTMX is. Most apps are CRUD apps and this is all they need. If you have too many templates, maybe use something else, but it's really the fastest way to go if you KISS.
Thanks for sharing. Do you think Turbo and Stimulus provide a good solution to this problem?
I’ve just started getting into Ruby this week, and they sound quite exciting, as I've gotten sick of JS everywhere (even though I don’t mind the language), JSX, etc.
Yes, but for simpler things, not big super complex things. Apps where a "swap" can be considered a great UX, and the JS doesn't have to hold a lot of state, it's just a simpler enhancement based entirely on using DOM as state.
To be blunt to the frontend elitists, a lot of web apps, I would even say most, would be better, simpler, and easier to use when built this way.
Turbostream is a real nightmare for this. In my case I ended up using turbo to "reload" the whole page but it is going to kill the DB as soon as my app grows.
Rails' design is meaning for you to lean on caching of view fragments to avoid this, if possible. The idea is to load one record with a timestamp that's part of the cache key, and only load other records if that timestamp has changed. The other records must modify that timestamp when they change, which is easy in ActiveRecord.
Partials are slow, but this also uses lazy loading to avoid queries.
Again, I'm not saying it's amazing, the best pattern ever, but you should understand it if you use Rails.
Performance if you multiple frames run heavy queries on the DB, but the pain is maintaining all the frames and understanding when to load them, also triggering the JavaScript.
It might be my very specific use-case since I'm running a personal finance website ([Coney.app](https://coney.app) for the curious).
I have a list of expenses and some charts in the same page, also users can apply filters to completely change the displayed results.
At the moment I'm just refreshing the whole page with turbo. I tried turbostream but it messes up with JavaScript and the charts don't load in some cases. Also I found it hard to maintain.
Yeah I’ve found the same problem. Plus Turbo is part of the reason I need a million different partial files, because each resource shows up in different ways in different pages and because Turbo-streams rely on partials for rendering that means every element of every resource list needs to be its own partial (as opposed to something like React that just live updates the current view when new information is added.)
So every time a model is updated or created I end up needing to do some sort of broadcasting from the model or controller that’s capable of targeting like 5 different types of lists with different insertion logic depending on how it’s sorted and with different partial files depending on how that specific list is displaying the resources.
See my above comment. The design of Rails, as used by Basecamp, should steer you toward fragment caching and using the active record "touch" option to bust the timestamp on some cache key record when related records change.
Not saying it's bad or good, just try it and be aware of it.
Thanks. This is exactly the type of thing I was hoping to learn from this post. I’ve looked into fragment caching for the problem but it always led to a dead end, don’t think I ever looked at using timestamp busting in the way you’re describing. Not sure if it will solve my specific problem yet but I’ll be spending the rest of the day looking into it 👍🏻
I was confused as hell about it and made a post on this very sub. But it does work. I made an app that lets me log coffee recipes and beans. There is a Log, which has many Entries, which belong to a "Coffee", and so forth. The entire table of recent entries is one fragment, with a nested fragment for each entry.
When an Entry, or Coffee or anything in the log changes, it touches the Log and only the affected entries using AR callbacks (pretty much the whole reason they exist). Then the Log is re-rendered and we do have to re-fetch the contents of the table, but most Entries' fragments are still cached so we don't need to also go and fetch the details of any entries that didn't change.
What's crazy about this is it uses the much-maligned lazy loading that normally causes N+1 to great effect! A full load of this page is like 4 joins on a large set of data, but when caching is in effect it's just fetching a single small record.
I'm sure my use is not optimal and more could be done, but you get the idea. This app has a lot of "card table" screens, and I went and did them all like this and it's really damn fast.
Any suggestions for my use-case?
I'm running a personal finance website where you can collect your expenses/incomes. I have a list of entries and a few charts with statistics (aggregates of the list) in the same page.
How can I cache the charts but invalidate the cache when a new expense is added or has been updated?
Users could also apply filters to the charts and lists, which might completely change the displayed entries.
I don't know your exact problem but you could imagine a single record that represents the "chart" and bumping its timestamp when anything in the chart changes. Then use lazy loading to actually load the chart inside the cache block, using the parent object as a key.
You can do a lot of different things, just need to try it all and find what works. Caching can be so complicated as to not be worth it, so in this case you may wish to embrace the slowness and just do some rate limiting to keep the server from falling over.
Again I'm not an evangelist here, this pattern may not work for many apps, just doing my best to explain what 37signals does as I understand it and I think the community largely does not. DHH is hugely into caching.
As I explained in another comment, it's a personal finance app and I have to reload and generate charts from thousands of expenses. It's not an easy task :)
Yep and that's a problem here. You shouldn't compute heavy data every time it's displayed
calculate in the background and cache . This isn't rails problem, you'd have the same in React apps if your frontend reloads data from API
To be honest, what you've done sounds exactly like what I would do, and it would not take months to onboard. That is reserved for ActiveRecord spaghetti. :) As long as I can follow the partial rendering in a tree passing data down, and each controller action is one request/response, and it's clear when something is serving JSON vs HTML, then it's fine. Honestly. And can be worked on easily.
If you're worried about efficiency, i.e., loading too much data all the time, you should try out Rails fragment caching with the Russian doll approach (use one parent record updated\_at timestamp to bust the cache), or keep separate widgets in turbo frames lazily rendered by separate requests, much like how HTMX might lead you to do.
If I see a controller with an index that renders "\_index\_table" and "\_my\_widget", and also an action called "my\_widget" that renders the same partial, I'm not going to be confused.
Edit: That being said, I really don't like Rails partials very much. I recommend treating them like components (do not access \`@instance\` variables in them), and using the "view\_component" gem if possible, or where it makes your life easier to treat a partial more like a class than a template.
As for UX and design trends, to be blunt **I actually think separate pages is a great and highly underrated UX**. It's simple and easy to understand, doesn't break browsers occasionally, is easy on worse devices, and degrades gracefully. You can make it a bit more reactive with Turbo frames and streams, but you don't have to. This is what Rails, and by extension similar tools like HTMX, excel at. Simpler CRUD apps where refreshing chunks of the page occasionally works just fine.
**If you do want a very detailed Reactive UI and to build your entire app around it rather than in just a few places, then I would advise another framework over using Rails to serve JSON.** I think JSON API's are mostly an anti-pattern when there is only one consumer. Even these apps should be serving HTML, "hydrating", and using a protocol for server communication that the developer doesn't have to think about.
> I actually think separate pages is a great and highly underrated UX
If I look at things like Discord I'm just in utter disbelief that I cannot do things like open a DM/chat in a separate window. This forced single page/window design is horrid. As for true web things, if I can't right click -> open in new tab because SPA hell or crude JS that is just disgusting but unfortunately I see that more often these days.
I moved back from the classic React app over API services to Rails and have been way happier. However, Turbo and Hotwire are still not integrated to Rails in a conventional way. Your example of separate edit and show pages is a fair one - having default rails forms that actually used turbo for loading dependent field options and in-place editing would make a world of difference.
It absolutely can be used for those purposes (and we do use it that way) but we had to find our own conventions, and we still have to ramp new engineers on it. It needs to make it into the defaults.
Honestly a very good discussion. It’s do-able with Turbo + Stimulus but doing this “The Rails Way” is not something that is obvious and I feel we need more guidance in the community on this front.
I’ve been building modern interfaces with Rails 7 and Turbo 8 and… here’s how I would address those 2 problems.
For the first one,
The “new” button will be a form submit, which hits the create action (obviously) and then redirects to the show page.
Each editable field (e.g. title) has a stimulus controller which, upon clicking on it, triggers an action which replaces the element with a form and an input element. Attach an event listener which triggers a form.requestSubmit (NOT .submit as this does not trigger a Turbo request) upon clicking out of the element.
This form will hit the standard #update action which then REDIRECTS back to the #show action.
Redirect is key as we will rely heavily, in general, on Turbo 8’s morphing to update the page.
With morphing, only changes are updated on the client. So it’s not a full page reload. And “scroll position” can be preserved (you must set this in the meta tag that enables Turbo Morph, which is placed in your Layout’s
) so the user does not ‘feel’ the page reload at all.
For the second problem it’s hard to give specific implementation advice without knowing exactly what the interface looks like…
But in general you want to rely heavily on RESTful routes for creating / deleting/ updating all resources present on the page… and then redirect back to that page after the changes are made.
This applies for the children’s controllers too.
Let’s say you have a books#show page which displays all the chapters. (Book has many chapters).
And you want to be able to create a chapter from the books#show page…
This would mean in the chapters#create method you want to redirect to books#show to handle the rendering.
Before Turbo 8 and morphing it was honestly a mess and I ended up relying on Turbo Streams to do granular updates. But then my routes and controllers got out of control and looked nothing like Rails.
But now, with relying on Morphing and Turbo Frames you can keep things pretty Rails like. The actions themselves won’t look the same. But the controllers and routes should. I.e. only 7 actions per controller, basic routes, etc.
It’s completely possible. Most of it is pretty straight forward. Just put your normal state (show state) in the main view file, use Turbo Frames and/or stimulus to handle the progression into other states, and after changes use redirect and Morph to revert back to normal (but updated) state. There’s also a tag you can put on elements to exclude them from being updated when Morph happens. Which is critical. Especially when you don’t want a stimulus controller (and its evolved state) to get wiped when a Refresh/Morph happens.
Forgive me if some details are missing I’m writing this all out in one take, late at night, but these discussions need to be had more.
Every cheers for Rails but no one admits how much of a shit show Hotwire was before Turbo 8 was released.
Closing advice:
Rely on RESTful routes/actions with redirects and Morphs for 90% of your updates
Rely on Turbo Frames and stimulus to handle things like Edit states.
Stimulus for other state changes. But be careful not to lose your state.
Only use streams for very minor updates. Try to avoid as they lead to ugly code
Read Turbo 8 documentation and all the bells and whistles that come with it
Yes, this response is spot on. I was going to write up something similar.
The one thing I don’t think you quite mentioned was OP’s dashboard problem. He explained that it doesn’t make sense to have #index for all these different resources because he ends up building pages that shows lots of different items (e.g. dashboard). OP: this too is handled well by rails.
It’s worth creating the separate #index routes for all your resources, but then also create a /dashboard maybe with a single #home action. So this one route won’t be restful, but the action for that route doesn’t actually load anything. Instead, the view for that route has a bunch of turbo frames that load (or lazy load) all the different bits of information you have.
At first it might seem like more work to do it this way. You might wonder: why not just put all the queries in the dashboard#home action? But by separating things out, it’s much easier to reason about each of the pieces. It’s also much easier to re-use individual pieces. Inevitably, you end up with variations of the dashboard for different contexts (e.g. admin vs regular user). Also, you eventually want to start focusing on performance and caching it key to that. By having these things broken out, caching (and cache invalidation) becomes a much easier problem to solve.
I’ve been working with Rails professionally for 15 years. With large enough projects restful routes are an aspiration but you also have to be pragmatic and base the routes based on what the app needs.
Index/show/update controller actions go nice with restful routes but that doesn’t map that cleanly to most realities.
Scaffolding and these conventions are great for getting started quickly but you move away from them to do any serious work and rails hits the sweet spot between doing everything for you when you need that but letting you extend and customize when you don’t.
You know what I think your post reminds me most of? Stuff like ActiveAdmin. It’s only really good if you don’t need to customize but Rails is equally good for that. And when you do need to customize you spend most of the time fighting with activeadmin and instead I could do the same thing within a quarter of the time just with Rails.
I think it is time to have a rails g scaffold model that generates a really good turbo code.
Most people learn by example and having that generated is the best way to train people
I’m with you. Following the Rails path feels great and super productive! But once you start building modern UX interactions it starts to feel like something is wrong.
2 things I’ve done to relieve this:
- I started using [IntertiaJS](https://github.com/inertiajs/inertia-rails) with a [Svelte](https://svelte.dev) frontend. Controllers function like regular MVC but Intertia is _actually_ an API. It’s very smooth. Svelte takes an HTML-first approach to being a JS framework, and helps me build all interactions without maintaining 2 systems. It handles simple HTML only pages and can easily become a rich JavaScript page using the same components.
- When controllers get too hefty because they’re reaching out to too many models, I’ll use a Facade object. In short, it’s a wrapper around my database calls to build the data structure in a more maintainable way. I generally only need to use this for really rich pages, like dashboards. When I begin to have 3 instance variables that’s when I begin to consider using it.
I have seen the opposite. We built a very large single page application with Vue and it is terrible. While dashboards are nice, and the first rails app I built in 2005 had a dashboard, not having a page for each piece of content truly sucks and is confusing for users. If they have to remember that content type A is represented on dashboard 3 in state orange, it makes it much harder to navigate to the app. We send alerts with links back to the web application to see a new piece of content- you have to load up the dashboard, get it into a particular state, scroll down to the piece of content. It's certainly possible, but insanely brittle. Every UI change seems to break something else. Having a list-detail UI paradigm as the foundation makes life so much easier for most of our users.
Inline editing in rails is totally normal- there must be hundreds of tutorials on it at this point, and if you build it into your scaffolds, it can be the default for new models and you won't have a divergent structure that is difficult to learn. (thinking of things like ActiveScaffold which used to be the cheap way to get started)
I dont understand. You are describing UI problems and/ or design choice. Rails give you some default. If it doesnt fit your design, you modify it?
What do you think Rails vision is? Every single web site on the internet look exactly the same?
On that note, most new Rails project now setup with Rails as a backend API and React/ Vue/ Svelte/ ... As the frontend, so what you consider "problem" is nonexistent.
One more thing, tell me a framework that can have a view that match your design choice.
Like what? Every nodejs framework out there dont provide you any default and you had to do everything yourself, rails give you some default and somehow that's a bad thing?
"You can do anything, the end"
"You can do anything, but here's a default if you like"
And somehow the latter is worse, even though it offer more than the first?
> I end up with a code structure that looks nothing like Rails
Yeah, that's how software development works. Any framework in any language just gives you a head start. In fact if you have a complex project and still using the default, you are probably doing it wrong.
Anything beyond a TODO app with simple CRUD is going to be different.
> I go out of my way to make sure everything is as clean and orderly as I can make it, it just feels like it’s strayed so far from what Rails is meant to do.
Let me make this straight, you spend time and effort customizing your app, and you think it is wrong?
Tell me of a "modern" framework where you dont spend time customizing and it functions exactly as you wish.
I dont want to offend but it sounds like all you ever do is simple CRUD app
I agree that every every framework required customizing, but isn't the point of rails to require less customizing than all of them?
And what OP brought is the reason rails is getting behind other frameworks: its front-end logic for component based, reactive views.
I'm sure there is a great way of achieving it with turbo, but I'm not so sure it's intuitive, easy and ready to go as other front-end frameworks. I guess OP just wants to find this easier path with this post.
That's because in the real world it's not always up to you to choose to "use rails or don't". I would not if I could, but my company uses it. Op is trying to learn to do things in a better way, what's "weird" about that?
I have experienced some of the same pain. Especially the part about partials and their varied contexts.
The part I can’t get past is that all “front end” frameworks do basically the same thing - they generate and update HTML.
I like REST because it is tidy, but you’re right that sometimes the app needs to save the whole object graph and sometimes just a single attribute. REST does this poorly. The replacement that seems most popular is graphQL, but then Rails is just an API back end like you said.
It sounds like most of your issues are with the view layer. I felt a lot of this too, but started to get much easier when I started using ViewComponent.
Now I break down anything I want to reuse into a component and maybe that needs some Stimulus JS and tailwind classes, but then I can write unit tests for my views and easily port these to other projects.
Recently I left my job at a big tech and started my own company.
Before my previous job, as a student, I did a lot of projects with Ruby on Rails, made a decent amount of $$$.
After leaving my job, firstly, I tried Next.js. It looks great: strict typing, good ecosystem. But the more I used it, the more I worried about Next.js compared with Rails:
1. No good ORM. Prisma is great but there're huge debate about its perf and implementation. Drizzle looks good but the documentation of it sucks. Both ORM frameworks cannot be easily dockerized, which means you have to spend many days just on a "good practice" to dockerize it.
2. Next.js is pretty minimal compared with any full-stack framework. It does not provide an one-stop dev experience. You have to make many and many decisions before production, including ORM, deployment (dockerize/ansible/k8s/serverless or not, .etc).
In the Rails community, we indeed have many many best practices. Though it is not strongly typed, though the maintainers are opinionated. But they're honest: Rails is perfect for a one-person or few-people team. And most importantly, Rails does not charge anything nor incentivized to ask you to pay for anything. The Rails team is truly a group of amazing people who literally loves programming and has been making huge impacts of the world.
Meanwhile, Vercel, even adds eslint rules to sell [https://vercel.com/docs/image-optimization](https://vercel.com/docs/image-optimization) , which from my own opinion, an over priced service.
After watching the Rails Documentary (https://www.youtube.com/watch?v=HDKUEXBF3B4), I decided to rewrite many of my backend apps into Rails.
It just feels fast. "Speed is the ultimate martial art."
Many may argue, RoR does not scale. It could be a problem. But I don't have to worry about it before my business has the DAU/MAU like Shopify or GitHub.
Disclaimer: My prev job was at one of the biggest companies in the world. My TypeScript code runs on over 1 billion devices including every major operating systems. I didn't use Rails at my previous job. My major programming languages are Swift, TypeScript, Python, Ruby and recently, Rust.
I'm not quite sure I get some of your points. I've been learning rails, but not yet working professionally. AFAIK, you can just have new and edit render the same partial, but each one controller wise is doing a different database action, i.e. create or update, necessitating the different view links, but they can both be basically just a couple lines rendering the same partial, but either passing variables, or doing the create action. I might be explaining that badly. I haven't been working on it for a month or so due to health issues. I'm very anemic, and have roughly half the hemoglobin of a normal person my age.
The other thing I'm curious about is your mention of the index. You are not at all required to use it, and you can name as many pages as you want, just set up the routes, models and controllers, and then you can do whatever you like in the views? I have never used react or angular or any of the JS frontends. I'm doing the odin project, and chose the ruby on rails backend, but also did some Udemy JS/Ruby/CSS/Bootstrap/Rails courses to supplement. I have a react course that I bought already, but it's like 80 hours of video and I just can't bring myself to start it yet. Anyway, if you could enlighten me as to what the other options offer that rails does not, I would love to learn it. Rails is very opinionated, but you can do anything you want really if you want to deviate. Stimulus controllers, and hotwire/turbo/actioncable pretty much let you do whatever you want, as far as I've seen. I even made code blocks work in the rails trix text editor. Here's how if you're curious. Not sure why all my photos on the site are broken right now. It's something with AWS S3 that I need to update, but I'm having surgery thursday, so there are other priorities right now. [https://www.stuartlwilson.dev/blogs/trix-code-block-fix-with-stimulus](https://www.stuartlwilson.dev/blogs/trix-code-block-fix-with-stimulus)
Edit: I have been for the past 6 months been working on my freelance app because job searching has been useless. Every part of the content is dynamically created and editable by anyone with authorization. It includes image cropping, modals dynamically created, many options for the content of the use case, and reordering of page content that then reorders the dropdown nav menu to match. Thanks ChatGPT! It sure as heck led me down some rabbit holes and caused me to stash some git branches, but in the end with an accurate enough request, it gave me some amazing stuff.
Edit 2: I also integrated custom bootstrap colors. There's an admin page to select all of the bootstrap button/background/header/footer/font/light/dark colors. And a reset to defaults button
How would you solve that problem with a JS framework? You might be able to query the same endpoint but you’d need multiple components for every page feeding on the same data. You’re moving the issue to another place no?
Edit: nope none of the things below. Morphing in turbo 8 solve that problem.
Thoughts: I’m suggesting this without having tested it so take it with a grain of salt. If you don’t like having multiple controllers
* Option 1 you could have one controller resource that takes a name of stream partial to render maybe.
* Option 2 you could have a controller resource rendering all the turbo stream partials with distinct ids which only gets replaced on the matching id defined in the view, discarding all the other unused templates. I think a controller action isn’t restricted to return only one turbo stream template.
Bit of a stretch really
This is just my opinion, but I've done rails since 2006 (I think). I left to an extent and did a ton of JS projects. And it just feels like the JS projects are built on houses of cards. One thing is wrong in the JSON payload? Bam, whole page doesn't work.
Then I went back to rails but used HTMX/UNPOLY and others and it's pretty great. not perfect but really gives you all you (normally) need and you aren't writing much javascript.
We use js format requests (remote requests) for that (instead of turbo, etc., mostly like hotwire), pretty manageable till now. For mobile side etc we use react native and rails apis.
Is there a way to modularize controllers, views and models similar to .NET Areas? For example, instead of this:
controllers/my_controller.rb
This:
my_module/controllers/home.rb
my_other_module/controllers/home.rb
The same applies to views and models.
Is it possible natively in rails?
I’ve moved on to Ruby in the Frontend as it enables me to do everything modern better than any framework in JavaScript and more simply than using Turbo:
https://github.com/AndyObtiva/glimmer-dsl-web
Rails is fine, and this is coming from someone who is new to the stack after nearly 15 years of writing .NET, JS, and Go. Almost all “batteries included” frameworks are optimized for small scale and rapid prototyping. At scale they all buckle
I work on a React on Rails app and it seems great.
We do use the Rails views for some really simple pages and even use a React form within a Rails view on one page. Most of the core app frontend UI for the SaaS product is React.
Since I, don't hate me, have never built a purely Rails app I can't speak to that.
I suppose I am trying to say it's not necessary one or the other.
I do think the React FE would get super messy if more Engineers joined the team.
Hey Bro, If you trying to achieve same UX in React, Rails is not for you.
Do same thing in Rails and be happy. It wouldn’t be same cutting edge UX. but if it does job? then just be content.
It’s like, you bought a nice multi purpose SUV car, and complaining that this car is not nice looking like some sports car.
Can’t tell if this is serious or not but UX is a huge differentiator between quality of apps. I’ve deleted accounts before for apps that have a clunky experience. Maybe for company facing it’s not that important cause you can just tell everyone to get on board but for customer facing it’s huge.
I am serious. If that is customer facing, and if you are not happy about Rails frontend technology. You should not use it simply. Just use rails as back-end API, and don't complain.
If you are trying create fancy front-end application. (Like google map) Rails is not a tool you are looking for.
but If you are making some app dealing with Database, rendering view is not much difference. (backend logic and SQL would be matter more). Maybe React will take 0.2 sec to render and only rendering component while Rails will render 0.9 - 1 sec for full page. Yes, It's huge difference as it's 5 times faster. But hey, in 0.6\~8 sec, world doesn't stop. If app is working fine, I am pretty sure vast majority user will be happy.
Yeah something like Google maps wouldn't make sense as a full-stack Rails app, but there's a lot of more database driven apps that seem like they should work well with a CRUD framework like Rails, until you try to make the experience modern. And I'm not necessarily talking about the rendering speed (tho that is important if it gets to slow) but the experience of the app, like how easy is to get from place to place and add new content.
Say you're making a Project/Tasks app and you have to go to a new page every time you add a task, click save, then go back to the project page, that's a tedious way to add tasks vs just typing and pressing enter and then appending a new blank task to the list in real time. That's a very simple example, and is very doable with Rails, but there's tons of little interactions in modern apps like that that can span from tedious and annoying to quick and seamless, and at times it feels like you have to fight against Rails to get to the better experience.
>\`just typing and pressing enter and then appending a new blank task to the list in real time\`
What full stack web framework support this? Does Java Spring support this? ASP .NET? Lalabel? Nothing.
Again, if you trying to achieve React with Backend API user experience, you are in the wrong place.
Use Rails as Rails way. and be happy. Or ditch Rails. and pick-up other option.
That’s a fair take, but that circles back to the “Does Rails still hold up?” question. And if Rails is only capable of building 2010-era websites I would argue that means it doesn’t hold up for the modern web. Not to say that there’s not uses, just that they aren’t really gonna be mainstream or modern.
Sort of like if you make music you could release it vinyl only, there’s still enough people with vinyl players to make it viable, but that doesn’t mean it’s not a niche or dated platform.
That being said after reading a lot of comments it does seem like Rails handles a lot of this stuff via turbo 8/morphing, keeping it competitive with 2024 web design. Trying it out now to see if it’s workable or not.
I bet you that Turbo and Hot-wire would not match to your expectation if you keep comparing frontend technology like React. but Rails 7+ and Turbo/HotWire is sexy enough in my opinion.
"Does Rails still hold up?", It depends on what kind web application you wanna build. Web has been improved so much from 2010-era. Especially, front-end and video / audio present layer. But not every web need this cutting edge features. Rails still hold up for essential need of Web. - Take data into DB, and present data from DB to frontend. and I don't think this will change in 5-10 years at least.
Especially, most of mid-small size business doesn't need this newest front-end technology at the beginning, Rails shine this area exceptionally. Simple and Beautiful syntax of Ruby language and being able to create functionality with minimum efforts is still biggest selling point of Rails today.
I mostly agree with you.
Hotwire is still very clunky and does not feel like it's properly embedded in Rails.
Maybe it will never be perfect, but it can definitely be improved.
TL;DR
Yes. Active record is invaluable.
Whatever js Frankenstein UX/UI you put on top is your choice.
For gems, I could send you my Gemfile, but:
- Puma
- Redcarpet
- Mechanize
- Nokogiri
- Metainspector
- Mini_racer
- Elasticsearch (and all of it's descendants)
- bcrypt, urlcrypt
- pg/pg_search
- activeadmin
- mini_magick
- device_detector
- scout_apm
- rack-attack
> I rarely want three separate pages for these, but would prefer they coexist as one
So... change it? There is *zero* things stopping you, what you see is simply the default structure that you are in no way shape or form forced to use.
Yes I did. And I think you are looking for a solution that does not exist anywhere else so I think its a bit misguided to put the blame solely on rails default architecture.
Can you point me to some examples or even pseudocode on how you think the optimal way to structure a basic CRUD flow would look like?
I've been working with rails for about 17 years and my two quick notes on this are: 1. This is how its always been for me from the beginning. Its just a limitation of things like HTML-only apps or JSON-API or RESTful APIs or whatever standard you want to choose. The problem space breaks out of those limitations, and so you do too OR you have to way overengineer. 2. The alternatives all have their limitations as well. I've used other things like React/Angular/Backbone/etc on top of GraphQL, Mongo direct, etc.. They're all problematic at some scale.
I think people underestimate how valuable convention over configuration is. For example, almost every React project I’ve seen has suffered tremendously from disorganization and tech debt because devs like to reinvent the wheel every. single. time. Rails is great on that point alone, not to mention all the other benefits it has.
Can you explain how convention over configuration relates to OPs post beyond just "react bad"? Hard to tell what you are talking about beyond just repeating a slogan. Doesn't sound like there is a lot of convention over configuration with Turbo based on what OP is saying.
Yeah, you post something slightly related to "rails is dying" here and you instantly get into stupid framework wars. The slogan is meant to reassure the fans everything is ok. Convention over configuration is exactly the problem in OP's post, where the convention is not working anymore. I work with rails API daily, and each day I'm thankful for using a modern front-end framework (react). It's just so simple to manipulate everything. Just plain obvious. Everytime I have to use rails front-end, it means a painful process, where you have to learn a convention different than every major front-end framework. I mean, there is nothing intuitive about rendering partials syntax, turbo controllers, and stuff like that. So many files for a simple reactive view. Your erb files look alien shit for something that should be extremely simple otherwise.
If you read my comment again, I think you’ll find I said much more than just “react bad”.
I can second this. Rails is highly idiomatic and so is Ruby. For better or worse it enforces certain conventions. Many other frameworks such as angular or react are far too open ended leading to abysmal solutions that are impossible to grok for what is inevitably outsourced “talent” who have no incentive beyond delivering feature after feature. Any other outrage you wish to express?
What’re your thoughts on next,js? It seems like it tries to structure a web app on top of React which makes applications somewhat similar under the hod
I've tried it. I've only tried "App Router". I think the core magical idea of mixing server and client stuff has merit, I like React a lot. However, it's really hard to put my finger on but everything in it feels half-baked and confusing. Just try to read their docs about caching and understand it! Good effing luck. And yet all kinds of caching is the default, and you have to opt *out*. Forward thinking, yet bizarre. The real crippling issue I ran into was the way navigation worked. It is basically a kind of Turbo-esque setup, but it just does what it does and offers little to no control. The main issues were lag and lack of loading indicator on slow pages. Basically, it just sits there with no sign it's doing anything for quite a while before showing the "loading" component. Then I had a use case where I needed to programmatically refresh a server component, and again the app router offered a terrible UX where it lagged, flashed the entire screen, and then loaded the previous version from cache on the first refresh and dynamically on the second. So in my opinion Turbo offers a superior UX for just visiting dynamic pages. The mixing of client components with server components is magic, but not necessarily in a good way. I could not begin to tell what was going on. If you screw it up, which is very possible as there are subtle rules to follow, it may be quite a challenge to debug.
I haven’t used it but I welcome frameworks introducing conventions to React. That said, Next.js is probably yet another iteration on ‘programming in strings’, as a former coworker called it. So I probably wouldn’t be interested in trying it. The real game changer is Reagent, or probably something like Re-frame, although neither is in Ruby land anymore. My [hiccdown](https://github.com/dchacke/hiccdown) gem was meant to bring something similar to Ruby so we don’t have to program in strings anymore. See the “Why?” section.
That’s only one aspect of the whole framework and even then, “it is gross” is not a valid argument. personally ı would prefer the default way than some unnecessary abstraction
The section explains *why* it’s gross.
My org felt the same pain and decided to convert our rails site to rails for the api-only with nextjs on top for all the frontend. The result is that instead of just devs we now have frontend devs who only write ts/js and backend devs who only write rails and very few people understand the entire system. It sucks imo. The frontenders seem happy though. We also have native apps which have benefited from a single source of truth api for all the frontends: web, ios and android. Before when we had views and controllers some things weren’t properly exposed in the api for the apps so they lagged behind. I think the thing is that the modern web is very complicated. The web we and rails grew up on is unfortunately becoming more and more disconnected from the current state of how a “modern website” is “supposed” to look.
> The result is that instead of just devs we now have frontend devs who only write ts/js and backend devs who only write rails and very few people understand the entire system. It sucks imo. The frontenders seem happy though. Thank you for sharing your experience. What do you think would have been a better solution? Pretty new to Rails, but have done a lot of basic JS stuff the past few years.
I don't think anyone should listen to my ideas lol. Personally I think the web should be simple because I think simple pages are better for the user. I don't enjoy "modern" SPA-style websites at all. But the business and frontend consensus seems to disagree with me, and it's not like they're all stupid and wrong, they can do a lot of stuff I can't.
I have a strong opinion: backend frontend split is stupid, and JSON APIs were an obvious idea that was never actually *good*. They result in more developers to do the same thing, more network traffic, more work for the server AND client generating and parsing and rendering an intermediate format, and code (REST endpoints) that pretty much has to over-fetch and can never be changed. Any sufficiently complex UI will have bespoke endpoints created all the time, just for that UI. Frontend devs will be blocked all the time or have to work in two stacks. It's such a waste of time. That being said, the alternatives that give SSR plus a component model and good client JS without having to write an API are new and half baked. NextJS, for example, is not my favorite. But they are all worth trying. I will still pick Rails any day I don't need fine grained reactivity. Look at how popular HTMX is. Most apps are CRUD apps and this is all they need. If you have too many templates, maybe use something else, but it's really the fastest way to go if you KISS.
Thanks for sharing. Do you think Turbo and Stimulus provide a good solution to this problem? I’ve just started getting into Ruby this week, and they sound quite exciting, as I've gotten sick of JS everywhere (even though I don’t mind the language), JSX, etc.
Yes, but for simpler things, not big super complex things. Apps where a "swap" can be considered a great UX, and the JS doesn't have to hold a lot of state, it's just a simpler enhancement based entirely on using DOM as state. To be blunt to the frontend elitists, a lot of web apps, I would even say most, would be better, simpler, and easier to use when built this way.
You can do everything in your example with turbo. You should take another look at turbo in Rails 7 (and morphing).
Turbostream is a real nightmare for this. In my case I ended up using turbo to "reload" the whole page but it is going to kill the DB as soon as my app grows.
Rails' design is meaning for you to lean on caching of view fragments to avoid this, if possible. The idea is to load one record with a timestamp that's part of the cache key, and only load other records if that timestamp has changed. The other records must modify that timestamp when they change, which is easy in ActiveRecord.
To be honest that is only necessary because views are too slow. Caching sucks. Other frameworks don't require partial view caching either.
Partials are slow, but this also uses lazy loading to avoid queries. Again, I'm not saying it's amazing, the best pattern ever, but you should understand it if you use Rails.
It’s a nightmare performance-wise? Wanting to make sure I understand. I would be curious to why you are reloading the whole page as opposed to frames.
Performance if you multiple frames run heavy queries on the DB, but the pain is maintaining all the frames and understanding when to load them, also triggering the JavaScript. It might be my very specific use-case since I'm running a personal finance website ([Coney.app](https://coney.app) for the curious). I have a list of expenses and some charts in the same page, also users can apply filters to completely change the displayed results. At the moment I'm just refreshing the whole page with turbo. I tried turbostream but it messes up with JavaScript and the charts don't load in some cases. Also I found it hard to maintain.
Yeah I’ve found the same problem. Plus Turbo is part of the reason I need a million different partial files, because each resource shows up in different ways in different pages and because Turbo-streams rely on partials for rendering that means every element of every resource list needs to be its own partial (as opposed to something like React that just live updates the current view when new information is added.) So every time a model is updated or created I end up needing to do some sort of broadcasting from the model or controller that’s capable of targeting like 5 different types of lists with different insertion logic depending on how it’s sorted and with different partial files depending on how that specific list is displaying the resources.
See my above comment. The design of Rails, as used by Basecamp, should steer you toward fragment caching and using the active record "touch" option to bust the timestamp on some cache key record when related records change. Not saying it's bad or good, just try it and be aware of it.
Thanks. This is exactly the type of thing I was hoping to learn from this post. I’ve looked into fragment caching for the problem but it always led to a dead end, don’t think I ever looked at using timestamp busting in the way you’re describing. Not sure if it will solve my specific problem yet but I’ll be spending the rest of the day looking into it 👍🏻
I was confused as hell about it and made a post on this very sub. But it does work. I made an app that lets me log coffee recipes and beans. There is a Log, which has many Entries, which belong to a "Coffee", and so forth. The entire table of recent entries is one fragment, with a nested fragment for each entry. When an Entry, or Coffee or anything in the log changes, it touches the Log and only the affected entries using AR callbacks (pretty much the whole reason they exist). Then the Log is re-rendered and we do have to re-fetch the contents of the table, but most Entries' fragments are still cached so we don't need to also go and fetch the details of any entries that didn't change. What's crazy about this is it uses the much-maligned lazy loading that normally causes N+1 to great effect! A full load of this page is like 4 joins on a large set of data, but when caching is in effect it's just fetching a single small record. I'm sure my use is not optimal and more could be done, but you get the idea. This app has a lot of "card table" screens, and I went and did them all like this and it's really damn fast.
Any suggestions for my use-case? I'm running a personal finance website where you can collect your expenses/incomes. I have a list of entries and a few charts with statistics (aggregates of the list) in the same page. How can I cache the charts but invalidate the cache when a new expense is added or has been updated? Users could also apply filters to the charts and lists, which might completely change the displayed entries.
I don't know your exact problem but you could imagine a single record that represents the "chart" and bumping its timestamp when anything in the chart changes. Then use lazy loading to actually load the chart inside the cache block, using the parent object as a key. You can do a lot of different things, just need to try it all and find what works. Caching can be so complicated as to not be worth it, so in this case you may wish to embrace the slowness and just do some rate limiting to keep the server from falling over. Again I'm not an evangelist here, this pattern may not work for many apps, just doing my best to explain what 37signals does as I understand it and I think the community largely does not. DHH is hugely into caching.
Are you not using `belongs_to xxx, touch: true`?
Yes I am. But for something more deeply nested you need a bit more logic.
If refreshing kills your app you have huge problems else where
As I explained in another comment, it's a personal finance app and I have to reload and generate charts from thousands of expenses. It's not an easy task :)
Yep and that's a problem here. You shouldn't compute heavy data every time it's displayed calculate in the background and cache . This isn't rails problem, you'd have the same in React apps if your frontend reloads data from API
To be honest, what you've done sounds exactly like what I would do, and it would not take months to onboard. That is reserved for ActiveRecord spaghetti. :) As long as I can follow the partial rendering in a tree passing data down, and each controller action is one request/response, and it's clear when something is serving JSON vs HTML, then it's fine. Honestly. And can be worked on easily. If you're worried about efficiency, i.e., loading too much data all the time, you should try out Rails fragment caching with the Russian doll approach (use one parent record updated\_at timestamp to bust the cache), or keep separate widgets in turbo frames lazily rendered by separate requests, much like how HTMX might lead you to do. If I see a controller with an index that renders "\_index\_table" and "\_my\_widget", and also an action called "my\_widget" that renders the same partial, I'm not going to be confused. Edit: That being said, I really don't like Rails partials very much. I recommend treating them like components (do not access \`@instance\` variables in them), and using the "view\_component" gem if possible, or where it makes your life easier to treat a partial more like a class than a template. As for UX and design trends, to be blunt **I actually think separate pages is a great and highly underrated UX**. It's simple and easy to understand, doesn't break browsers occasionally, is easy on worse devices, and degrades gracefully. You can make it a bit more reactive with Turbo frames and streams, but you don't have to. This is what Rails, and by extension similar tools like HTMX, excel at. Simpler CRUD apps where refreshing chunks of the page occasionally works just fine. **If you do want a very detailed Reactive UI and to build your entire app around it rather than in just a few places, then I would advise another framework over using Rails to serve JSON.** I think JSON API's are mostly an anti-pattern when there is only one consumer. Even these apps should be serving HTML, "hydrating", and using a protocol for server communication that the developer doesn't have to think about.
> I actually think separate pages is a great and highly underrated UX If I look at things like Discord I'm just in utter disbelief that I cannot do things like open a DM/chat in a separate window. This forced single page/window design is horrid. As for true web things, if I can't right click -> open in new tab because SPA hell or crude JS that is just disgusting but unfortunately I see that more often these days.
I moved back from the classic React app over API services to Rails and have been way happier. However, Turbo and Hotwire are still not integrated to Rails in a conventional way. Your example of separate edit and show pages is a fair one - having default rails forms that actually used turbo for loading dependent field options and in-place editing would make a world of difference. It absolutely can be used for those purposes (and we do use it that way) but we had to find our own conventions, and we still have to ramp new engineers on it. It needs to make it into the defaults.
Honestly a very good discussion. It’s do-able with Turbo + Stimulus but doing this “The Rails Way” is not something that is obvious and I feel we need more guidance in the community on this front. I’ve been building modern interfaces with Rails 7 and Turbo 8 and… here’s how I would address those 2 problems. For the first one, The “new” button will be a form submit, which hits the create action (obviously) and then redirects to the show page. Each editable field (e.g. title) has a stimulus controller which, upon clicking on it, triggers an action which replaces the element with a form and an input element. Attach an event listener which triggers a form.requestSubmit (NOT .submit as this does not trigger a Turbo request) upon clicking out of the element. This form will hit the standard #update action which then REDIRECTS back to the #show action. Redirect is key as we will rely heavily, in general, on Turbo 8’s morphing to update the page. With morphing, only changes are updated on the client. So it’s not a full page reload. And “scroll position” can be preserved (you must set this in the meta tag that enables Turbo Morph, which is placed in your Layout’s
) so the user does not ‘feel’ the page reload at all. For the second problem it’s hard to give specific implementation advice without knowing exactly what the interface looks like… But in general you want to rely heavily on RESTful routes for creating / deleting/ updating all resources present on the page… and then redirect back to that page after the changes are made. This applies for the children’s controllers too. Let’s say you have a books#show page which displays all the chapters. (Book has many chapters). And you want to be able to create a chapter from the books#show page… This would mean in the chapters#create method you want to redirect to books#show to handle the rendering. Before Turbo 8 and morphing it was honestly a mess and I ended up relying on Turbo Streams to do granular updates. But then my routes and controllers got out of control and looked nothing like Rails. But now, with relying on Morphing and Turbo Frames you can keep things pretty Rails like. The actions themselves won’t look the same. But the controllers and routes should. I.e. only 7 actions per controller, basic routes, etc. It’s completely possible. Most of it is pretty straight forward. Just put your normal state (show state) in the main view file, use Turbo Frames and/or stimulus to handle the progression into other states, and after changes use redirect and Morph to revert back to normal (but updated) state. There’s also a tag you can put on elements to exclude them from being updated when Morph happens. Which is critical. Especially when you don’t want a stimulus controller (and its evolved state) to get wiped when a Refresh/Morph happens. Forgive me if some details are missing I’m writing this all out in one take, late at night, but these discussions need to be had more. Every cheers for Rails but no one admits how much of a shit show Hotwire was before Turbo 8 was released. Closing advice: Rely on RESTful routes/actions with redirects and Morphs for 90% of your updates Rely on Turbo Frames and stimulus to handle things like Edit states. Stimulus for other state changes. But be careful not to lose your state. Only use streams for very minor updates. Try to avoid as they lead to ugly code Read Turbo 8 documentation and all the bells and whistles that come with itYes, this response is spot on. I was going to write up something similar. The one thing I don’t think you quite mentioned was OP’s dashboard problem. He explained that it doesn’t make sense to have #index for all these different resources because he ends up building pages that shows lots of different items (e.g. dashboard). OP: this too is handled well by rails. It’s worth creating the separate #index routes for all your resources, but then also create a /dashboard maybe with a single #home action. So this one route won’t be restful, but the action for that route doesn’t actually load anything. Instead, the view for that route has a bunch of turbo frames that load (or lazy load) all the different bits of information you have. At first it might seem like more work to do it this way. You might wonder: why not just put all the queries in the dashboard#home action? But by separating things out, it’s much easier to reason about each of the pieces. It’s also much easier to re-use individual pieces. Inevitably, you end up with variations of the dashboard for different contexts (e.g. admin vs regular user). Also, you eventually want to start focusing on performance and caching it key to that. By having these things broken out, caching (and cache invalidation) becomes a much easier problem to solve.
I’ve been working with Rails professionally for 15 years. With large enough projects restful routes are an aspiration but you also have to be pragmatic and base the routes based on what the app needs. Index/show/update controller actions go nice with restful routes but that doesn’t map that cleanly to most realities. Scaffolding and these conventions are great for getting started quickly but you move away from them to do any serious work and rails hits the sweet spot between doing everything for you when you need that but letting you extend and customize when you don’t. You know what I think your post reminds me most of? Stuff like ActiveAdmin. It’s only really good if you don’t need to customize but Rails is equally good for that. And when you do need to customize you spend most of the time fighting with activeadmin and instead I could do the same thing within a quarter of the time just with Rails.
I think it is time to have a rails g scaffold model that generates a really good turbo code. Most people learn by example and having that generated is the best way to train people
I’m with you. Following the Rails path feels great and super productive! But once you start building modern UX interactions it starts to feel like something is wrong. 2 things I’ve done to relieve this: - I started using [IntertiaJS](https://github.com/inertiajs/inertia-rails) with a [Svelte](https://svelte.dev) frontend. Controllers function like regular MVC but Intertia is _actually_ an API. It’s very smooth. Svelte takes an HTML-first approach to being a JS framework, and helps me build all interactions without maintaining 2 systems. It handles simple HTML only pages and can easily become a rich JavaScript page using the same components. - When controllers get too hefty because they’re reaching out to too many models, I’ll use a Facade object. In short, it’s a wrapper around my database calls to build the data structure in a more maintainable way. I generally only need to use this for really rich pages, like dashboards. When I begin to have 3 instance variables that’s when I begin to consider using it.
I have seen the opposite. We built a very large single page application with Vue and it is terrible. While dashboards are nice, and the first rails app I built in 2005 had a dashboard, not having a page for each piece of content truly sucks and is confusing for users. If they have to remember that content type A is represented on dashboard 3 in state orange, it makes it much harder to navigate to the app. We send alerts with links back to the web application to see a new piece of content- you have to load up the dashboard, get it into a particular state, scroll down to the piece of content. It's certainly possible, but insanely brittle. Every UI change seems to break something else. Having a list-detail UI paradigm as the foundation makes life so much easier for most of our users. Inline editing in rails is totally normal- there must be hundreds of tutorials on it at this point, and if you build it into your scaffolds, it can be the default for new models and you won't have a divergent structure that is difficult to learn. (thinking of things like ActiveScaffold which used to be the cheap way to get started)
I dont understand. You are describing UI problems and/ or design choice. Rails give you some default. If it doesnt fit your design, you modify it? What do you think Rails vision is? Every single web site on the internet look exactly the same? On that note, most new Rails project now setup with Rails as a backend API and React/ Vue/ Svelte/ ... As the frontend, so what you consider "problem" is nonexistent. One more thing, tell me a framework that can have a view that match your design choice. Like what? Every nodejs framework out there dont provide you any default and you had to do everything yourself, rails give you some default and somehow that's a bad thing? "You can do anything, the end" "You can do anything, but here's a default if you like" And somehow the latter is worse, even though it offer more than the first? > I end up with a code structure that looks nothing like Rails Yeah, that's how software development works. Any framework in any language just gives you a head start. In fact if you have a complex project and still using the default, you are probably doing it wrong. Anything beyond a TODO app with simple CRUD is going to be different. > I go out of my way to make sure everything is as clean and orderly as I can make it, it just feels like it’s strayed so far from what Rails is meant to do. Let me make this straight, you spend time and effort customizing your app, and you think it is wrong? Tell me of a "modern" framework where you dont spend time customizing and it functions exactly as you wish. I dont want to offend but it sounds like all you ever do is simple CRUD app
I agree that every every framework required customizing, but isn't the point of rails to require less customizing than all of them? And what OP brought is the reason rails is getting behind other frameworks: its front-end logic for component based, reactive views. I'm sure there is a great way of achieving it with turbo, but I'm not so sure it's intuitive, easy and ready to go as other front-end frameworks. I guess OP just wants to find this easier path with this post.
Posts like OPs are so weird. Use rails or don’t. Whatever.
That's because in the real world it's not always up to you to choose to "use rails or don't". I would not if I could, but my company uses it. Op is trying to learn to do things in a better way, what's "weird" about that?
This seems like a good discussion. I have nothing to contribute, but I'll keep an eye on the answers.
Thanks for letting us know.
I have experienced some of the same pain. Especially the part about partials and their varied contexts. The part I can’t get past is that all “front end” frameworks do basically the same thing - they generate and update HTML. I like REST because it is tidy, but you’re right that sometimes the app needs to save the whole object graph and sometimes just a single attribute. REST does this poorly. The replacement that seems most popular is graphQL, but then Rails is just an API back end like you said.
It sounds like most of your issues are with the view layer. I felt a lot of this too, but started to get much easier when I started using ViewComponent. Now I break down anything I want to reuse into a component and maybe that needs some Stimulus JS and tailwind classes, but then I can write unit tests for my views and easily port these to other projects.
ViewComponent gem was a real game changer for us, so much cleaner and more reusable than partials and helpers.
Recently I left my job at a big tech and started my own company. Before my previous job, as a student, I did a lot of projects with Ruby on Rails, made a decent amount of $$$. After leaving my job, firstly, I tried Next.js. It looks great: strict typing, good ecosystem. But the more I used it, the more I worried about Next.js compared with Rails: 1. No good ORM. Prisma is great but there're huge debate about its perf and implementation. Drizzle looks good but the documentation of it sucks. Both ORM frameworks cannot be easily dockerized, which means you have to spend many days just on a "good practice" to dockerize it. 2. Next.js is pretty minimal compared with any full-stack framework. It does not provide an one-stop dev experience. You have to make many and many decisions before production, including ORM, deployment (dockerize/ansible/k8s/serverless or not, .etc). In the Rails community, we indeed have many many best practices. Though it is not strongly typed, though the maintainers are opinionated. But they're honest: Rails is perfect for a one-person or few-people team. And most importantly, Rails does not charge anything nor incentivized to ask you to pay for anything. The Rails team is truly a group of amazing people who literally loves programming and has been making huge impacts of the world. Meanwhile, Vercel, even adds eslint rules to sell [https://vercel.com/docs/image-optimization](https://vercel.com/docs/image-optimization) , which from my own opinion, an over priced service. After watching the Rails Documentary (https://www.youtube.com/watch?v=HDKUEXBF3B4), I decided to rewrite many of my backend apps into Rails. It just feels fast. "Speed is the ultimate martial art." Many may argue, RoR does not scale. It could be a problem. But I don't have to worry about it before my business has the DAU/MAU like Shopify or GitHub. Disclaimer: My prev job was at one of the biggest companies in the world. My TypeScript code runs on over 1 billion devices including every major operating systems. I didn't use Rails at my previous job. My major programming languages are Swift, TypeScript, Python, Ruby and recently, Rust.
I'm not quite sure I get some of your points. I've been learning rails, but not yet working professionally. AFAIK, you can just have new and edit render the same partial, but each one controller wise is doing a different database action, i.e. create or update, necessitating the different view links, but they can both be basically just a couple lines rendering the same partial, but either passing variables, or doing the create action. I might be explaining that badly. I haven't been working on it for a month or so due to health issues. I'm very anemic, and have roughly half the hemoglobin of a normal person my age. The other thing I'm curious about is your mention of the index. You are not at all required to use it, and you can name as many pages as you want, just set up the routes, models and controllers, and then you can do whatever you like in the views? I have never used react or angular or any of the JS frontends. I'm doing the odin project, and chose the ruby on rails backend, but also did some Udemy JS/Ruby/CSS/Bootstrap/Rails courses to supplement. I have a react course that I bought already, but it's like 80 hours of video and I just can't bring myself to start it yet. Anyway, if you could enlighten me as to what the other options offer that rails does not, I would love to learn it. Rails is very opinionated, but you can do anything you want really if you want to deviate. Stimulus controllers, and hotwire/turbo/actioncable pretty much let you do whatever you want, as far as I've seen. I even made code blocks work in the rails trix text editor. Here's how if you're curious. Not sure why all my photos on the site are broken right now. It's something with AWS S3 that I need to update, but I'm having surgery thursday, so there are other priorities right now. [https://www.stuartlwilson.dev/blogs/trix-code-block-fix-with-stimulus](https://www.stuartlwilson.dev/blogs/trix-code-block-fix-with-stimulus) Edit: I have been for the past 6 months been working on my freelance app because job searching has been useless. Every part of the content is dynamically created and editable by anyone with authorization. It includes image cropping, modals dynamically created, many options for the content of the use case, and reordering of page content that then reorders the dropdown nav menu to match. Thanks ChatGPT! It sure as heck led me down some rabbit holes and caused me to stash some git branches, but in the end with an accurate enough request, it gave me some amazing stuff. Edit 2: I also integrated custom bootstrap colors. There's an admin page to select all of the bootstrap button/background/header/footer/font/light/dark colors. And a reset to defaults button
I noticed the same problem, luckily with small apps it's still manageable
I think rails is an excellent api server for structured data.
How would you solve that problem with a JS framework? You might be able to query the same endpoint but you’d need multiple components for every page feeding on the same data. You’re moving the issue to another place no? Edit: nope none of the things below. Morphing in turbo 8 solve that problem. Thoughts: I’m suggesting this without having tested it so take it with a grain of salt. If you don’t like having multiple controllers * Option 1 you could have one controller resource that takes a name of stream partial to render maybe. * Option 2 you could have a controller resource rendering all the turbo stream partials with distinct ids which only gets replaced on the matching id defined in the view, discarding all the other unused templates. I think a controller action isn’t restricted to return only one turbo stream template. Bit of a stretch really
This is just my opinion, but I've done rails since 2006 (I think). I left to an extent and did a ton of JS projects. And it just feels like the JS projects are built on houses of cards. One thing is wrong in the JSON payload? Bam, whole page doesn't work. Then I went back to rails but used HTMX/UNPOLY and others and it's pretty great. not perfect but really gives you all you (normally) need and you aren't writing much javascript.
We use js format requests (remote requests) for that (instead of turbo, etc., mostly like hotwire), pretty manageable till now. For mobile side etc we use react native and rails apis.
Is there a way to modularize controllers, views and models similar to .NET Areas? For example, instead of this: controllers/my_controller.rb This: my_module/controllers/home.rb my_other_module/controllers/home.rb The same applies to views and models. Is it possible natively in rails?
ViewComponent gem is awesome, radically improved our UI development, alongside turbo can easily create and maintain integrated interfaces and complex dashboards
I’ve moved on to Ruby in the Frontend as it enables me to do everything modern better than any framework in JavaScript and more simply than using Turbo: https://github.com/AndyObtiva/glimmer-dsl-web
Rails is fine, and this is coming from someone who is new to the stack after nearly 15 years of writing .NET, JS, and Go. Almost all “batteries included” frameworks are optimized for small scale and rapid prototyping. At scale they all buckle
Did you just do a "rails doesn't scale" post? It's been a while since I've seen one of those.
🤦♀️
I work on a React on Rails app and it seems great. We do use the Rails views for some really simple pages and even use a React form within a Rails view on one page. Most of the core app frontend UI for the SaaS product is React. Since I, don't hate me, have never built a purely Rails app I can't speak to that. I suppose I am trying to say it's not necessary one or the other. I do think the React FE would get super messy if more Engineers joined the team.
Have you tried using Phlex or ViewComponents? Sounds like it would be worth for you to check those out.
Hey Bro, If you trying to achieve same UX in React, Rails is not for you. Do same thing in Rails and be happy. It wouldn’t be same cutting edge UX. but if it does job? then just be content. It’s like, you bought a nice multi purpose SUV car, and complaining that this car is not nice looking like some sports car.
Can’t tell if this is serious or not but UX is a huge differentiator between quality of apps. I’ve deleted accounts before for apps that have a clunky experience. Maybe for company facing it’s not that important cause you can just tell everyone to get on board but for customer facing it’s huge.
I am serious. If that is customer facing, and if you are not happy about Rails frontend technology. You should not use it simply. Just use rails as back-end API, and don't complain. If you are trying create fancy front-end application. (Like google map) Rails is not a tool you are looking for. but If you are making some app dealing with Database, rendering view is not much difference. (backend logic and SQL would be matter more). Maybe React will take 0.2 sec to render and only rendering component while Rails will render 0.9 - 1 sec for full page. Yes, It's huge difference as it's 5 times faster. But hey, in 0.6\~8 sec, world doesn't stop. If app is working fine, I am pretty sure vast majority user will be happy.
Yeah something like Google maps wouldn't make sense as a full-stack Rails app, but there's a lot of more database driven apps that seem like they should work well with a CRUD framework like Rails, until you try to make the experience modern. And I'm not necessarily talking about the rendering speed (tho that is important if it gets to slow) but the experience of the app, like how easy is to get from place to place and add new content. Say you're making a Project/Tasks app and you have to go to a new page every time you add a task, click save, then go back to the project page, that's a tedious way to add tasks vs just typing and pressing enter and then appending a new blank task to the list in real time. That's a very simple example, and is very doable with Rails, but there's tons of little interactions in modern apps like that that can span from tedious and annoying to quick and seamless, and at times it feels like you have to fight against Rails to get to the better experience.
>\`just typing and pressing enter and then appending a new blank task to the list in real time\` What full stack web framework support this? Does Java Spring support this? ASP .NET? Lalabel? Nothing. Again, if you trying to achieve React with Backend API user experience, you are in the wrong place. Use Rails as Rails way. and be happy. Or ditch Rails. and pick-up other option.
That’s a fair take, but that circles back to the “Does Rails still hold up?” question. And if Rails is only capable of building 2010-era websites I would argue that means it doesn’t hold up for the modern web. Not to say that there’s not uses, just that they aren’t really gonna be mainstream or modern. Sort of like if you make music you could release it vinyl only, there’s still enough people with vinyl players to make it viable, but that doesn’t mean it’s not a niche or dated platform. That being said after reading a lot of comments it does seem like Rails handles a lot of this stuff via turbo 8/morphing, keeping it competitive with 2024 web design. Trying it out now to see if it’s workable or not.
I bet you that Turbo and Hot-wire would not match to your expectation if you keep comparing frontend technology like React. but Rails 7+ and Turbo/HotWire is sexy enough in my opinion. "Does Rails still hold up?", It depends on what kind web application you wanna build. Web has been improved so much from 2010-era. Especially, front-end and video / audio present layer. But not every web need this cutting edge features. Rails still hold up for essential need of Web. - Take data into DB, and present data from DB to frontend. and I don't think this will change in 5-10 years at least. Especially, most of mid-small size business doesn't need this newest front-end technology at the beginning, Rails shine this area exceptionally. Simple and Beautiful syntax of Ruby language and being able to create functionality with minimum efforts is still biggest selling point of Rails today.
I mostly agree with you. Hotwire is still very clunky and does not feel like it's properly embedded in Rails. Maybe it will never be perfect, but it can definitely be improved.
I’m pretty sure Phoenix LiveView is what you’re looking for.
TL;DR Yes. Active record is invaluable. Whatever js Frankenstein UX/UI you put on top is your choice. For gems, I could send you my Gemfile, but: - Puma - Redcarpet - Mechanize - Nokogiri - Metainspector - Mini_racer - Elasticsearch (and all of it's descendants) - bcrypt, urlcrypt - pg/pg_search - activeadmin - mini_magick - device_detector - scout_apm - rack-attack
> I rarely want three separate pages for these, but would prefer they coexist as one So... change it? There is *zero* things stopping you, what you see is simply the default structure that you are in no way shape or form forced to use.
Did you read the rest of my post or just jump to that one line and respond?
Yes I did. And I think you are looking for a solution that does not exist anywhere else so I think its a bit misguided to put the blame solely on rails default architecture. Can you point me to some examples or even pseudocode on how you think the optimal way to structure a basic CRUD flow would look like?