Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document architecture (how it works) #364

Open
FeodorFitsner opened this issue Jul 7, 2022 · 7 comments
Open

Document architecture (how it works) #364

FeodorFitsner opened this issue Jul 7, 2022 · 7 comments
Assignees
Labels
documentation Improvements or additions to documentation

Comments

@FeodorFitsner
Copy link
Contributor

  • diagram
@jamesdbrock
Copy link

Yes please. I’m trying to understand this. If I run a native Windows Flet application, how many processes are there, and how many layers of communication? Is there a Dart-based process communicating with a Python process? Is there a Dart webserver communicating by Websockets to an Electron GUI?

@jamesdbrock
Copy link

Oh there's some good information in here. /~https://github.com/flet-dev/flet/blob/main/docs/flet.md

Flet hides that complexity by replacing Flutter's declarative model (re-build a UI tree on app state changes) with an imperative (modify UI tree as program progresses).

Really? That's too bad.

@jamesdbrock
Copy link

Ok Flutter is an alternative to Webkit. So there is no Webkit involved here. It looks like there is a Flutter Dart process with bindings to the C++ Flutter engine, and then a separate Flet Python process which communicates with Flutter Dart through JSON and sockets? And I guess that the subject of that communication is UI events and VDOM diffs?

I was hoping that Flet has direct Python bindings to the C++ Flutter engine? No?

@jamesdbrock
Copy link

@jamesdbrock
Copy link

/~https://github.com/flet-dev/flet/blob/main/docs/flet.md

Flet hides that complexity by replacing Flutter's declarative model (re-build a UI tree on app state changes) with an imperative (modify UI tree as program progresses).

Flet hides the simplicity of Flutter’s declarative model by replacing it with complex imperative modifications to the UI tree?

@ndonkoHenri
Copy link
Contributor

ndonkoHenri commented Jun 21, 2023

The flutter guys explained it pretty well. For them, having to modify the states by oneself could sometimes be problematic. I find this true in Flet's case.

@FeodorFitsner, you master Flutter and Flet architectures, what can you say on this today please?
And also, why do you name it as 'hiding complexity'?
And by the way, could it be easy for Flet to switch on to the imperative style ?

The language runtime is also to be taken into consideration:

This approach relies on certain characteristics of a language runtime (in particular, fast object instantiation and deletion). Fortunately, Dart is particularly well suited for this task.

The question is, is python suited too? I think Yes. But we can't really know if we don't give it a try.

@FeodorFitsner FeodorFitsner added the documentation Improvements or additions to documentation label Sep 13, 2023
@ypankovych
Copy link

ypankovych commented Dec 24, 2023

@FeodorFitsner any updates here? Can we have detailed "under the hood" docs?

That would help people to use the tool with peace of mind (cause it is pretty uncomfortable to use a tool without good architecture knowledge), and what's more important, that should help people to start actually contributing to the project.

I'm trying to have some fun with it now, and I'm having a hard time understanding how the thing works.

@ndonkoHenri ndonkoHenri transferred this issue from flet-dev/flet Dec 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

4 participants