Live data from Hacker News

High-Level Is the Goal

bvisness.me

51–60 of 158 posts

Re: High-Level Is the Goal

#51

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…

> "Collapsing Reddit comments could have been like 180ms faster" isn't very convincing to smart, ambitious people deciding what they want to be about

It's fairly compelling to an audience who spends a lot of time browsing reddit, however

Re: High-Level Is the Goal

#52
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.

> 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

Re: High-Level Is the Goal

#53

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…

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 wou…

> (ie: why is jira slow? It's literally a text box with a handful of buttons on the side!).

Despite me agreeing with your overall point, this is such a ridiculous comment to make. You and I both know Jira is much much more than that. Reductive things like this just turn off people who would otherwise listen to you.

Re: High-Level Is the Goal

#54
> 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

Re: High-Level Is the Goal

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

Re: High-Level Is the Goal

#58

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…

I have yet to find a cross-platform UI framework that really feels native on Gnome. The reality is that there is no shortcut for native UI on all platforms, you have to use the “official” framework (e.g. GTK for Gnome). In my opinion the only softwares that should use a custom framework are professional grade apps where custom workflows can’t fit the native UI (e.g. Blender). Despite all the noise about native cross-platform frameworks, it’s absolutely not fooling anyone, we can spot this immediately on any platform.

Re: High-Level Is the Goal

#59
post #39

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.

The frameworks have NOT gotten slower! God I hate Hackernews sometimes... whats really going on is actually that not a single dev reads the release notes / improvements / learns how to actually use the framework. If anything, the latest React release was almost purely a performance improvement release (and has been for a while) ...most people need to fully understand a tool they use before complaining about it.

Everyone always wants a frontend framework that "just works" - sounds a lot like a free lunch to me! You have to manage the state and updates of your application at some point - the underlying software cant just "guess" what you want. But I'm always like a broken record when these react hate / hate threads show up - most of the confusion is derived from lack of basic concepts of what problems these frameworks solve in the first place.

Re: High-Level Is the Goal

#60
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.

Post reply on HN