Sure, high level is the goal. But the question is whether the abstractions are the correct ones that fit the problem. Almost all software that I have encountered that was painful to work with chose a framework that did not apply to their situation.
E.g., develop a generic user interface framework which makes it very quick to produce a standard page with a series of standard fields but at the same time makes it very painful to produce a non-standard layout. After that is done it is 'discovered' that almost all pages are non-standard. But that 'discovery' could also have been made in five minutes by talking to any of the people already working for the company....
Another example: use an agent system where lots of agents do almost nothing, maybe translate one enum value to another enum value of another enum type. Then discover that you get performance problems because agent traffic is quite expensive. At the same time typical java endless typing occurs because of the enormous amount of agent boilerplate. Also the agents that actually do something useful become god classes because basically all non-trivial logic goes there....
I really like the sentiment here, and Handmade Network has such a cool vibe, but I can't help but think that he/they would have a bigger impact by focusing more on illustrating to people how this mindset leads to value and less on teaching and learning the skills.
>Building it yourself might sound crazy, but it’s been done successfully many times before—for example, Figma famously built their app from scratch in WASM and WebGL, and it runs shockingly well on very large projects.
Yes, let's hear more about this. "Collapsing Reddit comments could have been like 180ms faster" isn't very convincing to smart, ambitious people deciding what they want to be about. Find more examples like Figma and get people to believe that there's still lots of room for up and comers to make a name for themselves by standing on their performance, and they'll take care of the learning and building themselves.
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 using it in a heartbeat when the beta actually releases!
IDK, it seems like old reddit did just fine without even trying that hard. The DOM and surrounding JS API is already a high level GUI framework, and the post illustrates that it's perfectly capable of doing useful interactions >60fps. I personally love working with native code, but the modern browser is capable of producing fast interfaces that saturate human senses without it. If you write JS like a C programmer would, it will usually be quite fast, even if it's not optimal. If you write native apps in C++ like a modern JS programmer - frameworks and deps with abandon - it will be a stuttery mess.
When the DOM is not enough, there's already WebGL and WASM. A vanishingly small sliver of use cases can't saturate human senses with these tools, and the slowest, jankiest websites tend to be the least deserving of them (ie: why is jira slow? It's literally a text box with a handful of buttons on the side!).
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.
>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.
PanGUI seems to be interesting. However being mobile ready would matter a lot for adoption and I couldn't see anything on their sites regarding mobile platforms.
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)
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.
> I hoped someday Flutter might be mature enough for desktop development
I really don't think there is any broad future for Flutter. Requiring adoption of a new programming language is making an already an uphill battle even steeper, and the way they insist on rendering websites in a single giant canvas is... ugh
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)
> 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.
> 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.
Yes, that is the consensus of why Qt sucks - it's a massive framework that tries to do everything at the same time with a massive toolset of in-house libraries. This is inherently tied to the revenue model of the Qt Company - sell custom modules that work well with the Qt ecosystem at a high enterprise-level price. I also wish to just use the "good" parts of Qt but I can't, since it already has a massive QtCore as its dependency.
However, there is still no cross-platform framework except for Qt that can actually do the most important things that a desktop framework actually needs: an actual widget editor, styling and theming, internationalization, interop with native graphics APIs (though I have gripes with their RHI system), etc. That's why I'm rooting for PanGUI (https://www.pangui.io/) to succeed - it pretty much completes all the checkboxes you have, but it's still WIP and in closed alpha.
> 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.
Yeah, but at that time I thought this was at least better than wrangling with Qt / QML. You can write the core application logic ("engine" code) in C++ and bind it with Dart. There are already some companies I've seen gone a similar route with C# / WPF.
As far as I can tell, PanGUI is a drawing library not a graphical toolkit. Its primitives are geometrical, not widgets. Its showcase is an audio app, which is as far away as possible from a boring productivity application that I'd like to do.
In my university days I was very much into GUIs, and I've written apps with wxWidgets, plain Gtk 1 and 2, GNOME 2, Qt, Tk, GNUstep and even some fairly obscure ones like E17 and FTLK. For my tastes, the nicest ones were probably GNOME2, Elementary and wxWidgets. Especially GNOME2, which had a simple builder that let me create the basic shell of an app, with some horizontal and vertical layout boxes that I could later "hydrate" with the application logic.
>That's why I'm rooting for PanGUI (https://www.pangui.io/) to succeed - it pretty much completes all the checkboxes you have, but it's still WIP and in closed alpha
They say it's in beta and it seems anyone can sign up for the beta.
Really enjoyed reading this. Stuff like this is what inspires me to keep pursuing logos language and theorem prover. Things on the roadmap next include stuff like adding first-class inline ASM support. Adding great SPMD and auto-vectorization pipelines, and exploring making verifiable private computation a language primitive when you make things private. If interested, read about some of the planned upcoming enhancements here. :) https://github.com/Brahmastra-Labs/logicaffeine/issues
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.
There is Slint (https://slint.dev/), which was a company founded by ex-Qt devs and seem to be trying to make a better alternative to Qt. The core engine is built wiht Rust, but they also provide C++ and JS bindings and also have a QML-like scripting language you can use to design UI quickly. So far I think they've solidified their revenue model by catering to embedded devices, but I haven't seen a solid usecase for desktop apps (yet...)
He makes an interesting point that we are coding programs that run more slowly now than they did 10 years ago. Javascript has only gotten faster over the last decade, computer have faster CPUs and more RAM. The problem is the frameworks and the programs have gotten slower.
What did we gain exactly? Reddit is better at displaying videos and images now. But it's slower despite faster hardware.
I hate the state of affairs. That said my guess is what we „gained“ is tons of telemetry, tracking and the likes, engineers not needing to think about performance to get a feature out, which absolutely lowers the bar to entry, high level abstractions and ux and visual bells and whistles of varying importance and quality (infinite scrolling, streaming updates, image blend modes, blur effects, scroll timeline animations etc). People creating Pokémon had to think about every bit in their texture atlas and carefully manage the hardware memory manually. Web devs now try not to forget to clean up event listeners in a useEffect that triggers on mouse move to generate data for an interaction heatmap for the marketing department while 25mb of 3rd party scripts make sure every data broker and their mother is well informed about your digital whereabouts.
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 it was easiest to reason about. It still wasn't great. In fact, still isn't great. But it's the best blend of many leaky abstractions we use to code against the browser apis.
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)
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 alternative is to realize that constructing a DOM from any arbitrary state is pretty much the same as constructing it from initial state. But now you don’t have to track what DOM nodes must change on every state change. This is a massive reduction in code complexity. I will grant that there is something similar to the “expression” problem. Every time there is a new state element introduced it may affect the creation of every node in the DOM. As opposed to every time a UI element is added it may affect every state transition. The first Reddit can be fast, but you have to manage all the updates. The second is slow, but easier to develop. I’m not sure going any lower solves any of that. The React version can be made more efficient through intelligent compilers that are at better at detecting change and doing updates. The React model allows for tooling optimizations. These might well beat hand written changes. The web has complexity also of client/server with long delays and syncing client/server and DOM state, and http protocol. Desktop apps and game engines don’t have these problems.
We measure computer performance in the billions and trillions of ops per second. I'm sorry but if it an app takes 200ms to hide some comments, the app or the tech stack it's on is badly made.
> The web has complexity also of client/server with long delays and syncing client/server and DOM state, and http protocol. Desktop apps and game engines don’t have these problems.
Hugely multiplayer games consistently update at under 16ms.
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.
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.
It is blatantly obvious to anyone with just a little bit of experience that the reddit devs barely know what they are doing. This applies to their frontend as well as backend. For some reason, reddit is also the only major social network where downtime is expected. Reddit throwing 500 errors under load happens literally every week.
Yeah it's a call to action to improve the tooling but it's not the first one I've seen. Tooling really is under focused in many areas.
It would be nice if every language and library had a great working repl and a Jupyter Lab kernel and good mdn-like documentation and w3schools-like tutorials.
My exact complaint. What is the "handmade" community? At first I thought he was talking about woodworking or knitting.
Also the reddit comparison is great, but I wish he would have talked about why the slop is there in the first place.
I'm pretty sure new reddit isn't optimized for speed, it's optimized for analytics and datamining.
I bet they use all those backend calls to get really granular session info. When something is super slow, it's not that it's unoptimized, but rather it's optimized for money over user experience.
I enjoyed reading this article but I think the author overlooked that "low-level" languages aren't just less supported, they're also character-dense. You can accomplish more with less, simply because it's a higher level abstraction. If you choose to abstract through this problem, aren't you creating a high-level language?
Yes exactly. The only thing this article says about low level programming is that low level programmers have "no drive to innovate". So apparently the idea is to attract a bunch of new people to low level programming, tell them that all the existing low level stuff is crap, and that they should build a bunch of new frameworks as quickly as possible without learning from anyone.
Okay, this is an exaggerated description of the article. It doesn't literally say that. But you could come away with that impression, because the article is so poor. I mean, look at all the comments here trying to figure out what it's proposing. There may be a good initiative here, but basically they need to delete this article and start over.
I really agree with the point about React and Redux. It is crazy that collapsing a comment can take 200ms just because of the framework overhead. We have way too much power in our computers to be okay with this kind of lag in basic UI tasks.
This is a good reminder that abstractions are supposed to help us solve problems rather than just hide the details. I feel like I spend too much time fighting against tools that try to prevent me from seeing how things really work.
OS is to blame. There should be a way for the OS to tell to the app "offload your state" like phones do. Paging is supposed to achieve this but does not.
E.g., develop a generic user interface framework which makes it very quick to produce a standard page with a series of standard fields but at the same time makes it very painful to produce a non-standard layout. After that is done it is 'discovered' that almost all pages are non-standard. But that 'discovery' could also have been made in five minutes by talking to any of the people already working for the company....
Another example: use an agent system where lots of agents do almost nothing, maybe translate one enum value to another enum value of another enum type. Then discover that you get performance problems because agent traffic is quite expensive. At the same time typical java endless typing occurs because of the enormous amount of agent boilerplate. Also the agents that actually do something useful become god classes because basically all non-trivial logic goes there....
>Building it yourself might sound crazy, but it’s been done successfully many times before—for example, Figma famously built their app from scratch in WASM and WebGL, and it runs shockingly well on very large projects.
Yes, let's hear more about this. "Collapsing Reddit comments could have been like 180ms faster" isn't very convincing to smart, ambitious people deciding what they want to be about. Find more examples like Figma and get people to believe that there's still lots of room for up and comers to make a name for themselves by standing on their performance, and they'll take care of the learning and building themselves.
It's fairly compelling to an audience who spends a lot of time browsing reddit, however
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 using it in a heartbeat when the beta actually releases!
When the DOM is not enough, there's already WebGL and WASM. A vanishingly small sliver of use cases can't saturate human senses with these tools, and the slowest, jankiest websites tend to be the least deserving of them (ie: why is jira slow? It's literally a text box with a handful of buttons on the side!).
It sounds like a clever idea.
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)
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.
I really don't think there is any broad future for Flutter. Requiring adoption of a new programming language is making an already an uphill battle even steeper, and the way they insist on rendering websites in a single giant canvas is... ugh
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.
Yes, that is the consensus of why Qt sucks - it's a massive framework that tries to do everything at the same time with a massive toolset of in-house libraries. This is inherently tied to the revenue model of the Qt Company - sell custom modules that work well with the Qt ecosystem at a high enterprise-level price. I also wish to just use the "good" parts of Qt but I can't, since it already has a massive QtCore as its dependency.
However, there is still no cross-platform framework except for Qt that can actually do the most important things that a desktop framework actually needs: an actual widget editor, styling and theming, internationalization, interop with native graphics APIs (though I have gripes with their RHI system), etc. That's why I'm rooting for PanGUI (https://www.pangui.io/) to succeed - it pretty much completes all the checkboxes you have, but it's still WIP and in closed alpha.
> 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.
Yeah, but at that time I thought this was at least better than wrangling with Qt / QML. You can write the core application logic ("engine" code) in C++ and bind it with Dart. There are already some companies I've seen gone a similar route with C# / WPF.
In my university days I was very much into GUIs, and I've written apps with wxWidgets, plain Gtk 1 and 2, GNOME 2, Qt, Tk, GNUstep and even some fairly obscure ones like E17 and FTLK. For my tastes, the nicest ones were probably GNOME2, Elementary and wxWidgets. Especially GNOME2, which had a simple builder that let me create the basic shell of an app, with some horizontal and vertical layout boxes that I could later "hydrate" with the application logic.
They say it's in beta and it seems anyone can sign up for the beta.
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.
What did we gain exactly? Reddit is better at displaying videos and images now. But it's slower despite faster hardware.
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
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)
You have that backwards – jQuery predates querySelector by years.
The reason why getElementById is fast is because it’s a simple key lookup.
> The web has complexity also of client/server with long delays and syncing client/server and DOM state, and http protocol. Desktop apps and game engines don’t have these problems.
Hugely multiplayer games consistently update at under 16ms.
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.
"we at Handmade community" - and no link to that community anywhere
blog itself? 2 posts a year, and 2025 posts aren't even on the blog itself (just redirects)
Yes, tooling and toolmaking should be promoted - but promotion itself should also be accessible somehow?
It would be nice if every language and library had a great working repl and a Jupyter Lab kernel and good mdn-like documentation and w3schools-like tutorials.
https://handmade.network/
Here's the manifesto: https://handmade.network/manifesto
Also the reddit comparison is great, but I wish he would have talked about why the slop is there in the first place.
I'm pretty sure new reddit isn't optimized for speed, it's optimized for analytics and datamining.
I bet they use all those backend calls to get really granular session info. When something is super slow, it's not that it's unoptimized, but rather it's optimized for money over user experience.
Okay, this is an exaggerated description of the article. It doesn't literally say that. But you could come away with that impression, because the article is so poor. I mean, look at all the comments here trying to figure out what it's proposing. There may be a good initiative here, but basically they need to delete this article and start over.
https://www.youtube.com/watch?v=AmrBpxAtPrI