I love Rails and how simple and boring[0] it is, and appreciate how it keeps evolving and growing. I've dabbled with some Javascript frameworks and Elixir/Phoenix, but always come back to Rails and forget just how fast and productive I can be. A lot of people complain about it, but I feel like Active Record just can't be beat, and helps me feel so productive. Add Stimulus and Turbo and the level of UI fidelity possible is impressive.
You can like rails, but calling it boringly simple is highly misleading. I think, generously, something like "complex but fully-featured" might be accurate.
As a reference point, the top 2 rails books on amazon are 900 and almost 1100 pages.
I say this to warn those who are looking for something minimalist and quick to learn -- Rails does not fit the bill.
I love how they focus on simplicity and are not afraid to cut stuff out. Often times, software projects get more complicated over time. Rails seems to get simpler.
(1) IMHO they've flubbed the progressive typing. I'm spending some time learning Typescript and React. And it's amazing. The type system is flexible, powerful, and works well with an IDE. It's just way faster to write when code gets complexer. The fact that it's null and type safe is the cherry on the top. Amazing that Javascript with all of it's warts can be turned into this.
(2) They've never really got the front end story right. Coffeescript was a dead end, then Turbolinks was the thing, and now it's Hotwire. None of them are really right. Rails will always be a primary SSR paradigm. They just need an easy way to do basic dynamic things like show/hide fields and form error checking clientside. Ideally something written in Ruby and well integrated into the form builder.
A bonus for (3) is that the Rails UI is ugly out of the box. Wish they'd have more integrated UI components that are production ready.
I was pretty sad to see the pattern matching PR reverted for 7.1 [0], but I guess the Rails team wants to make sure they nail the execution (?) even if that means being late to the pattern matching party, which is arguably one of the best additions to Ruby since the 1.9.3 hash syntax.
Yup, I was hoping this would make it to 7-1 but I suppose there were too many cases to consider.
I wonder if certain features could be marked as "experimental" by Rails core like they do in Ruby, and include them without the promise that the API would be stable (or even be present at all in the future).
I’ve never seen a more productive stack. Enables me to build complete apps as a single dev - which would take 2x-5x of the time and effort if using separate front end apps. Ruby makes me happy when I use it. Hotwire and Stimulus let me create front end interactions without a separate SPA. The ecosystem is mature and well maintained. Absolutely love it.
Because of lazy evaluation, type issues persist though. Plenty of instances of trying to call string methods on integers, and array methods on nil, and Rails devs in denial that that's a big problem as the app continues to grow.
I love TypeScript, but Rails has a wonderful ecosystem of libraries that just feels unbeatable for the backend. For some reason (hot take incoming) the JS community seems to hate working with each other and improving existing libraries. The Ruby community seems to rally around improving our libraries (gems) rather than reinventing them every year.
I recently tried Nextjs and Remix to explore other stacks since I've been using Elixir and Phoenix since 2016.
You won't find the dev UX you take for granted in Elixir and Phoenix.
Endless routing options, background jobs? Just install Squirrel and yadabadabadoo or just use AWS SQS(https://old.reddit.com/r/nextjs/comments/qspw4v/how_to_do_ba...). What about solid backend processes? Can I call those in some kind of repl? In Elixir I can just go `iex -S mix phx.server` and `MyModule.foobar("test")` and bada bing I'm all set. What about logging? Wait I need to decide and configure a logger? I also need to decide and configure what to output to? What about a nice ORM? Prisma looks good, set that whole thing up from scratch, I need to await, but special considerations need to be thought of when iterating through a collection? Promise.all vs for..of? I iterated an array and want to save it to the DB but it's running out of connections (https://github.com/prisma/prisma/discussions/16884)? Why do I even need to think about this?
Really curious to hear your counterpoints to this because granted I am quite new to backend typescript.
Still using it, still highly productive. Not doing as much Rails work as I was 10 years ago but that's due to a change in the nature of my business. We still use it and Sinatra for the bulk of our Internet-facing and internal stuff.
At the backend side, it makes easy to build websites. However, the UI layer is a bit complex to integrate with common framework libraries like Vue and React.
Switched to Elixir/Phoenix a few years ago and have never looked back. Absolutely a 100% improvement on Rails in every way (except the availability of work!)
Rails is unfortunately much slower, and it’s quite coupled to the concepts of server-side rendering and OOP MVC. Making Rails work with a modern frontend feels pretty hacky compared to using a full-stack TypeScript framework.
I went from a full stack typescript project to a rails project and honestly I hate it.
The Ruby language is great if you want to jerk off about how concise your code is but programmers end up creating overly abstract, write-only code.
There’s so much magic that it’s hard to trace the code to see where stuff comes from.
Abstractions are over-engineered. Serializers should be simple, async functions that are easy to step through and debug. Instead you have serializer relations? Delegates, etc.
Don’t even get me started on updating rails itself. It’s a massive pain every time and you quite often see projects that are multiple major versions behind.
In typescript it’s common to integrate multiple independent libraries into your own framework. This is great because if I need to update my database library I can focus on that specific part of the code. Updating rails means everything could potentially break.
Great to see so many new features in Rails. Tbh, one of the reasons I use it for certain backend projects is how simple to do complex things.
Managing files and image variants is a pain when developing a site. Rails make it easy and even adds more features around.
However, I still think the UI layer is too coupled to the backend. Webpacker was a try, but I understand why it's deprecated. I would go on supporting common frameworks, even if it's just a template to organize the code.
Finally upgraded some internal applications to Rails 7 this month, and I was very happy with the asset pipeline changes. Rails' asset pipeline management hasn't really meshed with our development strategies for CSS and JS for a long time, and it felt like we were always fighting with trying to make our process fit Rails' expectations.
We're on Propshaft now and I expect far fewer asset issues in the future :P
I am really excited about the possibility that Rails finally get something in the way of ActiveDeployment. This tweet https://twitter.com/dhh/status/1604856555848884225 and the commited changes make me wish and wonder.
My impression is that there are two ways to use rails:
1. Your frontend js needs are pretty minimal and you don't want something approaching a single-page app. In this case, you lean into Turbo and Stimulus to have rails do most things for you that would previously have been done with some a heavy-weight react-based frontend.
2. Your frontend js needs are significant and you do want a single-page app. In this case, ignore/disable turbo + stimulus. Instead, build your rails app as just a json API and then have a separate project for your frontend built using a dedicated frontend build tool like vite/CRA/webpack/etc.
On one hand, I feel like the turbo/stimulus stuff is the rails community preferring to pretend that the JS world doesn't exist. On the other hand, maybe it's really just the rails world embracing the above dichotomy: they're tools for doing some light frontend work with no JS, and an acceptance of the fact that if you want an SPA, there are better non-rails tools that you'll wind up using anyway.
We went with esbuild and regardless of speed (it's way faster) the main reason I like it is because the config is tiny and I actually understand what it's doing. Our Webpacker config was big and fragile by comparison.
Is Rails anti Typescript? It’s weird to see most other JS environments move to Typescript by default, while Rails now now ignores the ability to use it without jumping through hoops.
Depending on what your app is, I've found server-side rendering to be superior in nearly every way. I don't use Rails but Django is the same way. Django templates, bootstrap, jQuery and sprinkle in a little bit of HTMX here and there and my productivity has never been higher.
> Is Rails anti Typescript? It’s weird to see most other JS environments move to Typescript by default, while Rails now now ignores the ability to use it without jumping through hoops.
Have you not paid attention to the direction Rails is going? Hotwire (Rails' default front end) is all amount rendering HTML directly (not via JS) and using the absolute bare minimum amount of vanilla Javascript (with Stimulus). It's not React... So why would it need TypeScript's features and added complexity?
The whole point is using vanilla ES6 without a compilation step...
Webpacker was a wrapper for webpack, which was an attempt to make webpack easy to use but instead added unnecessary complexity.
You can use Rails with React/Vue + TypeScript pretty easily by using something like rails-esbuild or vite_ruby.
I'm currently working on a project with Rails, React, TypeScript, Vite, and InertiaJS and have been very much enjoying it, especially now that Inertia supports SSR.
I just started a new Rails app for a side project and while Webpacker has been retired, there are still options for Typescript. For example, I'm using esbuild and it works with Typescript out of the box - no hoops to jump through.
I'm not on the RoR stack, but I think it doesn't generate a lof of buzz today because it's no longer the flashy new toy (IMO rust, go, kubernetes, a gazillion of react components in the UI, elixir, etc. took its place of "guess what, now we are running this!").
It's a battle tested and stable framework and I would use it anyday, but you no longer read much about it on the news, junior devs are not trying to pitch it as the next silver bullet. So, to be short, it's lacking buzz and online engagement. The tech is all there, the fad has passed.
I think you've gotten downvoted because it wasn't true when Rails 1.2.0 was released on Ruby 1.8, it wasn't true 10 years ago, it wasn't true 5 years ago and it still isn't true today. It's a meme, a synthetic reputation, one based in FUD, with nothing to back it up. Countless businesses have been built on Rails. All successful code regardless of language and framework evolves to fit emerging needs.
Also, the onus isn't on any community to 'prove' to outsiders that their thing can meet the demands of skeptics. It never will, they will find another reason, and then another one after that to fuel their FUD.
So when you write what you did in this thread you're not really, in my view, contributing to the conversation. You're just repeating something you've heard and this far in, it just feels grating.
I am curious, what do you think is what holds Rails from being useful for going beyond the MVP. In 15 years I've seen my fair share of Rails projects going to production and keep evolving with the business, and not in the startup world.
ghiculescu|3 years ago
bradgessler|3 years ago
mike1o1|3 years ago
[0] https://boringrails.com/
jonahx|3 years ago
As a reference point, the top 2 rails books on amazon are 900 and almost 1100 pages.
I say this to warn those who are looking for something minimalist and quick to learn -- Rails does not fit the bill.
maxpro|3 years ago
shafyy|3 years ago
treis|3 years ago
(1) IMHO they've flubbed the progressive typing. I'm spending some time learning Typescript and React. And it's amazing. The type system is flexible, powerful, and works well with an IDE. It's just way faster to write when code gets complexer. The fact that it's null and type safe is the cherry on the top. Amazing that Javascript with all of it's warts can be turned into this.
(2) They've never really got the front end story right. Coffeescript was a dead end, then Turbolinks was the thing, and now it's Hotwire. None of them are really right. Rails will always be a primary SSR paradigm. They just need an easy way to do basic dynamic things like show/hide fields and form error checking clientside. Ideally something written in Ruby and well integrated into the form builder.
A bonus for (3) is that the Rails UI is ugly out of the box. Wish they'd have more integrated UI components that are production ready.
kc22mr|3 years ago
Please allow me to introduce Sequel (https://sequel.jeremyevans.net/) for your consideration.
ezekg|3 years ago
For now, I'm good with the little gem that kddnewton put together (https://github.com/kddnewton/rails-pattern_matching).
[0]: https://github.com/rails/rails/pull/45553
drchiu|3 years ago
I wonder if certain features could be marked as "experimental" by Rails core like they do in Ruby, and include them without the promise that the API would be stable (or even be present at all in the future).
orf|3 years ago
brntsllvn|3 years ago
What's the general vibe on RoR nowadays?
andrei_says_|3 years ago
brink|3 years ago
Most people that use it are fine and productive.
Because of lazy evaluation, type issues persist though. Plenty of instances of trying to call string methods on integers, and array methods on nil, and Rails devs in denial that that's a big problem as the app continues to grow.
kshahkshah|3 years ago
ezekg|3 years ago
sergiotapia|3 years ago
You won't find the dev UX you take for granted in Elixir and Phoenix.
Endless routing options, background jobs? Just install Squirrel and yadabadabadoo or just use AWS SQS(https://old.reddit.com/r/nextjs/comments/qspw4v/how_to_do_ba...). What about solid backend processes? Can I call those in some kind of repl? In Elixir I can just go `iex -S mix phx.server` and `MyModule.foobar("test")` and bada bing I'm all set. What about logging? Wait I need to decide and configure a logger? I also need to decide and configure what to output to? What about a nice ORM? Prisma looks good, set that whole thing up from scratch, I need to await, but special considerations need to be thought of when iterating through a collection? Promise.all vs for..of? I iterated an array and want to save it to the DB but it's running out of connections (https://github.com/prisma/prisma/discussions/16884)? Why do I even need to think about this?
Really curious to hear your counterpoints to this because granted I am quite new to backend typescript.
bambataa|3 years ago
systems_glitch|3 years ago
angelmm|3 years ago
Although, I still use it in some projects :)
redox99|3 years ago
chrisbaker98|3 years ago
unknown|3 years ago
[deleted]
DiNovi|3 years ago
mplewis|3 years ago
Alifatisk|3 years ago
serverholic|3 years ago
The Ruby language is great if you want to jerk off about how concise your code is but programmers end up creating overly abstract, write-only code.
There’s so much magic that it’s hard to trace the code to see where stuff comes from.
Abstractions are over-engineered. Serializers should be simple, async functions that are easy to step through and debug. Instead you have serializer relations? Delegates, etc.
Don’t even get me started on updating rails itself. It’s a massive pain every time and you quite often see projects that are multiple major versions behind.
In typescript it’s common to integrate multiple independent libraries into your own framework. This is great because if I need to update my database library I can focus on that specific part of the code. Updating rails means everything could potentially break.
Oh and there’s no type system so good luck.
angelmm|3 years ago
Managing files and image variants is a pain when developing a site. Rails make it easy and even adds more features around.
However, I still think the UI layer is too coupled to the backend. Webpacker was a try, but I understand why it's deprecated. I would go on supporting common frameworks, even if it's just a template to organize the code.
andrei_says_|3 years ago
Alifatisk|3 years ago
systems_glitch|3 years ago
We're on Propshaft now and I expect far fewer asset issues in the future :P
juanse|3 years ago
texxtxxet|3 years ago
How do these new tools compare with the old? Versus Webpack, Vite etc?
fishtoaster|3 years ago
1. Your frontend js needs are pretty minimal and you don't want something approaching a single-page app. In this case, you lean into Turbo and Stimulus to have rails do most things for you that would previously have been done with some a heavy-weight react-based frontend.
2. Your frontend js needs are significant and you do want a single-page app. In this case, ignore/disable turbo + stimulus. Instead, build your rails app as just a json API and then have a separate project for your frontend built using a dedicated frontend build tool like vite/CRA/webpack/etc.
On one hand, I feel like the turbo/stimulus stuff is the rails community preferring to pretend that the JS world doesn't exist. On the other hand, maybe it's really just the rails world embracing the above dichotomy: they're tools for doing some light frontend work with no JS, and an acceptance of the fact that if you want an SPA, there are better non-rails tools that you'll wind up using anyway.
petepete|3 years ago
marlomajor|3 years ago
stevebmark|3 years ago
Is Rails anti Typescript? It’s weird to see most other JS environments move to Typescript by default, while Rails now now ignores the ability to use it without jumping through hoops.
VWWHFSfQ|3 years ago
Mikeb85|3 years ago
Have you not paid attention to the direction Rails is going? Hotwire (Rails' default front end) is all amount rendering HTML directly (not via JS) and using the absolute bare minimum amount of vanilla Javascript (with Stimulus). It's not React... So why would it need TypeScript's features and added complexity?
The whole point is using vanilla ES6 without a compilation step...
cachecrab|3 years ago
You can use Rails with React/Vue + TypeScript pretty easily by using something like rails-esbuild or vite_ruby.
I'm currently working on a project with Rails, React, TypeScript, Vite, and InertiaJS and have been very much enjoying it, especially now that Inertia supports SSR.
mike1o1|3 years ago
unknown|3 years ago
[deleted]
aliqot|3 years ago
[deleted]
DoctorDabadedoo|3 years ago
It's a battle tested and stable framework and I would use it anyday, but you no longer read much about it on the news, junior devs are not trying to pitch it as the next silver bullet. So, to be short, it's lacking buzz and online engagement. The tech is all there, the fad has passed.
cguess|3 years ago
kshahkshah|3 years ago
Also, the onus isn't on any community to 'prove' to outsiders that their thing can meet the demands of skeptics. It never will, they will find another reason, and then another one after that to fuel their FUD.
So when you write what you did in this thread you're not really, in my view, contributing to the conversation. You're just repeating something you've heard and this far in, it just feels grating.
mokkol|3 years ago
jrmg|3 years ago
https://docs.joinmastodon.org/dev/overview/
pantulis|3 years ago
CoachRufus87|3 years ago
texxtxxet|3 years ago
HN makes downvoted posts so low-contrast they're nearly illegible for me