Tag Archive for chrome

Wither Webkit?

As you are probably aware Google has forked Webkit and will be calling their fork Blink. Google does not intend to re-merge with the main project at any point in the future and is signaling that they will be adding new features to their rendering engine. As a developer who often has to work on the web or mobile web this is very interesting but also a little concerning.

 

Currently, Blink and Webkit are just about identical, so we can still feel secure in our Webkit “monoculture”, but the situation will likely change in a year or less. Even if Google makes an effort, as some have suggested that they might, to not break standards or chooses not to push Blink specific features, web developers are still going to have to deal with yet another rendering engine. Sure we’ve already been dealing with a number of them and have gotten used to having to append our CSS with “–webkit” or “–moz”, but Google is not adding a “–blink”. Instead, developers will have to dig into a settings screen to enable or disable functionality. Bottom line there is that there will be Blink specific functionality that some developers will likely want to user; for example currently NACL only works on Chrome and Dart VM works best on Chrome – in other browsers code written in Dart has to translated into traditional JavaScript. There are also a number of rumors floating around that Blink may focus on optimizing HTML5 graphics performance on ARM devices.

 

The question really becomes not what Google is going to do with Blink but rather what are the rest of the Webkit team going to do without them? Google and Apple have been the driving forces around the project and more and more Google has been taking point on a lot of the more cutting edge issues; for example, Google has been pushing performance more than any other contributor to the project but, for the most part, Apple and others have been able to benefit from Google’s efforts thanks to the free software nature of the project’s license. Given Apple’s less than enthusiastic embrace of developers using web technologies to develop for their platforms, it seems unlikely that they would be inclined to match Google’s pace. In a lot of ways, give that Apple’s business model is to sell expensive hardware, a good browser is just another feature on an Apple device, however, for Google, the browser is the primary platform.

Progress is a good thing for web and I am confident that Google’s decisions will yield web developers some pretty cool tech to work with, but there is also the risk that web developers will start relying on those tools too much and we will end up back in an IE 6 / ActiveX situation. Questions? Comments? Dogmatic rage? Please feel free to contact me on Google+ or Twitter. This post was brought to you by Code Journal for Mac.

Chrome > Android

chrome-iconAndy Rubin is no longer working on the Android project at Google but, at least for now, is still part of the organization — see his parting email here courtesy of the Wall Street Journal. The good news is that Sundar Pichai is going to be in charge of Android, but the bad news is that he is the head of Chrome / Chrome OS (referring to Chrome and Chrome OS by simply Chrome going forward) and the departments seem to be doing something of a merge; or at the very least the distinct positions of Android head and Chrome head have been merged into one. The question is what does this mean for Android and, more importantly, what does this mean for Android developers and Chrome developers?

First off, let’s face the hard truth about Android it. It is quickly spinning out of Google’s control; one one end Samsung basically has a monopoly on the high end Android device market and on the other there are tons of Asian manufacturers taking Android and slapping it on sub-par devices, further diluting the brand. Chrome, however, is 100% Google. Sure, there is the Chromium open-source project, but guess who sponsors and, for all intents and purposes, controls that? That’s right, Google. Open might be a great marketing term, but let’s be real, it’s a lot easier to monetize an operating system that you control.

Many of you may not necessary agree that Google would be interested in maintaining control of Android, but it is hard to argue that Chrome isn’t  more in line with Google’s goal of a web based world built in HTML and related technologies. It’s called synergy, baby! You don’t need an MBA to see that Android (aka glorified Java) is not exactly in line with an HTML future. If only Google had a web based operating system it could focus on…. As web development technologies continue to evolve and become more capable for developing full featured applications with rich experiences, Android will become increasingly less important to Google.

 

My guess is that the conversion will start slow. Perhaps Google will start to push Chrome apps for the Android version of Chrome. Maybe in a year, when those rumored Google stores start to show, we’ll see a Chrome for Mobile “developer phone.” Regardless of the conversion starts, my bet is that within the next five years Google will start publically pushing Chrome  as its next generation  operating system. In fact, I think it would move faster, and probably had plans to, but is being thwarted but regions with little or poor connectivity — this is a particular issue in large portions of the United States.

The good news is that, overall, developers stand to do well in this scenario. Android developers have little to fear from Google, since Android is largely beyond Google’s control at this point; if Google ever stopped supporting it, hardware manufacturers, chiefly Samsung, have enough riding on the OS to keep some sort maintenance and development effort going. Google’s focus on Chrome will be a boon for web developers. Sure there was WebOS, a good and severely underrated web focused mobile OS from HP, and there will be FireFox OS, but it’s going to take a bit of muscle that HP and Mozilla didn’t have, in the case of HP, and will never have, in the case of Mozilla.

Questions? Comments? Dogmatic rage? Find me on Twitter and Google+. This post was brought to you by Code Journal and Fingertip Tech, INC.

Balsamiq GDrive Edition

I have been more than a little critical of Google Drive, because of its poor support for source control (Git), however, I still use it for a number of document editing tasks. At the same time I have been looking for a wireframe editor that supports designing mobile, web, and desktop applications; I am a big fan of designing the UI first and iterating on that initial design over the lifetime of the app, so that type of tool is an important part of my toolchain.

Balsamiq, the cross platform (Adobe Air, Linux, Mac, and Windows) wireframe tool has been on my radar for some time and I even tried a demo version of the Mac app a few months Overall, I liked it but wanted to something more. It was hard to explain what was missing but something seemed lackingl, then they released the web app for Google Chrome.

This is the tool that I’ve been looking for. It is pretty much as responsive as the desktop app and saves your wireframes right in your GDrive. I found this to be a one two punch of power and convenience that was too hard to resist. Better still, the tool integrates with a number of services including Jira (more on that later) and Fog Creek.

There is a also a number of community developed templates that you can add to the app by uploading them to you GDrive, for example there is a template specifically designed for working on apps for Amazon’s Kindle Fire and Android 3.0 tablets.

I know this sounds a lot like a commercial, but balsamiq for GDrive is a great tool and given how hard it was for me to find a wireframe editor that I like, I assume there are others with the same problem. As a pro level tool, the app is not free. It costs $50 for a year or $5 a month; there is also a free seven day trial. Let me know what think. I can be found on Twitter and Google+.