8 ms·

Currently stuck on a fairly large code base on rails 6 with a ton of react and trying to upgrade to the new “non”-JS way with Hotwire. Wish me luck Rails is gr

Currently stuck on a fairly large code base on rails 6 with a ton of react and trying to upgrade to the new “non”-JS way with Hotwire. Wish me luck Rails is great when you stick with the defaults and a land of pain as soon as you leave them.

yxhuvud 3y ago
Don't upgrade your architecture all at once. First bump yourself to rails 7 (including any other gems you can upgrade), then do any other changes you want.
FBISurveillance 3y ago
I've been doing Rails since 2005 and love it, but - and that's just my personal preference! - I wish they'd have a stable release cadence (calver like vscode maybe?) and a clearer roadmap/governance. Maybe it's just me but I just don't like DHH's governance lately. Not in a bad way, but following him on Twitter I just no longer respect him.
- itake 3y ago
  Coding in rails since 2012 here. I lost faith in rails at 5.2. Active storage was so terrible.
  - roboben 3y ago
    Looking forward to see if and how it evolved in rails 7. In 6 it was really bad too and my tests are flaky because of some weird active storage async stuff. Can't find the id of blobs I have no idea
  - nerdwaller 3y ago
    What is terrible about active storage?
    - itake 3y ago
      My memory is fuzzy, but... 1. all data flow through the rails app (no pre-signed s3 upload or download links for direct uploading). 2. no support for CDNs (I think newer rails versions added support) 3. blobs and attachments were unnecessary abstractions. 3a. Querying was annoying (extra joins) and easy to add n+1 queries. 3b. In my app, images are moderated and it was unclear where to put the moderation metadata (on blobs? attachments? create a new table? why so many tables?) or `deleted_at` type columns. 4. GraphQL gem didn't support it: https://github.com/rmosolgo/graphql-ruby/issues/1777 https://github.com/rmosolgo/graphql-ruby/issues/1777
      - dham 3y ago
        1. Rails has had direct upload since it introduced Active Storage. No one has uploaded files through their servers in a decade 2. What do you mean? Point whatever CDN you want at your origin 3. Maybe 3a. Yes 3b. Metadata or a new table 4. GraphQL is the single worst technology that has ever been adopted. We adopted at my company...twice. Twice we made the same mistake now we're stuck with it for mobile clients. In fact we're stuck on the old Graqphl RB gem that used a DSL instead of classes, which also blocks our Rails upgrade. We've been able to revert everything back to good ole Rest for another part of the app. Be cautious adopting technologies of large companies.
        itake 3y ago
        1. You are correct for upload, but not for download. Looks like rails 7 added support for presigned urls: https://blog.saeloun.com/2021/09/14/rails-7-adds-expiring-urls-to-active-storage/ https://blog.saeloun.com/2021/09/14/rails-7-adds-expiring-ur... 2. CDN support is via monkey patch: https://github.com/rails/rails/issues/44136 https://github.com/rails/rails/issues/44136 3. yep 4. yep
- maxehmookau 3y ago
  > Maybe it's just me but I just don't like DHH's governance lately. It's not really governance, that's kinda the problem. To be fair, he never claimed that he was providing governance. Rails was extracted from basecamp. The impression I get is that he sees Rails as a gift to the community created from the profit-making Basecamp. Which is great; and I appreciate the fact that I've been able to build a career using Rails. But there is no governance really. Rails goes in the direction that 37signals wants it to, which is largely pretty good. You and I don't get much of a say in it though; especially if DHH disagrees.
ywain 3y ago
I'm working on a fairly recent Rails 7 code base. We initially started using Stimulus, but are now considering switching to React for a few reasons: - if you're looking to hire frontend engineers, the candidate pool for React is a few orders or magnitude bigger - it's getting harder and harder to find vanilla JS packages that you can wrap in Stimulus controllers for common tasks, compared to finding React packages - Stimulus doesn't really offer a way to write unit tests for your controllers. With React, you can use jest and react-test-renderer like normal. Additionally, the recent Turbo TypeScript debacle did not instill confidence in the long term stewardship of the Hotwire ecosystem. We're still on the fence about it. Stimulus does feel like a very Railsy way to write frontend code, which is definitely a plus for small teams of people who're already familiar with Rails.
- sibeliuss 3y ago
  Comparing the two: I have a hard time understanding how one could write FE code using classes (Stimulus) in 2023, when simple functions with inputs and outputs are there for the taking. It's just asking for trouble and hidden complexity. Choose wisely!
  - 0xblinq 3y ago
    > when simple functions with inputs and outputs And the state library, and the hooks for side effects, and the SSR, and the hydration, and the VDOM, and... It's not that simple.
    - pulse7 3y ago
      Functional/OOP flamewar is starting...
      - sibeliuss 3y ago
        On the FE, this is already a settled topic. Who wants to go back to `this`? Um... nobody.
    - mardifoufs 3y ago
itake 3y ago
I lost faith in rails JS integrations. I either do SSR with slim or do API only with a separate frontend. Rails changed direction too many times trying to do JS (coffee script, asset precompiling, webpack, etc)
- roboben 3y ago
  What is SSR with slim?
  - groggo 3y ago
    I think they mean Server Side Rendering (normal rails controllers/views), and Slim is just the name of the templating engine. It's a little nicer than the default ERB. https://github.com/slim-template/slim https://github.com/slim-template/slim There's also SSR with react and other js frameworks, but I don't think that's what they meant.
    - aaronbrethorst 3y ago
      I haven't used Slim before, but looking at the examples shown on the repo's README, it immediately brought to mind the thought experiment: 'what if Haml but Yaml?' n.b., I've been building Rails apps since 2007. I was a diehard Haml user up until about 2021 when I made an all-in bet on Tailwind and had to switch back to ERB because Haml with Tailwind felt too obtuse.
      - andrei_says_ 3y ago
        I’ve used slim for years and it’s incredible. Writing erb now feels painful. Slim is clean, terse, and correct. The only downside is I am now spoiled.
      - petepete 3y ago
        Slim is really nice for some things but the moment you want to style words within sentences or paragraphs it gets really messy and you have to start using unintuitive syntax like `|<` or `|<>` to get the spacing right. You can of course just drop to `markdown:`. Still, I use it where I can on personal stuff, but tend to opt for Erb when collaboration with others is needed.
eikenberry 3y ago
> Rails is great when you stick with the defaults and a land of pain as soon as you leave them. You just described every framework. Frameworks are great if your application is fairly simple and aligns with its way of doing things. Libraries are where to look if you need a more complex, flexible setup.
- jshen 3y ago
  I've worked on tons of old code bases over decades. I've never seen a library based one that's in good shape either. They usually evolve into some half baked homegrown framework that no one understands.
  - bambax 3y ago
    It seems that, at least in the enterprise world, eventually every software project evolves into a hairy monster "that no one understands", choke-full of traps and side-effects that turn around to bite you at the worst and least-predictable moment. As a result, projects are frozen in time because everyone's afraid of touching anything, less it triggers Armageddon. Maybe AI can help? Instead of copilot writing new code, or chat systems explaining a couple of lines, there could be an app that ingests a huge code base at once (spanning multiple languages and subsystems) and - explains what each part does - is able to spot potential side effects for each new addition - suggests simpler ways of doing things / nice refactoring There are some startups trying to address this but none seems to be there yet (I think); the market is huge though and people would pay through the nose for this.
    - jshen 3y ago
      That's a really interesting observation. Having been in enterprise for a long time I think there are 3 things that I've seen make a big improvement on the health of a system after a decade or more. 1. Longevity of Engineers: Attrition is a killer from a knowledge perspective. Teams that keep their engineers have healthier systems 2. Avoid Over Abstraction: Simple understandable code is easier to maintain. Too many mid level engineers go overboard with abstraction and bad abstraction is worse than no abstraction. 3. Choose tech that is likely to be well maintained decades later. It's better to pick tech that will be well maintained than to pick tech that is better in some way but more obscure and more likely to poorly maintained in decades.
ulizzle 3y ago
It could take a lot more than luck. If it turns out to be a rabbit hole stick with react unless you have a really good reason for that kind of refactor
- roboben 3y ago
  The react code base is written by me, a backend/infra person and it was the first time I used it. It is a mess and the worst is that all the system tests are super flaky because of weird react DOM stuff.
  - ulizzle 3y ago
    In that case you’re probably alright with the rewrite. My opinion is to stick to React and rewrite the parts you think are nasty. That’s only because this can turn into a real rabbit hole in my experience. But at that size maybe it won’t be so bad. Best of luck!
stevebmark 3y ago
Goodreads is an example of a Rails victim like yours. They customized the app on top of Rails, and it's been so bad that Goodreads is dead in the water and has not received major tech updates despite Amazon throwing engineers at it. Ruby is a dangerous language to refactor, so often you're locked for a long time. See also: Every blog post about Rails upgrades ever (see also: Stockholm syndrome)
- yxhuvud 3y ago
  > despite amazon throwing engineers at it Yeah, that is one way of phrasing it. Another way to phrase it is that Amazon took it over, turned it into an ingestion funnel to their book store, and has done as little as possible after that.
  - stevebmark 3y ago
    Don’t speculate. Listen to engineers who work there https://news.ycombinator.com/item?id=36577444 https://news.ycombinator.com/item?id=36577444
    - imperfectcats 3y ago
      That's rather ironic, because I read your comment you linked to, and it is pure speculation. The Goodreads dev said "the site was originally built as a giant pile of Rails spaghetti with views mixed with business logic and such and then a fuck ton of weird features built and left to sit there". I'm not sure why you think that is or ever was "the Rails way", but it seems more like the classic "move fast and break stuff" startup engineering than anything resembling rails to me.
- gardenhedge 3y ago
  It's just that amazon isn't that good. See the alexa app as another example
  - steve1977 3y ago
    See pretty much everything Amazon. AWS, Kindle, you name it. Successful, yes. Technically good, oh no.
crystaln 3y ago
Loose typing is a nightmare. The youngins always learn the hard way.
- bdcravens 3y ago
  20+ years of experience here, I happily reach for loosely typed languages in most circumstances.
  - lolinder 3y ago
    Can you elaborate on what circumstances you're referring to? The field is extremely diverse these days, and tools that are appropriate for small data science teams may not work as well in enormous monorepos maintained by thousands of developers (and vice versa). What's missing from most discussions of static/dynamic typing is context—each career is unique and what projects you've worked on will have a huge impact on your perception of which is preferable.
    - bdcravens 3y ago
      You perfectly illustrated the point: that there are no maxims like the grandparent comment made. Myself, I work on very small teams, usually building applications that are backend-heavy web apps or filled with tons of async background processing on the server. Applications that are funded by revenue, not VC. Applications where I typically have a high degree of autonomy and responsibility as to maintainability, with usually no insulation between me and stakeholders. Given different parameters, I'm sure the decisions would be different as well.
      - lolinder 3y ago
        Oh, for sure, I wasn't endorsing OP's position! I had another recent thread [0] that was full of highly dogmatic claims on my mind, where I noticed that very few people brought in the context for their opinions. [0] https://news.ycombinator.com/item?id=37764326 https://news.ycombinator.com/item?id=37764326
  - 3y ago
ivandenysov 3y ago
Try https://vite-ruby.netlify.app/guide/rails.html https://vite-ruby.netlify.app/guide/rails.html It was almost a drop in replacement for webpack for me
stevepike 3y ago
I wouldn't necessarily recommend moving from an existing react frontend to hotwire at the same time as upgrading Rails itself. I'd get to Rails 7.1 first/independently. FWIW the Rails 7+ way of doing single page app JS is also more reasonable than it used to be. You pretty much just use whatever build tool you want in isolation from your rails app. You have to run something like `yarn build --watch` alongside `rails s` in development but IMO that's not so bad and makes things a lot simpler. My company builds software to automate Rails upgrades, and offers a full service where we'll upgrade Rails for you. steve (at) infield.ai if that's interesting or you can generate a free rails upgrade plan at https://app.infield.ai/users/sign_up https://app.infield.ai/users/sign_up (no cc required). https://docs.infield.ai/docs/creating-an-upgrade-path https://docs.infield.ai/docs/creating-an-upgrade-path for some more details.

yxhuvud 3y ago

Don't upgrade your architecture all at once. First bump yourself to rails 7 (including any other gems you can upgrade), then do any other changes you want.

FBISurveillance 3y ago

I've been doing Rails since 2005 and love it, but - and that's just my personal preference! - I wish they'd have a stable release cadence (calver like vscode maybe?) and a clearer roadmap/governance. Maybe it's just me but I just don't like DHH's governance lately. Not in a bad way, but following him on Twitter I just no longer respect him.

itake 3y ago
Coding in rails since 2012 here. I lost faith in rails at 5.2. Active storage was so terrible.
- roboben 3y ago
  Looking forward to see if and how it evolved in rails 7. In 6 it was really bad too and my tests are flaky because of some weird active storage async stuff. Can't find the id of blobs I have no idea
- nerdwaller 3y ago
  What is terrible about active storage?
  - itake 3y ago
    My memory is fuzzy, but... 1. all data flow through the rails app (no pre-signed s3 upload or download links for direct uploading). 2. no support for CDNs (I think newer rails versions added support) 3. blobs and attachments were unnecessary abstractions. 3a. Querying was annoying (extra joins) and easy to add n+1 queries. 3b. In my app, images are moderated and it was unclear where to put the moderation metadata (on blobs? attachments? create a new table? why so many tables?) or `deleted_at` type columns. 4. GraphQL gem didn't support it: https://github.com/rmosolgo/graphql-ruby/issues/1777 https://github.com/rmosolgo/graphql-ruby/issues/1777
    - dham 3y ago
      1. Rails has had direct upload since it introduced Active Storage. No one has uploaded files through their servers in a decade 2. What do you mean? Point whatever CDN you want at your origin 3. Maybe 3a. Yes 3b. Metadata or a new table 4. GraphQL is the single worst technology that has ever been adopted. We adopted at my company...twice. Twice we made the same mistake now we're stuck with it for mobile clients. In fact we're stuck on the old Graqphl RB gem that used a DSL instead of classes, which also blocks our Rails upgrade. We've been able to revert everything back to good ole Rest for another part of the app. Be cautious adopting technologies of large companies.
      - itake 3y ago
        1. You are correct for upload, but not for download. Looks like rails 7 added support for presigned urls: https://blog.saeloun.com/2021/09/14/rails-7-adds-expiring-urls-to-active-storage/ https://blog.saeloun.com/2021/09/14/rails-7-adds-expiring-ur... 2. CDN support is via monkey patch: https://github.com/rails/rails/issues/44136 https://github.com/rails/rails/issues/44136 3. yep 4. yep
maxehmookau 3y ago
> Maybe it's just me but I just don't like DHH's governance lately. It's not really governance, that's kinda the problem. To be fair, he never claimed that he was providing governance. Rails was extracted from basecamp. The impression I get is that he sees Rails as a gift to the community created from the profit-making Basecamp. Which is great; and I appreciate the fact that I've been able to build a career using Rails. But there is no governance really. Rails goes in the direction that 37signals wants it to, which is largely pretty good. You and I don't get much of a say in it though; especially if DHH disagrees.

ywain 3y ago

I'm working on a fairly recent Rails 7 code base. We initially started using Stimulus, but are now considering switching to React for a few reasons: - if you're looking to hire frontend engineers, the candidate pool for React is a few orders or magnitude bigger - it's getting harder and harder to find vanilla JS packages that you can wrap in Stimulus controllers for common tasks, compared to finding React packages - Stimulus doesn't really offer a way to write unit tests for your controllers. With React, you can use jest and react-test-renderer like normal. Additionally, the recent Turbo TypeScript debacle did not instill confidence in the long term stewardship of the Hotwire ecosystem. We're still on the fence about it. Stimulus does feel like a very Railsy way to write frontend code, which is definitely a plus for small teams of people who're already familiar with Rails.

sibeliuss 3y ago
Comparing the two: I have a hard time understanding how one could write FE code using classes (Stimulus) in 2023, when simple functions with inputs and outputs are there for the taking. It's just asking for trouble and hidden complexity. Choose wisely!
- 0xblinq 3y ago
  > when simple functions with inputs and outputs And the state library, and the hooks for side effects, and the SSR, and the hydration, and the VDOM, and... It's not that simple.
  - pulse7 3y ago
    Functional/OOP flamewar is starting...
    - sibeliuss 3y ago
      On the FE, this is already a settled topic. Who wants to go back to `this`? Um... nobody.
  - mardifoufs 3y ago

itake 3y ago

I lost faith in rails JS integrations. I either do SSR with slim or do API only with a separate frontend. Rails changed direction too many times trying to do JS (coffee script, asset precompiling, webpack, etc)

roboben 3y ago
What is SSR with slim?
- groggo 3y ago
  I think they mean Server Side Rendering (normal rails controllers/views), and Slim is just the name of the templating engine. It's a little nicer than the default ERB. https://github.com/slim-template/slim https://github.com/slim-template/slim There's also SSR with react and other js frameworks, but I don't think that's what they meant.
  - aaronbrethorst 3y ago
    I haven't used Slim before, but looking at the examples shown on the repo's README, it immediately brought to mind the thought experiment: 'what if Haml but Yaml?' n.b., I've been building Rails apps since 2007. I was a diehard Haml user up until about 2021 when I made an all-in bet on Tailwind and had to switch back to ERB because Haml with Tailwind felt too obtuse.
    - andrei_says_ 3y ago
      I’ve used slim for years and it’s incredible. Writing erb now feels painful. Slim is clean, terse, and correct. The only downside is I am now spoiled.
    - petepete 3y ago
      Slim is really nice for some things but the moment you want to style words within sentences or paragraphs it gets really messy and you have to start using unintuitive syntax like `|<` or `|<>` to get the spacing right. You can of course just drop to `markdown:`. Still, I use it where I can on personal stuff, but tend to opt for Erb when collaboration with others is needed.

eikenberry 3y ago

> Rails is great when you stick with the defaults and a land of pain as soon as you leave them. You just described every framework. Frameworks are great if your application is fairly simple and aligns with its way of doing things. Libraries are where to look if you need a more complex, flexible setup.

jshen 3y ago
I've worked on tons of old code bases over decades. I've never seen a library based one that's in good shape either. They usually evolve into some half baked homegrown framework that no one understands.
- bambax 3y ago
  It seems that, at least in the enterprise world, eventually every software project evolves into a hairy monster "that no one understands", choke-full of traps and side-effects that turn around to bite you at the worst and least-predictable moment. As a result, projects are frozen in time because everyone's afraid of touching anything, less it triggers Armageddon. Maybe AI can help? Instead of copilot writing new code, or chat systems explaining a couple of lines, there could be an app that ingests a huge code base at once (spanning multiple languages and subsystems) and - explains what each part does - is able to spot potential side effects for each new addition - suggests simpler ways of doing things / nice refactoring There are some startups trying to address this but none seems to be there yet (I think); the market is huge though and people would pay through the nose for this.
  - jshen 3y ago
    That's a really interesting observation. Having been in enterprise for a long time I think there are 3 things that I've seen make a big improvement on the health of a system after a decade or more. 1. Longevity of Engineers: Attrition is a killer from a knowledge perspective. Teams that keep their engineers have healthier systems 2. Avoid Over Abstraction: Simple understandable code is easier to maintain. Too many mid level engineers go overboard with abstraction and bad abstraction is worse than no abstraction. 3. Choose tech that is likely to be well maintained decades later. It's better to pick tech that will be well maintained than to pick tech that is better in some way but more obscure and more likely to poorly maintained in decades.

ulizzle 3y ago

It could take a lot more than luck. If it turns out to be a rabbit hole stick with react unless you have a really good reason for that kind of refactor

roboben 3y ago
The react code base is written by me, a backend/infra person and it was the first time I used it. It is a mess and the worst is that all the system tests are super flaky because of weird react DOM stuff.
- ulizzle 3y ago
  In that case you’re probably alright with the rewrite. My opinion is to stick to React and rewrite the parts you think are nasty. That’s only because this can turn into a real rabbit hole in my experience. But at that size maybe it won’t be so bad. Best of luck!

stevebmark 3y ago

Goodreads is an example of a Rails victim like yours. They customized the app on top of Rails, and it's been so bad that Goodreads is dead in the water and has not received major tech updates despite Amazon throwing engineers at it. Ruby is a dangerous language to refactor, so often you're locked for a long time. See also: Every blog post about Rails upgrades ever (see also: Stockholm syndrome)

yxhuvud 3y ago
> despite amazon throwing engineers at it Yeah, that is one way of phrasing it. Another way to phrase it is that Amazon took it over, turned it into an ingestion funnel to their book store, and has done as little as possible after that.
- stevebmark 3y ago
  Don’t speculate. Listen to engineers who work there https://news.ycombinator.com/item?id=36577444 https://news.ycombinator.com/item?id=36577444
  - imperfectcats 3y ago
    That's rather ironic, because I read your comment you linked to, and it is pure speculation. The Goodreads dev said "the site was originally built as a giant pile of Rails spaghetti with views mixed with business logic and such and then a fuck ton of weird features built and left to sit there". I'm not sure why you think that is or ever was "the Rails way", but it seems more like the classic "move fast and break stuff" startup engineering than anything resembling rails to me.
gardenhedge 3y ago
It's just that amazon isn't that good. See the alexa app as another example
- steve1977 3y ago
  See pretty much everything Amazon. AWS, Kindle, you name it. Successful, yes. Technically good, oh no.

crystaln 3y ago

Loose typing is a nightmare. The youngins always learn the hard way.

bdcravens 3y ago
20+ years of experience here, I happily reach for loosely typed languages in most circumstances.
- lolinder 3y ago
  Can you elaborate on what circumstances you're referring to? The field is extremely diverse these days, and tools that are appropriate for small data science teams may not work as well in enormous monorepos maintained by thousands of developers (and vice versa). What's missing from most discussions of static/dynamic typing is context—each career is unique and what projects you've worked on will have a huge impact on your perception of which is preferable.
  - bdcravens 3y ago
    You perfectly illustrated the point: that there are no maxims like the grandparent comment made. Myself, I work on very small teams, usually building applications that are backend-heavy web apps or filled with tons of async background processing on the server. Applications that are funded by revenue, not VC. Applications where I typically have a high degree of autonomy and responsibility as to maintainability, with usually no insulation between me and stakeholders. Given different parameters, I'm sure the decisions would be different as well.
    - lolinder 3y ago
      Oh, for sure, I wasn't endorsing OP's position! I had another recent thread [0] that was full of highly dogmatic claims on my mind, where I noticed that very few people brought in the context for their opinions. [0] https://news.ycombinator.com/item?id=37764326 https://news.ycombinator.com/item?id=37764326
- 3y ago

ivandenysov 3y ago

Try https://vite-ruby.netlify.app/guide/rails.html https://vite-ruby.netlify.app/guide/rails.html It was almost a drop in replacement for webpack for me

stevepike 3y ago

I wouldn't necessarily recommend moving from an existing react frontend to hotwire at the same time as upgrading Rails itself. I'd get to Rails 7.1 first/independently. FWIW the Rails 7+ way of doing single page app JS is also more reasonable than it used to be. You pretty much just use whatever build tool you want in isolation from your rails app. You have to run something like `yarn build --watch` alongside `rails s` in development but IMO that's not so bad and makes things a lot simpler. My company builds software to automate Rails upgrades, and offers a full service where we'll upgrade Rails for you. steve (at) infield.ai if that's interesting or you can generate a free rails upgrade plan at https://app.infield.ai/users/sign_up https://app.infield.ai/users/sign_up (no cc required). https://docs.infield.ai/docs/creating-an-upgrade-path https://docs.infield.ai/docs/creating-an-upgrade-path for some more details.