A Complete History — and Why It Still Defines Serious Excel Work
By Hiran de Silva
The question “What is VBA?” keeps coming up — especially on social media, LinkedIn in particular. And every time it does, the same thing becomes painfully obvious:
Most people talking about VBA do not understand what it actually is.
This misunderstanding shows up everywhere:
- In posts asking “Will VBA die?”
- In comments claiming VBA is “dangerous” or “banned”
- In training courses that conflate VBA with “macros”
- Even in webinars where VBA is incorrectly introduced as “Visual Basic Application”
That last one matters more than people realise.
Because VBA does not stand for Visual Basic Application.
It stands for Visual Basic for Applications — and that small word for changes everything.
To understand what VBA means to Excel users today, you have to understand where it came from, what problems it was designed to solve, and what it was never meant to be.
This is that history.
Part 1: “Visual” — A Branding Marker, Not the Point
Let’s start with the word Visual.
Today, we’re used to Microsoft branding waves:
Power Query, Power Pivot, Power Apps, Power Automate.
The word Power signals a generation.
In the late 1980s and early 1990s, Microsoft did exactly the same thing — but with the word Visual.
Before Windows, computing meant DOS:
- 80 columns by 25 rows
- Fixed fonts
- No mouse
- No graphics
- No overlapping applications
Then came graphical user interfaces:
- Apple Lisa (1983)
- Macintosh
- Windows
The difference wasn’t subtle — it was revolutionary. Screens became visual: scalable, graphical, mouse-driven, multi-tasking.
Microsoft rebranded everything to signal this shift:
- BASIC → Visual Basic
- C++ → Visual C++
- InterDev → Visual InterDev
“Visual” didn’t add meaning to the programming model.
It announced the Windows era.
So while the Visual in VBA has historical importance, it is not the key to understanding VBA’s power today.
That comes next.
Part 2: BASIC — The Language Designed for Humans
BASIC is itself an acronym:
Beginner’s All-purpose Symbolic Instruction Code
It was created in 1964 at Dartmouth College by two professors who wanted a language:
- Not limited to scientists (Fortran)
- Not limited to business batch processing (COBOL)
- Not limited to engineers
They wanted something general, approachable, and human-readable.
BASIC was procedural:
- Step by step
- Line by line
- Explicit logic
It became the gateway language for generations of programmers — including Bill Gates.
Microsoft’s first product was BASIC.
But on its own, BASIC is not VBA.
To understand VBA, we have to step sideways — into macros.
Part 3: Macros — And Why Spreadsheets Never Needed Them
The word macro is one of the most misunderstood terms in Excel history.
Originally, macros were keystroke macros.
In the DOS era:
- No mouse
- No clipboard
- No copy/paste
Word processors recorded every keystroke:
- Characters
- Tabs
- Carriage returns
- Arrow keys
This came directly from electronic memory typewriters, which could replay stored keystrokes to reproduce documents exactly.
For word processing, this was revolutionary.
For spreadsheets?
Almost useless.
Spreadsheet work is not repetitive keystroke work.
You don’t type the same thing again tomorrow in the same place.
The only meaningful spreadsheet use case for keystroke macros was batch printing.
Then Windows arrived.
With:
- Mouse
- Clipboard
- Copy & paste
Keystroke macros became obsolete overnight.
But software vendors kept them — because removing features looks like regression.
This is the origin of the confusion:
- Macros survived
- Their purpose did not
And yet VBA arrived — not to revive macros, but to solve a completely different problem.
Part 4: The Real Revolution — Object-Oriented Software
By the late 1980s, software development underwent a seismic shift:
Object-Oriented Programming
The idea is simple:
- Encapsulate complexity
- Expose behaviour through properties and actions
- Let users manipulate objects without understanding their construction
An electric kettle is an object:
- Properties: temperature, capacity
- Methods: switch on, switch off
You don’t build the kettle.
You use it.
Windows applications were built exactly the same way.
Excel is not a grid of cells.
It is a collection of objects:
- Application
- Workbooks
- Worksheets
- Ranges
- Cells
- Fonts
- Validation
- Charts
- Connections
Everything you see — and many things you don’t — are objects with:
- Properties (settings)
- Methods (actions)
This is crucial:
VBA does not create these objects.
Excel does.
VBA is simply the language that allows you to manipulate them programmatically.
Part 5: “For Applications” — The Part Everyone Misses
This is the most important word in VBA.
For.
Visual Basic already existed as a standalone language.
What Microsoft did in the early 1990s was embed it inside applications:
- Excel
- Word
- Access
- PowerPoint
And tightly bind it to their object models.
That embedded version became:
Visual Basic for Applications
VBA is not a scripting add-on.
It is not a macro recorder.
It is not a legacy feature.
It is the native control language of the application itself.
Part 6: Why Recording Macros Misses the Point
Recording a macro today does not record keystrokes.
It records object manipulation.
That makes it useful for:
- Discovering object properties
- Learning syntax
- Inspecting formatting values
That’s how many of us learned.
But recording macros is not programming.
Programming requires:
- Conditions
- Loops
- Branching
- Logic
- Adaptability
Recorded macros break the moment anything changes.
Teaching “VBA” by stopping at macro recording sends learners entirely the wrong way.
Part 7: The Invisible Objects That Change Everything
Here is where VBA becomes decisive — and where no ribbon, formula, or macro recorder can follow.
Some of Excel’s most powerful objects are not visible.
Example: ADO (ActiveX Data Objects)
Not enabled by default.
Not accessible from the UI.
But fully part of Excel.
With just two objects:
- A Connection
- A Recordset
You can:
- Connect to databases
- Pull live data
- Push updates back
- Build true client-server systems
None of this can be recorded.
None of this is “macro work”.
All of it is VBA.
This is the architectural fork in the road.
Part 8: Why “Will VBA Die?” Is the Wrong Question
When people ask whether VBA will be replaced by:
- Power Query
- Office Scripts
- Python
- LAMBDA
They are comparing tools built for different purposes.
None of these were designed to:
- Manipulate application object models
- Orchestrate application behaviour
- Control invisible infrastructure components
VBA has no replacement — because nothing else does what it does.
And historically:
- VBA was licensed into thousands of Windows applications
- No successor language ever replaced it
The Bottom Line
VBA is not:
- A macro recorder
- A legacy curiosity
- A dying language
VBA is:
- The control layer of Excel
- The bridge between users and architecture
- The difference between hobby spreadsheets and enterprise systems
If you understand VBA properly, the effort is tiny — and the impact is massive.
That is why it still matters.
That is why it always will.
Add comment