search

DioxusLabs / dioxus

Fullstack app framework for web, desktop, mobile, and more.
https://dioxuslabs.com
Apache License 2.0
21.44k stars 826 forks source link

desktop todomvc runtime Error missing field values packages/desktop/src/events.rs:85:62 #255

Closed omac777 closed 2 years ago

omac777 commented 2 years ago

Problem

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error("missing field `values`", line: 0, column: 0)', packages/desktop/src/events.rs:85:62
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Steps To Reproduce

Steps to reproduce the behavior:

Expected behavior

Expected the second todo item to appear in todo list gui.

Environment:

jkelleyrtp commented 2 years ago

Looks like our recent bump of wry to 0.13 interfered with serde parsing.

I just pushed a fix to master - can you confirm that this works for you?

omac777 commented 2 years ago

It is working now.

A native desktop app wouldn't or shouldn't require javascript to be built with the native gui gtk. I find it redundant for a desktop app. My worry is about bringing unnecessary cruft on its intended target.

Dioxus uses WebKit which depends on javascript. You are using WebKit everywhere. To Dioxus, every target is a WebKit browser and the Dioxus user provides .css files and .rs files holding "javascript/html snippet render code" for the app even if it's a native target os app.

Are you encouraging the continued use of javascript with dioxus? Yes because you depend on WebKit. Will Dioxus obviate the need for javascript? No because Dioxus heavily depends on WebKit which will always depend on javascript.

I have always associated javascript with "free-style" coding running on a 32-bit vm inside the web browser on 64-bit operating systems.

Web Assembly(WASM) Targets have similar problems in the plumbing: Web Assembly Byte Codes running on 32-bit vm inside the web browser on 64-bit operating systems.

I'm not a big fan of javascript/wasm as a result. Whenever possible, I usually opt for Native CLI / Native GUI.

I do respect your approach but I do have concerns about the long-term maintenance of such infrastructure and applications. Bringing in more dependencies like WebKit for native desktop apps complicates maintenance matters. I believe WebKit to be unnecessary cruft for native desktop apps.

With that said, for WEB APPS in Web Browsers, Dioxus is a valid approach to provide apps in browsers AS A SERVICE. It further strengthens the possibility of ensuring the app users are always using the latest and greatest version since they access the app through the browser on every request. The CURRENT WEB APP WEAKNESS is the 32-bit vm on which javascript and web assembly sit on. When this aspect is upgrade to a solid 64-bit standard, it will be truly valid but I believe it isn't ready now. Web Apps feel slower/buggier/less-reliable than Native apps especially when you bring in 3D/2D/Touch/Stylus Pen/other accessibility, very large files. GUI infrastructures are general-purpose and we need to ensure when we design something it can fulfill every use-case. QT can do touch/stylus. GTK can do touch/stylus. Web Browsers can do touch but stylus pen has issues so WASM/JAVASCRIPT/DIOXUS can't serve that audience properly.

Dioxus fails to be a general purpose gui infrastructure for web apps because it can provide the essential general-purpose input method support capabilities. 3D(WGPU)/HPC/GPUDirect/DirectStorage/Touch and stylus pen and other accessibilty(think handicapped) are still considered an after-thought and not a deliberation in the original gui design.

Perhaps in future if Dioxus can answer to these shortcomings within the WEB APP use-case, it could be a good infrastructure. GUI toolkits that have considered all these use-case scenarios QT and GTK.
On all OS'es and devices, accessibility and stylus pen support and related device drivers are tricky to set up and familiarize/customize for production/everyday usage. There certainly is room for improvement there but it exists.

jkelleyrtp commented 2 years ago

Dioxus fails to be a general purpose gui infrastructure for web apps because it can provide the essential general-purpose input method support capabilities. 3D(WGPU)/HPC/GPUDirect/DirectStorage/Touch and stylus pen and other accessibilty(think handicapped) are still considered an after-thought and not a deliberation in the original gui design.

You are saying Dioxus fails as a library for building web applications because we don't have special code for WGPU and Stylus Support?

I disagree - I think you can build a many number of accessible, beautiful, and performant web applications without needing to consider special code for WGPU or stylus support. I'd be happy to review any designs you have that improves our support for those things, but they are not the focus of this library. If you need deeper WGPU or Stylus integrations, then you should go through their respective crates (wgpu and web-sys).

I do respect your approach but I do have concerns about the long-term maintenance of such infrastructure and applications. Bringing in more dependencies like WebKit for native desktop apps complicates maintenance matters. I believe WebKit to be unnecessary cruft for native desktop apps.

The word "cruft" implies it could be removed while retaining functionality. If you have a desktop-ready HTML/CSS engine that doesn't have JavaScript but has good support for accessibility, I'd be happy to consider switching our desktop dependency. If we could enable desktop apps at the same quality as we have without JavaScript, then we would have.

And to clarify - on the Desktop your Dioxus app is running as native code. You can tokio::spawn from your components. The VirtualDom tree is converted into patches that are sent into WebKit.