Microsoft's support for WASI has been pretty slow. Wasm isn't just for the browser - it came from there but with WASI, Wasm has the opportunity to run just about anywhere, even more portable than .NET Core.

MSFT's interest in making a wasm profile has been somewhat lacking and I understand the reason - the size I managed to achieve would've been impossible if I went with the full BCL / CoreLib. In particular, I had to cut reflection and typenames, keeping only thin RTTI.

So yes to staying as close to the latest C# language features but also deliberately not supporting features that bloat the resulting wasm if there's better and more modern alternatives such as source generation in place of reflection.

A clean Release application containing Console.WriteLine(42) produces 82.5 KB of final WASM with WASI p2, including the runtime and precise garbage collector.

Website: https://www.netwasm.com/ Playground: https://playground.netwasm.com/

The playground runs fully on the browser without a backend / cloud server compiling your code - it's all WASM! Locally, you use dotnet new, dotnet build, dotnet test, etc like you would normally. You can run the self-contained .wasm output with wasmtime, fully portable.

GitHub repos: https://github.com/zion-sati/NetWasm https://github.com/zion-sati/NetWasm.Libraries

What is it?

It's CIL (used to be called MSIL - it's the dotnet bytecode in other words) to WASM compiler. But more than that it's intentionally not using Microsoft's Corelib. We avoid reflection, typename with full namespace strings etc where the resulting .wasm can end up bloated. The goal is to have C# (and later .NET in general - thus F# and VB.NET) be on equal footing as Kotlin/WASM. Note that Kotlin/WASM uses WasmGC, NetWasm uses BoehmGC in precise mode. NetWasm makes Wasm a first class target.

Why NetWasm?

I fell in love with C# in 2006 and have OSS attempts at building C#-like syntax using C++ template metaprogramming with BoehmGC a long time ago because I didn't like the idea of having a runtime pre-installed. This idea was revitalized when I tried to migrate my web UI framework FUI-RS to C# - the resulting smoke test was already a minimum of 1 MB Brotli compressed running in interpreter mode! FUI-RS (Rust) had it at under 50 KB uncompressed. What already works?

C# 15, precise GC, finalization, exceptions, generics, virtual/interface dispatch, LINQ, tasks / value tasks (thus async-await), JSON, dependency injection, regex, XML, HTTP, WIT/WASI and TUnit (a modern source generated unit testing framework) etc.

What's left to do?

There's a roadmap to v1.0 on the repo's README - tl;dr there's a lot to do before we can get there, e.g. Expression trees, faster dev loops, threading, web workers, interop via libimport and globalization (opt-in just like NetWasm's implementation of timezone info).

NuGet packages should be able to multitarget to support NetWasm as well as the full .NET as long as there's no reflection / typename involved.

Licence: Runtime, CoreLib, templates and libraries: MIT Compiler and tooling: NetWasm Community License

Note that NetWasm is pre-1.0 (currently v0.5) and evolving rapidly, so I'd appreciate any technical feedbacks from the community if you'd like to help me shape this project. Particularly, real WASI use cases people want supported, NuGet packages to multitarget (or even better if you're one of the popular open source packages and would like to start multitargeting).

Comments URL: https://news.ycombinator.com/item?id=49892613

Points: 6

# Comments: 4

My point around ts is people want strongly typed languages these days.

The bigger problem with HTML/CSS is, when you're trying to do more sophisticated things (see the immediate drawing page on the demo), you'll find you need to use a canvas/HTML5. That then becomes a mini UI framework of its own...

For simple webpages, HTML/CSS is probably still the best way to go. But I wouldn't say the same for webapps?

Porting HTML/CSS/JS to native apps is another big problem, which is why we ended up with Electron/WebView. The amount of RAM it gobbles up just to run simple apps is pretty horrible.

Why Rust? It's a strongly typed application language across browser and native. It also has a massive ecosystem and this allows us access to all of it.

BTW canvas is only the renderer. There's a lot of engineering that went into making the canvas not a typical "canvas UI app". We have solved accessibility, touch gestures, direct/immediate draw etc.

There's more reasons behind this if you're keen, I've written up a more comprehensive doc https://dev.to/zionsati/html-javascript-css-should-have-died...

This is the second slice of that dream.

FUI-RS (retained UI in Rust) now runs the same retained application model (via the same EffinDOM runtime as FUI-AS) in browsers (including mobile browsers, so it has extensive touch gesture support / event system) and as native desktop applications without embedding a browser, thus no Electron/WebView. Major OSes supported are Windows (D3D12), macOS (Metal) and Linux (Vulkan). Comes with packaging tools for their respective OSes too (MSIX, DMG and AppImage).

In the FUI-RS demo, have a play around to see and feel what a typical web app looks like with FUI-RS. Try: - VoiceOver on macOS (yes, we have extensive semantic roles / customization support in the SDK) - bring up the page inspector (Cmd/Ctrl+Shift+F12) and inspect the mirrored DOM elements - multiline text editor with the various options - password manager compatible text inputs - drag-drop reorder - external file drop site - worker with progress reporting - HTTP fetch (POST/GET demo) - Copy the rich text in the demo and paste it in a word doc - Immediate mode tab with real time graphs and interactive dancing yarn - A mouse painter canvas

There's also a virtual list that demos 100k rows. If you're on your phone, pinch to zoom, fling scroll, pull to refresh will work as usual too.

How's FUI-RS different?

In the UI land of Rust, FUI-RS fills a gap for people who want a clean modern fluent syntax that is unencumbered by HTML/CSS on the web as well as native apps (iOS and Android are definitely in my view), and want to code purely in Rust. The same Rust code that runs on the web browser also runs natively without Electron or WebView, giving you retained controls with persistent identity and state (you'd probably guessed by now I'm not a big fan of React along with its many fragmented state management libs).

Try it out via crates.io: https://crates.io/crates/cargo-fui

Cargo-fui scaffolds and builds web and native apps.

cargo install --locked cargo-fui cargo fui new my-app --target universal cd my-app cargo fui dev

There's also a community created Galaga game based on an early version of FUI-RS here: Galaga-RS - https://jatm80.github.io/galaga-rs/

FUI-RS repo: https://github.com/zion-sati/fui-rs/

Comments URL: https://news.ycombinator.com/item?id=49256765

Points: 3

# Comments: 5

Marketing is always the hardest part. I came across this medium article https://zach-saw.medium.com/the-internet-is-dead-96a3f3ed866... while researching why it is so hard. It talks about the difficulty of getting some eyes on your app / project. In particular, it said Linus needed to be a content creator first before creating Linux in this day and age which hit me pretty hard.

This is a WPF grade UI framework with SwiftUI like fluent syntax that is created specifically for the web. As you probably know, creating a native feeling canvas wasm UI framework for the web is a massive ask but the goal is to make it feel as native as possible.

I've solved ARIA compliance problem, there's semantic tree by default but customisable. With brotli, the actual page is quite small, the demo pages are all under 100kb. The other bits such as the runtime and font assets are download once, cached forever.

It uses yoga, harfbuzz, ICU, skia for responsive UI, proper text formatting, shapes and shapes of modern UI, and comes with ICU data for all languages including Chinese Japanese and Korean. It also supports font tofu swapping, which is when you haven't loaded a font for a language but your user pasted some text in that language in text input/area.

Plenty more problems I've already solved which typically is canvas apps' biggest setbacks.

There are a few I have yet to implement, such as rendering a shadow DOM for pure Dev tool debugging purposes. Most likely it'll be opt in under Dev mode.

Other things like long press gesture and pinch to zoom are not done either.

I'm working on immediate more custom drawing as well as drawing text onto both immediate mode and memory bitmap canvases (yes canvas inside HTML canvas).

Maybe there's no point for such a thing any more these days when everyone can simply hackle AI to do things adhoc. But maybe someone out there still appreciates some good old engineering.

Comments URL: https://news.ycombinator.com/item?id=48569642

Points: 2

# Comments: 0

Look at the gap between gpt5.4-mini vs deepseek v4 pro!

However, I am realistic about the current legal landscape. Big tech corps are treating public code as free raw material for LLM training under the banner of "Fair Use". I am concerned that a company will ingest my codebase and use an LLM to effectively launder the logic, allowing their users to prompt a clean, closed-source recreation of my software without triggering the AGPL.

Do we have a licence specifically to prevent this but still keep OSS healthy and alive? Do we have a llm.txt / robots.txt that LLM scrapers respect? I feel that the whole OSS model is under threat here, even more than before (e.g. big corps earn billions from Linux instances without having to pay any software licensing cost, but they're more than happy to charge others for their own OS).

Comments URL: https://news.ycombinator.com/item?id=48485069

Points: 5

# Comments: 3