Previously on ... In the previous article I wrote on how DrakoFlow came to life and why I believe a more modern UML and Diagram engine is needed. I also dove a bit in the design philosophy and how I conceived the DSL language that Drako uses. In this article I will dive a bit in the programming part of Drako. How and why certain technologies were chosen and some of the other challenges I faced while developing Drako. The tech stack From the very beginning I had a few objectives and must-have features, which without them I knew that Drako would have no chance of standing out. You should be able to create complex diagrams with ease A diagram should feel alive and interactive, not just a static image It should look and feel modern, not something designed in the 90s Drako should look and run the same regardless of programming language, IDE and OS Privacy is a first-class citizen These restrictions ment that when developing Drako, I needed to be able to create something cross-platform that will work both stand-alone and in the most popular IDEs: Visual Studio Code and IntelliJ Now came the challenge. I could make a complex application, compile it for different operating systems and developers would have to download it. Too much friction. PlantUML has less friction than this. I needed something that runs in the web browser, as well as in the IDE. Because of this, there was only one true solution. Luckily, web technologies have evolved a lot in the past years and modern web browsers can achieve far superior functionalities than they did int he past. TypeScript is a powerful programming language and I could create all the interactivity, design and functionality with it. There was one small problem I am a back-end developer. I worked primarily int he Java ecosystem for the past several years. I worked with Scala in the past. I worked for almost two years with Kotlin. But I never build in the JavaScript ecosystem anything not even remotely close to the complexity required by Drako. On the bright side, building Drako would prove to be an excelent learning opportunity. The role of a software engineer evolved as well in the past years, with companies constantly looking for people that are multi-talented and know a vast array of technologies. The tech stack Choosing TypeScript as the programming language had a major advantage. I could easily port Drako from the Web to the IDE. Visual Studio Code is build in TypeScript, so extensions for it naturally integrate in the IDE when using the same tech stack. IntelliJ also has support for web views, so building the extension for it would also be less challenging. Furthermore, I could reuse a lot of code. For such a piece of software, it is important to be able to hav the same render engines so that the diagrams look exactly the same fro one computer to another, regardless of the medium used. Having one programming language allowed Drako to work across systems in the exact same way since the same code is being used for both the Web editor, the stand-alone HTML player, the Visual Studio Code extension, the Intellij Plugin and even the Chrome extension. This also allowed me to hav a very light weight dependency tree. "devDependencies": { "@types/lz-string": "^1.5.0", "jsdom": "^22.1.0", "typescript": "^5.0.4", "vite": "^4.5.3", "vitest": "^0.34.6" }, "dependencies": { "lz-string": "^1.5.0" } No complex modules, no dependencies that bring on other dependencies, no risk of security vulnerabilities. Everything is build using TypeScript with no overhead. Conclusions... for now This article proved longer and less technical than I initially anticipated. I will have to leave more technical details regarding the implementation for the next one. In Part 3, I will present more on how I made the overall architecture of the application, how different render engines work and some of the challenges I faced during development. In the meantime, I encourage you to check out the Live Studio, download the extensions for your favourite IDE and let me know your thoughts in the comments!