Sure, but at the cost of not being able to share logic between the two layers and giving up most of the advantages of native UI. For example, you can't have an encapsulated component that combines user input with validation that comes from the business logic - you'd have to have an input box that sends a message to the business layer when the user inputs a value and then the business layer does the validation and sends a message back.
Again, we are doing the messaging for years now, AJAX/REST are messaging protocols ...
I am not saying that this is the only way...
In Sciter you can use custom native UI components extending existing DOM - they can handle event, do custom painting, etc. And you can design those components in Rust, C, Go or whatever you like.
Like I said, you're no longer encapsulating the validation in the component, where it logically belongs from a business point of view. You're being forced to distort your architecture for these operational concerns. And it gets worse as your structures and UI get more complicated - e.g. if I want to validate several fields within a single database transaction, that's the sort of thing that Rust's ownership system is ideal for - each datastructure can know how to validate itself given a borrowed connection handle.
> Again, we are doing the messaging for years now, AJAX/REST are messaging protocols ...
Yes, and the overhead of having to serialise everything is the biggest problem with web UI. If you're going to separate the UI from the business logic like that then why even bother making a native UI at all?
