Web and mobile development (which I have done all 3) are significantly slower than what you could do with VB6. It's really strange why we haven't gotten back to it.
It was just brilliant.
Having said that, I must also say that I started coding on VB6 and if I had to show some elemetary programming to a ~10-yo, I'd give them something like QB64 in a heartbeat. There's something good in grappling with a "bad" language, educationally speaking.
EDIT: Ah I guess you were referring to arbitrary code injection after, say, a stack overflow? But I think that's a runtime issue rather than a language one (hard to draw a line in a systems PL, but still)
Something that my sibling comments haven't (yet) mentioned:
VB6 was really easy to create a GUI with, had great DB support, and was a pretty easy language to get started with. Given that a lot of business apps boil down to "present a nice, user-friendly interface to the company database" (particularly biz apps for smaller businesses) VB6 was a great fit for business consulting types. And use it they did! There were a lot of business consultant types writing code in VB6. They were smart people but not necessarily the most hard core coders.
I think that's part of why VB6 coders (as a group) got a reputation as being "lesser" programmers - they were derisively called "code monkeys", etc.
Regardless of the language itself, I think that seeing a lot of "minimally viable code" being shipped by people focused on delivering business apps helps to contribute to VB6's reputation.
Side question: I wonder how many people here on HN have a 'career origin story' something to the effect of "Yeah, so I was in college/high school/middle school, and the <name of small organization/mom-and-pop business> wanted to use their computer to streamline things. I was just learning how to code but was able to get VB to do <minimal but useful task> which really helped <org mentioned prior>. Looking back on it that was some really gnarly code I wrote, but it worked, <the org> appreciated it, and it got me hooked on programming"
These days every application reinvents its own controls for everything. For example, in a web browser the tab bar and address bars are totally custom controls. Electron apps like vscode take this to the extreme - I don't think vscode or spotify use any native controls in the entire UI.
I blame the web in part. It was never designed as a system to build application UIs, and as such the provided UI primitives are primitive and rubbish. Developers got used to building our own custom elements for everything - which we build fresh for every client and style in alignment with the brand. UIs built on the web are inconsistent - so our users never get a chance to learn a common set of primitives.
And for some reason, OS vendors have totally dropped the ball on this stuff. Windows has several competing "official" UI libraries. Every library has a different look and feel, and all are in various stages of decomposition. Microsoft's own software teams seem as lost as everyone else when it comes to navigating the morass of options - if windows 11 and MS Teams are anything to go by. Macos isn't quite as bad, but its still a bit of a mess. Every year I expect the people building xcode to know how to build and debug software on macos. And then xcode crashes for the 3rd time in a week. Xcode achieves the impossible of making the javascript ecosystem seem sane and attractive.
I'd love a return to the halcyon days of vb6, where UIs were simple and consistent. Where there was a human interface guidelines document that UI developers were expected to read. I want users and developers alike to know how the platform works and what the rules and conventions are. F it. How hard can that really be to build?
https://guidebookgallery.org/pics/gui/interface/dialogs/colo...
... But limited to only allow you up/downvote between -1 and 1.
Everything else could be done with buttons and a TextField / Label for comments and replying.
The web is a bit weird in that it taught us to build every UI as a giant scrolling document. And HN is no different. A more "classic" UI approach would be something like Thunderbird mail - with 2 panes: a "comments" tree on top and a "message body" down the bottom. That would be harder to read (since you'd need to click on the next message to jump to it). But it might encourage longer, more thoughtful replies.
Thunderbird: https://lwn.net/Articles/91536/
Or you could reimplement HN with classic controls and something like TB 114's UI:
https://www.ghacks.net/wp-content/uploads/2022/08/account_ma...
Probably still worse that what HN is now though.
Usenet had a much better model for discussion groups/forums like HN in my view, though crucially for the modern world it is missing some kind of "comment voting"/user-driven moderation. I wonder if there's an HN<->NNTP gateway around somewhere?
It really isn't. Web is anemic in controls and layouts compared to what's actually possible with proper controls and control over those controls.
Web apps also can't use a lot of native shortcut keys to build keyboard-friendly UIs. Its rude to override the browser's right click menu. Alt-anything might bring up browser native controls. Ctrl/Cmd+S is owned by the browser. And so on. Some of this stuff you can override, but even if you do, users never experiment because those shortcut keys basically never do what you expect.
The HN UI would be very easy to recreate in something like Delphi, I'd call it trivial.
We use Delphi at work. Our main application is a regular Windows desktop application. I recently had to add a new module to our application at work, it required three new input windows/screens, each with 100-150 input fields, few dozen buttons, and several grids.
I made the UI parts in a day. A few more hours the day after and all the UI logic and database loading/saving was done, and I had a functional UI for all three windows/screens.
Many of our customers have HTML-based ERP or CRM systems that we integrate with. I've never seen any of them that are close to dense UIs, and most of the time I see the user having to click through multiple sub-screens just to do a relatively simple task like looking up a couple of values. With a denser UI that could all have been on a single screen and saved the user a ton of time.
But I'd love to be proven wrong. Any examples out there of actually dense, in the good sense, web UIs?
I realised I should've added: Have you actually seen a proper dense UI? Look at any professional software. You will die of old age before you can implement just the layout for it using web technologies.
Here's Cubase with TAL-U-No-LX synth emulator in front of it: https://pbs.twimg.com/media/E8M6-QOWEAQMgGl?format=jpg&name=...
The skins are made using XML and QSS (Qt CSS).
It's not web per se, but it is not too far from it either. I would say it's a combination of both, Web and Desktop technologies, into one.
https://i0.wp.com/djtechtools.com/wp-content/uploads/2021/07...
You have no control over layout or control over rendering. In native apps (especially desktop apps) you can always go down or up any level you want. In the browser you're always fighting the quite rigid and high-level layout and rendering engine.
It's somewhat better now with grid and felxbox, but the browser will always have its own ideas on how the children can be laid out, and there are no good ways for children to depend on the parent, or for the parent to depend on the children etc.
There are very, very few dense layouts on the web. And while late-90s/early-2000s sofware was often ridiculed, you could create dense control-rich interfaces in minutes. Because they are usually not ad-hoc hacks added to the platfrom as an afterthought, like everything on the web.
My experience had been that most (almost all) of them _only_ worked with a single font in a single font size and a specific window size. If you did change any of these, it got unusable.
About consistency: except for those that didn't, not even MS themselves were consistent. http://hallofshame.gp.co.at/shame.html
The 90s had been also the time of programs like Kai's Power Tools https://mprove.de/script/99/kai/ and Winamp.
I'm sorry, but "interface consistency" is not something that comes to my mind when I think of 90s and early 2000s Windows programs (neither was Linux). Irix with 4DWM had been quite consistent at that time.
I can't speak to font sizes since IIRC that was an option but I left it default.
I taught courses on VB from versions 3 to 6 and this was always something we went over.
In comparison, modern windows doesn't even hide its inconsistencies. Try right clicking on the desktop in windows 11. You get a dropdown with large item spacing and rounded corners. But then if you click "Show more options", the dropdown is replaced with a different dropdown with subtly different menu items, small spacing and sharp corners.
They aren't even pretending any more.
This isn't Kai's photo goo we're talking about here. This is core windows.
Unless you opted out, basically every application in the 90s and early 2000s was built using the core platform's UI library. There were a few exceptions, but the 90s were a golden age for platform consistency compared to today.
Now its hard to find any 2 applications on windows which use the same UI style. Firefox and explorer? Nope - the maximise and close buttons have a different style. Spotify? Nah thats some custom webview. Visual studio? Nope, thats using an old windows library. Whatsapp desktop? Qt. Intellij? Some java thing. And so it goes. Its an absolute zoo.
They're pretty fast to create, relatively consistent, simple and fast/easy to create.
That's not what people want, they want all the flexibility and features of say Gmail or maps. B along with some communication and flexibility. Not to mention running on every OS under the sun, and being able to use accessibility and screen reader tools on all those platforms.
Uh, no you can't. Web forms aren't rich enough to build most desktop applications. You can't make vscode, gmail, slack or spotify using web forms. They're just a bad set of primitives for applications. (In the web's defense, it was never designed as an application platform).
Yet - we had some version of all of those applications in the 90s, on every OS at the time. And (mostly) using the platform's built in UI libraries so the look and feel was consistent and delightful.
IMO the fact that someone cared enough to make a site about what is largely nitpicks like this shows exactly how these stood out in the otherwise consistent landscape of UIs in the 90s.
Nowadays such a site would have 99% of every application released. It could even be automated, just somehow track all new .exe files in GitHub, MajorGeeks, Softpedia, etc and add them automatically to a hall of shame list, chances are even without human supervision the overwhelming majority will be correct :-P.
Part of what causes this crap is that the costs aren’t visible. If you can get it through stakeholders’ heads that they’re cutting the feature development rate in half (and making UX worse, and paying in maintenance time and a higher defect rate, but those are harder to make them understand) with their twee UI, some can be steered away from it, or at least convinced to tone down the most-harmful parts.
A billion times this. And this is when the next version of the design system isn’t incompatible with the previous one.
I can’t fathom why they made the decision to push every style to a different rendering engine. Working on Windows gets you to see every look and feel and the deeper you go, the closer you get to Windows 2000.
They seem to aim at minimising users leaving and maximising the extraction of data obtained per user
I'm gonna ask a dumb question out of ignorance because I know responsiveness is all the rage, but... what do we gain from it? Would it not be more straightforward to build UIs from the ground up for desktop and mobile targets than make one UI to morph to fit both?
As for the web, responsive design was so great that in almost every site i had to zoom out to make it think i had a monitor with a bigger resolution than i really did.
These days and since i do not maximize the browser (because my monitor is huge - like all modern monitors that do not have awful image quality tend to be), i often have to resize the window because sites tend to think i'm using a mobile phone and instead of scaling down / hiding less important stuff (that would at least be appropriate for a narrower viewport) they make thing ultraginormous (because touch screens), overly padded out (because touch screens) and they hide all options behind a hamburger menu (because mobile screens are physically too small).
I'm certain there are theoretically ways to do it "right" (a friend web developer told me how but i forgot) but absolutely zero sites (that i visit) do that.
This alone means you either handle any window size and size ratio or your UI will break for some users.
You should spec your UI in device-independent units and let the GUI handle things like different pixel densities (or aspect ratios) and font sizes.
* - two for one up front, ongoing development and maintenance costs of modern responsive UIs is going to be much greater than doing things right 2 or 3 times, but those costs are beyond the next sprint, and pay the good chunk of salaries in this industry, so...
--
[0] - And, unfortunately, this thinking became the zeitgeist of software development, so OSS projects do the same.
Most of the controls you have on the average GUI app are present in HTML. The big difference is that HTML describes active documents, not dialog boxes.
Styling should be provided by the host, not the app. The app should give, at most, hints to the system - that this button is the default, what the tab key navigation order is, etc.
> Web front-end are a completely different game in that regard
They shouldn’t be. The API is different, because the presentation layer leaks all over the place into the app logic. With runtimes such as VB’s the UI elements see and react to events, while the runtime takes care of pushing those events either to the host software or to the event handlers that are part of the app.
C# with WinForms is still usable today and provides a similar experience. Although the design language has fallen out of fashion.
For me, WinForms always had an element of struggle not present in Delphi
It was Lifted in spirit from NeXTstep's Interface Builder, so it was okay. But still a pale comparison.
P.S. If you are old enough, you will remember when $MSFT tried to steal Quicktime so its video products didn't suck. They got caught because they copied the machine code. Byte by byte. #howSad
Back in those days, I (and many others) would use VB just to build the GUIs for C or C++ programs. It was that good.
Bill Gates demoing it from 32-years ago.
However this is so long ago I have forgotten the details.
Access was probably simpler for a simple database entry and query.
However Access"s database was a disaster constantly getting corrupted etc. However I would note I was in companies that had access to full databases like Sybase and Oracle and as we had site licenses they were effectively free for each project. We often took a users Access project and made it maintainable in VB6.
VB6 was a programming language environment, Access was a client for the Jet DB engine. You could technically connect to more than just Jet DB's but that's primarily what it was for.
Visual Basic did have some database support but the actual database functionality/engine relied on external engines instead of being part of the runtime itself and it wasn't really part of the language. Being able to define a data type that is transparently mapped to a table's columns in a database and variables being cursors in a database would help with a bunch of smaller scale applications.
Basically something that mixed VB and Access. Ssadly that'd mean one would cannibalize the other's sales so it was never done.
Even non programmers can come up with some crazy stuff in Excel that just works, that will just run on any machine in their company.
https://support.microsoft.com/en-us/office/get-started-with-...
Even the "plan A" button code doesn't show the only interesting part of the code - how the UI is actually updated in response to the changed underlying data.
The IDEs I was making in VB6 in the 90s I'm making about twice as quick in Visual Studio 2022 in C# with WinForms.
In fact, quicker because I'm getting GPT to write any gnarly code I need -- like I just asked it if it was possible to add a tooltip to a ListBox and it churned out exactly the code I need, something I would have spent a bunch of time figuring out on my own.
>>Web and mobile development (which I have done all 3) are significantly slower
The above will probably take half a day in web development (assuming an experienced developer), so no, they aren't "totally wrong" at all.
VB created applications that had to ship with a shared runtime library. Windows wasn't great at versioning these libraries so developers often shipped their own VB runtime with their executable. The executable was small and the runtime was comparatively huge which had a negative impact on user perception when downloading the installers.
Before moving on to Microsoft in 1996, Anders Heilsberg was the Chief Engineer at Borland that oversaw the development and release of Delphi 1.0.
For years, VB felt like an application that could make deployable versions of itself. Delphi felt like a programming environment that compiled code into applications.
After Heilsberg moved to MS, a lot of improvements were made in VB that utlimately made Delphi less attractive, especially during Borland's strategic waffling known as "The Inprise Years": https://en.wikipedia.org/wiki/Borland#Inprise_Corporation_Er...
If you want to get a feel for what it was like then check out the FOSS clone "Lazarus".
Well, not actually. With Anders' move to Microsoft, VB6 (aka, VB "classic") was discontinued. Microsoft supported Visual Basic syntax on the .NET runtime, but the vast majority of VB programmers considered this to be a different language because developing for the .NET Framework (remember this is ~2001) was a huge departure from VB Classic.
Many VB developers petitioned Microsoft to open-source VB6 or continue releasing improvements on it. Microsoft did not and chose to continue with their .NET + C# strategy.
At the same time, I was playing with Linux at home, and wanted tooling that could run on either platform. I learned Python at home, and then made the switch at work.
One of my last VB6 apps, thousands of lines, has been running in the plant without issue for 15 years. On one occasion I had to bump up the declared sizes of some fixed length arrays.
As for GUIs, I never found anything close to VB, but also decided to just write a thin wrapper around Tkinter and let my layout be generated automatically by default. I haven't missed laying out my GUIs, which were always a hodgepodge anyway.
VB5 in 1997 and VB6 in 1998 really closed the gap with Delphi from what I remember.
This is (from Borland's telling) not an accident. https://news.ycombinator.com/item?id=29513242
Hard to not waffle when your major competitor hires away your top talent.
The VCL component library in Delphi is still unmatched in native code – very comprehensive built-in (and commercial) components, and customizable. Plus, Delphi's database connectivity was unparalleled and can be setup in the designer where you could see data queried and returned live in your grid component!
Delphi also supported advanced language capabilities (when compared to VB), like inline assembly and pointers, which were essential for low-level optimization or system hacking. The robust error handling in Delphi was another plus compared to VB's older 'On Error' style.
VB was easier to start but Delphi was nearly as fast to build, code was compiled (fast!), Object Pascal supported OOP and the UI features like visual form inheritance I have yet to see implemented anywhere else.
1. The component architecture was just great - I have yet to see any language/platform with a more sophisticated component structure even now.
2. There were all sorts of free and commercial components that you could download and install into the IDE and have it running in your application in next to no time. ActiveX etc didn't even come close to the level of integration and speed that the Delphi component architecture provided.
3. Components could be loaded into the UI during the design time itself and you could see it functioning directly within the IDE when you place it on your form. Example: You could connect to a database, run a query, put that into a table with all sorts of sorting and navigation functions and you could see this working even without compiling the 3pplication.
4. It was trivial to develop components for Delphi - even though it was so sophisticated. You could develop one in about 15-30 minutes.
5. The compilation speed was just insane. It just blew everything else out of the water and so you could do fast compile+run cycles.
2. The documentation was excellent and always reachable from anywhere in the IDE. It was all local of course so if you wanted to know about something - a control, an API, a part of the UI, whatever - you just pointed at it and pressed f1. Help would appear immediately with low latency. It also came with a big pile of yellow and blue covered books that taught you everything you needed to know.
3. The UI was well optimized with things like tabbed editors before tabbing became popular. It was made up floating but dockable windows, sometimes this was annoying but other times it let you keep things on screen.
4. Very good support for database connectivity.
5. The ecosystem was more coherent. VB wasn't usable for many advanced tasks so VB devs relied heavily on components written in C++ (OCX controls). Delphi was more powerful so components were often written in Delphi itself, with all the attendant advantages.
6. "Components" were more powerful than ordinary libraries of the type you get today - you could install a component into the IDE and it'd appear in a components picker at the top. You could then immediately drag and drop them onto a "form" (window) and begin configuring it with an interactive property and event UI that was always present on the left. This worked even for components that were not UI components, for example, you could drag/drop a timer from the component library onto a form, see all the properties and configure them visually, and then double click on the event to be taken to an editor window with the event handler already written out for you.
7. There were lots of little quality of life things, like it came with some stock icons for buttons.
Last time I used Qt Designer was the KDE2 days, it's almost certainly better than Delphi by now.
Versus the way we do things today, some stuff was better and some is worse. Delphi was primarily a wrapper around Win32 so apps written in it weren't portable. Back then it didn't matter of course, Windows had a monopoly. That meant it inherited Windows' limitations - UIs weren't responsive, styling barely existed, typography was limited, and the deployment story was nonexistent. That's why you keep seeing references to how great it was that Delphi made statically linked EXEs; same reason people like Go today. Operating systems suck hard at deployment, one of the things that eventually pushed people towards the web. In the grand tradition of platform devs ignoring deployment entirely, Borland never fixed it even as the web ate their lunch along with Microsofts.
On the other hand, the components model was pretty nice. Being able to configure libraries using a simple auto-generated GUI made them often much easier to use.
Until VB 6, which introduced AOT compilation based on VC++ backend, and creation of OCX in VB itself.
To this day, one of the easiest way to do COM on Windows, even better than .NET Framework (.NET Core made it harder, yet another thing that Framework does better).
Note that it still required the VB runtime either way.
In version 6, you could chose what compilation model, classical (p-code) or the new AOT backend.
Compiling BASIC to machine code is how it was born after all, the interpreters came to be in 8 bit machines, due to their hardware constraints.
Besides, Microsoft already had similar experience with a dual compilation model in Quick BASIC.
And not to leave this being my opinion only,
"Microsoft Visual Basic allows you to compile your applications to fast, efficient native code, using the same optimizing back-end compiler technology as Microsoft Visual C++. Native code compilation provides several options for optimizing and debugging that aren't available with p-code. These options are traditionally called "switches," because each option can be turned on or off."
https://learn.microsoft.com/en-us/previous-versions/visualst...
Delphi, with its Object Pascal roots, was(is) a systems programming language that also happens to have a nice RAD tooling for GUI applications.
Put in another way, it didn't own anything to C++ in capabilities, and had VB like tooling.
VB had to wait for version 6 to support AOT compilation and being able to implement its own COM based controls without depending on C++, and even then it only supported a subset of COM features.
Meanwhile the GUI framework being used by C++ Builder is actually written in Delphi.
As an old fart, GUI toolkits and building tools are one of those categories of absolutely essential software that gets scrapped and rebuilt (not in a good way) for every platform.
Kind of like IDEs for new languages, to the point of the article. First comes the language and basic CLI tools, and then about ten years later you might have a mature IDE with full language-specific syntax coloring, autocomplete, visual debugging, variable watches, etc.
And these 4GL tools were doing this with BASIC variants (not compiled) atop maybe 200-300 Mhz processors and 16-64MB (not GB, MB) of RAM. It blows my mind that modern OSes have slowdown and stuttering when the amount of CPU, considering multicore, more pipelining, branch prediction, etc, is likely 100x stronger than the the CPUs back then.
The 4GL languages/tools were all closed source and that did not age well. PowerBuilder folded (probably killed by Visual Basic), and then Visual Basic was killed in one of Microsofts platform purges.
They also were tightly coupled with databases in a UI --> DB architecture. As server architectures exploded in complexity beyond that, the 4GL tools couldn't adapt, partly because they were leveraging so much power of SQL under the hood, and the various server and RPC/invocations never offered the same power and flexibility.
But I can hear you .. SQL over the wire? Like send SQL to a backend service so it can be intercepted and injected and all that? Yup, probably part of the problem. Thick clients and direct internal LAN communication is an implicit requirement.
It's more that few people want to make and distribute small desktop apps anymore.
Commercial devs meanwhile will work on those things, but generally want to host the resulting app on their own cloud for a monthly fee. That's lockin which is scary to people and so outside of platforms where there's no choice (e.g. Apple) they prefer to have a less productive dev environment but more vendor options.
30 years ago devs were much less sensitive to lockin concerns. Open source barely existed so the question was merely which vendor would you choose to get locked in to, not whether you'd do it at all. And fewer people had been burned by projects going off the rails or being abandoned. The VB/Delphi era ended when VB6 suffered execution-by-product-manager and Borland renamed itself to Inprise whilst generally losing the plot (wasting resources on Linux, etc).
Open source stuff tends to have much worse usability, but there are no product managers, no corporate strategies and in the unlikely even that the project decides to radically change direction it can always be forked and collectively maintained for a while. That concern outweighs developer experience.
Also the ecosystem is just way more fragmented these days. In the 90s everyone coded for Windows unless you were doing mainframe stuff, and on Windows there was C++, Delphi and VB. That was pretty much it and they could all interop due to Microsoft's investment in COM. These days you have JS, Python, Ruby, Java, Kotlin, Swift, C#, Rust, Go ... and they barely talk to each other.
Money? Internal elitism?
They're trying to steer people away from end-user programming towards using more well-defined, tested, features. I find it patronizing, but, having seen some VBA, understand the reasoning.
Can't have user-programmable tools, because they could be used to ship (gasp!) malware, or let users (GASP!) work around policies of their employers' IT staff.
I do agree though that any GUI programming on Linux is a pain compared to Linux / Mac. However the proliferation of web based apps, even those running in electron shows how valuable a truely cross platform GUI framework that is easy to use would be.
Google is trying with flutter and dart but last time I used it I felt it was still being iterated on far too quickly, maybe a bit ( maybe even now ) it will be more friendly to use.
Much of the 90s experience lives on in FPC/Lazarus, but it did not get much better after that, and few use it. I wish they aligned themselves with a more popular language like Rust or Go for a more cohesive experience, while keeping Object Pascal (built with IDE experience in mind).
I still prefer the GUI building experience in Delphi 6/7 than anything that was produced since then. C#/Winforms is fine, it was designed by the same person - Anders Hejlsberg, but I wanted something native.
It's unbelievable that something modern like Flutter still fails to capture the design convenience of Delphi, from decades ago. Yes, the design markup is great, but I don't even want to look at it most of the time.
The later Swing/SWT editors never came close. Even Qt, which was inspired by it, never provided the component market experience of Delphi, and it was much more bloated in runtimes.
I fell in love with GUI design with Delphi, but otherwise hated it since.
A very core aspect of LCL and how Lazarus works (and VCL/Delphi for that matter) is language features like metaclasses, RTTI, properties, etc which allow the framework to register classes, instantiate them at runtime and inspect the class definitions so that serialization/deserialization and IDE features like the object inspector will work. AFAIK neither Go nor Rust have this.
The only language off the top of my head that has it is C# (which isn't surprising considering both Delphi's dialect of Object Pascal and C# were designed by the same person).
Of course there can be language extensions like C++ Builder did for C++ but they'd need to maintain their own compiler (or fork).
Personally i get the impression that Visual Basic and Delphi's language features were added in tandem with the underlying framework (if not deciding first how the framework and IDE features will look like and then deciding on the language features to support those) whereas modern UI stuff are made with whatever the target language has in place.
This is exactly what I hope would happen, except this time with Rust or Go. They don't need to integrate fully. I am not hoping for the ability to write Go/Rust for GUI code, just to be able to call into them without the clunky foreign functions.
I leave out Pascal now because besides the GUI part, the value isn't there anymore. The language is archaic otherwise.
> Personally i get the impression that Visual Basic and Delphi's language features were added in tandem with the underlying framework (if not deciding first how the framework and IDE features will look like and then deciding on the language features to support those) whereas modern UI stuff are made with whatever the target language has in place.
I agree. But the features stabilized, more or less. IDE experiences have not gotten better in a long while. It's not much of a moving target.
Smalltalk and Objective-C?
In Smalltalk you might be able to inspect objects and their values. The VM certainly has enough information for that - after all it needs to so it can read/write the image the objects are in - but i don't know how much of that is exposed (i've only played around with a few Smalltalks and never made any real application with them). Though even if that functionality is available, you'd still need some way to tell -say- a Delphi-like object inspector what properties are available and what values they are meant to be (so, e.g., a "backgroundColor" property is presented in the GUI with a color editor and not a string editor or whatever else :-P).
In contrast, Free Pascal (and Delphi) has enough functionality to implement serialization/deserialization for objects without the objects themselves having to have any custom logic (this is how components are saved - you simply declare a published property and the framework handles serialization and the IDE handles showing it in the object inspector with the appropriate editor based on its type). In addition the on-disk format can be implemented in a way as to allow only storing properties which have different values from the defaults (there is a language keyword to specify what the default is though there are also other means), meaning that any new property can be added. The default object writers work like that but as this information can be exposed to any program, you can do your own (the default formats and functionality mostly support whatever is needed for saving GUI forms but in my own game engine i need more functionality than that to handle binary data and external data assets so i wrote my own serialization system).
<select name=title><option>Mr.<option>Ms.</select><input name=name><input type=submit>
you can try it in your url bar: data:text/html,<select name=title><option>Mr.<option>Ms.</select><input name=name><input type=submit>
of course that doesn't give you database integration, but if you just want crud, you can get crud pretty quick out of django's admin
here's a couple of things i've hacked up recently in dhtml which i think wouldn't have been easier in vb6
http://canonical.org/~kragen/sw/dev3/ifs a 2-d iterated function system editor
http://canonical.org/~kragen/sw/dev3/clock a watchlighting clock
Also your two examples are drawing canvas examples, thats a pretty different target that delphi / vb6 have with their GUI toolkits.
i have no idea what segment, revenuecat, mixpanel, datadog, sentry, etc., are
And indeed, many of the complaints people have about VB6 not supporting multiple resolutions, etc, are fixed in Lazarus.
christine lavin wrote a song about your interpretation https://mojim.com/usy144575x1x8.htm in which she says
The reality of me
cannot compete
with the dreams you have of her.
And the love you've given me
is not as sweet
as the feelings that she stirs.
And so you turn away
and you say that you're sorry,
But you must pursue this dream,
this improbable dream.
Though things have not been bad,
you can't say you've had
Quite as good a time as it first seemed.
creating UI's in VB6 was so much faster and easier than html+css
yeah, but they're not reactive to resolution changes.
me: but they could have been updated rather than throwing them away and going with the complexity of today's solution.
css has gotten pretty complex, but html isn't inherently complex
Additionally, use of `@container` queries (the modern, poorly-documented alternative to `@media` queries) lets you do more advanced layout changes on element resize. This requires adding `container-type: size` style on the parent (I found this very confusing in the docs).
With grid-template-areas, you can use ascii art instead of specifying rows/columns manually. Though you would still need numbers if you wanted something other than the default spacing, which would be based on the content.
Responsive UI like its 1996!
Maybe in the era of LLM-assisted webdev tools (like teleporthq.io or MS Sketch2Code etc) the LLM will help sidestep API moats and help bring back such low-code IDEs. Or it could backfire and bring about API moats with non-human-accessible APIs (obfuscated binary only).
Adobe claimed that they could get Flash running on the first iPhone if Apple let them.
When Flash finally did come to mobile via Android in 2010, it required 1GB of RAM and a 1Ghz CPU and it still ran badly.
The first iPhone had a 400Mhz CPU and 128MB of RAM. It could barely run Safari. Were you around when the only way that Safari could keep up with your scrolling was by having a checkerboard pattern while waiting on the screen to be redrawn?
If you don't mind proprietary languages, there is Xojo[1] which seems to be designed mainly around Mac (it can do Win32 and Linux apps though).
That said, I've never used VB6 so maybe I'm missing something...