Overview of Syntax 1008: Diffs, Trees, and VS Code 2.0
Wes and Scott talk with Alex Sexton and Amadeus DeMarti about the primitives they’re building at Pierre Computer Company for AI-era developer tools: ultra-fast diff and tree components that can power code review, file navigation, and other UI layers in products like OpenCode, Codex, and Claude Code-style apps. The episode focuses heavily on how they make huge code views feel instant, even when rendering massive repositories and gigantic diffs that would normally choke GitHub or standard web apps.
What They’re Building
Diffs and Trees as reusable primitives
- Diffs: a highly optimized code diff viewer for reviewing changes at scale.
- Trees: a file-tree/sidebar component designed for extremely large repos and deep folder structures.
- Both are built as web component-wrapped vanilla JavaScript primitives so they can be used across frameworks.
- These tools are part of a larger push toward what feels like a “VS Code 2.0” for AI-driven coding workflows.
Why these matter now
- AI tools are generating massive volumes of code and repo changes.
- Review and navigation UIs need to be fast enough to handle:
- thousands of repo creates per minute,
- huge file trees,
- enormous diffs,
- code review flows that don’t assume a human manually typed every change.
Performance and Rendering Deep Dive
Why GitHub-style rendering struggles
- The guests explain that code UIs are inherently expensive because they contain:
- tons of nested spans/tokens,
- large DOM trees,
- syntax highlighting,
- scrolling and resizing pressure.
- React-style rendering can be overkill for static text-heavy views, because it adds extra work for content that often doesn’t need frequent updates.
Their main performance strategy
- Lean into what browsers are already good at:
- plain HTML/CSS rendering,
- browser-native scrolling,
- off-main-thread work when possible.
- Virtualize at the smallest useful granularity:
- diffs are virtualized per line / per hunk,
- trees avoid building data for items that aren’t visible.
- Use sticky positioning tricks to prevent blanking even when JavaScript can’t keep up with fast scrolling.
- Keep scrolling native rather than fully abstracting it away, so the experience feels smooth and familiar.
Handling huge data sets
- The components are designed to render content like:
- millions of files,
- 8 million+ lines of code,
- 150MB+ diff files.
- They emphasize that at this scale, even the browser itself has limits, so the goal is to make the UI degrade gracefully instead of freezing or crashing.
Technical Challenges and Solutions
Syntax highlighting and wrapping
- Syntax highlighting is pushed off the main thread using workers to avoid jank.
- The system often renders plain text first, then upgrades to highlighted output as soon as the worker finishes.
- Tree items are easier because line height is mostly fixed.
- Diffs are harder because line wrapping changes height dynamically, so they:
- estimate heights first,
- render visible chunks,
- measure actual height after render,
- cache those measurements,
- correct scroll position when needed.
Search/find limitations
- Native in-page find is problematic at this scale.
- They don’t fully support browser find in these giant virtualized views because:
- the browser can’t reliably search content that hasn’t been rendered,
- huge diffs can crash the browser during native find anyway.
- They’re exploring worker-based indexing and custom search interactions instead.
Scroll correctness
- They spent a lot of effort making sure the view:
- never blanks,
- survives rapid “fling” scrolling,
- stays stable during resize/zoom/scroll-mode changes.
- A key concept is maintaining an anchor point so the same content stays in view even when layout mode changes.
AI and Benchmarking Workflow
AI as a performance assistant
- Amadeus describes using AI as a rapid prototyping and benchmarking partner:
- generate experimental code,
- run performance tests,
- inspect Chrome profiler output,
- iterate until benchmarks improve.
- One example: a merge-conflict parser was reduced from about 20ms to 0.5ms after AI-assisted optimization.
Testing methodology
- They rely on:
- mitata for statistical benchmarks,
- Chrome profiler data,
- custom phase markers in code for higher-signal measurement,
- PyAutoResearch / auto-research style loops to repeatedly run scenarios.
- Their key advice:
- measure one thing at a time,
- make the benchmark fast,
- give the model enough data to evaluate its changes accurately.
Practical takeaway
- A lot of their speed gains come from:
- splitting logic into small pure functions,
- focusing on hot paths,
- aggressively testing only what’s visible or necessary,
- letting AI brute-force optimizations after a strong testing harness is in place.
Web Components, SSR, and Framework Interop
Why web components
- They use web components mostly as:
- a shadow DOM boundary,
- a way to avoid style collisions,
- a framework-agnostic integration layer.
- This lets the components work in environments using:
- React,
- Preact,
- Solid,
- Vue,
- or vanilla JS.
SSR and declarative shadow DOM
- A big requirement is SSR support, because the components must render immediately and still hydrate correctly.
- They use declarative shadow DOM to combine SSR with web components.
- They also use slots so apps can inject things like:
- comments between lines,
- custom context menus,
- interactive children rendered by another framework.
Business Model and Open Source Strategy
How the company makes money
- Code.Storage is the paid B2B product:
- a Git-like backend for AI agents,
- built to handle massive scale,
- an alternative to pushing everything into GitHub when GitHub API limits become a problem.
- The diffs and trees libraries are part of the broader ecosystem:
- open-source primitives,
- helpful for adoption,
- useful for companies that need scalable code-review UI.
Why they open source the primitives
- It helps establish trust and utility in the ecosystem.
- Many companies want the same high-quality code review UI, even if they can’t adopt the full Pierre product.
- Open-sourcing the building blocks makes it easier to support more teams and workflows.
What’s Next
Editing is the next big request
- The most common feature request is editing diffs directly.
- Right now there are still partial workflows like accept/deny changes, but full editing is on the roadmap.
- The guests hint that it’s coming, but without a release promise.
Possible future primitives
- They joke about the next obvious primitive being textarea.
- The idea is that once you solve diffs and trees at this level, other foundational editor-like primitives become natural next steps.
Sick Picks
Amadeus’s pick
- A 40% custom ortholinear keyboard.
- He likes:
- home-row-based layers,
- tiny form factor,
- no awkward finger stretches,
- the “perfect grid” feel.
Alex’s pick
- A Flip Dot display project he’s building for wall art.
- It’s a DIY microcontroller-driven display with magnetic flip dots, and he’s still finishing the physical setup.
Key Takeaways
- Modern AI coding workflows need new primitives, not just better apps.
- Rendering huge code views is less about “making React faster” and more about rethinking browser rendering from first principles.
- Virtualization, estimation, caching, workers, and SSR-aware web components are the core tools behind these fast experiences.
- Their approach is a good example of building deep infrastructure for a specific, hard problem instead of layering more abstraction on top.