Thursday, June 12, 2008

Google I/O thoughts

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 as an application platform is getting much better. It still sucks in many ways, like Javascript as a language, tool support, desktop integration, etc., but there initiatives to address those problems. Gears is a big step forward. SSBs (e.g. Prism and Fluid) and platforms like Adobe Air solve some of these problems. Web applications will never keep up with desktop applications in terms of user interface, performance, and integration.

Javascript still sucks. GWT does solve a lot of the suckiness, but what's the long term viability of it? GWT is pretty cool and is not an all-or-nothing venture, so it would be good to investigate. Javascript 2 is still a long ways off and may not even address the enough of the suckiness. This is a downside of going to a mostly web-based platform.

There seems to be a trend for moving more application logic to the client side Javascript layer of the application. This is necessary if offline support is to be achieved. This does open up security issues unless constraints are also enforced on the server side, creating duplication and therefore maintenance issues.

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.

No comments: