> Isn't that a case of not letting developers rewrite anything? How did it got so outdated?

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).

There's also a chance writing your project on that 10+ years old platform will cost you enough time/money to write it three times in a more modern one.

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.

> Frameworks shouldn't get outdated in just a few years, and any tech where they do is doing something very wrong.

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) :)

You know, if Microsoft developed all its other applications in VBA and ran them inside Word, they'd be a laughing stock.

But everyone else in the world thinks it's sane to write applications inside a thing meant for displaying documents...

Got a better solution, with wide adoption, that can get you on just about every internet-enabled consumer-facing computer in the world with the same codebase? :)