I had a thought on the plane on the way over after we announced Atlas.
The past ten years in programming has seen the rise of a huge number of ways of building similar-looking applications – from using VB6 to build a rich client experience, to dynamic HTML, to plugging into a browser with ActiveX or Flash, to the combination of technologies now labeled “AJAX.” These styles of application development combine programming language, programming framework, development methodology, administration implications, deployment, and end-user experience into a single entity called an application model.
Application models represent a way to improve a development team’s odds against the perennial tradeoffs of application development: “Time, money, or quality: Pick two.” Each application model comes with its strengths and weaknesses designed to optimize for making it easier to get all three, though none of them is there yet. VB6 for example offers a particularly productive development environment, but runs on fewer clients than, say, DHTML. Flash enables designers to create rich UI experiences, but lacks the full gamut of online/offline capabilities that you would expect from a smart client.
This richness in the application model landscape is both a help and a hindrance for application developers. In particular, tremendously disjoint development skills are required to incrementally improve the user experience from, say, HTML 3.2 to DHTML to Flash to VB. Each step along the application’s richness requires hugely different skills: new programming languages, new development frameworks to learn, and new development tools and processes.
Even beyond the client, one of the fundamental problems that developers face today is that classic desktop (smart) applications tend to be isolated to the client computer. The IT industry has yet to produce a really great way to create smart client applications that use a server effectively – being smart about what to do if the server is offline temporarily or if the client is disconnected from the network, how to synchronize data between the client and server, and how to handle authentication between the client and the server. Building a smart client application that truly uses a provisioning server (a centralized repository of services and data) is an overwhelmingly complex and daunting task – one that most companies can’t afford to invest in.
The alternative has been to write a web application. Web applications certainly make use of the server, but pay a price: they don’t leverage all the richness offered by the client and its operating system and require connectivity to function. Much of this is simply due to limitations in the technologies – the gap between Web application models and smart client application models. For example, DHTML doesn’t offer any way to deeply integrate with the client, and writing complex DHTML (like AJAX requires) is incredibly complex and often involves the use of programming “worst practices” in addition to several rocket scientists – these application are non-trivial.
If the pain felt here were solely contained to developers, it might be tolerable. But each of these transitions of application model results in costs that the IT infrastructure must bear in the form of different deployment and management systems and different operational guidelines. End customers are also affected, as each transition in the application model results in either severe degradation of the user experience or dramatic changes in the richness of the application.
The historical way to “solve” this problem has been to provide a single application model designed to do everything. This approach was particularly typified by Java, which with its Abstract Windowing Toolkit (AWT) and later with the Swing infrastructure tried to make every device and every PC behave the same. But the idea of the “universal application model” that can meet every need is flawed: it reduces the capabilities of the underlying platform to only those understood by the application model’s rendering infrastructure giving the user a degraded experience (for example, eliminating handwriting recognition or flattening all the colors on the screen), it forces developers to learn a new application model, and it forces administrators to learn new technologies for application deployment and maintenance.
Rather than trying to replace every application model in use today with one perfect model, a better solution is to let them flourish and to connect them together so that each can do what it does best. This vision, which I’d call the “Scalable User Experience,” is where Atlas begins to take application models. This team is building off three tenets (even if they don’t know it):
• Respect the richness of the client (whatever that is) to provide the best possible user experience
• Contain complexity on the server to build on existing administration skills and infrastructure
• Leave no developer behind by using existing developer skills, code, and tools
There’s more thinking to be done here, but if the demos I saw at the last ASP.NET team meeting were any indicator, you’re going to see more, not less of Atlas-like functionality coming out of Microsoft.