I understand the requirements of having a dedicated canvas and a decent UI running on it for things like games, CAD, 3D modeling and image manipulation apps. At the same time I don’t want my web bank using it. And unfortunately that’s usually what comes out from this.
Emerging Rust GUI libraries in a WASM world
111–120 of 272 posts
Re: Emerging Rust GUI libraries in a WASM world
#112Earlier 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 What are you talking about ? HTML and CSS is full of widget libraries, it's the best cross platform widget library out there. Ease of deployment + reach is the driving force behind improving the platform, but at the present nothing in Rust can even compare to something like Material UI. And let's not even go into stuff like date range picker components and s…
Re: Emerging Rust GUI libraries in a WASM world
#113Earlier quoted context omitted.
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?
The main issue was that V promised automatic memory management like Rust, but without the "trouble" caused by the borrow checker, which is something anyone who knows about the problem more deeply would laugh at.... last I checked, they were still at the same stage as a few years ago with that: "it will be working soon". It will almost certainly always stay there.
This is another one that tries to attack the same surface area as rust but aims at being easier.
Re: Emerging Rust GUI libraries in a WASM world
#114What's wrong with TypeScript? Last time I checked all WASM stuff was slower and much heavier than TS/JS.
That doesn’t mean I don’t want Rust “people” to work on frontend stuff for Rust. Typescript is good, I like using it, but I’d like to have options. If not for anything else, then for Typescript to take the best parts of Rust and use them.
I don’t personally think we’re going to see a massive shift away from a JavaScript world until someone like Microsoft starts driving the change. The amount of resources they pour into Typescript means it’s not likely to leave my world any time soon. But if it did, and something better came along then I’d be happy, not sad.
Re: Emerging Rust GUI libraries in a WASM world
#115Earlier 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…
If the web API zoo wouldn't be so random it would all be easier. Pretty much all problems on the web (including the Javascript framework churn) are caused by the DOM being too high level, too inflexible and generally too 'black-boxy' to do anything interesting. Accessibility could be fixed easily if there would be a web accessibility API. There's basically an entire 'middle layer' of web APIs missing, current APIs ar…
i mean, it sucked, but it was kind of that middle layer.
Re: Emerging Rust GUI libraries in a WASM world
#116Earlier quoted context omitted.
Obligatory jaw-dropping egui demo: https://www.egui.rs/#demo Egui slaps and is clearly going places.
That looks awesome - are there any accessibility features (e.g. supporting screen-readers)?
Re: Emerging Rust GUI libraries in a WASM world
#117Earlier quoted context omitted.
This is a matter of familiarity. For example, Golang is claimed to have simple syntax, but I find Golang's syntax much harder to read than Rust. The fact they avoided keywords and symbols like a plague caused that now e.g. function signatures are mostly names, spaces and parentheses, and the meaning of them depends on their relative positions, which is something I'm not used to. I guess if I wrote / read Golang sourc…
> This is a matter of familiarity No it is not. Or at least not for everyone. I have learned several languages more unfamiliar to me than Rust (pure functional, logic, stack-oriented,etc), but none has given me the difficulties Rust has. Also (only my sample of course, but there are no reliable stats) no-one I personally know who has gone through the Rust book has continued with Rust. The Rust Foundation hasn't made…
Re: Emerging Rust GUI libraries in a WASM world
#118Earlier quoted context omitted.
From a Rustacean's perspective: Golang is a no go because it lacks enum types, sensible error handling, generics (I think it has some version of this now), non-nullable types, or macros. Once you've gotten used to using these kinds of features in Rust, it is really annoying to go back and work in a language that lacks them. Basically, golang takes such an opposite design approach to Rust, that if you like Rust you'll…
If you're going to use electron and all the bad that comes with it, why not just use typescript though?
Re: Emerging Rust GUI libraries in a WASM world
#119Earlier quoted context omitted.
My understanding that WASM has a heavier load time, however actual benchmarks after the initial load are more impressive.
It’s not WASMs fault. Rust produces large binaries for whatever reason and people like to write their WASM in Rust. I’ve ported Rust to equivalent C and it was 25% of the size and similarly for loading times.