> But why should it be? The goal of building web sites and apps isn't to use the latest shiny new technologies.

I agree that it shouldn't be, but I don't agree that it's possible for it not to be, mainly because browsers are constantly changing and improving and assumptions older frameworks had become irrelevant over a long enough time period (certainly over 5 years). This is precisely the reason why Angular is having to make such drastic re-write - they're trying to align better with Web Components and other ECMA6 features that are coming down the pipeline.

I hate to stereotype but often people who complain about the volatility of web development tools and frameworks are people who are traditionally server-side developers who have enjoyed a relatively stable deploy target for periods much longer than 5 years. Trust me, I wish it was the same for front-end development.

> And if we're talking about app-style development, why should someone who invests significant time and resources to build, say, an intranet app to automate some function in their business not expect that app to still work five years from now?

Because building desktop style applications using old web technologies is really freaking hard. If it wasn't, we there wouldn't be such a huge deluge of web frameworks to help do it.

> This is why standards and stability are important, and it's why "living standards" are a pile of [expletive deleted], and it's why it's a bad thing that some browsers currently have very rapid release cycles with an obvious emphasis on adding new shiny things at the expense of maintaining support for older technologies, and it's why you shouldn't build anything you might need to maintain for more than a year or two with the JS framework du jour.

I can't really disagree with you here and that's why I find React so compelling because they're kind of saying "fuck you" to the standards committees and building something they know works whether or not the promises of ECMA6 and HTML5 come to fruition.

> A lot of front-end devs today make building simple user interfaces to access databases seem awfully complicated. Every time I read articles like this one I become more convinced that most of that complexity is of their own making. They talk down to old school developers who put most of the logic on the back end, or who build interactions using jQuery, but sites written 5 years ago using those technologies still work and can still be maintained just fine. I wouldn't bet on that being true for anything built with a framework like Angular or React today.

I'm guessing you're not a front-end developer so forgive me if I'm wrong, but what you're saying is absurd. It is hard. Much harder, in fact, than building an iOS or Android App which rely on sane frameworks built by single entities to function perfectly within one sandboxed environment. Web applications like Google Docs are every bit as sophisticated as native mobile apps but must be built without the benefit of native performance and monolithic, corporate-sponsored SDKs. Putting "most of the logic on the backend" isn't a viable solution for native mobile apps, why would it be a viable solution for desktop-style web apps?

Just step back for a moment and compare the functionality you get from a framework like Angular or Ember to the functionality you get with the iOS or Android SDK and you will see they are all solving generally the same problem in the same way. The only difference is that there are far more choices of frameworks on the Web (which is both a curse and a blessing).