One of the biggest misconceptions I see pop up regularly among developers who start working on the new Umbraco “Bellissima” backoffice for the first time is that they think you need a lot of scaffolding and an entire build pipeline to extend the Umbraco 14+ backoffice.
This makes it seem like arbitrary extensions to the backoffice are very hard, especially for backend developers who aren’t into npm and such.
I’m here to tell you that you don’t need to use Lit, Vite, or TypeScript if you don’t want to.
Why do so many developers think you need all that scaffolding?
For the most part, this is a documentation thing. Umbraco itself uses Lit, Vite, and TypeScript in its codebase, and as a result, most examples in the documentation are based on Lit. Also, the [Setup your develop…
One of the biggest misconceptions I see pop up regularly among developers who start working on the new Umbraco “Bellissima” backoffice for the first time is that they think you need a lot of scaffolding and an entire build pipeline to extend the Umbraco 14+ backoffice.
This makes it seem like arbitrary extensions to the backoffice are very hard, especially for backend developers who aren’t into npm and such.
I’m here to tell you that you don’t need to use Lit, Vite, or TypeScript if you don’t want to.
Why do so many developers think you need all that scaffolding?
For the most part, this is a documentation thing. Umbraco itself uses Lit, Vite, and TypeScript in its codebase, and as a result, most examples in the documentation are based on Lit. Also, the Setup your development environment article talks about setting up TypeScript and Vite, which reinforces that impression.
You might think it’s just a matter of better documentation, and although I agree that the docs could improve, the problem is actually a bit bigger.
A well-designed (and overly flexible) architecture
The funny thing is that biggest problem is that the backoffice architecture is really well designed. That sounds like a contradiction, but hear me out.
The backoffice is built to be flexible, extensible, and framework-agnostic. Because of this, there are actually very few hard requirements for extending it.
- UI extensions (like property editors, buttons, or workspaces) must be web components.
- Other extensions (like repositories or stores) must follow the requirements of their extension type.
- And lastly, you need an
umbraco-package.jsonfile to register the extensions.
But that’s practically it.
This means that as long as you follow these basic rules, you can create your extension however you want. Yes, Umbraco uses TypeScript for their code, Lit for its web components, and Vite to bundle it all, but you don’t have to. You can use your own framework and bundler if you like, as long as your bundles use the ES module syntax.
No scaffolding? No problem
You can also use plain JavaScript and skip any compilation or bundling entirely. As long as the requirements are met. That means no npm packages, no build scripts, and no scaffolding.
So, there are many ways to go about this. And that’s what I mean when I say that the backoffice architecture is both a blessing and a curse: there are so many possibilities that it’s impossible to document every one of them.
That said, I also believe the documentation could do a better job at showing this flexibility. I’m part of the Umbraco Documentation Community Team, and I try to spread the message of this blog wherever I can.
When to use what
There’s no absolute right or wrong, but here’s my opinion:
- Use plain JavaScript for small and simple things, like a block view or a small Tiptap extension.
- For anything bigger, it’s worth investing the time to use TypeScript — it elevates the quality of your code and prevents bugs. Especially if you’re a C# developer, you’ll probably appreciate the strong typing.
- Once you’re already using npm and build scripts, it’s just a small step to introduce Lit and bundle it with Vite.
In the end, it’s not that hard. I’m primarily a C# backend developer, and yes, the learning curve exists, but I can honestly say that the quality of my packages has improved significantly since adopting these tools.
I’d also recommend going with Lit for elements. The Umbraco source code and most examples use it, so unless you have a specific reason not to, it’s a good default.
Lit is lightweight and removes the most annoying parts of writing web components by hand.
Want to learn more?
Because I don’t want to bloat this blog with tons of examples, I’ll wrap up with a few useful links if you want to dive deeper:
- I recently rewrote the documentation on the extension registry, which hopefully makes things a bit clearer.
- For the Umbraco Autumn Contribution Challenge 2025, I created an example showing how to register a custom condition to an existing extension. The example illustrates three different approaches (with the same result): vanilla JavaScript, TypeScript without bundling, and Lit + Vite. You can find it on GitHub.
In short: you don’t need all the scaffolding to extend Umbraco’s backoffice, but knowing how to use it can make your life a lot easier.