You seem to enjoy switching tools and methodologies and see it as part of embracing Node.js.
Others don't have that luxury and just can't afford that.
And if your software needs to be around for more than 5 years, you want to keep your costs low.
How long would it take you to find a bug given a stack trace from a Node API with close to no clue which part part of your app registered that callback that isn't called because of the error?
Chances are, you don't even measure the time spent in code archeology as I like to call it.
The time probably is not significant right now as you kinda know your way around your code base...yet.
> You seem to enjoy switching tools and methodologies and see it as part of embracing Node.js.
I've been using the same tools for the last 7 months outside of switching from Angular 1.5 to React because I'm not a fan of Angular 2.0.
> Others don't have that luxury and just can't afford that.
Then don't? What is this sense of needing to change everything because something else comes out, that developers have?
If your current toolset works, why change it? Why rewrite a monolithic app in another fancy language or tool just because someone wrote a blog post boasting about that new tool/language?
Others don't have that luxury and just can't afford that.
And if your software needs to be around for more than 5 years, you want to keep your costs low.
How long would it take you to find a bug given a stack trace from a Node API with close to no clue which part part of your app registered that callback that isn't called because of the error?
Chances are, you don't even measure the time spent in code archeology as I like to call it. The time probably is not significant right now as you kinda know your way around your code base...yet.