Programming is supposed to be about creating platforms for each other so we can continue solving higher (and higher) level problems. This web crap has us stuck fighting in the mud going nowhere.
HTML and CSS aren't as complex as those. Not even close
I'd say building Win32 GUIs in C++ was easier than current Web stack.
Same with Java AWT and Swing libraries.
Objective C / Cocoa is more complex - never really managed to learn it beyond basic stuff, maybe with Swift it's easier.
Elm is close to those desktop GUI frameworks, but functional instead of OO.
But Tcl/Tk is the most easiest GUI toolkit ever, too bad the resulting UI does not look professional.
I will have to vehemently disagree. I have no experience with Win32 GUIs, but I still have nightmares about wrangling nested LayoutManagers: comparing that to the current state of the web (especially after Flexbox) is downright absurd.
I am very happy with: Typescript + (Sass|LESS) + framework (Angular|Bootstrap|ReactJS). I think the 'hardcore' devs who would rather avoid using abstractions (frameworks/JS transpilers) will have a torrid time with the front-end.
For the decades leading up to this stage cross system GUIs with a few simple library dependencies have been an unachieved "easy" task. Web remains as frustrating as ever because now we need it to work on all non portable browsers even on platforms that supports better ones. Then we want new features at an alarming pace that GTK could never normalize across *nixes.
Using the only non-browser that I think sort of got cross system portability working as an example.. I don't think things functioned reliably against the weird m$, Ibm and gcj Java implementations. But since they aren't really GUIs themselves with bookmarks, and familiar menus, no one gets upset when you tell them to replace an odd Java implementation before running a Java program.
ttk does
The initial learning curve was higher, but once you had that knowledge it remained correct and relevant for years- sometimes decades.
And your application UX was faster and smoother. The minor lag between user interaction and UI action that we take as a given today in all but the most basic applications simply didn't exist if you wrote your UI to conform with the platform guidelines.
Even poor performing complex UIs typically did better than today's well written complex UIs - on hardware quite a bit less capable.
We've accepted he current hodgepodge because of portability, but if you've ever worked with the base platforms for any length of time , the difference is painfully clear.
This doesn't touch on how you could expect a consistent ui experience across all applications on an entire platform. It's hard to get that across even two web sites.
We are currently well into a full generation of developers and consumers who are unaware of what's being lost, because most of their interactions are with browser base applications and mobile phones. Waiting a few dozen to a few hundred extra ms for ui to respond is considered normal, if it's noticed at all.
However, displaying a modal window and handling messages in a local window-specific message loop is easy in Win32, and much more difficult in HTML/JS. In general, the browser makes it much more difficult to deal with synchronous operations like modal windows and server requests that require the application to wait on the response. This is how you end up with the overly-complicated mess that is callback-hell, which is then solved by another overly-complicated mess called promises.
So, presentation functionality = A+, foundational functionality for UIs = D.
The problem now is nobody can rationally understand the complexity. At least that was known before.
Perhaps the language may have been a barrier to some back in the day, but complexity vastly transcends that small issue.
Flip side: You can distribute/deploy the host HTML application with reach that will be impossible achieve with a WIN32 or MFC application.
With canvas, every browser has hardware accelerated immediate mode rendering that could be used to create UI toolkits. Looking around the web, there are some attempts to make this happen, but none of them seem to be hugely popular.
Last time I looked into this (years ago), a big blocker was that nothing inside a canvas element is visible to accessibility APIs, so UI rendered in a canvas would be invisible to people using assistive technologies like screen readers.
I'll answer that: every single one. I haven't ever seen a GUI system more complicated than the HTML/CSS/JS mess. The problem with these is that at first glance they look easy. Doing 'hello world' in HTML is little more than actually typing 'Hello world'. They only become a mess if you try to do something reasonably complex. The end result of this is that there are many people who start out with HTML and stick with it. They simply never experienced anything different.
> Why then so many devs choose to use WebBrowser wrappers to render their desktop/mobile UIs because it's way faster and easier to develop with?
No, it's cheaper to develop with. There are many more 'web developers' out there than mobile developers and they are usually very cheap to hire. The goal of corporations is not to build the best UI or to use the best tools, it is to make the most profit. A web-UI is usually considered good-enough by the suits and web 'developers' are a dime a dozen.
The answer to your second question is manyfold. First, it makes a false presupposition, web development is not faster and easier. Second, most devs probably chose the browser as a platform because Apple was so tremendously successful at creating artificial "application barriers" -- making it uneconomical, problematic or even impossible to create well-behaving cross-platform applications. Building application barriers used to be Microsoft's primary concern (they invented the term for internal correspondence), they fought hard against Sun's original vision of Java, but has become Apple's main trump card for while, after Apple decided to give up making great and innovative hardware. Third, mobile apps became sexy but the fragmentation is too high (even just Android is way too fragmented).
So many devs and companies bite the bullet and decided to make a web page for desktop and mobile phones/tablets as a least common denominator.
If you disagree, show me one non-trivial web application with the performance and a user interface that matches or outscores a corresponding native application, and we can discuss why it's better than the rest and an exception. So far, I haven't seen a single example but there should be one or two.
We old timers have native experience.
Many of those that use WebBrowser wrappers never used anything else other than web tools and aren't even aware of the RAD tooling we used like Delphi, for example.
https://www.commitstrip.com/en/2016/07/11/a-bad-workman-blam...
Jokes aside, the history of mathematics is a pretty worthwhile subject to study to truly appreciate the importance and implications of tools (or mathematical discoveries in this case). There's a reason why it took humans 2000 years after Euclid first wrote his 'Elements' to discover non-euclidean geometry...
There is the Unix Hater's Handbook (http://web.mit.edu/~simsong/www/ugh.pdf).
However, Unix doesn't suck half as bad as web development. Web development keeps a lot of problems alive that have been overcome in Unix development and everywhere else.
