Rails is great, and better than ever.
I've spent most of my early years in the field working with Django and Laravel, then moved to frontend doing [all the usual stuff we do nowadays] and this year I was assigned back to a Rails + Hotwire project.
I'm truly amazed how much simpler things are. I feel sad most of us have forgotten how easier things could be, and I'm terrified about new people joining this industry that will never know about how easier things could be because they'll never experience that (as things are right now, who knows the future...).
If you're reading this and never tried Rails, or discarded it because you listened somebody say the usual "PHP is ugly/Rails is dead/JavaScript is messy" give it a try with an open mind and ignore what others say for a moment. I can't recommend it enough.
It might not be the best tool if you have 1k engineers working on the same repository, but as a small team it has no competitors, it's just miles ahead everything else (well, honestly, maybe Laravel is as good).
Rails wins every battle for initial development speed, as the conventions are so thorough and well thought out that nothing even remotely comes close. Laravel is creeping in, but it's not there yet IMO.
LiveView however, scales better (in every sense of the word). It also comes with batteries included (auth, database access, jobs, mailer, complete testing kit etc), little-to-no-DIY-JS, and one of the finest VMs there is (BEAM).
If nothing else, I'm happy that these projects all fight the "let's take a step back"-fight. At $DAYJOB I write React with Relay and the amount of hoops one needs to jump through is exhausting, even though I've been writing frontend JS for many years now and consider myself half decent in it.
Interesting to hear your comparison to Django and that you wouldn’t say they’re on par, at least for you, today. Any particular reasons for preferring Rails over Django?
I love rails. Hardly anyone is using it in my country, and the companies that do are looking for absolute wizards. Because I can’t find jobs using it, I do t get enough experience and lose out to said wizards (after the jobs stay open for 12+ months). Instead, I’m spewing yet more JS into the world because that’s where the demand is :/
A lot of rails devs I know have switched to ember.js [1], because it's also a framework based on conventions rather than having a million third-party plugins that break all the time.
Architecture-wise I really like the ember-data approach because it allows a lot of automations when it comes to left join/right joins of datasets, with an integrated mockup server etc.
But it's not as cool as the other ones I guess, because it just works too well enough!?
I took a 13,000 line Rails 7.0 app and updated it to 7.1. I had to change 1 line of test configuration code to make everything work beyond the diff between 7.0 and 7.1[0].
I would say that's a success for having an easy upgrade path. Now the fun part is going back to refactor some of the code to use the new features in 7.1.
If anyone is curious, I updated my Rails / Docker example app to use 7.1 too https://github.com/nickjj/docker-rails-example. Even though Rails 7.1 comes with a Dockerfile, there's still a lot of opinions you can add such as using Docker Compose to have a fully working out of the box experience that works in development and production -- complete with Postgres, Redis, Action Cable, Sidekiq and more.
Don't get me wrong, I love Rails, and have been using it off and on since Rails 2.
It's a really good framework, and for someone like me who needs to stand up a website from time to time it really is the path of least resistance.
What bugs me is the pain of setting up a new laptop to run Rails. I need node, which means npm. I'm a backend guy, I don't understand how to set up node, what order to do things in, etc. I do it rarely enough that it always seems a fight. Eventually I get it done, but I'm never sure why it finally all comes together.
An installer that puts together all the requirements so my rails just works would be great. The rvm installer will set up rails on top of ruby but won't set up the node system underneath it.
I am hoping for a renaissance of Rails + HTMX with some sprinkles of JS on very interactive pages.
Using Rails with Slim/HAML is an absolute bliss. If you prefer there are also libraries like `ViewComponents` that can facilitate partial rendering even further. Add in some web components and you can build very interactive pages with it. Even use React if you really need it in specific pages.
HATEOAS cuts the complexity of applications drastically. And if you still need APIs, it's extremely easy to respond to different mime types and even have the same endpoints if you desire.
IME the majority of applications that use React don't need it at all. They use React for a couple of menus that have to pop ups. So hopefully once some larger apps start popping up with no React (or only sprinkles of it), it finally clicks for some people how unnecessarily complex our applications are today.
But I already read comments saying they need to switch to React because everyone else uses it. SMH.
The official announcement here: https://rubyonrails.org/2023/10/5/Rails-7-1-0-has-been-relea... has a few more high level details. Looking forward to using some of these new changes (some of the new async query methods will be very useful for some quick performance wins).
Thus there was no way around Webpack Yarn or any other helping tool for JS until now.
Now we have importmaps and good support in browsers for east least ES6 (https://caniuse.com/?search=es6) thus there is almost no need for extra tooling so you can write modern JS.
Don't beat me, but still on rails 4.2 and happy... Gives me everything I need for no/low JS backend SaaS stuff I do for my self and B2B companies, running on low end VPSs...
I hope to see the Hotwire dependency dropped one day. I love Rails and Hotwire, but I wish the latter were also a community tool. When TypeScript support was discontinued, DHH commented:
> This project has been founded, funded, and maintained predominantly by the resources and investment of 37signals. We will set the direction as we see fit...
With TensorFlow recently discontinuing support for Windows, it's very concerning to me that one day one person or organization decides that "we will set the direction".
They don't even try to use nicer language. Don't get me wrong, I respect the work and effort. But 37signals are no saints. There was a scandal, and employee exodus not so long ago.
Hotwire is so deeply integrated into Rails, so Rails is even more 37signals' tool than ever before. Before we had webpack, and JavaScript libraries that sometimes were not easy to use. Now things are easier, but instead of JS libraries we've gotten 37signals dependency, which is VERY concerning.
The Turbo incident was none. It just wasn’t. I would not have dropped TS but the change barely matters. I have only ever seen it used in a script tag and the code reads well enough in vanilla.
The actual incident was a horde of morons piling on top of that repo in the days that followed.
Why not? I have seen or worked on too many projects that would have been better off using Rails/Laravel/Django instead of whatever cobbled together mess was chosen instead.
Not saying that those are the best choice under all circumstances but they certainly aren’t wrong.
Looking at the new Hotwire stuff. It’s neat from a technical perspective but looks dreadful to me. Why double down on a sloppy backend language when hardly any of the needed logic for a web application is backend? Especially when the alternatives include a full stack of TypeScript, a robust, performant, strongly typed, fantastically tooled language?
I was an RoR developer for a decade. These code bases do not age well. The test requirements of loosely typed languages are so much greater. The lack of ability to automate refactors alone is enough to avoid ruby.
Please name a few with the same comfort of having most things built-in. One example: database migrations. In the JS world it is knex all over and it is much less comfortable than ActiveRecord.
I am Rails dev, and I don't like the fact that Rails in every new version has to REINVENT ALL THE WHEELS, ALL THE TIME. That creates huge problems for Rails devs and stakeholders.
Rails is based on Ruby, which is backend language, and Rails should stay more on backend.
That means
- session management
- routing and controllers
- many API options (REST, json-rpc, ...) + JSON object exporters
- ORM, Mailing, etc
- server template renders (ViewCells are still not part of Rails)
- tasks, logging and other helpers
In the same way Rails adopted rake gem as default task runner, without re-inventing it as "ActiveCliTasks", they could have created standardised connector layer that will exchange objects between backend and frontend.
So no Stimulus, TurboLinks, HotWire and other stuff one HAS TO learn and re-learn between versions. Svelte, Vue and React should have been officially supported with thin connectors. Rails server render layer can easily be integrated in any existing frontend tech, as alternative to React server components insanity.
Also, there is no reason to have to have socket connection to pass HTML between server and client, good old RPC is just fine as 99% of big app scaling problems are Database problems, no need for another layers of complexity one has to ensure it works.
I think, in that way Rails could "shine" far into the future, using its strong points but adopting new frontend stuff on the way, not re-inventing it all the time.
And chances are, new Rails projects will just be API backends with React frontends.
Also, if trying to do lightweight Javascripty frontends within the framework is important, we might as well just move to Phoenix. Phoenix is arguably better already... it just requires a moderate jump to learn Elixir (which unfortunately looks very much like Ruby but requires a very different approach to writing).
[+] [-] 0xblinq|2 years ago|reply
I'm truly amazed how much simpler things are. I feel sad most of us have forgotten how easier things could be, and I'm terrified about new people joining this industry that will never know about how easier things could be because they'll never experience that (as things are right now, who knows the future...).
If you're reading this and never tried Rails, or discarded it because you listened somebody say the usual "PHP is ugly/Rails is dead/JavaScript is messy" give it a try with an open mind and ignore what others say for a moment. I can't recommend it enough.
It might not be the best tool if you have 1k engineers working on the same repository, but as a small team it has no competitors, it's just miles ahead everything else (well, honestly, maybe Laravel is as good).
[+] [-] fredrikholm|2 years ago|reply
Rails wins every battle for initial development speed, as the conventions are so thorough and well thought out that nothing even remotely comes close. Laravel is creeping in, but it's not there yet IMO.
LiveView however, scales better (in every sense of the word). It also comes with batteries included (auth, database access, jobs, mailer, complete testing kit etc), little-to-no-DIY-JS, and one of the finest VMs there is (BEAM).
If nothing else, I'm happy that these projects all fight the "let's take a step back"-fight. At $DAYJOB I write React with Relay and the amount of hoops one needs to jump through is exhausting, even though I've been writing frontend JS for many years now and consider myself half decent in it.
[+] [-] tom_walters|2 years ago|reply
[+] [-] ornornor|2 years ago|reply
[+] [-] tenderlove|2 years ago|reply
[+] [-] cookiengineer|2 years ago|reply
Architecture-wise I really like the ember-data approach because it allows a lot of automations when it comes to left join/right joins of datasets, with an integrated mockup server etc.
But it's not as cool as the other ones I guess, because it just works too well enough!?
[1] https://emberjs.com/
[+] [-] brightball|2 years ago|reply
I’m thinking of building a side project with Rails and I’m wondering if they are worth it?
[+] [-] gardenhedge|2 years ago|reply
[+] [-] nickjj|2 years ago|reply
I would say that's a success for having an easy upgrade path. Now the fun part is going back to refactor some of the code to use the new features in 7.1.
If anyone is curious, I updated my Rails / Docker example app to use 7.1 too https://github.com/nickjj/docker-rails-example. Even though Rails 7.1 comes with a Dockerfile, there's still a lot of opinions you can add such as using Docker Compose to have a fully working out of the box experience that works in development and production -- complete with Postgres, Redis, Action Cable, Sidekiq and more.
[0]: https://railsdiff.org/7.0.8/7.1.0
[+] [-] roboben|2 years ago|reply
Rails is great when you stick with the defaults and a land of pain as soon as you leave them.
[+] [-] steve_gh|2 years ago|reply
It's a really good framework, and for someone like me who needs to stand up a website from time to time it really is the path of least resistance.
What bugs me is the pain of setting up a new laptop to run Rails. I need node, which means npm. I'm a backend guy, I don't understand how to set up node, what order to do things in, etc. I do it rarely enough that it always seems a fight. Eventually I get it done, but I'm never sure why it finally all comes together.
An installer that puts together all the requirements so my rails just works would be great. The rvm installer will set up rails on top of ruby but won't set up the node system underneath it.
[+] [-] Draiken|2 years ago|reply
Using Rails with Slim/HAML is an absolute bliss. If you prefer there are also libraries like `ViewComponents` that can facilitate partial rendering even further. Add in some web components and you can build very interactive pages with it. Even use React if you really need it in specific pages.
HATEOAS cuts the complexity of applications drastically. And if you still need APIs, it's extremely easy to respond to different mime types and even have the same endpoints if you desire.
IME the majority of applications that use React don't need it at all. They use React for a couple of menus that have to pop ups. So hopefully once some larger apps start popping up with no React (or only sprinkles of it), it finally clicks for some people how unnecessarily complex our applications are today.
But I already read comments saying they need to switch to React because everyone else uses it. SMH.
One can dream!
[+] [-] conorh|2 years ago|reply
[+] [-] ulizzle|2 years ago|reply
On the front-end it’s been a mess for a really long while now though
[+] [-] gls2ro|2 years ago|reply
I don't disagree, but also front-end was a mess for a long time.
Now Rails (with Rails 7.1 + Hotwired + Importmaps) is a pleasure to work with.
But we had to wait for good support in browsers of at least ES6 + Import Maps.
See the date of this article here: https://web.dev/import-maps-in-all-modern-browsers/ -> 28 March 2023 announcing importmaps is available on all modern browsers.
Thus there was no way around Webpack Yarn or any other helping tool for JS until now.
Now we have importmaps and good support in browsers for east least ES6 (https://caniuse.com/?search=es6) thus there is almost no need for extra tooling so you can write modern JS.
[+] [-] roboben|2 years ago|reply
[+] [-] Pungsnigel|2 years ago|reply
[+] [-] mountaineer|2 years ago|reply
Well, here we go, PR coming up. Even if it has to stack behind the 7.0 one that's been sitting there for months.
[+] [-] kitsune_|2 years ago|reply
[+] [-] damir|2 years ago|reply
If you have time to answer - why would I upgrade?
[+] [-] desireco42|2 years ago|reply
I used to make good money doing upgrades from one version to another as well...
I hear your gripes here... I think with Rails if you run into problems, this is because you created (or someone in your org) them for you.
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] thrillgore|2 years ago|reply
[+] [-] roboben|2 years ago|reply
[+] [-] RomanPushkin|2 years ago|reply
> This project has been founded, funded, and maintained predominantly by the resources and investment of 37signals. We will set the direction as we see fit...
With TensorFlow recently discontinuing support for Windows, it's very concerning to me that one day one person or organization decides that "we will set the direction".
They don't even try to use nicer language. Don't get me wrong, I respect the work and effort. But 37signals are no saints. There was a scandal, and employee exodus not so long ago.
Hotwire is so deeply integrated into Rails, so Rails is even more 37signals' tool than ever before. Before we had webpack, and JavaScript libraries that sometimes were not easy to use. Now things are easier, but instead of JS libraries we've gotten 37signals dependency, which is VERY concerning.
[+] [-] gherkinnn|2 years ago|reply
The actual incident was a horde of morons piling on top of that repo in the days that followed.
[+] [-] crystaln|2 years ago|reply
If someone suggested using Rails for a new project to me today, I would show them the door.
There are so many more mature frameworks in more robust and performant languages.
IMO the only reason to use Rails today is if you’re too uncurious to learn something better.
[+] [-] gherkinnn|2 years ago|reply
Not saying that those are the best choice under all circumstances but they certainly aren’t wrong.
[+] [-] crystaln|2 years ago|reply
I was an RoR developer for a decade. These code bases do not age well. The test requirements of loosely typed languages are so much greater. The lack of ability to automate refactors alone is enough to avoid ruby.
[+] [-] gls2ro|2 years ago|reply
Please name "many more mature" frameworks. I am curious about how many web frameworks are still actively maintained today.
Please note for me, mature also includes age. So you have to state frameworks that are at least older than 2005 (I would also accept created in 2005).
[+] [-] roboben|2 years ago|reply
[+] [-] Alifatisk|2 years ago|reply
[+] [-] throwthrow5643|2 years ago|reply
[+] [-] dinoreic|2 years ago|reply
Rails is based on Ruby, which is backend language, and Rails should stay more on backend.
That means
In the same way Rails adopted rake gem as default task runner, without re-inventing it as "ActiveCliTasks", they could have created standardised connector layer that will exchange objects between backend and frontend.So no Stimulus, TurboLinks, HotWire and other stuff one HAS TO learn and re-learn between versions. Svelte, Vue and React should have been officially supported with thin connectors. Rails server render layer can easily be integrated in any existing frontend tech, as alternative to React server components insanity.
Also, there is no reason to have to have socket connection to pass HTML between server and client, good old RPC is just fine as 99% of big app scaling problems are Database problems, no need for another layers of complexity one has to ensure it works.
I think, in that way Rails could "shine" far into the future, using its strong points but adopting new frontend stuff on the way, not re-inventing it all the time.
[+] [-] michaelteter|2 years ago|reply
Also, if trying to do lightweight Javascripty frontends within the framework is important, we might as well just move to Phoenix. Phoenix is arguably better already... it just requires a moderate jump to learn Elixir (which unfortunately looks very much like Ruby but requires a very different approach to writing).
[+] [-] gls2ro|2 years ago|reply