21–30 of 100 posts
The real value in Wasm is in the Web use case: bring to the most popular platform software that was impossible (or very difficult) to bring before. Just look at Ruffle (Flash Player reimplementation), V86 (x86 virtual machine), Google Earth, ... Wasm on the Server is a fad, and sadly it's hijacking resources and design space from the real thing. WASI being a prime example: because of the "Component model", any attemp…
Web Assembly has (at least in the past) a business problem. In the past in nearly all prior discussions on this the greatest proponents for Web Assembly were developers who wanted to bring their technologies into the browser because they hate JavaScript. That is a horrible business case that is more effort than any value returned and no user will ever care about. Worse, it won't ever work if you intended it to be a J…
Why would someone use this for desktop applications if you aren't obligated to target a web browser? The only benefit this brings is access to browser rendering, which is a pretty terrible desktop experience (see e.g. slack, spotify).
In some situations it is harder to support different desktop builds and this might unify that.
I don't think it is the strongest argument but at least on the margins it is an option I can see teams in some places choosing.
Web Assembly has (at least in the past) a business problem. In the past in nearly all prior discussions on this the greatest proponents for Web Assembly were developers who wanted to bring their technologies into the browser because they hate JavaScript. That is a horrible business case that is more effort than any value returned and no user will ever care about. Worse, it won't ever work if you intended it to be a J…
Why would someone use this for desktop applications if you aren't obligated to target a web browser? The only benefit this brings is access to browser rendering, which is a pretty terrible desktop experience (see e.g. slack, spotify).
Web Assembly has (at least in the past) a business problem. In the past in nearly all prior discussions on this the greatest proponents for Web Assembly were developers who wanted to bring their technologies into the browser because they hate JavaScript. That is a horrible business case that is more effort than any value returned and no user will ever care about. Worse, it won't ever work if you intended it to be a J…
Why would someone use this for desktop applications if you aren't obligated to target a web browser? The only benefit this brings is access to browser rendering, which is a pretty terrible desktop experience (see e.g. slack, spotify).
The real value in Wasm is in the Web use case: bring to the most popular platform software that was impossible (or very difficult) to bring before. Just look at Ruffle (Flash Player reimplementation), V86 (x86 virtual machine), Google Earth, ... Wasm on the Server is a fad, and sadly it's hijacking resources and design space from the real thing. WASI being a prime example: because of the "Component model", any attemp…
I have high hopes for wasm on the desktop for app plugins. Loading a whole binary DLL/SO is such a risk. VMs like Lua don't give you enough performance. VMs like Python and Java require huge effort to embed. Once the SIMD stuff is in, it may even have enough performance for music plugins. wasm codecs would be real cool too. Nobody likes having to build and install ffmpeg. `ffmpeg-4.0.wasm`... just imagine.
As a (backend) Java dev, I couldn't let that stand. And indeed I found out java now offers a tool called jlink with first class support, that will create a system native (e.g. .dmg on my macbook) executable with the JRE embedded. The javafx example project* I found could be downloaded, built and run from its native release all within less than 5 minutes.
Mind you the Hello World example executable is 80mb and takes 6 seconds to start, but I feel like with the garbage we are used to in regards to desktop applications, this totally holds up -doesn't everything else usually bundle all of chrome? I have also read there are simple command line options to reduce the size to about 50mb.
Earlier quoted context omitted.
Why would someone use this for desktop applications if you aren't obligated to target a web browser? The only benefit this brings is access to browser rendering, which is a pretty terrible desktop experience (see e.g. slack, spotify).
Slack is terrible? In what sense?
Earlier quoted context omitted.
Why would someone use this for desktop applications if you aren't obligated to target a web browser? The only benefit this brings is access to browser rendering, which is a pretty terrible desktop experience (see e.g. slack, spotify).
Not sure why you claim it's a "terrible desktop experience"? What's wrong with it, please explain.
Web Assembly has (at least in the past) a business problem. In the past in nearly all prior discussions on this the greatest proponents for Web Assembly were developers who wanted to bring their technologies into the browser because they hate JavaScript. That is a horrible business case that is more effort than any value returned and no user will ever care about. Worse, it won't ever work if you intended it to be a J…
That is a pretty bold statement considering that Blazor actually does allow you to ditch JavaScript and very much integrates with the surrounding page.
It is true that for manipulating the DOM, Blazor internally needs to go through JavaScript as there are no direct WASM-to-DOM binding (yet).
But you, as a developer, can develop sites that runs its interactivity using webassembly instead of Javascript.
The real value in Wasm is in the Web use case: bring to the most popular platform software that was impossible (or very difficult) to bring before. Just look at Ruffle (Flash Player reimplementation), V86 (x86 virtual machine), Google Earth, ... Wasm on the Server is a fad, and sadly it's hijacking resources and design space from the real thing. WASI being a prime example: because of the "Component model", any attemp…
Running FFMPEG in the browser through WASM is a game changer for me.
Earlier quoted context omitted.
Why would someone use this for desktop applications if you aren't obligated to target a web browser? The only benefit this brings is access to browser rendering, which is a pretty terrible desktop experience (see e.g. slack, spotify).
Portability? In some situations it is harder to support different desktop builds and this might unify that. I don't think it is the strongest argument but at least on the margins it is an option I can see teams in some places choosing.
Granted, at least the browser code uses native widgets, but the look/feel and layout still tend to be way off.