[MUSIC PLAYING]
KEVIN MOORE: I don't know if you've noticed,
but the web has changed a lot in the last 20 years.
This is Wikipedia in 2002, a pretty typical example of what
you could expect from the web at the turn of the millennium.
Fast-forward 20 years, and hardware-accelerated graphics
and a rich user experience can almost
be taken for granted on the web.
20 years ago, opening a URL meant black text and blue links
on a white background.
Now, it means flying around your favorite local landmark
from the comfort of your couch.
How did this happen?
In this talk, I want to cover three things--
first, how browser technology has expanded the web
beyond sites and pages to rich application experiences.
Second, how Flutter uses the latest browser technologies
to fundamentally change how developers
think about targeting the web.
And third, a quick look at emerging standards
that will push the possibilities of the web and web
apps even further.
Let's rewind again to 2002.
20 years ago, we had web pages, linked documents,
and some images.
This was and still is a great way to consume text content.
But if you wanted to actually do anything on your computer,
you needed a native application.
To do pretty much anything, it's amazing
how much time we spent running setup and then
downloading patches just to do simple tasks.
Let's fast forward.
In 2022, I use my phone to play on the web, and on my laptop,
I use a web app to make phone calls.
Documents, spreadsheets, chat, taxes, games, even telephones
are web apps.
And a growing number of traditional installed desktop
apps are just wrappers around web experiences.
It's pretty clear we've gone through a fundamental blurring
of the line between what's a web experience and what's an app.
Let's talk about the technology that got us here.
I could spend hours going through all
of the capabilities added to the web browser over the last 20
years.
From networking, to URLs, to storage,
to threading and programming models, to security,
every aspect of developer and user experience
has seen massive innovation.
But I want to zoom in on one area in particular--
how we paint pixels on the screen.
We're going to spend a bit of time in this diagram.
Browser here could be any modern web browser.
But later, I will get into things
that are specific to Chrome.
Above the browser, we see application code, which often
is built on an HTML framework.
This sits on a stack of browser technologies.
Let's zoom in to HTML.
You can also call this the DOM.
This includes things like CSS, text layout, user input,
et cetera.
This is the first and still the most prevalent way
to paint pixels on the web.
But there is another option.
Canvas started with a simple 2D API to literally paint pixels,
and it freed developers from the "everything must be an element"
model of HTML.
Then WebGL came along to bring 3D
and accelerated graphics to the web.
But wait, some might say.
You can't ditch HTML.
HTML is what makes the web the web, right?
I'd actually claim it's the URL and not
HTML that's core to the web.
HTML is great, but it's the URL that makes the web powerful.
It's how we share content.
It's how search engines find the world's information
and make it accessible and useful.
It's how we compose media and code and data
from different sources.
The URL has replaced running big, scary setup apps for most
of our computing experiences.
But even if I've convinced you HTML is not the only way
to make web experiences, why would a developer pick Canvas
and WebGL unless you're building something 3D?
Why walk away from the richness of the browser document model
to mess with individual pixels?
There are three reasons.
First, flexibility-- HTML represents
one way to build for the web.
Canvas and WebGL now offer all of the pieces needed
to imagine a completely different developer
experience and user experience.
Second is portability.
If an application is built in HTML,
you need to run it in the browser,
or you need to embed the browser in your application.
This is how frameworks like Electron work.
If instead you drop down to the level of triangles
and textures, your assumptions of the target platform
are much easier, so porting is much easier.
It also makes it easier to have a consistent, high-fidelity
experience across many platforms.
Third is performance.
The history and richness of the HTML stack is a feature,
but it can come at a cost.
Being able to have an app platform built straight
to hardware-accelerated graphics removes a lot of barriers
to rich visuals and high frame rates.
So while 3D is clearly important for apps like Google Earth,
apps like Adobe Photoshop can leverage the flexibility,
portability, and performance of Canvas and WebGL
to bring a big desktop app experience to the web.
What's missing is a toolkit that leverages
the power of this new web app paradigm while also being
approachable and portable.
This brings us to Flutter.
Flutter makes a flexible, portable, and performant UI
toolkit available to anyone who wants to target the web.
Let's talk about how.
You can break Flutter into two parts--
the framework and the engine.
The engine, we'll get back to shortly.
The framework is all of the things a developer uses
to build an application.
Think UI widgets, layout containers, and APIs
for animation and input.
And all of this, including your Flutter application,
is written in the Dart programming language
and compiled to JavaScript to run on the browser.
Again, there's an obvious question-- why Dart?
Why not JavaScript or TypeScript?
We're used to this question.
In fact, we hear similar questions
from many other developers.
We'd like to think of Dart as Flutter's superpower.
Flutter needs a language and runtime
that work great on native platforms and the web.
Flutter needs a great developer experience,
where we can go from updated code to updated
pixels in milliseconds.
Flutter also needs production binaries
that are small and fast across architectures.
Dart delivers all of these.
Now, there is one exception to the Dart-everywhere model
of Flutter, and that's in the engine.
The Flutter engine embeds Skia.
Skia takes the triangles and textures provided by WebGL
and exposes a rich 2D API.
If you remember before, the Chrome HTML stack
is accelerated in a separate GPU process.
The layer between the HTML and the GPU
that handles rasterizing, layering,
and compositing-- that's Skia.
Skia is an open-source GPU-accelerated 2D graphics
library that powers Chrome.
And it's highly portable, running anywhere Chrome runs,
so it's an amazing building block.
Flutter takes Skia, the C++ API that's shipped within Chrome,
and hoists it into the Flutter engine.
But how do we run C++ in a web framework?
With WebAssembly.
WebAssembly allows native code-- think C++--
to be compiled into small, high-performance, portable, and
secure modules for the web.
This is the trick used by Google Maps and Adobe Photoshop
to run in the browser, and we use it with Skia.
And because Skia is so portable and Dart is so flexible,
we can bring Flutter pretty much any place
you want to bring pixels.
But there's one piece left--
apps are more than pixels.
If there's a native platform-level feature,
it's likely supported on the web now,
or there's a working group looking into it.
The Flutter team is working hard with the community
to provide integrations for all of these APIs
across native platforms and the web.
So how does Flutter enable web apps?
First, with Dart for happy app developers and happy app users;
with Skia, an optimized portable 2D graphics
library powered by WebAssembly; and with modern browser APIs--
all of the rich features that go beyond painting pixels.
But can you build real apps on the web with Flutter?
Yes.
Supernova uses Flutter to connect designers
and developers by turning design assets into running
code, all on the web.
Rive allows creators to add rich, animated, interactive
content to their products while providing open-source runtimes
to deploy on a wide variety of platforms.
iRobot is letting kids program machines both virtual
and in the real world, using a rich, visual programming model.
And Google Classroom just announced a new feature--
practice sets-- built on Flutter to give students
a more engaging and personal learning experience
with digital ink and a math keyboard with a built-in tutor.
The education space makes me really excited
because it highlights the benefits of democratizing
application experiences.
Not everyone has their own computer.
Not everyone has rights to install apps
on the devices they use.
When you make an experience a web experience,
you suddenly expand access to so many more folks.
A locked-down or shared computer--
think a school computer lab or a library--
these are now fair game for rich math tools,
or programming virtual robots, or building
rich, interactive content.
This is the promise of the web in 2022,
and I'm excited that Flutter can play a part.
And we're just getting started.
Not only are we continuing to invest in the Flutter toolkit
on all platforms, but we're also excited about the continued
evolution of the web platform.
A lot of accessibility technologies
assume HTML content on the web.
This is tough if you're using Canvas or WebGL
since your app will appear effectively
as an opaque rectangle.
At the moment, Flutter uses a hidden HTML-based layer
to render accessibility information,
something we call semantics.
But we want something faster and more flexible.
That's why we're working with the Chrome team and standards
bodies to allow a programmatic definition
of the accessibility tree via something called
the Accessibility Object Model.
This will be great not just for Flutter web apps,
but for all apps using low-level graphics techniques.
We're also looking beyond JavaScript.
As I mentioned before, Dart not only targets the web,
but it can be compiled to run natively
on x86 and ARM processors.
Now the DART team is investigating compilation
of Dart to WebAssembly.
Our hope here is to continue pushing download sizes smaller
and runtime performance higher.
But to do this, we need some new features in WebAssembly.
Dart, like many high-level languages,
uses garbage collection to manage memory.
Since WebAssembly was originally targeted
at low-level languages, its design
assumes manual memory management.
One option would be to compile and ship
a garbage collector with every compiled WebAssembly app.
But that risks bloating the application size
and hurting performance.
So instead, we're working with the W3C and Chrome
on a proposal to add support for garbage collection
to WebAssembly.
The effort is called the WASM-GC.
We're excited to be included in conversations
with folks working on Java and Kotlin as well.
Our shared goal is to make WebAssembly
an amazing common target for all programming languages.
Finally, on the graphics front, there's WebGPU.
WebGPU is meant to take the last 10 years of hardware advances
and lessons learned in accelerated graphics APIs
to go far beyond what's possible today with WebGL.
WebGPU is available now as an origin trial in Chrome.
We can't wait for it to be stable across all browsers
so we can start using it.
Today's browsers are amazingly powerful,
and there's so much more to come.
The web started out as a great place for linked text content,
and it still is, but it's also a powerful, ubiquitous
application platform.
We're excited to share Flutter's unique capabilities
to make it easier to bring amazing applications
to the web.
And we're super excited to collaborate
on all of the great features yet to come.
Thank you.
[MUSIC PLAYING]