React gets used because no matter if there is a better way, that's what the company mandated. They want to hire "react devs".

Perhaps AI will help us by allowing us to swap to simpler and better solutions without the same level of pain and without necessarily having to hire experts in that new solution?

> a gigantic manual that lists every property of the system in excruciating detail, which is totally worthless for learning and barely usable as reference.

It's the only usable form of reference! I want all the details to be presented in a reference. Where else?

> low-level tools are terrible too

It seems to me the author is confusing lack of familiarity with lack of existence. There are lots of fantastic tools out there, you just need to learn them. They don't know them, so conclude they don't exist.

> We could have editor plugins and language servers to help beginners along

We already have all that.

I think the point about tooling being the problem deserves more emphasis. I'm a firm believer that the right thing to do should be the easiest thing to do. Currently, the easiest place to innovate is at the top of the stack, using web technologies and languages like JavaScript.

You can see this with languages like Rust and Go—they're some of the first low-level programming languages with actually good tooling, and, as a result, they're becoming very popular. I can pull down some code, run `cargo build`, and not have to worry about the right libraries being installed on my system and whether I've generated a Makefile. Packages are easily searchable, hosted on popular platforms like GitHub, and I can file bugs and ask questions without having to join an obscure mailing list or deal with an unfriendly community.

If you want your language/library/framework/layer in the stack to become popular, make the tooling good and make it easy for folks to get their questions answered. Everything else will follow.

I feel like the term 'engineering' implies bending the rules of reality to your goal in a way that is both economical and is very good at reaching the stated goal.

Like for example if you're an automotive engineer, you can't go ahead and put in the thickest beams made out of the strongest steel on hand, because the resulting car would weigh 20 tons and cost $300k. To add to that, it would probably drive like crap, and wouldn't even protect the driver that well.

In engineering, even a 10% waste is frowned upon. Here I outlined a waste of 10x. I don't think a Reddit comment opening/closing taking 200ms is a 10x waste, but a couple orders of magnitude more.

Why is that, that despite tons of very highly paid (moreso than any other kind) software 'engineers' work on websites like Reddit (which is not the only example of this trend), the result ends up like this?

It's not the lack of resources, constraints, pace of development (I don't remember the reddit site changing all that much in the past decade).

I think if software engineers have the mindset of other engineers, this thing would be considered ridiculous and unimaginable, like the 20 ton car is for automotive engineers.

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 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!

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.

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.

> Instead, I imagine a future where we have new “high-level” tools, built from lower in the stack.

This is exactly what I'm trying to build. I'm writing a library on top of Qt that would make it easy to write native code as easy as it is writing React code! I would say it's even easier since we are throwing all the constraints of browsers and web apis out of the way.

I feel like I'm somewhere on that Venn diagram O:-)

The specific examples in the article are about UI.

I agree that UI ecosystem is a big and slow mess, because there is actually a LOT of complexity in UIs. I would even argue that there is often more complexity to be found in UIs than in backends (unless you are working on distributed systems, or writing your own database). On backend, you usually just need paralellism (95% of jobs is just parallel for, map-reduce kind of thing).

But in UI, you need concurrency! You have tons of mutable STATE flying around that you need to synchronize - within UI, across threads or with the backend. This is /hard/ - and to come back to the point of the article - the only low-level language that I'm familiar with that can do it well and reliably is Rust.

In Rust, my absolutely favorite UI framework is egui. It is based on immediate mode rendering (maybe you're familiar with dearimgui), rather than the old, familiar-but-complex retained mode. It's really interesting stuff, recommend studying on it! Dearimgui has a wonderful quote that summarizes this well:

> "Give someone state and they'll have a bug one day, but teach them how to represent state in two separate locations that have to be kept in sync and they'll have bugs for a lifetime." -ryg

We use egui in https://minfx.ai (Neptune/Wandb alternative) and working with it is just a joy. Emilk did such a fantastic job bringing egui about! Of course it has its flaws (most painful is layouting), but other than that it's great!

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.

This is why I think the maximally from source bootstrap that Guix did, and that Nixpkgs is about to do too https://github.com/NixOS/nixpkgs/pull/479322 is so important.

These bootstraps essentially speedrun software history, and so they tell us a lot about how we got here, and why we write the things we write. But they also create perfect game to weite greenfield alternative bootstraps. The shortest, most readable bootstrap, is proof of the best abstractions, the best way of doing things.

It's a chance to finally put the sort of software stack / tech tree stuff on a more apples-to-apples basis.

I think people overestimate the necessity of 'high level' conveniences or the difficulty of writing C/C++ to the metal.

For example, take Dear.IMGUI which is a c++ UI framework with a kind of data binding, which generates vertex buffers which can be directly uploaded to the GPU and rendered.

It supports most of the fancy layout stuff of CSS afaik (flexbox etc), yet its almost as low level as it gets.

The code is also not that much harder to write than React.

When you can build down as well as up (https://ngnghm.github.io/blog/2015/08/24/chapter-4-turtling-...) — or, equivalently, do away with the up/down orientation entirely, you can have your cake and eat it too.

And as a bonus if you control both slices of bread it's much easier to change the sandwich filling as well! (Though if the original sandwich-builder wasn't careful you might find some sticky residue left over on your bread… maybe someone should take this metaphor away before I do more damage.)

I would say 80% of the software quality issues come from the context and constraints defined by the requirements complexity, design choices, stack selection, infra decisions, org processes and so on. A lot of this context is tied to org policies and non-technical decisions. AI is not going to redefine this context. It can only increase code production and code level quality. But the source of 80% of the issues remain intact.

While I am totally on board with the idea... the article doesn't really say what to actually do to help?

"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?

Something interesting happened, this is the first time I read him and just after I finish the article and I get into YouTube YouTube recommends me a video from the author with the same title

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

Side note, but this article reads like a Wes Anderson film, if that makes any sense.

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?

undefined

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.

I created a https://ideawell.fly.dev/ just for this particular goal, identify pain points and project ideas from HN discussions

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.

For those interested here's the talk that this is from:

https://www.youtube.com/watch?v=AmrBpxAtPrI

We should start making low-level enjoyable

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.

> At the time, it took New Reddit almost 200 milliseconds to collapse a single comment. That is 200 milliseconds of pure JavaScript, with hardly any DOM work in sight. If you care about quality software, your jaw should be on the floor. It is a staggering amount of waste for what should have been a few DOM calls. And you feel it as a user: an ugly, intense hitch.

> New Reddit was a React app

Many such cases. React is basically synonymous with horrible lag and extreme bloat to me. Its name is the highest form of irony.

I'm really not sure why JS frameworks in general are so popular (except to facilitate easy corporate turnover), when the browser already gives you a pretty complete toolset that's the easiest to use out of any GUI library in existence. It's not low level by any means.

Granted something like an <include html component> feature is desperately missing from the html spec, but there are lightweight solutions for it.

> a Redux action, which would update the global Redux store, which would cause all Redux-connected components on the page to update, which would cause all their children to update as well. In other words, collapsing one comment triggered an update for nearly every React component on the page. No amount of caching, DOM-diffing, or shouldComponentUpdate can save you from this amount of waste.

yeah this is pretty much 1. an incorrect implementation and/or 2. an incorrect take

and easily solvable with a bit of 'render auditing' / debugging

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.

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.

A few thoughts:

* These articles always say that hardware is amazing but software sucks. Let's not forget that hardware has its problems. Intel's management engine is a pile of complexity: https://www.zdnet.com/article/minix-intels-hidden-in-chip-op.... The x86_64 instruction set is hardly inspiring, and I imagine we lose a pile of performance because it fails to adequately represent the underlying hardware. (E.g. there are hundreds of registers on modern CPUs, but you can't access them directly and just have to hope the hardware does a good job of register allocation.)

* Languages unlock performance for the masses. Javascript will never be truly fast because it doesn't represent the machine. E.g. it doesn't have distinct integer and floating point types. Rust represents the machine and is fast, but is not as ergonomic as it could be. OxCaml is inspiring me lately as it's an ergonomic high-level language that also represents the machine. (Scala 3 is also getting there with capture checking, but that is still experimental.) If we want more performance we have to give a way to efficiently write code that can be turned into efficient code.