Building GUI utilities based on VB6 instead of status quo web technologies might actually be more stable and productive.
Alternatively, RemObjects makes Elements, also a RAD programming environment in which you can code in Oxygene (their Object Pascal), C#, Swift, Java, Go, or Mercury (VB) and target all platforms: .Net, iOS and macOS, Android, WebAssemblyl, Java, Linux, Windows.
Wait you can make Android applications with Golang without too much sorcery??
I just wanted to convert some Golang CLI applications to GUI's for Android and I instead ended up giving up on the project and just started recommending people to use termux.
Please tell me if there is a simple method for Golang which can "just work" for basically being the Visualbasic-alike glue code to just glue CLI and GUI mostly.
Why don't you try it out: https://www.remobjects.com/elements/gold/
One of the key principles of f-droid is that it must be reproducible (I think) or open source with it being able to be built by f-droid servers but I suppose reproducibility must require having this software which is paid in this case.
Java Build code for any of the billions of devices, PCs and servers that run JavaSE, JavaEE or the OpenJVM.
.NET Core
The cross-platform .NET Core runtime is the future of .NET and will fully replace the current classic .NET 4.x framework when .NET Core 5 ships in late 2020.
It really seems like it was last updated sometime in the last decade. Not sure I want to base a future project on it.
We might take it for granted but React-like declarative top-down component model (as opposed to imperative UI) was a huge step forward. In particular that there's no difference between initial render or a re-render, and that updating state is enough for everything to propagate down. That's why it went beyond web, and why all modern native UI frameworks have a similar model these days.
Personally I much rather the approach taken by solidjs / svelte.
React’s approach is very inefficient - the entire view tree is rerendered when any change happens. Then they need to diff the new UI state with the old state and do reconciliation. This works well enough for tiny examples, but it’s clunky at scale. And the code to do diffing and reconciliation is insanely complicated. Hello world in react is like 200kb of javascript or something like that. (Smaller gzipped, but the browser still needs to parse it all at startup). And all of that diffing is also pure overhead. It’s simply not needed.
The solidjs / react model uses the compiler to figure out how variables changing results in changes to the rendered view tree. Those variables are wrapped up as “observed state”. As a result, you can just update those variables and exactly and only the parts of the UI that need to be changed will be redrawn. No overrendering. No diffing. No virtual Dom and no reconciliation. Hello world in solid or svelte is minuscule - 2kb or something.
Unfortunately, swiftui has copied react. And not the superior approach of newer libraries.
The rust “Leptos” library implements this same fine grained reactivity, but it’s still married to the web. I’m really hoping someone takes the same idea and ports it to desktop / native UI.
That's not true. React only re-renders down from where the update happens. And it skips over stuff that is provably unchanged -- which, fair, involves manual memoization hints. Although with React Compiler it's actually pretty good at automatically adding those so in practice it mostly re-renders along the actually changed path.
>And the code to do diffing and reconciliation is insanely complicated.
It's really not, the "diffing" is relatively simple and is maybe ~2kloc of repetitive functions (one per component kind) in the React source code. Most of complexity of React is elsewhere.
>The solidjs / react model uses the compiler to figure out how variables changing results in changes to the rendered view tree.
I actually count those as "React-like" because it's still declarative componentized top-down model unlike say VB6.
React only skips over stuff that's provably unchanged. But in many - most? web apps, it rerenders a lot. Yeah, you can add memoization hints. But how many people actually do that? I've worked on several react projects, and I don't think I've ever seen anyone manually add memoization hints.
To be honest it seems a bit like Electron. People who really know what they're doing can get decent performance. But the average person working with react doesn't understand how react works very well at all. And the average react website ends up feeling slow.
> Most of complexity of React is elsewhere.
Where is the rest of the complexity of react? The uncompressed JS bundle is huge. What does all that code even do?
> I actually count [solidjs / svelte] as "React-like" because it's still declarative componentized top-down model unlike say VB6.
Yeah, in the sense that Solidjs and svelte iterate on react's approach to application development. They're kinda React 2.0. Its fair to say they borrow a lot of ideas from react. And they wouldn't exist without react. But there's also a lot of differences. SolidJS and Svelte implement react's developer ergonomics, while having better performance and a web app download size that is many times smaller. Automatic fine grained reactivity means no virtual dom, no vdom diffing and no manual memoization or anything like that.
They also have a trick that react is missing: Your component can just have variables again. SolidJS looks like react, but your component is only executed once per instance in the page. Updates don't throw anything away. As a result, you don't need special react state / hooks / context / redux / whatever. You can mostly just use actual variables. Its lovely. (Though you will need a solidjs store if you want your page to react to variables being updated).
Even without any hints, it doesn't re-render "the entire view tree" like your parent comment claims, but only stuff below the place that's updated. E.g. if you're updating a text box, only stuff under the component owning that text box's state is considered for reconciliation.
Re: manual memoization hints, I'm not sure what you mean — `useMemo` and `useCallback` are used all over the place in React projects, often unnecessarily. It's definitely something that people do a lot. But also, React Compiler does this automatically, so assuming it gets wider adoption, in the longer run manual hints aren't necessary anyway.
>Where is the rest of the complexity of react?
It's kind of spread around, I wouldn't say it's one specific piece. There's some complexity in hydration (for reviving HTML), declarative loading states (Suspense), interruptible updates (Transitions), error recovery (Error Boundaries), soon animations (View Transitions), and having all these features work with each other cohesively.
I used to work on React, so I'm familiar with what those other libraries do. I understand the things you enjoy about Solid. My bigger point is just that it's still a very different programming model as VB6 and such.
UI libraries aside, I’d really love to see the same reactive programming pattern applied to a compiler. Done well, I’m convinced we should be able to implement sub-millisecond patching of a binary as I chance my code.
It's more the other way around, this model started on desktop (eg WPF) and then React popularized it on the web.
But if you liked that, consider that C# was in many ways a spiritual successor to Delphi, and MS still supports native GUI development with it.
On later versions they had animated cursor positions which felt slow, the spellcheck squiglies were lethargic and menus convoluted.
That said, I've given up and mostly use Google Docs/Sheets now because of the features and cross platform support.
It runs fine under WINE, and you can install the 3 service packs for it too. As released, when you try to save a .RTF file it actually doesn't. Not that that matters, but it's nice to have all the known the bug fixes.
It runs inside the L2 cache on any modern-ish CPU. Even on a Core 2 Duo, it's fast.
It is hilarious and sad to recall that when it came out -- I was working for PC Pro magazine around then -- it was seen as big and bloated and sluggish compared to Office 95. The Mac version, Office 98, was a port of the Windows version, and Mac owners hated it.
Now, it's tiny and sleek.
The web was a big step backwards for UI design. It was a 30 year detour whose results still suck compared to pre-web UIs.
Maybe one day something like Lazarus or Avalonia would catch up but today I feel that Electron is best at what it does.
Emulation does not mean that the CPU must be interpreted. For example, the DOSEMU emulator for Linux from the early 90s ran DOS programs natively using the 386's virtual 8086 mode, and reimplemented the DOS API. This worked similarly to Microsoft's Virtual DOS Machine on Windows NT. For a more recent example, the ShadPS4 PS4 emulator runs the game code natively on your amd64 CPU and reimplements the PS4 API in the emulator source code for graphics/audio/input/etc calls.