Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I Switched from Flutter and Rust to Rust and Egui

jdiaz97.github.io

Post reply on HN
Print view View original

51–60 of 148 posts

Re: I Switched from Flutter and Rust to Rust and Egui

#51

Post by nu11ptr »

newswangerd wrote: post #43

I've been doing something similar to this, except with go. In my case I have a flutter frontend and a go backend that's built using go mobile. Instead of trying to figure out how to make all of my go functions use data types that are supported by the various native frameworks, I've opted to use protobuf objects for every type that is shared between the frontend and backend. This way I can expose a single go function…

Have you considered just using gRPC in this case? You gain 100% language separation (no FFI) and remote client/server at the cost of a little more call overhead.

Re: I Switched from Flutter and Rust to Rust and Egui

#52

Post by pseudocomposer »

newswangerd wrote: post #43

I've been doing something similar to this, except with go. In my case I have a flutter frontend and a go backend that's built using go mobile. Instead of trying to figure out how to make all of my go functions use data types that are supported by the various native frameworks, I've opted to use protobuf objects for every type that is shared between the frontend and backend. This way I can expose a single go function…

This is what I did for BeatScratch! https://beatscratch.io

My music model is all Protobuf messages, which go from Dart/Flutter land to Kotlin/C/Swift/JS audio backends on target platforms. I also use Protobuf for saving and sharing. It’s been incredibly resilient and performant.

Re: I Switched from Flutter and Rust to Rust and Egui

#53

Post by klabb3 »

nu11ptr wrote: post #51
newswangerd wrote: post #43

I've been doing something similar to this, except with go. In my case I have a flutter frontend and a go backend that's built using go mobile. Instead of trying to figure out how to make all of my go functions use data types that are supported by the various native frameworks, I've opted to use protobuf objects for every type that is shared between the frontend and backend. This way I can expose a single go function…

Have you considered just using gRPC in this case? You gain 100% language separation (no FFI) and remote client/server at the cost of a little more call overhead.

Not OP but in same situation. Not every platform can run gRPC over localhost easily or without extra privileges.

I used to use protobuf but now I just use JSON, over stdin/stdout on desktop. It’s honestly quite good.

Re: I Switched from Flutter and Rust to Rust and Egui

#55

Post by cyberax »

klabb3 wrote: post #53
nu11ptr wrote: post #51

Earlier quoted context omitted.

Have you considered just using gRPC in this case? You gain 100% language separation (no FFI) and remote client/server at the cost of a little more call overhead.

Not OP but in same situation. Not every platform can run gRPC over localhost easily or without extra privileges. I used to use protobuf but now I just use JSON, over stdin/stdout on desktop. It’s honestly quite good.

Why not ConnectRPC? It's basically gRPC but without all the strange requirements for exotic HTTP features.

Re: I Switched from Flutter and Rust to Rust and Egui

#56

Post by k__ »

edflsafoiewq wrote: post #35
rossant wrote: post #33

I really like the immediate mode GUI (IMGUI) paradigm. The other day, I looked into whether any web-based IMGUI libraries existed. It seems that HTML and the DOM are designed so differently from IMGUI that such an approach doesn't really make sense, unfortunately, unless everything is rendered manually in a canvas, WebGL, or WebGPU, which brings its own set of challenges.

Isn't that basically what VDOM is?

A virtual DOM is another indirection, so the opposite of what immediate mode tries to accomplish.

Re: I Switched from Flutter and Rust to Rust and Egui

#57

Post by edflsafoiewq »

k__ wrote: post #56
edflsafoiewq wrote: post #35

Earlier quoted context omitted.

Isn't that basically what VDOM is?

A virtual DOM is another indirection, so the opposite of what immediate mode tries to accomplish.

Immediate mode only describes the interface.

Re: I Switched from Flutter and Rust to Rust and Egui

#58

Post by k__ »

ar-nelson wrote: post #36
rossant wrote: post #33

I really like the immediate mode GUI (IMGUI) paradigm. The other day, I looked into whether any web-based IMGUI libraries existed. It seems that HTML and the DOM are designed so differently from IMGUI that such an approach doesn't really make sense, unfortunately, unless everything is rendered manually in a canvas, WebGL, or WebGPU, which brings its own set of challenges.

I really like Mithril.js ( https://mithril.js.org/ ), which is, IMO, as close as it gets to web IMGUI. It looks a lot like React, but rendering happens manually, either on each event or with a manual m.redraw() call.

I think, similar to Preact, Mithril skips the VDOM, which makes it "more immediate" than React.

However, updating the DOM and then turning the DOM to an image (i.e., rendering it) still has an indirection that using canvas/webgl/etc. don't have.

Re: I Switched from Flutter and Rust to Rust and Egui

#59

Post by nopelynopington »

piker wrote: post #19
merksoftworks wrote: post #7

So egui is great for projects where the application runtime is short lived, or for overlays in longer lived projects. The visual equivalent of scripts, where you know you need a small amount of immediate visual feedback and tweaking parameters for it to be useful to the end user. Flutter answers questions about more robust UI. It's good that you chose the right tool for the job and more people should know that there…

Both approaches have their downsides and, in my view, retained mode and immediate mode tend to converge as the UI complexity increases. So far, no problems with implementing any UI I want in my experience with egui on a somewhat complicated application (Desktop word processor). Immediate mode is a breath of fresh air from React. [Edit: although the standard accessibility criticisms apply to my application; although t…

I'm also thinking of building a word processor so I'd be interested to see what you're working on if you fancy sharing?
Post reply on HN