Hi Daz, I wanted to jump in actually move the question away a bit from "X vs Y" to talk about some of the philosophy, and 2nd order consequences of such a discussion.
Starting with philosophy, Rails is _heavily_ "convention over configuration" driven, but it's a way of expressing that a bit part of what makes Rails "railsy" is that those decisions have been made for you, the thresholds for various trade-offs have been taken, and there's a large return on the investment you can get from your Rails app by enjoying the "tailwinds" by just following the status quo. Not only is it maybe "easier" to use Hotwire, than X, but because it's the Rails preferred way, it tends to be a well-paved-road, unsurprising to Rails developers, and generally pretty smooth sailing. That all being said, even if X were objectively better than Hotwire on a pure technical basis, at some point by adopting Rails, you are buying into the ecosystem. *Buying* is a good segue into the next topic of second order effects too. The software doesn't exist in a vacuum, someone is paying for it, someone is paying (hopefully you) someone to maintain it, people will come and go, and the business this software, (whatever it may be) supports will evolve. When considering what technologies to use in a business context, it essentially comes down to a triangle of business needs the preferences of the people involved, and the current "reality" of how the tech landscape looks right now. *Business needs* first, if you're a React developer, and someone approaches you about building something, of course React-centric solutions will be foremost in your mind, after a couple of decades in the industry however we folks who've been around the block, we can see if a different setup might be more appropriate. Branding yourself as a "Rails Developer" will both limit, but enhance your access to a jobs market, it's the classic specialist vs. generalist argument, but even specialists should keep their ear to the ground and _learn_ other things even if they don't become your new speciality. How is that related to X vs. Y question? If the business needs a prototype to get to market in a fortnight, and you're an X developer, and you are free, and they'll pay your rates, the choice of technology basically doesn't matter, but if the business needs to scale from 1,000 sales a week to 100,000 sales per week in the next 2 months by supporting mostly mobile commerce, well, then maybe your tech choices might change (hopefully they're also paying more) *Preferences of the people involved* is next, assuming you're not a one man show prototyping something on the weekend for a friend, at some point you have to work with others. Ideally you work with open minded, broadly experienced people who aren't choosing to die on one or the other tech choice hill, but a "Rails by the book" shop might balk at the idea of having this whole separate X stack on the side, even if it's objectively a superior platform. Preferences go a long way, and programmers in particular are renowned for being hung up on details, tribalism and petty arguments. I *specifically* gravitate towards technologies where this is less of an issue, and proactively *avoid* software stacks where this is utterly petty. (The Scala community has a lot of this... two libraries, both doing basically the same thing in the same way, and nobody can agree if one or the other is better and people are super dogmatic about which one to use). Arguing about preferences takes away from the business needs, costs time and money and ultimately can lead to staff turnover and general dissatisfaction in the job, which manifests in frustrated, bickering people. There's less of that than I think used to be common, but it does still happen. *The reality of the tech landscape* can be summed up as "you made your bed, now lay in it". If you hired a team of React developers to build an SPA, and a team of Rails developers to build a backend, and you suffer an economic downturn and have to lay people off, and your React folks can't work on Rails and the Rails folks can't work on React, you now eat this problem. You end up halving your capacity to get things done because you chose (subjectively) "the best frontend, and best backend" technologies but now you need specialists, not generalists, and then you run into all kinds of fun situations where you now need to coordinate front-end deployments separate to your back-end deployments, and your continuous integration system now needs to be coordinated between your back and front end repository, and you now need to consider how to have the same view of your data models in the app, and on the backend, and what API technology you're using. Ohh, and you also need configuration as code for your AWS, or GCP account because they way you host the Rails app on a Docker container with nginx isn't the same way you host the frontend SPA which is now a static file server such as S3 with a CDN in-front of it with certificates and certificate rotations, and you now need to integrate all of that into the GitHub actions continuous integration too. Wait, none of this applies to you because you build a monorepo where the Rails app and the React apps co-exist in the same repo, see "preferences of the people involved", you'll be having the monorepo vs. macro repos discussion forevermore now. In summary then, the code we end up writing, or the code that ends up being written is a small fraction of the actual result of the decisions we make. People like to say that lines of code are not an asset, they're a liability, it's like owning a building that needs constant maintenance and repair. From the pure financial bookkeeping situation it's exactly the same, and if programming were as mature as classical engineering, or real-estate we'd have better mental tools to help us reason about all this. ps. sorry if this comes off a _little_ cynical, hyperblole is applied for artistic effect, and as a senior leader in a 150 engineer org who no longer codes all day, I see a lot of this stuff going on where we're now victim to years and years of decisions that only considered 5% of the actual impact of a choice for A vs. B :-) Ahoy, Lee Hambley http://lee.hambley.name/ +49 (0) 170 298 5667 On Tue, 23 Apr 2024 at 19:52, DAZ <daz4...@gmail.com> wrote: > Okay everyone ... this 'debate' got going on another thread I started. > > I've used React before and have found using Turbo frames and Stimulus to > be like a breath of fresh air, especially how well they integrate with the > rest of the Rails stack. > > Other people have said that it can quickly get messy and React is needed > for anything complex. > > Would love to hear everyone's thoughts? > > -- > You received this message because you are subscribed to the Google Groups > "North West Ruby User Group (NWRUG)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to nwrug-members+unsubscr...@googlegroups.com. > To view this discussion on the web, visit > https://groups.google.com/d/msgid/nwrug-members/6b2f7f85-843c-478b-a326-26a07704ab0fn%40googlegroups.com > <https://groups.google.com/d/msgid/nwrug-members/6b2f7f85-843c-478b-a326-26a07704ab0fn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "North West Ruby User Group (NWRUG)" group. To unsubscribe from this group and stop receiving emails from it, send an email to nwrug-members+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/nwrug-members/CAN_%2BVLVKX%3DMZULHV9x4AE_ZncTPz%3DaT_0uYy%3DWwqXkn2ZdyKGw%40mail.gmail.com.
