3 ms·
The de-factor Ruby/Rails way to application development is DRY. DRY everything if possible, performance is not 1st priority. Less code >> more performant in ge
by revskill 4y ago
The de-factor Ruby/Rails way to application development is DRY. DRY everything if possible, performance is not 1st priority.
Less code >> more performant in general use case.
TL;DR is: Vendor lock in vs performance lock in. It's hard to not have both at once.
- moomoo11 4y agoAh I see. How do rails-first places handle performance issues, such as this template rendering issue? I'm curious to know what I could have done differently than a re-write.
- revskill 4y agoThe Rails way to scale is caching. In your case, Rails has something called Fragment caching.
- moomoo11 4y agoI see. But that would increase memory usage no? I'll look into it, thanks. And I understand now, the priority is not to chase high performance but have some set of standards that you can adopt without to much bike shedding. I still am not convinced to use rails over Go for my needs, but I am glad you helped me get some more insight.
- zdragnar 4y agoFWIW, my experience on projects with a rails backend is it makes it really easy to fall into performance traps. Active Record is especially bad at encouraging N+1 queries, though the same could be true of many ORMs. A second issue is that if you come from a background where everything is either explicit or obvious, you are in for a world of hurt. I've seen senior developers try to figure out where a particular method is defined by setting a breakpoint, connecting a REPL, then invoking some special methods to get Ruby to tell them the file and line for the source definition. It is just a different way of developing, and (personally) I think the reputation is a bit cult-ish.
- jaxn 4y agoCaching. There are multiple layers of caching in rails, including caching of rendered views/partials.