[pornel]

The egui framework they mention is pretty neat:

https://emilk.github.io/egui/

It an entirely custom toolkit, so don't expect it to have a native look and feel, but it's a GPU-first design with multiple back-ends. It can be used in native OpenGL apps too. It's an immediate-mode UI, so it's very easy to build and update even complex windows. Great choice if you want to prototype a game.

[Beltalowda]

The biggest downside of this is that everything is painted as "graphics", and you can no longer use the web inspector to modify the fonts, colours, etc.

While few people (like myself) do this directly, lots of people use it indirectly through extensions like Adblock, Stylus, etc.

For example, I find the fonts hard to read due to the colour choices; then I zoom in and it's better, but now this "Widget gallery" no longer fits on my screen and there is no scrollbar.

[franga2000]

Yes, I really hope this doesn't become common. By not utilising the DOM, you're killing accessibility, autofill, customization (things like reader mode, automatic dark themes...)... These are things that regular people rely on every day (not just us techies writing userscript a and Stylus themes).

[pjmlp]

It will definitly be the new common, by killing Flash et all without comparable tooling, while at the same time offering WASM, it was only a matter of time until we had the revenge of plugins.

Basically 10 years wasting time to come full circle.

https://leaningtech.com/cheerpj

https://leaningtech.com/cheerpx-for-flash/

https://opensilver.net/

All of the three major ones are now back, but it is ok, WASM is great!

[Beltalowda]

It's not really a "WASM problem", as such; you can use the DOM from WASM and that works quite well. Similarly, you can do all this kind of graphics drawing with just JS as well.

It's just a choice this framework made. I bet there are actually some real advantages to it, but also disadvantages. I very very much like the customizability of the web, so I'd be very surprised if the advantages would outweigh the problems.

In short, I don't think it's really the same as Flash.

[labawi]

Concur. I block wasm and webgl, mostly for security and privacy, so don't use sites that require it. Unfortunately, as I also block trackers, most site operators won't even realize people like me visit their sites.

[Beltalowda]

Does blocking WASM improve privacy? As I understand it, it essentially has the same capabilities as regular JS(?) but I never looked very deeply in to it, so maybe there's some parts I don't know about(?)

[labawi]

Theoretically, wasm shouldn't have more access, though I would be moderately concerned about bugs, and better access for timing and rowhammer.

Practically, it's mostly used for tracking and making users' machines execute even more inscrutable code. IMO, if you need wasm for |"normal" pages and apps, you're doing something wrong. There are notable exceptions (say machine emulators, maybe 3d games and such), but they are spread far between most pages.

[seanw444]

It's ridiculous to me to even call these things web browsers anymore. A more realistic term is any-type-of-application-cross-platform engine. But that's not really concise. Why did the web have to become the primary development platform for nearly everything, with WebAssembly, WebGL, notifications, etc?

I, for one, am a fan of the fact that Gemini is growing in adoption (at least as far as I can tell). Such a nice, stout protocol.

[734129837261]

It feels like a huge step backward in terms of all of that. It's what Flash used to be, except less blatant security risks I guess.

[pmlnr]

> less blatant security risks

For now. Flash was also fine in the early days.

[Cullinet]

Just look at the growth in the number of Adobe employees between 1990 and 2019 at this link :

https://dazeinfo.com/2019/11/08/number-of-adobe-employees-wo...

if headcount was any way to measure success, then the killing of Flash did Adobe the world of good.

edit : not corollary, but the capacity to manage Flash security might have arrived too late, if I recall that late 2000s sudden Acrobat hegemony that was so absolute a stranglehold on corporate document cultural defaults they were uncaring about opt out only browser extension auto installation and more dark patterns than I care to remember. Unless the dark patterns secured that growth. Ugh. One of the primary factors in my purchase of a top model iPhone for my first Apple product that wasn't Snow White era was the ability to print to PDF (edit removed anecdote accidentally aggregated)

[mhoad]

I mean I would just argue that the accessibility APIs are currently tied to the DOM and we should fix that.

[rat9988]

Accessibility API need a semantic layer that the DOM provide. You can't just make every arbitratry gui accessible. The app developers will have to pay the price (more development time).

[mhoad]

I’m only familiar with Flutter which just happens to have a render to Canvas option on the web but they have a full accessibility tree that is designed for exactly that already with zero work from the developer.

[progmetaldev]

Hopefully the GUI developers realize this is needed and put in the work, so that work can be shared by the end users of the GUI frameworks. I'd hate to think developers are going to reinvent the wheel on each project, but I've been less surprised before.

[dspillett]

> extensions like Adblock

I suspect that if Amazon have considered this, they certainly didn't see it as a disadvantage!

[throw14082020]

> we built an application that overlays debugger information on an application scene render using egui, a Rust GUI library

This is the context. They use egui to display debugger information - performance does not matter for the debugger information.

[IshKebab]

It does if you're debugging performance issues.

[throw14082020]

If you need good performance to debug "performance issues" - lack of good performance - I don't think you will solve your problem.

[IshKebab]

I'm not.sure what you're saying. You need good performance in your debugging tools to debug performance in your main app, otherwise when you enable the debugging tools they will dominate any measurements.

[jcranberry]

It can be very difficult to replicate a data race when using shared memory without decent performance when debugging.

[pacificat0r]

You can easily tag imgui update/render times in profiling sessions. Then they are isolated from the rest of the work that's happening.

[FpUser]

Checked demo. Bugs when interacting. For example when clicking buttons on top does not switch to supposed part. just flushes screen momentarily. Clicking refresh on browser right after that fixes the situation.

Major pita is keyboard handling when selecting, cutting, pasting text in edit controls and markup editor

[lordnacho]

Can confirm this lib is very good. I use it to simplify my status app, it allows me to keep everything in Rust so that I don't need to know too much about react and other web tech.

There's demo apps that you can just grab and edit to your liking, and the docs explain what you need to build the WASM app and run it.

[agumonkey]

someone made a tutorial to make a web app in rust with egui https://www.youtube.com/watch?v=4MKcqR9z8AU

[rafale]

Immediate mode is such an outdated approach for a modern UI framework. It's a deal-breaker imo.

[coldtea]

Immediate vs retained is not about "modern" vs "outdated", both are about as old as computer graphics themselves. One is better in some cases, the other in others.

In any case, the fashion (for the last ~10 years) is to consider immediate mode the modern approach, and retained mode an awkward practice of the 90s. So you can call "immediate mode" a lot, but you can't call it "outdated" when most consider it the new black...

[IshKebab]

You're thinking of React and Flutter and so on. They aren't immediate mode. They're more like retained mode with a non-traditional way of keeping the UI state up to date. Very different to egui.

[coldtea]

React and Flutter aren't immediate mode only because they're build on top of the DOM as primitive. Otherwise, conceptually they are evolutions of immediate mode.

And they inspired plenty of GUIs outside the web to go "immediate" mode themselves.

[jcelerier]

Words don't have any meaning anymore if react (and the HTML DOM) is considered anything close to "immediate mode".

For starters the DOM is a declarative thing - immediate mode means that you have a function called for each frame with imperative function calls written by the user of the immediate mode GUI toolkit for rendering each element of the GUI every time (unlike retained mode where a framework hides that behind some object model). It's not really possible to be more opposite to a declarative approach.

[mockery]

Perhaps confusingly, the term "immediate mode GUI" usually describes an API style. NOT an implementation detail.

It suggests a particular implementation, but in practice most nontrivial "immediate mode" GUI libraries (including egui [1] and the famous Dear-IMGUI [2] [3] ) retain some "shadow state" between frames. The existence or scope of that state is a (sometimes-leaky) implementation detail that shouldn't distract from the fact that the API presented is still "immediate mode."

[1] https://github.com/emilk/egui#ids

[2] https://github.com/ocornut/imgui/blob/master/docs/FAQ.md#q-a...

[3] https://github.com/ocornut/imgui/wiki/About-the-IMGUI-paradi...

[coldtea]

The key point of the comparison is than in React, as in immediate mode, you tell what you want shown every time (for every "frame") as opposed to having references to and controlling instantiated widget objects (an object graph).

In React's case, you tell it declaratively (your JSX component tree) with some procedural stuff thrown in (JS parts in the JSX). In classical immediate mode, by calling paint functions. But in both cases you tell every time - as opposed to performing actions on a pre-created widget graph. With the caveat that in React's case, behind the scenes, there is a widget graph, the DOM. But that's an implementation detail, as far as the dev writing React is concerned, they re-describe every GUI state.

So, you can say that React is an "immediate mode" abstraction over the retained DOM. In fact that's exactly what devs say about it:

https://twitter.com/ibdknox/status/413363120862535680

That's the inspiration from "immediate mode" that React brought - the GUI intention described by creating a new state, as opposed to manipulating state. And the diff algorithm is also inspired by the diffing algorithms used in immediate mode to draw less for each frame.

That React does this with DOM widgets under the hood as opposed to painting commands, and that those are higher level widgets and not lines and rectangles is not the part of the analogy people emphasize.

retained: user instantiated widgets, and changes their state (e.g. to clicked).

traditional immediate: for every 'tick', user issues commands to draw the new GUI state, usually with some smart diffing under the hood to minimize paint commands.

React immediate: for every tick, user describes the arrangement of widgets, text, etc for the next GUI state, usually with some smart diffing under the hood to minimize DOM changes.

Calling a "draw button" function, as opposed to declaring a "<Button>" in a JSX structure, is not that crucial of a difference, compared to the conceptual change between "manipulating objects" and "telling everything about how the UI should look at each tick".

Heck, a dev doing an "actual" immediate mode could trivially wrap the "draw button" function call to be driven from a declarative file (if you parse the term "button": call draw button, etc). It still wouldn't be retained mode.

And React and co also inspired interest in immediate mode GUIs, and inspired some new actual bona-fide immediate mode, with graphic calls and everything.

[pier25]

Flutter on the web uses the DOM?

I seem to recall discussing here on HN with people from the Flutter team how they didn't use the DOM on purpose.

[coldtea]

>Flutter on the web uses the DOM?

Yes. On the web it actually has 2 renderers, a HTML (which uses the DOM) and a Canvas based one (which doesn't).

But I mostly wanted to write about what's the case with React - I just wrote quickly and also kept the reference to Flutter from the parent comment which mentioned them together...

[IshKebab]

Flutter isn't built on top of the DOM. And anyway that's not why they're not immediate mode. Take a look at some egui code and you'll see huge differences, e.g. in how button clicks are handled, when code runs, etc.

[coldtea]

>Flutter isn't built on top of the DOM.

The web version has a DOM-based HTML Rendered in addition to a separate Canvas one. So (on the web, where the DOM is applicable anyway, it kinda is).

In any case, I didn't intend to go about Flutter, which I don't use, just wanted to write about React. I mentioned it while answering because the parent comment mentioned them together, and I didn't paid much attention.

[malermeister]

Is the font rendering awful for anyone else? Firefox on Windows fwiw

[f00zz]

Cool. Looks like a fancier version of Dear ImGui.