There are currently multiple approaches for building web applications:
1. Server-side only
This is a classical approach where you render pages on the server by a web framework like Ruby on Rails, Django, Express, Play! Framework and etc.
Typical workflow: Build all your business logic, models and view templates on the server in the framework of your choice.
2. Client-side + REST API
Relatively not too long ago, web community as a whole started to build client-side applications in Angular, Backbone, Ember, and a few dozen of other JavaScript MV* frameworks. And now we also have React.js join the party.
UPDATE: There is no misunderstanding. What I meant by client-side only is complete separation of concerns. Your have a REST API server and a client-side application that talks to that server. Depending on your use case, chances are, you will never have a true client-side only application that doesn’t connect to a back-end either for authentication or data persistence.
Typical workflow: Spend hours deciding on Angular vs Backbone vs Ember vs X. Then you build your routes, models, views, controllers on the client. After you are done, now build models, controllers, routes on the server. In a way you are doing double amount of work.
3. Hybrid
I don’t know much about using this approach, but if I were to take a guess, you render your views (View of the MVC framework) on the server. As a result you get SEO support plus faster page loads.
On the Hybrid front there is airbnb’s rendr that supposedly combines backbone and express together.
Eric Florenzo has posted on his blog today: React: Finally, a great server/client web stack.
The amount of ways to build web applications is just overwhelming. And for someone who’s learning web development this can become a problem. How does one decide on which approach to use in order to build their next application?
3
I think you have totally misunderstood the “Client Side Only”.
Firstly it should be labelled “Client Centric”. This whole point of frameworks like Angular is that the “VC” parts of MVC are implemented entirely in the browser in Javascript. The “M” higher level logic of the “M” part — the Model — are implemented in the browser and the lower level “CRUD” logic is implemented on the server.
The business logic is developed once. The view logic is developed once. The control logic is developed once — all in the Javascript framework of choice. The data access logic is also developed only once but this time on whatever RESTy or SOAPy framework you choose on the server side.
In extreme cases you can implement the Model entirely in the client, if it is acceptable to access the data from only one browser on one machine, and, have the data trashed every time the “Clear Cookies” option is selected.
4
The answer to the question is that it depends on the requirements. An at least cursory look at the history of “web” development sort of indicates a cowboy culture where talking to stakeholders, customers, requirements gathering, is often overlooked.
I was lucky enough to attend a talk some years ago where I heard something that really stuck with me: “you choose the design to meet the requirements, not the requirements to meet the design”. So when faced with a question like this, you need to go find out what is actually needed by the people who are asking you to build this software.
Your job is to explain the pros and cons behind each approach.
3
I think one of the key points of the newer approaches and frameworks is that there is less coupling between the front end technologies and the back end technologies.
The idea is that you can use whatever framework on the client and pull data and/or views from any number of sources regardless of the server side framework.
This lets us choose the best tools to get the job done and our choices can evolve independently.
Admittedly, I have not used Angular or Backbone so I can not make any experienced recommendations. My current base stack consists of the slimmest server side mvc or restful services I can find. Mostly delivering templates and data. The data is rendered and/or subsequent data retrieved client side using mostly just plain ol’ javascript, jquery, and css.
I start here and build on it were I need to. The benefits of this approach are evident when you think about supporting multiple client platforms – browser, mobile, etc. If you need client specific rendering, you shouldn’t need to make massive changes server side.