[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]
There is a discussion on Hacker News, but feel free to comment here as well.