 I'm here with Stephen Barber, who's an engineer on Chrome OS. So good evening, everyone. I am Dantas Kalisku. 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 you 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 tool workflow there. And this is a sneak preview of what's coming into the talk. You can see here a terminal, an IDE, a couple browsers, and, of course, a PWA. So the second reason why you should develop on 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 also all in ones, like the LG Chrome base. And small four-factor PCs. This is the Chrome box, which was debuted by Samsung in 2012. And then HP, Asus, and other manufacturers followed suit. And this is the mini four-factor PC. It weighs three 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 Chrome box commercial. It powers digital signage or QS displays. And this summer, we saw the first tablet powered by Chrome OS. And 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, what are you 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 touchscreen. So this could also future prove 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, aka NomWeb. 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 cross-train subreddit, you'll find this thread. Try it 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 container's architecture, which I'll let Steve tell you more about. 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 apps 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 Cristini uses both virtualization and containers to provide security and 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, we'll 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 Christine is based right now on Debian Stable because a lot of developers are familiar with app 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. Like right now, we'll do port forwarding. It doesn't seem like you're running a container. You get localhost 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 and upcoming releases. And now, Dan will talk a bit more about using Chromebooks for web development and show us what Christine looks like in action. 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 cross-tiny 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 can install with app. To set up cross-tiny, search for Linux in Settings. And then you'll see this dialog 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. 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 web 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 Karlo, which is a Google project that is essentially a helpful Node app framework, provides applications with Chrome rendering capabilities. So with Karlo, 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 a high-level API for you to rendering 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. And this is what Spotify has done. You can see here that I'm going to open the Spotify.com in a 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 launched 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 Asian by now. And the organics on Windows starting with Chrome 70, the current versions table, and on Mac with Chrome 72, or if you want to give it a sneak peek, check the Enable Desktop AWS 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 payment request. Firefox is working on that. Edge has push notifications and out-of-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 Christine 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 out Squoosh. You might have seen it in one of the earlier talks. It's an image recompression app. We'll open that in VS Code to check out the code. Run 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 demo station. I'm going to run NPM install, NPM build, those take a while. Then NPM start to start the web server for the Squoosh app. And you see that it tells you it runs at port 8080. It bound 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 localhost 8080 and there's 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. The point here is that you have access to localhost from the Linux container. And now let's try running Chrome Dev from Play. And I'm 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. So I'm going to launch it before it gets a chance to update. Now localhost here will not work. And that's a known issue. Steve is working on it. We need to get the IP address of the Android container, which is this one. There is this command IP address show. So I'm going to just copy that and paste it in Chrome Dev, which I thought I launched somewhere. It quit because it updated. OK. Well, I hope it didn't break anything. Call on. Well, 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 the R container. And we set up an ADB bridge to it. So now if things are on my side, you'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. I'm going to 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 on 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. We're going to 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 deb 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. All right, wait one second. For two seconds. There it is. Head to search. And here we go. VS Code. 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. I had to brag about that. So the way to set this up is not trivial, which is why I posted a medium post this morning with complete instructions. It's about 17 steps you need to follow. So check out bit.li slash cro s dash remote dash 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 it before install prompt 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 before install prompt, 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. All right, so as I said earlier, the answer to this question is no. You have your app installed on Chrome OS, but you should not do browser sniffing, 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 touchscreen or you might not. Some lower end devices don't have a touchscreen. 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 have support for them. There might be a mouse, so I support for that if it makes sense. It might also be a stylus, useful for drawing apps. Also, make sure to build responsive and take advantage of all the screen early state. 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 to a font size screen, it shows less information, and it can even support a rolled up state if the user just wants to glance at the weather continuously. But for a media player, that would be a more useful example you can have previous and next controls. 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 we have some guidance at g.co slash amazing web forms. That's an amazing URL. And if you want to handle touch in an optimized fashion, check out g.co slash web touch. 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 Chrome, Firefox, Opera, IE Edge, and Samsung, such as pointer move, you simply add a listener for it, or, sorry, you have pointer enter, pointer down, pointer up, cancel out, leave, and so on. More at g.co slash pointer events. And this is an example of a code that distinguishes between the pointing device. You can check if there's mouse or touch or pen or something that has not yet been supported by the browser. Okay, 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 you 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 rendering, for mastering, 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 is scanned out directly to the screen. So this low latency context around 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 through, 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 converges 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 subreddit, 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.