Javascript goes on incredible pace. Code, which was written just few years ago, using Backbone and CoffeeScript (which was really hip and cool at the moment), now is just obsolete. Where is jQuery now? Yeah, it still a big deal, but nothing comparing to the moment when the proposal to inject it on browser level(1, 2, etc) was not something completely crazy – so, it’s best days are in the past. Angular was like shining star, until React came out. Nowadays FRP principles are in favor – but they are too hard to be accepted by majority – so, waiting until the next user-friendly framework with some cool and big company behind it will arise (and it will – basically, this competition is one of the biggest reason why JavaScript is so developed now). And not to mention about ClojureScript, Elm, some less-knows projects like Scala.js, etc. (look at all these languages compiling to js – and also some languages claim about it even in their roadmap).
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.
Fast pace is very tempting – and considering that JavaScript is pretty-much hype-driven development, where single tweet from respected developer in community shakes a lot of minds – “No compile-time errors in Elm! Thanks god!”, or “No errors in my new project!”. It is out the parenthesis that their “new” project is just some pet project to play with on a weekend, and that in exchange to no compile time errors you have to get a lot of other stuff – like untested interoperability in hard cases (you may use some 3rd-party-library, which was not covered by dev team of your new shiny language), or just some bugs, which would be very hard to test and especially debug. Size of the community, number of products using technology, their roadmap, number of issues – all of these matter, and we don’t take it into the consideration, because from the developer side it doesn’t matter at all. We like to hack new stuff, that’s it. But this hype culture often endangers the whole projects because of that.
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.