Comment by rickcarlino
1 day ago
Building GUI utilities based on VB6 instead of status quo web technologies might actually be more stable and productive.
1 day ago
Building GUI utilities based on VB6 instead of status quo web technologies might actually be more stable and productive.
I would pick Delphi (with which you can build Windows, Linux, macOS, Android, and iOS apps - https://www.embarcadero.com/products/delphi)
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.
Yes, you can build cross-platform GUI apps with Delphi. However, that requires using Firemonkey (FMX). If you build a GUI app using VCL on Delphi, it's limited to Windows. If you build an app with Lazarus and LCL, you CAN have it work cross-platform.
I thought the point was that Windows apps will run on Linux under Wine (and macOS?) so using VCL is a cross-platform GUI development environment.
2 replies →
> 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.
> Wait you can make Android applications with Golang without too much sorcery??
Why don't you try it out: https://www.remobjects.com/elements/gold/
1 reply →
I started with VB6 so I'm sometimes nostalgic for it too but let's not kid ourselves.
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.
> 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.
>React’s approach is very inefficient - the entire view tree is rerendered when any change happens.
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.
3 replies →
Sure but the parents point was more about declarative UIs than React. SolidJS and Svelte are declarative.
Dioxus is halfway between React and Svelte, and is working on its own native renderer. Might be worth considering.
> That's why it went beyond web, and why all modern native UI frameworks have a similar model these days.
It's more the other way around, this model started on desktop (eg WPF) and then React popularized it on the web.
I would vote for Delphi/FreePascal, but share the sentiment.
I only had limited exposure to Delphi, but from what I experienced, it's big thumbs-up.
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.
Except on the AOT experience and low level programming, which only started to be taken seriously during the last five years.
Lua
Performance?
11 replies →
And more performant. Software written for 2005 Windows runs super fast on todays systems.
Sometimes I install Office 97 for kicks and marvel at how much I can do with it, yet it asks so little of my system. <2Mb RAM for Word 97!
Same, I used to use Office 2003 because it was so quick and the UI was exactly what you needed.
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.
Only if I don't need to do anything beyond the built-in widgets and effects of Win32. If I need to do anything beyond that then I don't see me being more productive than if I were using a mature, well documented and actively maintained application runtime like the Web.
That's not really true. Even in the 90s there were large libraries of 3rd party widgets available for Windows that could be drag-and-dropped into VB, Delphi, and even the Visual C++ UI editor. For tasks running the gamut from 3D graphics to interfacing with custom hardware.
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.
That sounds nice. I agree, not having a UI editor making apps is a step back. However, you seem to be discussing mostly in past tense.
Maybe one day something like Lazarus or Avalonia would catch up but today I feel that Electron is best at what it does.
If it is made to allow C codes to be combined with VB6 codes easily, and a FOSS version of VB6 (and the other components it might use) is made available on ReactOS (and Wine, and it would also run on Windows as well), then it might be better than using web technologies (and is probably better is a lot of ways). (There are still many problems with it, although it would avoid many problems too.)
Or VB.NET? In some ways it's actually easier than VB6
Honestly, it’s probably faster and less resource intensive through emulation than your average Electron app :-/
Wine Is Not an Emulator (WINE). It provides win32 APIs; your CPU will handle the instructions natively. There is no “probably” about it.
Traditionally WINE uses QEMU on Apple Silicon to execute x86 binaries on an ARM CPU, so while I’m aware WINE Is No an Emulator there’s likely emulation happening in a lot of cases.
Whenever people bring this up I find it somewhat silly. Wine originally stood for "Windows Emulator". See old release notes ( https://lwn.net/1998/1112/wine981108.html ) for one example: "This is release 981108 of Wine, the MS Windows emulator." The name change was made for trademark and marketing reasons. The maintainers were concerned that if the project got good enough to frighten Microsoft, they might get sued for having "Windows" in the name. They also had to deal with confusion from people such as yourself who thought "emulation" automatically meant "software-based, interpreted emulation" and therefore that running stuff in Wine must have some significant performance penalty. Other Windows compatibility solutions like SoftWindows and Virtual PC used interpreted emulation and were slow as a result, so the Wine maintainers wanted to emphasize that Wine could run software just as quickly as the same computer running Windows.
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.
2 replies →