Web lists-archives.com

Reconciliation, diffing algorithm and functional approach to Model-View-Controller pattern




Héllo all,


td;dr: What do you think of ReactJS (native)? How can this be applied to GTK+?


First, I'd like to thank you as whole for what you've done as a community,
for your very existence and making possible what I am today. You sparked
in me the passion of programming and the idea that together we write better
software when it's free software. Sadly, I never got into programming in
C. Our roads have forked 10 years ago, because and thanks to you, to dive
into Python language which was a tremendous enabler for me. Also, I see
with a good eye, that JavaScript was promoted to help people like me that
don't feel comfortable with static typing and manual memory management.

Even if today, I know better, I know GNU Guile Scheme.

Guile is a lisp functional language with OOP library called GOOPS
that is dynamically typed and mostly rocks, see https://gnu.org/s/guile.
That being said, I am not here to promote Guile in any way or ask people
to write GNOME apps using Guile.

I'd like to discuss Graphical User Interface programming.

Nowdays GUIs are mostly written using the web stack
aka. HTML + CSS + JavaScript or a variation of that.

Among the various frameworks for doing GUIs in this stack, there is
a constant that is the use of virtual DOM and diff + patch algorithms
also known as reconciliation [0]. Please do not flee, I will mention
ReactJS.

[0] https://reactjs.org/docs/reconciliation.html

AFAIK it takes in roots in windows 3.1 API and was made popular
recently by ReactJS view library.

Last year, while trying to figure out what all this stuff was about
I created bindings of snabbdom [1] in scheme to experiment with it.
I implemented a prototype framework for doing web apps in scheme.
You can find a demo at [2] see also a small introduction at [3].

[1] https://github.com/snabbdom/snabbdom/
[2] https://github.com/amirouche/scheme-todomvc/
[3] https://amirouche.github.io/defunct-forward.scm/

There is also a more up-to-date JavaScript version at [5].

[5] https://github.com/amirouche/xp-socialite/blob/master/frontend/src/forward.js

Simply said, my prototype framework takes its ideas from Redux
state management [6] library and somewhat Elm [7].

[6] http://redux.js.org/
[7] http://elm-lang.org/

I tried to simplify the design of Redux + ReactJS without loosing its
benefits. The main benefits are:

- Declarative API for the rendering part (somewhat like glade)
- Predictable state
- Truly single way data flow (no two-way bindings or other magic, events
  always have to go through a controller, generate a new state).

Also, I removed the action creator and dispatcher to make the MVC pattern
much more obvious.

Using scheme is makes things much simpler because scheme expressions can
easily describe html (or xml) through sxml syntax [8]. So there is no
need for a preprocessor like babel for JSX and the magic resides in Scheme basic things like quote, quasiquote and unquote (and sometime unquote-splicing).

[8] https://www.gnu.org/software/guile/manual/html_node/SXML.html#SXML

Immutable datastructures are first class in scheme, so there is no need
for things like immutablejs.

Also, there is no need to learn OOP, it only use functions aka. procedures.

It relies on lexical scoping and a closure (and a function returning a function
returning a function). Those are details.

Basically, I think it lowers the bar to get started to do frontends.

For various reasons, I am considering building a desktop application in guile-gnome.

But I don't like the OOP approach and I really find the declarative
approach of ReactJS and in particular I think forward.scm is a very
good idea.

As GTK+ and desktop application developpers, what do you think of
the approach taken by ReactJS + Redux and forward.scm to do GUI
applications?

Did anyone experiment porting those ideas (diff+patch / reconciliation algorithms)
to do desktop development?

Thanks for reading!


Amirouche ~ amz3 ~ http://www.hyperdev.fr
_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gtk-list