Dioxus: User interfaces that run anywhere | Hacker News Reader

Dioxus: User interfaces that run anywhere

dioxuslabs.com

391 pointsnbrempel145 comments

Creator here - ask away! We added a bunch of new features to master that haven’t been released yet, like liveview, WGPU renderer, instant hot reloading, autoformatting, and more.

What is the (minimum) application footprint?

On the web, you can get the final bundle down to about 60k gzipped, which is comparable to react.

The average desktop/mobile binary is less than 2mb, but that’s with zero size optimizations to shrink the output. You can certainly get less.

Dioxus runs on a native thread and renderers into the webview, so there’s very little JS footprint and the render resources are shared among all webview on your system.

I haven’t experimented with it, but it’s entirely possible to run on a raspi with webkitgtk. We’re building a native renderer with WGPU and already support rendering to the terminal.

> Dioxus runs on a native thread and renderers into the webview, so there’s very little JS footprint and the render resources are shared among all webview on your system.

So I need to have some sort of WebView library pre-installed? What WebView would that be on, e.g., Linux? And is it possible to include it in the build to create a standalone binary? If so, how much would that make the binary size go up?

In my experience, relying on a system-wide WebView is a recipe for desaster.

For most platforms relying on the browser’s webview is fine since most platforms ship with a browser! But you can always specify WebKitGTK as a dependency which I think is a one time 2GB cost.

Hi, home site doesn't run without enabled js jit. Are there any plans to not rely on jit or that's not possible ? Or it's caused by 3rd party plugins ?

The homepage is built with Dioxus so it uses Javascript and WASM right now. Dioxus does support ssr (https://docs.rs/dioxus-ssr/latest/dioxus_ssr/) which could be an option to support better progressive enhancement in the future

Looking for screen shot and capability description of the TUI renderer - how likely is it to be able to cross build the same UI across renders?

Building an application that works with TUI, web, and desktop is possible but there are some differences you need to keep in mind. The TUI renderer has a different scaling factor than the web renderer. One pixel is one character and Widgets have start with a capital letter with the web renderer, but for the attribute and elements that the TUI renderer supports the goal is to behave as close to possible to the web implementation. There are some differences that will likely remain because of the differences of the terminal platform, but we would like to continue working on minimizing these differences in the future.

I assume you can easily case for rendering specialization?

You can use rust's feature flags with one flag per renderer to specialize based on the renderer

What do you think the main challenges are with implementing LiveView? How do you think it will ultimately compare to Phoenix for web apps, and more generally? It looks like a good project!

How's support for older systems? Will apps run nicely on older 32bit systems or older windows versions? What does the platform testing look like?

Dioxus desktop uses Wry (one of the libraries Tauri is built on) which requires WebView2 on windows. You can install this on windows 7 or include a bootstraper. All windows versions after 7 have WebView2 pre-installed. In theory, 32 bit machines should work out of the box although I haven't tested it.

Dioxus runs its test suite on modern versions of windows, macOS and linux

What's the maturity of Dioxus right now, and what's the roadmap for that with rough dates?

After flipping through the different target platform info, looks like the front page claims are partly aspirational, not currently implemented or integrated.

(Reason I ask: Coincidentally, I'm just starting a new TUI project with Cursive tonight, but looked at Dioxus when I saw it on HN, because I'd love to not have to keep relearning different UI toolkit bureaucracies, for also doing Android&iOS, Web, and Linux desktop. But I've seen countless cross-platform GUI toolkit efforts over the decades, and unclear how mature Dioxus is going to become.)

Dioxus is still pre-1.0. We will try to minimize unnecessary changes, but there will be breaking changes between 0.x releases. This allows us to keep iterating to find the best approach. If you are willing to brave some breaking changes and bugs, try Dioxus. If you want a mature framework you might want to choose another project. I don't know of many mature rust frameworks but there are many more mature Javascript frameworks to choose from.

Here is a rough roadmap: https://github.com/DioxusLabs/dioxus/blob/master/docs/guide/...

The major projects for the next year are to improving the native render (Blitz), the full stack framework (Tokamak), Router, and subtree rendering.

Thank you. That platform status might be moved to the home page, and also updated (e.g., to add TUI, clarify the state of Android, clarify when it relies on a partner project, etc.).

I hope this Dioxus is very successful, since I'd love to be doing all this work in Rust.

why not break the 0 and do major releases whenever you break something?

i wouldn't leave 0.x until its somewhat complete and stable. I'd be kinda mad as a consumer if it was labeled 1.0 but was missing half the essential features and 2.0 came out 2 months later (also incomplete)

What’s the story surrounding cross platform MIDI support? I don’t expect it to be a priority but it’s something that I was looking into with Flutter/Dart, it would be killer to have.

For Dioxus web and desktop (webview), we provide a use_eval hook to execute Javascript that should allow you to use interface with MIDI

very cool however

wifi scanner is named bluetooth scanner and doesnt show any networks. im typing this on wifi. also code has 15 levels of indentation.

weather app search doesnt work

e-commerce cant fake-buy anything

dog-app lit says instagram, nothing is clickable, tons of deeply nested jss

The frontpage doesn't mention microcontrollers. What's your plan for them, and what kind of microcontrollers will you target (memory and performance)?

I'm assuming there is a plan given "run anywhere".

You can already run Dioxus on an SBC. I’m not sure it’s realistic to run on an stm32 without some real limitations. IMO “everywhere” means everywhere in the physical sense, like desktop, mobile, server, AR/VR, handhelds, etc. we can’t support something like a Pic-8 ever, so it’s not worth trying to qualify that.

Thanks for the reply.

Given Qt, Slint[1] and similar, and Rust being supported on a lot of embedded platforms, it didn't seem out of place to imagine it on an higher-end STM32, ESP32 or similar.

Will definitely dig deeper, looks interesting.

[1]: https://slint-ui.com/

How do I import my UI files made with Design Studio?

How is the accessibility? I can't find it mentioned anywhere on your pages.

It uses HTML as the base so accessibility is built right in. As we stray into more custom solutions, then we’ll use accessibility kit, but since in the short term it’s all rendered straight to the DOM, we get it for free.

I pressed the play button the the first example on the guide page and it gave an error about a missing macro.

The rust docs don’t run UI libraries with any helpful output.

Maybe it's because I'm not very experienced with web development but I have a hard time wrapping my head around this and unfortunately the tutorials didn't enlighten me either.

How is this used on a very high level? Is this a pure front-end framework? So, let's say I write an app using Dioxus. Then the input are .rs files but what is the output? For desktops: an executable? For web: a folder with HTML/JS/CSS?

And how does this work under the hood? Is it drawing all UI elements from scratch using Canvas/WebGL? Or is it more like a translator that fills a regular DOM at runtime and uses that for rendering?

Dioxus is HTML native so it speaks in native HTML elements to solve the flutter problem.

It’s written in Rust so it doesn’t need a JS engine which gives it this huge portability. Your intuition on the outputs is correct. For the web, you get a folder of HTML, CSS, and the tiniest amount of bootstrapping JavaScript. For most other platforms you get a small binary that is self contained.

This sounds neat, but something sorely missing from this page is ahh mention of accessibility. Does Dioxus integrate with the platform-native accessibility APIs?

It uses web tech so all the accessibility is built right in!

In another comment you mentioned some ongoing work on a native back-end, how is the accessibility story going in this scenario?

We’re leveraging the work done by Druid so the plan is to use AccessibilityKit as the foundation. Our native renderer is essentially a GPU-accelerated HTML/CSS renderer so we’ll pull in all the accessibility tech there. We don’t want people to learn anything new to get started, so sticking with web foundations is smart even if it’s not as great as a bespoke solution.

Thanks for your answer. This part confuses me a little bit though:

> Our native renderer is essentially a GPU-accelerated HTML/CSS renderer

You'll just implement a subset of an HTML/CSS renderer that is capable enough for a specific subset of HTML and CSS that Dioxus generates, you're not planning to develop a fully browser-compliant HTML/CSS renderer, right?

We’ll implement what it takes to hit the majority of CSS we run into. The Rust ecosystem has some great packages for CSS and layout (we and Bevy comaintain Taffy) so at a certain point it’ll be filling in the blanks.

Being browser compliant would be great, but just being 70% of the way there would be cool too.

> Being browser compliant would be great, but just being 70% of the way there would be cool too.

Thanks. I think aiming a 70% compatibility is a realistic goal, going up to 90% would probably need 10 times more efforts, and 95% ten times more, with 100% being unreachable anyway because no two browser behave exactly the same.

"Web tech" could mean WebGL or Canvas, which are not accessible. Does it create HTML elements?

I'd check myself, but none of your examples seem to be available to just look at without cloning the repo locally.

If you dig into the library a bit more you’ll find that it renders native HTML elements.

That doesn't mean much on its own. 30 nested <div>s with auto-generated IDs and all input handled in JS also counts as "web tech", but I wouldn't want to subject any screen reader user to that.

Honestly, full AT tree support is minimum table stakes at this point. If a toolkit’s documentation doesn’t say how that support is of course there because they started with it in mind, then it’s an automatic skip for anyone building production systems that are expected to be live in the US, Canada, Israel, Australia, Norway, the EU (in 2025), etc etc.

Dioxus renders HTML. Right now using WebKit, but in the future, its own engine with the same accessibility libraries that power the platform’s accessibility with the layer to get from HTML.

There are webview mentions, so I assume the user interfaces are built with HTML and CSS? Do the apps bundle the renderer (like Electron or Sciter) or use the OS webview (like Cordova)?

It provides mobile and desktop via tauri. It’s just a web framework

And IIRC Tauri defaults to using the OS webview so you can ship very small binaries.

…at the cost of running into annoying and hard-to-reproduce bugs because not all WebViews are created equal. (Safari WebViews, I'm looking at you!)

Dioxus is kind of like React - it's renderer-agnostic. It has a browser renderer, one based on Tauri (OS webviews), a TUI renderer, and a native renderer (wgpu) is planned.

Isnt Yew (https://yew.rs/) similar in regard of the react like way to update the html document? I understood that Dioxus goes beyond and is the whole platform to run the app by including a webview, but wouldnt make sense to have another framework like yew as dependency to manipulate a "Virtual Dom"?

Dioxus uses the virtual DOM as the core that allows rendering to many different platforms. Yew and Dioxus are somewhat similar but Dioxus represents it's virtual DOM very differently internally. Because of the way Dioxus' virtual DOM is made unlike Yew, Dioxus will never diff the static parts of a component (read more here https://dioxuslabs.com/blog/templates-diffing)

Is this like Flutter? I see they say you can use a WGPU based renderer but it seems like the desktop and mobile apps are still akin to using a webview which isn't a great user experience.

Right now Dioxus uses webview for all platforms except TUI and blitz.

Why? Choosing to use a webview renderer initially allows us to support many platforms quickly with fully featured renderer and accessibility built in. Comparing to Flutter targeting a web based model also allows our web renderer to render using elements instead of a canvas, and has a much smaller bundle size.

Dioxus is render agnostic and the plan for the future is to invest more time into blitz (our native renderer). This will allow us to achieve native performance on desktop and mobile.

Makes sense, thanks. What do you mean by native renderer, is it like React Native where Dioxus calls are transformed into native system UI calls but keeps a JS bridge (which can sometimes be slow), or like Flutter which draws every pixel on a custom canvas but which is able to be compiled to machine code?

More like flutter. Your code is compiled to machine code. It uses wgpu to render to desktop and mobile naively

So I use Flutter currently and it seems like they're doing quite a bit of work to get everything to work well together on all of their platforms, with varying levels of success. How do you plan to handle all of that complexity as well, and compete with them, so to speak? I don't mean compete in a negative way but as a developer, I should be able to look at the pros and cons of all these Flutter-like frameworks popping up in different languages and choose the best one.

so do you get a non-native experience because input fields etc are not implemented by the OS where all the IMEs and accessibility works?

Widgets are currently not implemented, but we plan to integrate with access kit to provide accessibility for applications built with Blitz

Is the LiveView reference referring to integration with Elixir's LiveView or is it just a poorly chosen name for some Rust thing?

On desktop, does it support multiple windows? I can't find any information. I'm generally not a fan of multi-target UI platforms, as desktop is almost always de-prioritized compared to mobile and web.

LiveView here describes the approach, not the integration with phoenix. Multi-window support is coming. You can hack it together today, but we’re actively upgrading the core architecture to support multiple renderers per UI tree for declarative multi-window setups.

> Is the LiveView reference referring to integration with Elixir's LiveView or is it just a poorly chosen name for some Rust thing?

Looking at the docs, LiveView is referred to as Server Side Rendering so I'm guessing yes

I read that. LiveView is a specific Elixir package and solution. Is LiveView synonymous with server-side rendering, independent of Elixir?

I haven't seen it used that way outside of the elixir space but I suppose it could be catching on in some dev spheres.

Sounds interesting, but where are there some basic screenshots of what it looks like on various UI platforms? The screenshots on the homepage all link to sample app repos which (at best) just have a single screenshot of the app running on a single platform.

It renders HTML and CSS. It looks like what HTML would look like.

Runs anywhere... except embedded platforms? (And no, android doesn't count so far as embedded platforms are concerned).

Weird nitpick. There are almost no GUI toolkits that run everywhere, including embedded systems (i.e. microcontrollers). The only one I know of is Slint.

LVGL is good. https://lvgl.io

Then maybe they shouldn't claim it runs anywhere.

It's not a nitpick to point out that the explicit claim of running everywhere is horseshit.

Doesn't run on my fridge? Liars.

Also <2mb doesn't really seem lightweight to me...

If it runs in a webview it ain't lightweight

For a web-based UI, if it manages to stay in the single-digit range I'd call that acceptable for all the functionality that you get in return. And I say this being skeptical of anything web-based in general.

You can get down to less than 60k. It’s just the average binary that links in various system resources with no size optimizations comes out at around 1.5mb. Tiny for desktop!

Was this website written in it? It’s awful on mobile. :/

Surprisingly no issues here in Firefox or Chrome mobile. What's wrong with it?

Maybe the code editors could use some horizontal padding, otherwise it looks just fine on iOS.

First impression, the landing page renders quite wrong on my phone. Viewport is too wide and I'm able to scroll left/right. Got some work to do on the running anywhere part I guess. Or maybe that's just the landing page. Either way there's work to be done somewhere.

Nearing the end of a deadline so can’t explore too much, but this work looks comprehensive in scope. Lots of docs already, tons of complete examples. Can’t wait to learn more. Not a Rust guy but loving the examples.

Am I crazy? I went to built a TODO app and almost 70% of the docs are blank pages. Anything "Advanced Guides" and onward.

Just for posterity, the documentation was updated and looks to be complete.

Dioxus doesn't exactly manage anywhere yet, but it would be cool if it eventually included things like rendering to phone response tree: push 1 for X, 2 for Y...

I like the fact that the website isn’t responsive

Huh? When I make the screen smaller the layout adjusts perfectly

Thought it was ironic to see “user interfaces that run anywhere” only to see the landing page break the viewport on my phone.

We’re using tailwind and it looks like the media breakpoint is set for a size too big/small. Should be easy fix!

I got an empty page myself.

Black screen, no content, no text selectable, no interactive component.

Running Firefox 108.1 (24234) on latest iOS 16.1.3 with sunrise/sunset dark/light screen mode (currently dark)

Also getting a blank (white) screen here, Safari on iOS. Disabled iOS lockdown mode for the website domain out of curiosity and that seems to make the page render correctly.

Not willing to undo the lockdown here.

You should host your own copy of Tailwind CSS. As-is, it looks broken with uMatrix.

So allow Tailwind CSS downloads. The site looks broken because you broke the site.

I long for the day blockers are so ubiquitous that sites not working with them is considered a bug that developers will be forced to fix.

This isn't a rock, it's a cup of delicious stone soup. It's perfectly edible once you've gone around the village requesting garnishes from random strangers.

Are there any cross-platform native UIs for Rust? Something like wxWidgets or GTK?

The question is why would you want something like that? Native is meaningless on non-Apple platforms. For Windows, wx is nowadays the opposite of a modern native Windows app, because it uses Win32. Gtk is "best viewed on" a Gtk-based Linux desktop. Qt Widgets, much like wx, emulates the LAF of Win32, so doesn't look correct any more on Windows. Qt Quick is a modern hardware-accelerated UI toolkit, but that's not a unique thing any more.

> For Windows, wx is nowadays the opposite of a modern native Windows app, because it uses Win32.

idk, whenever I have to use win32 and I see some app which uses the win32 widgets i'm like, "finally some good software"

I would certainly prefer properly written native software to web-based junk pretending to be native.

I guess you can consider me a fan of WinForms. Besides, you can change the background color and add a stupid amount of padding to everything and voila, you now have "modern". Hell I used to have something for C# that did exactly that and made WinForms apps look like they were made for Windows 10. It was pretty cool, ngl

I've been tinkering with wxPython since I can't get pygobject to work in Python 3 in Windows. It really isn't that bad, certainly not nearly as weird as trying to wrap my head around folks' awful (are they ever not?) React codebases and this moronic idea that everything has to bundle Chromium

Also you really can't beat an instantaneous cold startup time. It's the tits

Why is anything based on Win32 not native on Windows? As far as I know, it's the only way to create a window on Windows.

> The question is why would you want something like that?

Simple. You want to be able to make cross-platform UIs that are more performant, less resource-intensive, and more extensible than electron apps.

> The question is why would you want something like that?

Some of us want stable software that feels fast and responsive and doesn't lag on high-end machines while using 2GB of RAM despite being extremely simple

I‘d probably look into Skia first, it also drives Flutter. https://github.com/rust-skia/rust-skia

It doesn’t render native widgets though, AFAIK it’s „just“ OpenGL/Metal/Vulkan/CPU-rasterization.

EDIT: Someone is already working on a Skia adapter for Dioxus: https://github.com/marc2332/freya

Skia is cool. But I don't think it's going to end up being the solution for Rust graphics. There are already rust-native libraries that do most of what Skia does, and they're a lot easier to build.

I'd like to know the name of these libraries.

You can use GTK from Rust. But the Rust native ones aren't really there yet. [Iced](https://github.com/iced-rs/iced) which has been picked up by System76 and [Druid](https://github.com/linebender/druid) (and it's next gen version [Xilem](https://github.com/linebender/xilem)) are the ones to watch, along with Dioxus which is the main post here.

I'd expect there to be something useable by the end of 2023.

You forgot to mention [Slint](https://github.com/slint-ui/slint)

> picked up by System76

I missed that. Previous discussion https://news.ycombinator.com/item?id=33066593 and some updates and upstream contributions in https://blog.system76.com/post/november-at-system76-products...

There are some, the most promising of which to me are slint (runs anywhere, includes custom IDL), druid (from the xi-editor folks) and xilem (new architecture, from the druid folks)

I wonder how this compares to Dart/Flutter which runs pretty much everywhere.

As someone who has used both...

1. Dart is a terrible language with no signs of improving, Rust is somewhat decent

2. Flutter is terrible on the web, this isn't.

>User interfaces that run anywhere. Written in Rust, inspired by React

Wow! I was wondering if this exists TODAY. Even did a quick search but couldn’t find anything. Wild.

Edit: oh, doesn’t seem like it uses native UI

It doesn't... yet. But that is being worked upon. Native renderer is here: https://github.com/DioxusLabs/blitz

I think this could really be the selling point, high performance native & web UIs. Nothing like it exists.

I imagined something like React & React Native, except implemented in a performant compiled language and runs anywhere using WASM.

But now that I think about it, maybe React/RN will be able to switch the core to WASM and keep the user code in JS, maybe this will be good enough for performance while still being more developer friendly.

Isn't that Flutter?

Flutter is quite terrible on the web. I don’t think they use WASM either, I think Dart just gets compiled to JS.

Yeah it's not too great on the web but they are working on WASM as well: https://news.ycombinator.com/item?id=33908134#33910235

> One project that extends Blitz is SciViz: a high-performance plotting toolkit for Rust and Python.

Is SciViz available somewhere yet?

Seems to be at https://lib.rs/crates/sciviz, but a very early version? The Docs link goes to another project.

> Edit: oh, doesn’t seem like it uses native UI

(note I'm not talking about you specifically here)

There are many solutions out there that "run everywhere" (that matters) and it's always some variation of this compromise.

I get the obsession of having things run natively, but at some point you have to ask yourself if it's really that important.

This reminds me of people who want a game, but spend most if not all of their time trying to find the perfect game engine or even trying to make their own engine. I get it, it's fun. But it can potentially be mentally exhausting if you want an end product and a perfect prebuilt framework.

Personally I just enjoy building frameworks and tooling and find happiness just doing that. If I were to make a product I'd be using something that works well enough and try to leave my obsession with finding/building the perfect framework out of it.

Anyone here have data on how many commercial apps built with each of these framework? There are quite many, but even Tauri has most of show cases as random free apps.

Satellite is building their startup’s app with Dioxus!

https://github.com/Satellite-im

Dioxus is still less than a year old, but it’s getting more and more use.

That looks like a solid business. Is there any risk to the business, like lack of a certain feature?

In 2007 I said that the future of all apps is html/js/css. I knew the front-end space was going to get complicated (it did) and that to really change the game (ie, force a standard in UX) it would have to be web based. I wrapped chromium in a Java applet for travel kiosks (now mobile is king), I wrapped chromium in C#, in Python, in Go, all to make web tech the standard.

I loved electron before it got bloated, I found NW.js before that and wished it was more popular and had more love. I contributed a swig wrapper to webview to support any language you wish (swig interface naming amalgamations aside).

Keep going!!! I want a world where I can write an app for any platform and it spits out some standardized UI that could be augmented with some CSS. I’m super interested in this.

Just like the old Joyent "Slingshot". https://daringfireball.net/linked/2007/03/23/slingshot

> I found NW.js before that and wished it was more popular and had more love

nw.js made me appreciate HTML5 so much.

I ran into bugs with literally every single nw.js API I used in the application. Here's a taste:

* nw.js window menu: arrow keys don't properly navigate across menus, accelerator shortcuts randomly break (bog standard ones like <ctrl-1>), some weird race condition displaying the menu which affects the dimensions of the document that get returned by the DOM, inability to change an accelerator shortcut during runtime, and many, many more

* at one point, the nwworkingdir attribute for input tags didn't work unless I injected the tag/attr/value as innerHTML

* win.zoom and menu.popup didn't play well together

* many others

On the other hand, the only HTML5 limitation I can remember was that SVG's getbbox will include clipped content in the returned bounding box. There's apparently a newer option to exclude the clipped areas, but AFAICT it isn't honored in any of the browsers.

So each time a user would submit a bug, I'd get a sinking feeling because I just knew it'd be some weirdness in one of the nw.js APIs which would have scant documentation. If that turned out to be the cause of the bug it would either be unfixable or require really nasty kludges to work around. (E.g., at one point nw.js didn't play well with the @font tag, but after hacking I figured out that it would work if I included the font inline in the relevant css as a data url.)

On the other hand, if the bug had to do with my own buggy js code or a misunderstanding of the DOM, I'd get excited because I knew there'd be 1000 pages of documentation, 10 years of various workarounds (most with code examples on SO), and probably even a blog with smooth animations showing why that part of the DOM works the way it does.

They compare to Electron multiple times which makes it seems like it would run as a service with protocol layer support for the defining the UI and callback or something. But it looks like yet another UI framework/library that will only work with the implementation language (and ffi).

The lesson of Electron is that a server/protocol based UI is better than a library. Particularly a large/framework library that requires a lot of resources and is limited in scope would be better done this way to increase it's audience and participation.

>hooks

Why do you keep copying worst parts of react

It looks like everything is moving to a lisp-like structure. brackets... brackets everywhere.

Declarative syntax to express {HT|X|...}ML/DOM-like structures in your source code are a big win if that's a significant percentage of the boilerplate code you have to write.

E.g.:

Literal HTML

``` <div class="active">Hello!</div> ```

Procedural JS

``` let elt = document.createElement('div'); elt.setAttribute("class", "active"); elt.innerText = "Hello!"; ```

Rust literals + HTML macro

``` html! { div(class: "active") { "Hello!" } } ```

Modern Lisp (Clojure, Fennel, et. al.)

``` [:div {:class "active"} "Hello!"] ```

Dunno about you, but when I'm comparing my template source code to the materialized DOM in my browser dev tools, the latter is a _lot_ simpler for me to reason about.

Just so you know in case you don't, if you remove the ```backticks``` and just indent the line by 4 spaces it will be presented in a monospace font, like...

    <div class="active">Hello!</div>

Ah, you can also get italics using asterisks instead of _underscores_.

How do you get a literal asterisk?

Either

\*

**

Testing, *, *

Edit: it works

The documentation is https://news.ycombinator.com/formatdoc, found via the FAQ link at the bottom of the page.

You only need two spaces, not four.

Ah, yes. You're right, it's 2 :)

Canvas-like APIs are universal. What people want I guess is "text inputs and buttons with flexbox anywhere". Oh, and that it mimics component based dev. Concepts are more reusable than software.

It's coming. Flexbox (and CSS Grid) are implemented in Taffy [0]. Multiline text rendering and layout are implemented in cosmic_text [1]. Dioxus linked here implements a component system with state management and reactivity. It's all quite new though (cosmic text was only released 2 months ago, and it's only gotten to "mostly feature complete" as of a few days ago) and it hasn't all been combined together into a complete framework yet.

[0] https://github.com/DioxusLabs/taffy [1] https://docs.rs/cosmic-text/latest/cosmic_text/

> mostly feature complete

I just played around with it today again and I immediately ran into like 5 bugs with font matching until I found out that there's not even an implementation for font matching other than "every property has to match 100%" (and if not, it falls back to an emoji font which is another bug), so there's not even the basic CSS font matching algorithm implemented (and the state of the fallback algorithm might be even worse then, as unlike the nicely documented CSS font matching algorithm, the latter is the undocumented hard part).

Yeah, I think cosmic_text doesn't really have a good story for font matching yet, but it's done most of the hard shaping/layout bit, which was the bit that was previously missing in the Rust ecosystem.

Having spent some spare time working on a package manager for OS X Tiger / PowerPC, I’ve had to learn to take “runs anywhere” with a giant grain of salt.

You know, you can't just say "anywhere". User interfaces are used on microcontrollers, on embedded systems, on legacy systems, on odd platforms, on old platforms. Rust certainly doesn't target all of those, or even most of those, and not even many of those.

Even statements like, "One codebase, every platform" are just... wrong.

And if they were right, would have so many compromises nobody would use them: we have different platforms because we have different constraints, and that percolates up to the interfaces.

Anyone else bail as soon as they saw “inspired by React” on the splash page?

Reply on news.ycombinator.com