For the record Dart has something extremely similar to the Closure compiler built with the same ideas and similar performance AFAIK.
It’s totally fine, impressive even and currently runs the code producing the majority of their revenue via Ads which is all Dart.
But they also recognise (same with Google’s Java teams) that as the platform landscape is changing WASM with garbage collection should be the “next generation” of compile targets for the web for those languages for performance reasons. Both Java and Dart teams already have compilers ready to go once WasmGC is finalised and both of those teams are heavily involved in the standards team driving the broader effort.
I saw some hints at I/O about them building something called “managed languages” into the browser that covered both Dart and Java as well which seems to build on top of that.
I think this has some broader implications for the JS community as a whole for what it’s worth where “compile to JS” is no longer the only game in town in the near future.
As for WebGPU I don’t know enough about the internals to get real deep on the topic but they already have all those problems today but just with WebGL. This too as I understand things is just the “next generation” target for that code.
They (Flutter team) are also rewriting their entire shader pipeline engine from scratch as we speak to take advantage of everything they have learned to date.
In short, I believe them when they say it’s going to be fast and like native.
Edit: I missed your point initially about they could use WASM today. They do that also for parts of the code already (underlying graphics engine is C++ not Dart) but this allows them to move all of the Dart code to WASM now too.
It’s totally fine, impressive even and currently runs the code producing the majority of their revenue via Ads which is all Dart.
But they also recognise (same with Google’s Java teams) that as the platform landscape is changing WASM with garbage collection should be the “next generation” of compile targets for the web for those languages for performance reasons. Both Java and Dart teams already have compilers ready to go once WasmGC is finalised and both of those teams are heavily involved in the standards team driving the broader effort.
I saw some hints at I/O about them building something called “managed languages” into the browser that covered both Dart and Java as well which seems to build on top of that.
I think this has some broader implications for the JS community as a whole for what it’s worth where “compile to JS” is no longer the only game in town in the near future.
As for WebGPU I don’t know enough about the internals to get real deep on the topic but they already have all those problems today but just with WebGL. This too as I understand things is just the “next generation” target for that code.
They (Flutter team) are also rewriting their entire shader pipeline engine from scratch as we speak to take advantage of everything they have learned to date.
In short, I believe them when they say it’s going to be fast and like native.
Edit: I missed your point initially about they could use WASM today. They do that also for parts of the code already (underlying graphics engine is C++ not Dart) but this allows them to move all of the Dart code to WASM now too.