4 ms·
I would argue that the greatest benefit that client side MVC frameworks bring is that they enforce a clean RESTful API on the server. At a panel on MV* framewor
by olegp 14y ago
I would argue that the greatest benefit that client side MVC frameworks bring is that they enforce a clean RESTful API on the server. At a panel on MV* frameworks at HelsinkiJS last week somebody even said that they had to dramatically improve their API to make it work with Ember.
I myself have been working on https://starthq.com https://starthq.com which started life as a single page app using AngularJS where most of the functionality was behind a login. It has now pivoted into a web app directory, where delivering the initial page quickly and in a way that Google can easily index is crucial & there's very little actual input validation or interactivity on the page. The nice thing is that despite this transition, the core API has remained the same regardless of where the view is rendered and the architecture is all the better for it.
Give it a go and see if you can tell which pages are rendered entirely on the server and which entirely on the client.
- qschneier 14y agoI agree and would rephrase it as client side frameworks help to enforce a clean and well defined API on the data, thus help to separate the business logic from representation / interaction, which is kind of the original goal of MVC.
- Joeri 14y agoI agree. You always need a clean api to allow for multiple front-ends and to have a secure boundary layer between trusted and untrusted data. Even if the rendering happens on the server, you should always start with an api. I work on a 400 kloc app developed with a client-side mvc + web services architecture. The nice thing I've learnt about having a proper services api is that slapping another front-end on top of it is straightforward. We've had a relatively easy time building mobile apps thanks to having the service api ready. And because the core app is built around the same services, they are less likely to break.