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?


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.

| improve this answer | |
  • Its really hard not to develop at least some of the business logic twice. For a good user experience, you need to make sure the user enters their email to continue. But you can't trust the client so you also need to implement the rule on the server. At least I really hope you're not saying implement the business logic in JS on the client. – Andy Jan 24 '14 at 2:33
  • @Andy that is exactly my point. When I built an Ember app, basic form validation had to be done on the client, but it also needed to be done on the server. I got in serious trouble one time for not validating my data on the server and trusting the client completely. – Rated R Jan 24 '14 at 5:19
  • Andy et all -- take a look at google docs. Apart from loading the doc, spreadsheet etc. from the server , saving it at the end, and taking the occasional backup in between everything else takes place in your browser. The Google Docs site just acts as a data store and authentication server. – James Anderson Jan 24 '14 at 8:58
  • 3
    @JamesAnderson Google Docs is quite different from say an online store. You're editing your own document, its just a blob of data that they save without really caring about what the data means. But do you really think order validation should be done ONLY on the client? You're just asking for people to give themselves free products if that's how you build such an app. It seems like you're also assuming that Google is in fact not doing any data validation on the server end. There's not really any way for us to know what's going on. – Andy Jan 24 '14 at 14:04

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.

| improve this answer | |
  • 1
    Thanks. What you are saying makes sense. I was hoping there was a "silver bullet", one true way to do things. I started out with a Python web framework called Django in 2011. Soon after there was a big push towards client-side MV* frameworks like Backbone, Angular, Ember. And suddenly Rails and Django way of building web apps has become outdated. But today it seems we are taking a step backward and mixing client-side with server-side once again to achieve better performance. – Rated R Jan 24 '14 at 5:24
  • Sadly, no, there's no silver bullet. :). However the trick is to have enough understanding of how the pieces fit together to determine the best results for the task at hand, and also to support a culture of ruthless refactoring so that you can always change things if your initial direction wasn't fruitful. – RibaldEddie Jan 24 '14 at 21:43
  • 1
    This is fine and all but sometimes both approach are viable and in this case you need something else than requirement to make a decision. – Ced Nov 30 '15 at 8:21

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.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.