Hacker News Reader

Comment by alerighi | Hacker News Reader

I think the difference is about frameworks. Typically desktop application frameworks (Windows Forms, GTK, QT, etc) follow an imperative approach, where you design your UI (maybe with a graphical designer) and attach callbacks to events, than then update the UI elements directly.

Web frameworks (and modern desktop frameworks are starting to do so) use a functional approach, the view is a pure function of the state of the application, when you need to change something you change the application state and the view updates automatically. This solves a lot of problems that you otherwise have.

View on HN

Web frameworks do, but the web platform, i.e. browsers don't. The basic abstraction of browsers is still the DOM, which follows the same basic idea of desktop UI toolkits: A tree of elements which you can modify imperatively, combined with event handlers. Only, it's far less sophisticated than the data models of UI toolkits and still optimized for the web's original use case, which were text documents.

A lot of the bloat and complexity of web frameworks comes from the issue that they basically have to implement a modern, functional UI toolkit on top of an ancient, imperative one.

With Qt you can use QML and use a declarative language and this was way ahead of it's time when it was first released in 2009.

WPF and its markup language, XAML was added to Visual Studio in the 2008 edition. (But of course "there is only XUL" was way ahead-er when compared to either.)

XAML is generally static. A GUI markup browser/client should be interactive in my opinion. XUL had awkward command structures and syntax in my opinion. I didn't see the rhyme and reason for their odd choices.

Typically desktop application frameworks (Windows Forms, GTK, QT, etc) follow an imperative approach, where you design your UI (maybe with a graphical designer) and attach callbacks to events, than then update the UI elements directly

Unbelievably so, DOM also follows that. It’s apples to oranges comparison, because you could use React, Vue and other wrappers with Gtk, Qt and other runtimes, because it’s the same exact model as DOM, literally.

DOM only lacks collections/datasources, because it originated from a non-programmatic format which required every collection element to be fully described from scratch. This nuance caused around 50% of clusterfuck that web experienced for last 20 years. The other 50% was an inability (or reluctance) to support custom reflow hooks.

> the view is a pure function of the state of the application, when you need to change something you change the application state and the view updates automatically

Hum... Yeah. Except when the view is not actually pure, or when the framework can't decide, and decides to handle everything like if it isn't pure. Or when the state depends on the view. Or when some of the view depends on data from other part of it. Or when there is server data to synchronize...

But yeah, when you smooth out the movement, UI is evolving towards something nice. It's just annoying when people claim it's there already. It's not, there are plenty of problems.

Anyway, desktop frameworks are moving too.

I'd like to request a specific example. Functional can be really tricky to debug if not done well, so I'm skeptical that functional is a "magic fix". For the vast majority of office CRUD [1], the way Visual Basic (classic) did things was KISS and intuitive: you filled in the event snippet and didn't have to worry about the deeper guts of the GUI system. One should only have to fiddle with guts for special needs.

[1] Ignoring web-scale and "enterprise". I don't think it's possible to optimize a stack for smaller/middle end and larger end at the same time. One end has to take a hit.

> Web frameworks (and modern desktop frameworks are starting to do so) use a functional approach, the view is a pure function of the state of the application, when you need to change something you change the application state and the view updates automatically. This solves a lot of problems that you otherwise have.

Exactly! The React pattern is incredibly intuitive, to the point where even google implemented something similar with JetPack Compose for native android apps. The only thing I dislike about Compose is the actual state management and a few quirks, but in general, I'd love to see more native UI solutions to adopt this.

If you’re using Qt or Gtk with a dynamic language (e.g. pygtk/pyqt incarnations), then implementing hyperscript would be a relatively trivial task.

  def view():
    return h("GtkButton",
      title = "Hello”,
      clicked = …
    )

Then you get this hierarchy, compare to the old one, insert/remove/update controls and that’s it. Even issues like jumping focus on non-keyed elements will be the same.

Frameworks like React don’t do as much as you think they do wrt the paradigm itself. Most of work goes into pleasing performance quirks of both js and dom.

Reply on news.ycombinator.com