WebAssembly: A new development paradigm for the web

Рет қаралды 69,089

Жыл бұрын

WebAssembly (Wasm) is a low level, high-performance binary format for the web, which can be compiled from languages such as C++, Swift, Dart, & Kotlin. In this talk we’ll showcase new developments in language support, usability, and increased performance. We’ll also show you how to get started quickly yourself!
Resources:
AutoCAD blog → goo.gle/3LtWASX
Figma blog → goo.gle/3VtzekR
PS blog → goo.gle/3nsglSU
Speakers: Thomas Nattestad, Vivek Sekhar
Watch more:
Watch all the Technical Sessions from Google I/O 2023 → goo.gle/IO23_sessions
Watch more Web Sessions → goo.gle/IO23_web
All Google I/O 2023 Sessions → goo.gle/IO23_all
Subscribe to Google Chrome Developers → goo.gle/ChromeDevs
#GoogleIO

Пікірлер: 124

@ChromeDevs Жыл бұрын

Want to learn more about what's new for the web? Check out the Web Keynote at #GoolgeIO → goo.gle/IO23_webkey_pin

@cold_ultra Жыл бұрын

So I no longer need to copy buffers back and forth if I use wasm GC? huge if true, unfortunaltelly I could not find any simple demo to play arround with

@MirosawSiwecki 2 ай бұрын

In C# Blazor webassembly its the fourth year you dont need it

@muhamedkarajic Жыл бұрын

Truly amazing!

@amlivinginhell 11 ай бұрын

is wasm used only to compile codes from other languages to wasm?

@user-gy1hb1cq8x Жыл бұрын

Is webassembly supported in android system webview? and other mobile platform webview? like flutter webview and android webview devtool

@ben6 Жыл бұрын

Ahh, Wasm and JS will share memory. It would be good hear more about how race conditions are avoided.

@VincentPride1986 Жыл бұрын

Just write a good code and race conditions will be avoided

@Joshua-dc4un Жыл бұрын

@@VincentPride1986 just imagine creating a platform feature that requires the developer to write "good" code for it to work... it has always worked out well, right? 😂

@VincentPride1986 Жыл бұрын

@@Joshua-dc4un a man can only dream... Anyways, let's wait for LLMs to replace low level programming in a few years

@mAcCoLo666 Жыл бұрын

Why would you have race conditions by just sharing memory? Your run-of-the-mill program already shares memory with the rest of your computer programs...

@perplexedmoth Жыл бұрын

There is already SharedArrayBuffer supported in all browsers which allows you to share memory. The other, possibly bigger, issue with sharing memory is the object memory layout difference between that of JS, and the language that uses WASM. Accessing the same objects from both languages requires a language-agnostic memory layout, or pay the penalty of serialization/deserialization. Regarding the comment on race conditions, that doesn't make sense, since there's no multi-threading support, and hence there's no "race condition"s as I understand it to mean. If you mean just programmer errors stemming from mutating objects through multiple scopes, that can still happen using JS only.

@StefanGoldener Жыл бұрын

So what's the better cross-platform development stack? DART/FLUTTER or KOTLIN/JETPACK COMPOSE? Kotlin seems still the most popular at Google (amount of Development/News). Furthermore, for new Projects with the new WEB capability, Kotlin can do what Flutter already could do while keeping the existing codebase. So there is no need for Flutter anymore 🤔. Would be great if Google could clear this up a bit so choices on which language/framework to use in long-term cross-platform development/new projects could be made easier.

@_umutyilmaz Жыл бұрын

I agree that Google should decide about the better long-term option, and continue investing in it. It should be Compose imho.

@RomanTchekashov Жыл бұрын

With Dart+Flutter you can write UI logic once but with Kotlin KMM you can reuse only bussiness logic. So with Dart+Flutter you can create multiplatform apps faster.

@Mzulfreaky Жыл бұрын

For me, more options are better

@walrider7374 Жыл бұрын

I think Flutter UI is far better than Compose... But man, Dart is ugly as hell... once you taste the sweet of Kotlin, Dart taste like old Java

@RomanTchekashov Жыл бұрын

@@walrider7374 I agree with you. I don't know why google engineers cannot develop language which developers gonna like;

@avi12 Жыл бұрын

1:28 I'm wondering why Google Earth is not listed

@SamSiah-tn5pb 4 ай бұрын

@Thank you sir ☺️🙏🏻🇮🇩

@d-o-n-u-t Жыл бұрын

I think the biggest thing holding WASM back is its reliance on the JS namespace to access and manipulate the DOM. If there were some way to do it natively, without having to call into JS, I think WASM could be much bigger, and much faster. Interfacing from WASM to JS to the JS engine to the UI takes time - would be nice if there was some API exposed that let you skip the middleman.

@walrider7374 Жыл бұрын

JS needs to die, it has been a needed evil for far too long

@Yous0147 Жыл бұрын

This is the one thing I want from WASM. Being able to interact with the DOM would be a gamechanger for sure, and I genuinely hope it's in the works.

@thomasnattestad2450 Жыл бұрын

We actually looked heavily into this and you might be surprised to hear that the interface from JS to wasm is not heavily impacting performance. The only thing that really takes time is converting from linear memory into strings for API calls and this is going away with the new stringRef proposal. JS isn't slowing down wasm.

@Yous0147 Жыл бұрын

@@thomasnattestad2450 That's good to know but I think the real reason most people want a direct API is moreso because they want to skip that glue code setup and use whatever language WASM supports to manipulate the DOM directly. The added bonus if that is that you then won't need to cross communicate between languages which on all accounts would be simpler and faster.

@thomasnattestad2450 Жыл бұрын

@@Yous0147 Yeah, I definitely appreciate that the glue code can be cumbersome to set up. We've considered devtools / tooling changes to hide that more but it's a tough decision since sometimes you will want to debug those connections. The performance impact of communication between languages is the part that should be removed with stringRef (at least for string based API calls, which is most web APIs)

@mrmoon18 Жыл бұрын

Nice Pingu at the end!

@bashorov Жыл бұрын

If you have any questions about Kotlin/Wasm or Wasm GC, don't hesitate to ask below.

@jakerunzer Жыл бұрын

Is there any information on when Wasm GC will be available? Or how to use it currently? Also, how will Wasm GC work in non-browser environments such as wasmtime? It looks awesome though! Looking forward to using it :D

@bashorov Жыл бұрын

@@jakerunzer standalone VMs, like wasmtime and WasmEdge recently started implementing GC proposal

@LEDsellers Жыл бұрын

If there any possibility that a JS codebase (client side) can be compiled to WASM and be run on the desktop as an alternative to electron? Would this JS compiled wasm app be multithreaded and no longer be single threaded?

@adsick_ua Жыл бұрын

Hello, what does Wasm GC means for languages that do not use GC? like Rust for example. Will it improve memory management and perf of calling into DOM/WebGPU?

@bashorov Жыл бұрын

@@adsick_ua those languages can continue using linear memory and ignore new things introduced by GC proposal. The proposal will not help with memory management nor browser APIs. They can use reference types to simplify interop with an external world, maybe it will help a bit with some runtime overheads.

@guai9632 11 ай бұрын

I want wasm everywhere. an os with wasm as first-class or even only way to distribute software would be great.

@nested9301 Жыл бұрын

What is the best language to choose for wasm ? Also i hope that the react ecosystem and architecture are not forgotten

@kenneth_romero Жыл бұрын

currently I think Rust has the best support, but Rust is a tough language to learn. Kotlin is pretty nice since you can also code for Android and Apple within the same code. But any language you are comfortable in that is able to compile into web assembly is all you need. Though I heard debugging webassembly is still pretty tough and the debugging tools are not that fleshed out yet.

@justmichael1 Жыл бұрын

webp-hero does not use WASM as per their documentation on npmjs

@thats-no-moon Жыл бұрын

This is wild

@activewire-web5710 7 ай бұрын

Why Rust was not mentioned?

@_sonatard2568 Жыл бұрын

How does WebAssembly render UI in Chrome?

@alexander3293 Жыл бұрын

by using javascript

@farrellraafi1301 Жыл бұрын

@@alexander3293 or using canvas

@alexander3293 Жыл бұрын

@@farrellraafi1301 yes but its sill using javascript wrappers that call into the canvas api

@mehoprelivoda Жыл бұрын

its not

@juan-ramonsanchis-alberich2509 8 ай бұрын

EXCELLENT PRESENTATON. VERY VALUABLE. CONGRATS.

@krishanakumar490 Жыл бұрын

Can I use your videos on my KZfaq channel if I want.

@IlyaIzr Жыл бұрын

So, if you're web dev - you might get new faster libraries If you're not web dev - you can extend your app to the web via WA

@rammrras9683 Жыл бұрын

I don't understand if the end result is HTML or just a cavans rendered ?

@HybridLizard_com Жыл бұрын

In short it is about fast data computation. What data you compute is up to you and you can exchange it with JS code e.g. to render on canvas, but also to handle some data not related to graphics processing. It is not about DOM manipulation (html elements, its attributes etc.)

@FlutterShipp 3 ай бұрын

❤‍🔥❤‍🔥❤‍🔥❤‍🔥

@hasiiblive 19 күн бұрын

informative

@DinoFancellu Жыл бұрын

What's the status of Java+WASM?

@wuxxy Жыл бұрын

Why would anyone want to use Java in 2023?

@cryMoreLoL Жыл бұрын

@@wuxxy Seriously! The only reason why it still exists is because of legacy code. No one is thinking "I'm going to built this new app in Java!" Kotlin would make more sense, but Java? 🤦‍♂

@walrider7374 Жыл бұрын

Java?

@hetaeramancer 9 ай бұрын

kotlin is not a superset of java, you can be perfectly fine with using java wherever you use kotlin @@cryMoreLoL

@bernardosoccal1981 Жыл бұрын

Blazor hype!

@DavidAlsh Жыл бұрын

Would love it if threads were not restricted to same-origin opener and embedder applications as that basically disables any capacity for third party integrations - plus you can't add those headers easily with simple web infrastructure like an S3 website, GitHub pages site - etc Looking forward to the day I can write my application entirely in Rust and not thunk everything through JavaScript!

@jobiej7416 Жыл бұрын

Kmm on the web is interesting.

@gzoechi Жыл бұрын

Rust works great with WASM in the browser (and backend)

@amlivinginhell 11 ай бұрын

can you share few examples of this?

@davidlearnforus Жыл бұрын

I know its difficult but please someone use this for python web

@Vardiak Жыл бұрын

"with no store getting in the way, and no revenue split affecting your profitability" 21:30 🤔

@zohaib9381 Жыл бұрын

bro forgot he works for the company taking that split

@GillyTech 10 ай бұрын

Presentations like this make me feel like Google has a box of generic developers they can Mr. Potato Head up and put in front of a camera and read the script. As genuine as a car salesman.

@autohmae 10 ай бұрын

In the current age, you have to wonder: is it AI-generated ?

@klafbang Жыл бұрын

Very cool. You've invented Java applets.

@wickedtorpedo75 7 ай бұрын

кто шарит будь добры скажите пожалуйста (я чет особо не хочу углублять в эту тему просто зашел сюда не на роком), если коммпилированный код flutter/kotlin на web assembly в 2 раза быстрее чем компиляция на js (16:13) то почему вообще компилировать код на js, почему все компилирует на js или есть подводные камни (необходимость переписать в какой то части код)?

@laughingvampire7555 Жыл бұрын

is this the famous Thom who made JDSL?

@bababert8488 Жыл бұрын

The places where JavaScript isn't sufficient? So everywhere

@ck_naik Жыл бұрын

They talked about rust c c++ even Swift but not c# 😅 shows how much they hate. Hopefully it will change

@thomasnattestad2450 Жыл бұрын

We love C# and Blazor! We work actively with that team and they have a great experience. Honestly the only reason we didn't cover it is because the team does a killer job already with talks and documentation

@ck_naik Жыл бұрын

@@thomasnattestad2450 But still you should mention them atleast once

@thomasnattestad2450 Жыл бұрын

@@ck_naik I do mention that there are many other languages adding support. In an earlier draft I did rattle off the languages but there were just so many and I felt guilty leaving any single one out so I went with the generic coverage. Fair complaint tho :)

@ck_naik Жыл бұрын

@@thomasnattestad2450 thanks 🙏 Great talk though

@Ahmarth Жыл бұрын

Uff, doing Rust dirty, saying it cannot keep track of its own memory :D

@dmitriidemenev5258 Жыл бұрын

You do .forget() because you transfer ownership of closure to JavaScript engine.

@nested9301 Жыл бұрын

See u 15years later when wasm will be production readyy

@melveric1 Жыл бұрын

The language about managing memory is quite misleading, but this video is about advertising that google‘s runtime memory managed languages finally work in Washington too, so this must be assumed.