Conversation

Notices

1. Embed this notice
   smallcircles (Humanity Now 🕊) (smallcircles@social.coop)'s status on Tuesday, 29-Aug-2023 22:38:04 JST smallcircles (Humanity Now 🕊)

   Running WASI binaries from your HTML using Web Components

   https://runno.dev/articles/wasi-web-component

   https://news.ycombinator.com/item?id=37287339

   #WebAssembly #WASI #WebComponents

   • Embed this notice
     tyil (tyil@fedi.tyil.nl)'s status on Tuesday, 29-Aug-2023 22:37:59 JST tyil

     in reply to

     @smallcircles@social.coop With other piles of obfuscated and resource-intensive JS, so compared to what we've had before trying to port everything to JS, still a major step backwards. The solution is to stop trying to force everything in a browser through a horribly designed system, not to force it in through different means.

     翠星石 likes this.
   • Embed this notice
     smallcircles (Humanity Now 🕊) (smallcircles@social.coop)'s status on Tuesday, 29-Aug-2023 22:38:00 JST smallcircles (Humanity Now 🕊)

     in reply to

     • tyil

     @tyil depends, I think. What this replaces in terms of functionality is piles and piles of obfuscated JS.

   • Embed this notice
     tyil (tyil@fedi.tyil.nl)'s status on Tuesday, 29-Aug-2023 22:38:03 JST tyil

     in reply to

     @smallcircles@social.coop Horrid 😨

   • Embed this notice
     tyil (tyil@fedi.tyil.nl)'s status on Tuesday, 29-Aug-2023 22:38:11 JST tyil

     in reply to

     @smallcircles@social.coop "local-first" but with a thick added layer of tracking and ads. I don't consider anything done in a browser as being "local-first" in any sense of the word. Local first means it runs locally, without needing any outside resources. Webbrowsers oppose that concept at every step of the way. Let's not pretend any of the WASM stuff is intended to be an upgrade for the users to give them more control.

     翠星石 likes this.
   • Embed this notice
     smallcircles (Humanity Now 🕊) (smallcircles@social.coop)'s status on Tuesday, 29-Aug-2023 22:38:12 JST smallcircles (Humanity Now 🕊)

     in reply to

     • tyil

     @tyil most browsers have native and efficient impls of the webassembly standard now. There's no transpiling into different JS, and both speed and size improvements made. If you have resource-intensive part of your web-app just implement in C, Rust or other supported language.

     In terms of cramming everything in the browser I wholly agree: Please don't. Though I think with Wasm/WASI we get closer to a paradigm where we can ditch the browser. More local-first stuff, polyglot development, etc.

   • Embed this notice
     tyil (tyil@fedi.tyil.nl)'s status on Tuesday, 29-Aug-2023 22:38:40 JST tyil

     in reply to

     @smallcircles@social.coop In theory, yes. And as I said, let's not pretend here. The theory is not used much when you look at the use of the web. Most of it is just badly implemented garbage covered in a layer of tracking and ads. WASM won't change this. Making more bad stuff in WASM won't change this. Giving incredibly low-quality devs more tools to design horrible experiences is not the way forward.
     
     WASM is interesting as a concept, but blindly cramming stuff into WASM and saying "it's an improvement!" is just lying to yourself. We already have a "local-first" ffmpeg, its called ffmpeg. Making it less convenient to run and optimize by running it in a browser is not an improvement.
     
     I wish I could agree with "its just a tech choice to have ads", but the amount of addons and customization I need to avoid it is insane to a "normal" user.

     翠星石 likes this.
   • Embed this notice
     smallcircles (Humanity Now 🕊) (smallcircles@social.coop)'s status on Tuesday, 29-Aug-2023 22:38:42 JST smallcircles (Humanity Now 🕊)

     in reply to

     • tyil

     @tyil the second part of my last toot was about not needing the browser or have it as a separate/secondary option for a UI. Whether there's tracking and ads depends on what you are using, not on this technology choice.

   • Embed this notice
     tyil (tyil@fedi.tyil.nl)'s status on Tuesday, 29-Aug-2023 22:38:54 JST tyil

     in reply to

     @smallcircles@social.coop But that is the use case of this "new" technology. It's going a step backwards so it can become less local so it can be crammed into more user-hostile environments. That's the entire end-goal of WASM. We already have a local-first environment where we can run local-first applications in the way the user desires, and it's not in the web-browser.
     
     I'm "bringing things into the discussion" because they are relevant but conveniently ignored. Cramming ffmpeg in your browser through a convoluted process which introduces just more obfuscation and makes it much harder to control is not a step forward. Pretending it is will not lead to a better future.

     翠星石 likes this.
   • Embed this notice
     smallcircles (Humanity Now 🕊) (smallcircles@social.coop)'s status on Tuesday, 29-Aug-2023 22:38:55 JST smallcircles (Humanity Now 🕊)

     in reply to

     • tyil

     @tyil I agree with most of what you say and am just as critical as you about the malign forces exerted by hypercapitalism.

     But you bring in things in the discussion I never mentioned and aren't AFAIK in the (experimental) project I shared. One can cram ads and malware into anything and be as capitalistically evil as they want. That is deplorable if that happens. But it is a different discussion than "hey, look at this use case of this new technology".

   • Embed this notice
     tyil (tyil@fedi.tyil.nl)'s status on Tuesday, 29-Aug-2023 22:39:06 JST tyil

     in reply to

     @smallcircles@social.coop And how is this an improvement over just apt install ffmpeg and using an actual local-first variant?
     
     Do I get better performance through that entire mess of of buzzwords? Can I magically run it on devices that aren't supported by ffmpeg (which supports more architectures than most browsers last I checked)?
     
     All I see is making things more complex just to get back to a point we already were ages ago, but now I need 64gb of RAM and a 12-core CPU to get there.

     翠星石 likes this.
   • Embed this notice
     smallcircles (Humanity Now 🕊) (smallcircles@social.coop)'s status on Tuesday, 29-Aug-2023 22:39:07 JST smallcircles (Humanity Now 🕊)

     in reply to

     • tyil

     @tyil this application is actually a combination of 2 ways in which wasm is used. Traditionally it focused on the browser, but recently used also as "edge-based" technology and WASI is part of that.

     On the edge means that you can compile the code to run anywhere without having to worry about the infra + architecture. On mobile, IoT, server, browser, cloud, etc.

     Here it offers standards-based component-oriented, contract-first (WASI standardizes IDL interfaces), sandboxed, polyglot development.

   • Embed this notice
     tyil (tyil@fedi.tyil.nl)'s status on Tuesday, 29-Aug-2023 22:39:26 JST tyil

     in reply to

     @smallcircles@social.coop But if you had a codebase that uses e.g. Redis and an AWS object store,I didn't have a local-first application in this situation to begin with, so we're already off to a terrible start. You're right that this "new tech" is an improvement over the absolute worst state of garbage we have, but setting that as the baseline is simply disingenuous to me. Rather than lowering the barrier so we can pretend everything is an improvement, I'd suggest we stop pretending atrocious development practices are good and start calling them out on it. Better yet: stop using it when you can!And your builds need not worry about all the different processor architectures.But anything implementing WASM still needs to, and those builds will get more complex. You're not "fixing" the complexity, you're shifting it outside your viewpoint.Performance is near-native. Wasm is low-level stuff.This is marketing speech for "performance is worse". Keep doing cycles of getting "near" the thing we already have, and with time your performance is just absolutely atrocious. #Javascript is littered with things that get "near" to what we want, and what we've gotten is piles and piles of badly performing garbage requiring me to use several gigabytes of ram just for my browser to read documentation for my #day-job.

     翠星石 likes this.
   • Embed this notice
     smallcircles (Humanity Now 🕊) (smallcircles@social.coop)'s status on Tuesday, 29-Aug-2023 22:39:28 JST smallcircles (Humanity Now 🕊)

     in reply to

     • tyil

     @tyil dunno about ffmpeg.

     But if you had a codebase that uses e.g. Redis and an AWS object store, in the WASI situation these are replaced by a keyvalue and blobstore standardized interface. And when your wasm component moves from the cloud to your local pc the implementation of these interface may dynamically switch to an in-memory KV store and the filesystem.

     And your builds need not worry about all the different processor architectures.

     Performance is near-native. Wasm is low-level stuff.