All posts by Vjeko

Control Add-ins Supercharged – Frameworks

In the last example I put online, we’ve noticed that it was difficult to achieve a good separation of concerns in the front end if we are building UI directly through DOM. Apart from the fact that it’s very inefficient, manipulating DOM directly makes it very difficult to structure your front-end logic. You quickly realize you need a framework for that.

And here I come to a big fat point I want to make once again, that I made in my session, too: don’t build a new framework; pick one off the shelf.

The thing is, in the JavaScript world there are ridiculously many frameworks. This article on Hackernoon is an introduction into this total insanity: There are memes, jokes, comics, websites, even Alexa skills that address the fact that people keep creating new JavaScript frameworks all the time. Guess what? A tiny fraction of them generate any traction at all, and only a few stick.

And don’t get me wrong – I am totally for improving things; “the room for improvement is the largest room in the world” they say. But I am not quite convinced that building a yet another framework will benefit the posterity all that much. If you want to improve on what we have, most of the leading frameworks are open-source, contribute away.

As with previous (and future) posts in this series, there is a GitHub repo + branch that accompanies this blog post, and you can find it here:

(The featured image used under CC license from

NAV TechDays 2019 Goodies

NAV TechDays is simply the best NAV / Business Central conference there is. I can miss Directions, I can miss other events, but NAV TechDays – no way. There are few events which can match that energy, that community spirit, that enthusiasm, that top-notch deep-dive content. No, there are not few that can match it; there are none that can.

And then when you consider that they manage to attract ever more people to it, all that while publishing all conference content less than a week after conference is over – it just proves to you that the value of NAV TechDays is not in its content or its sessions. Being a part of NAV TechDays has always been an honor, and a pride, and a privilege.

No matter if you were there last week or not, you’ll want to access the conference materials, so here are the links:

Since this is my blog, I’ll also link directly to my Day 1 session about control add-ins development:

I’ll post the direct link to Waldo’s and mine Day 2 session about APIs as soon as it is available.

Day 2 content is now also available, so here’s the link to Waldo’s and my session about Business Central custom APIs, {ConnectApps}²:

Enjoy the content – and see you again next year in Antwerp!

Control Add-ins Supercharged – Separating concerns

If you know me, you know that I am obsessed with separation of concerns. It’s the core principle of good design, and good design is what I am always striving for.

The original Control Add-ins Supercharged example showcased how most of non-web developers (a category into which most of AL developers squarely fall) would develop a control add-in: just stuff everything into a single script, and all is fine. But it isn’t fine, if for nothing else, then because it can be done much better.

My next example is showing how you might attempt to solve the separation of concerns issue. The first step you may take is splitting the single script file into multiple files. For example, you may separate UI logic from state management logic, from AL-to-JavaScript interface logic. However, the example I am presenting today is yet an example of a good solution. It’s in fact a yet another “don’t do it this way” example. There are a few more wrong steps I want to intentionally take before I start solving problems for real, one by one.

The primary issue that my second repo (branch 01-split-js) addresses is that it separates front-end concerns as much as reasonably possible. However, as you will see in the repo description, once you attempt to separate logic into multiple JavaScript files, the separation of concerns isn’t really achieved, and there are a few files where you still have a mish-mash of UI, data, state, events, precisely those things that shouldn’t go together. The problem is, whatever way you attempt to solve it, you soon realize that the solution is just not good enough. As long as you are attempting to generate and maintain your UI using pure DOM, it will be impossible to achieve any decent level of separation of concerns.

So, head over to and check out the repo description (and content) and see for yourself why this approach is better than the previous one, but still far from good.

See you soon with the next example.

Control Add-ins Supercharged – Kicking off

Control add-ins have always been my passion. Not only because I’ve been working with JavaScript since 1996, and I could call it my mother tongue, but because I just love how they allow us to create amazing user interfaces. Business Central has made huge progress in terms of usability of the web client, however it’s still not the most user friendly thing out there, and performing some tasks may be tedious. Control add-ins help because they allow us to develop custom user interface over standard data and processes.

However, when building control add-ins, it’s not only about what we build, but also about how we build it. That was the central tenet of my NAV TechDays 2019 session named “Control Add-in Development Supercharged”, in which I wanted to show how control add-in development can be indistinguishable from modern web front end development. Because that’s exactly what it is – web front end development.

For my session I’ve prepared total of 36 demos. However, I realized just before the session that I won’t be able to deliver all of them, while also delivering all the theory I wanted to present. So I decided to post all of the demo source code for all 36 demos. However, this year I wanted to take a step further: I wanted to not only deliver the code as-is without any explanations, I actually wanted to explain all of it.

And this is what this blog series will be about – how to supercharge the control add-in development and make it as modern as it can possibly get. All with code examples and explanations. In the end, you’ll get a nice tutorial of modern control add-in development, that I hope will help you build your skills and take your control add-in development to the next level.

All code examples and explanations will be in in GitHub, and the first example is already there.

So, head to and check out the first example.

I won’t be posting code explanations here on my blog, I’ll merely be posting about the latest contribution to my GitHub repositories, and will add a line or two to explain what a particular repo or branch are about.

So, today: repository supercharged_01, branch master.

This branch introduces the “Simpler” control add-in and sets the stage for all further demos. It contains a very simple AL extension that contains a control add-in. The control add-in does not provide a feature-complete functionality, but merely showcases how it could be possible to simplify an otherwise less user-friend process. Keep in mind that the control add-in itself does not matter. What matters is its structure and how it was created.

In this branch, the control add-in is done in a “naive” way, how a typical AL developer without much experience in JavaScript or web development would develop it.

Stay tuned for (far) more content over the following days and weeks – it takes time to explain 36 demos in detail.

Codeunit Interfaces – this time for real!

There is a particular programming language feature that I’ve always missed in AL (and C/AL for that matter): interfaces. I’ve dreamt about it, then blogged about it, then finally created a feature request in Microsoft’s AL GitHub repository. My GitHub feature request caught quite some traction and became the most upvoted feature request in less than a day.

Now, I don’t know if or to what extent it was my submission that influenced Microsoft, but it doesn’t really matter – what matters is that it’s becoming reality. Last week at NAV TechDays, Microsoft has presented an amazing new feature that will be coming to AL pretty soon: interface object type. And it’s official, or at least as official as Microsoft’s keynote is, and you can check Microsoft’s demo yourself at

The feature is far more comprehensive than anyone could have hoped for, and it can be used for codeunits and enums, and in the future maybe even for a few more things. Who knows, or dares to dream. I dared, and I am pretty happy I did