Welcome to Office Zealot Sign in | Join | Help
The future of VBA looks a lot like VSTA. Or does it?

There is an interesting post in the VSTO forum about VBA/VSTO/VSTA. The question is: "Is VSTO/VSTA intended to replace VBA?"

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1461382&SiteID=1

The future of VBA and VSTO/VSTA's role continues to be a hot topic. Excluding VSTA for a moment, VBA and VSTO are two different tools. Though they have functionality that overlaps, one is not a replacement for the other. Never was, never will be IMHO. Thinking about them as tools, I tend to think of saws as an analogy. Saws are meant for cutting things. VBA and VSTO are meant for extending or automating Office. Although you can use various types of saws for cutting things, depending on what you're cutting, the effort required to complete your chore will vary dramatically with the type of saw you're using. Also, there are some materials that cannot be cut unless you have a saw of a specific type. We could argue about which type of saw VBA is and which type VSTO is, but that is tangential to my point, which is, they're two different types of saws.

I still haven't gotten into the nuts and bolts (as long as I'm talking about tools), of VSTA (sdk, dev center) . That said, from what I've heard, read, and seen so far, VSTA has the potential to be a future VBA replacement. It offers an IDE and a macro recording experience. From the surface, it looks like VSTA is capable of functionality germane to VBA. If you are a die-hard VBA person, VSTA is something to pay attention to.

While this is all related to the forum thread I mentioned at the beginning of this post, something mentioned in the post really jumped out at me. From the third message in the post (UPDATE: I added italics to emphasize the part that shocked me):

"I think the final decision about "replace" is still up in the air. There are some people in the Office team who believe power should be taken away from the user and given to IT and, by extension, to developers."

 Hopefully there aren't many on the Office team who think this. To those who may think this way, I'm sorry, but I think you are totally brain dead and out of touch with one of Office's core value propositions. I know that several large IT shops think they too, would like to prevent end-user development. The problem is that, in my opinion, many IT professionals have a hard time separating idealism from value, more specifically, the creation of value. Instead, most corporate IT shops are focused on cost reduction, which, in and of itself, does not necessarily create value.

End-user Office extensibility is an invaluble tool for tactical application development (small scale, departmental applications). I don't know of many corporate IT departments that are staffed adequately enough for enterprise development, let alone have the bandwidth to start bothering with tactical development. Removing end-user extensibility capabilities in Office, even substantially diminishing these capabilities would be a huge, huge mistake.

Before I close this rant out, let me end by assuring anyone reading this (all 5 of you, not including my wife), that the sky is not falling. It seems like some are paranoid that VBA won't work tomorrow or something. It will for the foreseeable future in my opinion. I'm just worried about the day after the foreseeable future.

 

Posted: Thursday, April 12, 2007 5:23 PM by hansen
Filed under: , , ,

Comments

dmoffat said:

<<"I think the final decision about "replace" is still up in the air. There are some people in the Office team who believe power should be taken away from the user and given to IT and, by extension, to developers."

Hopefully there aren't many on the Office team who think this.

>>

I think that most in the Office team DO think that way - I have felt this for several years.  Never moreso than since the beginning of this year.  

I am afraid though that this is a battle that is lost and we have to "get with the program".  The decision to drop VBA and move toward a "Professional Developer" future (which I think will simply mean the end of Office development over the next 5 years or so) has been made - there's no turning back right or wrong.  It's not our company - it's not up to us.

# April 12, 2007 9:36 PM

Jon Peltier said:

"I think the final decision about "replace" is still up in the air. There are some people in the Office team who believe power should be taken away from the user and given to IT and, by extension, to developers."

This is a shortsighted, narrowminded view. It's not much different than the laser focus the Office team had on the ribbon, foresaking the ease of development of the commandbar system in prior versions of Office. Maybe it's easier for a new user to find commandss on the ribbon, but the way the ribbon works makes me less efficient in Office 2007. It takes more clicking and dragging to get to the button I need, and I can't drag UI elements on screen to where I need them.

VSTO would be massive overkill for most of the Office solutions I build. VBA is a rapid development platform (ha ha, I made a funny, calling VBA a development platform) for producing easily deployed solutions.

# April 12, 2007 10:29 PM

XL-Dennis said:

The issue is that the large group of unofficially Excel developers in many corporates create unofficially supported Excel solutions.

Therefore they (the group and the solutions) does not officially exist.

The central IT-departments are the officially partners who discuss with Microsoft. After all, how can Microsoft discuss the future with a group that don't exist?

Different needs require different tools and why can't VBA, VSTO and VSTA co-exist?

Kind regards,

Dennis

# April 13, 2007 5:30 AM

maarten said:

> Different needs require different tools and why can't VBA, VSTO and VSTA co-exist?

It can, and -my- vision is that it will in the (near?) future. I haven't heard anything of this kind so far. I think VSTA still needs some work to do before they can kick this in.

My guess is when they finish the VSTA macro recorder VSTA is plugged into the system leaving VBA in place for backwards compatibility.

Later, when all the 'old school' VBA programmers retired VBA can be withdrawn without pain.

Just my $0.02 ...

I wonder how this looks when I look back in a couple of years to this comment :-)

-= Maarten =-

# April 13, 2007 5:34 PM

Simon said:

I'm with Dick on this completely.

I reckon client lockdown is coming, IT departments have been struggling to get control back ever since the PC destroyed their mainframe power play.  'Security concerns' is the ideal justification for the land grab. And 'software as a service' of course!

Yes user power is what made Office successful, but IT decides what gets bought, and they hate user power.

Had a big debate about this in Seattle - does IT hate Access or Excel most?

No one can look at the ribbon and say MS are giving power to the power user/developer, in fact the whole of 2007 offered little new for devs.

I'm surprised there has been no mention of a sandbox approach, maybe thats just too Java for MS, or maybe they are planning a major architectural shift that won't support rich client programability, in return for centralised management and controlled (SOX compliant) development.

Here is my prediction for 5 years:

MS office 2012 could be zero (client) install, purely web and browser based, and possibly client operating system agnostic (ie fully Saas'ed up). And probably not the dominant productivity suite. Or it might just be 2007 with an even bigger toolbar!

[as Maarten says ..when I look back at this comment..!]

exciting times - thanks for the heads up Steve.

cheers

Simon

# April 13, 2007 9:00 PM

hansen said:

Hi guys,

Good points. When I have more time, I've got several follow up thoughts. In the time I have however, I'd like to play this out a bit. Let's pretend for a minute that a VBA developer's worst dreams come true. Total lockdown, no more VBA.

Yet your clients still call you with the same story - very important business need, IT can't/won't help, can you help me? What do you see on the horizon to deal with this situation? Requirements - solve a business need using technology in a way that doesn't involve getting a non-cooperative IT department involved. The only ideas I've got in this type of scenario are pretty big hammers and not exactly what I'd call elegant solutions.

Also - Jon regarding VSTO - I don't think VSTO is overkill from a development perspective. If I could, I would always develop in Visual Studio using VSTO. The continued investment in VS makes going back to the VBE such a depressing event for me.

The overkill occurs during deployment - perhaps this is what you meant. As one of Simon's threads demonstrated, most of the Excel things a lot of us are doing are distributed to a fairly small number of people. The better the VSTO deployment story gets, the less of a problem this is.

The key is a no hassle deployment story that IT will "bless" and that can occur without incurring additional administrative overhead. From our "virtual" conversations I think we're on the same page on this. :)

Anyway, I've appreciated and will continue to appreciate all of the conversations I've had with you on this subject.

Thanks!

Steve

# April 13, 2007 10:24 PM

Simon said:

Steve

The answer is NO!

now what was the question?

I see a future where the business is told their needs would open unacceptable security/compliance holes and cannot be allowed.

The only option is a 6/9 month IT department mega project to deliver what IT think they should have.

The switched on CFO's will continue to use tools that support the actual business not some text book fantasy (contoso anyone?). That could easily end up being open source.

Cheers

Simon

# April 15, 2007 5:32 AM

dmoffat said:

It really comes down the fact that I am a "Spreadsheet Developer" or even an "Access Database Developer".  That means that the automation part of my story is secondary to the app.  

To tell a person that they will have to go back to the source code and recreate a deployment package every time they fix or change something that needs code completely goes against the reason why we use this technology.  It's because it is flexible and easily changed or fixed and then immediately usable.

Remember that we are talking about "application macros".

The problem seems to me that this new direction is being driven by people who are first and foremost "developers" not "users" (or they only listen to developers and IT managers worried about security and control).  That makes no sense to me.

That's why I am focusing on the "Applications" going forward because that's where the need is and where my "heart" is.

# April 15, 2007 7:04 PM

shasur said:

Though there will not be shelving of VBA in immediate future, I guess the development in future would happen 'outside' VBA. Already, Ribbons, Taskpanes etc are customized in VSTO (using .NET) or using XML.

# June 7, 2008 9:13 AM
Anonymous comments are disabled