I've seen companies falling at the other extreme ... making the interface "totally" decoupled, so that they could replace the UI anytime they wanted. That's why monstrosities like XSLT appeared.

But I haven't seen any example of a good application yet that does this successfully, because whether you like it or not, the web UI will require backend logic that your iPhone app does not, and vice-versa. And you'll either create a common denominator, or two different branches.

Also, if your iPhone app is so similar, maybe it shouldn't be an app in the first place, but an iPhone-optimized website. It's Apple's fault if they aren't making the integration between websites and the iPhone easier.

Don't get me wrong, web services have their place, but make no mistake ... a website that assembles the page from web services is a lot trickier to scale (assuming you're the one providing those services).

The fact remains that human preference is for tailored UI and not until AJAX took hold was the desktops dominance as a platform threatened. Time and time again, tailored UI's are preferred. It is the reason for Apple's return to stardom as well as the rise of web 2.0.

Developers try to fight this mentality to work in their boxed solution and I understand it, but you have to clearly refute evidence to the contrary to believe that the user prefers application developed in this manner.

So If that is the case why not design an architecture that accounts for this reality and makes peoples jobs whose responsibility it is to assist the user instead of enforcing a developers domain on them.

As well, I do not agree that different UI's require different back end logic they require different work-flow logic and work-flow is not reusable. If they require different back end logic for say getCustomer, addCustomer, validateAddress then there is core architectural flaw in the solution. How a customer is then displayed is a problem for the UI e.g. Do I show all info in one screen do I show pivots to make room for more screen real-state.

It is not Apples fault, that is faulty logic, Apple is giving their users what they want and their last quarter clearly reflects that.

Web sites that rely on web services are not tricky to scale look at my document on amazon I referenced. It is essential to scaling. Google, Amazon et. al. are doing this precisely for that reason scalability and to not be locked into back-end or front end technologies. Not to mention you are distributing all work-flow and dynamic templating to the clients, which in practice has a large impact on resource utilization.

I know that they are using lots of web services, but the assembly is still mostly done on their servers (not in the browser), and you're talking about something else (or have I understood you wrong?).

I've seen a talk from an Amazon fellow. They are using web services for parallel processing ... their frontend servers are sending asynchronous requests to those services, which is a huge win.

But in a browser, for an Ajax frontend that happens to periodically request updates, one thing that happens is that the number of requests made from a single client is a lot larger. Surely it doesn't reload all the static files, but those are non-issues even for a reasonable high-traffic website ... just put something like Varnish to serve them and make sure they have expiration headers in the future.

My company did consultancy work in matters of scalability for http://www.erepublik.com/ and after we placed a Varnish in front (that also functions as a load-balancer for Apache servers) it could handle thousands of concurrent requests to static files. And their biggest problem was definitely not the load on their Apache servers (it was MySql).

And this is mostly what I was thinking about.

Most people are already doing it.

I think there are two important points here. First, that is at best a beta level proposal, and I wouldn't bet the well being of my family on it. I'll be very happy when it stabilizes, but I'd stick to outputting plain html for the engines.

Second, this sounds far more complicated than simply outputting html from your web app. This thread is about decoupling UI from the backend for a clean design. Using this approach is far less clean than outputting the html directly.

It would be just as valid to argue that a fire-walled web environment is more complicated than one that is not fire-walled, while true it ignores a host of realities, but it is accepted that the advantages of security outweigh the complexity of a firewall.

What I am saying is that much like a firewall, it is a task of configuration and not custom development and therefore given its ease of implementation, the advantages outweigh the marginal complexity (I am arguing that it is marginal) that it brings.

As well, I am arguing that much like a firewall ejecting this problem domain out of the application, creates a simpler solution. You can implement access security in your application, but it is commonly accepted that rolling your own is a bad idea. The advantages of dynamic user applications are clear and I am arguing that those advantage clearly outweigh the need for this simple solution, if SEO is even a problem domain of your application, it is not for some.

Please, leave this fantasy to me then, because I like real money :)