The big difference between the Rails and Ember approach vs most framework communities is the shared community around a shared tech stack.
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.
This sentence surprised me. How does Rails do it?
I never documented types in Rails and all was well, since 2005.
If a function accepts an arbitrary type, as is the case for all inputs in a dynamic language, one needs to document how the function is expected to behave when given x type. This is ultimately the same as type checking in a typed language. It just moves where the documentation is located.
In that move, it is true that you often lose some strictness in the quality of the documentation. The developers who have an active hatred towards their co-workers may even forgo writing documentation entirely. But if you reach that point you've really got people problems, not technical problems.
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.
Like what?
What exactly do you mean by that? It's just a bad ORM all around or is there something specific that is insane about it?
> poorly designed table relationships/indices
What does that have to do with Rails? Poorly designed databases are the fault of the developer(s) who designed them.
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.
I used Rails mainly in the past because I did plain web apps with very little Javascript on the client. Active Record was really handy to quickly develop the data access part of it. But more importantly, they were several books (like the Rails tutorial and others) with practical projects.
IMHO that's what matters the most with a framework, concrete examples, real world project tutorials and a very good documentation.
Although, I still use it in some projects :)
Maybe InertiaJS [0] would help.
Are there any glaring reasons one would not want to use this library?
I understand that it is functional, which seems neat, but how does that translate into better app development?
Also, Phoenix LiveView is absolute voodoo magic the first time you experience it.
Still I am not really sure that the tradeoff makes it worth against non-FP frameworks a la Rails.
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.
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.
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.
I love TypeScript and would love to use it more extensively, but whenever I start a project, I quickly feel like I'm wasting so much time to do something that I'd hope a) it'd be very quick, and b) there would be some general agreement in the community on the right approach. It'd be great to compile what libraries to use, so you can very quickly put something together like you'd be able to do with Rails (e.g. devise, sidekiq, actionmailer, ...).
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.
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.
What's the general vibe on RoR nowadays?