Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

closed as too broad by gnat, MichaelT, GlenH7, Robert Harvey, Dynamic Jan 28 at 21:23

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

1  
"Client Side only: ...After you are done, now build models, controllers, routes on the server." This does not parse. –  user16764 Jan 24 at 1:33
    
@user16764 updated my question. –  Rated R Jan 24 at 2:30

3 Answers 3

I think you have totaly 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 lofic 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 t to access the data from only one browser on one machine, and, have the data trashed everytime the "Clear Cookies" option is selected.

share|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 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 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 at 8:58
1  
@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 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.

share|improve this answer
    
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 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 at 21:43

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.

share|improve this answer

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