DEV Community

Thomas Emad
Thomas Emad

Posted on

How AST Powers Modern Frameworks — And a Wild Idea for Blade

Banner

We talked last time about Blaze and how it makes improvements — and if you think about it, we said it relies on the concept of AST (Abstract Syntax Tree).

This is the same approach that Vue.js, Svelte, and Angular use. So let's dig into it.


Why Frameworks Exist

The whole idea starts from wanting a different way to write code than the traditional approach — just to keep things cleaner and more expressive. That's basically the core purpose of frameworks.

Since the code you write isn't understood directly by the browser, it goes through a compile step, which transforms it into optimized JavaScript. During compilation, the AST is created — a Tree that represents and simplifies the structure of your code.

The AST concept applies to almost everything in the template, even something as simple as a <div>.


The 4 Stages of AST Processing

1. Lexical Analysis (Tokenization)

The code is broken down into an array of tokens — small meaningful units the compiler can walk through one by one.

For example, a function call like isAdmin(1) becomes:

type: function,    value: isAdmin
type: punctuation, value: (
type: int,         value: 1
type: punctuation, value: )
Enter fullscreen mode Exit fullscreen mode

That's it — just a structured array of everything in your code, split apart and labeled.


2. Parsing

The token array is used to build a Tree — this is your AST. Each node in the tree represents a piece of your code with its full context and relationships.

If you want to see what an AST actually looks like, check out AST Explorer — it's a great visual tool.


3. Optimization via AST Traversal

This is where the magic happens. The compiler walks through the tree branch by branch — a process called AST Traversal. Think of it like a journey through the structure of your code.

One common traversal method is Depth-First Search (DFS), which itself has variants:

  • Pre-order → Root → Left → Right
  • In-order → Left → Root → Right
  • Post-order → Left → Right → Root

During traversal, the compiler makes decisions like:

  • <h2> with no dynamic content? → Mark it as static, skip it in re-renders
  • Something reactive or data-bound? → Attach a flag so it gets tracked and updated

This is what allows some frameworks to reduce or eliminate their reliance on the Virtual DOM entirely, while others (like Vue) still use it — but in a smarter, more targeted way.


4. Code Generation

Finally, the optimized AST is used to generate the actual JavaScript that runs in the browser. The framework then uses this output to construct the real DOM efficiently.


The Wild Blade Idea

Here's the part I find genuinely interesting — and maybe a little ambitious.

What if we applied this entire pipeline to Blade (Laravel's templating engine), properly — not just as a performance trick, but as a real compilation layer?

At that point, it wouldn't just be about performance. We could build on top of it:

  • Morph diffing — compare a Virtual Tree against the Real DOM and do surgical updates instead of full replacements
  • Real-time attributes — tag an element so the browser sends a request to the server, and PHP responds with only the changed data
  • Potentially a much lighter alternative to pulling in a full JS framework for dynamic UI

Is this basically what HTMX does? Kind of. Is the Morph piece already in Alpine.js? Also yes. But applying it natively at the Blade level, with PHP-aware compilation — that's a different story.

I don't know exactly how to implement it. Maybe it ends up in the bin like most late-night ideas. But I think it's worth writing down.


Further Reading

Top comments (0)