My good friends Chrome and Brackets all blended together.
I believe there is a special place in application hell for applications that make me restart my browser. Allow some hyperbole here, but I always felt like that was on par with someone coming into my house while I’m working and punching me in the face. Making me restart my browser makes me lose my music, sometimes lose my place in a video, and since I have a ton of tabs open, makes me sit there and wait while every one of them reloads.
So while I love the Live Preview feature from Brackets, it always annoys me when I’m developing along, go to test, and Brackets tells me I need to restart my browser so it can enable the feature (Edit: As Randy notes, the restart is only required on Mac). Luckily there’s a way to enable Chrome to always start with the remote debugging feature Brackets needs. And using Automator I was able to add a shell script as something that could live in my Dock so that I’m able to use that as my launcher for Chrome.
The shell script just uses the
open /Applications/Google\ Chrome.app/ --args --remote-debugging-port=9222
There are a couple of drawbacks. One, I have no idea what this has in terms of security implications (leaving the remote deubgging on all the time). That’s something I need to look into. The other downside is that this doesn’t open up within the same process, so you end up with the Chrome icon in the dock in addition to your shortcut. But that seems minor. Edit: Also, what would be ideal is if this was a flag exposed in Chrome so that you can make it persistent through opening/closing Chrome. Luckily Adam filed this as a request.
If you want to just grab the Automator file, I’ve got it on Dropbox.
TechCruch just posted about the news that Adobe and Google are going to be collaborating a bit around Chrome and Flash Player. The basic gist is that Chrome will start integrating Flash Player directly into the browser so that users will always have the most up to date versions and anyone who downloads Chrome won’t need to also install Flash Player. I think that’s good, but the much bigger news in my opinion, is that we’re working with Chrome and Mozilla to revamp the plugin architecture. This has huge implications.
We’ve been using an old-school plugin model for a long time. In fact NPAPI, the plugin interface, stands for Netscape Plugin Application Programming Interface. And as the Wikipedia entry states, it’s so sucessful because it’s so simple. The API basically lets plugins associate themselves with a content type (like a SWF file) and then puts that plugin in charge of all the rendering. There’s not a lot of integration between the plugin and the content in the browser, which means the plugin lives in its own little world and it’s tough to break out. You can do things like ExternalInterface but it’s still pretty hacky.
But under this new plugin model, we’ll have much closer integration at the browser level. There’s a great summary of what this means at the Chromium blog:
Think better access to the hardware APIs via this new plug-in model, better access to the DOM, and a generally much better, more stable experience. Flash Player in the browser has always felt a little like a black box largely because of the constraints in the plugin model. Certain things didn’t work quite as you’d expect in a regular HTML site. Hopefully this changes that. In theory this could make it possible to use the save-password feature with your Flex/Flash apps, or make Flash SEO a lot easier, and it allows us to innovate around HTML-Flash integration. If you’ve used AIR, you’ve seen what’s possible when you have complete control over both technologies. This new plugin work makes that easier to do across all browsers that support it. I don’t know when/if we’ll see it, but it’s easier now.
Another benefit is that the API is going to be OS and browser neutral so you won’t see such wildly different performance on different platforms. The hooks that we can use to make the browsing experience better will work across all of the browsers that support the new plugin across all of the operating systems.
Sarah Perez over at ReadWriteWeb has a post up titled Are you Over AIR Applications in which she talks about her change in perspective on the value of AIR and how much benefit desktop applications provide over browser applications. It’s a pretty good post, and one that I hope drives some traffic and conversation, especially as we’re hearing more about things like Chrome, Firefox 3.5, and the Chrome OS.
Notifications and Files
I think notifications, or the “toast” windows that you can pop up in AIR are more and more important as the web gets more real time. People want the firehose and they want it as soon as they can get it. Another area that I think AIR hasn’t been used enough for are filetypes. It’s incredibly powerful to be able to not only create items on the file system but to associate those with your applications. So far there hasn’t been need to create things like a .twitter file extension, but the next generation of web services may see big benefits from users being able to create those extensions. And of course with the file system you get some inherent benefits like the ability to tie into Spotlight or other desktop searches.
Ultimately I think both the browser and a more web-centric approach to desktop applications will succeed. The cross platform benefits, the improved developer productivity, and the close integration with web services are going to be instrumental in driving adoption for web applications both inside and outside of the browser. I hope AIR continues to do well and help drive innovation for web applications on the desktop. Seeing technologies like Google Gears and Titanium’s Appcelerator prove to me that the space is still growing and that we’ve got a lot of demand for a blend of web and desktop. And we’ve got a lot of enhancements coming up in the next version of AIR, so we’re not standing still. Stay tuned.