Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ruby on Rails: The Documentary [video]

youtube.com

Post reply on HN
Print view View original

141–150 of 248 posts

Re: Ruby on Rails: The Documentary [video]

#141

Post by PH95VuimJjqBqy »

block_dagger wrote: post #133
PH95VuimJjqBqy wrote: post #123

Earlier quoted context omitted.

I'm going to have go push back on this. I don't like the RoR community, not because they're bad people, but because I think they're insane from a tech perspective. I only occasionally pick up RoR work because of how off-putting my first experience was. But what makes it worse is that every project I've been on (including one I just started on a few weeks ago) has just been a cluster. What you're saying here is true i…

I think you have encountered some projects built by undisciplined teams. That is not a reflection on the framework, rather a reflection on the people improperly using it.

while that's true and obviously you can avoid these problems with any framework with enough discipline, my point is that the community in general isn't disciplined.

I've repeatedly seen the same things over a 15+ year timespan.

Re: Ruby on Rails: The Documentary [video]

#142

Post by cies »

berkes wrote: post #51
yawboakye wrote: post #28

Earlier quoted context omitted.

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…

I've had the pleasure to work on such kinds of Rails apps a few times. It was almost magical, compared to all the other common Rails apps with their ever accumulating fat models, complex controllers, untestable- coupled classes and so on. One had this what you describe: everything in /lib, and the MVC merely delegating to that. MVC downgraded to what it should be: plumbing that binds together your domain stuff. The o…

> compared to all the other common Rails apps with their ever accumulating fat models, complex controllers

i interpret fat model as: what can be move to the model, sits better in the model (directory). things that cannot be moved to the model: the request, the response, the session. not set in stone, but usually this works.

what i regret about older Rails code i wrote was the gluing of all biz logic to ActiveRecord ORM models (akin to, yuck, Hibernate entities), that also contain DOAs, form validation and all business logic. now i tend to split these out: form dtos that do validation, repos with queries, simple record classes, etc.

fat signals homogenous big thing, but is actually where most of the application lives. i coudl call it lib as well.

Re: Ruby on Rails: The Documentary [video]

#143

Post by kugelblitz »

AlchemistCamp wrote: post #41
monooso wrote: post #16

Earlier quoted context omitted.

Laravel would be a better example for PHP, especially as it borrowed so many ideas from Rails.

I agree. The only frameworks I’ve found about as productive as Rails are Laravel and Phoenix. Django and Sails.js both seemed like they were a step down in terms of general productivity, though each had a unique advantage of their own (admin out of the box, websockets & realtime features). I haven’t had a chance to really give RedwoodJS a trial run, but it's the JS-based fullstack framework I'm most curious about.

After a few years, and as my own application has grown, I feel I'm more productive in Symfony than Laravel, because there's less magic, I know where stuff is, and it's more "loosely" coupled components whilst Laravel is "All in or get out". I've been updating my app since Symfony 3.3-ish to now 6.3 and it's been fun! I've had to exchange the auth, the admin section, added new features, killed off features, but I feel with time, that my code has gotten more stable.

Maybe my first update experience with Laravel was a bit of a mess (v4.2 to v5.0 "The recommended method of upgrading is to create a new Laravel 5.0 install and then to copy your 4.2 site's unique application files into the new application. This would include controllers, routes, Eloquent models, Artisan commands, assets, and other code specific to your application."), and I couldn't easily "see" the models' properties and the Facades, that's why I have shy-ed away from it a bit. I have worked with several Laravel applications since then and have gone through the v6 through v10 upgrade cycle and can say it's gotten easier (though I wish they could settle on a release schedule), but my preference is still Symfony.

Plus when I checked out Django, I felt a bit more "at home" (e.g. see Twig templating language and how they used Django templating language as inspiration).

I've worked with Vue.js and AngularJS 1 and Angular 2+, but I'm glad htmx is coming in strong, so I can focus on logic, speed and stability instead of glueing the frontend and backend API together and debugging in the different browsers.

Re: Ruby on Rails: The Documentary [video]

#144

Post by seattle_spring »

jupp0r wrote: post #53
larksimian wrote: post #30

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.

Can confirm. Nothing worse than figuring out what sort of "magic" is affecting a route in a huge Rails app. Oh look, a before_filter in a super class 4 levels up that is defined in an include helper. But wait, why isn't it affecting all calls and only some? Ah there's another chain of filters that you only can know about if you are familiar with the older Rails version API.

Rails is the "goto:" label of web frameworks. It's unbelievable how much it encourages spaghetti code and misdirection directly via its conventions.

Re: Ruby on Rails: The Documentary [video]

#145

Post by tinco »

Pmop wrote: post #105
brap wrote: post #9

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…

Not "any" but "most". I've worked for a company whose RoR codebase/structure looked completely different from the usual because they used a Domain Driven Design-inspired architecture.

This is due to a conflict of philosophies within the RoR community. Basically the clean code enthusiasts (which are also more likely to subscribe to DDD) argue that business logic should not be tied to which specific web application framework you use. So it should basically be in a separate codebase, either in the `lib/` directory or literally in a different project and included into your application as a Gem.

This makes sense from an objective perspective on what constitutes clean code, and I used to believe that this is what a really large enterprise Rails codebase should be refactored to eventually (although I never personally did so).

Rails offers an alternative approach to this however, that is less neat from an objective perspective, but actually follows the Rails principles a lot better and it's called Rails engines. Basically you split your Rails app up into multiple mini-rails apps for each domain called Rails engines, each has the same directory structure as a Rails app and you get the full benefits of a regular Rails app inside each. I used to think this was an ugly approach and I never even considered it, but now after over a decade of Rails development I've made a 180 and I believe this is the way to go.

The "clean" way forces you to construct interfaces between your business logic and the Rails app, basically introducing a lot of extra boiler plate. All for the perceived benefit of making your business logic be abstract of the Rails framework. This violates YAGNI of course, and by a huge margin too. I've never seen the business logic of a Rails app be ported to some other framework in 15 years, the most I've seen is reusing code in a Grape API that was mounted inside the Rails app. And what you give up is Rails' convention over configuration and its predictable structure, and the general documentation and knowledge of that structure that people can carry from job to job.

Re: Ruby on Rails: The Documentary [video]

#146

Post by kaba0 »

AlchemistCamp wrote: post #41
monooso wrote: post #16

Earlier quoted context omitted.

Laravel would be a better example for PHP, especially as it borrowed so many ideas from Rails.

I agree. The only frameworks I’ve found about as productive as Rails are Laravel and Phoenix. Django and Sails.js both seemed like they were a step down in terms of general productivity, though each had a unique advantage of their own (admin out of the box, websockets & realtime features). I haven’t had a chance to really give RedwoodJS a trial run, but it's the JS-based fullstack framework I'm most curious about.

It will probably not be a well-liked comment, but Spring is absolutely there in terms of productivity, and the cool thing about it is that it never leaves your side when it comes to more and more complex requirements. It really has everything and especially Spring Data with JPA is unbeatable.

Re: Ruby on Rails: The Documentary [video]

#147

Post by DoesntMatter22 »

jupp0r wrote: post #44
DoesntMatter22 wrote: post #34

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.

Rails does everything. You can build a stateless API gateway with it. Is it great for that particular use case? No. Your question about frameworks with similar capabilities is pointless because my point was that there are use cases where the capabilities of Rails are not a good fit.

You said it's objectively very slow. My question is relevant because your point begs the question: Slow compared to what?

If you want to give an honest apples to apples comparison then, okay fine, what framework that does everything that rails does is considerably faster?

Is a Ferarri faster than a dump truck? Sure, but they have different uses. Try hauling gravel with a Ferrari. For the class that Rails is in, there isn't anything as feature compatible that is also an order of magnitude faster.

Re: Ruby on Rails: The Documentary [video]

#148

Post by LargeWu »

PH95VuimJjqBqy wrote: post #129
DoesntMatter22 wrote: post #33

Earlier quoted context omitted.

I don't know what exactly the complaint is here. You don't like that Rails has a common structure? > It's virtually impossible to swap AR out for anything else. I've used Mongo and a number of other ORM's, why can you not use other ORM's exactly? This just sounds like you don't like frameworks and want to build things from the ground up, because most of the complaints you make are just not true. Maybe you are just in…

because behavior is an unspoken part of contracts. I can't reasonably swap out an array with a linked list even if the official contracts are the same. this is why things like DAL's are created, they give you an opportunity to deal with the differences in behavior. The issue with frameworks like RoR that use AR throughout is that the queries are sprinkled throughout the codebase, giving no opportunity to fix such beh…

What kinds of queries are sprinkled throughout that are not part of AR, or depend on AR?

Sure, if you are going to swap out AR for another ORM in the middle of an established project you are going to have a bad time, but if one is doing that I have larger questions.

Re: Ruby on Rails: The Documentary [video]

#149

Post by kaba0 »

jen20 wrote: post #98
arnvald wrote: post #77

Earlier quoted context omitted.

Is there any comparably complete framework that does not need any significant adjustments even when it's used by 1000s of developers building the same app?

Probably ASP.NET is as close as it gets.

Or its Java counterpart, Spring.

Re: Ruby on Rails: The Documentary [video]

#150

Post by mattgreenrocks »

PH95VuimJjqBqy wrote: post #123
mosselman wrote: post #2

I had a lot of fun watching this documentary. The one person framework really comes out in the personal story of Toby from Shopify. "From Hello World to IPO". What I also loved is that he mentioned that 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. Sure that can be true for many apps, but in a world of, for example, APIs and f…

I'm going to have go push back on this. I don't like the RoR community, not because they're bad people, but because I think they're insane from a tech perspective. I only occasionally pick up RoR work because of how off-putting my first experience was. But what makes it worse is that every project I've been on (including one I just started on a few weeks ago) has just been a cluster. What you're saying here is true i…

Perfect storm of dynamic typing, needing to keep up with breaking changes, thought leaders that thought leader too much, and a community that seems to push back on anything that calls into question The True Rails Way.
Post reply on HN