News for hackers. Stuff that matters.
Re:The Cost of Frameworks by explorigin on Tuesday November 17, 2015 @10:07AM (#10581464)
Big picture this is a good reminder when the next big thing comes along <cough>React</cough> but he forgets where we came from. Prior to Angular, the major way of doing web-apps was with rendered templates that would replace whole swaths of html and so the "updating the DOM" step truly was more expensive than the Javascript driving it. This is the problem that Angular (and newer) frameworks/libraries sought to address.

But there's one more consideration...isomorphic rendering. If a framework can be rendered on the server-side then the time-to-interaction only matters if it's longer than it takes for the user to mentally process the page and take an action.

Re:The Cost of Frameworks by brlewis on Tuesday November 17, 2015 @03:26PM (#10583712)
If a framework can be rendered on the server-side then the time-to-interaction only matters if it's longer than it takes for the user to mentally process the page and take an action.

Yes, but time-to-interaction can be long when connectivity is poor. Connectivity is frequently poor.

Re:The Cost of Frameworks by seivan on Tuesday November 17, 2015 @02:34PM (#10583417)
Turbolinks is a good alternative if you want to stay on the Rails path. While Turbolinks 2 just replaced <body> with Turbolinks 3 you can replace partials without resorting to js.erb-templates.
Re:The Cost of Frameworks by aikah on Tuesday November 17, 2015 @03:26PM (#10583709)
Turbolinks should be turned off by default. Rails developers went way too far with it, it actually can f-ck up third party scripts on a page. Opinionated web frameworks are good, but they should stick to server-side tasks.

Turbolinks should have been an extension, not in the core. With these kinds of gimmicks, and constant breaking of APIs from versions to versions , Rails is committing adoption suicide.