@@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? 😂
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...
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.
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.
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.
@@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.
@@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)
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
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?
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?
@@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.
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.
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.
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
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.
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.
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!
@@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? 🤦♂
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 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 :)
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.)
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.
кто шарит будь добры скажите пожалуйста (я чет особо не хочу углублять в эту тему просто зашел сюда не на роком), если коммпилированный код flutter/kotlin на web assembly в 2 раза быстрее чем компиляция на js (16:13) то почему вообще компилировать код на js, почему все компилирует на js или есть подводные камни (необходимость переписать в какой то части код)?
Want to learn more about what's new for the web? Check out the Web Keynote at #GoolgeIO → goo.gle/IO23_webkey_pin
Ahh, Wasm and JS will share memory. It would be good hear more about how race conditions are avoided.
Just write a good code and race conditions will be avoided
@@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? 😂
@@Joshua-dc4un a man can only dream... Anyways, let's wait for LLMs to replace low level programming in a few years
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...
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.
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.
JS needs to die, it has been a needed evil for far too long
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.
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.
@@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.
@@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)
If you have any questions about Kotlin/Wasm or Wasm GC, don't hesitate to ask below.
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
@@jakerunzer standalone VMs, like wasmtime and WasmEdge recently started implementing GC proposal
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?
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?
@@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.
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.
I agree that Google should decide about the better long-term option, and continue investing in it. It should be Compose imho.
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.
For me, more options are better
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
@@walrider7374 I agree with you. I don't know why google engineers cannot develop language which developers gonna like;
@Thank you sir ☺️🙏🏻🇮🇩
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
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
In C# Blazor webassembly its the fourth year you dont need it
What is the best language to choose for wasm ? Also i hope that the react ecosystem and architecture are not forgotten
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.
Truly amazing!
Rust works great with WASM in the browser (and backend)
can you share few examples of this?
❤🔥❤🔥❤🔥❤🔥
I want wasm everywhere. an os with wasm as first-class or even only way to distribute software would be great.
"with no store getting in the way, and no revenue split affecting your profitability" 21:30 🤔
bro forgot he works for the company taking that split
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.
In the current age, you have to wonder: is it AI-generated ?
Nice Pingu at the end!
Blazor hype!
EXCELLENT PRESENTATON. VERY VALUABLE. CONGRATS.
This is wild
1:28 I'm wondering why Google Earth is not listed
is wasm used only to compile codes from other languages to wasm?
Why Rust was not mentioned?
Is webassembly supported in android system webview? and other mobile platform webview? like flutter webview and android webview devtool
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!
webp-hero does not use WASM as per their documentation on npmjs
Very cool. You've invented Java applets.
What's the status of Java+WASM?
Why would anyone want to use Java in 2023?
@@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? 🤦♂
Java?
kotlin is not a superset of java, you can be perfectly fine with using java wherever you use kotlin @@cryMoreLoL
Can I use your videos on my RUclips channel if I want.
Kmm on the web is interesting.
They talked about rust c c++ even Swift but not c# 😅 shows how much they hate. Hopefully it will change
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
@@thomasnattestad2450 But still you should mention them atleast once
@@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 :)
@@thomasnattestad2450 thanks 🙏 Great talk though
I don't understand if the end result is HTML or just a cavans rendered ?
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.)
is this the famous Thom who made JDSL?
The places where JavaScript isn't sufficient? So everywhere
Uff, doing Rust dirty, saying it cannot keep track of its own memory :D
You do .forget() because you transfer ownership of closure to JavaScript engine.
I know its difficult but please someone use this for python web
Jetpack compose on web… dies of canvas 💀. This is flutter all over again
See u 15years later when wasm will be production readyy
Ahhh leave it to these yoyos to bring in those crap bloated languages to WASM, there's a reason C++/C is used to do all the real stuff....
I’m only upvoting this because of the term “yo-yo” cracked me up.
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.
How does WebAssembly render UI in Chrome?
by using javascript
@@alexander3293 or using canvas
@@farrellraafi1301 yes but its sill using javascript wrappers that call into the canvas api
its not
кто шарит будь добры скажите пожалуйста (я чет особо не хочу углублять в эту тему просто зашел сюда не на роком), если коммпилированный код flutter/kotlin на web assembly в 2 раза быстрее чем компиляция на js (16:13) то почему вообще компилировать код на js, почему все компилирует на js или есть подводные камни (необходимость переписать в какой то части код)?
seriously???? C++ instead of Rust? byyyyeeee
Whoever said that Rust is an Alloc/free language has no clue about the borrow checker.
👀 bye bye JS 😢
👀 bye bye JS 😁
yeah, I'm listening this for 5 years.... it was always about community, frameworks, libraries, exampels, tutorials, never about technology itself
@@DJenriqez I mostly agree but in this case I think it it's also about the technology.
can’t JS also now compile to WA?
@@LEDsellers I believe so, that's right 🙌🏻
EggheadAssembly