Skip to main content

Why Don't Browser Dev Tools Understand Your Code?

· 5 min read
Steven Schkolne
Daniel Worthington

The browser is almost the perfect development environment. It’s amazing how you can poke around and inspect your app while it’s running. But there’s a catch. What you see is not nearly as deep as it could be. The browser operates on the DOM which is often miles away from your actual code.

The Peak Web Dev Experience

Could things be different? A cursory glance at native development environments indicates there’s more to be had:

  • Xcode (before SwiftUI) allows you to build your UI visually with Interface Builder. Outlets and actions tightly interweave your app’s code with your UI.
  • Windows Form Builder has historically done the same thing for Windows apps. You don’t have to manage UI code, just build it!
  • Game engines like Unity and Unreal offer perhaps the most powerful embodiment of this paradigm. While playing your game, you can stop, change how things look, and keep playing. The scene you edit is similarly tightly coupled with traditional hand-written code, but the power of Unity goes beyond editing. By allowing pause-and-inspect, you can get a deep understanding of how your code functions while it’s running.

Browser Tooling Today

It’s incredibly powerful to link code with a visual dev tool. In the browser it appears at first glance we have something like that, until we dive a bit deeper.

  • Chrome DevTools reveals your app’s structure through its inspect mode, but in the language of the DOM. When using contemporary JavaScript frameworks, the DOM is often far away from your code. Source maps may help get to your scripts, but not to the JSX that powers the layout you see.
  • React Developer Tools connects the DOM to JSX, but with a lot of errant virtual DOM entities that aren’t part of your code, and a relative lack of functionality. It’s a far cry from tools like Unity for revealing what’s driving the experience.

Beyond the gap between browser dev tools and your code, there’s another factor, and that is editing. If you make changes with these tools and like what you see, you’re responsible for mapping the result back to code correctly as an additional step.

Didn’t We Try That?

You may be familiar with a product that was launched in the early days of the web called Dreamweaver. In this environment, developers could seamlessly switch between visual design and real code editing.

As the web grew up, JavaScript started to govern the structure of complex sites and Dreamweaver couldn’t keep up. Dreamweaver showed that design-to-code could work well for basic sites, but left developers with the sentiment that, when it comes to more complex sites and code-to-design, “it can’t be done.”

Another famous example of design/code integration is Flash. Flash succeeded in blending code and visuals, creating a fond memory for many developers. Along with lack of iPhone support, Flash didn’t scale well beyond the borders of the box within which Flash “movies” lived. As JavaScript performance increased and HTML5 matured, Flash faded into obsolescence.

A “Scene File” for the Web

Remarkably, we have the key to unlocking this more powerful way to develop for the web. It’s sitting right underneath our noses, and it’s called JSX. This technology is exactly the right abstraction for expressing an app’s layout intertwined with functional code.

In environments such as Xcode (pre-SwiftUI) and Unity, this abstraction is called a “scene file”. In these worlds, it is literally a file (.xib and .unity files respectively) where the UI is represented. The guts of such files are XML-like, just like JSX.

Putting the Pieces Together

This observation that JSX is the “scene file” for sophisticated web apps is not enough, there are remaining questions. How could a dev tool unlock JSX in a way that makes development more fun and productive?

At MightyMeld, we’ve been answering that question by building the dream. Surprisingly, the web is an even better place than native apps for this kind of code-aware visual dev tool:

  • Since JSX lives within code, you don’t have to decide which parts of your codebase are visually editable, and which parts are not. You can start in either mode, and hop back’n’forth as suits your working style.
  • Hot reload is amazing, so the “pause the game, edit it, and keep playing” experience is way stronger than an environment like Unity where you often have to copy your changes, stop the game, paste and rebuild.

There’s a lot more to the story, but the short version is that this underpinning is a solid one for a more code-aware browser-based dev tool.

Browser Dev Tools That Understand Your Code

Building visual dev tools that harmonize with web coding has been a historical challenge with notable attempts and obstacles. JSX promises to take us to new heights of fun and productivity while building web apps. It’s an exciting time for web developers. Let’s take our tools to yet the next level.


This post is based on a talk that Steven gave at Conf42 JavaScript 2023. Slides and video available here. Made much better by further collaboration with Daniel 💪.