71–80 of 248 posts
sad to see _why the lucky stiff left out, but I suppose it is what he'd have wanted.
I know this is a possibly unpopular opinion but I don't think one should glorify a sophomoric book as a key Ruby book-- there are others that deserve that title, PickAxe is close, but I'd have liked a book like Whittaker's "C#, Player Guide" for Ruby.
Earlier quoted context omitted.
You're building CRUD apps. The conventions work and are extensible for teams of 1, 10, 100 and 1000s. You are not special and neither is your product. Companies making millions or billions of dollars have used this framework successfully. This level of bike-shedding is what makes conventions necessary especially when dealing with the typical hyper-pedantic software developer. Just the thought of having to debate wher…
> You're building CRUD apps. No. "we" are not.
hmm, sounds like this rails app that one might have not heard bout. You should check it out. Think it's called Basecamp
Did anyone else feel the same way? I kind of want to give it another chance bc I have some side projects that I want to try out, but I find django/python and next/react easier to grok. Maybe I should try harder?
FWIW, I also want to pick up good practices when it comes to engineering a back end, and the good ex-rails engineers I know tend to be really good in general.
Earlier quoted context omitted.
You're building CRUD apps. The conventions work and are extensible for teams of 1, 10, 100 and 1000s. You are not special and neither is your product. Companies making millions or billions of dollars have used this framework successfully. This level of bike-shedding is what makes conventions necessary especially when dealing with the typical hyper-pedantic software developer. Just the thought of having to debate wher…
This is part of the problem with your claim - many of us are not building CRUD apps, we are building complex enterprise software and there are unique challenges to solve.
Rails provides a way to approach CRUD via MVC. Controllers are your API. Models are the connection to the Database. Views are what the controllers render.
If your app doesn't do these 3 things - API, Database, and representation of your API - you don't need rails (I bet you do those three things). Other than that, you're free to layer on whatever architecture via ruby that you want on top of these basic rails constructs. If you don't like it, again don't use rails. It's opinionated for a reason
> if you open up any Rails application, it looks basically the same in structure whether it is the biggest Rails app there is or a new one. I used to love this, untill I started to hate it. I am convinced this is a major contributor to why so many Rails apps turn into an unmaintainable mess over years. Who measures onboarding in hours? It's fine if it takes a day or two to understand the domain. And the framework. An…
i’m preparing a talk for either railsconf or railsworld that puts this question/concern to the community. two times i have deviated from the standard apps/{models,controllers,views} layout and i have profited massively, especially in terms of conceptual integrity and abstraction. all my code lives in app/lib under domain-specific directories. this includes the models. the only part worth separating is the web router…
She is big on separating the business logic from the framework.
Earlier quoted context omitted.
Is there a comparable framework that does what Rails does but is somehow 10x faster? I wouldn't use Rails for everything but the fact that plenty of companies like Shopify are serving millions of requests per second with it shows that it's probably acceptably fast for mega scale apps.
Phoenix framework on elixir does come close to this. Designed by people with a background in ruby and rails, and has much of the same design philosophy. That said, there are areas where Phoenix can't match rails, such as having access to a large developer community and a large existing base of libraries.
https://www.techempower.com/benchmarks/#section=data-r21&hw=...
Earlier quoted context omitted.
You're building CRUD apps. The conventions work and are extensible for teams of 1, 10, 100 and 1000s. You are not special and neither is your product. Companies making millions or billions of dollars have used this framework successfully. This level of bike-shedding is what makes conventions necessary especially when dealing with the typical hyper-pedantic software developer. Just the thought of having to debate wher…
Your model of companies using Rails with 1000s of engineers is almost comically naive. Look at what Shopify and Github have to do to make Rails work for them. Also look at the non Ruby code engineers there are writing and ask yourself why they might be doing it. Rails is not a religion. It can be good at what it does without having to go on a crusade when people point out its substantial limitations.
Earlier quoted context omitted.
>if you open up any Rails application, it looks basically the same in structure whether it is the biggest Rails app there is or a new one I've never worked with Rails, but this sounds amazing. One of the things I really hate about the Node.js ecosystem is that there are no clear conventions, the structure is always different even when the same framework is used. It's a mess. The exception is probably Next.js but it's…
True, nodejs really doesn't have _the_ framework. Python had flask, php is WordPress and RoR. Why is that? Especially since most of the new frameworks copy the ideas of existing frameworks. P.S. Perhaps because a JS framework based off the ideas of rails would be called jails! /s
Express was the default with Node for some years but it was mostly used for APIs to feed front ends. These days lots of people have switched to Fastify but again mostly for APIs.
There's really nothing fullstack in the JS world that can be compared to Rails, Laravel, or Django.
Current fullstack solutions (Next, Nuxt, SvelteKit, etc) in JS are trying to kludge front end components into the server which IMO is a mistake. And I say this as someone who has been doing mostly front end since the 90s.
I tried to like ruby and rails, but when I tried to grok the language, I found it more difficult to follow than python + js (my daily drivers). Did anyone else feel the same way? I kind of want to give it another chance bc I have some side projects that I want to try out, but I find django/python and next/react easier to grok. Maybe I should try harder? FWIW, I also want to pick up good practices when it comes to eng…
Today it’s something I repeatedly try to tell everybody about. It’s just so productive.
Earlier quoted context omitted.
Phoenix framework on elixir does come close to this. Designed by people with a background in ruby and rails, and has much of the same design philosophy. That said, there are areas where Phoenix can't match rails, such as having access to a large developer community and a large existing base of libraries.
Except when you look at benchmarks it's actually not that much faster than rails. https://www.techempower.com/benchmarks/#section=data-r21&hw=...
https://medium.com/@elviovicosa/phoenix-vs-rails-benchmark-2...