Sometimes a need arises for browser-based apps that are not on the net, usually as part of a system installed at a location without access to public internet for various reasons.

If these systems are planned to have a life time of say 5-7 years, it would be best to not start developing parts of them with libraries and frameworks that are due to be phased out in just 2 or 3 years.

E.g. AngularJS, the writing is clearly on the wall. Google are investing in a number of libraries and technologies that are the "next thing": Polymer, Dart, Web Components + Shadow DOM in Chrome etc. It appears that in the big picture AngularJS is a stepping stone, which is a problem when you plan on building something that should be supportable for 5+ years.

Remember GWT? 5 years ago it was all the rage. At the 2012 Google I/O event they announced they're handing over control to a steering committee - their way of letting go and moving on. Imagine if you needed to continue supporting GWT based code for another few years, when the catalyst for the technology are phasing it out themselves. The worst part of this is the lack of developers - they see Google dumping GWT and stop learning about it. How do you hire developers to continue maintaining your software? This should qualify as being "in a rut".

So it begs the question, should an organization start using AngularJS (or any other fashionable framework trend) for long-term support systems? If so, how should one decide?

Because in 3 years the frameworks, tools, etc. will have a much weaker base of developers than it its heyday (now). So in 3 years the framework will fall behind in browser compatibility, integration with newer tools, etc. Left to rot in the bit bin of history. And if I need to make changes in the web app, add new features, it'll be much more challenging if I also have to be dealing with framework maintenance in parallel.