A story about product-driven development
When someone says that you need to switch to React
“If you are a front-end developer and you still don’t use React in your projects, you might be a bad front-end developer. You don’t use ES6 either, do you? Too bad for you then. Maybe Webpack? No? Why are you still not fired?”
I bet you all have heard opinions like this one before. People around want us to use the newest technologies available to us, right after they have been created. We leave off working on our projects not written with React / ES6 / Webpack (or name another new technology) just because it’s not cool that they were written not with it. Because someone said that the technology we apply is dead and no one uses it anymore. We spend tons of time on changing everything despite the fact that we will get the same working product in the end.
Should we really always do it so blindly? No, not really. Stop doing it. New technology is not always a good thing. And here is why.
A product is above all
First of all, we are software developers and our profession means that we must develop applications. Applications that will make our lives easy and help people. Applications that will just work. This is our main goal and we will be happy if we reach it.
We may not think about it, but when we want to make a step on the way to new sensational technology, we already have a product that works. Or maybe it doesn’t work yet, but we have a lot of experience in the current environment of the project. We can make a product work way faster by using this knowledge because we already know all the needed solutions to all the possible problems there.
Moreover, your users don’t mind which framework you use to develop your application. They only want it to solve their problems. There are so many great products that were developed with technologies that some people don’t want to use because they consider them to be “dead”.
jQuery, Backbone, LESS, Ember, etc. Do you still think these things are dead? So maybe you need to look at the list of companies that use Backbone, for example. Or companies that use jQuery. Or Ember. These frameworks are used by such projects as Pinterest, WordPress, Yandex, StackOverflow, Amazon, Square, TED. And these projects do pretty well and have many satisfied users.
So if you use whatever tools you choose while developing your product, they make it work and your users are satisfied, you’re already on the right way, aren’t you?
Too much hype
I don’t mean that we don’t have to move on and bring new technologies into the development of our products.
Front-end is growing with great speed, perhaps, faster than any other field of software development now. Developers bring new paradigms and new design patterns from other programming languages as well as create new frameworks and new libraries. It seems like every single developer has to write his own JavaScript framework, or he’s not good enough.
Some of these things can really make the development faster and easier. But not all of them_._ Or maybe they can but not for you and your project. Most of them are just hype that’s not worth any attention.
Our common mistake is loving these new technologies. As we hear a new beautiful word with “JS” at the end and read its small marketing description, we’re ready to start writing new projects with this “brilliant” thing. But the truth is that the marketing bullshit and the beautiful name are the only advantages of this new thing, and it could be forgotten in next two months. We spend so much time on learning new things just to forget about them and ruin all the knowledge we have when once again someone on the Internet says that it’s not cool anymore and there is this newest thing that is really great.
Sometimes new technology can really be groundbreaking. But it’s still not the reason to start using it right away. Even revolutionary technology needs some time to “stand on its feet”, to get all needed features and to be patched from its initial bugs. Node.js seemed like a rad thing at first, but if you decided to write your project with it, you had much more troubles than if you’d use the old good PHP. At that time Node.js didn’t have enough packages even for such tasks as e-mail delivering. React is a great solution, but when it was brand new, it didn’t have a settled framework to work with data and you needed to write it on your own.
You need to be very patient and selective. You need to pick technologies better. Give them some time to be utilised by other people in the community. Wait until people who have more opportunities to use them say that it is really worth working with them. That they have real advantages compared to the technology that you use. Wait until people write all the parts, create all the libraries without which you can’t use these technologies and fix all the critical bugs.
Also see if your product really needs the advantages of a new framework. It could be clear that React, for example, would provide faster application rendering. Or a new library for drawing charts will draw more beautiful charts than your current one does. But maybe these features are not so important if your product still doesn’t provide some essential aspects of its functionality. Users would rather see not so beautiful but right and up-to-date data on their charts, even if it is rendered 2 seconds later, than fast and beautiful charts with wrong information.
If after some time people still like this new thing, if the advantages are still clear to you, only then it’s time to start planning the revolution.
The right time and the right place
So you decided to bring something new into your product development. But you still can’t do it right now and right here.You will get the advantages when you switch to a new technology, but it will happen only when this change is made and if it is made at all. To start this change is not the same as that to complete it.
You need two important things to do this change. The first thing is your team, the second one is time. Both of them affect each other. If you have a better skilled team, then you need less time to develop something, and vice versa. Both of them are also affected by the budget of your company.
Usually a company has strongly limited financial resources. Therefore you have the limited developers team with their skills and limited time for work. During this time you need to bring something to the market. Something that will let your company get more money and stay alive. If the company lives, then product that you develop lives too. This is how it works. Of course, in this case we are talking about the real world and professional software development, not about petty projects that could be developing forever and don’t have users at all.
As we said before, you as a developer need to make people’s lives easier. Bring new customer value to them, in other words. It could be a release of a new product or new handy features in one that’s already existed. And you need to do it as fast as possible. As you can see, it can be a tough issue in such limiting conditions. And it’s always this way.
You always need to make sure that resources of your company are enough to perform the change of technology.
Do you really want to start it when your company does not have a lot of resources? Do you really want to lose all the time and have the same product after months of work and nothing else? Or maybe you have to wait for some time, bring new meaningful features while using your current framework, get more users, get new investors and more money from them, find more developers with needed skills and make this move then? This decision can be even worth the company’s life.
Concluding all written above, you need to pick not only a technology for migration, but the time when your product is able to be switched to it.
Conslusion
New technologies always sound good for software developers. Yet instant migration to them does not often end successfully. This problem is not about front-end only but it’s very relevant to front-end, because now is the time when we have too many new things appearing every day here.
We have to see why we refuse to work with some old technology and why we can’t use it anymore. We need to filter new technologies, find diamonds and stay away from garbage. We have to carefully pick the moment of the migration. Sometimes we don’t even need it despite all the appeal of this idea. Sometimes we need to wait for a long time to proceed it. And only sometimes we can do it on the spot.