In tech, there’s a new framework every month. In iOS, for example, we have SwiftUI, a new UI framework.
When a new framework is released, wait a few years before learning it. Don’t have a fear of missing out. You’re missing something, and can always adopt it next year. It’s not a spaceship that’s departing to Jupiter this week and you can’t join later. A fear of missing out makes you run just to stay still. If you run, you should generate business value, not end up where you began. In general, you shouldn’t make decisions out of fear.
New tech is invariably over-hyped by its builders, who are not going to say, “Our new stuff is mediocre.” They’re not going to say this at official events like WWDC, not on Stack Overflow, and not on podcasts that their engineers are invited to. Even if a tool or framework is internal to a company, the team will talk of it in glowing terms, since wide adoption will be good for their careers, and for their egos. And all of us have an ego!
The people who build a framework are not the only ones who hype it up. So will developers early in their career, who are hearing everything for the first time and are therefore super! excited! about everything. Many frameworks also have their fans, but you don’t want to make a decision based on what the fans say, because they will invariably say it’s great. It’s like asking a politician whether he’s improved life for his constitutents.
New technology invariably has problems: it’s rarely as good as promised. It may be better at some things and worse at others, and you don’t want to adopt it without checking which bucket you fall into. Documentation is often patchy. And the framework itself can be raw. Norms haven’t yet evolved around how to effectively use the framework, or in what kinds of situations it makes sense to use it. Even if you use it, others in the team will have to learn it to work with your code, imposing an extra burden on the team. So it makes sense to wait a couple of years for others to iron out all these kinks.
Some frameworks are so defective, like iCloud Core Data sync, that they even lose user data! You don’t want to lose your users’ data, but that’s what can happen if you naively adopt every new tool. If you rush to adopt a framework, you may very well figure out later that it doesn’t work, after spending a lot of time learing it. Or it works, but not for you. Or works in some ways but causes critical problems in areas like performance, backward-compatibility with older iOS versions, crashes or something else you don’t know yet. Adopting a new framework is an unknown unknown. It’s not like saying, “We’ll switch to Swift UI, which will take 3 weeks.” If it were that simple, you could make an informed decision. But unfortunately, too many things in software development amount to saying yes to an unknown amount of work for an unknown benefit. Which should naturally drive you to be more conservative.
If the new framework doesn’t work and you have to switch back, you’ve paid the transition cost twice. Even if you don’t have to switch back, it can be the case that it’s one step better and one step worse, so you’ve paid the transition cost for no benefit. You’ve made a change, not an improvement.
The arrival of a new framework doesn’t immediately make the old one obsolete. For example, Swift 1.0 was released in 2014, but it was ready to use only in 2016. That doesn’t mean you need to use it 2016, just that 2016 was the earliest it was production-ready. You could have waited till 2018 to adopt it. So, a new language, tool or framework doesn’t obsolete the old one. There’s a transition period of many years. You can adopt the new tech any time in this transition period. There’s no need to jump on the bandwagon the same year it comes out .
 I’m not saying, “Stick with what you know, and never learn anything new”. Instead, I’m suggesting waiting for a year or two before learning it, when the tradeoffs are clear.