Neither is an IPhone app, but I can guarantee you that most of the logic I use for my "Web Application" will be reused by my IPhone application. With the exception of my templating, work-flow and UI specific logic, so it begs the question why am I implementing my templating, workflow UI specific logic, in my "Web Application" (it's not reusable). Unless it really is a web UI to my enterprise application in which my UI should be worried about its concern? I see so many new companies fall into this trap and then have to do major rewrites when they realize they have boxed themselves into a "Web Application"
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).
No XSLT was an attempt to make the UI generic, either you accept that UI are a custom tailored to be optimized for the platform or you accept the dumb terminal philosophy where you try to generalize the UI to adapt to all platforms.
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).
different apps from these companies are further along in there utilization of a decoupled architecture than others but most all are working to this end, Many of Google's "applications" completely rely on this approach, I cannot comment on their mainstay (search). But most of Google app are assembled via the browser (Gmail, Docs, Maps, Wave) Its core to their strategy, hence entering into the browser market and the rapid push for HTML 5. As for Amazon most ancillary portions of their offerings use a decoupled strategy. The last understanding that I had, was they where waiting for a concrete SEO solution before moving their main asset .com over. These are large companies with legacy code base so it is natural that this architecture is emerging in their new product offering and acquired products first and is migrating it's way back into the legacy code base. In another post I provide referential links to the subject.
OK, you have a point, but I always was under the impression that Google is using Ajax in Gmail, Docs and Maps for user-experience, not for scalability.
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.
If you are doing a web client, that is dynamic, correctly, you should already be reflecting a distinct UI by a URL fragment. having a web proxy run on a seperate box than you production server and routing request for a search bot is not that difficult. There is no custom logic involved you are just proxing through a headless browser. It's not beta it is just that Google is trying to standerdize the practice. Where you get in trouble is if your proxy is giving something different to the bot than the end user is getting. It really is a simple as if a request comes from a bot agent service it from the proxy box, it's a router rule.
Not if you are supporting multipal clients and want to seperate out your concerns. The point is that the UI should be decoupled from your core application logic. The advantages that brings, negates the few hours one will spend setting up an out of the box server and proxy to support SEO. There are many web apps that don't even have SEO as a problem domain.
No I am arguing that setting up a route based on an agent does not require custom logic and therefore removes the problem from a development issue.
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.
odd, I've done numerous startups that have succeeded due to seo. I.e. 80+ % of sales were from organic search traffic, 100+ k unique visitors a day from organic search traffic, etc.
Please, leave this fantasy to me then, because I like real money :)
