Tag Archives: chrome

Always Starting Chrome with Brackets Live Preview Support

Posted on by
4

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 command:

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.

Flash Player and Chrome Sitting in a Tree

Posted on by
11

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:

Improving the traditional browser plug-in model will make it possible for plug-ins to be just as fast, stable, and secure as the browser’s HTML and JavaScript engines. Over time this will enable HTML, Flash, and other plug-ins to be used together more seamlessly in rendering and scripting.

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.

Are you Bored With Adobe AIR?

Posted on by
5

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.

For much of the past couple of years web applications were trying to mimic basic aspects like functionality and look and feel of desktop applications. That drove the movement towards RIAs and the shift made it painfully obvious that the browser in its current form wasn’t up to snuff. So more and more energy went into improving the browser so that web applications could compete against their entrenched desktop counterparts. We’re finally seeing releases from all that work. Firefox 3.5 looks to incorporate HTML5′s support for offline mode. Chrome was written from scratch because Google felt, basically, that the current browsers weren’t powerful enough to run complex HTML/Javascript based web applications. So what benefits does AIR have in this world? I agree that desktop applications as we know them are falling by the wayside, but AIR still has a few areas I think make it shine.

Web Technologies
One of the best parts of AIR is that it uses web technologies like HTML/Javascript and Flash. Web developers are a creative and innovative bunch. I’d argue that one of the main reasons Web 2.0 exploded the way it did was because web developers took to their destiny as the drivers of technology. Web development is relatively easy to learn but complex enough to keep the challenges coming. It’s also more productive than traditional languages because it’s both faster and it’s cross-platform. The strength of web development is a strength of AIR. Look at the first wave of a game-changing technology like Twitter. Almost all AIR applications. That’s because web technologies are easy and AIR made it very simple to quickly create a new kind of experience for a new kind of service. Tweetdeck and Twhirl got a first mover advantage and reaped the rewards. The development speed that the web allows for shouldn’t be discounted.

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.