Basically this is what Figma could be if you could add behavior to the UI. Somehow the web has been running backwards for years now. We lost flash in favor of HTML 5, which sort of fizzled out in terms of creative people actually doing a lot with it. We used to have simple application builders in IDEs like Visual Basic, Delphi, Borland JBuilder. Even Eclipse had a simple swing UI builder thing for a while. For the web we had dream weaver, frontpage, etc.
I'm not saying those tools were perfect; because they weren't. But we never really got good substitutes for them. We now have people "designing" stuff in Figma and then handing over for implementation to some developer team that essentially then recreates the whole thing pretty much from scratch. There's something deeply stupid/wasteful about needing to do that.
> I'm not saying those tools were perfect
Bite your tongue. Flash was perfect.
> We now have people "designing" stuff in Figma and then handing over for implementation to some developer team that essentially then recreates the whole thing pretty much from scratch. There's something deeply stupid/wasteful about needing to do that.
I'm not sure how wasteful it is really. There is some overlap, but not loads in my experience. Most of the time spent on frontend is the stuff behind the components: behaviour; device interaction; security; API calls.
I've had a weirdly large fraction of my career spent on making UI rather than business logic.
That said, the business logic in apps is, half the time, a needlessly complex shim on what is ultimately "here's a REST API you can do in one or two lines via `Codable` etc. except we're anticipating needing to support several API providers… oh no the money ran out".
> I've had a weirdly large fraction of my career spent on making UI rather than business logic.
Same here. None of my employers could go more than 2 years or so, before the head of UX would declare "Our app is no longer 'fresh' enough, and our competitors are adding 'pop' and 'zing' to their apps! We must stop what we are doing and totally redesign our app, create custom controls, and flex our brand onto the user!" Too much of my career has been turning a designer's Photoshop graphic pixel-for-pixel into an application, without regard to the OS's standard controls or conventions.
Yup, which is where I suspect most of the "visual UI builders are not the right tools to express dynamic constraints" objections come from: people are over-constraining the problem space with irrelevant nonsense. Half of the problems stem from abandoning OS standard controls, many of the rest are managing complexity of a large and complex UI codebase that didn't need to exist in the first place.
It's not like most webapp UIs are particularly well-aligned or consistent anyway, nor they are easy to visually overhaul on marketing teams' whim - so, what's the point? Why use tools that make important and impactful things between difficult and impossible?
(A possibly legitimate argument against RAD tools is that they encourage mixing business logic with UI code (static and dynamic). I used to be receptive to that, but I long come into conclusion that "separation of content and presentation" is bullshit both conceptually and in practice. And guess what, with React & all, we're all back to mixing UI and business logic - or adding extra layers of complexity to pretend we're not.)
Not mixing business logic kind of stops being possible when the UI needs to follow your business logic. We used to do much less complex, less specialized apps. And on the other hand - building an universal business rule engine just because you needed a wizard with three business process steps seems excessive.
There is quite some overlap, but the CSS generated by Figma is not really useful and of a grade I’d want in my application. On the other hand, there is a gradient where building in all the behaviour you could want in a designer application, makes the application so complex that it become unusable for designers.
I don't think visual UI builders were ever the way forward. These work well for static UIs, but once you try to express dynamic constraints, they fall apart.
Figma shows this: I find it useful to absolutely position elements (and maybe work with symbols) for a quick prototype, but once I bring in autolayout, I end up dealing with exactly the same issues as with CSS-flexbox and grids - except in a vastly inferior system, where I don't have version control, refactoring tools and chatGPT. Also, subjectively, I find it much easier to work directly with XML-structure, than to double-click (or cmd-click) through 15 groups in order to select a specific component, and then modify its properties in a textual form.
I'm guessing that's why Apple and Android deprecated their interface builders in favor of DSLs.
Very nicely done, now a Delphi and I can finally be happy about the state of development again.
Sourcecode: https://github.com/BAndysc/AvaloniaVisualBasic6
Edit: someone information about Lazarus deleted their comment, my answer;
I know about Lazarus yes; I use it for my old projects. I would like a modern version that also works in-browser and .NET seems good for that as this shows. Maybe based on this https://pascalabc.net/en/ .
Not kidding; I still enjoy Pascal/Lazarus (and common lisp) programming more than anything current; none of the anxiety and all of the joy and productivity.
Just because you can use some technology in .net on the client and inside the browser does not mean you should. Most of the time these frameworks have huge tradeoffs and once you are using it, you will quickly be locked in.
I.e it’s way easier to migrate from mvc to mvc than from webforms to blazor/avaloniaui/dotvvm
Needs more Turbo Pascal/C++
VB6 was the best IDE by far for people that get things done right now.
I was installing PC based CCTV systems for a living back in mid 2000s, I had a restaurant customer have their mind blown by pandoras music service while demoing the PC. They asked "can I hear this over the restaurant speakers?". Yeah, I got 3.5mm to RCA to BNC in the car which I can run to your AMP.
Now he was really happy, felt like he got launched into the 21st century.
"Can I pause the music and make an announcement to my customers?". I made him a shortcut on the desktop to sndvol32.exe aka sound mixer so he can talk over the speakers and then resume the music and he was again floored.
"I want my staff to be able to do this but not here in my office but at the front counter".
Easy. "Give me a paper clip and 30 minutes". Went to the car to grab some stranded Cat 5 and an old beige two button IBM mouse. Ran the cables from the office to the reception area, soldered a cat-5 pair to the left mouse clicker, drove a sheetrock screw threw the mouse body to mount it on the wall like a taxidermied deer head. Back in the office I soldered the leads to the paper clip so I could have a solid connection to the LPT port on the PC (I didn't carry DB-25 back then).
It was easy from there: googled "VB6 Volume Mixer". Download that, open the checkbox for mute stereo mix, copy one liner into a timer, set interval for 100ms, check if the pins on the LPT are shorted, if so mute stereo mix, unmute the mic.
This was written in the field without any pre planning. I still have this customer to this day. What a great tool for us "jacks of all trades".
I'm pretty sure I read a reddit comment a few years ago where someone said they were a customer in a resturant, and they saw resturant employees click on a mouse attached to the wall to make an announcements (I think notify that an order was ready). It sounds like a very unique setup, so it was probably this one!
I was so productive in VB5/6 back in the late 90s/early 00s. I made tons of utility apps to solve all kinds of little problems. It was just so easy to put things together. I tried to make the transition to vb.net but it was not the same thing.
The VB6 Winforms builder here is almost 100% identical to the Winforms builder in the latest release of Visual Studio 2022 that came out today.
I use it for hours every day to just drag and drop a few components onto a form and add some logic and have a little desktop app up and running in a few minutes.
I (sadly) code in C# since 2021, because the support is better, but I honestly believe VB.NET was superior because of the increased readability of the code.
I know the feeling, I was the go to VB6 guy in college for writing test automation on equipment over GPIB, UART, RS422, etc. I made bank as a grad student from the EE department, I quit my TA position and they replaced me as instrumentation guy :) . Paid for my masters for the most part.
It was rad!
This reminds me of one of the best programming tools at the time. Moving from basic to vs basic was mind blowing. I still miss such tools in the Modern era. There are lot of so called no-code or low-code tools that does things very differently today. I still think the best low-code is what VB did.
And honestly, with the reactive programming approach ... a related UX for IDE should not be that hard either.
I think most framework developers unfortunately forget productivity as a key metric. Might be a bit unfair however, the lack of visual tools is disappointing.
The issue today is that developers would create their own framework, most likely something TypeScript-based running in Node or Deno or some Rust-based thing like Tauri, which all might be OK, but with their own opinionated UI styleguides and features, where then half of the native OS functionality then won't work.
You see a somewhat related degeneration in Redmond, where the new Windows Explorer doesn't have an icon in the address bar which is actually draggable so that a shortcut to the currently open folder can be created on the desktop or anywhere where such a shortcut can be used (think TrueLaunchBar). Now you have to go to the parent folder in order to Alt-Drag the folder to create a shortcut.
It's those little things which where smartly developed during the 80s and 90s, which "modern" developers seem not to have noticed and therefore just ignored while re-implementing applications like the Windows Explorer.
There are so many Chesterson's Fences[1] being destroyed with modern UX design. Everyone just wants to change things for change's sake. Or worse, to simply have another piece of unique artwork for one's portfolio. Whenever I've tried to push back on Yet Another Big UI Design, the reasons for doing it are always so vague: Our current product looks "dated." It's not "fresh." Competitors' products look "sleeker." We're using "outdated" design language. So we overhaul the application, throwing years of know-how and bugfixes away in all the refactoring.
1: https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence
Alt-drag from the parent folder... so that's the workaround... thanks for the tip on handling this deprecated feature.
Not only has the folder address icon-drag been lost in the name of progress, so too have dozens of previously useful keyboard shortcuts, plus the core ability to re-dock Windows Start Bar onto any edge of the screen... nowadays in Win11 we are restricted to only docking at the bottom.
> And honestly, with the reactive programming approach ... a related UX for IDE should not be that hard either.
I think that's what Apple is attempting with SwiftUI previews in Xcode; given how long that took to not suck, I'd say it's probably harder than it seems.
Whoa. VB6 was totally what got me into software development as a kid. A blast from the past I needed today, thanks.
Same. But it didn't take me long, with the exuberance of youth, to declare BASIC a worthless language, and then moved to MS Visual C++ 6.
C++ and MFC was worse for different reasons, but then I discovered Linux and the rest is history.
Still, haven't found anything as powerful as VB6's RAD. These days we lay out UIs by hand or by writing XML, like absolute cavemen.
> Still, haven't found anything as powerful as VB6's RAD
We could easily do this now if companies would accept standard UI component styles instead of everyone inventing their own.
Layout has nothing to do with styling. The placement of a button has nothing to do whether it's a native one or it's green.
Even on the web, the set of controls we use are mostly the same we did in the 90s, except everyone styles them differently.
And everyone reinvents their own way to lay them out, and handle the dynamic consequences. It may or may not be a consequence of the web stack inherently tying together layout and styling; nevertheless the layout part was in the past done easier and better with visual tools.
I didn't say otherwise.
It is funny I had the same exact journey but starting from VB4. I actually wonder what would have happened if instead of killing VB for .NET that Microsoft instead merged legacy VB into the Office team and actually updated it instead of the perpetual state of deprecation that it has been in.
Cavemen had declarative UIs?
VB was the absolute sweet spot when you used Visual C++ to create performant DLLs which you could then use in VB.
Same. A pirate copy of VB6 and a download of some website which gave a reasonable introduction of how to do things. I remember doing things like using the Win32 API to get DMA to images so I could do pixel perfect collision detection between sprites etc. Fun times.
> A pirate copy of VB6
exactly how i did it as well! But it was a pirated copy of visual studio (6?) and it came in 6 CDs. I had no idea what it actually was, and just installed it and played around.
I'm so glad that i bought those pirated CDs off the street - it was a huge stack of disks for like $50 bucks, and it included a bunch of pirated games, pirated encyclopedia (brittanica at the time iirc), various music software (cakewalk pro, not that i ever used it).
There would not have been a chance in hell i'd discover these things by myself.
6 CDs because VS6 comes with 3 CDs and 3CDs for MSDN.
But later they switched to new format of MSDN and old IDEs can't use them. And there was some add-on that allow to old IDEs to use new MSDN format.
I have a very similar memory, building a Spacewar-type game and experimenting with low level stuff to try to get things flicker-free
Perusing the authors Github, it looks like they also maintain the UI library for the classic Win9x look and feel: https://github.com/BAndysc/Classic.Avalonia
I love it, I might have to try making my own app using it
IMO that library is worth a submission as much as the VB6 recreation! The attention to detail is excellent, it makes me want to dive into Avalonia again.
Author of the demo and library here, thank you for kind words, this was my goal to achieve almost pixel perfect recreation of the original GUI (which is sometimes not very easy as some components look slightly different in different programs, I meant small differences in buttons sizes, paddings, etc.).
A piece of feedback: The maximized MDI windows did not keep their border, AFAIK.
I miss those times. Every IDE had a line by line debugger. Now those Angular/React applications, even after years, do not have one; and they still have a confusing syntax.
I hadn't thought about it like this, but you're right. React has decent browser plug-in tools, but it is still painful to get things back to the IDE.
My experience with IntelliJ + a bunch of JS frameworks is that IDE-based browser debugging works quite well. Unfortunately, Firefox' remote debugging capabilities broke for me at some point, but adding a Chromium debug target in my IDE seems to work most of the time. As long as the Rube Goldberg machine that does JS transpilation includes a source map, frameworks just seem to work out of the box (as does raw JS, but that's not so common anymore).
That even includes debugging some languages compiled to WASM, like C#, interestingly enough.
What is written and what is actually running is so different that it’s better to think of SPAs as a different language. Firefox have a decent debugger for javascript which works well when the build tool output sourcemaps.
Nice! Small bug report:
I added a button and double clicked it to open the code window. I added something simple like
MsgBox "Hello"
The code was not saved. You have to "Save" the project or "Run" the project for the code to be updated. This is a difference with the old VB IDE that remembers everything you type.
This works with a button control, but it seems a label control does not want to fire the Click event no matter what I try.
I didn't add a handler for the click event for labels, fixed now :))
IIRC labels don't have the clic event.
I remember in the 90s a lot of small companies ran on VB and Access. It really enabled a lot of non programmers. Wish we had something similar for the web. Some low code solutions are superficially similar but what made VB different was that you could grow into full blown apps without changing. I am always amazed how complex today's web CRUD apps are to develop and deploy.
The web is a really terrible platform for apps. It's so popular for two reasons:
(1) No installation, and no need to deal with OS packaging because all our OSes are horrible.
(2) SaaS is DRM -- host software in the cloud and it can't be pirated and you can easily charge monthly rent.
A third I guess is that it makes collaborative features easier to build, but that only applies to some software.
(3) you can’t run a Windows app on your phone.
(4) The world isn’t Windows only anymore.
PowerApps. Built into Office365.
is 2024 and I still maintain a VB6 project. A client of mine (a aluminiun metalurgic compoany from sweeden) have all his machines controled but a central program in vb6. Since the machines are all old, they have integrations using windows COM+ protocol.
Its a offline application, that connects to SAP exchanging text files, so they have no reason to update so something more modern.
Not being able to replace hardware easily seems like a disaster in waiting.
They use an old offline machine with winxp to run stuff in factory. But they are replacing for virtualmachines now that the old hardware is dying. other than that, it runs really well. Sometimes, months without rebooting.
Running old versions of Windows in emulation or virtualization is really easy.
Oh, interesting. I should see if I can get my 22 year old coursework running in it.
Assuming I can get my source out of the Word document, because it predates git and I don't have the original source files: https://github.com/BenWheatley/A2-coursework
If you can't open it in a modern Office install, Microsoft used to have the option to download input filters for old and unusual formats.
It seems like you can write VBA to extract stuff from Microsoft Office files. It might be worth a try. Here is what I found: https://stackoverflow.com/questions/49724/programmatically-e...
The code in this case is plain text within the word doc — the hard part is that I don't have a copy of Word from 2002-ish (I don't know the specific Office version my teachers used), and it's spread over 261 pages because I was having too much fun writing it.
ChatGPT can probably do it, but my experience is that it starts hallucinating well before you'd expect from the context length.
This is amazing... I am much away from .NET world so can someone elaborate how does it get from C# to browser?
All I see is this main.js[0] and everything is drawn on a canvas! (probably explains why text is not as sharp as I remember back in the day)
There's a bootstrap loader at https://bandysc.github.io/AvaloniaVisualBasic6/_framework/do... which downloads the application, which has been compiled to WASM, and the dotnet runtime. Which is why it takes so many seconds to first page view.
The Avalonia framework is a third party UI toolkit.
> Which is why it takes so many seconds to first page view
I'm seeing a long load time in Firefox but in Chromium, loading takes maybe a second. Loading the entire .NET runtime isn't exactly lightweight, but it seems there's also some kind of browser engine problem in my Firefox setup that slows this page down artificially.
I must say I'm impressed that this approach even works with only 16MiB of data transferred over the line (though that 16MiB decompresses to about 50MiB).
They seem to be using this framework: https://github.com/AvaloniaUI/Avalonia
Avalonia aims at compatibility with Windows Presentation Framework (WPF) XAML. The web platform is explicitly supported: https://avaloniaui.net/platforms#wasm. The VB Form model must be implemented on top of this. This is for the UI part.
Now for the code part, the dotnet toolchain has supported WebAssembly (wasm) generation for some time: https://devblogs.microsoft.com/dotnet/extending-web-assembly... I suppose the C# code is translated to MSIL then wasm.
> text is not as sharp as I remember
Something interesting is that the top bar text (File, Edit, etc.) is a little bit blurry, but when I click on one of them (e.g. File), the drop down text (e.g. New Project) is completely crisp with no antialiasing.
Lol, that's amazing, as soon as it loaded up i was laughing at how accurate it was . So many memories from simpler times coding as a kid.
OMG, this is how I started programming. I was so happy creating small helpers with this toolchain, e.g. something like Spotlight to launch programs with with a hotkey + the name of the program, on Windows 98.
One nice side effect of having GUI builders in the IDE was standarized, optimized and "follow best practices" GUIs. No wonder we reached peak UI in the 90's-2000.
Then came the web and everyone and their mom had an opinion on how a button should look (for games that's fine) and we ended up here.
Immediately after seeing the page, got "oh, those were the times" feeling. Really great.
I miss VB 6, because it was so easy to teach people how programming works as the visual nature was very intuitive.
I have felt for a long time a modern version would be so useful.
You can do the exact same thing, with a nearly 100% exact user interface in the latest version of Visual Studio 2022 that came out yesterday.
I've been building desktop apps like this for 30 years. I still build them every day and the designer looks no different today.
I did not know that, thank you.
I guess the windows pc I have won’t be exclusively for gaming anymore!
What I really want is a form designer that would let me create a UI for any language instead of every language reinventing it.
Ahhh... first programming language I ever played with was VB3 and VB4 writing 'proggies' to knock other AOL users offline. Good times!
I miss RAD tools. I never played with Visual Basic but I enjoyed Borland C++ builder.
Oh the memories. How does this work? Is it built using an emulator of old VB6 code ? (didn't realize it was opensource) . Or is everything built from scratch?
Hey, author here, I built everything from scratch. It supports only a subset of VB6 so it wasn't difficult or long. I wrote an interpreter for VB6 code
I sometimes wonder if something like this using Lua wouldn’t be a great way to quickly build native desktop apps.
As someone building a JS type low code tool (yazz.com) which is also open source I am very impressed. Well done!
I actually think QT is not too bad for small applications too. I wrote a Quake launcher over a few days because I was so tired of finding my Quake executable and setting the same configurations every time I load a mod. I knew zero about QT back then so someone could write it in an afternoon. I think it definitely can be used equally easy for something bigger, e.g. a frontend of a lc-3 VM.
I can't get it to actually do anything, is it supposed to work to run programs in the browser? (mac, chrome)
It does! Drag some controls onto the form and hit the play button.
Event handlers don't seem to run (I couldn't get the simplest MsgBox to work, at least). Is the actual language implemented?
Hey, author here, only a subset of VB6 language is implemented, I also didn't implement all properties and events, i.e. the Click event on labels. Updated the website with all basic events.
Considering how much response this project got, I might improve the VB6 interpreter :)
Same issue here, I add UI elements just fine, double click and generate the event handlers, but nothing runs.
Hey, author here, I didn't implement all the properties and events, i.e. the Click event on labels was missing. Updated the website with all the basic events.
It works :-)
Amazing, such a fun project. Very well done.
They're working for me
Drag a button, double click, MsgBox "hello" in the event handler, hit play
turns out I had a typo and it doesn't report errors as far as I can tell
Syntax Errors reporting was missing indeed, but I just added it now and it would show a message box (while you write the code)
Maybe you need to explicitly capture the errors to view the error number and/or message in a message box or something? I have no idea, just guessing based on some prior VBA work I did.
The real VB6 IDE would report errors like this at compile time.
There's no compilation (yet?) -- the code is interpreted, so runtime only.
My first bit of paid programming work was a VB6 project in 2001. Such happy times!
I want a desktop version of this that runs on Mac and Linux.
It runs on Mac and Linux! https://github.com/BAndysc/AvaloniaVisualBasic6 It even supports dotnet's NativeAOT, meaning you can get a native x64/arm64 binary!
I owe my whole fascination with programming from childhood to Visual Basic 6.
I was 11 and I could hardly read English, yet VB6 with the WYSIWYG-editor and an introductory book by my side was intuitive and rewarding enough for me to learn the basics of programming.
My college thesis was writing complete inventory management using VB6, then making sure the program works inside the company. Good times!
This is the kind of content I am here for
This reminds me of Bindows framework. Seeing Windows interface in browser is hard to forget.
Site doesn't load for me other than the powdered by avalonia message, on Safari.
It takes a while to load on a slow connection, but then it works fine on my iPhone (IOS 18).
This is an incredibly impressive demo of what Avalonia is capable of.
After going to Help > Avalonia on the Web, the UI stopped responding
This is amazing. I love the nostalgia, it made my day.
Haha, it hit me with a tinge of pain that I probably saw the screen (the original one) a lot, thinking "Today is the day I learn VB6!", but I never got proficient with VB6.
Oh well, I still managed to have a career in IT, so...
Visual FoxPro as well, please :)
Wow, really nice !!
And very interesting project too...
Thanks !
This is at most something lat "looks like" Visual Basic 6. Most of the actual functionality is not there.
- ActiveX and custom controls? Not available
- Debugging/Single-Stepping? Nope
- Add-Ins? negative
- Also, many of the menu items just don't do anything when clicked on, or they open a dialog where everything is greyed-out
I mean, yeah, it's cute for someone who has never seen how VB6 looked like... But calling it "rebuilt in c#" is stretching it a bit...
You must be fun at parties
I feel like the complexity around current day .Net is more due to Microsoft’s pathetic attempt at naming and branding and the confusion around their development products. One example is their desktop development frameworks. As someone that is in and out of Microsoft centric development stacks - I can't even keep up with it anymore.
So cooool!
Wow.
I started in Visual Basic 3 and then moved to Delphi. My first job at 18 was working for one of the large ActiveX component libraries, providing technical support to many developers when I wasn't one myself yet!
On my first day, I found a book on my desk—"Learn Visual Basic 3 in 21 Days"—along with a brand new 486DX250 and a 14" monitor. I learned a lot quickly! We answered support queries by fax back then.
I never fully understood why this programming paradigm died off. Building business apps beyond Access or Excel was so straightforward. It was great to get an .EXE that you could package up with InstallShield or Wise Solutions and send to anyone.
I guess the web came soon after, and trying to do WYSIWYG for HTML and CSS has never gone well—even today.
FrontPage came out but died soon after, and mixing desktop apps with web apps was never great.
Today, I feel .NET is overly complex and much harder for beginners compared to the old days.
Sometimes, I think there are only so many ways to control the appearance of business apps. I'd constrain visuals but provide the most straightforward visual builder possible.
The No-Code world is fascinating, and the best I've seen in this space is https://retool.com/, but it's expensive and locks you into their ecosystem.
Even today, small businesses need to build out simple apps that were simple to do back in the Visual Basic days—a stock control system, a basic support system, sales tools, etc. Today, it's a minefield of options that can quickly get expensive.
I'd love to have a visual builder that creates code you can host yourself — something like retool.com but with open source and self-hosting, or maybe I'm just too old for this now! :)
> I never fully understood why this programming paradigm died off
My two cents --
A few reasons (briefly, I could have talked a lot more)
* Shift in platform: Windows is no longer the sole platform people want to build their apps for. Not a bad strategy by itself, and lots of companies still only develop for Windows (e.g. specialized software for instrument control etc), but people increasingly want their stuff to work on iPad, Chromebook etc and maybe even phones
* Shift in screen size: It used to be that everyone runs Windows on a 800x600 screen. That changed, and then changed quickly. Many different resolutions and screen sizes. The drag and drop thing just doesn't work well for that. The web model, where you write "responsive CSS" and the browser handles the rest for you, works better.
* Software and their UI got a lot more complex and require more expertise. On the other hand commercial software becomes easily available and accessible for those purposes. For the examples you mentioned -- stock control system, sales tool, they may be fine with VB6 for a prototype but can quickly get complex. And there is likely a commercial software you can buy and download within a few minutes at an affordable price.
* Shift to online/cloud: vast majority of "small VB6 applications" were used locally, and they never connect to the Internet. That's different now.
* Shift in language: BASIC/VB was often used for teaching, and it is indeed great as a first language to learn. Although Python already existed at that time, it became very popular, and I think many people would agree Python is a much better language than BASIC, in many ways. As a result, BASIC along with VB went out of fashion.
I've always found the use of anchors on UI controls to be light years ahead of what HTML/CSS have been doing. I always used to create UI forms with resizing and different screen sizes in mind. If you were coding for a hard coded 800x600 screen then that was just laziness.
I think you left off the biggest reasons, commercial:
* No piracy. Can't crack code you aren't running.
* Immediate installs/updates. No need to tell people to ever update stuff, or to install your program in the first place.
* You can charge subscriptions. It's much easier to justify a subscription when you pay for server costs, even though the customer would be happier just running your application locally.
* Easier deployment. You can handle complex integrations on the server, without the customer having to open ports or whatever.
Good points. I was more focused on the technical side.
I want to add a bit more to "easier deployment" -- traditional model is that you push updates at some interval (regular interval like semi annually/annually or non regular intervals), and you need to manage multiple versions and potentially patch multiple versions for severe bugs or security issues. Lots of software still works that way. But with office 365, jira etc you only have one version to worry about. Of course it means different risk levels, SLAs etc, but that's a different topic.
It's a bit ironic how in the same breath you go from "it's impossible to build apps for multiple resolutions with drag'n'drop hence web" to "software and their UI has become more complex".
While the absolute vast majority of web-based software cannot hold a candle to UIs you could trivially build in VB (or Delphi and other RADs). Most web-based software is either trivial forms or a few screens of text and images they struggle to display with any acceptable performance.
As for "many different resolutions and screens", have you ever, I don't know, resized a desktop window? Desktop apps work at the number of crazy sizes the web would die at.
> Shift in screen size: It used to be that everyone runs Windows on a 800x600 screen. That changed, and then changed quickly. Many different resolutions and screen sizes. The drag and drop thing just doesn't work well for that. The web model, where you write "responsive CSS" and the browser handles the rest for you, works better.
This... really doesn't match my experience at all. I may be thinking of later UI development tools from the .NET era (I no longer recall if VB6 had proper support for linear layouts and the like, that was forever ago) but GUI builders with responsive controls were absolutely a thing, and they ran circles around any "responsive" CSS we have today, if only because they had instant feedback. I don't miss most aspects of programming from that age, but this is one that I do miss tremendously.
Edit: I certainly agree on the other points. I think this one was less of a technical limitation and more due to the humans in the loop; lots of people just didn't know better, information dissemination was far more limited (lots of us learned these things offline, from books and the like), and the platform didn't force you to do the right thing, either.
> Software and their UI got a lot more complex and require more expertise.
In the B2C space sometimes sure. We do business with many companies all over the world and if you can see the 100s of 1000s of apps they are using; you could've done all of them with Delphi/VB without any tricks. Except now some incapable but suave talking Nextjs fanboi walked in and pushed all that overly complex nonsense while it's not needed for almost anything we see used in companies. Spending fortunes on stuff you should just click together in a few minutes and hook up a db. But yeah, we make nice money because of it for both of my main businesses; 1) fixing completely broken stuff because the person who introduced the tech left quickly after introducing the misery 2) creating LoB/ERP custom applications. Both are goldmines and both are goldmines because of the tech losers (resume driven 'workers' almost always) around the world who preach to always use the 'best tool for the job' and then completely do the opposite, introducing tools that really have no place there, ever.
And then the joke of course that they are not even really good at them, which is the worst pet peeve of mine; ONLY yesterday, I was virtually (via Teamviewer) fixing a new LoB app made by 2 freelancers who came (apparently) highly recommended; it was made in Next 15 with React 18 and shadcn (that's not fully compatible yet... but that's normal in that ecosystem; nothing is). So I checked the Linkedin / github's of these freelancers and had a short call with them if they could help (no, they had no time; new clients!); they were Django/Bootstrap guys before, but that sells less well than Nextjs/shadcn/tailwind, so they switched recently. What a joke. Why is this not liable really... But again, we make very good money, so please carry on!
I'd add another reason:
* Idiot developers like myself. Okay, I was a teenager back when I got infected by this idea, but it did persist for some time into my start of my career too - the idea that RAD tools are inferior, they are not "true programming", just some lazy no-code clicking to save monkeys from understanding the program they're building as a whole, etc.
I mean, sure, you could do a lot in RAD tools really quickly, and do it well - but that was cheating. Too good results for too small an effort. It wouldn't impress any of your IRC friends.
(Curiously, those few I know from my "generation" who wrote software for e.g. their parents' business, would happily use VBA or Delphi. Wonder why...)
This was all adjacent to and connected to other ideas that became influential with our cohort of developers, like "Windows suxx, Linux rulez", "plaintext is best", "CLI is best", "code generation is evil", etc. Those ideas are still deeply rooted in FLOSS, too.
VBA - was not C-like, you couldn't exactly put the whole project in SVN and diff nicely, it's tied to a specific platform (that sucked), a specific vendor (at a time when we all hated the evil M$ because it was the Right Thing to Do), and to a specific software suite (which was not vim). It's tricky for a technology to survive after a significant part of the fresh workforce tried to steer clear of it as a matter of principle.
https://www.flutterflow.io/ is an interesting option for cross-platform web-based low-code.
My main issue with these is using the the cloud dev tools has a cost, normally usage-based - so if you use Firebase, if you're not careful, you can end up with a large bill.
Funny thing is that there are more Windows devices out there than all iOS,MacOS, and chromebooks combined.
There are 1.46 billion iphones, 3.3 billion Android phones and tablets, 1.5 billion Windows computers in the world. About 100 million people use MacOS.
I'd say with the (few 100 million) Chromebooks it's an equal number of Windows devices to the sum of the other ones you listed.
P.S. What happened to Android in your list? That is like leaving out the 500 pound gorilla :)
are you certain? At least mobile phones (android+ios+maybe some other with somewhat modern web browser) outnumber desktops/laptops.
I don't think the platform mattered much, this happened before macOS became popular, and remember that at that time mac developers would still use Interface Builder and Objective-C. There was a certain level of pride in making Mac apps look very much like Mac apps. Very rarely did developers target both Windows and Mac.
My take is: A lot of developers didn't feel like cluing components together in Visual Basic 6 or later Visual Studio, dragging and dropping UI elements, was "real development". VB-developers where looked down on as second rate programmers. If you used VB.NET and WinForms/WebForms who where not a real developer. You had to use C# and XAML, which was absolutely terrible, but "real programming".
Same with Delphi, not something you built "real" applications in, no you use Java if you're a real developer.
Shit like that was all to common, and yet WinForms are still around and working, but XAML is dead (Edit: Apparently it's not dead).
Yes and:
> Shift to online/cloud ... they never connect to the Internet.
The fall of VB6 style RAD (for CRUD) started earlier with shift from "workgroups" (shared files on LANs) to client/server. This severed the direct link (ADO api) between apps and their persistence.
Tragically, the ODBC (then JDBC) API interface didn't quite fully bridge the gap. Meaning some necessary metadata was no longer front and center (for both compile and runtime, like ADO had always had). Yielding mitigation attempts like DAO/DTO, ActiveRecord, ORMs, LINQ, templates, etc.
That sad state of affairs is described in Ted Neward's famous "ORMs are the Vietnam of computer science" essay. https://web.archive.org/web/20060813030731/http://blogs.tedn...
Of course, client/server had to happen. But the innovators (and critics like Neward) didn't fully understood what they were replacing, what parts were missing. (Lather, rinse, repeat.)
--
It took noob me a LONG time to figure this out. (All I ever wanted was to recover the special magick of VBA + ADO.) And then even longer to attempt mitigation (cuz am noob).
Maybe if we had the new "internet's hourglass shape" analytical framework from the beginning (vs say OSI's layer model), someone(s) could have prevented the oversight. https://cacm.acm.org/research/on-the-hourglass-model/
>The No-Code world is fascinating, and the best I've seen in this space is https://retool.com/, but it's expensive and locks you into their ecosystem.
>Even today, small businesses need to build out simple apps that were simple to do back in the Visual Basic days—a stock control system, a basic support system, sales tools, etc. Today, it's a minefield of options that can quickly get expensive.
A RAD tool like Visual Basic, Borland C++ Builder, Borland Delhi, QT Designer doesn't mean no code. Rapid application design helps the developer quickly build the UI using already made components and using some predefined behaviors like gluing a database table to an UI component. But the developer has still to provide the application logic and to write whatever else is not covered by the RAD tool. It helps you build faster, write less code, but it isn't no code.
VB6 fans looking for a modern approach should try twinBasic which after many years is about to release v1.0 https://twinbasic.com/
Never seen this before - thanks. Looks interesting.
Delphi is still around and filling a niche for boring business apps where usability, accessibility and quick UI development is more important than following design trends. You won't get any VC money for Windows XP styled apps, but if you make industrial hardware and need control and maintenance software Delphi is a reasonable and somewhat popular choice.
They even cleaned up their licensing a bit, offering a free version for hobby use: https://www.embarcadero.com/products/delphi/starter
> I never fully understood why this programming paradigm died off.
First and foremost -- the world wide web.
Suddenly, we had a much more flexible way to deliver applications.
If I remember it correctly, Visual Basic couldn't write to STDOUT -- so it couldn't be used as a scripting language for the web.
Microsoft tried to push VBScript as an alternative, but it was linked to their expensive ecosystem, while LAMP (Linux Apache, MySQL Perl and PHP) was free.
> I'd love to have a visual builder that creates code you can host yourself — something like retool.com but with open source and self-hosting
I believe this is the promise of AppSmith: https://www.appsmith.com/
I haven't tried it myself, curious for others' experiences
Developing visually with VB(A) RAD-like dev tools to build websites without wallgardening and cleanly generated html, css, js, server side code & whatever, is a huge niche to be filled. Incredible that it doesn't exist yet. Maybe I'll do it myself.
We've been using ToolJet (the open source version) at my company with good results. It is self hosted, open source and you can export created apps in some JSON format.
I've successfully setup a dev-stage-prod flow where we export from one env and import into another pretty seamlessly.
The coolest thing about that is that I was able to hire a very Jr. Frontend dev to immediately start working building internal dashboards.
I've used retool in another company but found problematic not having the source code for the lack of control.
>Today, I feel .NET is overly complex and much harder for beginners compared to the old days.
I often see similar statements like that but that's not what I experienced. I did IBM DOS BASIC, MS GWBASIC and worked on VB3 to VB6 at a corporate jobs.
The C#/NET workflow feels much the same rapid-development simplicity as classic VB6: Drag some GUI components like text boxes and buttons onto a form, code the controls' event handlers, build the exe.
In contrast, the examples of GUI dev kits that had more complex language syntax and build steps than VB6 were original Apple iOS Objective-C, C++ Qt, Java AWT.
Sure, C# is a bigger language than Visual Basic in VB6 but C# also does a lot more. E.g. in VB6, it didn't even have a built-in way to check the existence of a file. Instead, you had to declare a "win32" API monstrosity such as :
VB6:
Private Declare Function OpenFile Lib "kernel32" ByVal lpFileName As String, lpReOpenBuff As OFSTRUCT, ByVal wStyle As Long) As Long
Function FileExists(FileName As String) As Integer
Dim RetCode As Integer
Dim OpenFileStructure As OFSTRUCT
Const OF_EXIST = &H4000
Const FILE_NOT_FOUND = 2
RetCode = OpenFile(FileName$, OpenFileStructure, OF_EXIST)
FileExists = (not OpenFileStructure.nErrCode = FILE_NOT_FOUND)
C#:
File.Exists()
EDIT reply to: >most definitely open files in VB, and therefore the "File.Exists()" function would at worse be comprised of a exception handler (on error ...) and a open call,
From my memory the "pure" VB6 way checking existence of a file by opening a file with error handler had issues (other processes using exclusive access and/or other issues) causing false-negatives or false-positives. Therefore, the recommended way back in 1990s was the win32 api declaration using OF_EXIST flag. It looks convoluted but it was more reliable.
You chose a very poor example, since you can most definitely open files in VB, and therefore the "File.Exists()" function would at worse be comprised of a exception handler (on error ...) and a open call, as in many other languages. No need to import OpenFile for sure.
I believe some people used that monster version because VB had simple libraries that didn't allow many options. Anything more complex required you to go down the Win32 rabbit hole. And that was the main weakness of VB, it was such a simple language that you didn't have many options to do something more complex than going straight to Win32.
It is a very different thing to claim "the language doesn't allow simple things such as checking for a file's existence" (which is false, the language allows many ways to do so) than to claim "the language doesn't have many options, but allows you to interop with the entire win32 API if you need to". The first is a valid if only false complain; the second reads to me not as a complain, but as a feature.
>to claim "the language doesn't allow simple things such as checking for a file's existence" (which is false,
That's not what I wrote. I said there's no _built-in_ way to check existence of the file. A reasonable interpretation of "built-in" is for an obvious named function such as "File.exists()" _without_ cobbling together extra workarounds and hacks -- whether those workarounds include re-purposing other VB built-in functions with On Error ... or using Win32 interop.
> in VB, [...] would at worse be comprised of a exception handler (on error ...)
That's an example of what I meant of not being built-in to VB. I should have been more clear. We were using different meanings of "builtin".
In any case, the following "pure" VB code to check for file existence is not found on Google or Bing search but I still have it from my 1995 archives and copied it here. It has many lines of code (instead of a simple "one-liner") because it tries to cover all the edge cases. And yet with all that defensive code, there's still a hidden timebomb of a bug in it. Can anyone spot it? The code is unmodified from Visual Basic Programmer's Journal. In contrast, the alternative using Win32 interop with OF_EXISTS doesn't have the bug.
Dim strTestFilename As String
strFilename = Trim(strFilename)
' To avoid problem with known bug, don't pass root directory to
' the Name function
Select Case Right$(strFilename, 1)
Case "\": strExistsFilename = "Root": Exit Function
Case "\.": strExistsFilename = "Root": Exit Function
Case "\..": strExistsFilename = "Root": Exit Function
End Select
On Local Error Resume Next ' Enable error trapping for Name function
Name strFilename As strFilename ' A trick to see if filename/path is good
' Now check the resulting err code of the Name function
Select Case Err
Case 5 ' Illegal function call
Case 53 ' File not found
Case 58 ' File exists (maybe)
strTestFilename = Dir$(strFilename)
If Len(strTestFilename) Then
strExistsFilename = "" ' It's a file
Exit Function
Else
strExistsFilename = "Dir" ' It's a directory
Exit Function
End If
Case 64 ' Bad filename
Case 68 ' Device unavailable
Case 71 ' Disk not ready
Case 75 ' Access denied
Case 76 ' Path not found
End Select
So, what is so wrong about simply calling FileLen() to check if the file exists, or if you also want to distinguish between Files/Directories using GetAttr to check the directory bit ? Why do you have to go all the way to this monster of code which even hardcodes lists of errors (why do you care which error it is?) ?
Your code sample renames the file, then globs anyway (when dir$ by itself can also be used to check existence). It looks too convoluted, and I cannot imagine why it needs to be so.
What is exactly the corner case that you want to avoid -- and if such case really exists, why are you so sure the File.Exists() implementation would not fall into the same pit trap, considering it also simply uses the metadata?
Disclaimer: I'm only familiar with VBA, not VB itself. But these file metadata functions definitely already exist in 95's VB5. (EDIT: Actually 97's. Maybe the problem is these functions did not exist in earlier VBs? But I would find it hard to imagine you could not check a file's size).
The sample code smells even in the trivial-case checks. E.g. Right$(_, 1) will only return a 1-char string at most, yet it tries to compare it with 2, 3 len strings. I didn't check any further than that.
To elaborate.. just what is wrong with simply doing the following?
Function FileExists(Filename) As Boolean
On Error Resume Next
FileExists = (GetAttr(Filename) And vbDirectory) = 0
End Function
Another way, use Dir by itself. This is even mentioned in the VB docs...
FileExists = Dir(Filename) <> ""
I still stand by my original point that this is a very poor example, since there are a million ways check for a file's existence, many using only builtin functions of the language. You can certainly find nigh-overcomplicated ways to do so, apparently even on books, but ... why? Not a fan of cargo-culting like this; it tends to create Cherteston's fences.
Many languages also lack a direct "File_Exists" function (e.g. Lua comes to mind) since it's about the most trivial thing to implement (and a magnet for TOCTOU issues). Or even if they do come with such function, it does not distinguish directories from files (e.g. Tcl). I hardly think the lack of a "file_exists" function discriminates anything in language design, modern or otherwise.
> does not distinguish directories from files (e.g. Tcl)
Tcl has the built-in functions [file exists], [file isdirectory] and [file isfile] to serve your existence-checking needs.
I know. So does VB. This is precisely my point.
GP complains that there is no direct function for "file exist". And technically there is not on Tcl either because file exists cmd will return true for directories. You can trivially build your proc that specifically checks for files (it will likely use isfile) but that is exactly the point of my comment. I have shown how do that for VB and it is not far from a one liner.
Presence/absence of a file exists function is a very poor example. If the language didn't allow you to check e.g. if a file was a directory or not, then GP might had have a point. But this is not the case.
But then you may have actually opened the file.
But if you rely on these subtleties this is hardly a "basic feature" that the language is lacking. In fact, I imagine File.Exists()/OF_EXISTS also opens the file (then immediately closes it).
It better not!
If you actually open a file, you update it's access time, and you interfere with the process that should actually open the file. Those both break perfectly simple business logic.
The documentation for OF_EXISTS literally says it will open then close it. I leave to your imagination whether this updates the (very poorly defined) access time or not, but for sure you "interfere" with other processes...
If you want to get the access time, why don't you just query the access time? Which is likely the only thing almost universally guaranteed not to change it... And I'm sure VB6 has an API for that, considering that VBA had a global API for it (FileDateTime).
(Which is, btw, yet another way to one-line check if a file exists).
Did you confuse the file with it's containing directory?
The way you probably did in your now-deleted comment claiming that stat() updated atime?
Citation needed. https://learn.microsoft.com/en-us/dotnet/api/system.io.file.... doesn't warn of any such thing.
> Did you confuse the file with it's containing directory?
No.
> Citation needed. https://learn.microsoft.com/en-us/dotnet/api/system.io.file.... doesn't warn of any such thing.
https://learn.microsoft.com/en-us/windows/win32/api/winbase/...
OF_EXIST: Opens a file and then closes it.
It's literally open file ! Are you dense?
OpenFile() opens the file??? c'est incroyable!
OF_EXISTS is just a side effect of some actual operation. It's some related info you you get along the way. You would not use that as the way to only check the file. Holy cow. Please do continue trying to spread the wisom.
You are the one claiming that OpenFile(OF_EXIST) does not open the file. Scroll a bit above. My initial comment was:
> In fact, I imagine File.Exists()/OF_EXISTS also opens the file (then immediately closes it).
"You are the one claiming that OpenFile(OF_EXIST) does not open the file."
I never said any such thing.
Yet another trivially verified false statement. Fits the pattern.
Hey, I am also a fan of the argument clinic sketch from Monty Python. Let me try to jump in:
If you didn't say any such thing, then why did you bother countering my comment at https://news.ycombinator.com/item?id=42107195 ? Aha! Gotcha!
What gotcha?
I never said, either explicitly nor implicitly, that File.Exists() modifies access time.
There is nothing there in that comment nor it's parent.
OF_EXISTS is not a thing by itself. It does not "open a file and then close it" which is a ridiculous and incorrect thing you DID actually say. OF_EXISTS is just a bitmask flag that can be returned by several functions, including ones that open files.
You have said a continuos string of incorrect things and employed invalid logic this whole time, and this yet again fits.
correction: you said opens a file and closes it about OF_EXIST the bitmask flag to tell OpenFile() how you want to open it. Slightly less ridiculous, yet still not a thing that opens a file, OpenFile() opens the file.
But then the only way to make sure that you can open a file is to actually open it.
You don't use exists and then open a file. If you actually want to open a file, you open it or fail. You don't check if it's ok and then do it, you do it and then check if it failed.
exists followed by open is a pointless exists because anything can happen in between.
Conversely, if you are neither the producer nor consumer of the file at this time, you don't want to actually open it just as a way to stat it, because actually opening it updates it's access time and interferes with the actual consumer(s). Even read-only non-exclusive.
You can use it as an improvised lock.
How do you impliment this lock? You use an atomic operation. Which atomic operation? You try to open the file in exclusive mode.
Create the file to lock and delete to unlock. I'm not sure if there are corner cases.
Public Function Fso() As Object
Static s_oFso As Object
If s_oFso Is Nothing Then
Set s_oFso = CreateObject("Scripting.FileSystemObject")
End If
Set Fso = s_oFso
End Function
Fso.FileExists("path")>CreateObject("Scripting.FileSystemObject")
That's not included by default in Windows 95. (A lot of classic VB6 apps of that era ran on Win95.) In contrast, "kernel32.dll" is always included.
Even for the later Windows 98, using "Scripting.FileSystemObject" as a dependency was fragile and could fail:
https://www.tek-tips.com/threads/forms-do-not-open-in-window...
https://www.vbforums.com/showthread.php?135362-running-vbs-f...
The sub thread this created of people not recognizing this as a problem is pretty interesting.
It's probably one of many ingredients that went into how so many of these apps are so half baked and buggy.
Not just the obvious that the language was aimed at and used by junior programmers and so of course much of the code is not robust in general.
But here is an example of the toolbox missing a tool. You can't really fault people for doing whatever seems natural using the tools they are given.
Not being experienced developers otherwise, they didn't know that something necessessary was missing, and made things that only mostly worked without it.
To be clear they would have often mis-used the tool if it existed too. In this thread people have thought the way you would use exists is to check before doing some actual operation. The inexperienced coder aspect is also true, seperately.
But the combination of a missing tool combined with a language explicitly aimed at users who don't come with their own experience and don't know anything but what the language provides, seems a little extra nasty.
Are you literally calling every commenter of this subthread an inexperienced developer? Seriously?
First, the subthread starts by claiming you cannot check for the existence of a file, which is simply false. You can try to open it, you can try to read metadata from it, you can glob it, etc. all of it using language builtins.
But then you claim that you need to check for a file's existence without actually opening it. If anything, as we people are constantly pointing to you, any code which does it is a code smell at the very least, and very likely wrong. There's a reason TOCTOU is a thing, and why these exist/access APIs usually have huge disclaimers right in the documentation.
But let's entertain the idea. Maybe you really have a crappy IPC handshaking mechanism implemented with temporary files (sorry!). Maybe you want to avoid side-effects of trying to open file (virus scan overhead? network traffic?) . It cannot be that you want to preserve the atime, because that would also be a code smell, seing how undefined the atime is on win32. On win9x, for example, reading metadata updates atime - likely the AV scan, but nonetheless; also, the granularity is only 1 day (welcome to FAT).
The WA offered by GP actually very likely opens the file anyway, so clearly he didn't have this requirement. But anyway, this scenario is no longer a "simple" feature whatsoever, and therefore the original complain loses all weight.
And to top it all, you _still_ can check the existence of a file w/o opening it by just trying to read the metadata, using any of the myriad functions at your disposal, in around two lines of code; no need to interop with Win32 at all. In fact, (trying to) get the file's metadata is exactly how .NET's File.Exist does it.
If you find yourself in a situation where everyone thinks you are trying to do a senseless thing, it is more likely you are, rather than everyone else being junior and inexperienced.
I am calling inexperienced developers inexperienced. Are you literally suggesting that there are no inexperienced developers?
I am also saying that this thread is interesting and that inexperienced developers don't see the problem.
"very likely opens the file anyway" is not an argument.
"code smell" and "very likely wrong" are not arguments.
The reasons you need to stat a file without opening it, or do any other low level operation, are open ended and infinite. It's backwards to try to think up some specific invalid contrived example use case, and then say how you didn't need to do that specific thing that specific way, and so therefor you never needed that facility.
These are all quite bad reasoning and "inexperienced developer smell". If you are experienced and still reasoning like this, that's unfortunate.
I know this is a bit of a first-world problem but back in those days[tm] you just slapped 2-3 DLLs into the exe directory and it worked. Yes, I know there were also different versions for different runtimes, but overall it was a couple of DLLs and fine. Since .net you really need to install the distributable by MS, and every new .net upgrade it's the same. Just 2 days ago I apparently needed the .net 8 runtime and even after installing it the app in question didn't work (without a reboot maybe, I will find out later today).
Overall, strictly as a consumer, C# and .net apps have been mostly great, except the practice (is it a best practice?) that some of them end up somewhere in my home dir's Local dir and not in c:\program files.
This is the worst example you could give. Just add filesystem dll or whatnot from the .net framework as a reference to your project and you can use File.exists from VB.
>Just add filesystem dll or whatnot from the .net framework as a reference to your project
To clarify, "Visual Basic 6" in this thread's title that everybody in this discussion has abbreviated to "VB6" is the "classic VB" from 1998.
There was no publicly released .NET in 1998. That came 4 years later in 2002. Maybe you're thinking of the newer VB.NET.
yes, I misread thanks
PowerBuilder too. I worked for an S&P 500 corporation from 2000 to 2006 trying to replace several business critical PowerBuilder apps in Java using a bloated commercial framework called Windchill. The original apps were written by a handful of developers over the years. The new team was fifty developers that struggled to replicate the old app functionality. We did manage to reimplement a couple of the old apps but they took a lot longer than anticipated and were incredibly slow.
The corporation chose Java/Windchill for the rewrite instead of PowerBuilder because Java was trendy. Both the original and replacement apps were desktop applications. During development of the new apps, browser based applications became trendy and some of the developers really wanted to switch to browser-based. Fortunately, that shipped had sailed. Can you imagine writing business critical apps for the browser in 2002?!
Because for the most part, you don’t need desktop applications in 2024. They are harder to maintain when used across multiple computers and you can’t access them from anywhere like web apps.
And most companies that need to build the things you mentioned can use a SaaS.
Also, those “simple apps” end up being an unmaintainable mess after a couple of years. In 2024, to a first approximation, no company should be writing software that is not core to their business.
Most problems are not special snowflakes. Someone has already solved their problem and created a customizable SaaS around it.
Yes I’m old enough to have used VB6 professionally from 2001-2008 (when it was way past its prime). But my first programming was on an Apple //e in BASIC and assembly and programming professionally in C and C++ from 1996-2008
In some context, I think desktop apps are far better than the web, and it's now super simple to roll out desktop apps using tools like Intune.
However, I'm talking about general business apps here.
The likes of Zoho, Salesforce, and, to some extent, Dynamics are covering some of this space—but again, they're expensive.
The main point of my post was that if I were 18 today and starting my first job, it'd be much harder to acquire the skills needed to grow. With VB or Delphi and a book, you could become pretty productive within a year or so, and the cost of entry was very low. The skills you learned opened the door to a whole new world for little cost. Especially, as others have mentioned, finding "DVDs lying around" :) which, of course, doesn't work for web tools in 2024! I was lucky my company provided, but i know friends who learned from the other approach.
These web based NoCode companies should provide people starting out with free, fully functional accounts—but then restrict live users to about 5. Atlassian/JIRA was always good at this with their $10 entry point. While it's not a programming tool, this approach is why it's found everywhere. It allowed someone wanting to experiment and learn to pay just $10 for access to the complete platform.
You might say there is plenty of open source out there, and this is correct, but again, in companies, this is not always used. They want the known companies.
What the generation do have today which we never did is access to high quality training beyond books - and now AI! Wish I was 18 again!
How do I roll out that Windows software on Macs? On mobile? And all computer management software especially on Windows ends up being corporate installed malware.
Besides, if you think that installing desktop software is ever easy - especially if something goes wrong - take a look at what happened with CrowdStrike.
As far as learning how to code, everyone has a web browser and can download VSCode or even Visual Studio for free. All languages are free and you can download free versions of every popular database for hobby level work.
Heck these days you can stay in the free tier of AWS forever if you stay serverless.
And software developers aren’t expensive as is maintaining software?
I was hired as a lead developer back in 2016 by a then new director. He had four mid level developers working there. After he interviewed me, he asked two of the developers to interview me while he was in the room.
They said they wanted to do address validation and they were trying to think through all of the corner cases - this was a real world issue not a coding challenge.
They asked me did I have any suggestions. I said sure, there are third party CASS solutions that are USPS approved and they shouldn’t be building that in house.
I was initially hired to modernize their homegrown Electronic Medical Records system built on PowerBuilder in 1999 using Sql server 2001 (this was 2016). It had been maintained by two other “developers” who had been at the company for 10 and 20 years respectively. I walked him through my proposed strategy if I were hired.
It didn’t take long to realize that this company had no business writing software. They were a low margin company that sent nurses to homes of special needs kids and made most of their money from Medicaid reimbursements.
I started leading the effort to do data migrations and being part of negotiations with SaaS companies as the company I worked for started buying up other companies in their vertical.
The company ended up laying off the developers who interviewed me and turning the other two into report writers and doing data analytics.
A year and half later, I had a frank discussion with the director. I told him we both know you don’t need me. I found another job three weeks later. I literally “put myself out of a job”
>I never fully understood why this programming paradigm died off. Building business apps beyond Access or Excel was so straightforward.
Because every business app needs to be written in a Javascript framework to be considered serious. Nevermind speed, resources, speed of development.
> providing technical support to many developers when I wasn't one myself yet!
This reminds me of my days as a Lab Tutor at the programming lab at my college. I was only one or two semesters in helping people with Advanced Java homework while taking basic Java.
>I guess the web came soon after, and trying to do WYSIWYG for HTML and CSS has never gone well—even today.
>FrontPage came out but died soon after, and mixing desktop apps with web apps was never great.
I remember using Macromedia Dreamweaver and Microsoft WebMatrix for WYSIWYG.
I think we would still be using all macromedia products if adobe didn't buy them. I miss flash :(
I think one aspect is that business requirements for many of these apps became more complex, which is why we now often use process management or case management tools instead of smaller local programs.
Agreed, a fair point - companies are a lot more aware of what is possible beyond a spreadsheet! :)
Not only business. I think it's better in 2024, but as someone who lived through the browser war years as a frontend developer.. We may shit on Windows a lot, but learning the windows bits you need to write software in VB were ridiculously less complex than writing a backend AND a frontend for a webapp circa 1999-2005. Just because of all the tiny undocumented differences to make stuff look ok-ish or even quite the same. VB's layouting stuff was very good in my memory.
Most of it is negative possibility? :)
Being 100% serious here: half the SaaS webapp products I've ever used, both personally and at work, would be better and much more ergonomic if implemented as an Excel sheet or an Excel plugin instead.
Visual basic was the best way to build business apps ever. We just got these features in visual studio. Some we may never get (drag and drop dbs, form builders, etc etc). The closest I have seen was Flash. But if you say Flash or visual basic you are downvoted. I will let people get back to their js frameworks.
You're completely right, however the market for business desktop apps is over; not just because of the web, which is still inferior to VB in many respects, but because companies restrictions of what can be installed in a corporate desktop. It is much easier to use a web service than having permission to install a desktop app in a corporate computer. The huge Windows vulnerabilities destroyed the desktop as a viable business software platform.
Small businesses don't want to pay for simple apps. They want to pay a percentage of their sales to a large middle man who takes care of sales. It's too much for them to pay a few thousand (or hundred) dollars for a bespoke solution, but they have no problem paying tens of thousands per year to a middle man.
There's a reason small businesses remain small.
Almost none of those reasons are managing what are generally trivial costs for a growing business.
Small businesses remain small because they: cant scale, have a small tam, require direct labor from the founder to get the job done, the market is fairly well established but the founder has some special skills which are difficult to impart, especially in the context of the business.
Market conditions, the ability to get capital, and a lot of luck have way more to do than is your SaaS bill a little too high, you can always just use some google sheets and google docs and get 80% of what you'd need in most SMB situations.
When you deal with enough small businesses, you'll find out that they usually pay a large percentage of their revenue to middle men in order to save a pittance of money or effort which would be required to get rid of the middle man. People don't act rationally. Those who do act rationally regarding their business, generally find ways to grow it beyond being a small business. Assuming they want to. Many are happy being small.
SaaS is not a middle man. They're usually a good solution for a small business.
Pretty much everything boils down to having capital. Tech startups work because they inject capital into an idea that can be developed using technology. If you don't have capital to hire talent and sustain losses during several years, you have little chance to create a growing business in the modern economy.
Say what you like about Visual Basic (and a lot has been said that is less than complimentary), but for a huge number of people and workplaces this was the tool that moved people from trying to fudge Excel or Access into a workflow and actually trying to write some software.
My first language was BASIC on 8-bit machines (actually, it may have technically been Logo on a BBC, but I remember BASIC on a BBC as an 11 year old more clearly), and by the time VB came along I'd moved onto compiled languages like C and interpreted languages like Perl and PHP, and was a bit sniffy about the point and click nature of it all. I had one friend at college who refused to move on from QBASIC - I once saw him write a 3D game engine in that could about 30 frames _an hour_ on a Pentium - and the general atmosphere of being pro-FLOSS/anti-MS, plus a ton of really badly written apps encountered out in the wild when I did some small business IT consultancy made me very averse to VB in general.
But you know, it wasn't the fault of the environment or the language. It was powerful, useful and better than the alternatives for a lot of people. Its main contemporary competitor - Delphi - seemed all the rage before it didn't. And I now wish we'd been able to get a little more down the simpler visual programming domain for a while, because the modern equivalents like XCode feel massively confusing to the novice, so the learning curve feels very steep by comparison.
> a ton of really badly written apps encountered out in the wild when I did some small business IT consultancy made me very averse to VB in general.
A lot of VB has been historically written by people who had no background in writing software. They were jack of all trades, needed some quick and dirty and they learned just enough to have some working code
I see lots of comments about how good VB6 was. I agree it made programming super-easy and practical.
However, it is evident to me how the whole thing fell appart by the late 2000's, and now we have much more powerful, yet complex programming environments:
- Rust, C, C++: Extremely complex but powerful.
- HTML, JS, CSS: You have to learn 3 different technologies and won't be able to leverage the easy, powerful native APIs the OS provides. It's cross-platform though.
- .net: Not as easy as VB6 (and C# becomes actually more and more complex, more powerful as well, though). You have to learn XAML as WinForms is still a thing but considered legacy.
- Python: Easy (maybe more than VB, but not by much?), but no native, easy GUI toolkit for Windows. There are native bindings for GTK, but Linux is not a big desktop platform, and more so in business, and still GTK is much, much more complex than VB6 + Winforms + COM.
So basically, it seems we have traded easy of use and practicality for power/performance and cross-platform compatibility? What do you guys think?
I often muse over there not being a VB-alike approach for Python.
It would surely be reasonably straightforward to automate the creation of the GUI boilerplate code from a form designer, and then within an accompanying IDE hide most of that code from the user, only making the specific parts visible that correlate with different UI interactions?
> creation of the GUI boilerplate code from a form designer
why? i think the approach of of the form designer generating code instead of generating serialized objects that your code interacts with at runtime is a serious flaw. java got it wrong, cocoa got it right there.
I guess because that seems the path of least resistance within the existing Python world.
PyQt/PySide with QT Creator is the closest equivalent.
There's a ton of visual programming tools out there, they just don't call it visual programming but low code.
VB6 made writing Windows GUI applications very easy (on screen form designer), particularly when interfacing with COM libraries written in languages such as C++. No-one would use it if performance was an issue. Better was Borland's Delphi, with much the same features, but that ship sailed long ago.
VB6 is a terrible, quirky programming language, and it’s a pain to debug, especially if you’re used to modern development tools.
Microsoft killed it to push .NET (although originally, VB.NET was promoted as the main GUI language). People went to .NET, but also chose the "adult" language of C# along the way. Also, WinForms isn’t deprecated (it was in maintenance mode for some time, but now it gets some new features).
Language history aside, browser-based UIs are easier to develop and deliver, so they won over desktop applications.
> browser-based UIs are easier to develop and deliver
Compared to the ease of a VB6 winforms app, they are way harder to develop. It's just the delivery that's a little easier - as well as the portability to non-Windows platforms like phones.
Writing a simple VB6 app is easier than a simple React app, sure. But things get complicated when something needs to happen in the background — you need threading, and all the issues that come with threads in most GUI frameworks.
One of the "quirks" that really caught me out once was the fact that VB6 doesn't do short-circuit evaluation of logical operators....
VB.NET was apparently suppose to get short-circuited evaluation, but many of the old VB6 developers hated that or misused it in a bunch of places and their code would break when they attempted to move over to VB.NET. So instead Or and And went back to not being short circuited, and we instead got OrElse and AndAlso, both of which are short circuited.
VB6 is how I got really started off with programming and building games. There were project files you could find online of games made in VB6 of such immense complexity (one was an 'MMORPG' with networking, file save/load and data serialisation via RTF blocks, etc.) that it made my head spin. I don't know if I would have gotten into programming at such a young age otherwise.
Are you by any chance talking about Mirage online (and it’s many other servers)?
I remember loving that game (or the Jerrath Online server anyways) and being amazed by it. I knew enough about computers to know it was programmed in VB 6, but not enough to actually code.
But the desire to eventually make something like it definitely had to do with my interest in coding later on.
Page is not loading in Firefox 132.0.1 on MacOS Intel 15.1?
Edit: no, it just takes a loooooong time to load
True
Is this supposed to work? It does not for me. Probabbly my privacy settings are prohibitive for it?
And why is this mania putting everything into the browser that does not belong there? Is the reason putting there is just to have it there? Why not desktop app? Any sensible reason? Is it for pepole not owning a computer and have to fly from borrowed one to borrowed one where only the browser access is stable for them? So many things are particular with browsers for the purpose navigating the web or other source of information that it negatively interferes with usability for generic purpose app if not running the extra miles to get a workaround for it (and most do not care to run the extra miles). Pushing the wrong button in the browser f.s up something and others are cumbersome too, back utton, refresh, context menus, working with files, mixed with anything else in the tabs, even the address bar is in the way, etc. The few sensible web apps were either narrow use trivial ones doing a simple task thing mostly accessing a client service (human client) or put into a thin client (now its a computer) for clarity. Not user friendly at all. But hey, today's computer "engineers" give no fuck for the user but all for the technology, we all must enjoy that! (No)
This is an application built on Avalonia. You can compile it into a desktop application if you want (https://github.com/BAndysc/AvaloniaVisualBasic6), but because of the framework you get the web version for free. Seems rather ridiculous to complain about a web version of a hobby project just... existing.
You completely missed the fact that this is built using Avalonia, which means that you can run this on desktop (win, linux, osx), mobile (android or ios) AND browser (using wasm) with almost the same codebase. check https://github.com/BAndysc/AvaloniaVisualBasic6, and feel free to try the desktop ones.
The second part was an adjacent complain about the generic trend of putting things to the web too much. As it is obvious. It wasn't about this very project (the "putting everything" =/= 'putting Avalonia based Visual Basic 6', obviously, even the 'everything' is a rhetoric expression here used widespread in generic discussions and not a literal 100%, obviously). Please review it carefully this time, thanks.
It's written in Avalonia so you could easily compile a desktop version if you wanted, although the author doesn't package one explicitly
> mania putting everything into the browser that does not belong there?
This ship has sailed a long, long time ago.
Yes. : (
"And why is this maniac putting everything into the browser that does not belong there? Is the reason putting there is just to have it there?"
Haha, relax a bit. If it wasn't a browser application i wouldn't have tried it at all (most people here would not have either). I see it more of a toy than a development environment - but the fact that it seems fully functional and in the browser is impressive to me.
Anyways, 99.99% anyone using VB6 today is doing it for nostalgic purposes, not to develop real useful code - and that's probably what the project had in mind. Just a fun project.
If you did want an accurate no-changes recreation of vb6 on the desktop, just download the original vb6.
more people use it for production than you think. I have 20+ ActiveX controls being used in production using IEMode in Edge =D
> Why not desktop app? Any sensible reason?
It is a desktop app as well. It's written in C# and Avalonia. You can compile it to Windows, MacOS, Linux, iOS, and Android. You can also compile it to WebAssembly, which is what has been done here for this demo:
https://github.com/BAndysc/AvaloniaVisualBasic6
WebAssembly brings all languages to the web and this is a nice example of the power of wasm.
> Probabbly my privacy settings are prohibitive for it?
Yes. It does not load for me on Firefox unless you disable fingerprinting protection.
I guess that disables ALL wasm access to the canvas.
for the same reason some people have made run doom on evrything with a bit of processing power and a display, for the funsies