This always struck me as weird thinking. If you aim for sustainability and longevity, shouldn't you use technologies that have stood the test of time rather than the latest and shiniest pieces of tech?
Avo was first a Rails-backed SPA (Rails server and Vue front-end), and it didn't work out that well. Unfortunately, the Rails community didn't take that lightly, and for a good reason. I won't go into too much bike-shedding here, but the most important reason is that you have to maintain two codebases (ruby & JS).
In January, we re-wrote Avo with Hotwire (the JS front-end suite created for Rails), and it went very well. It's a joy to write apps using Rails and Hotwire.
But the fact of the matter is that we need an app that's a bit more dynamic on the front-end than Hotwire can deliver. I mean, yes, we could weave together Hotwire and a few other JS libraries to get what we need, but we'd get the same two codebases and the same two sets of skills you need to run your app.
The reason we chose to go with React is the ecosystem, mostly (*fun fact; I'm sitting here writing this wearing a VueJS hoodie). We're running Next.JS because, honestly, it's a beast when you're talking about React apps. TailwindCSS because of its popularity, and it vibes with us, and we move fast using it. Prisma because it really is a breath of fresh air when you consider the alternatives in the JS world.
I left TS at the end because it's the most "well-known development secret" out there. It keeps your codebase in check and your team on the same page.
Yeah, I agree. That's not the way to go. Components is the way to go.
Regarding using tailwind in general, I had a few issues in the beginning, too, until I figured out how it's supposed to be used.
It is a bit tough to use it with frameworks that don't allow you to create components in a more modular way. But if you get to create these components, it's really a joy. It reminds me a bit of the BEM methodology (just a bit).
Again... it's also a matter of what each person is vibing with.
Because the fact that the things likely to last the longest into the future are the ones that have already lasted and not the newest, most-apparently-forward-looking is counterintuitive to many people.
Or because they recognize that, but recognize that its also likely that something new will do even better than the things that are already old but that the hard part is picking the right new thing, and they think they have unique insight on the right new thing.
Or because they realize they probably don't have unique insight, but gambling on new has the best payoff if you are right, whereas the upside of choosing COBOL because its still trucking since the 50s is...you have job security eternally working on a COBOL [0] code base.
[0] And this generalized to all the metaphorical COBOLs out there in various domains, as well as actual literal COBOL.
I'm not the one to say if what we choose will last in the future, but we really are not afraid that they will be gone in the near future. The technologies we picked are not the "hot new thing", and we just picked them up.
If I can use your metaphor, I'm not sure we could have built this in COBOL. We chose the tools that we thought were best at this moment in time.