3 ms·

I disagree with the last point. If you can make sure that the change is worth it, that you understand the new technology very well, and if you make a commitment

by spion 11y ago

I disagree with the last point. If you can make sure that the change is worth it, that you understand the new technology very well, and if you make a commitment to follow through and do all the necessary work, you wont fall into the "Duke Nukem" hole. (The problem of course is that often times we don't take the time to make the necessary evaluation and want to make a change just for the sake of learning the new shiny)

mhd 11y ago
I'm talking about the beginning JS programmer. So it's quite likely that they don't understand the technology they're currently working on and thus have bigger problems evaluting the new one, as there's no good point of comparison. Also, I hope that the first project a JS newbie does isn't a 100'000 line app, but something more bite-sized, and thus you really don't have to wait months to get to use the new stack or tool. Quite often this kind of decision making happens when the project is 80% done and you have to face a few things that aren't that easy or your code has become a bit too complicated. And yes, the new tool could solve that and you might even end up re-implementing bits and pieces of that. This might not be the most effective use of your time, but it's a good learning experience.