[HN Gopher] Dioxus: User interfaces that run anywhere
       ___________________________________________________________________
        
       Dioxus: User interfaces that run anywhere
        
       Author : nbrempel
       Score  : 157 points
       Date   : 2022-12-26 18:16 UTC (4 hours ago)
        
 (HTM) web link (dioxuslabs.com)
 (TXT) w3m dump (dioxuslabs.com)
        
       | fxtentacle wrote:
       | You should host your own copy of Tailwind CSS. As-is, it looks
       | broken with uMatrix.
        
         | nmilo wrote:
         | So allow Tailwind CSS downloads. The site looks broken because
         | you broke the site.
        
       | pomatic wrote:
       | Runs anywhere... except embedded platforms? (And no, android
       | doesn't count so far as embedded platforms are concerned).
        
         | IshKebab wrote:
         | 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.
        
         | mike256 wrote:
         | Also <2mb doesn't really seem lightweight to me...
        
           | jkelleyrtp wrote:
           | 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!
        
           | yazzku wrote:
           | 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.
        
           | h4x0rr wrote:
           | If it runs in a webview it ain't lightweight
        
       | lilyball wrote:
       | This sounds neat, but something sorely missing from this page is
       | ahh mention of accessibility. Does Dioxus integrate with the
       | platform-native accessibility APIs?
        
         | jkelleyrtp wrote:
         | It uses web tech so all the accessibility is built right in!
        
           | littlestymaar wrote:
           | In another comment you mentioned some ongoing work on a
           | native back-end, how is the accessibility story going in this
           | scenario?
        
             | jkelleyrtp wrote:
             | 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.
        
       | bmitc wrote:
       | 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.
        
         | jacoblambda wrote:
         | > 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
        
           | bmitc wrote:
           | I read that. LiveView is a specific Elixir package and
           | solution. Is LiveView synonymous with server-side rendering,
           | independent of Elixir?
        
         | jkelleyrtp wrote:
         | 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.
        
       | pdntspa wrote:
       | Are there any cross-platform native UIs for Rust? Something like
       | wxWidgets or GTK?
        
         | manmal wrote:
         | 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
        
           | nicoburns wrote:
           | 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.
        
             | ptato wrote:
             | I'd like to know the name of these libraries.
        
         | formerly_proven wrote:
         | 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.
        
           | pdntspa wrote:
           | 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
        
           | nicoburns wrote:
           | > 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.
        
           | jcelerier wrote:
           | > 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"
        
           | rstat1 wrote:
           | I would certainly prefer properly written native software to
           | web-based junk pretending to be native.
        
           | bmitc wrote:
           | 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.
        
         | nicoburns wrote:
         | 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.
        
       | 082349872349872 wrote:
       | 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...
        
       | jkelleyrtp wrote:
       | 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.
        
         | pieresqi wrote:
         | 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 ?
        
           | demonthos wrote:
           | 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
        
         | fnordpiglet wrote:
         | 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?
        
           | demonthos wrote:
           | 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.
        
         | ipnon wrote:
         | 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!
        
         | amelius wrote:
         | What is the (minimum) application footprint?
        
           | jkelleyrtp wrote:
           | 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.
        
         | vorpalhex wrote:
         | 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?
        
       | Existenceblinks wrote:
       | 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.
        
         | jkelleyrtp wrote:
         | 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.
        
       | tomcam wrote:
       | 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.
        
       | ronreiter wrote:
       | I like the fact that the website isn't responsive
        
         | midasz wrote:
         | Huh? When I make the screen smaller the layout adjusts
         | perfectly
        
         | [deleted]
        
       | fallat wrote:
       | 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.
        
         | nicoburns wrote:
         | 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/
        
           | CryZe wrote:
           | > 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).
        
             | nicoburns wrote:
             | 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.
        
       | account-5 wrote:
       | I wonder how this compares to Dart/Flutter which runs pretty much
       | everywhere.
        
       | satvikpendem wrote:
       | 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.
        
       | cuu508 wrote:
       | 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)?
        
         | nicoburns wrote:
         | 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.
        
         | rhodysurf wrote:
         | It provides mobile and desktop via tauri. It's just a web
         | framework
        
           | agency wrote:
           | And IIRC Tauri defaults to using the OS webview so you can
           | ship very small binaries.
        
       | eikenberry wrote:
       | 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.
        
       | brap wrote:
       | >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
        
         | nicoburns wrote:
         | It doesn't... yet. But that is being worked upon. Native
         | renderer is here: https://github.com/DioxusLabs/blitz
        
           | brap wrote:
           | 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.
        
       | _boffin_ wrote:
       | It looks like everything is moving to a lisp-like structure.
       | brackets... brackets everywhere.
        
         | rcoder wrote:
         | 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.
        
           | genezeta wrote:
           | 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_.
        
             | steveklabnik wrote:
             | You only need two spaces, not four.
        
               | genezeta wrote:
               | Ah, yes. You're right, it's 2 :)
        
             | amelius wrote:
             | How do you get a literal asterisk?
        
               | steveklabnik wrote:
               | Either                 \*
               | 
               | or                 **
        
       | gabereiser wrote:
       | 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.
        
       ___________________________________________________________________
       (page generated 2022-12-26 23:00 UTC)