3 ms·

> you can't have an encapsulated component that combines user input with validation that comes from the business logic. Why not? On UI layer I can always do:

> you can't have an encapsulated component that combines user input with validation that comes from the business logic. Why not? On UI layer I can always do: var response = bl.sendMessage("account.validate", accountData); if( response && response.valid) ... else if( response && !response.valid ) 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.

lmm 6y ago
> Why not? On UI layer I can always do: var response = bl.sendMessage("account.validate", accountData); if( response && response.valid) ... else if( response && !response.valid ) 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?