There have been a few attempts over the years to take a more revolutionary approach to pushing the web forward. Google's Dart, Microsoft's TypeScript are some examples of these. While these have been interesting to skim, I have never followed them too closely because they lacked the kind of support they would need to succeed. JavaScript alternatives can compile to JavaScript, but without being built into the browser, they were never going to replace JavaScript.

Yesterday, news of the Web Assembly initiative broke:

• TechCrunch: Google, Microsoft, Mozilla And Others Team Up To Launch WebAssembly, A New Binary Format For The Web
• Ars Technica: The Web is getting its bytecode: WebAssembly

It's far too early to decide whether or not this will work out, there's very little detail to go on at this point. However, I was pleased to see that the group of companies putting some support behind it seems to be the right group. If Apple, Mozilla, Microsoft and Google all put their weight behind an initiative to improve the web, there's a much better chance of it succeeding than if one, or none of them does.

Now, "weight" is a subjective term, and it wouldn't be hard to imagine one or all of these companies not putting enough force behind this to make it a success. But if they really do all commit significant resources to this kind of effort, there's a real chance that this could be a moment in the history of the web that we look back on as a turning point.

It's still too early to have much of an opinion, but I'm interested to see where this goes.

Ars Technica's "Google's Iron Grip on Android: Controlling open source by any means necessary" is an interesting look at some of the problems that Google faces with Android and some of the strategies they've had to employ along the way.

Google has had to take a very interesting position with Android because they didn't really want to be in the mobile phone business, they just want to protect themselves from the Mobile business changing the business they are in too drastically. Google's business depends on the health of the web, and Google's place in that.

In order to protect their position, Google doesn't want to rely too heavily on the goodwill of others, any more than Apple does, although I don't think that's as ingrained in Google's DNA as Apple's. Android, for Google, is about ensuring that they have a say in the evolution of the mobile phone and mobile device market and how that has an impact on Google. They were willing to give away a fair amount of value in this new market as long as it helped to support Google's existing business.

Exerting enough control over an open-source project to meet your own objectives is a tricky thing, and Android has always had to walk that line carefully by being a hybrid of open and closed source models. Much of the development of new versions of Android is done completely in the dark, with code only being open-sourced near the release date. Portions of the overall Android experience are wholly dependent on proprietary closed-source Google applications and services which are only available to you if you meet certain conditions. You can build an Android device without these, but not without a significant investment in filling these holes.

The emergence of out-and-out-forks that do exactly that has encouraged Google to continue to seek more leverage over the Android ecosystem by moving features into closed-source applications and tying them to Google services, which they can control more completely.

Ars Technica has done a typically solid job of covering those problems and some of the solutions Google has employed, and it's a worthwhile read.

My posts from a couple years ago about building testable components for Google Web Toolkit with MVP are still fairly popular, they still drive a fair amount of traffic. GWT applications that I built in that era still use MVP, and while it certainly made those applications testable, the cost in boilerplate code and maintainability is high.

In the meantime, however, there were significant improvements in test frameworks that could disarm GWT widgets, making them testable without using the very slow GWTTestCase. If I were starting a new Google Web Toolkit application right now, I would be much more inclined to take this approach as the primary approach for building testable GWT applications.

Unsurprisingly, others have gone down this path. There's a pretty accessible presentation from Google I/O 2013 that talks about these different approaches for testing in GWT, Demystifying MVP and EventBus in GWT:

The first half of this presentation discusses some of the styles, the uses of MVP, and the alternative approach of building testable views by disarming the GWT widgets. It's pretty easy to follow, and in addition, the presentation briefly introduces gwtmockito, a framework for making it slightly easier to use mockito and GWT together for testable composite views.

While I haven't spent a lot of time with this approach and I haven't yet tried the framework, this matches very closely the path I would be inclined to explore with a new GWT application, so it feels like it's a step in the right direction at the very least.

If you're building applications in Google Web Toolkit, or considering a significant refactoring of an existing project, it's well worth watching.

Dave Winer suggests that using iOS has a flip side -- Apple controlling mobile through the App Store:

Right now it's the only open source mobile OS that has a chance against IOS. If there is no alternative to IOS then Apple will have exclusive control over what makes it to market. That is a future none of us should want to live in.  

...

I don't like Google any more than I like Apple. But at least they don't control the channel of apps to users of Android. That's a huge deal. It makes up for a lot of Android's inadequacies. And if Google fucks us, let's find another home.

John Gruber points out that you could argue the Flip Side to Android is your loss of privacy to Google:

But, to quote Neil McCauley, there is a flip side to that coin. Winer’s perspective is that Apple is the bigger threat. A different perspective would be that Google is the bigger threat, and that using Apple products is a way to better protect our privacy and personal information. 

Fear of Apple is about losing control over the software on our computers. Fear of Google is about losing control over our privacy.

These are both good arguments.  Apple's control over the App Store has some positive effects, but it's clear that it puts a lot of power in Apple's hands and they can and will make capricious decisions that we may disagree with.

Google absolutely wants to know as much about you as it can and sell you in aggregate form to advertisers. That's their business, and if you don't like that, then storing most of your personal information on Google's services is probably scary.

I think it's a mistake to link Android only to Google. As has become entirely clear, the open-ness of Android is to be open to the manufacturers and carriers who often close it with respect to its customers. Putting your faith in Android is not merely to trust Google, but to trust Motorola, HTC, Samsung, etc. and Verizon, AT&T, Telus, Rogers, Sprint, T-Mobile, Orange, etc.

Pre-iPhone mobile phones were entirely controlled by the manufacturers and carriers. The iPhone was in many respect a great liberation the mobile phone market. Although Apple retains the same powers that the manufacturers and carriers once did, they attempt and mostly succeed to use those powers to improve your experience as a mobile customer (and secondarily to profit from it), and they keep everyone else's hands outside of the cookie jar.

Putting your faith in Android is putting your faith in the mobile phone ecosystem that kept a stranglehold on your phone for years and years before Apple came along. If you think those people are more trustworthy than Apple, you're probably drinking the Open kool-aid.

If Google used its Android powers to force the carriers to make the software open to their customers, to allow people to install whatever they want without worrying about carrier agreements, to prevent spyware installed by carriers, to encourage phone manufacturers to update to the latest version of Android -- if Google was open to customers then maybe I'd agree.

For me, Dave Winer's argument doesn't hold water. I don't see the value in wresting control away from Apple just to hand the power to a larger and shadier group of companies.