Hacker News new | ask | show | jobs
by WhereIsTheTruth 334 days ago
WASM is not a web scripting language

Trying to shoehorn Rust as a web scripting language was your second mistake

Your first mistake was to mix Rust, TypeScript and JavaScript only just to add logic to your HTML buttons

I swear, things get worse every day on this planet

3 comments

WASM enables things like running a 20 year old CAD engine written in C++ in the browser. It isn’t a scripting language, it’s a way to get high-performing native code into web apps with a sensible bridge to the JS engine. It gets us closer to the web as the universal platform.
The biggest problem solved by WASM is runtime portability. For security reasons many users and organizations will not download or install untrusted binaries. WASM provides a safer alternative in an often temporary way. The universal nature is an unintended byproduct of a naive sandbox, though still wonderful.
Why would WASM be any less secure than JavaScript?
It's not, they're saying it's a safer alternative to traditional binaries
Exactly, and the CAD engine doesn't need to know about nor access the DOM

> It gets us closer to the web as the universal platform.

As a target

I don't want a pseudo 'universal' platform owned by Big Tech; or by governments as a substitute

Google/Chrome controlled platform, no thanks

https://i.imgur.com/WfXEKSf.jpeg

So what should they have used to share logic between backend and frontend in a type safe way?
If the logic is compute heavy, Rust with Wasm can be a good approach. TypeScript on both ends is also a pragmatic choice. You can still have a boundary in the backend for lower level layers in Rust.

If the logic is merely about validation, then an IDL with codegen for TS and some backend language is probably better. There are also some more advanced languages targeting transpilation to both JS and a backend language such as Haxe, but they all have some trade-offs.

Actually, WASM will enable many languages better for web scripting than Javascript.
WASM certainly had the potential for this, but I am afraid without direct DOM access it is never going to happen.
It is happening. Leptos is an example: https://www.leptos.dev/

Dioxus is another: https://dioxuslabs.com/

C# with Avalonia for a different use case: https://avaloniaui.net/

Avalonia solitaire demo: https://solitaire.xaml.live/

Avalonia Visual Basic 6 clone: https://bandysc.github.io/AvaloniaVisualBasic6/

Blazor can run as WebAssembly on the client side if you choose that runtime mode: https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blaz...

Beyond the browser, Wasmer does WebAssembly on the serverside: https://wasmer.io/

Fermyon too: https://www.fermyon.com/

Extism is a framework for an application to support WebAssembly plugins: https://extism.org/

Btw there is also Dominator: https://github.com/Pauan/rust-dominator
how'd you compare dioxus and leptos?
If you're familiar with JS frameworks, you can think of it like this:

Dioxus : React :: Leptos : SolidJS

The key for me is that Leptos leans into a JSX-like templating syntax as opposed to Dioxus's H-like function calls. So, Leptos is a bit more readable in my opinion, but that probably stems from my web dev background.

The Dioxus README has a whole section comparing them -- https://github.com/DioxusLabs/dioxus#dioxus-vs-leptos

Not parent but GP: Love Leptos, I think they are on the right track. Dioxus is good too, I think it has wider scope and they also obtained funding from external sources while Leptos is completely volunteer based.