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

Autotuner: How to speed up your Rails app

railsatscale.com

Post reply on HN
Print view View original

61–68 of 68 posts

Re: Autotuner: How to speed up your Rails app

#61

Post by adeeshaek »

ecshafer wrote: post #13
RowanH wrote: post #11

Earlier quoted context omitted.

I would imagine with cutbacks on spending/investing I think people getting leaner and meaner will re-visit the sheer productivity you can get out of it. Sure shaving the last 10/10ths of having a SPA with simple API based back end gets the ultimate user experience and speed but that cost curve goes up significantly for that last 10th (if you were to compared to an 'old school' Rails app) I can't even fathom what it w…

If you haven't given Turbo and Stimulus a shot, I would recommend it. Way faster to write than React, and super fast and performant. I would say its definitely the way to go with Rails pages that aren't extremely simple.

Could you share the kinds of situations in which you've seen Stimulus and Turbo really shine?

My team inherited a Rails app, which used Turbo and Stimulus and we really struggled to create UIs that matched our design team's vision. We eventually had to move to react + MUI just so that we could build a webapp with a modern look and feel.

None of us come from a rails background, so I'm sure that a big part of our problem came from us trying to bend Rails to our will rather than embracing it - if you have any advice on articles / books that embody the rails approach, I'd be really grateful if you could share them.

Re: Autotuner: How to speed up your Rails app

#62

Post by adeeshaek »

selykg wrote: post #21
andrewmutz wrote: post #7

I love to see how active and vibrant the Rails community is. I used to be concerned about the viability of building new companies in Rails, since the ruby share of languages is so low these days. Based on the still-healthy community and the ridiculous productivity level that a developer can have with Rails 7+ (turbo, morph, stimulus) I still think its a fantastic stack to build a company with.

This thread seems to be getting some views. I'm looking to break into the Rails work, but it seems rough trying to get into a job doing Rails work as a junior, not quite senior role. I have other development experience, primarily in Ruby and Objective-C. Any advice? I know the job market is a bit of a rough one right now as well.

If you are looking to become more competitive as a candidate, I strongly recommend that you look at one of the more popular languages / frameworks instead of focusing on Ruby on Rails.

Despite the major investment made by Stripe and Shopify, my experience is similar to that of this commenter: https://news.ycombinator.com/item?id=40161561 - like them, I've found the open source libraries available in the Ruby + Rails ecosystem to be aging and less well supported than that of more popular languages / frameworks like GoLang / Java / Python.

Rails is delightful to work in and very thoughtfully constructed, and the Rails community is helpful and welcoming. However, if your priority is to maximize your chances at getting hired, I would look towards GoLang / Java / Python etc, which are far less enjoyable to work in but far easier to find jobs for.

Best of luck!

Re: Autotuner: How to speed up your Rails app

#63

Post by parentheses »

bastawhiz wrote: post #23
bigEnotation wrote: post #3

Earlier quoted context omitted.

I wonder what the break even point would be to just have switched to use JVM.

Stripe tried switching lots of code to the JVM and it was a huge disaster. Unless you already have lots of small services with clean interfaces and their own data stores that can be incrementally switched, you spend far more time bending over backwards to keep two systems running (one with some limited parity with the other) in tandem. The cost of running the system is almost never bottlenecked by the performance of…

Stripe and Shopify are such polar opposites. Stripes profit per web request is super high. Shopify has to monetize infrastructure efficiency.

Re: Autotuner: How to speed up your Rails app

#64

Post by [deleted] »

gedy wrote: post #28
bdcravens wrote: post #16

Earlier quoted context omitted.

I remember what happened in the early 2000s and how companies pulled back on the tech they were using. A few years ago I was convinced that fat front-end stacks are a luxury of companies with "free" money, and that the industry would be making tough choices. (To be clear, there are applications that the SPA approach is best for, but many applications are being built that could just as well be served by an old-school…

I feel like this opinion is a bit stale, many companies use tools like NextJS, and it's as productive as Rails and not what I'd call "fat". The biggest issue some folks have are there's no standard ORM yet (maybe Prisma), but ORMs are not so critical with node or js based apps imho.

[deleted]

Re: Autotuner: How to speed up your Rails app

#65

Post by realusername »

gedy wrote: post #28
bdcravens wrote: post #16

Earlier quoted context omitted.

I remember what happened in the early 2000s and how companies pulled back on the tech they were using. A few years ago I was convinced that fat front-end stacks are a luxury of companies with "free" money, and that the industry would be making tough choices. (To be clear, there are applications that the SPA approach is best for, but many applications are being built that could just as well be served by an old-school…

I feel like this opinion is a bit stale, many companies use tools like NextJS, and it's as productive as Rails and not what I'd call "fat". The biggest issue some folks have are there's no standard ORM yet (maybe Prisma), but ORMs are not so critical with node or js based apps imho.

I struggle to see how you could maintain a large backend app without a good ORM to support it, that would be painful for sure

Re: Autotuner: How to speed up your Rails app

#66

Post by bdcravens »

realusername wrote: post #65
gedy wrote: post #28

Earlier quoted context omitted.

I feel like this opinion is a bit stale, many companies use tools like NextJS, and it's as productive as Rails and not what I'd call "fat". The biggest issue some folks have are there's no standard ORM yet (maybe Prisma), but ORMs are not so critical with node or js based apps imho.

I struggle to see how you could maintain a large backend app without a good ORM to support it, that would be painful for sure

It was done before ORM became en vogue using SQL and recordsets. When it got too hairy we'd just put an abstraction in place, similar to how many apps end up doing the same atop the ORM via service objects, etc.

Re: Autotuner: How to speed up your Rails app

#67

Post by realusername »

bdcravens wrote: post #66
realusername wrote: post #65

Earlier quoted context omitted.

I struggle to see how you could maintain a large backend app without a good ORM to support it, that would be painful for sure

It was done before ORM became en vogue using SQL and recordsets. When it got too hairy we'd just put an abstraction in place, similar to how many apps end up doing the same atop the ORM via service objects, etc.

Yeah you always can but you end up with an in-house kind of ORM and those tend to not evolve too well in my experience.

Re: Autotuner: How to speed up your Rails app

#68

Post by ecshafer »

adeeshaek wrote: post #61
ecshafer wrote: post #13

Earlier quoted context omitted.

If you haven't given Turbo and Stimulus a shot, I would recommend it. Way faster to write than React, and super fast and performant. I would say its definitely the way to go with Rails pages that aren't extremely simple.

Could you share the kinds of situations in which you've seen Stimulus and Turbo really shine? My team inherited a Rails app, which used Turbo and Stimulus and we really struggled to create UIs that matched our design team's vision. We eventually had to move to react + MUI just so that we could build a webapp with a modern look and feel. None of us come from a rails background, so I'm sure that a big part of our probl…

How Stimulus and Turbo work together, is basically this: Turbo lets you do partial page updates. Stimulus works a bit like a super light framework for UI only functionality (Toast messages, Error notices, etc). We have made both applications that are pretty stateful and more display and read only, and its way faster to both develop and run than React pages imo. Compared to standard ERB pages in Rails, where if you want to change some value on the page, you need to reload the whole page. Turbo lets you split these up into components with their own controllers, and views, and components. Then only reload the components you need to reload. So you end up with a lot more performance, a lot less redraws, and a lot less database activity for complicated pages.
Post reply on HN