I'm in the process of designing a (soon-to-be) rather large PHP/MySQL web application. I've come to a fork in the road as far as internal architecture; I can build the website as a "traditional" web application where, when you make a request, the server builds you an HTML page, sends you the whole page, and the browser renders it, or, I can build it as a "separated" web application where the entire HTML structure and code of the application is provided to the browser upon initial load, and the application uses JavaScript callbacks to get specific data or issue commands via a unified API. Also, I intend for there to be multiple versions of the site (desktop, mobile, iPhone/Android mobile, search-engine friendly, etc..) and at some point, perhaps even standalone mobile or desktop apps as well.

What advantages/disadvantages have you, as web developers, run into with each of these architectures? Is there a clear reason why I should go with one over the other? Is it more of a developers'-preference thing?

  • Why are people upvoting these questions instead of voting to close as off-topic?
    – delete
    Jul 22, 2010 at 4:16
  • IMO, clearly off-topic according to FAQ: webmasters.stackexchange.com/faq This has been asked and answered many times on Stack Overflow.
    – JasonBirch
    Jul 22, 2010 at 5:49
  • I see this as being on topic, since it is largely about architectural concerns for a web application. The code part is a bit tangential, and such details would be better on SO. Jul 22, 2010 at 6:46
  • 1
    I did try to word this question in such a way that it would fall under an architectural discussion as opposed to a programming discussion. I'm well aware that anything further into programming would have fell into the realm of an SO question, but per the FAQ here: "If your question generally covers the operation of websites which you control, then you're in the right place to ask your question!" I think I'm in the right place.
    – Adam Maras
    Jul 22, 2010 at 13:44
  • @Adam, yes but designing the architecture of a program is a big part of programming. This should be migrated to Stackoverflow IMO.
    – GSto
    Jul 22, 2010 at 19:55

4 Answers 4


I think the idea of a "separated" application that relies heavily on JavaScript/AJAX is going to get you into a lot of trouble. A few things off the top of my head:

  1. It's going to be bad for SEO since Google will have a hard time indexing anything.
  2. It's going to be hard to make it "bookmarkable"
  3. You'll have a hard time with mobile devices as many of them have very limited (or broken) javascript support.
  • Re #2, it's fairly easy to make an AJAX site 'bookmarkable' by using anchors. Try adding #inbox or #drafts to the end of the URL in Gmail. Jul 21, 2010 at 23:30
  • Your Gmail inbox is not indexed by Google. And Google only indexes pages, not anchors. Sep 4, 2010 at 5:22
  • Google parses/interprets javascript code now adays.
    – Chris
    Sep 4, 2010 at 11:48

First off, whether you go with an Asynchronous heavy website or not won't have much affect on your ability to build iPhone/Mobile and desktop apps because it has nothing to do with them. Either way you won't be able to reuse your code.

Also, Asynchronous sites can be just as slow or slower than normal sites. Usually, that kind of functionality is added for a reason, specifically for enriched user experience. Using JavaScript tends to hurt you on SEO because webcrawlers cannot fully understand the intent of the JavaScript and so ignore it mostly.

I think what you are looking for is a way to reduce your development overhead by only writing your functional(middle) tier once and using the same one for all of your apps. In this case I think there is value but frankly these kinds of architectures are harder to setup and take a lot of time. I would be of the opinion that you should develop your website as best you can and keep your middle tier code as strong as you can. That way when it comes time to add an iPhone app or whatever you will be able to move to a model with a common middle level more easily

What I am really advocating here is taking baby steps. Don't try to write code now to handle things you don't know about yet. Just write the code you need and make it as flexible as possible.

  • Also, if you design your application properly (e.g. proper use of the MVC pattern), it should be relatively easy to add a mobile portal or convert the interface to AJAX or add SOAP services later on. Sep 4, 2010 at 5:25
  • Asynchronous sites will usually be faster or at least appear to be so because the browser is usually making only a single request instead of reloading entire pages.
    – Chris
    Sep 4, 2010 at 11:47

First, no offense if this answer is too obvious or basic. Your use of "separated" instead of terms like Ajax or jQuery makes me assume less experience with this topic. Of course i could be misreading the question, so my apologies if that's the case.

Use both, but wisely

Think of your choice of server-side or client-side tasks in terms of where and how a task is most efficiently done. This will help you render pages quickly (on the server), but offload work to the browser where it makes sense to do so. And, there will be gray areas where you just have to make a judgment call. Your job is to find a smart division of labor.

What belongs server side?

(This is an extreme example to illustrate the point.) Say you're writing a web app that does some type of searching. You don't write browser-side Javascript to call a server-side PHP web service to retrieve an entire 2GB database to "free up your server" and offload searching to the user's machine. What you do is get the search terms from the user with a form, POST it back to the server to query the database directly, then send the results back from the server to the browser.

The logic here is that the DB itself knows how to best do the query, the server is closer to the source data, and less data has to be moved around between components. The browser only needs what it displays, so don't send it all to the browser. (Not to mention relative language performance.)

What belongs at the browser?

Browser side code is your "separated" scenario (if i understand correctly). But for the browser to do most anything intelligent, it has to have server cooperation.

Okay, you've got your search app working but you want to spruce it up with some fancy pants Ajax. Write a PHP web service to take a few letters and return matching search terms, a la the "search suggest" feature of Bing, Google, etc. Write your browser code to only suggest terms after the user's typed in three or four letters, so your suggest list is small. Back at the server, index your database on that field so the search is fast fast fast.

Here the thinking is that "search suggest" is a feature that must be split between the server and client. The browser can quickly deal with targeted, small-ish piles of data. The server can get that targeted, small-ish pile of data and give it to the client. A poor division would be for the server to render a monster list (of say, 500,000 items) of possible field values as an XML island embedded in the HTML page, then have the browser search that as the user types. (a) sending all that data to the browser is slow, (b) searching it in Javascript will never be as fast as letting the DB search it, and (c) you're likely to blow up a user's machine by cramming all that data into their browser app space. On the other hand, you need to make sure that the Ajax call to the server, and the subsequent query and return are super-fast. No dilly-dallying around.

Where's the gray area?

Here again it's a judgment call. Above, i talked about the server doing the search, then sending the results to the browser. But, the question arises, do you let the browser submit the search terms with the form and have the server render the result page, or do you use client-side Ajax/Javascript to send the search terms and retrieve the results, then render it in a DIV to avoid a page refresh? Both are valid. Resource-wise, there's no real benefit either way. The Ajax way can provide a better user experience but, depending on your app and the circumstances, might present some other challenges (e.g. security).

Bottom line

Use both appropriately. Don't skimp on thinking and learning about architectural performance and efficiency. Move less data, fewer times. You'll take a load off your servers, your databases, and your users' browsers.


In order to be able to re-use code you can always look at XSLT for the generation of landing pages and then have XML/JSON interfaces for AJAX (utilising the XML interface for the XSLT landing pages).

You would normally allow the content and interaction to work on a RESTful interface with a /json/... and /xml/... prefix and host your main content, converted into mark-up via XSLT on /...

This way people can land on any page and suddenly have the full blown AJAX website. Spiders can crawl your site and you have concentrated on the content/interfaces first and foremost - seems like a win/win.

Mobile websites sometimes need different layouts (bespoke iPhone only sites anyone?) a simple XSLT conversion here or there for different user clients can re-use everything you've done so far.

Remember to design for simple HTML output and navigation, the AJAX simplifications can follow.

PS - Do the XSLT transformations server side

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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