5 ms·
Rails has matured through the years, I'm convinced it's the right framework for any project if you already know it, you can get by with Hotwire for the FE and n
by siaw23 4y ago
Rails has matured through the years, I'm convinced it's the right framework for any project if you already know it, you can get by with Hotwire for the FE and not run after React and the rest. Happy to be a Rails dev to be honest.
- jemmyw 4y agoIt's good with React too when you need more interactivity.
- siaw23 4y agoI believe you can do anything React can with Stimulus + Turbo these days. I don't do much FE but I've been tracking Hotwire for some time now.
- sharps_xp 4y agoperhaps for most things but probably not to the extent of something like excalidraw, which uses react
- splitrocket 4y agoYes, but in that case, you can use only the complexity where you need it, instead of globally.
- mokkol 4y agoYou can still use React or whatever on those pages. And for the rest (settings pages, signup pages and all the CRUD pages) you can use standard Rails with Hotwire.
- simpsond 4y agoYes, but there is a whole ecosystem of react components and react developers.
- jacobsenscott 4y agoMaybe you can with heroic effort, but you shouldn't. You should build within the constraints of your tools. HW + Stimulus are great - good enough for what most web apps need to do. It gives you "traditional web app, with a bit of realtime updating" - which is the perfect fit for most web apps. But you wouldn't want to use it for a fully interactive desktop style application with lots of interacting components.
- 0xblinq 4y agoAgree. So unless you have a pretty big budget and you're building Google Maps or Figma you shouldn't use React. Sadly, everyone things they have such a big budget and they're building the next Figma. Even if you're building a CRUD app. (I'm talking to you previous team of mine).
- jemmyw 4y agoYou can do anything with plain JS too, but that doesn't mean you'd want to. The problem with Hotwire is that you do often have the server round trip in there. That's fine most of the time, it just gets a little harder to understand as the complexity rises. That's not to knock it, I think Hotwire is pretty good.
- andrei_says_ 4y agoIn what scenario would complexity be higher in a simple UI - server loop? Doesn’t complexity usually arise from having additional logic in the browser and maintaining state separately?
- jemmyw 4y agoI guess it depends somewhat on how you imagine up something and write it. I was working on some drag and drop UI that had multiple sortable lists and an action area. Figuring the server side and UI at the same time didn't work out. I reversed and implemented the UI with its required state, and then it was easy to transform that state to what the server side required, and vice versa. Complexity is tricky. Are three simple things more complex than one thing thats harder to understand?
- granshaw 4y agoStill decent amount of caveats given the UX expectations of 2023... eg last I checked there was no official support for transition animations
- Gigachad 4y agoRails is extremely easy to get started with but after a few years the lack of types on Ruby cripples every single Rails app I've ever worked on. You can have as many unit tests and browser automation tests as possible, but updating any gem is a dice roll despite doing as much due diligence possible. And it's always something extremely trivial like a method changing its parameters without announcing it in the change log for some reason. Something almost any other language would warn you about. I've been doing Rails dev for 7 years now but I just don't see it winning over TypeScript/nodejs frameworks. The only advantage Rails still holds is the out of the box batteries included package. But once a TS framework gets this, Rails will be in decline.
- favorited 4y agoDoesn't Ruby have 2 production-ready typecheckers now? I think Ruby officially has something called RBS, and Stripe open-sourced Sorbet.
- Gigachad 4y agoWe evaluated them, it's just not there and it's unclear if it ever will be. DHH, the lead for the Rails project has indicated that Rails will "absolutely not" have a type checker in reply to a tweet asking about it. And a huge amount of work would be required from the Rails team to get type checking to work.
- klardotsh 4y agoUsed to work at a Rails shop, and led an effort to get type safety into the codebase. It was a nightmare that wasted endless time and added plenty of stress. Sorbet is great on vanilla Ruby code that doesn't try to use too much arcane metaprogramming. It's "okay" on vanilla Ruby code that uses some arcane metaprogramming that humans can reliably reflect in RBS files. In a Rails codebase, which is (IMO) a huge ball of relatively hard to statically analyze magic and quite heavily uses all sorts of tricks for either API ergonomics/skimmability or for performance, it was a mess, and frankly, I had a pretty nightmarish time selling almost any of the feature set beyond (1) ADTs/Enums (2) the subset of Interfaces as exposed by `T::Struct`. Sorbet is a herculean effort by some extremely talented devs. I don't at all want to discredit that. Tapioca is likewise an impressive DSL-reflection machine on top of RBS files, particularly post-0.8 release. But type safety in a Rails app is, at least in my experience, extremely high cost both upfront and maintenance.