I use Extensions and Visual Studio Code in my daily life. Or at least for a while, nowadays it’s more something in my weekly life. I try to avoid them when I can.

Not because they are bad or evil but because they slow down my productivity, and because I have legacy software.

Almost everyone I talk to agrees that programming extensions is slower and more clumbersome than C/Side. Not just the first few weeks.

The Differences

When Extensions were first shipped I was stronly against the way they were architected. Microsoft simply slapped to existing pieces of technology together with a PowerShell sauce and sold it as the best thing since sliced bread.

It was even sold as being the only way to have decoupled code.

This, my friends, is where I think it went wrong.

With C/Side it is possible to have decoupled code, but it is not possible to have decoupled tables and pages. Only if you keep the delta files, which is the artifact Microsoft used as one of the ingredients for Extensions.

If Microsoft would support Table Extensions and Page Extensions in C/Side and if they would disable access to existing objects C/Side would have the same technical capabilities as Visual Studio Code.

It would in fact be capable of doing much, much more… I’ll get back to that.

Visual Studio Code has native Git integration. True. I’ll give you that. I’ve used it a lot but I have yet to find the true value compared to exporting text files from C/Side and moving them to Git manually.

With Visual Studio we cannot debug a live system, or look at an existing object. There is no solution for XMLPort Extensions or Report Extensions nor can you simply replace existing objects with new ones.

Legacy & Monoliths

The true difference between Visual Studio Code and C/Side is how the solution is managed. Both tools have intellisense and can handle thousands of objects. If you create and maintain an Angular project in VSCode you’ll see that your project easily contains more objects than you can oversee.

Which is where the value of C/Side is imminent. Where Visual Studio Code expects you to only edit a handful, maybe up to 100 files, C/Side allows you to easily navigate accross every file in the solution and change everything.

Visual Studio Code is designed for modern decoupled applications that take dependencies on packages.

This is where we get challenged because NAV, Business Central or Navision (I don’t care how you call it) Is not a decoupled application. It’s a monolitical dinosaur that requires years to master and was never designed with decoupling in mind.

ISV Solutions

Most ISV solutions are also monolitical applications because we took the habbits from Microsoft and designed our solutions in an identical way. Microsoft must do it right, so let’s do it like they do.

WRONG!

I don’t blame you for making that choice. I did the same and it is the very reason I decided to keep working in C/Side. The solution I work with every day has over 2000 objects. Even though these objects are not depending on the Microsoft objects it is very hard to manage them in Visual Studio Code. You actually realise how smart object numbers are and how easy they make C/Side work once you don’t have them anymore.

Visual Studio Code & Decoupling

VSCode is designed for smaller, decoupled projects. You can work with multiple projects open at the same time, but they work best when separated.

To get the most out of the VS Code experience you need to refactor your solution in multiple extensions and figure out the dependency schema.

Which is a shitload of work and who has time for that.

The Other Difference…

There is another difference between Visual Studio Code and C/Side that makes it valid for Microsoft in my opinion to keep C/Side alive.

Imagine the scenario a few paragraphs ago. Imagine C/Side with a Table Extension object type and a Page Extension object type. That would make both environments identical rithg?

No… actually it would give C/Side a huge competitive advantage to Visual Studio Code.

Financials Object Files…

Aka Fobs… Tell me how many times you only change two objects in a database that has 8.000 objects or more. Or just one.

How do you ship them? Exactly, you just export the file using C/Side.

If my solution with 2.000 objects were one big extension shipping small changes would become a nightmare. We all have a DTAP system but how often do you make a fix in Test so the tester can continue? How many of you have a Hotfix database? More scary; how many of you just make a change to a report or a page in Production?

Microsoft Keep C/Side Alive!

For Microsoft to make Business Central in the Cloud succesful they don’t need to do away with C/Side.

The new generation of Cloud developers (if they exist, I only see NAV partners jump on it) never see C/Side.

On the other hand, if Microsoft would move base-NAV to Visual Studio Code we would all take a huge step back.

Navigating in 5.000 or 10.000 file project in Visual Studio Code is a freaking nightmare and compiling and shipping the whole monolith for one report would make customers run away to the competition in a fraction of a second.

Great, so now what…

So Mark, you say Microsoft has to keep C/Side because of the way NAV is designed, because it is not decoupled. Yes, that is what I am saying.

And this is where it becomes freakingly dangerous what I am about to say.

Let’s be the devils advocate…

If you are forced to refactor or redesign your monolithical applications into decoupled microservices, why would you per-se do it in AL?

That my friends, is where and how we will continue this blog series by talking about things like the API, CDS, PowerApps, Asp.Net Core and Angular.

Yes, I choose to stay with Microsoft, but you are correct if you think you might as well switch to any other framework as long as it is a web-framework. The latter is important if you want to embed with Business Central, the best cloud solution out there today.