> I can't remember a time when I couldn't easily grasp any of Qt, Gtk, whateverTk toolkits in few hours

When I tried those things, I had a hard time making an hello world app in two hours because of dependency/build/tooling issues.

However I was able to grasp angular 2 in two hours probably because I am more familiar with the frontend ecosystem.

It would be like saying that because you knew english & german and was able to quickly learn swedish, you should be able to learn russian easily.

> Not to blame or insult good frontend people here and everywhere, but it feels like en masse they don't understand the programming essence at all. Sorry, but UI development was never HARDER than today. My colleague feels the same, having more than 15 years of html/css/js experience.

15 years ago the js applications were nowhere as complex as they are today. So obviously things are a bit more difficult IF you want a rich application. If you just want to make a simple document you don't need all those librairies.

> We picked Angular2 randomly after few probes and it seems that out project has more quirks, hacks and LoC than if we just coded it in pure js with heavy templating help from e.g. perl backend

This is your first project with a very unfamiliar tech. This was an expected outcome.

> My thoughts are we're throwing it out next week and generate all ui with decent server-side scripts, leaving /js/util.js of 1kloc as a broker and generic table sorter.

And that's a perfectly reasonable option, especially if you don't have someone with more experience in frontend tech to keep things sane.

Our CEO, also programmer in distant past, took his macbook, asked me "where do I get Xcode", and in his free time did anything we did in web, including animations, itunes-like header/progress area, etc. With my "intensive kickstart", obviously, but the shocking fact is that he never touched Objective-C, Cocoa, AppKit and HTTP. Never. In. His. Life. (Though he has very strong background of sockets, threads, C, widget frameworks, coreutils, evaluation models and general software engineering). It took about a week or two in between of management and negotiations to simply write that thing by all canons.

I don't think we'll hire another frontend master on the middle of the road anyway, but that has something to do with complexity, not competence.

(Fun thing, he started with Swift but quickly "downgraded" to Objective-C, because Swift was getting in his way too much with no clear benefit.)

I'd be interested to know how you tried.

For instance, for GTK:

https://developer.gnome.org/gtk3/stable/gtk-getting-started....

For Qt, the IDE itself comes with examples that can be built and run in two clicks.

Or maybe you want to use python ?

  virtualenv --no-site-packages .
  source bin/activate
  pip3 install pyqt5 
  echo "import sys
  from PyQt5.QtWidgets import QApplication, QPushButton

  if __name__ == '__main__':    
    app = QApplication(sys.argv)

    w = QPushButton('Hello world')
    w.show()
    
    sys.exit(app.exec_())" > main.py
  python3 main.py

This is a quite recent phenomenon and to be applauded.

Minus sides -

Neither of these work with pypy yet (ideally the bindings would be rewritten using cffi for best benefit).

The downloads on these are quite big, but maybe this isn't the end of the world.

Gtk still doesn't work with pip like that yet.

Pyimgui may be worth a look if you want a small download that works everywhere, though it does look like it's own thing.

Being a desktop and embedded developer myself, I share your sentiment. My personal explanation of the state of the art of web UI tech is, that there can only be wrong ways of doing it if the basic abstraction at the bottom of the stack is wrong. HTML was invented as a hyperlinked semantic document markup language with presentation largely left to the browser's interpretation. Presentation (CSS) and interaction (JS) aspects were only added (dare I say "glued") to it later, which seems like a design afterthought.

> Now that I'm forced to dive into it, I see that they just reinvent square wheels in a wrong ways that were polished a decades ago in regular desktop apps.

If you're talking about tcl/tk, decades ago it had a motif look to it (raised 3d borders, lots of grays). There was no theming engine. Font sizes were integer only (and that only recently changed). I'm not sure what the status of antialiasing was, but it probably wasn't good.

The event loop was (and is) slow. Unicode support was new.

Oh, and then there was the documentation. Seems like everyone who installed tcl/tk on a university machine made a public copy of the docs. So if there were bugs in a topic of the doc (and there were), and you searched for something related to that topic, you'd get back 100 links to copies of that same doc which all had the same error. What you wouldn't get were in-depth blog entries explaining that topic, complete with inline, cross-platform working demos which you can read, write, modify, and-- with a single shortcut-- inspect using one of at least 3 completely different implementations of the same standard from competing companies.

For example, for a file dialog under Windows and MacOS a call to the native libraries is made to get a native dialog widget. But in Linux of the late 1990s/early 2000s there was no such thing as a native dialog. So some tk developer coded their own file dialog.

Let's say you started in a deeply nested directory and you wanted to climb out. You see a button that goes one level up the directory tree. Great. You click that button and on Linux now the window shrinks because its width is set to be as wide as the directory being shown. So you couldn't do multiple clicks in a row to climb up the tree without moving the mouse to the left for each click.

You might be able to dig into the internals and muck around to get that dialog to have a better UI. But then you notice that the window menus in Linux-- unlike the ones on MacOS or Windows 95-- don't toggle the menu display on click. They only display on click. Not sure about Gnome 1, but Gnome 2 window menus definitely toggled on click. If you want that standard behavior now you've got to dig into yet another implementation-specific codebase for your tcl/tk installation. And since you're mucking around inside the implementation there is no guarantee that what you change will still work when you upgrade to a newer version.

If Firefox rolled their own weirdo file dialog on Linux and required an extension to get something that looked better, you can bet every new release would be met with complaints and sneers about just that. Yet whenever people bring up whateverTk it's some kind of antediluvian paradise.