9 ms·

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. (Al

• radicalbyte 3y ago
  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.
  • jamra 3y ago
    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.
    • Sophistifunk 3y ago
      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.
    • fodkodrasz 3y ago
      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.
    • bowsamic 3y ago
      The ViewState problem is easily avoided by keeping it on the server
    • mike_hearn 3y ago
      The ActiveX era pre-dated ASP.NET. 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.
  • oliwarner 3y ago
    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.
• viraptor 3y ago
  > 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?
  • deleted 3y ago
    [deleted]
  • reactordev 3y ago
    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.
    • wvenable 3y ago
      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.
      • gabereiser 3y ago
        Yeah, I agree. They didn't know it at the time but .Net and C# (their answer to java) would take over everything they did.
  • emodendroket 3y ago
    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.
• monalogue 3y ago
  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.
• thread_id 3y ago
  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.
• ksec 3y ago
  >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. HyperCard, Delphi, VB6, Flash.
  • antupis 3y ago
    Adding features to a popular tool later can make it messy. Building a tool where you can add features easily makes it elegant eg Lisp.
  • glenngillen 3y ago
    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.
  • Qwertious 3y ago
    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".
  • kalleboo 3y ago
    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.
• nrivoli 3y ago
  As someone that started in vb6 and then php in 2001, this.
• yoava 3y ago
  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...
  • marcus_holmes 3y ago
    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.
    • fendy3002 3y ago
      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.
      • yoava 3y ago
        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.
• seanmcdirmid 3y ago
  My understanding is that the target audience for VB.net was happy enough with C# instead, so it was a product without much of a user base.
• dkga 3y ago
  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.
  • ShadowBanThis01 3y ago
    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!
    • dkga 3y ago
      Thanks! Good luck to you too! 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).
• wkat4242 3y ago
  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
  • 3np 3y ago
    Electron seems successful regardless of lack of multithreading on the language level? I don't buy this one.
    • mike_hearn 3y ago
      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.
      • wkat4242 3y ago
        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.