Does C++ devs worth more than web devs?

2019-07-31

History, or why is the present the way it is, again?

I've started programming professionally around the end of the 90s during the first internet bubble. Back then we had two secret weapons to bring customers what they needed much faster and for a fraction of the price than what was possible to the established practices of the established industry that we were disrupting:

GNU/Linux and web GUIs.
 

The main reasons we used to put web GUI in front of everything, rather than the more traditional fat clients, were several:

Essentially, the web was our battering ram against closed, expensive walled gardens of IBM, Sun, Novel, Bull and others which names have been forgotten.

But using tools and protocols designed to share arid papers across scientists was not without flaws though.

First and foremost, user interactions were limited to the bare minimum as the bag of tools available to web devs for user interactions were, at the time, severely limited. Fat clients using native or even java GUI libraries, could offer dedicated widgets to dedicated tasks, whereas to us everything had to be a web form.

Also, dumb clients had to perform a round trip to the distant server in between any two web forms which slowed things considerably. Even text interfaces, still around at the time, were often time preferred by their users for their responsiveness compared to our sluggish ersatz.

Finally, fat clients could make a much better use of client hardware, starting with the keyboard; Indeed, they had plenty of hotkeys and short cuts that web GUIs were missing which made them feel even slower. Fat clients could also store some data locally and work offline at least to some degree, or share data easily with other applications.

Still, then as always, the price argument fiercely prevailed.

The evolution of web GUI is well known:

Rather than acknowledging the fact that we needed a protocol to codify the semantic of a rich GUI and its universal client for each platform, the industry, unable by design to plan further away than the next baby step, carried on using the web for everything with many very minor improvements here and there to try to make it suck less while not loosing the price advantage.

Better standardisation of HTML slowly led to many new standards and revisions, most of them unused, and which, as the demise of XHTML have shown, were not allowed to break backward compatibility (that quickest road known to man toward overcomplexity).

Separation of graphical rendering from what to render, thanks to cascading style sheets, was invented to rival printed magazines for publishing eye-appealing documents on the web, rather than the customary arid scientific articles the embellishment of which climaxed with an horizontally <center>ed picture. We took advantage of CSS to make our web front ends suck less for the odd clients with unexpected screen sizes, the variety of which exploded when smartphones and then tablets became popular.

And most importantly javascript became prevalent. We initially used javascript to spare our clients from some of the round-trips to the server and patch the most infuriating UI corner cases.

At each of these baby steps we had to give back some of the initial advantages: our dumb clients became more complex, more expensive, less portable and less secure.

Fast forward to today. A whole industry grew like a cancer out of what was just a hack, and many computers only native application is now a web browser.

Finally, the initial flaws of the web have been solved:

Today's web apps can use most of the local computer peripherals like touch screens, cameras and microphones. They can also store data locally and work offline. The round trips to the server are gone, replaced by the initial download of the application and the intermittent background discussion with the server.

Are the advantages still there, though?

If one dig deep enough into any web front-end today, regardless of how fashionable and on-the-edgeness of the stack, one is likely to still find the antique HTTP and HTML layer at the foundations. To achieve feature parity with fat clients, the web industry have had to pile up many different techs and standards basically simulating the native environment, the craziness and inadequation of which became the main jokes provider among professionals.

Has the time come, then, to revisit the tenet that web front-ends are more economic than fat clients?

Questioning the custom

Having to write a GUI for Ramen, I could initially though only of web front-ends and effectively have started two of them: one from scratch and one as a Grafana plugin, both of which I abandoned along the way as too costly to maintain and for lack of interest. Indeed, I took the wrong decision to start from what users would most likely want to use them for (plotting dashboards) rather than what I would want to use it for (visualising Ramen's internals).

Rethinking the whole concept of a GUI, I also considered going native. So I looked for a cross platform UI library (therefore, some may argue, not properly native). What choices are there, as in summer 2019, of reasonably usable and portable GUI libraries?

My criterion were: Open-sourceness, portability, adequacy for drawing charts, easiness to link with other libraries (C or not), as I'd like to share some code with the OCaml server, at least in the beginning to speed up development.