I first became interested in Google’s Chromebook initiative by way of a long-held affinity for low-end computing, and ARM-based devices in particular.

What really sold me on the utility of these cheap, cheery machines was the emphasis on a small, key set of features:

Low time-to-web with minimal setup. Automatic, frequent updates. Encrypted transparently by default. The web and only the web.

These days my on-the-go work involves getting small bits and pieces wrapped up on my commute. My near-instant-on ASUS Chromebook Flip is perfect for this, and the operating system gets out of my way in seconds.

Having used these devices now as daily drivers for a few years, I thought it would be useful to give my own take on the various options available for coding on these devices for anyone considering buying one with that use case in mind. In addition to this, I have an interest in making the Chromebook more coding-friendly as a platform, so it’s my hope that this will help with that goal too.

Caret

The most straight-forward option I’ve found in terms of coding on one of these devices is simply to install Caret from the Chrome Web Store.

Caret is a user-friendly text editor with the common features you’d expect such as syntax highlighting for common languages and document formatting.

I’ve found that I can get pretty good mileage out of just Caret and Google’s Secure Shell extension, and it’s obviously very quick to get rolling with.

Benefits

Developer mode is not required for Caret, which is quite a large positive point as it means the user-space encryption and boot sector protection stays intact on the device.

It’s also simple to install, and it’ll update automatically by virtue of being a Chrome application.

Drawbacks

Caret falls short for my workflow in a couple of areas.

It’s not nearly as polished as better known editors available for other platforms such as Sublime Text or Visual Studio Code. This is more than forgiveable when you consider that Caret is the work of a single developer (Thomas Wilburn, presumably only in his free time), and achieves a lot considering it runs within the confines of the web sandbox. It’s also updated quite frequently with bug-fixes and new features.

One other final drawback for me is not really the fault of Caret at all; the Chromebook file-system mounts only the download folder for local access in the file browser, making dealing with the file structure directly in Chrome OS quite painful when you’re used to having unencumbered access to your files.

Switching from Chrome OS to Linux

Admittedly, my first thought was that one of these devices would be an excellent candidate for formatting and installing a stripped down Linux distribution. A cheap, fanless laptop with exceptional battery life, albeit with fairly meager performance. It works quite well, and later Chromebooks have stepped up in the performance stakes impressively.

Linux on a Chromebook is quite an interesting proposition to me as it fills a niche I feel is fairly underserved — a POSIX-based ultraportable that skips the premium bells-and-whistles of the Macbook. It also does so in many cases for about one tenth of the price, which is quite exciting.

Benefits

A full Linux operating system, with no compromises required in terms of software installation or other user-space restrictions outside of a potentially condensed list of supported packages in the case of ARM devices (although ARM support in major distributions is strong these days, and is improving all the time).

Quite a few of the most popular distributions have official and third-party ARM ports, with strong community support (including Ubuntu, Fedora and ArchLinux).

Drawbacks

The most obvious drawback to this option is that you lose Chrome OS. To us dyed-in-the-wool hacker types this might not seem like such a loss, and in some ways that may be true, but it sells short just how good of a job Google has done at optimizing Chrome OS for lightweight work. It’s also worth not discounting that Google has an obligation for driver support throughout the service lifetime of the device.

The other primary drawback is that you lose Verified Boot. This is nothing new to the Linux world and has been discussed for years with regards to Windows and TPM, but it’s worth calling out here as a security consideration.

Crouton

Crouton is quite a creative way to utilize the developer shell on Chromebooks to provide a Debian chroot that can launch Linux apps on Chrome OS effectively side-by-side. It does this by broadcasting a framebuffer into a new window or tab, so that the user is interacting with the X11 application as if it were a Chrome window.

NOTE: Crouton is also what my Visual Studio Code for Chromebook builds and scripts are using under-the-covers to create the side-by-side scenario you see there, as I believe it currently offers the best trade-off for flexibility, compatibility and performance.

Benefits

As Crouton works by running a chroot inside Chrome OS, the kernel and drivers used are those maintained by Google, so you don’t need to surrender official support in order to be able to use Linux applications on the device.

In addition, with Crouton running Linux applications side-by-side with whatever you happen to be doing in Chrome OS, you have the benefit of not maintaining two seperate desktop environments or restarting the device to jump between the two.

Drawbacks

The biggest drawback with Crouton is that (as in the case of the switching to Linux option described above) you’ll still need to put the Chromebook into developer mode, with the compromises that come with it. In the case of Crouton, you’ll also be forced to endure the Chrome OS “Nuke Screen”, a warning screen that appears on boot each time, which actively prompts the user to press a key that will factory reset the device.

The Chrome OS “Nuke Screen”. Pressing SPACE will reset the device. Seriously.

The other drawback, which I find in practice to be less of an issue, but one worth mentioning nonetheless, is that there is some graphics lag introduced when broadcasting the virtual framebuffer to a browser window. This has never really bothered me, as in the use cases we’re discussing here (editing code), the lag is barely noticeable at all. If you intend to use Linux for more than editing text though (i.e. video and/or games) you may find this to be more of a problem.

Remotely connect to a free Google VM

This is a relatively new possibility that is owed to Google, Microsoft and Amazon’s ongoing cloud computing price war.

Under the new pricing tiers for Google Compute Engine, you can now run a dedicated f1-micro instance in the cloud on Google’s infrastructure, free of charge. When coupled with the Chromebook’s remote desktop support, this opens the interesting possibility of having a dev-box-in-the-cloud for which the Chromebook is one of a number of thin clients.

Benefits

There’s quite a lot to consider here. This option will not require developer mode, keeping the security policies in place on the device. It also means we don’t have to worry about that awful Nuke Screen.

Furthermore, we won’t need to install anything on the Chromebook beyond the Chrome Remote Desktop extension, so the impact on filesystem space will be minimal.

Lastly, it’s worth not discounting the capability of connecting to a cloud VM from other computers. If your battery dies while on the road or the device bites the dust, you’ll not automatically lose your work. You’ll also have the option of borrowing/using another device to get back to work quickly from where you left off.

Drawbacks

The trade-off to consider with this option is that the long-standing myth that Chromebooks require constant connectivity will actually be true in your case. If your connection to Google goes down at any time, you’ll be prevented from working until it’s back up again.

It’s also worth noting that if you plan to do a lot of development on-the-go, a remote desktop session over a cellular connection could be quite costly depending on your provider plan and where you are in the world.