Live data from Hacker News

High-Level Is the Goal

bvisness.me

21–30 of 158 posts

Re: High-Level Is the Goal

#21
post #12

Earlier quoted context omitted.

There was WxWidgets.

The main consensus in the native space is that Qt is still miles ahead of any other cross-platform desktop framework (including WxWidgets). Doesn't mean that Qt is anywhere good - it's just the least worst option out of all. I hoped someday Flutter might be mature enough for desktop development, but so far they've focused most of their efforts on mobile and I don't think this will change in the future.

As 1 datapoint to support this, see Audacity moving from WxWidgets to Qt for 4.0.

Re: High-Level Is the Goal

#22

The Reddit example is about two different design choices. The DOM is a tree of state that needs to stay in sync with your app state. So how to make that happen without turning your code into a mess. The old Reddit had to first construct the DOM and then for every state change, determine what DOM nodes need to change, find them and update them. Knowing what needs to change gets ugly in a lot of apps. The other alterna…

I'm fairly confident that the new reddit React implementation can be improved in performance by a factor of 3x to 10x. I would be interested to hear others who have good reason to explain why not. I can certainly imagine React-like systems that are capable of statically determining DOM influence sufficient to make comment-collapsing negligible.

Re: High-Level Is the Goal

#23
post #7

While directionally correct, the article spends a lot of time glorifying jquery and not enough on what a horrible, no good, unoptimized mess of a framework jquery was, and by extension what kinds of websites were built back then. I remember those times well. The reason to use React isn't because it was new, far from it . It was because it won vs. Ember, Angular, et. al. in 2014-2015? as the best abstraction because i…

[deleted]

Re: High-Level Is the Goal

#24
So from what I understand…

Someone needs to build Qt’s successor, probably with more beginner-friendly declarative semantics (akin to HCL or Cue) and probably with syntax closest to YAML or Python (based on learning curve, beginner readability etc).

The backend will probably have to be something written in Zig (likely) or Nim (capable, less likely) and will probably have to leverage OpenGL/Metal, WebGL and WASM.

Obviously a massive undertaking, which is why I think the industry has not reached consensus that this is what needs to happen. The less ideal options we have now often gets the job done.

Re: High-Level Is the Goal

#25

Earlier quoted context omitted.

The main consensus in the native space is that Qt is still miles ahead of any other cross-platform desktop framework (including WxWidgets). Doesn't mean that Qt is anywhere good - it's just the least worst option out of all. I hoped someday Flutter might be mature enough for desktop development, but so far they've focused most of their efforts on mobile and I don't think this will change in the future.

As 1 datapoint to support this, see Audacity moving from WxWidgets to Qt for 4.0.

Absolutely, they need Qt in order to design and theme a UI that actually doesn't look terrible (They already had good experience in porting Musescore from vanilla C++ Qt5 to QML widgets, so I think they'll use a similar system for Audacity)

Re: High-Level Is the Goal

#26
post #7

While directionally correct, the article spends a lot of time glorifying jquery and not enough on what a horrible, no good, unoptimized mess of a framework jquery was, and by extension what kinds of websites were built back then. I remember those times well. The reason to use React isn't because it was new, far from it . It was because it won vs. Ember, Angular, et. al. in 2014-2015? as the best abstraction because i…

jquery was an unoptimised mess? it's like 30k minimised and just bridged a bunch of functionality that browsers lacked as well as providing a generic api that let you (often) ignore per-browser implementation and testing of your code there's no reason to blame it for the types of websites being made either, it doesn't really provide enough functionality to influence the type of site you use it on

Since when did we start using file size as a measure of efficiency or optimization?

Off the top of my head: $() CSS parsing and DOM traversal was way slower than querySelector or getElementById, both of which predate jquery by years. Every $('.my-class') created wrapped objects with overhead. Something like $('#myButton').click(fn) involved creating an intermediate object just to attach an event listener you could’ve done natively. The deeper the method chaining got the worse the performance penalty, and devs rarely cached the selectors even in tight loops. It was the PHP of Javascript, which is really saying something.

By the early-2010s most of the library was dead weight since everyone started shipping polyfills but people kept plopping down jquery-calendar like it was 2006.

(I say this as someone who has fond memories of using Jquery in 2007 to win a national competition in high school, after which I became a regular contributor for years)

Re: High-Level Is the Goal

#27
post #15

I think the real conclusion is: someone has to make a native cross-platform desktop UI framework that doesn't suck. (Yeah Qt exists, but it really sucks...) Until then, everyone will default to just using the browser for a desktop app, and the beatings will continue. Because of this, I'm really looking forward for PanGUI to step up ( https://www.pangui.io/ ), their UI framework is very promising and I would start usi…

What about Flutter?

Not bad for mobile apps, but still sucks a lot for desktop support.

Also, really wished they've opted for a more general language like C# rather than Dart - but that's inevitable since Google needed to make use of their Dart language after they've failed to standardize it on the Web (and I think they don't want to use a language developed by Microsoft of all companies)

Re: High-Level Is the Goal

#28

I think the real conclusion is: someone has to make a native cross-platform desktop UI framework that doesn't suck. (Yeah Qt exists, but it really sucks...) Until then, everyone will default to just using the browser for a desktop app, and the beatings will continue. Because of this, I'm really looking forward for PanGUI to step up ( https://www.pangui.io/ ), their UI framework is very promising and I would start usi…

Never heard of PanGUI - glad to see its C#, will have to try it out.

They're making the initial version with C#, but they have plans to make the library language-agnostic. Rather than creating bindings, they'll write it in a subset of C# and then transpile it to C++/Jai/Zig/etc, so you can get the best language integration without the hassle of also wrangling with your build system.

Re: High-Level Is the Goal

#29

The Reddit example is about two different design choices. The DOM is a tree of state that needs to stay in sync with your app state. So how to make that happen without turning your code into a mess. The old Reddit had to first construct the DOM and then for every state change, determine what DOM nodes need to change, find them and update them. Knowing what needs to change gets ugly in a lot of apps. The other alterna…

The thing is that you can still have high-level abstractions without them needing to be as slow as React. React does a slow thing by default (rerendering every child component whenever state changes, so every component in the UI if top-level state is changing), and then requires careful optimisation to correct for that decision.

But you can also just... update the right DOM element directly, whenever a state changes that would cause it to be updated. You don't need to create mountains of VDOM only to throw it away, nor do you need to rerender entire components.

This is how SolidJS, Svelte, and more recently Vue work. They use signals and effects to track which state is used in which parts of the application, and update only the necessary parts of the DOM. The result is significantly more performant, especially for deeply nested component trees, because you're just doing way less work in total. But the kicker is that these frameworks aren't any less high-level or easy-to-use. SolidJS looks basically the same as React, just with some of the intermediate computations wrapped in functions. Vue is one of the most popular frameworks around. And yet all three perform at a similar level to if you'd built the application using optimal vanilla JavaScript.

Re: High-Level Is the Goal

#30
post #12

Earlier quoted context omitted.

There was WxWidgets.

The main consensus in the native space is that Qt is still miles ahead of any other cross-platform desktop framework (including WxWidgets). Doesn't mean that Qt is anywhere good - it's just the least worst option out of all. I hoped someday Flutter might be mature enough for desktop development, but so far they've focused most of their efforts on mobile and I don't think this will change in the future.

> The main consensus in the native space is that Qt is still miles ahead of any other cross-platform desktop framework (including WxWidgets). Doesn't mean that Qt is anywhere good - it's just the least worst option out of all.

That's not consensus. I very much reject a "desktop framwork". Qt has its own abstractions for everything from sockets to executing processes and loading images, and I don't want that. It forces one to build the entire app in C++, and that's because, although open-source, its design revolves around the needs of the paying customers of Trolltech: companies doing multi-platform paid apps.

I want a graphical toolkit: a simple library that can be started in a thread and allows me to use whatever language runtime I want to implement the rest of the application.

> I hoped someday Flutter might be mature enough for desktop development

Anything that forces a specific language and/or runtime is dead in the water.

Post reply on HN