How We Will Develop for the Web in Five Years
Okay, I admit that I'm predisposed to prognostication, but I'm less inclined to blog if I'm not confident. So comeback in five years so I can say, "Told ya so!"
In five years, nearly everyone who writes code for the web will be using a web-based IDE to create those applications. All of the libraries that you use to create your UI will be hosted on a CDN, freely available to all, and your IDE will be aware of the CDN. You'll add new widgets to your toolbox by specifying CDN URLs.
The MVCC for your web project will be hosted by your cloud infrastructure provider. Unit tests and code coverage requirements will be imposed on check-in, and continuous integration will be de rigueur. The other distributed developers on your team will receive a notification of failed builds in the web-based IDE, and workgroup chat capabilities in the IDE will be used to coordinate a fix.
On the server-side, the distinction between persistent storage and in-flight objects will have all but disappeared. No longer will there be a separate notion of a data store and middle-tier objects. Ad-hoc object composition will be supported via interfaces in the object runtime, as opposed to a query language. Backups and disaster recovery will be outmoded ideas, as the cloud infrastructure provider will ensure redundancy and edge computing performance in myriad datacenters. Data replication between these points-of-presence will be completely automatic and unnoticeable.
The standard application architecture will be server-coordinated real-time continuations. The majority of applications will have just a handful of screens in the UI, with one screen generally accounting for 80% of interactions. These screens will be HTML pages generated primarily using JavaScript UI toolkits. That is, the server will not generate individual pages, but will deliver client-side applications. These applications/screens will interact with the server via RESTful AJAX calls returning JSON that will move forward a state-machine facilitated by continuations on the server. Browser extensions like AIR/Flex, Gears, and Silverlight will be used primarily for their ability to allow offline application interactions, not for flashy graphics or rich-media, but this usage will eventually be deprecated by browser implementations of offline storage in HTML 5.
State machines and workflows will be specified using a constraint language layered on top of the fluent interface/DSL available ipso facto on a platform that requires an object model to get any work done. So, business rules will be clearer and organized, allowing more transparency in the development process.
This state of affairs will require domain-driven design a priori. While user interfaces and the mechanics of interactions could be built ahead of other development, all meaningful interactions will require the construction of workflows out of domain models.
Much of these ideas already exist. Seaside is a great example of browser-based development and server-side continuations. Salesforce.com's Force.com platform imposes code coverage restrictions for production code. LINQ provides an object-runtime method of programming without an explicit query language. Google hosts jQuery and other tools on its CDN. ASP.NET 4.0 stands poised to take client-side templating to the masses. AWS, Azure, AppEngine, and RailYard are providing the infrastructure we need. The pieces exist, what I wanted to do was articulate a vision for the future where these technologies are mainstream, integrated, and proven.
