WebAssembly: A new development paradigm for the web

Summary

This video script delves into the exciting realm of WebAssembly, a revolutionary technology that empowers developers to bring high-performance applications and libraries to the web, leveraging languages beyond JavaScript. It showcases groundbreaking examples of applications like AutoCAD, Figma, Photoshop, and Snapchat harnessing WebAssembly's capabilities. Moreover, it explores how languages like C++, Swift, Java, Kotlin, and Dart are embracing WebAssembly, enabling cross-platform development with native-like performance on the web. The script emphasizes the potential of WebAssembly to revolutionize web development, offering greater flexibility, portability, and performance optimization for developers and captivating user experiences.

Takeaways

• 🌐 WebAssembly (Wasm) is a low-level binary format that allows other languages to be compiled and run on the web, offering better performance and portability than JavaScript alone.
• 🚀 Wasm enables large applications like AutoCAD, Figma, and Photoshop to run on the web with high performance, and even allows running server environments like WordPress in the browser.
• 📚 Wasm supports a wide range of languages like C++, Swift, Java, Kotlin, and Dart, enabling developers to bring their existing codebases to the web.
• ⚡ Wasm provides performance improvements through features like threads, SIMD, and memory optimization proposals.
• 🧩 Wasm libraries like OpenCV, TensorFlow.js, and SQLite can be used in web applications, exposing JavaScript APIs and providing high performance.
• 📱 With Wasm GC (Garbage Collection), managed languages like Kotlin and Dart can run on the web with performance comparable to native mobile platforms.
• 🌉 Wasm GC enables shared memory between JavaScript and Wasm modules, reducing bloat and improving interoperability with web APIs.
• 🔀 Cross-platform frameworks like Kotlin Multiplatform Mobile and Flutter can now target the web with the same codebase as native mobile apps, thanks to Wasm GC.
• 🎨 UI frameworks like Jetpack Compose for Android can be brought to the web using Wasm, allowing developers to share UI code across platforms.
• 🔓 Wasm opens up new possibilities for web development, combining the productivity of cross-platform development, the performance of native apps, and the openness of the web.

Q & A

What is WebAssembly?

WebAssembly is a low-level binary format for the web, compiled from other languages, that offers maximized performance and is meant to augment the places where JavaScript isn't sufficient.

Why should developers use WebAssembly?

There are three main advantages of using WebAssembly: 1) It offers more reliable and maximized performance, 2) It enables great portability by allowing developers to compile from other languages and share code across deployments, and 3) It offers greater flexibility by allowing developers to write for the web in languages other than JavaScript.

What are some examples of large applications that have been brought to the web using WebAssembly?

Some examples mentioned in the script are AutoCAD, Figma, Photoshop, Snapchat, and WordPress.

How does WebAssembly enable the use of libraries like OpenCV, TensorFlow.js, and Skia on the web?

WebAssembly libraries, such as OpenCV for image analysis, TensorFlow.js for ML, and Skia for graphics, expose JavaScript APIs and are amazingly performant thanks to WebAssembly under the hood.

How has WebAssembly enabled Swift applications to come to the web?

The SwiftWasm toolchain, which includes JavaScript kit and Carton, has matured to a point where Swift on WebAssembly is truly shippable in production. This has allowed applications like GoodNotes to reuse their Swift code base and bring their iOS app to the web.

What are some recent advancements in the WebAssembly standard itself?

Recent advancements include WebAssembly threads and SIMD for performance-sensitive workloads, the tail called proposal for functional programming languages, the memory 64 proposal for addressing more than 4 gigs of memory, and the JavaScript Promise Integration API for accessing asynchronous APIs from synchronous code.

What is WebAssembly GC and how does it address the challenges of managed memory languages on the web?

WebAssembly GC is a new extension that shares a joint heap between JavaScript and WebAssembly GC modules, allowing managed memory code to allocate objects on this shared heap and have them garbage collected together. This eliminates the need for shipping a separate garbage collector, enables dynamic memory resizing, and improves interop with JavaScript code and web APIs.

How does WebAssembly GC benefit cross-platform frameworks like Kotlin Multiplatform Mobile and Flutter?

WebAssembly GC allows these frameworks to compile directly to the native runtime of all three platforms (Android, iOS, and the web), giving developers access to the reach and instant start-up of the web while providing users with a fast and smooth experience matching native platforms.

What is the significance of being able to share UI code across platforms with frameworks like Jetpack Compose?

Frameworks like Jetpack Compose, which allow developers to share much of their UI code across platforms, combined with the performance of WebAssembly, enable a truly consistent and high-performance user experience across Android, iOS, and the web.

What are the potential benefits of running applications on the open web using WebAssembly?

Applications on the open web are just a click away from new users, can be discovered and shared easily without app stores or revenue splits, and offer the productivity of cross-platform development, the performance of native mobile apps, and the openness of the web.

Outlines

00:00

🌐 Introduction to WebAssembly

This paragraph introduces WebAssembly, a low-level binary format for the web that enables better performance and portability. It highlights the advantages of WebAssembly, such as reliable performance, cross-platform compatibility, and flexibility for developers. It also mentions that WebAssembly is now fully supported in major browsers. The paragraph sets the stage for discussing how various languages are leveraging WebAssembly for web development.

05:01

💻 C++ and WebAssembly

This paragraph focuses on the use of C++ with WebAssembly. It discusses how large applications like AutoCAD, Figma, and Photoshop have been brought to the web through WebAssembly, leveraging their existing C++ codebases. It highlights examples of companies such as Snapchat, WordPress, and others that have adopted WebAssembly to port their C++ implementations to the web. The paragraph also mentions the Emscripten toolchain, improvements in WebAssembly debugging, and the availability of various WebAssembly libraries like OpenCV, TensorFlow.js, and Skia.

10:01

🔢 WebAssembly and Managed Memory Languages

This paragraph discusses the challenges of bringing managed memory languages like Java, Kotlin, and Dart to the web. It explains the limitations of the original WebAssembly architecture, such as bloat and the split brain problem between JavaScript and WebAssembly memory spaces. The paragraph then introduces the WebAssembly GC extension, which enables sharing a joint heap between JavaScript and WebAssembly GC modules, addressing these issues and enabling better performance and interoperability.

15:01

🚀 Kotlin and Compose for Web Development

This paragraph focuses on Kotlin and its potential for web development with WebAssembly. It discusses JetBrains' efforts to bring Kotlin and Jetpack Compose, a modern UI framework, to the web. It includes a demonstration of a Compose-based application running in the browser, showcasing the ability to share code across platforms, including the web. The paragraph also highlights the performance benefits and the ability to debug Kotlin code directly in the browser using Chrome's DevTools.

20:04

🌐 The Future of Cross-Platform Web Development

The final paragraph discusses the broader implications of WebAssembly for cross-platform web development. It emphasizes the productivity benefits of cross-platform development, the performance advantages of native mobile apps, and the openness of the web. The paragraph mentions Flutter's adoption of WebAssembly for better performance on the web and the potential for developers to target multiple platforms, including the web, without compromising performance or user experience.

Keywords

💡WebAssembly

WebAssembly is a low-level binary format for the web that is compiled from other languages like C++, Rust, Swift, Java, Kotlin, and Dart. It offers maximized performance, portability, and flexibility for developers to write web applications in languages other than JavaScript. The video highlights WebAssembly's ability to enable large, performance-demanding applications like AutoCAD, Figma, and Photoshop to run on the web.

💡C++

C++ is one of the earliest languages to leverage WebAssembly, enabling large applications with large code bases like AutoCAD and Figma to be ported to the web. The video mentions how AutoCAD brought its 40-year-old codebase, and Figma wrote its engine in C++ for maximized performance. C++ is compiled to WebAssembly using tools like Emscripten, which also handles porting POSIX APIs and translating OpenGL calls to WebGL.

💡Swift

Swift is a language that can now be compiled to WebAssembly, enabling Swift applications like GoodNotes to be brought to the web while reusing their existing Swift codebase. The video shows how GoodNotes uses a React UI framework, PWA for installability, and a central Canvas connected to the Swift Engine. The toolchain used is SwiftWasm, which includes JavaScript Kit for interacting with JavaScript and Carton for bundling and deployment.

💡WebAssembly GC

WebAssembly GC (Garbage Collection) is a new extension that enables managed memory languages like Java, Kotlin, and Dart to efficiently run on the web. It shares a joint heap between JavaScript and WebAssembly GC modules, eliminating the need for shipping a separate garbage collector implementation. This results in smaller binaries, faster interop with JavaScript and web APIs, and a dynamically resizable memory footprint.

💡Kotlin

Kotlin is a statically-typed programming language that can now run on the web thanks to WebAssembly GC. The video showcases Kotlin multi-platform mobile, which allows developers to write business logic once and compile it for Android, iOS, and the web. JetBrains is working on bringing Jetpack Compose, a declarative UI framework for Android, to the web using Kotlin WebAssembly.

💡Dart

Dart is a programming language used by the Flutter framework for building cross-platform applications. With WebAssembly, Dart code can now be compiled directly to efficient WebAssembly code in the browser, unlocking faster performance for Flutter web applications compared to transpiling to JavaScript.

💡Cross-platform development

Cross-platform development refers to the ability to write code once and deploy it across multiple platforms, such as mobile (Android and iOS), desktop, and web. The video highlights how WebAssembly enables cross-platform frameworks like Kotlin multi-platform mobile and Flutter to target the web without compromising performance, providing a native-like experience on all platforms.

💡Performance

Performance is a key advantage of using WebAssembly. The video emphasizes how WebAssembly offers maximized and reliable performance for demanding applications, enabling smooth experiences on the web comparable to native mobile platforms. This is achieved through efficient compilation from languages like C++, Rust, Swift, Kotlin, and Dart.

💡Portability

Portability refers to the ability to run the same code across different platforms or deployments. The video highlights how WebAssembly enables portability by allowing developers to compile code from various languages like C++, Rust, Swift, Kotlin, and Dart, and share that code across web, mobile, and desktop environments.

💡Web APIs

Web APIs are interfaces provided by the web browser for interacting with various browser features and functionalities. The video discusses how WebAssembly GC improves interoperability with JavaScript-based Web APIs like the DOM, Canvas, WebGL, and Web GPU, enabling efficient data exchange without excessive copying between JavaScript and WebAssembly heaps.

Highlights

WebAssembly is a low-level binary format for the web that is compiled from other languages, to offer maximized performance and is meant to augment the places where JavaScript isn't sufficient.

WebAssembly offers more reliable and maximized performance, great portability since you can compile from other languages, and greater flexibility for developers to write for the web in languages other than JavaScript.

Large applications such as AutoCAD, Figma, and Photoshop have been brought to the web using WebAssembly, enabling them to leverage their existing code bases and achieve high performance.

Snapchat is using WebAssembly to expand their audience while using a single code base, delivering their entire application directly in the browser across all operating systems.

WordPress has managed to get the WordPress server environment built to run directly in the browser by compiling the PHP interpreter and SQLite to WebAssembly.

WebAssembly libraries like OpenCV, TensorFlow.js, Skia, SQLite, and FFmpeg are changing web development by providing high-performance functionality through JavaScript APIs.

Swift on WebAssembly is now shippable in production, with applications like GoodNotes reusing their Swift investments to bring their iOS app to the web.

WebAssembly is being continuously improved with features like threads, SIMD, tail call optimization, memory64, and JavaScript Promise Integration API.

WebAssembly GC (Garbage Collection) extension shares a joint heap between JavaScript and WebAssembly GC modules, enabling smaller binaries, faster interop, and dynamically resizable memory footprint.

WebAssembly GC allows managed memory languages like Java, Kotlin, and Dart to run on the web with up to two times faster performance than compiling to JavaScript.

Cross-platform frameworks like Kotlin Multi-Platform Mobile and Flutter can now compile directly to the native runtime of web, Android, and iOS platforms, providing a fast and smooth experience across all platforms.

JetBrains demonstrates Jetpack Compose, a declarative UI framework for Android, running on the web using Kotlin WebAssembly, with the potential for shared code across platforms.

Flutter developers can now compile Dart code directly to fast and efficient WebAssembly code in the browser, unlocking better performance for Flutter web apps.

WebAssembly offers the productivity of cross-platform development, the performance of native mobile apps, and the openness of the web.

The WebAssembly community is continuously working on improving and expanding the standard, with proposals for features like SIMD instructions, tail call optimization, memory64, and JavaScript Promise Integration API.

Transcripts

[MUSIC PLAYING]

THOMAS NATTESTAD: Hi, everyone.

My name is Thomas.

Along with my colleague Vivek, we

will be covering WebAssembly and how

it's enabling a new paradigm of web development.

So let's start off by covering what WebAssembly actually is

and why you would use it.

Well, WebAssembly is a low-level binary format

for the web that is compiled from other languages

to offer maximized performance and is

meant to augment the places where

JavaScript isn't sufficient.

So why use WebAssembly?

Well, there are three main advantages.

First, it offers more reliable and maximized performance.

Second, it enables great portability

since you can compile from other languages,

enabling you to share your code across deployments.

Lastly, it offers greater flexibility

for developers who can now write for the web in languages

other than JavaScript.

Perhaps best of all, it is now shipping fully

in every major browser, so you can reliably

reach all of your users.

In this talk, we want to go over four languages

to show how they're coming to the web

and how you can get started yourself.

We're focusing on these four languages in this talk.

But it's worth noting that there are a ton of other languages

that are also adding support for WebAssembly.

So let's dig in and start off with C++.

One of the earliest areas where WebAssembly transformed the web

was by enabling large applications, such as AutoCAD,

Figma, and most recently, Photoshop, on the web.

These are performance demanding applications

with large code bases, often ported from other platforms.

AutoCAD brought their code base, which

was started over 40 years ago, before the first ever browser.

And now, parts of that original code base

are directly accessible with a simple link.

Figma made a big bet on WebAssembly from the start

and wrote their Engine in C++ for maximized performance.

Photoshop has brought their complex application to the web,

enabling easy sharing across platforms

with commenting and editing.

They'll also soon be using Web ML for optimized machine

learning operations, which you can

hear more about in the What's New with Web ML

talk here at I/O.

In the last year, we've continued

to see more of these incredible advanced apps,

leveraging Wasm to come to the web.

Snapchat wanted to expand their audience

while using a single code base to hit all of their platforms.

They decided that C++ would give them the performance

and portability that they needed.

By leveraging WebAssembly, they can

deliver their entire application directly

in the browser across all operating systems.

Snap is also investing in bringing their amazing camera

kit to the web through WebAssembly,

which you can try yourself right at web.snapchat.com.

Here, they're again reusing their C++ implementation that

is shared across platforms.

They're using Emscripten, including its Embind binding

systems, and OpenGL to WebGL conversion.

They're also using TensorFlow.js for ML inference,

Web Workers for off-screen rendering,

and performance optimizations using the Chrome profiling

tool.

WordPress has done something rather incredible

and actually managed to get the WordPress server

environment built to run directly in the browser.

This relies on compiling the PHP interpreter itself and SQLite

to WebAssembly.

With this, users can try out WordPress directly

in the browser with zero setup.

This is amazingly impactful for getting started,

enabling interactive tutorials, and eventually supporting

easy publishing of backends.

By running on Wasm, they can now also

deploy to non-browser environments,

including Node.js or other Wasm server environments.

You can read tons of interesting details

in this deep dive blog post.

All of these examples are powered

by the Emscripten toolchain.

Emscripten will help compile your C++ code,

but also helps port code built against POSIX APIs,

and will even translate OpenGL calls to WebGL.

To get started, go to emscripten.org.

We've also made really substantial improvements

in enabling WebAssembly debugging.

With this support, you can now see your C++ code in DevTools,

set breakpoints, step through your code,

and even see runtime values of variables.

Visit this link to see how.

Now, you might be thinking to yourself,

I'm not writing C++ or building a large cross-platform

application.

I'm doing web development.

Well, this is where WebAssembly libraries

are going to change your life.

These libraries include things like OpenCV for image analysis,

TensorFlow.js for ML, Skia for graphics, SQLite for database,

FFmpeg for video manipulation, and so, so much more.

You can dig into these examples at this URL.

These examples all expose JavaScript APIs.

And you might not even know that they're powered by WebAssembly

under the hood, except for how amazingly performant they are.

So let's take the incredible web app for Telegram as an example.

Telegram is a traditional web application

with the majority of functionality

built in JavaScript.

But there were a few areas where they

needed some additional functionality

that they found in WebAssembly.

Specifically, they use the RLottie renderer

for animated stickers, Opus Recorder for voice recording

and decoding, fastTextWeb for language detection,

and Webp-hero for dot Webp support in Safari.

And indeed, when looking at MPM, there

were 1,500 packages with WebAssembly.

If you're a library author in really any language,

and you're interested in bringing your library

to the web, now is your moment.

If you'd like to connect directly with us,

provide feedback on your experience,

or even get featured on web.dev, you can visit this link.

So now that we've covered C++, let me jump into Swift.

It's been possible to compile Swift WebAssembly for a while.

But it's only recently that the toolchain and ecosystem

have matured to a point where this is

truly shippable in production.

One such application that is shipping Swift on WebAssembly

in production and coming to the web is GoodNotes.

They have invested a decade of work

in creating the most incredible iOS

application, full of cool features with a 4.8 star

rating.

They decided it was time to spread their application

to non-iOS users.

And rather than having to do an incredibly expensive rewrite

that would also have to be separately maintained,

they decided to reuse their Swift investments

through WebAssembly.

This means their decade of work can be reused, while also

minimizing maintenance costs.

When we talked to them, one of my favorite things they said

was, quote, "every day, our iOS developers contribute something

new to our Swift code base.

And our web app benefits from that."

In terms of their tech stack, they're

utilizing Swift on WebAssembly, React as their UI framework,

and PWA for installability.

They have a great Tech Talk with lots more details at this link.

They do their surrounding UI in React,

and have a central Canvas connected to the Swift Engine.

This is the same pattern that we saw with our previous partners.

As an example, when a user clicks something like Add Page,

it calls from the click handler in React

into the Swift code base to add the page

and then make it ready for input.

The toolchain they use is called SwiftWasm.

And you can get started with that on swiftwasm.org.

The toolchain includes JavaScript kit,

which enables your Swift code to interact

with JavaScript through bindings and translating types

and objects.

It also offers Carton, which provides a Swift alternative

to something like webpack.

It lets you easily bundle and deploy your app,

while also shipping your code to other platforms.

As with anything, there are some limitations

that developers should be aware of.

I want to be clear that this isn't

a magic button that will make your Swift app run directly

on the web.

And while it's dramatically faster than a rewrite,

it's not zero effort.

Swift code and SwiftUI should work well.

But things like storage, UI kit, networking, and files

need to utilize web alternatives.

Still, if you're a Swift developer who

has been hoping to expand your addressable market,

this is your moment.

So now I want to take a step back from any specific language

and update you a bit on the progress of the WebAssembly

standard itself.

In the past, we've discussed how WebAssembly threads and SIMD

can offer a 10x or more improvement

for performance-sensitive workloads.

For an overview of how powerful these features can be

and how to get started, check out

this video from Chrome dev sub.

And we're continuing to expand with even more SIMD

instructions to further maximize performance.

The tail called proposal is a critical optimization

for functional programming languages and enables better

support for C++ programs using coroutines.

The memory 64 proposal gives applications the ability

to reference more than 4 gigs of memory

and making it easier to port code that

assumes a 64-bit architecture.

Lastly, the JavaScript Promise Integration API

lets synchronous code access asynchronous APIs

without substantial code size or performance overhead.

This is a big deal if you're trying

to make code that assumes a synchronous environment

work with the web.

Now, to continue our language journey,

I'm going to turn it over to my colleague, Vivek.

VIVEK SEKHAR: Thanks, Thomas.

You may remember at last year's Google I/O,

we previewed our plan to bring new languages,

like Java, Kotlin, and Dart to the web.

Over the past year, the WebAssembly community

has been busy making this happen.

So let's talk a bit about what we built

and what this new technology makes

possible for developers across the web

and native mobile platforms.

As Thomas mentioned, WebAssembly has taken off among developers

using C and C++, as well as a growing community around Rust.

In these languages, developers are

responsible for, in a sense, cleaning up after themselves,

freeing objects from memory after an application

is done using them.

This class of languages was the primary focus

of the early WebAssembly standard, what

we call WebAssembly MVP, in part because these were

the languages many large desktop applications were written in,

and also because they had somewhat simpler requirements

when developing the WebAssembly standard.

Another class of languages manages memory

on behalf of the developer.

The languages own runtime automatically

finds and frees memory that the app is no longer using.

This class of languages is really interesting

if you're building web or mobile apps because JavaScript

is the language in which the web's own APIs are specified

and standardized.

And Kotlin and Dart are increasingly

popular among developers building

cross-platform, native mobile apps.

So we wanted to figure out, what would it

take to extend the web platform to applications

written in these languages in a performant way?

So let's walk through how we do that.

When a web app starts in the browser,

it's given a context for its JavaScript code and some heat

memory.

JavaScript memory is garbage collected,

so there's a garbage collector provided by the browser

behind the scenes.

Now, when an app instantiates a WebAssembly module,

it asks for and is allocated a region of linear memory

for its own use.

If the developer is using a language like C or C++,

then the WebAssembly module uses some of this memory

for a dynamic heap.

And the developer would handle freeing objects on that heap

after they're used.

On the other hand, if the developer

wanted to use a managed memory language,

then the WebAssembly module will need

to include that language as garbage collector code

to manage the heap and automatically free up

unused memory.

There were two main problems with this approach.

The first is obviously bloat.

The WebAssembly module has to ship and instantiate

that garbage collector every time the app is loaded.

This increases the module size and delays the application

startup, despite the fact that every standards compliant

browser out there already contains a garbage

collector for apps to use.

Another form of bloat comes from the need for developers

to have a kind of clairvoyance when deciding how much memory

to request for their module.

To avoid crashes, the typical thing to do

is to set a maximum memory size that

is just beyond the upper bound of your anticipated memory

needs.

This puts more pressure on implementations

who have to manage the apps JavaScript and WebAssembly

memory separately, alongside the memory needed by other apps

and tabs that the user might be using.

The second problem is what I call the split brain problem.

In this architecture, those two memories

and their garbage collectors know nothing about each other.

This means developers need to be careful to architect

their applications to avoid corruption

when, for example, the JavaScript garbage

collector comes along and frees up

memory that's actually still needed by the Wasm side or vise

versa.

All this adds up to more bookkeeping

that developers have to do themselves,

which kind of breaks the whole reason to use a managed memory

language in the first place.

But even if you put all of your objects on one side,

on the WebAssembly side, you can't

avoid dealing with the JavaScript heap.

And that's because of web APIs.

Web APIs are specified to accept and return

JavaScript objects, which naturally

live on the JavaScript heap and are collected by the JavaScript

garbage collector.

In the original version of WebAssembly,

this meant copying your data in both directions

between WebAssembly and JavaScript

any time you wanted to call a web API.

Graphics APIs, like the Dom, Canvas, WebGL, and Web GPU,

are especially impacted by this since in some cases,

they need to be called hundreds of times per frame

or thousands of times per second with very strict latency

requirements to avoid user visible jank.

The net result is, even after we built a fast compilation target

for code, many frameworks and applications

ran the risk of producing jankier experiences on the web

compared to what they would be able to produce

on native mobile platforms.

So how do we address this?

Well, the WebAssembly community created a new extension

that in effect, shares a joint heap between JavaScript

and WebAssembly GC modules.

Now, your managed memory code can just allocate modules

on this joint heap.

And when the browser's garbage collector comes around,

JavaScript and WebAssembly GC objects

are garbage collected together.

This means no more bloat.

Your WebAssembly module doesn't have

to ship its own full garbage collector

implementation with your app.

And your WebAssembly app can more easily

grow or shrink its memory consumption as needed,

just like a JavaScript app can.

Some browsers, including Chrome, will even

return unused WebAssembly memory from this shared heap

to the operating system whenever possible,

helping ensure all apps running on the user's device

remain efficient and responsive.

The web API story improves as well.

WebAssembly GC modules, create objects in the same heap where

the JavaScript Web APIs will look for them,

and return values are easily passed back as well,

all without excessive copying.

So that's WebAssembly GC, smaller binaries

for modern, managed memory languages,

faster interop with JavaScript code,

and the JavaScript-based Web APIs,

and a dynamically resizable memory footprint that

grows and shrinks to provide your module with what it needs.

With WebAssembly GC, the web can finally

give a proper welcome to our developer friends

building Flutter, Android, and Kotlin multi-platform apps.

Let's look at what WebAssembly means for you.

Early data shows that WebAssembly GC now

runs code compiled from these languages in the browser up

to two times faster than compiling them to JavaScript.

From a user's point of view, this level of performance

is increasingly indistinguishable from what

they would see on native mobile platforms.

We're talking about apps running at 120

frames per second with single millisecond frame update times.

We can now imagine a world where cross-platform frameworks can

build apps for native mobile platforms and the web

with no perceivable difference in capabilities or performance.

And the developer experience gets better too.

Previously, developers would have

to build separate native Android and iOS apps, as well as a web

app to reach the broadest set of users.

Cross-platform frameworks, like Kotlin, multi-platform mobile,

let developers write their mobile apps business

logic, the part that manages user data

and implements your apps features,

in a single code base that compiles to both Android

and iOS, while implementing their user

interface using platform native frameworks and widgets.

But extending this cross-platform capability

to the web ran into some challenges.

For a long time, you couldn't really

compile mobile languages, like Kotlin, to the web.

At best, you could transfer pile it to JavaScript

and then run that JavaScript in a browser.

This approach produced apps on the web

that just weren't as fast and smooth for users

as they would be on native mobile platforms.

Now, thanks to WebAssemby's new support

for managed memory languages, cross-platform apps

can compile directly to the native runtime of all three

platforms, giving developers access to the reach and instant

start up of the web, and giving users

a fast and smooth experience wherever they find your app.

The Kotlin community also benefits from UI frameworks,

like Compose, which can help developers

share much of their UI code as well across platforms again,

with the performance level matching

that of native platforms.

Here's Sebastian from JetBrains to share more about Kotlin

multi-platform and Compose.

Thank you, Vivek.

At JetBrains, we think WebAssembly

is a promising technology.

And we want Kotlin developers to get all the benefits

it has to offer.

Just recently, we released an experimental version

of the WebAssembly target for the Kotlin compiler.

SEBASTIAN: We see a lot of potential use

cases in Kotlin Wasm's future, from building

high-performance web applications running

in the browser, to building speedy serverless functions.

I want to show you a concrete example of one such thing that

is part of the potential future of Kotlin Wasm.

So here you can see an application

built using Jetpack Compose, the declarative and modern UI

framework created by Google for Android.

You might have actually seen this specific app before.

Now, at JetBrains, we're working on bringing Jetpack Compose

to multiple other platforms beside Android,

like desktop, iOS, and web.

In practice, this means that you can take any knowledge

about the APIs of Jetpack Compose

that you might have from developing for Android

and use it to target other platforms.

The web target for Compose is built on top of Kotlin Wasm.

It's still experimental.

But let me show you what we can already do with it.

Here is the same application you just saw on Android

running in Google Chrome.

It looks and behaves just like we saw on Android before.

If we want to get an idea of the current performance

of this app, we can open the FPS counter in Chrome's DevTools

and watch some of these beautiful animations.

We're also working on making it possible

for you to debug Kotlin code right inside your browser

and inspect variables and stack traces

right in Chrome's DevTools using the built-in support for source

maps.

Now, let's move back to IntelliJ IDEA

and take a quick look at the code of our app.

As you can see, the UI and business logic of the app

are all located in the Common module.

It's all code that is shared between the different targets

for the project.

But we can also specify platform-specific logic

for the individual targets in the respective subprojects.

That way, we still get to use everything

in terms of platform-specific APIs.

OK, so after making a small change to our code,

we can actually have a look at the result of the changes.

And look at that.

They appear right in the browser.

We hope this little demo made you want to learn more

about this experimental technology we're

building at JetBrains.

If that's the case, follow the link

and check out the project sources for this demo yourself.

Thank you and take care.

VIVEK SEKHAR: Thanks, Sebastian.

You can learn more about Kotlin running

on the web with WebAssembly at kotlinlang.org.

And we're not just making Android apps multi-platform

with Kotlin.

Multiplatform developers have been using Flutter for years

to target Android, iOS, and the web.

And on the web, Flutter developers

have also had to transpile to JavaScript

to run in the browser.

But we're unlocking faster performance for Flutter web

as well.

For the first time this year, compiling Dart

code directly to fast and efficient WebAssembly code

in the browser.

You can read more about the exciting new performance boost

offered by Flutter web at flutter.dev/wasm.

On the open web, your app is just a click away

from new users, who can discover it and share it just

as easily as they share a web page, with no stores getting

in the way and no revenue split affecting your profitability.

The productivity of cross-platform development,

the performance of native mobile apps,

and the openness of the web--

that's why we love WebAssembly.

On behalf of Thomas, myself, the Flutter team,

and our friends at JetBrains, thank

you so much for joining us.

We can't wait to see what you'll build next.

[MUSIC PLAYING]