Nah... why should it? It works and it does what it needs to do and more if you decide to hook into the Windows API or Mac’s API.<p>Want to parse 500mb structured XML file? Okay. Takes 3 seconds or so.<p>I had a lot of fun creating a full featured & modern look & feel application using Excel’s VBA runtime as my platform. Sure... I had to create everything from scratch, but learned so much while doing it. Kind of miss it at times since I now work with Java.<p>By the time I moved jobs, the codebase was +30k lines and even built an auto-updater, auto-installer, diagnostic, and AD type of authentication for the app, but most importantly saved tens of thousands of hours by automating reporting, analysis, detect errors, and querying that analysts, accounting, and some BI’s would do as part of their normal work.<p>VBA is great for analysts to work in Excel all day & every day who want to get into programming a little more, but want to have it apply directly to their daily work.<p>Now.... I wish Access does die...
It'd honestly be a shame if it did (but I understand the stresses that might cause it to happen).<p>Flash back to ~1986, and Bill Gates wrote an article for a Byte magazine special edition in which he described a unified version of BASIC implemented across a suite of GUI productivity applications.<p>Keep in mind, this is before Windows 3.0 and the Microsoft hegomony, before Word for Windows, (and Access, Project, Visio, etc.), before OLE/COM/ActiveX/IDispatch, and all of which are arguably necessary to complete the vision he outlined in the article. Ten years later, the vision of the article was realized, and thirty-five years later, it not only still exists, it's still useful across a huge cross section of computer users. (Despite the radical changes in the industry over that time.)<p>Microsoft has gotten a lot of flack over the years, and a lot of it has been earned, but the ability to identity a useful target state ten years in the future and rally an organization to achieve that goal is an amazing accomplishment.
I'm working on an excell addin right now. It doesn't use VBA (it uses microsoft interop libs for .NET) And I have zero interest in using VBA, but I will admit, it would have been much easier to do this project in VBA instead of C#.
Debugging would have been easier. I could debug inside the VBA code-behind instead of Attaching to the excel process in Visual Studio.
Deployment would have been easier. I could make an .xlam file and just give it to the users instead of A separate visual studio project that creates an installer on each build.
Excel interop would have been easier too(probably, I'm not 100% sure.) But using the Microsoft.Office.Interop.Excel libs are kinda hard. I don't have any good reference material for this lib, but for VBA, there are tutorials all over the internet for doing common things.
I mostly avoided VBA because I prefer the syntax of C#. I would imagine most people that only know VBA would have no interest in using C# to write office interop code, and I don't blame them. As for javascript, I doubt anyone that knows VBA well would have a hard time learning javascript, and if the codebehind for excel was slowly migrated to that, most devs would welcome the change.
Microsoft should rather provide a better path toward office automation rather than just frustrate users. As I have seen it, javascript isn’t even remotely close to the sort of integration that made the success of VBA. Like how can I save a javascript macro as a user? Javascript user defined function?<p>VSTA was a good attempt in its time, a mini visual studio integrated in office with VB.net and C# instead of VB6. That would have been cool.
As long as Excel is used by businesses, VBA will be relevant. Excel will probably continue to exist - and be supported and updated to ever newer versions - forever, so it stands to reason that VBA will probably also exist forever. Unless Microsoft goes bankrupt and Excel isn't picked up by another company. Which will also probably never happen.
Quote: "What Will Replace VBA? Short answer: JavaScript. "; and author follows with some logic about JS vs VBA using cross-platform.<p>Except this will never happen:<p>1 - M$ loves backward compatibility. It's what keeps their software being sold all these times. Worse case JS will have bigger user share and that's it, but M$ will never cut VBA out.<p>2 - Also majority of business is done on Windows. Cross-platform means absolutely nothing to corporations. The day that Windows dies that's the day VBA will die as well.<p>3 - JS as golden boy vs VBA? pleease. Best case scenario you're switching from one ugly boy to another ugly boy. Both VBA and JS are horrors. Don't believe me? Go read'em horror stories about JS cross browsers implementations. JS solved the problem of cross-platform only to open the problem of cross browsers. Good luck having Apple implement the same JS in Safari as their mortal enemy from Google in Chrome.
There's really two camps of VBA, the "application builder" and the "spreadsheet functionality" camps.<p>Application builders are trying to build interfaces for things that will run in a non-spreadsheet (i.e. non-reactive, not always-recalculated-to-be-consistent) mode. That's bound to be brittle, because that's not what Excel is for.<p>Spreadsheet functionality extending people OTOH write almost 100% what in ordinary programming is known as "pure functional style". Too often to write complex formulas in Excel (even something as simple as the Black-Scholes equation) people have to use multiple cells to keep things tidy and debuggable. You can use VBA functions for that. You can also write short loops to "solve for zero" with the bisection or Newton method etc. as long as they don't run for long. None of that interferes with spreadsheet semantics.
My first apps ever were extremely customized VBA Access databases. I already knew QBasic so doing VBA was easy. It affords a ton of power. I was able to create an entire interface and workflow easily and have everything contained within one Access file. The only downside was when multiple users wanted to use it (I think one had to save/close to let another in). For small things (a workflow tracking a university's scheduling changes) it can be great. Filemaker is a similar tool and both tools allow rapid development and prototyping. It might not be that useful to seasoned programmers, but to people who just want to get something done quickly, and especially for people who don't program much, it's an amazing tool.
Some points:<p>* I guess with Office365, JavaScript makes some sense, but why not just go VBA to WebAssembly?<p>* What about the Python rumors a couple years ago?<p>* I should probably turn my NecroVisualBasiCon library into A book. If you use the Access.Application library, right-click and toggle the hidden members, that COM object has a few extras like loading/saving objects from the VBProject that make e.g. git integration feasible.<p>* VBA does an outstanding job of providing 80% of what you want and no more.
Excel is one of the reasons I want to leave a career of Business Analyst behind.<p>Regardless of the process, the last step is always to dump the data into Excel and spend tons of time to create good-looking charts and tables. It usually takes me a full day to do that plus write wiki pages in Confluence (another pain point).<p>I just want to stay away from spreadsheet -> which means I need to get further from business and get a more technical position.
I don’t think it will. Microsoft might add another macro language but everyone is obsessed with backwards compatibility at MS and I highly doubt they would remove something as widely used as this. I used to be really annoyed by this as an engineer, but in contrast to Google’s culture where products are shutdown all the time I’ve started to come around that users should come first to avoid getting this reputation, even if it does become a combinatorial hell of different versions. I work at MS so I’m biased probably
Ha - good timing! I've been using VBA today and yesterday actually!<p>Often only a few times a year I use it now but when I do it I feel productive.<p>In case your wondering I has a previous Excel VBA Macro that I wrote for updating a SQL Server Database based on data in Excel. The macro first has to run checks against data in an IBM AS/400 Database.<p>I ended up having to pull out the macro to do a bulk update in an ERP. It was faster to do this then re-write in an modern language (especially since I work with the data in Excel first).
As far as I'm concerned, JavaScript (or at least JScript, MicroSoft's proprietary reimagining) replaced VBA 13 years ago. I haven't had to do anything programming with Excel for rather a long while, but way back in 2007 I was already writing JScript programs to automate spreadsheet tasks.
I hate VBA with a passion, but on the other hand it saves me many many hours every month through my ability to automate tasks. I would love for almost any language to replace it, but there has to be some kind of replacement if it goes away.
Between the spread of excel across businesses and MS focus on compatibility it seems rather unlikely. It is kinda ridiculous how much depends on VBA macros.<p>Weirder things have happened, but whatever would replace it, would create an industry overnight.
I don't own a Windows computer, but I've seen some incredibly interesting stuff come out of the VBA for Excel, which I sadly never have had a chance to learn.<p>Does anyone here have a side-by-side comparison of the LibreOffice BASIC vs the VBA?
> one of the easiest coding languages to learn if you don’t have a computer science background<p>Really? A language that has values passed by value, values passed by reference, references passed by value and references passed by reference? (And both late and early binding, and auto-boxing with all kinds of mysterious type-conversions, etc. and so on. And default properties.)<p>What makes it easy for beginners is the integrated environment, which is also what makes it difficult for more experienced programmers as it doesn't integrate with their version control system and other common tools.
It's weird to me that we haven't settled on a common, stable, purpose-built high-level language specifically for business logic. Stuff that doesn't change much, that doesn't need to concern itself with the platform, only the business. That code should be portable to whatever shiny new underlying system gets invented; why does it keep having to be re-expressed every few years?<p>The situation is much better (though still far from ideal) when it comes to data. Everything knows how to use CSVs. Relational databases, from a schematic perspective, really haven't changed terribly much in decades. NoSQL came around but that was really just an alternative option; you don't see everyone scrambling to migrate their SQL data to Mongo. SQL isn't quite a standard, but it would be dramatically easier to migrate an ancient MS SQL database to Postgres than an ancient COBOL codebase to Java.
Well judging from the fact that my first computer my father bought back in 1988 Amstrad CPC 6128 is still alive and kicking with very active community and more development tools than it ever had, I think its safe to assume that software never dies. Only thing it takes is a small dedicated community and it can last for centuries. Partly because father and mothers infect their sons and daughters with their passion for the technology and the the loop never ends. What else never dies is necrophilia in software , apparently people are addicted to declaring software dead prematurely. Oh and of course clickbait because some people are desperate for views. It started with Java back in to 2000s and still going strong. I am not fan of Java but I am also not that delusional to declare Java dead. So no I think its pretty safe to assume VBA is not going anywhere.
JavaScript, for better or worse, is probably the most widely used language out there, by nature of being the language in the browser. The push for cross platform, mobile and web with frameworks that leverage it have leaned in on and expanded JS greatly. The engines are highly optimized (more than any other scripting language as feature rich), cross platform and nearly ubiquitous.<p>VBA just isn't. Anything not JS is just about a non-starter for the web versions of these applications, and that's where things are headed. If you're on Linux it's probably the only option in the space for a while.<p>JS is pretty decent, the ecosystem is massive, and you have the option of TypeScript if you want something more formal. Guessing everything MS offers will actually be written in TS, just consumable in plain JS or TS.
I still think that original Excel macro language was better than VBA. It essentially excel's formula language extended to be imperative language and represented as sheets. At the same time it was user friendly and had kind of lisp feeling.
If there's one thing I've learned in 15 years of IT work, it's that once business users have discovered a thing it will never die.<p>No matter how outdated, shitty, useless, etc. it may be, some jackass has built their entire workflow around it and has more power than you to prevent that from ever changing.
I have a soft spot for VBA. Programming macros in Excel was my introduction to programming; it made me realise how simple it can be to automate a repetitive process and save yourself literally hours a day with just a small investment of time.
VBA was my entree into professional programming and I'm not ashamed to admit it. I enjoyed using BASIC to solve my own problems (games) as a kid, but VBA showed me how fun it was to solve other people's problems.
VBA will "die" (in the same way fortran is dead) when people can record macros in another language, and then keep those macros baked into xlsm files.
Hopefully not. It's withstood the test of time, why replace it with something trendy?<p>Edit: Yes, Python has also withstood the test of time... as a scientific and web language. There's no reason to assume that it could replace VBA as a spreadsheet automation language used by relatively non-technical business folks.
With ExcelDna, which is open source .NET library, has very fast C API and rich COM API, I don't know why one would use VBA for new dev. One commenter here said debugging of interop libs is hard, but my experience is quite opposite - it works nice from Visual Studio with normal F5.
VBA was the first environment/language that I professionally used at the beginning of my career. It was so efficient to navigate in an environment that had 1000s of Excel files. I did not realise how fast I could develop the things needed to be done.
If they killed it today, then if VB6 is anything to go by, it will still be chugging along unconcernedly in 2050.
VBA was a huge component of VB6, so it would be relatively easy ( I think) for MS to produce a 64 bit VB7.
Depends on what you're using VBA for, it is for Excel data processing or analytics. IMO it will likely die out, there are much better data solutions on the market for data analytics that use python.
I can relate to every single point he makes about how great VBA is compared to other languages and how annoying it is that MS has basically abandoned it in favor of JS.
this will definitely will be a huge relief for many sys-admins in windows environments...
I think javascript isn't a bad choice since ms isn't as ignorant as some years ago, when it comes to new standards.
I wish Microsoft would just make a CSA already, c# for apps. This would be a huge win on so many fronts that I am shocked they havent done it already.<p>Increase C# mindshare.<p>Better Lang means a better ecosystem.<p>It's a free win.<p>It's also an ad for office. I started appreciating Outlook and Excel once I had vba filters and maps
VBA won't "die" anytime soon for the same reason Office or VB/VB.NET are still around. Legacy code. Almost every office in the US and probably around the world has VBA code in one of their office products ( excel, access, etc ).<p>Google spreadsheets was going to kill Excel, C# was going to kill VB, Sql Server was going to kill Access, etc. Look at how that turned out?<p>Maybe in an ideal world, but in the real world, there is a ridiculous amount of time, money and resources invested in VBA code. These sunk costs are very meaningful to corporations and governments and as long as corporations and governments give microsoft huge stacks of money, microsoft is going to keep VBA around.