I see a lot of folks here asking about what happened to the original Yahoo Pipes.
We had the same question, so we went and talked with a lot of the original team and wrote up the story[0]. We also made a fun mini-site that contains a lot of easter eggs (e.g. if you click on the "Memory Pipes" folder on the desktop, you'll see a bunch of candid photos of the original team circa 2007)
By the way, that page is entirely unusable without JavaScript enabled, apparently in service of a modal preloader? Retro vibes are nice, but let's leave Flash-based websites in the past.
(Hi, Retool employee here who worked on this piece.)
This is the second installment[1] in what we hope will be a regular series telling the stories of novel programming environments that had a lot of influence on developers.
Creating these is a labor of love—we get to talk to the original teams who built products that were formational for us. We have an incredible in-house creative team that finds a way to sneak these fun mini-sites in amongst their other work.
For me, the most exciting part of working on a product like Retool is that it's an evolution of lot of ideas from the past. We're always looking at prior art to spark ideas and challenge our assumptions as we're building. There are many great ideas in old computing papers and products that were either before their time, or lost when there were major shifts in the industry. Pipes was a touchpoint for us as we built out one of our newer products[2].
We have lots of ideas for future installments in this series, but if you have any programming environments that were near and dear to you heart, let me know!
[1] Our first deep-dive was on Visual Basic. I'm very biased (I wrote it!), but if you like Glenn's Pipes piece, you'll probably enjoy this one too. :) https://retool.com/visual-basic
Hi Ryan, I appreciate the artistic approach taken, but thought you might want to know the page barely works for me in Firefox 120 on Linux 6.6. Everything is very laggy and the scrolljacking is terrible. Chromium is much smoother but the scrolljacking is still bad.
Generally speaking I don't think Linux is a target platform worth worrying too much about, but when it comes to programming-related content that might not be the case.
Generally speaking I don't think Linux is a target platform
Maybe, but you’d think an iOS iPad might be a target. I just closed the tab, as there’s no reader view, and the janky scrolling and waiting for text to load (text!) wasn’t worth the effort.
Same here on Firefox 120 Win10, but I don't mind it on the rare occasion such as this where it's half art project half write-up. If it were every article it would get tiresome.
Author here: Thank you so much for the amazing work! I am still finding more Easter eggs. Tips to other readers: click on EVERYTHING on the desktop in the opening splash screen.
I wrote a long form history of Visual Basic[0] awhile back that covers the origin of the product and how it ended up being married to BASIC at Microsoft.
tl;dr: VB started out as a project called "Tripod" (later "Ruby"), written by Alan Cooper (of "The Inmates are Running the Asylum" fame) and a small team of developers. It was originally a Windows shell construction set, but Alan sold it to Microsoft where it languished on the shelf for awhile.
Bill Gates eventually decided that he wanted to marry the visual UI building aspect with BASIC and handed the project off to Scott Ferguson and the Business Languages Group, who were maintaining Microsoft's QuickBASIC IDE, the BASIC compiler, and developing a new language engine (dubbed Embedded Basic) for inclusion in a relational database product codenamed Omega (which would go on to become Microsoft Access).
I actually wrote a long article on this [1]—and had a chance to interview some of the team that built the original version of VB that was sold to Microsoft. (Alan Cooper and Michael Geary; Michael actually frequents HN pretty regularly!)
My opinion is that it was a confluence of a few factors:
- Microsoft was very worried about the threat of Java/Sun, and rotated hard into .NET and the common language runtime as a response.
- The most vocal, but minority of VB users wanted more advanced functionality and a more powerful/expressive language (as is often the case). Couple with the shift to .NET, Microsoft listened to them: VB got a full rewrite into an object-oriented language and the IDE moved further away from the VB6 visual building paradigm. That left the silent majority high and dry.
- The web emerged. Working with the Win32 API was suddenly less relevant, and younger devs adopted PHP en masse, rather than adopting VB. (And existing VB6 devs upset about the change also migrated over when they could build for the web instead of Windows) Unforced error on Microsoft's part, since IE had 96% browser marketshare in 2001.
The web and the way MS handle the web killed it. Microsoft was pushing everyone towards these horrible activx components. Many moved to PHP or Adobe Flash.
I was using MS Access back in the day to solve business problems - it was like a VB6 DSL focused fully on data-driven applications. It was extremely time efficient thanks to that focus - what took me days to build took a VB developer (or PHP developer) months. That died thanks to web (and the web version being horrific and a dataleak waiting to happen).
The move to C# and the path they've followed since then was, looking back, the way to go. I only wish that they had done more to make the experience for native programmers better out of the box.
In my experience, ActiveX was not what they pushed. They pushed Asp.Net Webforms which used VBScript for the template language. The ViewState monstrosity made it an awful experience. Specifically how it send way more data than needed to and from the server on each request. I shiver when I think of it.
The real problem was worse than that: it was not a technical, but a legal one: Licensing!
You need to buy CALs for every concurrent user (yes, not only SMB/terminal services users) was the way to go according to some MS license experts, and the licensing was totally incomprehensible, as is today. No wonder most didn't want to risk building a business on these maybe not so solid foundations.
Still I only dare using asp.net for serving public webpages from Linux.
Of course the technical problems were also present, but many didn't even get to think of that as the BSA bullying was keeping them away already.
I think GP is describing the period before the .net switch. I remember back in those days having to do web stuff on MS platforms, which meant classic ASP, which was great for the job it was designed for: gluing together ActiveX components.
Unfortunately, nobody anywhere ever trusted ActiveX because it (at least gave everybody the impression it) had holes the size of a bus, so you were stuck using a limited language with no library support to do all the glue and all the heavy lifting, it was a very unpleasant period of time if you found your way into a Microsoft shop.
When the web was new, it was so clearly not designed for apps that pretty much everyone agreed it was absurd to use it that way. The UX and DX was just such a horrifically huge downgrade. Instead, HTML was for documents and linking, and apps would be given a rectangle (maybe the entire rectangle) through which they could appear in the browser. Netscape partnered with Sun for Java applets. ActiveX was therefore a response to that.
ActiveX made a lot of sense for Microsoft at the time. Firstly, it let the enormous base of Windows devs put stuff into a web page almost overnight. Secondly, it leveraged existing tech that was already designed for embedding one app's UI inside another app (OLE), and for shipping widget libraries to visual designers (OCX). Thirdly, ActiveX was a lot faster and more efficient than Java applets, being based around tightly written Win32 code. Finally, people weren't so focused on security back then and anyway, Microsoft had recently been investing in adding code signing to Windows. It appeared to them at the time that code signing would be sufficient to stop abuse. We know in retrospect it didn't quite work out that way for them, although it's been pretty successful on Macs.
And in fact ActiveX did see quite wide usage, albeit mostly as IE's answer to Netscape's plugin interface. But it didn't take off in a big way because:
1. ActiveX apps were native code and native code is very low level and thus very large compared to JavaScript and HTML. Performance is great because the CPU eats it directly with no intermediate translation layers, but you pay for it in code size. Back then bandwidth and CPU were both tight, but HTML/JS were light on both at the cost of UI latency and primitive controls. People picked low startup time followed by high latency and primitive controls.
2. The UI they picked for code signing was a (standard at the time) popup modal dialog. It had very poor usability, being filled with tons of complicated words, often asking you to approve software from a company you'd never heard of (i.e. products/websites did not use the same name as the company that produced them) and worse, malicious web pages could put you into an infinite loop where if you clicked cancel they'd just immediately ask you again, forcing you to click yes. Which was equivalent to downloading and running an unsandboxed program. Back then browsers went years between updates so once they shipped that mistake, it was very hard to fix quickly and so the reputation of ActiveX became very poor.
3. They had no way to sandbox native code at this time, the Windows kernel just didn't support it at all and it probably wouldn't have occurred to them anyway.
The first problem was fundamental to the approach. The second problem was an unforced error.
They could have tried to switch over to a sandboxable bytecode; VB used what they called "P-code" on an interpreter already. But they didn't. Java was becoming too popular, too fast, and they lost confidence in their own tech stack. Instead Gates threw the company into a crash effort to clone Java. By the time .NET had the ability to do ActiveX controls they'd already moved on from that approach and were trying to make DHTML work instead.
I have the opposite take, as a non-native programmer in the early 00s.
All the PostBack loops in ASP.Net and WYSIWYG editing in VS.Net 2003+ felt like they were trying to appease native programmers to a fault. VB.Net wasn't bad but it was frustrating how hard it was just to script something without boilerplate. Being limited to IIS was also bunk.
>The most vocal, but minority of VB users wanted more advanced functionality and a more powerful/expressive language (as is often the case).
This is the single reason why most computing tools, ( not limited to VB ) never reached wide enough audience. The nerds keep asking for complexity, but the majority actually wanted even more simplicity.
I think there's a deeper problem with development tools in general:
There is no tool that goes from 0 to 100.
The tools you listed (I'd also add Excel) were great for people starting out, people who had an itch to scratch, people solving a problem. But inevitably, the programs they made worked too well, they got adopted, got added features, became mission-critical, and now outgrow the tool they were written in. And that's when you get the "nerds asking for complexity". Those people didn't start out nerds, they started out as users solving a problem, but now their little "make a formatted report out of this Excel sheet" tool is running the whole companies realtime sales forecasting and they scaled up along with the project.
I think the plan with VB.NET was that ("start out with VB and if you need it you can seamlessly graduate to C#!"), and Chris Lattner planned the same thing with Swift ("it will replace Python!") but none of those plans were ever carried out properly.
I have a theory on why: it's because the scope of a general-purpose-ish language inherently increases; there are always users that are mostly covered by the featureset, who just need one more feature and they'll be fully covered, so they'll ask for that feature. But by satisfying them, you'll bring more non-users from their nowhere-near-covered position up to the "99%-covered" boundary, and then they'll want their own last-1% feature.
The same people who want simplicity in their language/tooling also want to not learn a second almost-identical system just to achieve that last 1%, so refusing to expand your scope here isn't necessarily "optimizing for simplicity".
I worked for a company where we built a prototype for a rewrite of their flagship product in VB. Meanwhile a big team of programmers implemented the “production” version in VC++. But at that time a bunch of the controls available in VB were not in VC, so they lagged quite a bit. Of course management saw the prototype working (it was a CRUD app for property management) and said why not just use this. The C++ programmers turned up their noses at working in VB and were summarily fired, leaving me and a team of contractors to finish the job. 100% the right business decision and a good lesson on getting too precious with your tech.
The people with money really. Few people care what the nerds complain about, but Microsoft will listen to Fortune 500 companies that hold thousands of top tier paying users and their complaints about how such or such feature would help them save days of work every months.
This the ultimate "vote with your wallet" I think, those with bigger wallets will have bigger votes.
An unfortunate byproduct of this, that I think is an unpopular opinion in these parts, is increased in product analytics/telemetry. People eventually learn that the feedback you receive re your product only rarely reflects the experience of the majority of users.
This article was excellent, @RyLuke — I read it a few months ago when it was first published and passed it on to just about everyone I know in my MSFT network.
I cut my teeth on VB6 back in the day — for someone that didn't know much about programming at the time it felt like I suddenly had found a new set of superpowers. VB6 was a big confidence booster + momentum builder that set me on a path to a happy career.
Awesome that you were able to connect with Alan and Michael and thanks for the trip down memory lane.
> VB got a full rewrite into an object-oriented language and the IDE moved further away from the VB6 visual building paradigm.
What do you mean by this? Visual Studio today has a designer / code editor that works in a very similar way to VB6 that I remember. What do you think is missing?
P-code debugging with fully rewindable edit and continue.
A one-true-way event model that was derided at the time but was really just years ahead of its time.
Minimal runtime downloads to install apps locally, which also produced tiny, performant executables.
The sweet, sweet With keyword. I know, I know. But I don’t care. Just be more aware of your namespaces.
Also (and I still don’t understand why we can’t have this in VS Code when VS had this in 1998) object combos at the top of the code file for class and method (admittedly VS proper still has this I’m just grumpy at the regression)
> Minimal runtime downloads to install apps locally, which also produced tiny, performant executables.
.net framework 2.7 is guaranteed to be installed by default these days so you can deploy one exe without shipping your own runtime. Yes, officially you shouldn't, but there's so much stuff that depends on it now.
One thing that sucks about those combos, if I remember correctly: Don’t they show only the members of the class your cursor happens to be sitting in, and not those in the whole file? That’s just monumentally dumb. I remember cursing at those as I hunted through a bunch of files for some function… only to find it was right there in the file I had up but Microsoft didn’t show it.
I remember scorning Xcode back when it was Project Builder, but saying Hey, at least its drop-down member lists work properly.
A lot of people who wrote VB weren’t serious/professional programmers and VB.NET was too complex for them. For the serious programmer group, the stink of “VB” tainted it right out of the gate (despite having complete feature parity for a long time VB.NET jobs always paid notably less than C# ones). So it was kind of a compromise that satisfied nobody.
That was me. I wrote what I affectionately call "crapware," which are small apps that solve a problem but are not intended for use at scale. There was a lot of this stuff, such as little database queries, or hacking together a few industrial sensors with a crude display. Businesses ran on crapware. Maybe they still do. A few thousand lines of code that I wrote for a manufacturing fixture ran bug-free for more than a decade.
I remember that just downloading and installing VB.NET was burdensome, especially in the plant where many of the computers were not networked.
When VB.NET came out, programmers hung on to their VB6 disks, and kept using it for easily another decade. By the time VB6 really reached the end of the road, its replacements (e.g., Python for me) were up to speed, and free.
I've written a lot of crapware, still keeps my employer working 15+ years on. Meanwhile "replacement" systems have come and gone, but the users still keep using the crapware.
I was going to say, a few thousands lines of code that reliably solves a real business problem for over a decade is pretty much the exact opposite of 'crapware'...
As long as you don’t care about stuff like maintainability or logging sure. The issue is that a lot of times businesses outgrow their bespoke Access app or whatever and then it’s a huge headache to untangle the reliance on it and go more robust. Of course if that never happens it’s great and frees up developers’ time for higher-value work.
The issue is there’s no engineering process around it, even in a shitty organization where the “engineering” is garbage.
One place I helped out at had a pretty awesome access app for doing some business functions. Way better than the Oracle whatever they failed to replace it with.
The problem was, nobody was willing to claim ownership. The business guy who wrote it was long gone, and IT would not accept an Access app.
OK but does IT exist to serve the business by accepting responsibility for stuff that doesn’t meet their standards and they can’t really support? Why have qualified people at all then?
I can't speak to IT specifically, but generally the answer would be yes. Stuff happens, resulting in "nonstandard" or unexpected requests, and the decision on how to deal with them rests with the business, with reasonable input from the people involved. In my own work, this can often happen by accident when departments and business units are reorganized and acquired. I once got an entire product line dropped in my lap, that didn't work at all, hardware or software.
Many, if not most, professions are not nearly as well organized and optimized as IT, so we don't have things like silos and ticketing systems to regularize our work. I can imagine an IT worker who has never experienced a nonstandard request, but I can't imagine it in my own occupation.
I don't get the relation here?, most businesses care somewhat, and certainly the better run businesses do quite a bit, so they'll make sure to record down everything important about the software.
So when it goes wrong in many predictable ways it’s a nightmare. All the stuff software engineers put around software to make it reliable, fault tolerant, and generally having the expected behavior is not just for laughs but the result of hard-won experience.
It seems like your describing more of a problem with the system between the screen and the chair.
e.g. 'inability to account for new desired behaviors' for presumably a core business system, that the business relies on, would almost certainly imply that.
As to your question, it doesn't really matter what my background is, I could be a ballet dancer and would still be able to reason out how businesses operate and how software historically has integrated. It's not some big secret.
I'm sure this happens all the time. The term is technical debt.
I think there's a kind of no-mans-land, where programs get too big for an individual hacker to manage, but too small to muster the programming department. Getting small tasks done on any kind of timeline is usually just a no-go.
Also, most machines did not have the .Net framework installed, and back then it was 20 MB download which was gonna take ~2 hours on dial up back in the day vs MSVMVM6.dll which was on all Windows versions from 98 until 7 at least.
> When VB.NET came out, programmers hung on to their VB6 disks, and kept using it for easily another decade. By the time VB6 really reached the end of the road, its replacements (e.g., Python for me) were up to speed, and free.
VS6 was still the majority IDE well into the mid-00s, at least in an academic setting. I still remember getting handed an academic license DVD to use for my C++ courses in University around that time.
The disconnect between "classic" and ".NET" VS took a long time to break, I would say until about VS2008/2010.
I think today python fills that void - people who are not serious programmers but need to put something together. Think academics, data analysts, etc. And since Python is cross platform and easy to get started with it is a lot more attractive than VB.
It's significantly harder to put together a quick GUI application in Python than it used to be in the VB6 days. Just getting all the dependencies installed can be a pain, and then good luck trying to add another button to that app say 2 years later, chances are nothing will build anymore.
Honestly it's harder to put together a quick GUI application in anything than it was in the VB6 days. By losing VB6, we've lost a lot of power and ability to do GUI things quickly.
WinForms in C# was pretty decent tbh. Not so sure about WCF/Metro/Modern and whatever it is now that Microsoft been releasing. They just stopped caring about consistent UI for apps on Windows altogether since ~2010 or so.
WinForms is fine but it makes it way too easy to put all your behavior in the code behind instead of doing things nicely. Which I guess is what you want for a non-programmer tool but it is a hassle for me. Either way the .NET UI situation is a mess and I’ve never seen the sense in picking up the latest flavor of the month since it will be out of favor by the time I have occasion to use it.
Correct, but it hasn't been upgraded in over a decade. It no longer produces apps that are consistent with Microsoft's own the way it was until Windows 7.
There are VB like tools. These days they're all SaaS though. Oracle APEX is one well known one, there are plenty of others out there.
There are at least three massive problems faced by anyone who wants to hew closer to the VB6 model:
1. Deployment tech.
2. Getting people to pay for it.
3. Developer culture.
In order:
Deployment. There are tools and UI toolkits today that support VB6/Delphi-like development, but they aren't web based. For example, you can also do VB6 like development using Java or Kotlin + JavaFX + Scene Builder (or Swing and one of the visual form designers for it). This leads to the question of how to deploy the result. Unfortunately, for the past 15 years or so the answer has been pretty much "you can't".
In the VB6/Delphi era the answer to deployment was "take your EXE and stick it on a shared Windows network drive". For internal business distribution this worked fine. Java had JRE+Java Web Start, which also worked fine inside businesses. Unfortunately neither approach works anymore: Windows is no longer ubiquitous, tools don't produce standalone EXEs anymore, users don't know how to handle zips and folders (these skills have atrophied). Also security has got tighter so throwing EXEs around is harder, and people expect software updates to work smoothly. Java dropped WebStart and never replaced it with anything good enough, so the tooling actually regressed with time too.
This isn't fundamental and is fixable. I spent the last couple of years fixing the tooling situation [1]. You can now deploy desktop apps as easily as you do for a web app. Conveyor does signing, packaging for Win/Mac/Linux, and integrates auto-update as part of the packaging process. It will even generate icons and a download page for you and then upload the results. You do still need code signing certificates, however, and getting those isn't as easy or cheap as it is for SSL certs with LetsEncrypt.
A related issue is database and server side logic hosting. VB6 development assumed it was OK to just connect directly to a database using its native protocol and that e.g. every employee would have a DB user. People are more protective of their databases these days and would find this level of simplicity to be radical. I've experimented with that too and given a talk on it at KotlinConf [2]
Payment. VB6/Delphi were developed in an era when people expected to pay hundreds or even thousands of dollars for each version of their IDE/compiler. There were no subscriptions but in practice new versions would come out every couple of years or so, so if you wanted to keep up you'd need to budget a few hundred dollars a year. Skipping versions was common.
Nowadays, people's payment expectations are different. They expect programming languages and platforms to be free and open source. They take absolutist positions on it, saying things like, "it's not open source so I can't ever use this". This rule vanishes if something is a proprietary SaaS however. This kills the incentives to develop better tools for standalone "business crapware" development as mentioned elsewhere in the thread - apps have to be tied to a subscription SaaS or else you can't get paid to work on it. In turn that makes it hard for people to learn by just experimenting locally. For programming languages, every new language that comes along in the past 15 years or so is essentially either a hobby project of celebrity employees (e.g. Go), or a way for rich tech firms to solve tech debt and productivity issues (e.g. Kotlin, Rust, TypeScript), or commercialized by selling long term support (Java). The closest to a real commercial language is Kotlin and that's very indirect, it incentivizes IDE sales, as IDEs are still something people are sometimes willing to pay for (but most use whatever's free).
It's possible that the pendulum will swing back here.
Developer culture. Part of why devs are so hardline on stuff being free is that they want to add it to their CV and learn tech that they can take with them to their next job. This means going where the crowd is. If you wanted to do something VB6 like you'd have to do things very differently to how they are done today (e.g. probably not web based) and that would mean people would stay away just out of fear that they'd stray too far from the herd.
Still, despite these problems, there are ways you can do that. Like I said, take Java/Kotlin+JavaFX+Scene Builder+Conveyor and you have something similar to the highly productive 90s era platforms. You do of course need the confidence to learn tech that some consider old fashioned, and which isn't as widely used as React or whatever.
You could even just go all-in on the Apple platform! Swift+Xcode+their Interface Builder still works.
> It's significantly harder to put together a quick GUI application in Python than it used to be in the VB6 days. Just getting all the dependencies installed can be a pain, and then good luck trying to add another button to that app say 2 years later, chances are nothing will build anymore.
I would say that it is harder, but not significantly so.
Lazarus gets mentioned a lot on these forums, but have you tried it? I use it to whack together decent native looking applications.
It's a single download, it comes with a comprehensive list of components which you drag onto a form to build the GUI, never breaks old apps on an update, and works on Windows, Mac and Linux.
And as a programmer who preferred more c style languages, vb.net sucked (and I understand that's just, like, my opinion man). Way more verbose with weird syntax. Can't remember the exact syntax for lambdas, but it was a joke.
VB6’s concept of OOP was different. Sure the same keywords are found: Module, Sub, etc but it was rewritten to run on IL/NET VM. Fundamentally changing it from a COM compatible language to a .Net framework compatible one.
VB6's concept of OOP was simple enough it could have been translated into .NET and .NET is broadly compatible with COM. I'm certain Microsoft could have made it work. They really needed to consider VB6 as a backwards compatibility target instead of building VB.NET as a modern replacement. VB.NET really has no reason to exist; it's not compatible enough with VB6 but then also includes a bunch of VB6's weirdness.
The visual editor is the same...but even with VB Classic, you couldn't just design a UI and have it magically work, you needed to wire up the logic. That component has a much higher learning curve backed by a particularly more difficult to grasp language.
Vb.net was a bit weird yes but visual basic did need work. Vb6 did not have multithreading which was really starting to hurt its efficacy by 2002. You could work around it by using events as much as possible but there were still some things that were blocking. Also the events were not even on a separate thread either leading to the need to pepper DoEvents everywhere.
This was a dealbreaker for vb to ever become a serious language and kept it squarely in the hobby bob / prototyping arena. But who wants to prototype in a language that requires a full rewrite in another language to go to production?
In the long run this was always unsustainable. The rewrite to .net fixed this but it was a significant departure from vb underpinnings and in particular the seamless winforms integration that was pretty amazing.
Also, with .net came multilingual capability and c# got really popular quickly and displaced vb.net
VB was probably 80%+ line of business CRUD apps. What would you write in VB that needed multi-threading? You're not writing trading systems or games in it.
> VB was probably 80%+ line of business CRUD apps.
That's more a result of it not supporting it I'm sure. It could have been a great general purpose language if it was a bit more powerful.
I used to write apps in it and I often ran into these issues. Mainly small business custom administrative stuff. Like a management system for a chain of hostels. It was still important to have multithreading because things can get updated by other users, or even clients themselves through the internet (in fact I spent a lot of time adding ASP frontends back then). I don't like using locking too much in a multi-user environment because it gives a terrible UX, so I would have to constantly check if nothing had changed.
In this day and age you will also have to deal with a lot of web API calls that can happen asynchronously. Locking the main thread is really not an option. Remember that VB6 even locked the User Interface when it was doing something, even the visuals didn't have their own thread. Making for a very choppy experience.
Like I said peppering DoEvents everywhere helped mitigate this a bit, but sometimes you had to call stuff in external DLLs and while the call was away the whole UI would be hanging.
Correct, nobody cared about "true" VB multithreading. Besides VB supported multi-processing very well, much better than the JS world does today. You could call objects between threads no problem. Behind the scenes it was using DCOM, so if you passed an object from one thread to another, the other thread would get a proxy that'd do RPCs to the first thread. So there was no true shared memory multithreading, but for VB users what they had instead was in some way even better, it was basically web workers but more transparent. Specifically, it meant that object calls couldn't run in parallel to UI updates or other logic so there was no need to think about locking.
But the whole thing of the UI being on the same thread was a really big problem. You could get around it by calling the Win32 Threads API but that would quickly lead to a crashfest due to the no shared memory thing. Electron doesn't have this problem because the UI is handled by the renderer, not the JS engine. So in that sense the UI is in a separate thread. This wasn't the case for VB6.
And events in VB6 were not great. They were good for the time, sure. Because they had to be. If you'd write an app in it today with lots of external API calls it'd be a mess.
VB6 was serviceable at the time but without multithreading support it didn't have a future in an ever more API-driven environment.
I don't quite understand what you mean by UI being in a separate thread. You could have background threads in VB from what I recall (it's been a while...). The only difference is that Electron/JS forces you to do your own IPC messages whereas Windows would abstract that out.
What I mean was that if you ran a large function that would take a few seconds, any UI redraw would be blocked completely for that time. So resizing a window would not cause a redraw of the UI until it came out of the function, pressing a button would not visually reflect the button status, basically it would seem like the application was hanging.
You could avoid this by peppering DoEvents in your loop. However, this was not always possible like if you were calling an external DLL function. I had an application that would talk to a Kodak digital camera by using their DLL and that would take considerable time.
It's really what separates a serious programming language from a toy, or at most a prototyping tool. Like Fisher Price, you can make something quick but it's not capable of actual use.
I think people have this rose-colored view because back in those days UX standards sucked and many apps had a lot of quirkiness. But times were changing and even a few years later this was unacceptable.
There were no official background threads, you could use the Win32 Threads API but it would cause instability due to not having memory protection.
But this "hanging" behaviour was really not suitable for a general purpose application. Electron doesn't have this issue because the renderer is independent from the javascript code.
but from looking it seems like people were doing it by writing VB that ran in a separate EXE and then indeed, COM would let you do RPCs between the different processes. So multi-processing rather than multi-threading.
Javascript is better at asynchronism than VB was, and in Electron the user interface does run in a separate process. Unlike Visual Basic 6, where the UI would completely hang when you were busy with some external function call.
As someone who loved coding in VB6: (I actually dreamt about it the other night, thought I woke up some 20 yrs ago!)
- very cool that you got to interview the VB team, your article is high on my reading list :)
- to OP’s point, I recently started doing some things in Swift with XCode and found sim having just as much fun. I’m using SwiftUI. So maybe not the same experience for everyone but I wanted to share here.
I did a shitload of programming in VBA, specifically Word macros. Word 6 was the peak of that product. I wrote entire text-processing applications in it, with dialog boxes and everything. Started my career at a Big-6 firm with one, actually.
Now I’m learning SwiftUI as well, and like it so far. I’m an experienced iOS dev, but SwiftUI is new to me. But I like it (and QML in Qt) more than I expected. Good luck!
I don’t have experience with iOS - I am actually doing a bit of macOS development with that SwiftUI because, well, desktop apps kind of take me to my teen years building VB programmes (no one called them apps, at least I didn’t).
VB and the Web: The VB model for rendering Web pages was Active Server Pages and Server side rendering. Very similar to Java Server Pages. Which was still better than PHP but the IDE did not have a community version and php was easier to get started and was being taught in college curriculum.
IE having so much browser market also killed anything MS because they always tried to create their own standards which nobody wanted to follow. The client side was so difficult to script with having to test which browser and accomodate quirks mode. Another unforced error. Corporate adopters are still trying sunset critical apps which only run in IE or Edge with IE mode turned on.
I do not think the problem with VB was the language.
I think it was the graphic / UI expressive power, a simple way to add and create custom components.
At the same time that both VB and Delphi reached peak usage, the web started to show how easy it is to express graphically and UI using CSS. When you have to write tons of lines of code in VB to get to the same as 3 lines of CSS...
This doesn't match my experience, if anything the other way around.
CSS back then was a lot harder than it is now. There's still memes around this, but even something as common as centering an item with CSS was not trivial at all. Now we have flex and it's easy, but back then it was very much not.
VB didn't work on the same paradigm - it was a more WYSIWYG environment. You drew a button on the form, set some properties in the sidepanel, and that's that. Notably there are zero lines of code involved in this, so the whole "you have to write tons of lines of code in VB" is simply not true. Possibly you're thinking of its successor, XAML, for which this is true.
Having worked for 10 years on both Delphi and VS, I understand the experience you are talking about. Having the ability to draw UI is amazing, and super productive. For business applications, it is amazing.
However, I still remember at around 2002 that we where asked to build specific custom user experiences, I think it was around reports, and using VB or Delphi was a lot of programming using draw commands... while using HTML and CSS it was fairly easy, even with the browser differences of CSS.
Any custom component in VS or Delphi (I am talking atomic components, not composite) requires using basic draw commands, and a lot of them.
The end result was that both platforms are not as expressive in terms of UI as the web, you cannot compare basic draw commands to structured CSS.
Reports, yes, that was a pain in the arse. Anything where you had to generate controls on the fly based on data was painful. Crystal Reports was both a nightmare and a lifesaver at the same time. I always thought that someone should do a better job of it, but I did not want to go there ;) By comparison producing a report (or anything data-generated for that matter) in HTML was easy.
can vouch on this, since originally I really prefer WYSIWYG UI (VB, C# winforms, wpf) over web early. However security-wise it's hard to enforce when using them, since they don't really operating using client-server by default, having your backend logic prone to be reverse engineered.
This doesn't happen in web apps, since backend logic stays on the server. Whipping a html UI over the already server-client architecture is easier. In addition with ease of deployment of application making web apps very favorable.
VB and Delphi reference architecture was 2 tier - client and database. With this reference architecture, you are right about the security and distribution problems. You just reminded me of the shareware market and the hacked shareware markets...
However, early on, around 1998, people started talking on 3 tier architecture of client - server - database on both platforms. There where even attempts to build web pages using both platforms (and later on .Net), which failed because of a lot of reasons, one big reason was not understanding the advantages of CSS.
Yes and nowadays there's nodejs with react, where there's javascript on both client and server, with addition of html and css making desktop app that's not multi platform, almost obsolete.
Which is why lately companies are trying to use electron or react native to replace them.
I opened VS and looked at WPF again the other week. It was a surprisingly pleasant experience. Though my C# is sooooo rusty now (and not in a crab-like way).
I wonder if there's a market for "WPF for Golang"? ;)
One of the developers here. Sketch.systems is about 5 years old and we haven't actively worked on since its release––but it's still used fairly regularly by folks and does the job it set out to do! If anything ever seems broken, reach out (our Twitter accounts are in the website footer) and we'll definitely take a look.
Hey Stephen, I wrote the original article. Had no idea that MS actually tried to port the Ruby forms engine to the CLR—what a fun twist. Did it end up being too difficult technically, or were there other factors that killed it?
We kept the Ruby forms engine as unmanaged code written in C/Win32/COM and tried to integrate it with Basic code compiled and running on the CLR, but it didn't work very well. There were a lot of problems back then (this was 25 years ago now, a couple years before .NET 1.0 shipped) with CLR/COM interop. One particular problem I recall was that the interop layer did not support calling event handlers via IDispatch which the Ruby forms engine required.
Thanks, Michael! Finding your comments on HN about the design details of the original "Ruby" version of VB and VBX was part of my inspiration for writing this article in the first place. Your recollection of "firing an event" is my favorite kind of classic Silicon Valley story.
Ryan, thank you for writing the article. I remember you described it to me as a "labor of love". Indeed it is that. It also reminds me of how much work goes into journalism like this.
Ruby/VB was a labor of love for us. One of my favorite episodes of Silicon Valley was the TechCrunch Disrupt where every founder said "we want to make the world a better place." It's funny, but true! That is exactly what we wanted to do.
Anyone who likes the "fire an event" story may also enjoy What the Dormouse Said by John Markoff:
Most of them have found niche markets in verticals like automotive/medical/embedded, where it's easier to just ship a runtime for the UI.
UI/UX designers working on the dominant platforms (web/mobile) have a lot of nostalgia for Flash--particularly the perceived ability to actually ship functioning product. There's no lack of new tools trying to improve on the status quo: drawing pictures of UI and throwing them over the wall for developers to figure out how to implement.
I suspect that we haven't seen the aforementioned IDEs become industry standard for a couple reasons:
+ They're by nature more difficult to use than drawing tools, often surfacing a lot of advanced parameters, state machines, and code
+ The variability in languages/frameworks/platforms inherent in web and native development make usable output a much harder problem than having everyone all-in on a single framework/runtime
The happy path issue is definitely one of the big pain points in the "designer throws mockups over the wall" workflow. Simulation of the production medium in the visual design tool can help a bit, but the real solution is to get designers working in the production medium. That's easier said than done, of course. (And ultimately more of an organizational/practice issue than a tooling one.)
We had the same question, so we went and talked with a lot of the original team and wrote up the story[0]. We also made a fun mini-site that contains a lot of easter eggs (e.g. if you click on the "Memory Pipes" folder on the desktop, you'll see a bunch of candid photos of the original team circa 2007)
[0] https://retool.com/pipes