Let me tell you a story. Imagine one very enthusiastic developer, who was working on some project. Project was quite old, so he tried to improve it, introducing new cool stuff. Unfortunately, because earlier modern practices were not adopted yet, it was nearly impossible – everything was tangled, connected; code really smelled. So there was a hard decision of complete rewriting – but finally it was approved, and rewriting shouldn’t get more than two months. All deadlines were arranged, and our hero started to work on it with double energy. But it turned out, that this new software wasn’t the best suitable for this kind of task (in some intrinsic way, which was really hard to predict), and currently there was no solution – some other developers in the community were struggling the same way. Finally, some workarounds were found, but it took almost all time, and only half of the task was done. After the deadline everybody was expected to see actual results, and also new features and improvements should be developed. So, after this started double-front development. Finally, after few months of struggling, it was decided to add more developers and to fix this problem, and after another two months (yes, with all these new people onboard, who were already known this stack) the project was finally moved to this new stack. If you tracked, it took almost a year (and because initially it took more than a half a year just to discuss the transition, it actually has taken even more) – unbelievable result! And, because JS community is a very vibrant one, during this time a lot of new stuff revealed, even in the same ecosystem – best practices, some new libraries, new approaches. Of course, it is much easier to update after this transition, but it is just nearly impossible to keep it up-to-date with all latest stuff. Of course, you could devote more people, introduce changes more gradually, but the problem is that it is always not enough resources, and lack of knowledge of this new ecosystem; so I think this story is a pretty typical example of enthusiastic changes.
We, as developers, like to use new stuff – we feel that we’ll miss a lot, even everything, if miss this boat. We don’t really think about our domain and size of applications, we don’t read through issues and don’t try to work on bad scenarios, we don’t think how hard it will be to maintain this project in the future, what will happen in case new shiny framework won’t stand out, how to hire people with at least some understanding of this stack and how to migrate to another new best solution. We don’t think about it, but basically solving of all these questions require time and money – yeah, very often it is hidden, but they still exist. And thanks god, if it just a react (which succeeded tremendously) – but what if it was a ClojureScript or Elm, which are still not the most stable products, and you just can’t hire enough skilled people in your town, and your company never worked with people remotely? It is cool to introduce Haskell to some internal projects, to make constant jokes about it drinking beer, but someone has to maintain it later – and it will be painful and very pricy process.
I completely understand that to this point there is a strong thought that I hate new stuff. I don’t, and that story is pretty much about me at some point of my career – I just think that we should get into consideration much bigger number of issues, and don’t push to much because of our feelings and right way. In this fast-paced world technology is obsolete after just a year, but for building big applications it is insane – so always take new stuff into consideration, but take it with grain of salt. And always build prototypes and don’t rewrite anything – you just won’t be on time.