5 ms·
Building GUI utilities based on VB6 instead of status quo web technologies might actually be more stable and productive.
by rickcarlino 10mo ago
Building GUI utilities based on VB6 instead of status quo web technologies might actually be more stable and productive.
- steve1977 10mo agoAnd more performant. Software written for 2005 Windows runs super fast on todays systems.
- HeckFeck 10mo agoSometimes 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!
- apatheticonion 10mo agoSame, 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.
- lproven 10mo agoSame here. I have a physical copy of Word 97, although TBH I use the classic licence key 11111-111111111 to "activate" it because it's easier. 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.
- andy_ppp 10mo agoHonestly, it’s probably faster and less resource intensive through emulation than your average Electron app :-/
- jeremyjh 10mo agoWine Is Not an Emulator (WINE). It provides win32 APIs; your CPU will handle the instructions natively. There is no “probably” about it.
- ndiddy 10mo agoWhenever 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 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.
- jeremyjh 10mo agoSure, you can call it an emulator in that sense but how does that imply anything at all about performance? That is what I was responding to.
- 10mo ago
- pjmlp 10mo agoI would vote for Delphi/FreePascal, but share the sentiment.
- NooneAtAll3 10mo agoLua
- pjmlp 10mo agoPerformance?
- Etheryte 10mo agoIf there was sufficient interest in it, most performance issues could be solved. Look at Python or Javascript, big companies have financial interest in it so they've poured an insane amount of capital into making them faster.
- vips7L 10mo agoIsn’t python still the slowest mainstream language?
- Etheryte 10mo agoBeing slower than other mainstream languages isn't really a problem in and of itself if it's fast enough to get the job done. Looking at all the ML and LLM work that's done in Python, I would say it is fast enough to get things done.
- NetMageSCW 10mo agoAs pointed out already, most of that uses C code or GPU code to do the work and not slow Python code.
- 10mo ago
- deleted 10mo ago[deleted]
- bobajeff 10mo agoOnly 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.
- jlarocco 10mo agoThat'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.
- bobajeff 10mo agoThat 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.
- andsoitis 10mo agoI would pick Delphi (with which you can build Windows, Linux, macOS, Android, and iOS apps - https://www.embarcadero.com/products/delphi 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.
- Imustaskforhelp 10mo ago> 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.
- andsoitis 10mo ago> 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/ https://www.remobjects.com/elements/gold/
- Imustaskforhelp 10mo agoIt's really price-y and I am not sure about if I could create applications for f-droid if they aren't open source and how it might go with something like remobjects.com/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.
- dardeaup 10mo ago
- danabramov 10mo agoI 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.
- josephg 10mo ago> 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.
- Philpax 10mo agoDioxus is halfway between React and Svelte, and is working on its own native renderer. Might be worth considering.
- c-hendricks 10mo agoSure but the parents point was more about declarative UIs than React. SolidJS and Svelte are declarative.
- zzo38computer 10mo agoIf 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.)
- 0xbadcafebee 10mo agoOr VB.NET? In some ways it's actually easier than VB6