[mtberatwork]

> When an HTTP request comes in, we direct it to Ember's router, where it figures out what models to load and components to render. When it finishes, it sends the document back to the browser.

Aren't we now just back to square one again in terms of MVC frameworks? What are the advantages here over simply implementing Django, RoR, Spring, Laravel, etc and cutting back on the JS (at least in terms of content-driven sites)?

[orf]

> What are the advantages here over simply implementing...

You get all of the advantages of single page apps, without the unresponsive initial load time. There are also whole classes of apps you can't build with Django, RoR etc, so the question is a bit ridiculous IMO.

[takno]

It really isn't. Jumping into using a huge performance sink like ember to add a little interactivity to a content page is a horrible decision to start with. This just seems to drag the poor performance back to kill your server

[orf]

That's a straw man though. Sure, adding Ember for a "little interactivity" is kind of stupid. But if you want to add a lot of interactivity? Is a load of "$.click" function soup better?

[Kiro]

With Django, RoR etc all subsequent navigation would require full page reloads while this only does it the first time.