The following is based on a talk I gave at the Insites Xmas day in December 2012.
Since the year 2000, web development platforms have become increasingly powerful and secure, faster and leaner, easier and more complex, in every way imaginable.
Although the platforms have become more refined, secure and generally better over the last decade, they have shared a common trait which I believe will cause developers considerable pain over the coming years: it's too easy to create a monolithic application.
Monolithic: formed of a single large block of stone - Google
Even when following best practices and guidelines, separating the logic into projects, tiering the applications so our front-end does not talk to the database directly, all too often we end up deploying our web app into a single folder on the server and thinking we're done.
This is not future proof.
Between 2001-2004 I developed a geographically aware, on and offline, mobile-based platform designed for non-technical people to use. The users loved the applications, but the technology sucked (we were using Windows CE) and when the project was built I left the company and swore off mobile. However, this experience had planted the idea in my mind that in ten or twenty years time, computers will have disappeared from the landscape as we know it.
An increasing percentage of online users will access the web solely on mobile. This means developing across platforms has become an accessibility concern. If you build solely for iOS, you are making a statement that you actively discount those who cannot afford an Apple product.
This might be acceptable if you develop a video player which needs the power of an expensive consumer item, but if you are providing a service which may effect people's lives, such as contact numbers for a hospital, you need to be at least useable on the worst available platform.
The iPhone was released in 2007, five years ago. We can only imagine what we'll have in five years time, whether it's embedded devices in our cars or fridges or in the walls - Smart Devices Which Do Things. We can assume they're going to need to communicate with the web and possibly each other.
When building our platforms, we need to be writing small, specific modules, communicating using open protocols. By separating out the functionality, we release ourselves from the monolithic structure and reduce internal dependency.
Creating common APIs for the platform to communicate with internally forces us to think about the data getting passed around. Only send as much as you need and maintain referential integrity inside your services. Your basket service for an e-commerce site should not care about the ID of the user in a database, because that should be handled by the authentication platform. This is a trivial example, but you should get the picture.
Excited? You should be.