News for hackers. Stuff that matters.

A comment on Ember Fastboot. Parent comment

Re:Ember Fastboot by mtberatwork on Tuesday March 29, 2016 @06:47PM (#11385593)
> 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)?

[ Parent | on HN ]
Re:Ember Fastboot by orf on Tuesday March 29, 2016 @07:19PM (#11385765)
> 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.

[ Parent | on HN ]
Re:Ember Fastboot by takno on Tuesday March 29, 2016 @10:01PM (#11386452)
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
[ Parent | on HN ]
Re:Ember Fastboot by orf on Wednesday March 30, 2016 @05:36AM (#11388074)
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?
[ Parent | on HN ]
Re:Ember Fastboot by Kiro on Wednesday March 30, 2016 @05:16AM (#11387983)
With Django, RoR etc all subsequent navigation would require full page reloads while this only does it the first time.
[ Parent | on HN ]