nicoburns

Because he (on behalf of Open AI) made deals with 2 of the 3 major manufacturers of RAM to buy a significant proportion of their output, in the same week, without either of the manufacturers knowing that he was also making a deal with the other one. This directly led to the current RAM shortage.

> IMO his comments are blown way out of proportion

The context for people's reaction to this is that he has single-handedly caused the current spike in RAM prices.

To the limit that any Winit-based app is. Which is to say it builds and runs, and there is basic touch and text input support. But system integration is pretty limited.

It's absolutely in good faith. There are two kinds of GUI framework in Rust:

- Those people have poured consistent time and effort into over a period of years

- Those people vibe code into existence in a couple of weeks and typically abandon after a few months.

Nobody wants to waste their time on the latter, so I am pointing people to the former. Yes, mine is one of them, but that doesn't make it bad faith, it just means I know what I'm talking about.

I am building such a lightweight browser engine: https://github.com/dioxuslabs/blitz. It targets most of HTML/CSS, but leaves out (or makes optinal) a lot of the extra stuff that browsers pull in). It also has the option to use Rust instead of JavaScript for the scripting layer.

Though 8 MB RAM is a non-starter when a single RGBA texture @4k is ~30Mb and modern system often require 2 or 3 for buffering. Somewhere around the 60MB to 100MB mark seems to be the base for modern setups, at least on macOS.

A large amount of the energy of an ICE is wasted as heat and noise. Some of that is a constant factor that isn't sensitive to load. So when increase load, it doesn't make as much of a difference to energy used.

By contract in EVs, much more of the energy is going towards moving the vehicle and therefore both weight and air resistance greatly affect the amount of energy use.

(I am the maintainer of dioxus native, and also posted the comment above)

So:

- The initial version was released over a year ago (3 month is the most recent patch release of the stable version).

- It is part of the Dioxus project (https://github.com/dioxuslabs/dioxus) which has been going since 2021 (but the other renderers are web/webview based).

- The native renderer (https://github.com/dioxuslabs/blitz) has been under development since December 2024 (building a whole new web engine is just a big project).

You're ultimately kind of right that it's not as established as 1-4 in the list. But I think it justifies it's place with the other frameworks lower down the list as one of the lesser-known frameworks that compete technically with those further up the list.

If you're interested in a GPU-rendered Rust UI framework, then maybe skip this vibe coded project, and check out some of following established projects:

  Rust-native GUI frameworks (by crates.io downloads):

   1. egui (30.3M total / 9.2M last 90 days)
      https://crates.io/crates/egui

   2. Iced (3.2M / 770k)
      https://crates.io/crates/iced

   3. Slint (2.4M / 955k)
      https://crates.io/crates/slint

   4. GPUI (447k / 255k)
      https://crates.io/crates/gpui

   5. Dioxus Native (181k / 26k)
      https://crates.io/crates/dioxus-native

   6. Freya (49k / 12k)
      https://crates.io/crates/freya

   7. Floem (45k / 15k)
      https://crates.io/crates/floem

   8. Vizia (7k / 700)
      https://crates.io/crates/vizia

List is hand-picked list, ordered by crates.io downloads. I had an LLM fetch the download counts and links. Webview based UI like Tauri and Dioxus Desktop are excluded. As are bindings to native toolkits and GTK.

Using less power is generally the main benefit. On lower end hardware you may also notice a performance difference, depending on what the UI is trying to display.

It's definitely possible to do sharp fonts in the Rust GUI ecosystem (although you certainly won't get it out of the box). With the native text libraries if you want to (both Servo, Zed/GPUI, and anything using Skia do this), or emulated with Skrifa + Vello.

But I agree with the reset

I did not, but judging from it's README it may well solve most of the issues.

For Style and Layout, Servo is now competitive (and in many cases faster) than Chrome / Firefox according to my benchmarks https://nicoburns.github.io/browser-layout-bench/

Some actual numbers (vibe coded benchmark ported from the JS framework benchmark):

  Median update+build time per frame (ms), lower is better
  Machine: macOS 26 VM, Apple M4 (virtual)

  benchmark (ms)      Dioxus    Iced    egui   Slint    GPUI
  create 1k            12.91   17.57   10.66   26.99   22.32
  replace 1k           14.46   14.48    7.48   17.07   17.41
  update every 10th     2.12    1.94    4.17    5.55   10.65
  select row            1.16    0.37    3.50    6.62   10.68
  swap rows             1.45    0.42    3.53    4.10   10.26
  remove row            1.32    0.39    3.27    4.46   11.95
  create 10k          124.97  152.52   58.97  136.07  164.58
  append 1k to 10k     28.12  157.67   33.01   69.93  117.70
  clear 1k              3.00    0.86    0.07    4.60    0.04
  scroll frame          0.28    0.10    0.55    4.23    3.79

Dioxus above is Dioxus Native.

These are CPU-only times for the state management / style / layout / etc, but don't include rasterization (additional work in the benchmark harness required to measure GPU time sensibly), probably aren't fully apples-to-apples, and could probably do with testing some more complex layouts.

For anyone looking at Rust GUI: don't expect GPUI to be the fastest. From what I've heard, Iced, Slint, Dioxus Native, Freya, etc are all faster. Despite claims of being blazingly fast, GPUI isn't that optimized. Zed gets away with it because it's UI is simple.

(I'm the maintainer of Blitz)

My experience is that it varies greatly by feature.

Something like border styles, the agent was able to do pretty effectively. Although it still took a few hours iterating on it to get the performance characteristics and edge cases right.

More complex features like hoisting position absolute nodes and other layout features still take days to weeks of iterating to get something usable that isn't so fragile it'll blow up the next time you touch something.

IME, agents are generally capable of passing the tests autonomously. But not with code you'd actually ever want to use. Both because of the quality, and because it will have awful performance/memory/security issues.

It's normal. But you can somewhat mitigate by:

- Making sure you compile with as few profiles as possible.

- Disabling debug info (or setting it to "line-table-only") for the default profile.

The difference is that this accumulates over time. You'll only get this if you haven't run "clean" for some time (likely months).

Testing touchscreen experiences for other devices is the main thing I can imagine actually using this for.

> As an occasional "pinch to zoom that thing centered on my fingers, and adjust it to show what I want to someone 10 feet away" tool: it's fantastic. I could learn the key combo, but "use two fingers" is dramatically easier to remember and control.

Perhaps, but on a Mac you can already do this via the touch pad.

Definitely appreciated. The increased weight is the one downside of my M1 laptop over my earlier 2015 Macbook.

Good news: batteries on are a similar exponential curve. Just a decade or so behind.

Yep, and if it's anything like previous transformative technologies: the internet, and 100 years earlier the railways, a lot of people are going to lose a lot of money overbuilding the wrong things along the way.

I'm pretty sure electricity demand in the UK has been declining in absolute terms, not just per capita.

> I'm highly skeptical that a battery + inverter (w/o solar), using time-of-use for payback would ever make pure financial sense.

Ever? Batteries are 10x cheaper today than they were ~a decade ago. If that trend continues for even a little longer, they'll be absolute no-brainer like solar is today within the next 5 years.

2026 seems to be roughly the break-even point. And whether it's worth it depends on where you live (greatly affects the cost of both installing a system, and buying energy from the grid).

> I don't know how you guys in Europe managed to gaslight yourselves into justifying regression of social and technological development

Many of us believe that the alternative is a serious risk of severe climate change that would be much more disruptive. Not being able to use your washing machine at night is going to seem like the smallest of minor inconveniences if crops start failing and we don't have food, or cites end up underwater triggering mass migration into neighbouring areas and that leads to large scale societal conflict.

Of course, if you don't believe that those things will happen then caring about climate change seems irrational. But belief in (anthropogenic) climate change is the mainstream view on all sides of the political spectrum in most of Europe.

This was needed. A lot of large businesses ban Firefox because they don't have these kind of controls. I can't test Firefox on my work computer because company policy prevents it being installed. And that kind of thing really hurts Firefox.

There are `rsx` macros in Rust that work with a regular `cargo build` and retain IDE support.

Four-hour grid-scale batteries wouldn't have helped the Texas winter crisis much. But something like a 10 or 20kwh home battery would have helped a lot (it wouldn't sustain normal energy usage for that long, but the individual home owner could choose to ration the available power for critical functions).

You think the Oil and Gas industry is cleaner?

Recylable is important because it means we don't have to mine as much.