Anybody knows if this will reduce the first download sizes for flutter web?
It has a lot of limitations, currently, but you may get your app working if you don't use native plugins. Let us know if you manage to get it working.
81–88 of 88 posts
Anybody knows if this will reduce the first download sizes for flutter web?
It has a lot of limitations, currently, but you may get your app working if you don't use native plugins. Let us know if you manage to get it working.
A few days I published a small game built using WASM GC. As far as I know it's among the first. It's a retro vertical scrolling space shooter called Strigoform[0]. It is written in Scheme, the language that Netscape almost put in the browser back in 1995, using the Guile Hoot[1] compiler. If you have the new Chrome it should just work. You can also use Firefox Nightly. Does not work on mobile at the moment as I didn'…
I like using apps on web, like Figma ..etc, no download or update manager, just open an URL. But currently these apps just don't have the fluidity, that's there with native apps, also maintaining large JS codebase is horrible, Typescript doesn't help much in my opinion. WebGPU + new development languages, will hopefully send web-apps to the next level.
Unless you enjoy trying to make up what 3D rendering calls belong to the browser, and which ones belong to the actual application.
Finally, Java arrives to our browsers! Maybe we could use it to write some small applications with it, let's call them "applets".
I don't know, this time around there has been much more focus on security which was really what spelled doom for Flash/Java. That and it's actually included as part of web standards instead of being something that users have to download and update separately. I doubt that GC would have been added at all except that it's a requirement to speedup and simplify the boundary between the browser and WASM.
Earlier quoted context omitted.
Yes, but it's important to think about the bridge/shim between your application code (the web assembly module) and the host (the browser). If you have a C++ game which draws to the screen with SDL, then you can use a shim to convert SDL calls into html canvas calls [1]. But if a backend engineer wants to compile their java swing application to web assembly, there is a larger impedance mismatch from Java Swing => reac…
For games canvas is fine. There is no 'web native ui' people expect. I really don't think the use of this is running existing Java swing applications on the web. Maybe a bit of a hack for legacy software, but it's really using Java instead of Javascript, but using the normal DOM/HTML.
* user "menaerus" goal is have "C/C++/Rust developer [...] expose your product as a browser service", which they can transpile to wasm - cool.
* they will need "a bit of JavaScript you integrate it into the end service" - UI targets the DOM, sounds great.
The questions become:
* how much code will need to be written into each layer (rust wasm, react html ui, bridge between the 2)?
* what level of experience with that tech will you need todo that? ie: writing a react ui which interfaces with a wasm shim is some non-trivial javascript to say the least.
* based on the above: how far has wasm enabled a "c/c++/rust developer" to easily port their application to the web without also being a super strong frontend developer?
I'm trying to draw a contrast between:
A) I have business logic which is not well suited for javascript (image processing on binary data, figma, etc), and I have rust/c++ developers AND javascript frontend developers to build the application
B) I am a rust/c++ developer who wants to target the web with their rust/c++ product, but doesn't want to dive deep into frontend/js/react tech.
In the long term, I am optimistic that scenarios like "B" will be opened up by application (web) frameworks which target wasm via backend technologies and their MVC patterns. But in the short term, the amount of "glue code" to be written is non-trivial.
Earlier quoted context omitted.
It would be cool if there was a wasm package manager that you could use from any language, and each lib could autogen interfaces in the language that you're working in
Ugh, last thing we need is yet another security nightmar--I mean package manager.
I guess wasm is essentially trying to be a dynamic c library without being requiring OS specific binaries and being written in languages other than C
This starts to open a lot of very interesting new doors for web development in general. JavaScript is suddenly no longer the only real game in town it seems. I mean sure WASM has allowed C, C++ and Rust to run on the web for awhile now but they aren’t typically languages that web developers tend to have a lot of knowledge of or interest in learning. But Dart, Kotlin and Java for example, they very much are viable rep…
[1] https://www.clojure.org/news/2011/07/22/introducing-clojures...
This starts to open a lot of very interesting new doors for web development in general. JavaScript is suddenly no longer the only real game in town it seems. I mean sure WASM has allowed C, C++ and Rust to run on the web for awhile now but they aren’t typically languages that web developers tend to have a lot of knowledge of or interest in learning. But Dart, Kotlin and Java for example, they very much are viable rep…
Kotiin already compiles to JavaScript, but to my understanding it has seen limited use in browsers. So why would people use it to target wasm if they don't already use it to target JS?
Notice the footprint is very small (3k for an hello world).