Architectural Idea / Question

[JeffGillin]

Forgive me if this is not the right place for this conversation. I didn't see much going on with Yew on StackOverflow. If somewhere else is better, please let me know and I'll remove it from here.

I've been thinking a bit about RUSTs role in UI development, and being able to make re-use of code between Web, Mobile, Desktop. I know that, for instance, you can develop all your front-end application logic in RUST for pretty much any UI -- Mobile, Web, Desktop. I know Yew itself is specific to web assembly, however, depending on framework layout of non-UI components, it may or may not be a challenge to share code between different types of front-ends
I haven't dug into the details of Yew yet. Just starting to look at it, but wondered if this concept of having application code fairly agnostic to particular UI implementation is part of Yew's goals. I'm not thinking in terms of anything UI specific -- but simply keep the implementation of non-UI stuff (network communication, thread-handling, etc) done as an abstraction that can be easily swapped out (configurable) so that application code itself wouldn't need to change when switching from a mobile UI to a web UI -- have a service layer that can be re-used "as-is" between a flutter app, and a Yew web-assembly app. And you could have a VSC workspace, for instance, that included flutter and yew projects side by side referencing the same rust library (for application code) - albeit in different ways (dynamic for flutter).

[sirrodgepodge]

The potential for a "yew-native" so to speak :)

I believe the way React accomplishes this is by maintaining separation between:
-The Virtual DOM + its diffing engine
-The "reconciler", i.e. the way diffs get applied to the UI

The reconciler can then be replaced to be target-specific. React 16 actually exposes an API for you to make your own:
https://github.com/nitin42/Making-a-custom-React-renderer

Just sharing what I know from JS-land in case that's useful.

[erlend-sh]

There’s a fairly close example implementation for this now in https://github.com/ivanceras/sauron-native by @ivanceras.

[OscarRL]

Actually we have few cross-platform libraries like React/React Native, IONIC/Angular. They are really nice but these libraries have their cons that are hard to solve.

First, JS-based frameworks makes it hard to scale to large code bases and have less performance than Rust. TypeScript/Flow are nice but they fail in the practice because the type system is not present at runtime that sometimes leads to a wired behaviour at runtime, creating the “WTF” effect.

• React/React Native: JS-based. Still needs to work with vendor-specific things. Hard to debug native elements when failing on the Android, Objective C or Swift side.
• IONIC/Angular: JS-based. No native elements that make it more harder archive high performance, Cordova helps but there is no React support. No declarative approach. Hard to debug when native component fails.
• Flutter: Custom UI library that mimics the native ones. Nice thinking but the current web project is rendered over a canvas that makes it really hard, or impossible, to make SRR or SEO-engine optimizations. Dart has poor server-side/backend support, compared to Rust.

Also:

• Yew is an awesome library with a declarative approach that makes it easy to make awesome UI's.
• Rust can compile to all native targets wasm, x86( windows/linux ) and arm ( Android / IOS ) with extreme performance and memory safety.
• There are some Open Source IOS UIKIT, Android, GTK... bindings, for example https://github.com/ryanmcgrath/cacao.
• Rust can work on server-side. This means that we can do everything with just 1 language and 2 SDK yew & backend(actix?)! Specially with SSR.
• Wasm seems to be compatible with near all the browsers now. Yew and similar libs will gain momentum in the future.

This makes Rust the perfect target to create a front-end framework that can rule the world.

Market space:

Yew + some backend tech, like actix, can create an ecosystem to build apps for all of the platforms and build its server side counterpart by using the same technology minimizing the production costs and increasing the productivity, covering more than the 90% of use-cases( Native-apps/Hybrid/PWA + website + backend). 1 language with just 2 frameworks.

I think that small startups needs a single way to build their platform and make it bigger. Actually React/Angular + Express approach is nice but when the code-base starts to be bigger it can convert, easily, to a bunch of spaghetti-code. Then, the usage of TypeScript and Flow can help but is not perfect as a compiled language.

On the server-side, NodeJS is nice but 99% of the libraries are a “wood-sword” to kill a “dragon”, like mentioned in the Toggle comic over Python. Some other libraries are made in C++/Rust/Go and then loaded by using Node FFI, the problem with these ones is that they can’t be debugged when something weird happens, and 0 support on the browser.

Special things to take in count

• No CSS support outside the browser world. Maybe we will need to create an engine that interprets the CSS-like rules and map them to the specific native platform. ( is it a project of its own? )
• Animation support in the browser world is the CSS because is the "high-performance" approach to perform animations. Also we have the Animation API. Wasm requires to "touch the dom" that maybe can be slower than CSS approach. Some kind of "common API" should be created.
• Rest of the HTML5 API’s like geolocation.

Actions to perform:

Actually I don’t have knowledge of all the Yew internals but in general I think:

1. De-couple Yew core from std_web and web_sys dependencies making some kind of abstract interface.
2. Create a build system that selects the implementation of a specific component or class for the target platform during build time and/or runtime. This will create the ability for the community to build libraries and maybe implement the Web API in different platforms.
3. Create an interface to build components, and document it, to allow the creation of components in other platforms by the community.
4. Build platform-specific extensions to build to a specific platform. We can start with GTK or something similar, community rules here.
5. In the future, make a cross-platform extension based on the last ones that can build to a given target and automatically select the implementations for each build target. A single Button element that can be rendered in AndroidX.Button, GTKButton or Cupertino.Button based on the platform.

Note: SRR can be a build target also.

We should move the 1rst and 2nd points that will allow the community to work on the rest of the parts and the creation of a “How-to” page for the creation of platform-specific components or libraries to let the people know where to start with.

In resume: Yew-native can be awesome if we can create some declarative experience html-based without the React Native problems and native performance similar to Flutter.

[ivnsch]

I found this looking for a "react native"-like yew implementation and finding this discussion very interesting... Rust is perfect for mobile development (or pretty much everything 😉). I compromise currently with native UIs + shared Rust binary but it would be great to be able able to write everything in Rust and yew is amazing to work with!