What's wrong with TypeScript? Last time I checked all WASM stuff was slower and much heavier than TS/JS.
Emerging Rust GUI libraries in a WASM world
41–50 of 272 posts
Re: Emerging Rust GUI libraries in a WASM world
#42Earlier quoted context omitted.
That's because Rust GUI people are like Lispers and functional programmers — too obsessed with doing things correctly "from first principles" and "purity". For GUI programming, there is only one feature that matters: having a fuck ton of well supported widgets for every situation across every platform. Almost everything else is secondary. This is why HTML/CSS, Flutter (and to a lesser extent Qt) are so successful. No…
Maybe you are right but it sounds a bit like: "For GUI design there is only one feature that matters: having a fuck ton of well supported colors for every situation across every platform." Replace colors with fonts or animated GIFs and you and up in late 90s web design.
I don't think that's quite the point. It's not that you want dozens of different widgets in every app. It's that when picking an ecosystem for apps, a business will want to know that whatever they need (whatever small sample from that multitude), it's available. A large pool of resources is particularly important when you don't know exactly what you'll need up front, which is most of the time.
You might only want 8 colours, but if you don't know exactly which 8, you'd better have a large palette available.
Re: Emerging Rust GUI libraries in a WASM world
#43Re: Emerging Rust GUI libraries in a WASM world
#44Earlier quoted context omitted.
Cool demo, but by the looks of things the whole site is rendered into a canvas element. As a result, the browser's dev tools are useless, it won't work with screen readers, and you can't copy+paste text. And any text rendering and input elements will be non-native. (So, no nice iphone controls. No native / system configurable keyboard shortcuts. And so on.) I sincerely hope the web as a whole doesn't move in this dir…
And scrolling is unavoidably all wrong: dragging two fingers from one end of my touchpad to the other should scroll by about four screenfuls, but only manages two thirds of one screenful; a quick swipe should send it dozens of screenfuls, with inertia, but manages even less than that two thirds of a screenful; and these limitations are fundamental due to the web not possessing the right primitives. (Then there are mo…
In my testing, I went through a bunch of Rust frameworks that sit on top of the core OS UI frameworks. My experience with all of those was that they all capped out at about 3k rectangles on a screen at a time at 30 fps (vs the about 80k rectangles that fit at usually 30-60 fps in my demo).
I wonder if your experience is different?
As best I've been able to tell, right now you have to make a choice between (a) fast and (b) native, and you only get to choose one. And in my application domain, fast is nonnegotiable.
Re: Emerging Rust GUI libraries in a WASM world
#45I am betting on Vlang instead. Rust is too complicated for an average person - like me. It's basically the Haskell of system programming. V is basically Go made right.
I remember looking into V last year, it seems most of the discussion surrounding it was that it was vaporware.
Is that not the case? It certainly looks nice, but is it ready for use?
Re: Emerging Rust GUI libraries in a WASM world
#46What's wrong with TypeScript? Last time I checked all WASM stuff was slower and much heavier than TS/JS.
Slower - not really now Rust client web frameworks have improved. Don't have refs handy, but Leptos, Dioxus etc are on a par with Solid.
Larger bundle sizes - yes that's still true.
And not all GUIs are web GUIs, so WASM isn't the whole story.
Re: Emerging Rust GUI libraries in a WASM world
#47I am betting on Vlang instead. Rust is too complicated for an average person - like me. It's basically the Haskell of system programming. V is basically Go made right.
It's sorely lacking Haskell features, I have sometimes written functions to simplify my code to find out the function signature is several lines of code and MUST use references
fn apply(mut f: impl FnMut(B) -> G, a: A) -> impl FnMut(&B) -> C
// must still be `for impl FnMut(&'r B) -> C`, because that’s what filter requires
where
G: FnMut(A) -> C,
B: Copy, // for dereferencing
A: Clone,
{
move |b| f(*b)(a.clone()) // this must do any bridging necessary to satisfy the requirements
}
...
.filter(apply(second, i))
...Re: Emerging Rust GUI libraries in a WASM world
#48Earlier quoted context omitted.
I'd argue that the most successful UI platform is a browser. And guess what? Browser does not have a fuck ton of well supported widgets. All it does it some button with outdated UI, few inputs nobody really uses and dropdown select suitable only for the most basic uses. Anything other built on divs with CSS and JS. And it works. So my opinion is that it's definitely solid foundations what matters. Rest will come with…
> Browser does not have a fuck ton of well supported widgets [...] And it works. I beg to differ. When the economics of doing UIs shifted away from APIs like Windows Forms, Carbon, JavaFX towards the current trend of doing everything in a browser, it brought with it some serious regression in how powerful and user friendly those GUIs are. With Microsoft-level resources, you can take on a mammoth engineering task like…
I beg your pardon, but why do you consider CRUD 'degenerate'?
Re: Emerging Rust GUI libraries in a WASM world
#49What's wrong with TypeScript? Last time I checked all WASM stuff was slower and much heavier than TS/JS.
My understanding that WASM has a heavier load time, however actual benchmarks after the initial load are more impressive.
Re: Emerging Rust GUI libraries in a WASM world
#50What's wrong with TypeScript? Last time I checked all WASM stuff was slower and much heavier than TS/JS.
Where did you check that?
If you're talking about Wasm with Emscripten, yes there's a cost of loading the runtime because Emscripten comes bundled with a lot of stuff.
I'm skeptical that just wasm itself was slower or heavier.