3 ms·
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
by explorigin 11y ago
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.
- seivan 11y agoTurbolinks 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.
- aikah 11y agoTurbolinks 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.
- brlewis 11y agoIf 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.