Podobnou knihovnu jsem se pokoušel naprogramovat pro C++ někdy v roce 2010. Časem jsem přišel na to, že to nepotřebuju, spíš mi vyhovuje backend v C++ a frontend komplet JS+HTML, aspoň mám hezky oddělené UI od zbytku kódu a navíc to nabízí možnost používat aplikaci i programově přes (dobře navržené) API.
On je tam technologický rozdíl. Zatímco GWT transpilovalo zdrojáky z Javy do JavaScriptu a potom se to nějakým způsobem spojovalo s backendem přes AJAX, v PyWebIO nic takového vlastně není. Tady je oddělení provedeno tak, že existuje sada komponent pro UI, které se dají dynamicky z Pythonu zobrazit a použít.
Tedy GWT je sice mnohem flexibilnější, ale ten výběr technologií dělá třeba z ladění dost peklo. PyWebUI není pro plnohodnotné UI vhodné, ale je to celé navrženo mnohem čistěji (no a další věc je, že to Google ze své pozice zabil, ale to není žádné překvapení, to prostě Google dělá https://killedbygoogle.com/)
To je to, co jsem, přiznám se, z článku právě nepochopil - jak je PyWebIO udělaný technologicky. Je to nějaká sada pevně daných JS komponent, které se dají poskládat do stránky a pokud komponenta vyvolá event, tak se udělá callback na server a tam se spustí příslušný Python kód? A server pošle zpět celou stránku, nebo nějak "magicky" zjistit, co má překreslit?
Tak ta komunikace je obousměrná přes websockety. Vždycky Python kód (tedy kód reálně běžící na serveru) určí, jaká komponenta/komponenty se mají zobrazit a poté se už nechá na frontendu, aby komponentu vykreslil, reagoval na akce uživatele a ve chvíli, kdy se stiskne "Submit", aby frontend poslal backendu vyplněná data zpět.
Z pohledu programátora (v Pythonu) to ale není řešeno callbackem - čekání na vyplnění formuláře (sady komponent) je normální blokující operace. Prostě taková funkce input() na steroidech :-)
Celá stránka se neposílá, jen vždycky přes websockety příkaz typu "zobraz text areu", "zobraz sadu radio buttonů" atd.
Ten protokol je popsan tady https://pywebio.readthedocs.io/en/latest/spec.html