It's a wise decision if you care about engineers being engaged and liking their job.
I am all for keeping your engineers happy. Heck I am one of them. "Exciting" can mean "better architecture" or "extensible", but I think that adding a new language is always a bad idea.
Isn't that a case of not letting developers rewrite anything? How did it got so outdated?
Anyway, the Javascript world sucks. Frameworks shouldn't get outdated in just a few years, and any tech where they do is doing something very wrong.
If you're writing (or rewriting) using whatever's hip/new there's a good chance it will be "outdated" within a few years. New languages and frameworks come out all the time and nobody is able to determine with certainty which have real staying power - but something that has been in [wide] use for 10+ years is much more likely to still be widely used ten years from now than something that just came out last year.
Think of it like music, people have been listening to Mozart for centuries - it's highly likely a hundred years from now people will still enjoy his music. It's a lot less likely they'll be listening to Taylor Swift (nothing against her / her music - just using her as an example of someone who's very popular right now).
Well, you sound like somebody who I'd agree with most actual decisions about this. But I do disagree with the overall position. Holding down too much at "it works, don't change" has actually worse consequences than adopting immature frameworks all the time. That's not exactly like music - software tools do get old.
Good platforms, of whatever age normally last for a long time and should be safe. But if for some chance one didn't last, one shouldn't be too resistant to replacing it (piecewise and slowly), because the cost of not doing that is just too big.
I don't think it's that they get outdated. It's that they each try to solve the hardest problem of web UI programming: keeping track of state and binding data in an asynchronous world. Unfortunately, each one ends up with pain points in different places.
Each successive framework tries to solve the new pain points by rethinking the original problem, because reworking the original framework to ease that pain point would often require massive restructuring of apps built on that original framework - the issues are often architectural.
Angular, for example, is fantastic for getting a very simple CRUD app up and working. But try to do anything fancier and things get very hairy very quickly with a web of controllers, directives, scopes, etc. Getting into a place where one data change cascades and kills your app is a very real concern. That's the pain point React/Flux attempts to solve. Angular can't solve it without some major architectural changes - see the hubbub about Angular2.
We're still in the baby stage, I feel - while each successive framework may seem faddish, they don't really get outdated. Out of favor for new projects, perhaps, because the developers who used the older framework were so frustrated with the previous tool's rough edges. Things will probably settle down soon (especially with the fantastic language improvements in ES2015) :)
But everyone else in the world thinks it's sane to write applications inside a thing meant for displaying documents...
As a result of its effects on the work of other members of the team, such people often have a negative net productivity. I, too, am in favor of making things interesting where possible, but not to the point of indulging the Dunning-Kruger effect.
Could you imagine if everytime you wanted your HVAC upgraded, your contractor decides to rip out your entire current system and replace it with something new ("this new polymer ducting is awesome!") just to keep their engineers happy?
There's a time and a place for all types of projects, and the mark of a successful engineering effort is to have engaged engineers regardless of the 'cool factor' of their work.
In fact, this whole thing stinks of poor leadership (not just management) and undisciplined engineers.
-- snippet from a more or less realistic set of requirements for a "2 years of business logic" app. I do not want to be here in another 28 years...
If you chose any of the major frameworks for your application you'll be good. Django, Rails, Java EE, Spring, Play Framework, Meteor. These aren't likely to go away anytime soon, and they've been around for a while.
On the front end it's a much more dangerous approach. If you have one or two pages that use the latest flavor of the month, Backbone(2011) Knockout(2012), Angular(2013), React(2015), you'll be ok.
The problem comes when you just re write your entire front end app in one of these. I like to experiment with front end technologies on one page, but I would never buy into the SPA for the entire app. The shelf life is way to small. They'll still be supported probably.
If your trying to keep or hire developers, putting backbone.js as a tech you use probably won't get as many applicants as say React.js. Since most front end devs right now are trying to introduce React into current job or jump to a job where they use it.
Even if you said yes, you're only kicking the problem down the field a bit, because six months later they'll get just get bored of the new stuff they've rewritten and will want to move on to rewriting something else. Ad infinitum.
I consider these people the "90% engineers", meaning they like to take a project from 0% to 90% complete, but then once the going gets tough, and they're no longer writing new code but trying to track down the bugs in their existing code, they decide it's no longer fun and need to move on to something else.
These people usually fail to realize the implicit risks associated with throwing away an existing codebase and starting over from scratch. All that time spent ensuring the business logic is correct and tracking down obscure bugs will need to be repeated in their new rewrite. (Spolsky elaborates: http://www.joelonsoftware.com/articles/fog0000000069.html)
These people are essentially spinning their (or rather, their company's) wheels by creating more work for themselves, without actually getting anything done.