Yeah, selecting a stack IMO has more to do with scoping your goals. For example, if you are an indie dev who will be developing a project solo, pick whatever you're best at, because all that matters is the product. If you're an open source project, that's a different story. If you're looking to hire engineers, also a different game. And if you're the creator of Ruby on Rails and have created a giant personal brand ar…
I wouldn't call DHH contrarian for sticking with a mature framework.
Not only is it mature, but it's his framework. Sure he's not the only maintainer but he's the original author. It makes sense to use your own tools; specially if they're successful.
What I think is even more significant than Hey’s backend stack is its _frontend_ stack. There’s no complex JavaScript framework; it’s all server side rendered HTML with a few touches of lightweight JS (mostly Turbolinks and StimulusJS, afaik) on the client to add basic interactivity. And it feels just as fast—if not faster—than any other modern, well-built web app. It goes to show that libraries like React and Vue ar…
Idk,I actually don't understand the obsession of many with Tech Stack or predicting the doom of a language. Because Facebook uses PHP for their service, Would you still use PHP? A lot of people despise PHP. But there's PH maker Mubs, most of his indie products LAMP stack. The main lesson I get from any of these is that pick the one that you're comfortable with and deliver the project than looking for what's the best…
Yeah, tech stacks are important, but which one is right is so dependent on the specifics of a given project, which is what most of these tech-stack-hype conversations ignore. My small company pays out the ears in so many different ways to run our Python service, but we picked it because certain big companies can use Python at much larger scale than ours. Of course, those companies are mostly just doing CRUD operations to a database and often errors don't matter nearly as much because it's social media or whatever, and also they aren't as cost-sensitive as our business. Instead, we're fighting tooth and nail to keep our requests below a 60s HTTP timeout threshold when they could probably be on the order of a few seconds without optimization if we used a more performant application language like Java, C#, or Go (although the first two might involve some tradeoff on developer productivity; Go would probably improve developer productivity and it would certainly be a significant improvement to the tooling/deployment/etc story).
> - MySQL for DB (Vitess for sharding) Curious why not postgres?
They probably use MySQL for Basecamp and it's worked for them so they're also using it for Hey (same team developing both). As for Vitess it makes sense since it's made to work nice with Kubernetes (which they are using). I don't know of a Postgres equivalent.