8 ms·

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 s

by RowanH 2y ago

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 would have taken to build our startups' product in say React + Node (as an example..) vs OG Rails SSR. I look at a "sort of" competitor in our industry, and their rate of feature development is ridiculously slow by comparison.

ecshafer 2y ago
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.
- nickjj 2y ago
  Yep, and you can also use it with any stack. I've successfully used both with Flask.
- RowanH 2y ago
  Thanks! Definitely aiming to try them out
- adeeshaek 2y ago
  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.
  - ecshafer 2y ago
    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.
rubymancer 2y ago
> I look at a "sort of" competitor in our industry, and their rate of feature development is ridiculously slow by comparison. Seconded. At my org, Ruby/Rails is our competitive advantage. Our 5-6 competitors are all Java/.NET shops -- we deliver fixes and new features dramatically faster and deploy them with ease. It gets noticed. The main downside is rails doesn't scale well re: complexity so regular refactors are necessary (ours is a high-volume big data app). For performance/cost, it took some doing but by strategically moving business logic to higher performance techs we've even managed to get to a great spot there.
- RowanH 2y ago
  While certainly a little polarising the adage of optimise later really comes into play here. We do a lightweight industry specific system that had all the generic stuff (eg time/tasks etc) with some special sauce that makes us stand out. One of our clients said "Mate the rate you guys are adding features - the ERP company we went with they haven't done 1/10th of what you've done in the last year. Can you implement full multi-level bills of materials? " I said "no, can't do that - that's huge". A weekend later of experimentation (thanks to one very kick-butt gem on that has an amazing way of managing trees) "actually, we may just be able to - it's going to be a long road though - setting expectations..." A period of time later we've now implemented a full BOM planning/tracking system, tested well upto and beyond the numbers of items these types of companies expect. To the point they cancelled their renewal with a big/established ERP vendor and went with us instead. There's definitely some instances where speed to market trumps everything else. We can go optimise queries later on. What's been fascinating is I left my day job 2 years ago (to the month). We've gone from unheard of to becoming the market leader in our space. There is absolutely no way that could have been done with any other stack (without spending 5x the money - and I argue that co-ordinating a bigger developer team it almost wouldn't matter what money you throw at it, it gets exponentially harder getting everyone on the same page for delivery). At my old workplace I couldn't convince the .NET team for love nor money to look outside the box.
  - neonsunset 2y ago
    Because Ruby and especially RoR is a strict downgrade in every dimension compared to .NET. Now, these developers could have been using old .NET Framework, in which case we usually pretend they don’t exist because it’s like stubborn Python 2 of .NET that is otherwise the most productive platform for back-end (with really, really good performance).
bdcravens 2y ago
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 PHP and Jquery app)
- gedy 2y ago
  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.
  - bdcravens 2y ago
    I do like how NextJS has done a good job of bridging the gap between SPAs and classical back-end apps (for example, file-based routing). My understanding (with limited experience) is that the deployment story is great for Vercel, and less so for other platforms (requiring you to own a lot of the build pipeline, which is one of the bigger pain points of modern JS)
  - deleted 2y ago
    [deleted]
  - realusername 2y ago
    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
    - bdcravens 2y ago
      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.

by RowanH 2y ago

ecshafer 2y ago

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.

nickjj 2y ago
Yep, and you can also use it with any stack. I've successfully used both with Flask.
RowanH 2y ago
Thanks! Definitely aiming to try them out
adeeshaek 2y ago
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.
- ecshafer 2y ago
  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.

rubymancer 2y ago

> I look at a "sort of" competitor in our industry, and their rate of feature development is ridiculously slow by comparison. Seconded. At my org, Ruby/Rails is our competitive advantage. Our 5-6 competitors are all Java/.NET shops -- we deliver fixes and new features dramatically faster and deploy them with ease. It gets noticed. The main downside is rails doesn't scale well re: complexity so regular refactors are necessary (ours is a high-volume big data app). For performance/cost, it took some doing but by strategically moving business logic to higher performance techs we've even managed to get to a great spot there.

RowanH 2y ago
While certainly a little polarising the adage of optimise later really comes into play here. We do a lightweight industry specific system that had all the generic stuff (eg time/tasks etc) with some special sauce that makes us stand out. One of our clients said "Mate the rate you guys are adding features - the ERP company we went with they haven't done 1/10th of what you've done in the last year. Can you implement full multi-level bills of materials? " I said "no, can't do that - that's huge". A weekend later of experimentation (thanks to one very kick-butt gem on that has an amazing way of managing trees) "actually, we may just be able to - it's going to be a long road though - setting expectations..." A period of time later we've now implemented a full BOM planning/tracking system, tested well upto and beyond the numbers of items these types of companies expect. To the point they cancelled their renewal with a big/established ERP vendor and went with us instead. There's definitely some instances where speed to market trumps everything else. We can go optimise queries later on. What's been fascinating is I left my day job 2 years ago (to the month). We've gone from unheard of to becoming the market leader in our space. There is absolutely no way that could have been done with any other stack (without spending 5x the money - and I argue that co-ordinating a bigger developer team it almost wouldn't matter what money you throw at it, it gets exponentially harder getting everyone on the same page for delivery). At my old workplace I couldn't convince the .NET team for love nor money to look outside the box.
- neonsunset 2y ago
  Because Ruby and especially RoR is a strict downgrade in every dimension compared to .NET. Now, these developers could have been using old .NET Framework, in which case we usually pretend they don’t exist because it’s like stubborn Python 2 of .NET that is otherwise the most productive platform for back-end (with really, really good performance).

bdcravens 2y ago

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 PHP and Jquery app)

gedy 2y ago
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.
- bdcravens 2y ago
  I do like how NextJS has done a good job of bridging the gap between SPAs and classical back-end apps (for example, file-based routing). My understanding (with limited experience) is that the deployment story is great for Vercel, and less so for other platforms (requiring you to own a lot of the build pipeline, which is one of the bigger pain points of modern JS)
- deleted 2y ago
  [deleted]
- realusername 2y ago
  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
  - bdcravens 2y ago
    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.