I ordered the i7 16GB RAM 512GB SSD Pixelbook with the Black Friday deal that started on November 22nd.

Day 1

My Pixelbook arrived this afternoon. Within a few hours, I’ve already got my primary dev tooling installed and working! There were only a few minor bumps in the road, and they were quickly resolved with a quick Google search.

I’m curious how things will play out over the next week as I try to push it for productivity tasks.

I’ll also be monitoring the thermal performance since I don’t want to be working at some point in the future with burning finger tips. So far today, I felt some heat when I reached up above the keyboard and below the screen. However, when I checked Cog, the temps were actually not bad at all (160 F / 71 C or less).

With the machine mostly idle, 4–5 tabs open, while I wrap up this post, the CPU is barely over body temperature at 104–109 F.

The battery life is very impressive so far. I’ve been off of power most all day, and I’ve still got over 30% power remaining and almost 3 hours of estimated run time.

I’ll also be doing a good deal of testing with Bluetooth. I was able to use an LG Tone 700 headset for over an hour today without any disconnections or issues.

There has been one minor usability glitch that has bothered me a few times today. On about 5–10 different occasions, the machine seemed to lag or freeze up. Sometimes this was only affecting the scroll of the touch pad, or the responsiveness of the touch screen. Other times the entire UI was frozen and there was no way to interact with the device. This generally only lasted 1–20 seconds… until just about 5 minutes ago.

I wrote 99% of this post on the Pixelbook, but I’m finishing up the first draft here on my mid-2014 MacBook Pro. With 30% battery left and low heat (as seen above), I closed all of my Linux and Android apps. I also closed a few open tabs to get down to only 4 tabs open. Then while making minor edits to this post in the Medium web app, everything froze.

It never came back. After about 5 minutes, the machine rebooted itself to this:

I pressed the power button and tried to reboot it, but it just turned off. There were no connected devices. Nothing I did was able to wake it back up, even holding the power button for 30+ seconds, until I plugged it into power. It then booted up pretty quickly and still had 29% battery left.

That was… a little scary. When I first unboxed the device, I had a similar experience. I couldn’t get the power button to do anything. Only when I connected my Pixel XL via USB-C did it power on and start responding.

Day 2

I found out that the Chrome OS missing or damaged screen isn’t new and isn’t that uncommon.

I didn’t have a lot of time today for development tasks, but I did get a good deal of web browsing, and a little Android gaming done. I found that using the device on the lap in either tablet or laptop mode did not generate enough heat to bother me. This was after about an hour of web browsing and some Star Wars Galaxy of Heroes.

On the gaming side, I’m still getting a feel for the touch screen as there are quite a few occasions where I don’t touch it with enough force to register and need to tap again. Gaming performance-wise, I’m seeing a significant improvement over my Nexus 9, but I feel like my Pixel XL may outperform the Pixelbook in the GPU category.

I was able to get the Google Cloud SDK (gcloud) installed using their instructions for Debian.

I was able to get IntelliJ IDEA installed and running with almost the same instructions that I used for WebStorm. I ran into an issue with the Google Cloud Tools plugin and opened a bug.

I was also able to get Android Studio installed and running. I am generally able to install the SDKs and libraries and get my Gradle builds to succeed. However, there are a number of other minor issues like not being able to sign in to Google due to the callback going over a port that isn’t forwarded to Crostini and resolution of secondary SSH keys when using Git. Android Studio suggested that I install libsecret-1-0 and gnome-keyring so that it could preserve access to my keys, but it doesn’t appear to be working.

I’m also seeing an issue where I need to re-authenticate with GitHub either after rebooting or re-launching of WebStorm. It says “missing access token” as if the previous token has been lost. I’m seeing similar issues using a secondary SSH key in WebStorm as well.

I’m getting the feeling Crostini and Chrome OS are on the edge of being a real development platform. However, the concern that Crostini (beta) may have too many productivity-draining issues with edge cases is getting more real.

Day 3

I spent many more hours trying to get a second SSH key to work in IntelliJ IDEA and WebStorm. I tried both the Built-In and Native SSH, but had no luck. Then I learned about, and setup, a ssh-agent service with systemctl. Additionally, I tried keychain and gnome-keyringsome more. Even though everything appeared to be set up properly and worked from the Terminal, it would never work from the IDE.

I finally just gave up and decided to use the key for associated with my BitBucket account for accessing both GitHub and BitBucket. I was able to add that email address to my GitHub account. I’ll have to wait and see if this causes me problems with some PR review bots, commit verification, or CLA checks in GitHub.

I found out today the issue I reported about the Google Cloud Tools plugin for IntelliJ IDEA wasn’t specific to Chrome OS. It was just an issue that they hadn’t added support for the latest version of IntelliJ (2018.3). They released that fix today, and it resolved the issue.

I did however run into another problem with that plugin. It uses a strategy where it logs you in via OAuth redirects. However, when it tries to send the confirmation back to the IDE, the browser shows a Not Found page. This is because they use a random high level port (40–60K) each time, and those ports are not forwarded between Crostini and Chrome OS. Only some well-known ports are forwarded. For now, being logged into the Google Cloud Tools plugin is not critical for my work, so I am going to ignore this issue.

That said, Firebase is critical for my work, and they use a similar model for authenticating with their firebase-tools CLI. I’ll have to give that a shot soon to see if it will be a problem.

Another important activity that I did today was hosting a two-hour Hangouts Meet video call. I did the whole call connected to my LG HBS 700 Bluetooth headset without any issues. I did some screen sharing and navigated through a few tabs while on the call. Everything was smooth for about 99% of the call. I didn’t notice any excess heat being generated and the keyboard and palm rests were still comfortable to use.

The other person on the call was also using a Pixelbook. While the video quality on both sides was acceptable, I wasn’t really impressed. The Pixelbook has a 720p 60 FPS webcam which should be similar in quality to my MacBook Pro mid-2014’s 720p webcam. However, in this small sample, I felt that it wasn’t really up to par with my MacBook Pro. There was a bit of graininess and as it got dark, the low light performance didn’t seem to be very good.

Note that this is just anecdotal evidence based on a general feel and not head-to-head comparison.

I also have some feedback on the keyboard, palm rests, and track pad. In general, the keys have a really nice feel and are a pleasure to press. I do still get a little disoriented at times and end up pressing keys 1 column to the right, but I don’t see that being a long term issue.

I VERY frequently press the Assistant key when I do not desire to speak with the Assistant. I really wish that it was up near the function keys, perhaps replacing the hamburger/settings key. However, I haven’t taken the step to disable it yet, but it’s certainly under consideration.

The palm rests are excellent! They are very comfortable and keep quite cool! Similarly, the track pad is really a pleasure to use! Sometimes Chrome OS doesn’t scroll quite as smoothly or responsively as I would like, but that isn’t an issue with the track pad itself.

I did some interesting reading today over at the Crostini Wiki and Simos Xenitellis’ Blog. The wiki has some great resources and guides for installing and configuring different tools. The blog post covers some internals of how Crostini is built.

Oh! Finally, I learned how to insert emojis 🌟! This is also helpful for adding in some special characters like jalepeño. Unfortunately, the emoji picker doesn’t have text search (like macOS or Slack) 😞 and there are no tooltips on hover to help you differentiate similar emojis. Additionally, there appears to be a bug where I’m not able to use the trackpad to scroll through all the emojis (the touch screen does allow you to do this though).

Day 4

While I have not run into Bluetooth issues with my Pixelbook, there are a lot of other reports out there. It looks like a firmware fix from Intel will help mitigate some of these issues in Chrome 71 (beta). Stay up to date by starring this bug.

I’m finally running into random Bluetooth disconnections. I had 3 of these today in about 30 minutes of SWGOH with my LG HBS 700 connected. One note on the positive side, this is certainly the best sound I’ve ever had on SWGOH. On some Android devices (like the Nexus 9), I can sometimes get poor, crackling audio. On the Pixelbook, it was so crisp and deep! I heard sounds that I had never been able to discern before!

It looks like there is some bad news for Pixelbook Bluetooth users in the above bug. Today, the Chromium team responded that while things have been improved with the firmware update in Chrome 71, there is still an underlying hardware issue that won’t be able to be resolved in existing hardware (Pixelbooks included).

If you need a device with solid Bluetooth performance, it doesn’t look like the Pixelbook will work out for you. The bug mentions that the Pixel Slate and ‘Nami’ devices, including the Acer Chromebook 13 and Spin 13, should have the hardware capability to have Bluetooth that auto-recovers (without a reboot) when it has issues.

I spent a couple of hours coding while streaming Google Play Music over Bluetooth via the web (not the Android app). I wanted to try this to see if my earlier disconnects were related to actively using an Android app. It wasn’t related. I had about 6 more disconnects (with no auto reconnection) over this time. Again, the sound seemed very clear, but the disconnections make it problematic to use the Pixelbook with any Bluetooth accessories 😞

Day 5 — Beta Channel

Today I decided that it was time to try the Beta Channel of Chrome OS. The main reason was to try out the Intel firmware update for the Bluetooth/Wi-Fi chip. It took about 15 minutes to download, install the updates, and reboot.

This evening I streamed music while coding for about 5 hours with numerous breaks, disconnections due to going out of range, turning my headset on/off, etc. I also got in about 30 minutes of SWGOH with BT. Thankfully, I can report that I did not have a single bogus disconnection, and the system’s BT did not disable itself.

I didn’t do any coding or fiddling with configuration today. I needed to get my productivity up, so I stuck with my MacBook Pro for dev today.

Day 6

I was busy working on my MacBook Pro for most of the day, but I streamed Google Play music for at least 3–4 hours on BT without any disconnections or issues.

I also ordered a set of USB-C to HDMI adapters so that I could do some testing with dual external monitors. I didn’t want to spend the money on a whole USB-C Hub with video out yet.

Day 7

I hooked up the following today

• Uni USB-C to HDMI adapter to AOC 27" monitor

• Anker 10 port USB-A 3.0 Hub

• Logitech K800 Wireless Keyboard

• Logitech M570 Trackball

• Western Digital 1 TB My Book for Mac

In this configuration, I was only using one of two monitors, but this allowed me to have WebStorm running side by side: macOS vs. Chrome OS.

I messed with the scaling in the Chrome OS display settings a bit. However, with this configuration, anything but 100% scaling resulted in blurry text in WebStorm. I needed to bump my font size in WebStorm up from 9 to 12 (same as in macOS). I had previously lowered it for the Pixelbook display. Later when I opened WebStorm settings, it appears that the font size was auto converted to 28.

I also had to tweak the font since the Menlo font that I use on macOS isn’t available on Chrome OS. I settled with Fira Code Medium.

With the scaling and font sizes sorted out and both displays of WebStorm (macOs, Chrome OS) looking similar, here’s what I noted

• The text in the Project panel (where your files and directories are) has a real nice contrast in macOS, but it’s smaller and dull in Chrome OS.

• Many parts of WebStorm on Chrome OS are smaller and need to be scaled up to match the size on macOS. Unfortunately, I can’t do that due to the blurring.

• Fonts and UI elements are significantly sharper on macOS. This actually used to be a weakness when running any IntelliJ product on macOS compared to Windows. However, JetBrains solved this issue a couple of years ago. It looks like some kind of similar fix is needed for Chrome OS’ Freon graphics stack.

After this, I decided that I needed to get two external monitors set up. However, this meant losing my external mouse and keyboard since I don’t have a USB-C Hub. The good news is that the Pixelbook’s keyboard and trackpad are excellent, so I’m using them in that configuration to write up this post. Of course this also means that I can’t charge in this configuration due to only having 2 USB-C ports. For any longer term use, you would certainly want a USB-C Hub to solve that.

So configuration #2 consisted of the following

• Uni USB-C to HDMI adapter to AOC 27" monitor

• Uni USB-C to HDMI adapter to AOC 27" monitor

I had to plug in the 2nd monitor twice as the first time it wasn’t recognized by Chrome OS. The second time it worked fine and was available in the Display settings. I was able to set up the monitor positioning (each 27" on one side of the PB’s internal display. This was quite a nice experience.

The first thing I tried was to move an open Chrome window from my PB’s internal display to one of the external monitors. This crashed Chrome OS and I lost my WebStorm instance which was hosting an Angular CLI project and Firebase Functions.

I was able to open the Chrome window again and move the tab back to the external display. I have read online this is a common issue with Chrome OS. However, I haven’t yet tracked down the related bug on https://crbug.com.

The other issue that I ran into here, which I don’t think is restricted to external monitors, is that Linux apps which are running in fully expanded windows don’t have their position remembered when they restarted. This means that I have to use an extra click every time that I open an app to make it take up the full screen.

These are software bugs which should be fixed. I’m not sure if the blurry scaling and lack of sharpness in WebStorm is 100% a software problem, but it certainly needs to be addressed by either the Chrome team or JetBrains. For now, these issues make the whole external monitor experience on Chrome OS sub-par. It’s certainly workable but, much like tablet mode, there seems to be quite a lot of space for improvement.

Some additional positive notes:

Letting the Pixelbook go to sleep connected to external monitors worked well. I was able to wake it using a variety of options including an external mouse, external keyboard, and the Pixelbook’s trackpad and keyboard. All the window positions and states were intact.

Issue with moving Android apps between monitors - Solved

When I open certain Android apps, like SWGOH, the app appears to open in the first monitor. This happens even if you launched the app from the launcher on another display. In my case, it opens in the left external monitor. However, I want it to open on the Pixelbook’s internal display so that I can use the touch screen. There doesn’t appear to be a way to move a full screen app like this from one display to another. It’s impossible to take the app out of full screen mode either via the mouse cursor, or the full screen button on the Pixelbook. There are some articles about shortcuts for moving windows across displays, but they reference the out of date Launcher+Alt+Arrow shortcut.

The shortcuts for snapping windows to the left/right half of the screen with alt+[ or alt+] work for me, but that’s not what I want to do here, and they don’t work with full screen Android apps like this.

Finally, I decided to open the Chrome OS shortcut search panel via Launcher+Alt+/. Then searching for “move” immediately showed me the proper shortcut: Launcher+Alt+m. This works!

Like a number of functions in Chrome OS, a keyboard shortcut is the only way to access the functionality, and the discoverability of this functionality is poor.

More notes on the general developer experience

I mentioned in a day 3 that the Google Cloud Tools plugin login didn’t work due to the redirect not being mapped between Crostini and Chrome OS. This wasn’t the case for logging in from the Firebase CLI via firebase login. Everything worked smoothly there. I also tried the Google Cloud SDK via the gcloud auth login command and that worked well.

On the Pixelbook, I always saw an accumulation of the same error in my browser console when I have a site open in live reload (dev) mode:

Unchecked runtime.lastError: The message port closed before a response was received.

I’m not sure what is causing this or how to solve it. However, it does not appear to be causing a significant issue.

I did some performance tests with Angular CLI v7.1.0. Eventually, I decided to test against a brand new ng new project. I used the existing project only for build times, but not reload times as they were too funky due to the project using a number of different libraries. For comparison, I included some numbers from my primary dev machine: a mid-2014 i7 16GB RAM 256GB SSD MacBook Pro.

Pixelbook Performance in a new project

Time to run ng serve: ~16s

Time to refresh the browser on a page served via ng serve: ~1s

Round trip for making a change and seeing it live in the browser: ~2–3s

Production build time: ~33s

Pixelbook Performance in an existing project

I had to throw out the browser refresh and round trip times here due to an issue with this project that caused both platforms to run much slower than they should.

What about that production and dev build times though?

Production build: ~3 minutes

Dev Build: ~29s

For the production build, looking at the CPU cores in Cog, a few of the longer running tasks like the TerserPlugin have significant portions that run on a single CPU. When this happened, the other CPUs were hanging around 5–25% while one CPU was around 90–100%.

This was done on battery power and none of these tests really drove up the thermals in any significant way. Everything continued to run around 105–140F.

Building significant AngularJS project

I also tried and AngularJS project that just uses Gulp and gulp-connect. In this case the build took ~22s and live reload did not work at all. On the MacBook Pro, this project builds in ~17s. This app also had the same console errors.

By default, the app used http://localhost:35729/livereload.js?snipver=1 for live reload. I was able to get gulp-connect livereload working using the following config:

livereload: { hostname: ‘penguin.linux.test’ },

This did not fix the console errors, but it fixed live reload.

MacBook Pro Performance in a new project

I wanted to provide some comparable times for the above data points in the same project on my 2014 MacBook Pro. These are numbers that I’m mostly fine with and would like to see equaled or improved upon by a new laptop.

Time to run ng serve: ~10s

Time to refresh the browser on a page served via ng serve: ~1.5s

Round trip for making a change and seeing it live in the browser: ~2–3s

Production build time: ~26s

MacBook Pro Performance in an existing project

Production build: ~2m 19s

Dev Build: ~26s

Android App Launch Performance

On Android, one of the slowest tasks that I do with apps is opening up SWGOH.

Here’s the data:

• Nexus 9: ~70s
• Pixel XL: ~34s
• Pixel 3: ~21s
• Pixelbook: ~15s

Performance Summary

The Pixelbook was 10–40% slower for CPU intensive tasks like running builds. I was surprised that it refreshed pages in dev mode approximately 0.2–0.4s faster than the MacBook Pro. This may be explained by the fact that the Pixelbook is running Chrome 71 while the MacBook Pro is running Chrome 70. Or the Pixelbook is just slightly better tuned for running Chrome?

These results aren’t overly surprising. The Pixelbook is running a newer generation i7 processor, but it’s also tuned for mobility and thermal performance in a laptop w/o fans. The Pixelbook is also half of the price of this mid-2014 MacBook Pro.

Overall, performance-wise the i7 Pixelbook packs enough punch to do web, backend, and Android development, but it won’t blow you away with speed.

Day 8 - Powerwash

One of my goals when picking up the Pixelbook i7 16GB RAM 512 SSD was to see if it could serve as an effective backup development machine.

This is due to the fact that my mid-2014 MacBook Pro i7 16GB 256GB SSD w/ Intel graphics is well outside of it’s extended Apple Care warranty. The MacBook Pro still works great and does most everything that I need. I’ve found that the 256 GB SSD is a little too small for me, and I’ve run into cases where I wish that I had more graphics power. That said, it has proven to be an incredibly reliable, performant, and productive tool over the last 4.5 years. It was clearly one of my best tech purchases, ever.

My testing in the last week has proven that the Pixelbook can indeed fill in as an emergency backup development machine.

That said, there are still enough rough edges in Chrome OS and Crostini (beta) that getting things set up properly and keeping things running over time will be too large of a drain on my productivity. This is obviously a personal decision. If you don’t have kids and find that you have a lot of spare time in your life, then you may make the opposite choice here.

Another aspect of this decision also relates to productivity. That is the speed and smoothness with which I would be able to make the transition from a temporarily or permanently disabled primary development machine (my MacBook Pro). While I use almost no macOS-specific apps, preferring mostly Linux-based apps, it is still not a simple transition for me to switch my dev environment from macOS to Linux. There are a number of contributing factors here:

1. My MacBook Pro time machine backups are on a USB-A 3.x drive that my Chromebook cannot read due to the Mac OS Extended Volume Hard Drive Format (HFS+).

2. The Pixelbook does not support Thunderbolt 2 or Thunderbolt 3. So peripherals for my MacBook Pro need extra adapters and if I upgrade to a new MacBook Pro there will be peripherals that may not work with the Pixelbook. This problem is especially painful when it comes to $300+ docking stations to support dual external monitors.

3. There are minor differences between the two systems which would cost me a good deal of time to mitigate. These include font and resolution settings in IDEs, differences in window management behaviors and shortcuts, differences in keyboard layouts, etc.

I’ve seen some reviews out there about Chrome OS and the Pixel Slate. They mention the idea of a thousand little cuts. Each one may have a work around or mitigation, but taken on a whole there are enough of them that the total impact is significant.

Thankfully, most of these issues are on the software side and will be improved or resolved over time! I feel strongly that Chrome OS has a strong future in most all markets (even development).

The Pixelbook is an amazing device for so many people today. It’s going to keep improving over time, especially since it will get updates for 7 years after its launch date instead of 5 like many other Chromebooks.

Now the Pixelbook hardware

Most of it is amazing. The keyboard and trackpad are superstars. The overall feel is very solid and premium. I was happy with the thermal performance and quiet fan-free usage.

The hinge worked great for me in most all cases. It has a little more movement than I’d like when touched in non-tablet and tent modes. Plus you need to hold down the keyboard when opening the screen. This is a hard problem. In one case I want the hinge to be more stable and in another I want it to open more easily.

I have very positive and negative opinions on the Pixelbook’s screen. The bezels are indeed enormous, but it’s not a deal breaker for me. I much prefer the 3:2 aspect ratio over the wide screens seen on many of laptops (Dell, etc.). This gives more vertical space for productivity tasks like reading, writing, or coding. The screen is impressively thin. The webcam worked well enough, but did not impress me.

The Pixelbook has 235 pixels per inch, and my MacBook Pro has 220 pixels per inch. The Pixelbook’s display has 400 nits of brightness which makes it usable outdoors. My MacBook Pro only has 320 nits of brightness, and it doesn’t excel outdoors. That said, new MacBook Pros have 500 nits of brightness.

On paper, the Pixelbook’s screen is very solid. However, in practice I found that changing resolution or scaling display output resulted in blurry or pixelated images and text. This was likely due to Chrome OS’ Freon graphics stack, Linux apps being in beta, and Android apps not being fully tuned to Chrome OS yet. This resulted in a display experience that I wasn’t completely satisfied with.

Stone Peak 2 by Intel

The Intel Bluetooth/Wi-Fi combo chip is the primary reason that I am returning the Pixelbook. I had many occurrences in Chrome OS 70 (Stable) of Bluetooth disconnecting and not auto reconnecting on me.

This device has been on the market for a year now. Lately, I’ve been waiting to buy a number of tech products until they have been in the market for a few months. This gives me the chance to see which products have serious flaws and which have flaws that can be addressed via software updates. This strategy has saved me a lot of wasted time, frustration, and money in the last 4 years.

That said, the Pixelbook still having serious feature-breaking problems in the Stable channel after a year is too much for me to ignore. Yes, I had better luck with Chrome 71 (Beta), but there are numerous users who are still reporting Bluetooth issues with that build. I don’t have the luxury of waiting to see since the return period is only 15 days. Plus I’ve already spent as much time testing this device as I can afford.

Additionally, comments in the various Bluetooth bugs in the Chrome OS issue tracker seem to indicate that there is a hardware flaw or missing feature with the Pixelbook’s Intel Stone Peak 2 Bluetooth/Wi-Fi chip. There is some additional discussion of this issue on Reddit.

Final Decision

It doesn’t seem wise for me to spend $1,700+ on a device that has an issue like this that may never be fully fixed. Bluetooth is something that I make heavy use of, so issues with this chip could seriously impact productivity.

That combined with the many little cuts to productivity, mentioned above, resulted in me making the decision to return the Pixelbook.

Next Steps

If I can pick up the cheaper model on a big discount, then I would love to have a Pixelbook, but I can’t justify keeping the top end model.

I will certainly continue to keep my eye on high-end Chromebooks which can be used for development. I’m excited by the progress and goals of Crostini. Additionally, I’m also confident Android apps on Chrome OS will continue to improve each year. I do plan to make a Chromebook my primary development machine at some time in the future.

Until then, I am planning to stick with MacBook Pro devices for my primary development platform. I’m very happy I’m able to test my web apps on Android, macOS, iOS, Windows, and Chrome OS using a MacBook Pro. You can find out more about running Chrome OS in a VM on a MacBook Pro in this Twitter thread.

If you haven’t checked it out yet, DevFest Florida is happening at Disney World’s Contemporary Resort on January 19th. The list of speakers is really impressive. Tickets for students and professors are only $99 (plus fees) and general tickets are $175 (plus fees).

If you are interested, I am happy to offer readers 25% off of general ticket prices using this link! I hope to see some of you there.