Client-side MVC’s major bug - TimKadlec.com
I’ve said it before: if your client-side MVC framework does not support server-side rendering, that is a bug. It cripples performance.
I’ve said it before: if your client-side MVC framework does not support server-side rendering, that is a bug. It cripples performance.
This!
The difference between back-enders and front-enders is that the first work in only one environment, while the second have to work with myriad of environments that may hold unpleasant surprises.
Yes!
I feel that the subconscious assumption that a complex JavaScript-driven web site or web app will run in only one monolithic environment is the root cause of many problems front-enders see in back-end-driven web-based projects.
I have doubts about Angular 1.x’s suitability for modern web development. If one is uncharitably inclined, one could describe it as a front-end framework by non-front-enders for non-front-enders.
I like the thinking behind this isomorphic JavaScript library: start with the (Node.js) server and then take over on the client side after the initial page load.
The motivation seems entirely misplaced to me (SEO? Really?) but never mind: the end result could be the holy grail of JavaScript MVC frameworks — code that runs on the server and the client. That would get you the reach and initial rendering speed of progressive enhancement, combined with the power of client-side application logic once the page has loaded.
Watch this space.
The Filament Group run the numbers on how long it takes browsers to parse the JavaScript of popular MVC frameworks: Backbone, Angular, and Ember. The results—especially on mobile browsers—are not encouraging.
The creator of PHP offers an antidote to the profusion of frameworks out there.