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.
Which is (arguably) a good thing.
(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.
As for 2, I see this as a common complaint, but Hotwire, Turbo Streams with ViewComponent is a really power combination whose full potential is still being worked out.
As for client-side error checking... why? So I have to maintain validations in two places and ensure they always match?
I don't even understand your 3. Rails has no UI. Do you mean the CSS applied to the scaffolding views?
Please allow me to introduce Sequel (https://sequel.jeremyevans.net/) for your consideration.
For now, I'm good with the little gem that kddnewton put together (https://github.com/kddnewton/rails-pattern_matching).
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).
What's the general vibe on RoR nowadays?
Every now and then I try some new web app framework that catches my eye in some new language and it always seems like its just getting started compared to rails -- and, it is. Worth noting -- rails works great API only as well. I bet Django is pretty good by now too of course, but Rails is really a fantastic tool well suited to task.
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.
It's a problem, but it's not a big problem.
This is not anymore inherent in the language. Gradual typing support for Ruby is now reasonably mature (companies like Shopify with large codebases have adopted it), so it's up to the team do decide if they want to take advantage of it or not.
I've been experimenting with Rbs, Sorbet & Contracts though, they have their potential.
As someone who maintains Rails 3 apps ad infinitum, this is where things break down with Rails applications. You can create applications very quickly with Rails if you stay within the conventions. But as the app grows, that discipline breaks down and the structure starts to suffer.
This is true for a lot of web applications. But I think the problem is worse for Rails because it's so easy to get started and create apps. That ease comes back to bite you -- as a giant legacy Rails app that no one on the team understands and no one is interested in fixing or maintaining.
As I add type annotations to my methods, VS Code and Sorbet are giving me similar feedback to what I get from Typescript projects.
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.
Although, I still use it in some projects :)
Maybe InertiaJS [0] would help.
But now I'm looking at performance, and memory usage, and phoenix looks very appealing from that side.
Now I think I should try pheonix, since both rails and phoenix are new to me, so I can compare.
I understand that it is functional, which seems neat, but how does that translate into better app development?
Rails are good enough to keep Shopify standing for another year of holiday sales. It seems to do that since 2006, so this alone demonstrates that Rails can support you a long way in your multi-billion business.
And if you think: "yes, but Shopify has a big talented team," I feel the need to say back, "Well, when you are at Shopify business size, you will have it too. And Shopify used it when they were small too."
I am not saying Rails fits everything, but if your business fits Rails, that is a great framework to build with.
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.
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.
We're on Propshaft now and I expect far fewer asset issues in the future :P
How do these new tools compare with the old? Versus Webpack, Vite etc?
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.
37Signals have both their Basecamp and Hey.com products which act very much like a single page app but only using Turbo and Stimulus.
I think the rails devs believe that single page apps are overused and the majority of functionality can be done using just the provided tools.
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.
But if you plan to support multiple targets (web, mobile, headless) then you have to develop an api anyway so why not use the best front end framework for each of your targets?
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...
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.
