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

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments

There is a discussion on Hacker News, but feel free to comment here as well.

👍︎︎ 1 👤︎︎ u/qznc_bot 📅︎︎ Nov 14 2018 🗫︎ replies
Captions
[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]
Info
Channel: Google Chrome Developers
Views: 35,447
Rating: undefined out of 5
Keywords: type: Conference Talk (Full production);, pr_pr: Chrome, purpose: Educate
Id: QTmAtXoPkgw
Channel Id: undefined
Length: 23min 46sec (1426 seconds)
Published: Tue Nov 13 2018
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.