Edit: egui is an immediate mode GUI library written in Rust. egui runs natively on , and on the web it is compiled to WebAssembly and rendered with WebGL or WebGPU. Everything you see is rendered as textured triangles. There is no DOM, HTML, JS or CSS. Just Rust.
Devs are constantly making the mistake of falling in love with immediate mode GUIs... because it's convenient for them, the developer. For the user, it's almost always a worse experience as things don't behave in the same way as the rest of the platform they're on.
egui is great for video game debug UI overlays and internal tools, and maybe some specialized graphical tools. Otherwise its quirks are too annoying for general purpose app usage. Sure, you banged out a UI quickly with it, at the expense of your users.
No, it’s fine. It’s the longer term DX that takes a hit. Anything other systems can do, immediate mode can do, because like those systems you can always cache across frames. The same can’t really be said for retained mode. We wrote some about it here: https://tritium.legal/blog/desktop
I clicked on that expecting to see something about the limitations of retained mode, but I didn't see anything. There's a claim about long term retained mode complexity, and a discussion about a winit bug...
* Right off the bat in the login screen, if you resize the window, it flickers
* I logged in. Double clicking the top part of the window doesn't maximize it, like I expect on basically all other windows. I'm using MacOS, btw
* Resizing the main home screen is also a flickery mess. Though I'll give credit, it's a fast flickery mess, because the official spotify app resizes like ass
* Okay, here's one more specific to egui and why I think its approach is not good outside of the app types I listed in my original comment: I type some text in the search bar. Let's say I want to highlight the last word after I've typed it, in order to delete it or type something else. On every other app on my system, I can hold Option + Shift + Left Arrow Key. Or perhaps Cmd + Arrow Keys to move the cursor to the start or end of the line. The egui app just doesn't work, because egui misses so many fine details about text manipulation on a given OS.
* In general, text handling just sucks
* Scrolling doesn't have the inertial bounce when it hits the ends of a scroll action
* It's very easy to create overlapping UI elements by resizing panels and/or the window itself.
Anyway, those are just some of the things from a few minutes of trying this specific app out.
In general, if it's an egui app, I already know there will be weird resizing glitches/flickers, a poor text editing experience, and it will typically not follow the platform's idioms and built-in gestures, scroll physics, behaviors, etc. In this case, the app is decent since it mostly just needs to play music, and you mercifully don't need to interact with it much when it comes to text and such.
But saying "It's a GUI like any other" is like saying "wonderbread is a bread like any other". Maybe it's a curse of knowledge? Similar things happen with coffee. One person says "tastes like coffee" while another can pick out individual flavor notes. Maybe I'm shouting into the void and no one gives a shit anymore, I dunno. But to me, these things matter and are a mark of quality.
If we have LLMs that can shit out whatever code now, why aren't people having them output truly "native" GUIs that use the UI framework of the OS so they can get all the expected behaviors by default?
This seems like more of a complaint about egui's choice to re-implement all the widgets from scratch than its choice to use an immediate mode API. The two are orthogonal. The IMGUI idea has its roots in a community of people that like implementing things from scratch, but you could implement it on top of native widgets if you wanted to.
The choice to re-implement native widgets from scratch is justifiable if the egui devs think they can do better than the native widgets do. It's also nearly required in practice if they want the toolkit to have consistent behavior across multiple platforms (something people have learned the hard way multiple times across multiple different UI libraries).
It's hard to get it right, but that's why the egui devs are writing a library: so that others can benefit from that hard work. Many of the things you pointed out are just bugs, and bugs can be fixed.
> but you could implement it on top of native widgets if you wanted to
Is there an immediate mode GUI API that uses native widgets? I don't think I've ever seen that but would be curious to try it out. Does it work well in practice? If it doesn't exist, then it's kind of a moot point, isn't it?
I sympathize with wanting "consistent behavior across multiple platforms", but that usually just results in "consistently kneecapped behavior across multiple platforms".
You should draw a distinction between “implementing the GUI” and “implementing OS behavior”. Flickering aside egui works mostly fine for the former; the latter falls apart on most non-browser-and-non-toolkit-wrapper approaches because people never stop to handle those things.
E.g your double click on title bar thing sounds less like egui to me and more like somewhere in the stack is missing an AppKit flag.
I was about to come here and say that egui is a terrible choice for web. Everything is rendered in a canvas, so accessibility and extensibility is thrown out of the window. Basic browser functions like pinch-zoom don't work, it has some very wonky visual bugs when resizing the window, interactions have a very noticeable delay, no browser extensions work with this.
This is really not a good solution for web apps, and if you're vibe coding your apps anyway, there isn't any reason not to have a native browser application.
It's the first time I've heard about egui. I'm currently working on a desktop app that uses Tauri, and I realized there's a Tauri plugin that connects the two:
in addition to what other comments pointed out, on the demo ( https://www.egui.rs/#demo ) if you have a sidebar open, there is an offset of approximately the sidebar's width (though not exactly) between the system's mouse pointer position and the web app
Interesting. I don't remember my crossover cables being marked that way; you had to read the dot-matrix printing along the side to know. Color would have been way more handy.
I added labels (just a piece of paper under some clear tape) saying "CROSSOVER" at both ends of the cables, so that if I ever plugged a crossover cable into a place where I needed a straight-through, the label would be right there next to the plug.
Well I have to add that was interesting too. Because I remember you had to hold the ends up next to each other and compare the order of the colored wires. Same order left-to-right, not cross-over. Anything else, cross-over.
I believe a lot of NIC's could autodetect and adapt to the cable? I'm pretty sure I had 2 computers connected to each other using a regular network cable.
It's not too dissimilar from GitHub, but geared towards ML. They have a 9/mo pro plan for individual users for upgraded storage/usage, and an enterprise version of Hub that larger orgs can pay for. I think the enterprise has some contract minimum + 50/mo per seat. https://huggingface.co/pro
They also have inference endpoints with metered prices, and their spaces product (though i'd imagine this is a smaller portion of revenue).
I’d be curious to see how much that’s subsidized. Maybe they’re different, but when I see ML and monthly plan in the same sentence, I see zero sustainability.
Why I don’t think it’s sustainable to run a compute-intensive business on low monthly plans? If they’re like OpenAI and Anthropic, monthly plan users can spend many times the amount of money in a month than they pay, and unlike regular lower-compute SaaS businesses, overhead increases significantly with usage. That means the more users many of these services get, the more money they lose. Some surmise OpenAI was hiding the actual cost in marketing expenses to make their business look less unprofitable. Anthropic was smart enough to focus on customers most likely to be willing to pay for API pricing, so they’re in a better position. If hugging face is primarily focused on selling monthly accounts rather than token based billing which bills more as the company’s expenses increase, its not likely to ever be sustainable without significant changes.
I think maybe just click around Huggingface's site a bit? They don't run a compute-intensive business on low monthly plans. You're describing frontier labs that sell access to their enormous models with subsidized subscriptions, but that's just an entirely different company/model than Huggingface. They've been around in their current form since around 2018. They provide a GitHub like service for hosting and sharing models primarily, and they also provide infra for optimized compute (for training and inference) that you can purchase through them, but you pay as you go for the compute and they have their premium baked into the price.
Most of HF's revenue comes from their enterprise customers; you essentially get direct access to their MLEs (Slack) as well as their software stack, hence the per-seat cost and annual minimum contract price. In that sense they are not particularly "compute-heavy" in terms of what they "really" sell.
The M1 was genuinely a big step forward, but what has followed, not so much. I have an M5 Pro with 48GB of RAM and it is genuinely good ... but that's about it.
I love the battery life, appreciate the hardware, but find the OS to be annoying. Less annoying than Windows for sure, but I'd rather be running Linux.
I do actually enjoy them and they’re pretty much all in my wheel house. Well I enjoy them when I have plenty of time to sit down with a cup of coffee and study. A few times I’ve been under basically deadline pressure to get the exams passed in time to qualify for the bonus, that’s not fun at all. Over about 20 certification attempts I’ve only failed one :) (they’re all pass/fail).
For not well off geeks you could just solder a bunch of resistors together and get vastly better sound than from the crappy PC speaker and there were games that supported it and I wrote some software for it (which unfortunately is gone I think). I had a lot of just having this on the pc in the house.
Could be completely off base, but isn't this the equivalent of polling a Provider's commit log or distributed log? So accessing a third party's Apache Kafka?
Yep! And since your partner will be unlikely to build a new architecture on the request of one customer, you should 'do the Kafka thing' on your end, capture everything (double-sends and all), then smartly query your events, rather than try to program correct double-send-friendly db updates.
