[rtpg]

Try writing a GUI with other toolkits. Hours of tweaking random XML to try and figure out why some constraint solving thing just isn't working...

Despite all the mess, I have an easier time getting buttons on a screen and doing things sanely (once all the fuss is set up) compared to trying to get the ball rolling in Qt/GTK/etc (especially if you're not using Java or C++)

[kaba0]

Absolutely not true. Windows forms, WPF, JavaFX, Swing all are much more productive than the vanilla web. Like, how many lines of code does the most basic vbox/hbox thing requires in web technology? Many of them even have dragndrop ui creations, and this XML hatred is downright stupid at this point. How about criticizing the technology and not a random medium for that? Is writing something stupid in JSON inherently better?

HTML is simply a terrible GUI base, JS is quite great nowadays and CSS would be great, but has to provide way too much of what HTML should be doing. But the web ui frameworks are just barely getting at the level of where native frameworks have been in a decade.

[ath92]

That example you mentioned would be just a couple of lines of html with css (which you could inline if you wanted), and there are plenty of drag and drop tools for the web (WebFlow is a modern example, but they have been around for decades).

[kaba0]

Why would it need any sort of CSS? Isn’t HTML supposed to be responsible for the structure of a webpage? And of course it can be done, but if we do something like hbox inside a vbox inside a vbox, the resulting code will be ugly as hell (perhaps Webcomponents will help a bit here?). Like, what is the point of HTML at that point? To spam divs (pun sort of intended)?

And there are plenty of other “layouting primitives”, all of which are quite cumbersome. And due to HTML encoding some form of semantic meaning only (though seldom used even for that), drag n drop tools can’t generate easy to read/modify output. Also, without js frameworks, you can’t really just embed another component into it trivially.

And I’m not trying to shit on web tech, JS has absolutely overcome its shitty past, and is quite a likable language nowadays, and CSS is an extremely powerful and expressive system (though this latter is due in part to how shitty html is). My only gripe is with HTML that is simply not fit for the task (as it was never meant for that).

[yoz-y]

> Isn’t HTML supposed to be responsible for the structure of a webpage?

If by structure you mean things like hbox/vbox then no, html is not supposed to do that. HTML should only represent the semantic structure.

[kaba0]

Yeah I know, but that is because it was meant for documents. It is not a great fit for web applications.

[danShumway]

Applications aren't special.

There are a couple of exceptions for interfaces that are genuinely unconventional, or that deal with multiple spacial dimensions, or that are primarily representing graphs and visual/audio data. But most interfaces should be representable in pure text.

This argument that "the web is only for documents" is missing the point that most applications are just interactive documents when you really break down their UI. A labeled tree is a fine way to represent user-facing state for most apps, and most apps would benefit from exposing a more semantic interface to users that was easier for them to manipulate and read programmatically.

[eurasiantiger]

What is a better fit for web applications?

[rtpg]

Drag n drop UIs don't really help when you have too much dynamism (like "oh only have this button appear in these conditions", "do this here", etc). And I would say that box layout offered by CSS is much nicer than the constraint layout system _when you have a lot of dynamism_.

Like I wouldn't want to have to deal with an interfrace like facebook in native stuff. I don't think it's impossible, but I feel like it would require a lot more up-front design and correct engineering.

You're right about XML being a medium, just kinda my memories of working with this stuff.

[kaba0]

> Drag n drop UIs don't really help when you have too much dynamism

Yeah, its true — though you can leave an area empty where you will dynamically load one from a set of already drag’n’drop created layouts.

[hnbad]

> Like, how many lines of code does the most basic vbox/hbox thing requires in web technology?

CSS:

    .vbox, .hbox { display: flex }
    .vbox { flex-direction: column }
    .vbox > *, .hbox > * { flex-grow: 1 }

HTML:

    <div class="hbox">
      <div class="vbox">
        <button>Top left</button>
        <button>Bottom left</button>
      </div>
      <div class="vbox">
        <button>Top right</button>
        <button>Bottom right</button>
      </div>
    </div>

Or was that a rhetorical question?

[noduerme]

Such a great point. HTML is a terrific way to write documents and TERRIBLE way to lay out applications - especially for lots of different screen sizes. It's not surprising at all to see Google embracing Canvas now to underpin Docs; basically they are admitting that it would have been better to write the whole program in a Java VM or in Flash than to rely on the browser for layout. This is patently obvious to anyone who builds large web applications. Ten years ago we had ASWing, JSwing and plenty of other actual frameworks where you didn't have to diddle around with tons of logic embedded in templates which were embedded in other logic; but thanks to Apple we're still saddled with this wretched Javascript/HTML paradigm that was never meant to do much more than inline some animated GIFs back in the 90s. Yes, it's gotten better (I've been doing this since the 90s, so I know). But it's so inelegant. To some degree this is just a problem with open web standards. It would be better if any one company actually had dominated to the point where they could write a closed standard, because at least it would be coherent and cross-platform. It was a lot easier to write a web app in 2010 than it is now, and it pains me to think how many hours I could have avoided reinventing the wheel if Flash had been allowed to stick around. Any app written entirely now on canvas is just replicating a VM that already existed a decade ago in what was by then a much more mature ecosystem - and was faster then than canvas or WebGL is now.

If I had to pick a stack to do a new web app entirely in canvas, I'd probably choose to port a ton of interface components from AS3 into PixiJS... but the point is, where have we gotten? Ten years from now we'll be writing apps the way they were written in 2010 -- inside a black box in a canvas or VM. The HTML5/JS revolution has been a sham from the start, just a way for one corporation to dismantle another with the side benefit of forcing all of us to rewrite our code from scratch in a crappier language.

[friend-monoid]

I'm not sure I buy the idea that "efficient and easy tooling around a technology makes the technology". We all went through the same Dreamweaver pains.

[kaba0]

How come the minuscule userbase of native frameworks have better tooling than the numero uno popular web? It may mean that there is a technical reason in the background.

[goto11]

They solve a simpler and more constrained problem which makes it easier to make tools. Something like Windows Forms are basically WYSIWYG - you drop some controls on a canvas and now you have a GUI. But the GUI will not gracefully adapt to different screen dimension from large monitors to mobile.

[pseudalopex]

Native frameworks support flexible and resolution dependent layouts too.

[kaba0]

Responsive layouting is an orthogonal problem.

[goto11]

Orthogonal to what?

[pmontra]

30+ years of history?

[kaba0]

Interestingly enough JavaFX is much younger than the web, and is quite niche, yet it has SceneBuilder.

[pmontra]

It's younger than the web but much older than the current bunch of frontend technologies. JavaFx is from 2008 [1]

Anyway, that's not very important.

What web apps never had is a visual app builder as popular as the first Visual Basic for Windows 3. We had some tools like that (example Jwt [2]) but none of them got a critical mass of users. Maybe it's difficult to match Visual Basic's success because Microsoft controlled the tool, the operating system and the language. If this is the case the only current candidate is Google, because of Chrome. They are investing on Flutter and Dart now but making them prosper on the web looks like a uphill battle. Much easier on Android.

[1] https://en.wikipedia.org/wiki/JavaFX

[2] https://en.wikipedia.org/wiki/JWt_(Java_web_toolkit)

[jcelerier]

> I have an easier time getting buttons on a screen and doing things sanely (once all the fuss is set up) compared to trying to get the ball rolling in Qt/GTK/etc (especially if you're not using Java or C++)

ah, yes, the famous difficulty of getting buttons on a screen in Qt https://streamable.com/bs5fxk

[einpoklum]

I agree that it's pretty simple to get a button on screen in Qt, but your linked video presents it as horribly complicated. And requiring an IDE to do it is pre-admitting it's complicated.

By the way - Qt and GTK are super-outdated ways to do GUI in C++. Popular, but outdated.

[jcelerier]

> but your linked video presents it as horribly complicated.

... could you precise that more ? I'm literally just making "new project" > design view > search for the button component > drag'n'drop it ? How can it get more simple ?

(opening a text file and writing "Button {}" is definitely more complicated if we're talking about teaching to beginners)

[bryanrasmussen]

>(opening a text file and writing "Button {}" is definitely more complicated if we're talking about teaching to beginners)

if teaching beginners to programming sure, if teaching a programmer beginning QT development no.

[jcelerier]

I disagree, the first case is discoverable, the second isn't at all. But apparently no one cares about discoverability of tools in 2021..

[bryanrasmussen]

I mean the second case is generally discoverable for a programmer because there will documentation of a language or API. I believe people are generally aware of discoverability of documentation in 2021.

[presentation]

Just that starting modal with 6 steps to choose various configuration stuff would probably throw a beginner into a loop for a while, even if you could just skip it all. Maybe if this IDE wanted to be beginner friendly, they ought to consider just having reasonable defaults and letting power users change them later - like how web tools tend to be designed these days.

[hnbad]

There are visual editors for React. Pretending QT is easier than web technologies because it's easier to drag a component in a visual editor than type text in a code editor is comparing editors, not UI technologies.

[jcelerier]

Are you saying that React is easier than this purely code-wise: https://qmlonline.kde.org/

[hnbad]

It's about the same but you can do this with minimal HTML and CSS using a basic CSS keyframe animation.

[indigo945]

What do you feel is a more "modern" way to do a GUI in C++?

As an aside, do "modern" developers still write GUI applications at all, since everything is on the web anyway these days?

[krapht]

Is this a joke? There's a whole world of software out there that isn't web based. Anybody who hasn't switched to a Chromebook uses them every day.

I even write terminal user interfaces sometimes to interact with servers that don't have a desktop environment installed.

[cat199]

if you reread, this is what the parent is asking of the grandparent, in less nice terms.

[einpoklum]

Well, the question of what's "modern" in C++ is both deep and contentions. But I won't shirk the question...

You want to be utilizing the features C++11, C++14 and maybe even newer versions of the standard allow you to use, to avoid unnecessary boilerplate, repetition, and arcane-ness of syntax and semantics.

Similarly, the GUI toolkit should not be based on C-like or C++98-like design patterns, when newer versions of the standard allow replacing them with more convenient patterns.

Here's one example, from the Nana C++ GUI toolkit:

  #include <nana/gui.hpp>
  #include <nana/gui/widgets/label.hpp>
  #include <nana/gui/widgets/button.hpp>

  int main() {
      nana::form form;

      nana::label label{form, "Hello, <bold blue size=16>Nana C++ Library</>"};
      label.format(true);

      nana::button button{form, "Quit"};
      button.events().click( [&form]{ form.close(); } );

      form.div("vert <><<><weight=80% text><>><><weight=24<><button><>><>");
      form["text"] << label;
      form["button"] << button;
      form.collocate();
 
      form.show();
 
      //Start to event loop process, it blocks until the form is closed.
      nana::exec();
  }

This is not perfect IMHO; for example, I don't really like the confusing div string with the many < and > signs. But you can put this in a text editor, build it with `g++ -I/path/to/nana/includes -L/path/to/nana/libs -lnana` - and it will just work, on various platforms. No secret sauce, no need for a bunch of IDE dialogs or any special configuration or action.

[jcelerier]

Here's a quick port to Qt (except for the <> thing which I did not really understand after a cursory reading of its docs)

    #include <QtWidgets>

    int main(int argc, char **argv) {
      QApplication app{argc, argv};
      QWidget widg;
      QVBoxLayout form{&widg};

      QLabel label{
          R"(Hello, <span style="font-weight: 600; font-size: 16pt; color: blue;">Qt C++ Library</span>)"};

      QPushButton button{"Quit"};
      button.connect(&button, &QPushButton::clicked, [&widg] { widg.close(); });

      form.addStretch(0.1);
      form.addWidget(&label);
      form.addStretch(0.7);
      form.addWidget(&button);
      form.addStretch(0.2);

      widg.show();

      app.exec();
    }

Builds with

    g++ example.cpp -I/usr/include/qt/ -I/usr/include/qt/QtWidgets -fPIC -lQt5Widgets -lQt5Core

Here's also how the two programs behave in practice: https://streamable.com/brltmc

tl;ds: now that I saw it in action, I know I can instantly ignore anyone who says that nana is a suitable replacement for Qt.

[alibarber]

There is a wide world of applications and development that don't have anything to do with the web.

The films you watch on TV or at the cinema were not created (edited, VFX) using a web browser for a start, and the User Interfaces to those applications are pretty Graphical by anyone's definition...

[hnbad]

As a counter point: plenty of desktop software embeds web technologies these days and even AAA games occasionally use them. I think Battlefield was a prominent example for React being used in AAA games for UIs. The Horizon TV streaming box also had a UI written in React (rendering to canvas for performance using their custom Chromium build I think, but they wrote it so the UI could also be rendered to the DOM so they could use it in their web version).

Not disagreeing with what you said, but "not having anything to do with the web" isn't as clear cut as it used to be and web technologies are increasingly showing up in unexpected places.

[jcelerier]

> The films you watch on TV or at the cinema were not created (edited, VFX) using a web browser for a start

to add on this, the reference UI toolkit for building VFX tools is Qt. Maya, DaVinci, Lightworks, Nuke... are all Qt-based.

https://vfxplatform.com/

[cies]

If not using C++ with Qt, Qt is a bit harder to get going. But I honestly dont think that building a UI with JS/HTML/CSS is easier than in C++/Qt.

But then the Qt UI:

* needs to be (re)compiled for each platform

* needs to be re-shipped on each change

* is not a client-server application (all runs on the client)

* has "desktop styling" by default

[klausjensen]

Agreed wrt other GUI toolkits.

I think of it like democracy. It is ugly and terrible, but still better than all the other options.

[kwanbix]

I imagine you never used Delphi, VB, or even Lazarus?

[kodah]

Having worked on both desktop and web UIs the problem you're describing occurs in both worlds. Usually with web you run into it when you're dealing with a more sizeable app, or fancier things you want to do with your framework.

[1vuio0pswjnm7]

Sounds like "developer productivity" could be increased by not having to create GUIs. As an end user, I will happpily accept and in fact prefer text-based, keyboard-driven interfaces.