Live data from Hacker News

A Broken Heart

allenpike.com

51–53 of 53 posts

Re: A Broken Heart

#51

Earlier quoted context omitted.

Will I ever wake up in a world where Vue is not slept on?

I would much rather use Vue than React too. That said, from a bird's eye view, I would say they're siblings. In a way I would say that Vue inherits the "react approach", and does it much (much) better, but its also not a fundamentally different approach.

Most definitely, I've always loved React ppl open a Vue codebase and be productive in like ~30 minutes.

Re: A Broken Heart

#52
post #15

> And despite being the least-bad approach for web frontends today, the React ecosystem... As if anyone has seriously tried anything other than the "reactive UI hacked together with callbacks or proxies, with weird XML-like syntax in the JS code" paradigm for the last 10 years. At this point I just have to conclude that anyone who believes this stuff is good is either too indoctrinated into this workflow or just lack…

I'd give people the benefit of the doubt. Personally, having built UI with Win32, WinForms, VisualBasic, Cocoa/Interface Builder, Qt, Tcl/Tk, XSLT, vanilla HTML/JS, jQuery, Backbone, Ember, Knockout, Bootstrap, MooTools, YUI, ExtJS, Svelte, Web Components, and React (including Preact, SolidJS…)… I'll happily choose the React approach. The only other one I would even describe as "good" was Qt. I also don't get why "XM…

You're clearly well-traveled, but it's unfortunate that none of the frameworks you listed follow the only UI paradigm I actually find enjoyable to work with.

Look Immediate Mode UIs when you have some time to kill. It's a famous paradigm in videogame UI development, so unfortunately most publicly available IMGUI libraries are tailored for use in game engine editor tooling (not very style-able, simple layout algorithms and assumption that they're running in a 60FPS loop), but they're still a good place to look at, to get a general idea. The most famous library is Dear ImGui [1]

The biggest advantage of the immediate mode approach is that you get UI/state syncing for free without having to manage any callbacks/getters/setters/magic properties. It introduces new problems (widgets are now defined implicitly and you need a system for keeping track of them over time), but they're way easier to solve than the UI/state sync issue.

Examples of real-non-video-game software that uses it are File Pilot [2] and RAD Debugger [3], which are modern desktop UI applications with all the modern desktop UI application bells and whistles.

[1] https://github.com/ocornut/imgui [2] https://filepilot.tech/ [3] https://github.com/EpicGamesExt/raddebugger

Re: A Broken Heart

#53
post #15

Earlier quoted context omitted.

I'd give people the benefit of the doubt. Personally, having built UI with Win32, WinForms, VisualBasic, Cocoa/Interface Builder, Qt, Tcl/Tk, XSLT, vanilla HTML/JS, jQuery, Backbone, Ember, Knockout, Bootstrap, MooTools, YUI, ExtJS, Svelte, Web Components, and React (including Preact, SolidJS…)… I'll happily choose the React approach. The only other one I would even describe as "good" was Qt. I also don't get why "XM…

You're clearly well-traveled, but it's unfortunate that none of the frameworks you listed follow the only UI paradigm I actually find enjoyable to work with. Look Immediate Mode UIs when you have some time to kill. It's a famous paradigm in videogame UI development, so unfortunately most publicly available IMGUI libraries are tailored for use in game engine editor tooling (not very style-able, simple layout algorithm…

Somewhat familiar with them, but can't say I've ever built anything with them. I'm curious though: are you aware that people already consider React and its cousins to be immediate mode style APIs for the Web? At least, as close as you can reasonably get when your rendering target is the DOM? That's why `UI = f(state)` is so often cited in React literature; components are functions that don't know anything about the "widget tree" or "instances" or anything like that, you always just return the latest output that you want with the data/input you receive, as if you are rendering "from scratch" each time. Components don't really know whether they're "initializing" or "updating" or anything like that, they just know they're "rendering"; React takes care of reconciling that output with the actual DOM.

So, if that's not good enough for you, what would an even more faithful immediate mode API even look like? (And if your idea includes ditching the DOM as the render target, which is inherently "retained mode" and could never be otherwise due to performance and DOM state (like focus), I'm afraid it's a nonstarter.)

Post reply on HN