Chrome OS: Ready for Web Development (Chrome Dev Summit 2018)

[MUSIC PLAYING] DAN DASCALESCU: I’m here with Stephen Barber who’s an engineer on Chrome OS So good evening, everyone I’m Dan Dascalescu I’m a developer advocate at Google, and tonight, we’d like to talk to you about why Chrome OS is an awesome choice as a web developer platform And there are two main reasons for why you should develop on Chrome OS The first is that Chrome OS is an unprecedented convergence of technology stacks It brings together web applications because it’s an OS that has a browser as its UI, but it can also run Android apps, and with full Google Play support, you can install Android browsers that you can test your web apps on And starting with Chrome 69, you can install Linux and you can run your familiar development to a workflow there And this is a sneak preview of what’s coming in the talk You can see here a terminal, an ID, a couple of browsers, and, of course, a PWA So the second reason why you should develop on Chrome OS and target Chrome OS is that it powers a very wide variety of devices You might have seen Chrome OS laptops or Chromebooks from a variety of manufacturers, and also, you might have seen some convertibles, again, from various manufacturers, and those all-in-ones, like the LG Chromebase And the small form factor PCs– this is the Chromebox, which was built by Samsung– 2012 And then HP, Asus, and other manufacturers followed suit And this is the mini form factor PC It weighs 3 ounces You plug it into the HDMI port of a display, and it turns that one into a computer You can attach a mouse or a keyboard via USB or Bluetooth And then there are mega displays This is the Chromebox Commercial It powers digital signage or kiosk displays And this summer, we saw the first tablet powered by Chrome OS This is the Acer Chrome Tab 10 And of course, Google has our own lineage of devices This is the Pixelbook, the flagship device, which is at 75% off for you guys Yeah And our latest offering, the Pixel Slate, which was announced last month So in one slide, why target Chrome OS? Because of a large and increasing market share, you probably heard that we have a very extensive presence in the EDU space Chromebooks are very popular there Then if you optimize for Chrome OS, you’ll actually target a variety of these convertible form factors– devices that have or have not got a keyboard or a mouse or a stylus or even a touch screen So this could also future proof you from devices that haven’t been invented yet Though after I put this slide together, Samsung actually released a foldable screen phone that becomes a tablet So the future is here already So again, in one slide, the reason is diversity You can develop apps on Linux and test them on a variety of Android and Linux browsers So Chrome OS brings together your own development workflow– the one you’re familiar with– your own development tools, a variety of form factors, from mobile to tablet to convertible to desktop, and browsers on Android and Linux And there are quite a few of them– Edge and Samsung Internet work on the Pixel Slate The others should be able to be installed on Google Pixel, as well And this is Edge and UC browser and Firefox running on the same Chrome OS machine Then you can install some desktop browsers, so you can test, in full desktop, Firefox, if you install the Linux version of it This is Firefox and this is Epiphany, a.k.a GNOME Web And you can also install Docker, which, I’ve heard, many of you are interested during the forum This is unofficial support for it, but there is a thread on Reddit if you search for Docker now working in the [INAUDIBLE] sub-reddit You’ll find this thread Try at your own risk, but it does work So how does it work? How does Chrome OS manage to stick to its principles, which are speed, simplicity, and security? How can it run all these different web apps and Android apps from Play and Linux apps like GIMP while staying fast, simple, and secure? This boils down to the containers architecture, which I’ll let Steve tell you more about STEPHEN BARBER: Thanks, Dan So when we were bringing Linux apps to Chrome OS, it was really important that we maintain all of the things that make Chrome OS Chrome OS So simplicity was first It shouldn’t feel like you’re running a separate OS, but instead, have the Linux terminal and GUI app

seamlessly blend in with Chrome and Android apps And we’ve managed to do this while keeping things fast So Android and Linux support don’t do any emulation By using lightweight containers and hardware virtualization support, your code will run natively And of course, security is always on the mind for Chrome OS So Crostini uses both virtualization and containers to provide security in depth So to expand a bit on security, we’re starting from a secure foundation and we’re working our way up with features from there So right now, Linux is pretty isolated from the rest of Chrome OS, but we’re working on the ability to share files and folders with it, and soon, we’ll be adding support for Google Drive, as well So you’ll be able to keep all of your dot files, projects, and other important work safe in the cloud So let’s take a look under the hood real quick The first time you launch a Linux app after logging in, it will start up a lightweight VM and container So this VM is actually providing the outer security boundary and gives you a real Linux kernel And it’s actually a minimal version of Chrome OS that was designed specifically to run containers And the container inside is where you do all of your work This container is very tightly integrated with the rest of Chrome OS So things like launcher icons and graphical apps work just like any other Chrome OS or Android app And the most important thing, of course, is that you get a terminal So how does it actually feel? What’s it like? And the answer should be, like most other Linux systems So Crostini is based right now on Debian stable because a lot of developers are familiar with apped package management and Debian-based systems And for now, we’re starting out targeting web developers because Chrome OS is a web-based OS, and we think it’s appropriate that you should be able to develop web apps on a web-based OS So to do this, we provide some nice integration features Right now, we’ll do port forwarding It doesn’t seem like you’re running a container You get local hosts to connect to, and that’s treated as a secure origin, just like it should be But if you do want to treat your container like a separate system, you can And we provide a penguin.linux.test DNS alias And we do want to support more developer workflows than just the web So we will be adding USB, GPU, audio support, file systems and user space, and better file sharing in upcoming releases And now, Dan will talk a bit more about using Chromebooks for web development and show us what Crostini looks like in action DAN DASCALESCU: Thank you, Steve So we know how it works We know why it’s awesome Let’s see how to actually use it for developing web apps The goal is to let developers do everything they need locally, and the Crostini support is still in development, but most things work as expected You can run editors, IDs, databases like Mongo or MySQL, local servers, and pretty much anything you can install with apt To setup Crostini, search for Linux in Settings, and then you’ll see this dialogue Once you tap Install, in about a minute or two, depending on your network speed, you’ll have Linux installed on your Chromebook And this is a terminal So we have a terminal Woo-hoo Let’s build a desktop web app for Pixelbooks, right? A bit about how these apps are usually built A lot of development of desktop dev apps is done with Electron or Node-Webkit But the problem with that is Electron means Chromium plus Node So you ship a rendering stack along with your app And that might be useful if you have needs for low level access, but consider Carlo, which is a Google project that is essentially a helpful Node app framework It provides applications with Chrome rendering capabilities So with Carlo, you don’t have to ship Chromium or any rendering engine with your app It uses a locally detected instance of Chrome and it connects to your process pipe, and then exposes the high level API for you to render in Chrome from your Node script But if you don’t need all these low level OS features, you can do something even simpler, which is to build a progressive web app This is what Spotify has done You can see here that I’m going to open the Spotify [INAUDIBLE] tab and click that Install App button And once I accept the install prompt, the tab becomes a PWA without a URL bar, and it has its own buttons, like Close And you can find it in the shelf You can launch it from there And once you launch it, there is no more Install App button because it’s an installed progressive web app And it’s also accessible from the shelf

So these system level integration features are provided by Chrome, and they are available on Chrome OS since Chrome 67, which is ancient by now And on Linux, on Windows, starting with Chrome 70, the current version stable And on Mac with Chrome 72, or if you want to give it a sneak peak, check the Enable Desktop PWAs flag This is thanks to service worker support, which has been implemented by all major browsers, and they are also working on advanced features, such as [INAUDIBLE] request Firefox is working on that It has special [INAUDIBLE] and at the home screen now And Safari is also working on authentication APIs So OK We’ve talked a lot Let’s try and do a demo and see if anything blows up So I’ve set up Crostini already because that will take two minutes, which I don’t want to waste We’re going to install Node, which I have already– VS Code NPM And then we’ll check our Squoosh You might have seen it in one of the earlier talks It’s an image compression app We’ll open that in VS Code to check out the code around the web server, and the most interesting part is we’re going to open Squoosh from an Android browser on the very same device And if things work, we’re also going to do some remote debugging So these are the instructions to install Node I’ve already run them because it takes a bit And I’ve switched to the demonstration I’m going to run the NPM install NPM build does take awhile Then, NPM start to start the web server for the Squoosh app And you see that it tells you it runs at 8080 It bounds to all local addresses So let’s run Chromium for Linux This runs in the Linux container And once Squoosh has started, which seems to be the case, let’s go to a local host 8080 And there is Squoosh I’m not sure why it said failed But it certainly works You can open images or not This is a live demo, after all [LAUGHTER] The point here is that you have access to a local host from the Linux container, and now, let’s try running Chrome Dev from Play And then choosing Chrome Dev here to be able to distinguish the icons It looks like we need to update it Hopefully, the update won’t break anything [LAUGHTER] So I’m going to launch it before it gets a chance to update Now– [LAUGHTER] Local host here will not work That’s a known issue Steve is working on it We need to get– didn’t mean to put you on the spot, Steve We need to get the IP address of the Android container, which is this one There is this command, IP Address Show, which has a long ass output So I’m going to just copy that and paste it in Chrome Dev, which I thought I launched somewhere STEPHEN BARBER: It quit because it updated DAN DASCALESCU: OK Well, I hope it didn’t break anything Colon Whoa [APPLAUSE] So this is Squoosh running in Chrome, and now, let’s try something even more dangerous Let’s try to remote debug it with Chromium On the same machine– I know it’s called remote debugging, but it’s on the same machine because these are different containers So to do that, we need to put a device in developer mode, and then enable it to be debugging here, which I’ve done And then we need to run this command That fixed IP is actually documented on our Android setup page It’s the IP of our container, and we set up an ADB bridge to it So now, if things are on my side, we’ll be able to go to Chrome Inspect and see a number of remote targets here And we actually see two of them, so let’s open the Squoosh one, and I’ll click Inspect And this appears to work surprisingly well, for a demo So I’m going to resize the window and try something really spectacular I’m going to scroll So this is live, not an animated GIF This is actually remote debugging, and whatever I’m doing here, whether this app works or not, you can actually remote debug it with Chromium or Linux, debugging an Android browser running your progressive web

app Does that make sense? This is what I wanted to show, and let’s get back to the slides So these are the instructions for installing Node There’s nothing special here You follow what Node publishes on their GitHub, then you check out Squoosh using Git Again, your usual development workflow And oh, something else Maybe Steve wants to show this We can run VS Code to check out the code, so until we switch to the demo, this screenshot shows what we actually are going to do But great And I’ll do it live now So Steve is going to double tap that after he copies it to the Linux container And in the Linux container, if you double tap a dev file, you are prompted to install it as a Linux app So Chrome OS supports that out of the box, and once the installation completes, you should be able to see visual code in the launcher And even that installation prompt will say Find Visual Code in the Launcher And this is not network dependent, so we should be as fast as it was when we rehearsed Though 58% is not terribly fast OK, 91 Cool So show us some code, Steve STEPHEN BARBER: All right Wait one second or two seconds There it is Had to search And here we go VS Code [APPLAUSE] DAN DASCALESCU: Yeah I have a manifest That’s why it’s a progressive app– has a start URL OK, so let’s switch back to the slides for some best practices for– oh, no Let’s actually look at this once more It’s really cool, right, how you can drag those in sync, yeah? I had to brag about that So the way to set this up is not trivial, which is why I posted the Medium post this morning with complete instructions There’s about 17 steps you need to follow So check out the bit.li/cros-remote-debug or take a picture of this slide OK, I see the phones down, so next How to actually optimize PWAs for Chrome OS, which is not really a topic It’s more of a non-topic You shouldn’t detect that you’re running on Chrome OS You should use Lighthouse as you use for any PWA So if you only have five minutes to spend on optimizing your app, check out Lighthouse, the auditing tool that will give you a checklist of what to do And make sure that your app installs This is one bit that might be different on Chrome OS Unlike on older versions of Chrome on mobile, your users will not be prompted automatically at the bottom to install the app You need to catch the beforeinstallprompt, and then save that prompt and call the prompt method And this is the code to do that, so you add an event listener for beforeinstallprompt, then you prevent default for all the browsers, save the prompt in this deferred variable, and then show your install button So here, we just set a display to block And then in the click listener for that install button, you hide it, call the prompt method from that saved variable, and then you check the user choice property, and particularly, the outcome field to see if the user has accepted your installation OK So as I said earlier, the answer to this question is no You have your app installed on the Chrome OS, but you should not do browser [INAUDIBLE] but do, instead, feature detection And the reason is there is a wide variety of input devices and form factors that Chrome OS can run on So you might have a touch screen or you might not Some lower end devices don’t have a touch screen There might be a trackpad or it might be the Acer Tab 10 tablet that I mentioned earlier There might be a keyboard So if your app can use keyboard shortcuts, it’s good to add support for them There may be a mouse, so add support for that if it makes sense There might also be a stylus, useful for drawing apps Also make sure to build responsive and take advantage of all the screen real estate This is an example of an app that supports a large or wide display, rather, and displays a number of days in the weather forecast But also, if it’s resized for phone-size screen, it shows less information And you can even support a rolled up state if the user just wants to glance at the weather continuously if they have OCD But for a media player– that would be a more useful example– you can have previous and next controls I actually have OCD and I do that often And this is an example from Starbucks They found that building responsive

pays off because users would actually order on the desktop and use their mobile device to pick up their order So build responsive It also pays off to optimize your forms because nobody likes to fill in the forms And to have some guidance– g.co/AmazingWebForms That’s an amazing URL And if you want to handle touch in an optimized fashion, check out g.co/WebTouch There are also pointer events, and these are a unifying model for all sorts of pointer input– touch, trackpad, mouse, stylus And you have a lot of events that are supported in the Chrome, Firefox, Opera, IE, Edge, and Samsung, such as pointer move You just need to add a listener for it or– sorry You have pointer enter, pointer down, pointer up, cancel out, leave, and so on More at the g.co/PointerEvents And this is an example of a code that distinguishes between the pointing device– you can check if there is mouse or touch or pen or something that has not yet been supported by the browser OK, so what’s going to happen in the future? We are working on improving the desktop PWA support One improvement is keyboard shortcuts Another one is badging for the launch icon So we don’t have to notify the user for everything You can display a number of notifications, just like for Android and iOS apps And then also, link capturing, which would make Twitter very happy They have a great PWA, but when you click on a link, it’s not captured yet So in the future, we hope to enable this, such that when you click on a link that your app can handle, your app will actually open and handle that link And for that, you need to define the scope parameter in the manifest And the scope parameter is used to determine when your user has left your web app and needs to be bounced in a tab We are also working on low-latency canvas contexts, which are introduced in Chrome 71 Beta And these are very useful for highly interactive apps They use OpenGLES for rastering, and how it works is that your pixels get written to the front buffer directly So this bypasses several steps of the rendering process, and Chrome writes there in that piece of memory that is used by the Linux rendering subsystem and the scanned [INAUDIBLE] screen So this low-latency context runs the risk of tearing, but if you don’t interact with a DOM, such as in a game or other highly interactive app, it’s useful to use it This is an example of how to set up a low-latency canvas context You pass the latency parameter true, and also, it needs to be opaque, so you pass alpha false And this is the last slide I had no idea what to put on it, but I figured that I should add that Chromebooks are these convergence machines that run Linux, Android, and Google Play natively without emulation So they run very fast You should totally take advantage of the 75% off discount, and please do explore Chromebooks and give us feedback We love feedback We have the Chromium OS dev group– the Google Group And also, the sub-reddit, Crostini If you find issues, please check if they’ve been reported at crbug.com Otherwise, file them using Shift-Alt-I, and add the Crostini tag And we are Dan and Steve, and thank you [MUSIC PLAYING]