I attended the Google I/O conference a couple weeks ago. Here are some thoughts I had from that.
Google has resource constraints, makes mistakes and misses deadlines too. They work in small, focused teams. 40% of Google’s new products in the last year have come out of 20-percent time projects. They do a lot of split A/B testing where they test different versions of the site on small groups and use metrics to determine what’s best. Google’s view is that anything that expands the web is good for Google, so they’re providing all these cool APIs for free.
It will be hard for a small company to keep up with the technology, especially if it is spread thin. Disruptive innovation will always happen before implementation and deployment of a current technology can be completed on a large project.
The web is moving away from RDBMSes as a back end data store. They just don't scale. An emphasis is being placed on what information is "current enough" instead of always the most up to date. In what contexts can this method be used vs. strict transactional, relational data? To what capacity does a project need to scale? That will be the biggest factor in determining whether or not to move to a data store like HBase.
Android is a cool platform, but will still be limited by the wireless companies that use it. No accessory (e.g. printer or signature capture pad) support in the near future and it's unlikely to be able to hack it in because you can't install native apps. It’s an open platform, but can and most likely will be locked down by the wireless companies. Android will have Gears support though.
Targeting WebKit will likely be the best way to get apps to the iPhone and Android phones for the next few years. It may be the only way to target both platforms without significant development overlap. It may be possible to provide specific hooks to the native platforms via browser plugins (currently impossible) or apps that embed the browser (will be possible on Android and iPhone 2.0, though limited).
The best way to develop apps for the web may be to determine if it is possible to deliver 80-90% of the requested features with just the browser and then make up the next 5-10% with optional native hooks. For example, one could deliver a web-based contact manager. If the user has installed Gears, the user can get offline lookup of some subset of contacts and perform some, but not all, actions on those contacts. Providing offline support will require architectural overhead, which may be minor or very significant – I can’t really say at this point.