Overview of Reactive GUI Programming

Tra­di­tion­ally, Graph­i­cal User In­ter­face (GUI) de­vel­op­ment and Ob­ject-Ori­ented Pro­gram­ming (OOP) go hand in hand. GUI pro­gram­ming as we un­der­stand it today was born with the ob­ject-ori­ented pro­gram­ming lan­guage Smalltalk. Ever since, plenty of ob­ject-ori­ented GUI toolk­its in OOP lan­guages—and even pri­mar­ily not-OOP lan­guages like C—came into ex­is­tence and ul­ti­mately into the main­stream. Not only his­tor­i­cal or em­pir­i­cal ar­gu­ments sup­port the union of OOP and GUIs. Even just ap­ply­ing our in­tu­ition we should clearly see a nat­ural cor­re­spon­dence be­tween OOP con­cepts and GUI con­cepts. OOP seems to sim­ply be made for GUI pro­gram­ming. And still, it re­mains chal­leng­ing up to this day. From a pes­simistic per­spec­tive we might as­sume that we al­ready have reached the lower bound of nec­es­sary com­plex­ity for GUI pro­gram­ming. Re­cent de­vel­op­ments par­tic­u­larly in the world of re­ac­tive pro­gram­ming sug­gest a dif­fer­ent pic­ture though. In this ar­ti­cle I thus want to give an overview of re­ac­tive and other mod­ern ap­proaches to the de­vel­op­ment of GUIs in order to let you de­cide if the pic­ture is worth pay­ing for.

Chal­lenges in GUI Pro­gram­ming

One might won­der what ex­actly it is that makes GUI pro­gram­ming chal­leng­ing. A good overview of some typ­i­cal prob­lems in GUI pro­gram­ming is given in the paper De­vel­op­ing GUI Ap­pli­ca­tions: Ar­chi­tec­tural Pat­terns Re­vis­ited . The au­thor iden­ti­fies four main prob­lem cat­e­gories: cre­at­ing and as­sem­bling the GUI, han­dling user input, di­a­log con­trol and in­te­grat­ing GUI and busi­ness logic. Al­though all these areas are hard, the parts of a GUI pro­gram that are con­cerned with in­ter­ac­tiv­ity are ar­guably the hard­est to tame. Not for noth­ing do most mod­ern ap­proaches try to tackle this par­tic­u­lar prob­lem. On top of that, man­ag­ing the (asyn­chro­nous) in­ter­ac­tions of many ex­ter­nal sig­nals in a GUI will gain more and more im­por­tance in the fu­ture (“In­ter­net of Things”).

The clas­si­cal ap­proach to han­dle user/sig­nal input and in­ter­ac­tions be­tween GUI com­po­nents is call­back-based. But call­backs have a cou­ple of se­vere deficits. 1

  • The con­trol flow is “scat­tered”; events may occur at ar­bi­trary times, call­backs may be added and re­moved on-the-fly, etc.
  • Data is ex­changed via shared state and side ef­fects.
  • Call­back ex­e­cu­tion is un­co­or­di­nated; call­backs may trig­ger other call­backs etc. and change prop­a­ga­tion fol­lows a “flood­ing” scheme.

The quote is from C++React’s doc­u­men­ta­tion. The term “call­back hell” was coined to refer to the prob­lems of call­backs. The fol­low­ing is a se­lec­tion of links that fur­ther il­lus­trate these prob­lems.

Re­ac­tive Pro­gram­ming

Re­ac­tive pro­gram­ming is gen­er­ally re­garded as a promis­ing al­ter­na­tive to call­back-based pro­gram­ming with­out its short­com­ings. In a re­cent em­pir­i­cal study it was even shown that pro­gram com­pre­hen­sion is bet­ter with re­ac­tive pro­grams than call­back-based ones. A good but also some­what fluffy overview of re­ac­tive pro­gram­ming is given by the Re­ac­tive Man­i­festo. The video Re­ac­tive De­sign & Lan­guage Par­a­digms goes into the ap­plic­a­bil­ity of dif­fer­ent par­a­digms for build­ing re­ac­tive ap­pli­ca­tions. One could even say that mod­ern GUI toolk­its like JavaFX are al­ready quite “re­ac­tive” by them­selves see­ing as they have data-bind­ing and ob­serv­able (“time-vary­ing”) val­ues/prop­er­ties/col­lec­tions. Scratch­ing the sur­face of the term “re­ac­tive pro­gram­ming” does not bring us far along though. Let us rather con­sider some more con­crete branches of re­ac­tive pro­gram­ming that also show promise for GUI de­vel­op­ment.

Func­tional Re­ac­tive Pro­gram­ming

Func­tional Re­ac­tive Pro­gram­ming (FRP) is a branch of func­tional pro­gram­ming which was mo­ti­vated by the goal to make an­i­ma­tions, in­ter­ac­tive pro­gram­ming and ul­ti­mately GUI pro­gram­ming bet­ter rep­re­sentable and more id­iomatic in func­tional lan­guages. The term FRP is hotly de­bated. Some un­der­stand it as it was orig­i­nally coined in the paper Func­tional Re­ac­tive An­i­ma­tion while oth­ers take a more lib­eral un­der­stand­ing. This ar­ti­cle takes the more lib­eral ap­proach and un­der­stands FRP as a par­a­digm around data flows, change prop­a­ga­tion and time-vary­ing val­ues or event streams using func­tional build­ing blocks. As this de­bat­able un­der­stand­ing sug­gests, there are many vari­a­tions of FRP. The fol­low­ing are links that, among other as­pects, try to pro­vide an overview of the FRP land­scape. 2

The fol­low­ing links pro­vide mo­ti­va­tion for FRP.

The fol­low­ing are links to a cou­ple of in­ter­est­ing and prac­ti­cal FRP pro­jects. 3

Not every­thing’s rosy in FRP. There are many crit­i­cisms and open ques­tions with re­spect to FRP which are par­tially dis­cussed in some of the pre­vi­ous links. The thread Lim­i­ta­tions of FRP con­tains some in­ter­est­ing crit­i­cisms. 5

Event Stream Pro­gram­ming

As the name sug­gests, this par­a­digm is con­cerned with mod­el­ling in­ter­ac­tions as streams of events. It was ini­tially con­ceived in the frame­work Re­ac­tive Ex­ten­sions (Rx) for .NET. The fol­low­ing links pro­vide very good in­for­ma­tion to learn more about this par­a­digm.

A pro­ject I want to spe­cially em­pha­size is Re­actFX as its goal is the ap­pli­ca­tion of event stream FRP to the de­vel­op­ment of GUIs. The au­thor Tomas Mikula’s blog con­tains very con­vinc­ing ex­am­ples of FRP’s use­ful­ness for real GUI tasks like syn­tax high­light­ing. In short, the ad­van­tages of using Re­actFX’s ap­proach for GUI pro­gram­ming are less side-ef­fects/mu­ta­ble state (→ less er­ror-prone­ness and hid­den de­pen­den­cies), bet­ter com­pos­abil­ity, more de­clar­a­tive/ex­plicit code, more prin­ci­pled ways to pre­vent glitches and pow­er­ful ways to ex­press asyn­chro­nous re­quire­ments. 6

Non-func­tional” Re­ac­tive Pro­gram­ming

Ex­plic­itly search­ing for re­ac­tive pro­gram­ming ap­proaches that are not FRP yields not a lot of re­sults. Nonethe­less, there are in­ter­est­ing pro­jects that want to com­bine the im­per­a­tive or ob­ject-ori­ented par­a­digm with the re­ac­tive par­a­digm.

Other Ap­proaches

It seems that every cou­ple of min­utes a new JavaScript fronted frame­work is born. Keep­ing track of all these frame­works and their dif­fer­ent ap­proaches is hard. There is one ap­proach though, orig­i­nally con­ceived by React.​js, that quite di­rectly goes against the cur­rent wis­dom of struc­tur­ing JavaScript fronted frame­works yet still seems con­vinc­ing. The rough idea is that in­stead of try­ing to keep the many GUI com­po­nents con­sis­tent by piece-wise mu­ta­tions/up­dates a la MV*, the GUI is just re­com­puted from scratch on each in­ter­ac­tion. The fol­low­ing are a cou­ple of very in­ter­est­ing links about React and its novel ap­proach.

A re­lated idea is to cen­tral­ize the state of an ap­pli­ca­tion in­stead of dis­trib­ut­ing it among dif­fer­ent ob­jects as is nor­mally done with clas­si­cal MV*. This idea is fur­ther char­ac­ter­ized in the fol­low­ing links.

Re­ac­tive pro­gram­ming is one way to tame call­backs. State ma­chines are an­other. The fol­low­ing links ex­plain the mo­ti­va­tion and ad­van­tages of state ma­chines over call­backs.

Yet an­other ap­proach to sim­plify GUI pro­gram­ming (or not) are im­me­di­ate mode GUIs.

For An­droid there is Macroid and Scaloid.

Con­clu­sion

The cur­rent re­main­ing dif­fi­cul­ties of GUI pro­gram­ming exist not due to OOP per se, as the in­tro­duc­tion might have con­veyed, but rather pri­mar­ily due to call­backs or, in OOP terms, the ob­server pat­tern. The most promis­ing idea to im­prove GUI pro­gram­ming seems to be event stream FRP like ex­em­pli­fied by Re­actFX. Even though this ar­ti­cle fo­cused on GUI pro­gram­ming, the ideas from the pre­sented pro­jects could be ap­plied else­where where call­back-based pro­gram­ming is used. 7



The fol­low­ing are fur­ther rel­e­vant links I found after hav­ing pub­lished this ar­ti­cle.


  1. Call­backs, lis­ten­ers, ob­servers, sig­nal-slot mech­a­nisms rep­re­sent es­sen­tially the same con­cept or, put an­other way, share the same short­com­ings. 

  2. I re­mem­ber search­ing the in­ter­net a cou­ple of years ago for a more id­iomatic way of writ­ing GUIs in a func­tional style. The an­swer al­ways seemed to be that FRP is the canon­i­cal way to write GUIs in func­tional lan­guages and more often than not some links to ob­scure pa­pers or pro­jects were given as proof. Of course, the ob­scu­rity of these links stood in stark con­trast to these an­swers’ claims. In any case, I was much too in­ex­pe­ri­enced to crit­i­cally as­sess the given in­for­ma­tion and so FRP re­mained this “siren call” for me that I maybe some­day could hope to un­der­stand. Now that I have re­cently delved once again into FRP I fi­nally un­der­stood that FRP re­ally was rather ob­scure at that time and only re­cently more ap­proach­able FRP pro­jects came into ex­is­tence. 

  3. Ad­mit­tedly, Scala.​React and REScala are not so easy to set up and play with, but the in­for­ma­tion in the re­spec­tive pa­pers is very prac­ti­cal in terms of re­ac­tive GUI pro­gram­ming. And, afaik, the pro­ject from the paper “Prac­ti­cal Func­tional Re­ac­tive Pro­gram­ming” is not pub­licly ac­ces­si­ble. 

  4. With­out a doubt, Elm is the most ap­proach­able of all pro­jects. 

  5. Most of the crit­i­cisms does not apply to event stream pro­gram­ming though. 

  6. Sim­i­lar pro­jects to Re­actFX are Re­ac­tive­Co­coa with which the Github Mac App has been built and Re­ac­tiveUI

  7. If you are in­ter­ested you could check­out my the­sis “Com­par­i­son of Ob­ject-Ori­ented and Func­tional Pro­gram­ming for GUI De­vel­op­ment” where some ap­proaches from this ar­ti­cle are ex­plored and an­a­lyzed in more de­tail. If you ex­pect to get the an­swer “OOP is ob­jec­tively bet­ter” or “FP is ob­jec­tively bet­ter and here is the proof” then you are going to be dis­ap­pointed. The the­sis has an ex­ploratory style and mostly pre­sents dif­fer­ent con­cepts for con­crete ex­am­ples. Of course, I tried to give as­sess­ments and rec­om­men­da­tions but not an em­pir­i­cal or ab­solutely ob­jec­tive ver­dict. I think though that the the­sis can serve as a first step/overview on the road to a more em­pir­i­cal or ob­jec­tive un­der­stand­ing of GUI de­vel­op­ment ap­proaches. This is why I tried to ex­tract the case stud­ies from the the­sis into a “no­ta­tional us­abil­ity bench­mark for GUI pro­gram­ming” with the title 7GUIs. In a fu­ture ar­ti­cle I will go into more de­tail about 7GUIs and the the­sis. 

Published: 14.09.2014 Last modified: 09.05.2015
Comment? Mail or tweet me.