DEV Community

Andrea Debernardi
Andrea Debernardi

Posted on

From VS Code to Zed: building a FreeMarker extension because I needed one

From VS Code to Zed: building a FreeMarker extension because I needed one

A few months ago, I switched from VS Code to Zed.

Not because VS Code is bad — it’s still an amazing editor — but because it slowly became… heavy.

My setup had turned into a Frankenstein monster of freemium extensions, background processes, upsells, and “just one more helper” that somehow made everything slower.

My VS Code setup: I feel thin, sort of stretched, like butter scraped over too much bread.

I wanted something:

  • fast
  • open-source
  • opinionated
  • boring in the best possible way

Zed checked all the boxes.

Until I had to start working with FreeMarker.


FreeMarker is still very much alive

If you work in Java or enterprise environments, you already know this.

FreeMarker isn’t trendy.

It’s not on Hacker News every week.

But it’s everywhere.

In my case, I’m using it in a project that integrates Keycloak, where FreeMarker templates are still a core part of the customization flow.

So yes — FreeMarker is old.

And yes — it’s still critical.

Which made this part a bit painful:

👉 Zed had no FreeMarker support.

No syntax highlighting.

No understanding of directives.

Nothing.

Fine, I’ll do it myself


The “fine, I’ll do it myself” moment

Zed is fast enough that once you get used to it, going back feels… wrong.

So instead of switching editors again, I thought:

“How hard can it be to write a FreeMarker extension?”

(Last words before opening a tree-sitter grammar.)

I already knew that:

  • Zed uses tree-sitter
  • Syntax highlighting is grammar-driven
  • Extensions are lean and explicit

I also had a starting point:

a FreeMarker extension for VS Code.

The idea was simple:

  • reuse what I could
  • adapt what I had to
  • learn the Zed extension model along the way

With some help from vibe-coding and a lot of trial & error, I started porting it.


The actual journey (a.k.a. tree-sitter reality check)

Some things were easier than expected:

  • Zed’s extension model is refreshingly clean
  • Tree-sitter forces you to think properly about structure
  • No magic, no hidden layers

Some things were… not:

  • FreeMarker syntax is flexible in annoying ways
  • Directives, interpolations, nested expressions
  • Edge cases you only notice after breaking everything

Porting from VS Code wasn’t a copy–paste job.

It was more like translating between two different mental models.

But honestly?

That’s what made it fun.

The actual journey


The result: early, but usable

The extension is live here:

👉 https://github.com/debba/zed-freemarker

What it supports today:

  • FreeMarker syntax highlighting
  • Directives
  • Interpolations
  • A solid base for further improvements

Is it perfect? No.

Is it production-grade? Not yet.

Is it good enough to work daily without hating your editor? Absolutely.

And for an editor like Zed, that already feels like a win.


Thoughts on Zed and niche tooling

Zed feels like an editor for people who:

  • enjoy understanding how their tools work
  • prefer fewer abstractions
  • don’t mind building missing pieces themselves

Writing this extension reminded me of something important:

Open source doesn’t move forward only with big features —

it also grows through small, boring, niche tools that solve real problems.

FreeMarker isn’t cool.

But someone still has to maintain it.

The actual journey

What’s next?

Possible next steps:

  • better grammar coverage
  • error handling
  • maybe an LSP in the future (no promises)

If you:

  • use FreeMarker
  • use Zed
  • enjoy hacking on developer tools

Feedback, issues, and PRs are more than welcome.

Sometimes the best extensions start with a simple need:

“I just want my editor to understand this file.”

And that’s exactly how this one was born 🚀

Top comments (0)