Seven years ago, there was a lot of hype around different technologies. If you were part of the JS/TS community, you probably remember how libraries and frameworks appeared almost every week. Many people eagerly picked up this zoo of libraries and dragged them into their projects. Those were interesting times, and to many it felt completely fine.
Once, I was reading someone’s Twitter, and I saw a post that said: “A JavaScript developer has written yet another library for himself, because he couldn’t handle the ready solution that was already available”. This, by the way, is a perfect statement about the technology market.
Over all these years, I have come to realise that it doesn’t really matter which technology you use. The technology should solve the specific problem. With any framework or library, your team must be able to deliver a feature as quickly as possible. And here it comes down to whether the team already has experience with that framework, or whether the team’s level allows it to integrate smoothly into the ecosystem and deliver the required project in a short time.
I would only leave room for a small debate about how rich the ecosystem of a given solution is — for example, whether it already provides ready made libraries for things like encryption or working with dates, so that you don’t have to write your own...
If you have a bias against JavaScript or TypeScript, that’s fine — sometimes these tools really do have strange behaviour. You can check out a great repository by my friend called wtfjs. As for TypeScript, there’s plenty of material you can find on the internet.
Personally, I’ve come to the conclusion that for me, the most optimal choice for building a backend is Ruby or Python. Ruby on Rails, in my view, is simply the best thing ever created for fast and stable development of API services. Ruby is a wonderful programming language with a great community. I think that anyone who can program in general can easily get comfortable with this framework and language.
So I’ll keep it minimal here: I like Ruby on Rails, or Django and FastAPI from the Python ecosystem.
After working with these tools, I came to understand the essence of how API services are designed. And in general, whenever I practise with a side project — whether I try out Golang, Clojure, or another programming language — the main thing for me is to understand the benefit of the language I’m using. In the end, a programming language is just a tool.
I believe you should always choose what fits the business and the team, and minimise dependencies that might get in the way during development.
Of course, when it comes to frontend development, I think React has become the de facto standard. A confirming fact, in my view, is that no matter which AI agent you ask to build something, it will almost always generate it in React by default. I cannot say this is always a good thing.
In reality, React often introduces far too many ultra-complicated things that could have been made simpler. Sometimes I find myself thinking that tools like htmx or Hotwire would actually be great for making an interface of almost any complexity dynamic — and for the end user, that would be perfectly fine.
In conclusion, it’s important to understand that you don’t need to run after every hype train in technology. Sometimes this only leads to becoming dependent and using a tool not because it solves your problem, but simply because it’s trendy. Based on my own experience, I always recommend — to myself and to others — taking the time to think before deciding what to use. You always need to use your head, because it’s your own experience that should tell you what you really need, not someone on Twitter or another social network.