Clearly at this point both architectures work, it's childish to see this as an argument for server-side rendering. Obviously it works, so do client MVC systems.

The value in this article is the humble detailing of their mistakes that many of us also experience in our careers.

I've had to deal with more than my fair share of crappy, hacked-together Ember apps that were developed like this. There have been too many breaking changes to upgrade, performance is bad, an they're full of hacks to work around deficiencies that existed back then.

Even though we actually have production-ready frameworks now, that sort of thing can leave a bad taste in your mouth. Especially when you see the same mistakes made by people jumping onto the Meteor bandwagon, for example. But it's defintiely something to try and get over :)

In many ways this is the same as Rails Apps have traditionally been very much tied to Rails.

Having worked on many Rails Apps that have grown beyond the scope of the framework, the apps I build today are as decoupled as possible from the framework.

I hope that the Ember community can grow in that direction too, and at a distant look, it feels like Web Components will be that method of decoupling.

Right now I tell everyone that I'd never render HTML (or JS) on the server, and I hope that JS frameworks will keep maturing with my clients' needs, so I don't have to renege on that approach.

Worse, 'cool kids' implies doing something because someone else is doing it rather than because it's the right thing to do in your organisation. It smacks of cargo cult behaviour - copying actions and hoping to get the same end result without understanding why.

    >and a lightweight custom JavaScript binding system