Showing posts with label Chrome. Show all posts
Showing posts with label Chrome. Show all posts

Monday, February 1, 2016

Service Workers will Fundamentally Change the Web

Prior to 2005, the web was a pretty frustrating place compared to the world of native applications. There was no reliable way to have your web app communicate with your backend without having to resort to full-page refreshes, each of which was a complete server round-trip. Something as simple as filling out a form was an agonizing experience. Building something as advanced as Google Docs? Forget about it.

Along came AJAX

A technology known as XmlHttpRequest (or more commonly called AJAX) changed all that. Something that Microsoft had innocently built back in 1998 and added to IE5 in order to support Web Outlook was suddenly being supported in Safari and Firefox, and one morning the world woke up to the magic of Google Maps - a highly interactive mapping app that seamlessly worked in the browser, no page refreshes needed.

Consider how much the web has changed since then. AJAX is now a key part of pretty much every popular web app, and its usage is so ubiquitous that you don’t even think about it. It has so fundamentally altered what’s possible on the web that hardly anyone builds native desktop apps anymore.

The Next Revolution Begins

Ten years on, the web is on the verge of going through yet another one of these transformative moments in the form of Progressive Web Apps, built on top of a key technology called Service Worker. The addition of this technology will have as much of a profound effect on how web apps are built as AJAX did 10 years ago.

Service worker’s key breakthrough is conceptually simple: allow JavaScript code to be "installed" directly into the browser itself, independent of any single web page. That code can then be executed even when the originating web site is not active in any open browser tab, in response to events such as network requests, push message events, and more in the future.

This one fundamental change enables entirely new scenarios:

  • Reliability: Because the service worker can intercept network requests from the browser, it becomes very easy to build web apps that work when there’s no network connection or (more commonly) when the connection is spotty
  • Native behavior: Browsers can run service worker code even when the associated site isn’t loaded, enabling web apps to implement features like push notifications the same way that native apps can
  • Powerful caching: The service worker API includes a Cache API that can cache data as well as the app’s HTML. This enables the app to cache its UX shell locally, enabling an “instant-boot” experience just like native apps
  • Background operations: service workers can register to receive events when the network becomes available, enabling any offline work the user has done to be synchronized back to the server

When you combine service workers with other technologies like the Web App Manifest, your web apps can do things like have a rich homescreen presence on a device, control the app’s layout orientation, and specify a “splash screen” startup experience, giving your app the look and feel of a native one.

It's Already Happening

Some savvy developers have already started to take notice: Facebook is using service workers to enable push notifications on their web app, and Flipkart (India’s largest shopping site) has created an amazing web experience.

These technologies are already supported today in Chrome (both desktop and Android), Firefox, and Opera. Hopefully, Microsoft and Apple will soon follow.

That doesn’t mean, however, that you can’t start using these technologies right away. Service worker follows the principles of progressive enhancement: you build your web apps such that when service worker is present, then users get the benefits, and your default experience when it isn’t. This is the same path that AJAX took when it was first introduced, and there’s no reason why service worker should be any different.

The next ten years of web app development is going to be even more exciting than the last ten. To learn more about service workers, check out:

Happy Coding!

Monday, March 10, 2014

Are Chromebooks the Future of Computing?

I was recently pointed to this article on Tech Republic, which asks if Chromebooks are the future of computing. I’ll come back to that question in a bit, because I want to address the larger, more encompassing one first - are lightweight, web-centric operating systems the future of computing?

Haven’t we been here before?

Let me preface the rest of this post by saying that I’ve been in this industry for some time now - almost 25 years. I can remember when computers were machines that you had to get into via a terminal, such as VT100, often over a dial-up line. Then, along came the desktop computer, popularized by the Apple II and IBM-PC, and the tech press of the time trumpeted that individual personal PCs were the "computers of the future". And for a while, the pendulum swung away from mainframes, and personal PCs ruled.

And boy, did they rule. Just about every electronics company had their own PC: Texas Instruments (Bill Cosby was even their spokesman), Atari, Panasonic, Commodore, Acorn… the list is too long to enumerate here. Eventually, though, there was a shakeout, leaving just Apple and the PC clone industry.

Then the web came along, and the pendulum started to swing back toward server-centric computing, with the client (in this case, a browser) playing a lesser (though still significant) role in the user's computing experience. The idea of having apps and data accessible from almost anywhere once again became vogue, and we even had a massive investment bubble to go along with it.

Here we are once again though, with personal devices delivering a very rich, local computing experience while connected via a cloud-backed service. Today's devices, whether they are iPads, Android tablets, or laptop PCs, work great when offline but truly shine when connected.

That, I think, is the far more important lesson to be learned here rather than whether one platform or another is the "future of computing." The key thing you need to focus on is the trend, not the current state of where things are.

What Do "Most People" Really Need?

Stop and think for a moment about what tablets (whether iOS or Android) do and how they work. They don't have a generally accessible file system in the sense of normal PCs. In fact, they don't have several of the characteristics of what you would call a traditional fully-featured computing device. Most of them aren't expandable, they don't have as much RAM as traditional laptops, there's no mouse, most don't have a physical keyboard, and yet these things are flying off the store shelves. Why? Because they perform almost all the functions that most people need on a daily basis, and they are great second- and third-devices to complement a home's primary computer. They send and read email, play games, take photos, play videos and music, compose documents, etc.

Now, wait a second - don't most of those characteristics sound like Chromebooks? The only difference was that most apps were Web apps, but that all changed last September when Google added the ability to install local, offline-capable native apps on Chromebooks.

When Chrome Apps happened, the last real remaining barrier to Chromebook adoption fell away. The Web is always introducing new features, and since Chrome updates every 6 weeks, a Chromebook owner always has the latest runtime and all the new features to go with it. Developers don't need to wait very long for end users to have the capabilities to run the latest apps, and since Chrome also runs on Windows, Mac, and Linux, the addressable market is huge.

Back to the question

So, are Chromebooks the "future of computing"? I don't know, and I don't think anyone else knows for sure, but what I do know is that consumers have clearly voted in favor of computing that is simple, secure, always-up-to-date, and works wherever they are. Tablets clearly fit that bill, as do modern smartphones, and increasingly, so do Chromebooks.

"Ah", you say, "but didn’t we go through the era of the netbook once before?" My answer to this is simple - Chromebooks aren’t netbooks. Again, let's go back to what made the iPod, then the iPhone, then the iPad super-successful: the ecosystem. People don’t buy "devices" anymore. They buy ecosystems. Consumers want to know that if they buy a particular platform they won’t need to worry about whether it will be supported or whether they can get what they need for it - both in terms of software and accessories.

The main problem that netbooks had was that there was no ecosystem - there was no central software store, no predictable update schedule, no place to bring your device when it was on the fritz, and your friends had different machines so it was hard to share their content.

Chromebooks don't have any of those problems. There's a full, rich ecosystem in the form of the Chrome Web Store, the Web itself, and even Google Play (Chromebooks can play all your Play content like movies and music). There's a set of big, established players supporting them. Content is now vastly standardized, and all your favorite Web apps work just fine (Chromebooks even support Flash, without the security hassles).

Now, sure, they aren't for everybody - but neither were the earliest personal PCs. You had to be a pretty savvy user back in the days of the IBM-PC and even the Apple II. Chromebooks don’t yet fit the bill for people who need to do heavy development or who need to run complex systems, but all of that is just a matter of time. Remember - a lot of the criticism you hear about Chromebooks was similar to what was leveled against Gmail ("no enterprise would ever use that!") and Android ("that ecosystem is way too fragmented!") and Google Docs ("it’s not Office!").

The future of computing is one in which the user is the center, not the device. Operating systems that get out of the way, not ones that insert themselves between you and your work. Simplicity, not complexity. Security, not anti-virus programs. So far, Chromebooks fit all of those. But even if Chromebooks themselves turn out not to be the "future", the directional trend itself is pretty clear.

Don’t be the frog in the pot

Before closing, I want to remind everyone about the parable of the boiling frog. The story is simple, for those of you that haven’t heard it - essentially, if you put a frog in a pot of boiling water, it jumps out right away. But heat the water gradually enough, and the frog will slowly boil to death, unaware of the drastic changes in its surroundings because of the slow nature of the change. The story is somewhat apocryphal, but it’s an apt metaphor for people who aren’t willing or able to notice the changes around them and adapt.

With that in mind, consider the following timeline:

  • 4 years ago, Chromebooks didn’t exist.
  • 3 years ago, Chromebooks were just a curiosity. Back then they didn’t even have a proper desktop or windows - only browser tabs. Many people wondered what they would ever be useful for.
  • 2 years ago, Samsung’s Chromebook suddenly started dominating Amazon’s top-seller list, and Google announced that over 2,000 school districts had adopted Chromebooks. People said "well, for some consumers they make sense, and schools clearly benefit from these devices, but they’re not for mainstream users."
  • Within the last year, Chromebooks were in over 5,000 schools, the Pixel was demonstrating what a high-end Chromebook could be, there were 3 new OEMs making Chromebooks, and you could buy them in a variety of mainstream stores. Oh, and Microsoft finally took notice and decided to start advertising against them.
  • Today, 6 of the top 15 best-selling laptops on Amazon - almost half - are Chromebooks. Every single OEM that makes a PC has now signed on to produce Chromebooks. Even HP, whose CEO Meg Whitman has said "Chromebooks have surprised us", is now making two models (so far!). There are new Chromeboxes on the way, and even enterprises are starting to replace their existing PCs with ChromeOS devices. The Chromecast, which runs a simpler ChromeOS, has literally taken off.

Focus on the trend, not the current state of the world. The water is starting to boil, folks.

Monday, November 4, 2013

Tools for Developing on ChromeOS

I've been using my Chromebook Pixel as my primary machine ever since I got it for most of my work, with one crucial exception - development. Whenever I needed to do more than just edit a couple of individual files, I had to turn to my MacBook Pro with its trusty Sublime text editor and ability to run things like Node.

I'm happy to report, however, that things have changed dramatically just in the last several months, and it's now easier than ever to do real development on your Chromebook. In this post, I'm going to give an overview of some of the tools that I use when developing on my ChromeOS devices (In addition to my Pixel, I also have an HP 14, a Samsung 550 in developer mode, a Samsung Series 3, and an Acer C720).

Keep in mind that some of these tools are fairly new and still developing, so keep an eye on them as they get better over time. Also note that all the tools I talk about in this post are available for all the supported Chrome Apps platforms (Mac, Windows, Linux, and ChromeOS), but I'm focusing just on ChromeOS here.

The Basics - Offline Editing

Let's start with the basics - editing code. Obviously, having a great code editor that works locally on offline files is a prerequisite for any serious development on any computer. For ChromeOS, we have a couple of good options here.

Text App

Until recently, my go-to text editor was - not surprisingly - Text. It's pretty straightforward, works offline, has support for syntax highlighting, syncs with Google Drive, and can easily handle multiple open files.

Screen shot of the Text editor app from the Chrome Web Store
The Text app from the Chrome Web Store
As of this writing, though, Text has a few shortcomings. It doesn't remember the files I had open between sessions, it doesn't remember the window position or size, and it's not very customizable. All that said, though, it's a good editor for what it does, and I still use it all the time for various text editing tasks.

Caret

I'm a pretty big fan of Sublime Text, and it's one of the things I missed most when working on my Chromebook. I recently came across a new Chrome App called Caret that does a great job of code editing and gives me a user experience that's much more like Sublime:

screen shot of the Caret text editor application
The very Sublime-like "Caret" editor

Some of the things I really like about Caret are:
  • It remembers the files I had open between run sessions
  • It remembers the size and position of the window
  • Support for multiple carets and other Sublime-like features
  • Lots of color schemes, support for font sizes, etc.
  • Code completion
  • Very customizable - lots of user-editable settings
  • It's open source and has a Github project
Between these two tools, I think local code editing is pretty well covered. Caret in particular is in active development by the developer, so I'm looking forward to that app getting better over time and incorporating new features as they become available in the Chrome Apps API.

md everywhere

In addition to editing code, I find myself creating and editing Markdown content quite a bit, since it's how ReadMe files and such are represented in Github. 

The app that I usually reach for when I need to do this on my Chromebook is md everywhere, which - you guessed it - runs as an offline Chrome App. It has two main components: a window for editing markdown content, and a separate viewing window to see the HTML output, which can be shown or hidden separately from the editing window.

Editing Markdown on the left, with preview on the right

It's not perfect, and has a few quirks, but it gets the job done and greatly reduces the amount of guesswork involved. There are a couple of other MD editors in the store, but md everywhere seems to be the best of the bunch so far.

Cloud-Based IDEs

One of the more exciting trends of recent years has been the emergence of cloud-based IDEs. These are full-fledged development environments that work within your browser, giving you full access to a remote development box that can run all manner of environments, tools, etc.

Several of these IDE providers have existing apps in the Chrome Web Store, such as (but certainly not limited to): Koding, Cloud9, Nitrous.IOShiftEdit, and Codenvy. There are also collaborative cloud-based editors like Neutron Drive.

Each of these tools could take up an entire post on their own, and I'm planning to do a deeper dive into them at some point, but for the moment I'm going to focus on Nitrous.

Nitrous.IO

The Nitrous guys recently released their online IDE as a packaged Chrome App, so I've been using it a lot recently (which is not to say that any of the others are somehow lesser; to the contrary, they're all very good and have their own strengths). 

Cloud coding with Nitrous.IO

The Nitrous app is essentially a window that hosts the <webview> control, which displays the remote environment that you're connected to.

Setting up a remote Nitrous box is pretty easy, and you have your choice of Node, Ruby, Python, and Go environments. The Web IDE is straightforward, includes collaboration options, and lets you upload source files to the remote box. There's also a command shell for executing commands and such. The docs are pretty extensive, too.

I recently tried out Nitrous on a small NodeJS/MongoDB project, and the experience was about as easy as it could be. I just provisioned the box, uploaded some source files, and was working away within minutes. The Web IDE even provides a "Preview" function that launches the app within the local browser with the URL already set up.

Between working on source files locally and having a cloud IDE to test and deploy in, I can easily see how a setup like this could become the future of development.

Testing and Debugging

One of the greatest things about developing on a Chromebook is that you have access to the best Web developer tools in the business - the Chrome DevTools, naturally. You would be amazed at the number of people who don't yet realize this.

Chrome DevTools

Whether you are working on Chrome Apps, Extensions, or regular Web sites, the Chrome DevTools give you unparalleled features for debugging, profiling, logging, etc. Now, I'm not going to go deep into the Chrome DevTools here because all the information that you need to use them effectively is at that link that I've provided above, but here are some of the features you might not know about that you should definitely investigate:


Postman

If you do any work that requires transferring data to and from RESTful Web services (and who doesn't these days?), then you'll find that Postman is a great utility for testing REST based APIs.

Postman comes in two flavors - the original V1 Packaged App, and the newer Chrome App. I prefer the latter, since it works offline and in its own window. It also comes with a great set of online docs.

Postman makes working with REST APIs easy

Postman has some features that make working with REST services a breeze:

  • You can define collections of requests, and group them together to reflect your API
  • Adding headers and query parameters is quick and easy
  • You can set up different environments (such as "Production" vs. "Development") and then customize the way that requests are sent using variables
  • There are helpers for setting up various authentication schemes, such as OAuth2
  • The app adds each request to its History, which makes it easy to experiment
  • It is easy to customize the app's settings, and there are a lot of ways to tailor Postman to your particular needs
If your work involves REST APIs, then I highly recommend you download Postman.

Dimensions

Dimensions is a legacy, or "V1", Chrome Packaged App, but it's still useful and runs offline so I included it here (and hopefully the developer is working on updating it to be a Chrome App). Dimensions essentially does one thing - it shows you how your UI will lay out at different screen sizes.

Using Dimensions to view various layout sizes

Essentially, you start up the app, point it at a URL, and then slide the grab-handle left and right to simulate different screen widths. Assuming you've written your HTML to use responsive layout techniques, the page will change at various widths so you can gauge what it will look like on various devices.

Dimensions include pre-defined layout sizes for iPhone, Android, and Tablet sizes, and you can rotate each device to display different widths.

By default, the app will load in a browser tab, even if you're offline (that's what v1 Packaged Apps do). I usually set Dimensions to open as a regular window (just right-click on the app icon and choose the appropriate setting), which gives it a more app-like feel.

Useful Utilities

Editing and debugging get all the attention, but there are always those small utilities that developers use to make their lives somewhat easier when it comes to the workflow and other parts of development. Two of the utilities that I've found really useful so far are GistBox and HexReader.

GistBox

I've started using Github more and more to store things like code snippets (or "Gists", in their terms) because it's really easy to access them from everywhere, and GistBox makes organizing and working with Gists simple.

You can edit your Gists directly in the app, create new ones, apply labels, search Gists, and even share them via email or Twitter.

Organizing Gists with GistBox

Unfortunately, since it relies on Github access, it doesn't currently work offline, but given its purpose and usage scenario, I haven't found a situation where that has mattered for me yet.

HexReader

This one is pretty straightforward, and will be familiar to anyone who's ever had to manipulate binary files. Want to make sure that the file you're working with really is a proper PNG? Need to extract some embedded data from a PDF file? HexReader has you covered.

HexReader in action

It supports large files, you can copy data as text or hex, and it has bookmarks too.

Yes, it's a bit of niche app, and not exactly for everyone, but for those people who need it, HexReader is one of those developer utilities that you're glad is there.

Summing It All Up

ChromeOS has a come a very long way in a short period of time, and the developer story has improved right along with it. I find that I can do pretty much all of my every-day development tasks right from my Pixel (or, thanks to Chrome Sync, any one of my Chromebooks) while getting all the usual benefits of ChromeOS: speed, simplicity, and security.

And this is just the beginning - more developer tools are on their way, and the built-in Chrome DevTools continue to improve at a rapid rate.

App Links

I've included all the links to the apps I mentioned in this post here in one handy list for those of you looking to try some of these out:


Do you have any tools that you like to use to develop on ChromeOS? Be sure to let me know in the comments.

Happy Coding!

Friday, February 24, 2012

Friday Roundup - News from Across the Chrome and HTML5 Ecosystem

Google launches new developers.google.com branding and redesigned site

"Our goal with the Google Developers site is to bring together all developer resources, programs, events, tools, and community into one place. Soon, all our information will be on this new Google Developers site, and Google Code will return to its roots as an open source project hosting service. As part of this project, today we’re introducing a new identity, complete with a new look, to unify all of our developer offerings. Our new logo says Google Developers, and that's intentional: it reflects our focus on you, not just the tools we provide."
Google Developers logo

Chrome Dev Tools get a CSS Color Picker

"Another 1,642 changes landed in the repositories last week, 958 for Chromium and 684 for WebKit. Highlights include a color picker for Web Inspector and early functionality for the calc() function. Brian Grinstead’s color picker is now enabled by default in WebKit nightlies, following some slight polishing. To aid the undo and redo system, an event has been added to monitor CSS modifications"

Apple Games Converge With Android’s by Using HTML 5 Code

"The goal of HTML 5, which is gradually making its way into all modern Internet browsers, including ones on mobile devices, is to make sites look and feel just like applications downloaded directly to a phone or desktop. Until recently, that was more of a promise than a reality. That’s changing in part because of the steamroller effect of Apple’s iPad and iPhone, which don’t run Flash content."

Getting Started with the HTML5 Track Element

"The track element provides a simple, standardized way to add subtitles, captions, screen reader descriptions and chapters to video and audio. Tracks can also be used for other kinds of timed metadata. The source data for each track element is a text file made up of a list of timed cues, and cues can include data in formats such as JSON or CSV. This is extremely powerful, enabling deep linking and media navigation via text search, for example, or DOM manipulation and other behaviour synchronised with media playback."

Why HTML5 makes justifying native applications more difficult

"One of the biggest shifts in development in the last few years has been the move to Web applications. For a long time, developers resisted this move, and some of the reasons why were good. For example, I said that for a long time the Web model wasn't so great--the UI capabilities weren't there without a ton of work, and the ability to do "real work" was lacking. Some of the reasons were not so good, and mostly boiled down to a refusal to learn something new. I have recently become very bullish on Web applications, and I now highly recommend that you consider them over desktop applications in all but a very few sets of circumstances."

Friday, February 17, 2012

Friday Roundup - News from Across the Chrome and HTML5 Ecosystem

Dartium - Tech Preview of Chrome with Integrated Dart
"...today we’re making Mac and Linux binaries available that integrate the Dart VM into Chromium
.
This technology preview allows you to run your Dart programs directly on the Dart VM in Chromium and avoid a separate compilation step. Over time, these programs will take advantage of the VM’s faster performance and lower startup latency."
Chrome Web Store Categories Updated
"The new structure of the store will improve discoverability for apps. For example, users searching for a photo album app can now easily drill down to the “Photos” subcategory level and track down the app they are looking for. At the same time, apps assigned to a subcategory show up in the category page as well giving them wider exposure; an app in "Photos" will appear on both the "Photos" page and the "Entertainment" page."
HTML5Rocks Updated with New Look, Web App Field Guide
"Yesterday, the Chrome Developer Relations team launched several new resources, including the Field Guide to Web Applications. It’s a new resource that is designed to help web developers create great web apps. We’ve heard loud and clear from users that they want more and better web apps, and we hope this new field guide will enable you to create those web apps."
Google Chrome will see greater expansion on mobile devices
"There are roughly 200 million Chrome users worldwide, and while Chrome is primarily a desktop experience as part of Google's dual strategy (Chrome and Android), it's starting to make its way on to mobile devices.Last week, Google released a beta version of Chrome for Android for mobile devices running Android 4.0 (Ice Cream Sandwich)."
Chrome Could Exceed 50% Market Share by End of 2012
"In December 2011, Chrome 15 became the most popular browser in the world, beating Internet Explorer 8, but if you combine all IE versions, Microsoft still holds the number 1 spot....If our prediction comes true, Chrome will by May 2012 be neck and neck with IE, and by June, it will have taken the lead. Note that this would be right on track with our prediction from last year."

Thursday, February 16, 2012

Google, Three Months In

February 14th, Valentine's Day, marked the three month point for me here at Google. I thought I would take a moment to share my observations and experiences now that I've been here a little while on what it's like to work here and what it is we're doing.

I joined Google to work on Chrome – the browser, the Chrome Web Store, the Chrome platform, ChromeOS / Chromebooks, etc. One of Google's core missions is to move the web forward, and Chrome is a very important part of that mission. Over the last three months, I've talked to dozens of partners about building and monetizing their Web applications for the Chrome Web Store, built a couple of apps and extensions myself (more on that in future posts), worked with exciting new HTML5 features that change the very nature of what you can do with a browser, and helped continue to plan and build out new ways of delivering rich experiences using Web technologies.

Here are some of the things I've noticed and learned along the way here at Google so far:

1. Chrome has become much more than a browser

Chrome has really come a very long way since I first started using it a few years ago. Not only has it become the world's second most used browser, but it's really redefined how I do my work at a fundamental level. During a typical work day, I rarely find myself having to go outside of Chrome to get my work done. I create, edit, and share documents and spreadsheets with co-workers, organize my daily to-do lists, conduct and manage research, videoconference and chat with colleagues and partners, listen and respond to voicemail, and much more – all from within Chrome. I don't even have a desk phone here at Google. Seriously. I just don't need one.

What has made all this possible is that Chrome, in all its forms – along with the Web itself – has become an extremely powerful platform. The underlying technologies like HTML5, the V8 engine, Native Client (NaCl), etc. have enabled apps that just a few years ago (heck, even a few months ago) weren't possible. You even write Chrome extensions and applications using the same HTML5 and JavaScript that you would use to create a site, and they just work across OSes. All you need to do is visit the Chrome Web Store to see what the result has been – there's been a veritable explosion of creativity in the kinds of things you can now use a browser for.

2. The short ship cycle has become a very virtuous one

I have to admit that a few years ago I was initially skeptical of the whole 6-week release cycle and auto-update policy that Chrome follows, but seeing it in action has erased all of my doubts.

The short development cycle enables new technologies to be introduced and integrated in a way that is predictable and usable for developers, starting with the Canary build, then the dev channel, then into the stable build. Developers can try these features out, get them integrated into their apps, and get those new features into the hands of users faster than ever before, thanks to the auto-update.

These apps can then use real-time analytics and performance measuring feedback to help developers fine-tune their code and find and fix errors faster than ever before, as well as deliver new features with a higher precision of knowledge of how they'll actually be used. This results in far more stable, consistent, and feature-rich applications for customers, and the cycle then repeats.

When I first started working as a software engineer 20 years ago (wow!) on shrink-wrapped packaged software, products and update patches were delivered on floppies directly to end users, who (hopefully) manually installed them. Some did, some didn't, so you never had a good idea how consistent your product codebase was out in the wild. It was also a huge bottleneck on getting updates out to customers – since shipping floppies (and later CDs) was expensive, you needed to gather as many updates as you could into a batch before sending them out to minimize costs.

Short ship cycles, along with auto-update and distribution over the Web, have largely eliminated these kinds of bottlenecks. The amount of time lapse between the introduction of new features into Chrome and when they get into users' hands has been greatly compressed.

3. Web developers are true developers in every sense of the word

I was one of the original Dreamweaver developers at Macromedia back in the 90s, and back in the early days of the Web I began to notice that the term “developers” got applied to people who used “real” languages like C, C++ and Java. Coders that used other languages, like JavaScript and VBScript were derisively referred to as “script kiddies” - in other words, people who made cute little animations  like image rollovers and did form validation logic, but not much else.

Fast forward to today, and I don't hear that term used much anymore. There are many reasons for this, but some of the big ones in my estimation are:

  1. The sheer scale of what is now possible in a modern Web application requires a lot of traditional engineering discipline knowledge and computer science theory,
  2. JavaScript itself has come a long way since its humble beginnings, and even though there are still some shortcomings, it has evolved into a very powerful language,
  3. Scripting languages have been embraced by industry titans like Google who have created some pretty impressive apps.
As a result, JavaScript developers are demanding many of the same tools and platform capabilities that more traditional developers have had for many years now. Chrome strives to provide these developers with the tools and platform they need to build the next and future generations of Web apps.



The last three months here at Google have been absolutely exhilarating – it's great to see the excitement around Chrome, Web apps, and the Web store. In the short time I've ben here so far, I've been amazed at the level of effort the Chrome team puts out to create a world-class browser and platform. I feel honored and privileged to be part of such a great team, and I'm really looking forward to helping Chrome move the web forward and redefining what's possible with Web applications.