Reading code at 10 — what view-source teaches.

How a generation learned the web.

If you ask a working web developer who started before about 2014 how they learned to make websites, a surprising number give a version of the same answer. They saw a page they liked. They right-clicked. They picked View Source. They read what was there. They copied a piece into their own file and changed it until they understood it. The page was the lesson.

This wasn’t a course of study. It was an environmental property of the early web: every page was readable. The browser shipped with a feature that let any visitor see the markup that produced what they were looking at. The intent was technical (debugging, learning) but the effect was pedagogical (the web taught itself).

That property was load-bearing for the careers of a lot of people who are now senior engineers. It wasn’t the only way to learn the web, and it wasn’t rigorous; it produced developers with patchy theoretical foundations. What it produced reliably was developers with strong mental models of what a webpage actually is. They had read enough of them. Markup wasn’t magic. Markup was a thing made of text.

Why view-source disappeared.

Modern web applications are usually compiled. The HTML the browser receives is mostly an empty shell with a script tag pointing at a bundled JavaScript blob. The actual content gets rendered into the DOM at runtime by the framework. If a kid in 2026 right-clicks and picks View Source on a React app, what they see is unreadable. Minified code, opaque variable names, no structure they can map onto the page they were looking at.

This happened for real engineering reasons. Bundling and minification ship faster, easier-to-cache code. Frameworks like React and Vue and Svelte produced more interactive UIs than vanilla HTML could deliver at the same level of polish. Type systems and module systems made teams more productive. Each individual step in the build pipeline made sense.

The build step optimized for the developer’s deploy speed and the framework’s ergonomics. It did not optimize for the next 10-year-old who would right-click on the page hoping to see how it worked. An informal history of the web’s last decade

The side effect, almost no one’s top priority, was that the educational affordance of view-source got buried. The web stopped teaching itself. Kids who wanted to learn how a website was made had to go find a tutorial. The page they were looking at could no longer answer the question.

Why we kept it on purpose.

Tell and Show’s site track is built around the inspectability promise. The engine produces plain HTML, plain CSS, and plain JavaScript. No build step. No bundler. No virtual DOM. When a kid deploys their portfolio site, what gets uploaded to the URL is the same files in the same shape that sit on their computer. Right-click the deployed page, pick View Source, and the kid is looking at their own work.

This was a deliberate engineering choice that cost something. Modern frameworks have real advantages we gave up. Component reuse is clumsier in plain HTML. Reactive state is something the kid’s code has to handle by hand or with small libraries. The site engine cannot match the polish ceiling of a full React app on the same effort budget.

What we got back for that cost is that the deployed artifact is the lesson. The kid can read their own site. A friend can read their friend’s site. A parent can open the file in a text editor and see what their kid is actually shipping. The Game and Story tracks make the same trade differently: the game ships as readable HTML5 / Canvas code, the story ships as inspectable HTML pages. The whole studio is biased toward output the kid can read.

The bias has a name in interaction-design research. Ben Shneiderman called it direct manipulation: systems are most learnable when users can see the objects of interest, act on them directly, and observe immediate results.¹ View-source is the dropped-into-a-text-file version of that principle. The object of interest is the page. The kid can act on it directly. The results are immediate.

The first time a kid looks.

We have watched this moment in cohorts. A kid has spent two weeks building a site, mostly using the visual builder, occasionally watching Inkie make changes in the project files. The site is live. The parent has approved the deploy. The URL works. Somebody in the family suggests they try right-clicking the page.

The kid does. The source comes up. They read the top: <!doctype html>, <html>, <head>, <title>. They scroll. They find a sentence they wrote. There’s the sentence, sitting inside a <p> tag. They scroll to the CSS. They find the color they picked. The color is a hex code now, but they can see which thing it’s coloring.

What changes for the kid in that minute is small and durable. The site stops being magic. It becomes a thing made of text. The text follows rules that look strange but aren’t deeply mysterious. The kid now knows, at a level they can’t un-know, that everything they see on the web is made of this kind of stuff. They’ve seen it.

The kid doesn’t become a programmer in that minute. They’ve crossed a threshold of demystification. The web is now a thing whose layers are inspectable. The next time they see a website they like, they have a default move: they can look at how it works. That move is exactly the one that taught the previous generation of developers.

What the research says it does.

The educational case for visible runtimes was made most carefully by Bret Victor in his 2012 essay Learnable Programming.² Victor argued that programming environments should let learners see what the program is doing, in time, as it runs. The opposite is invisible behavior, where the only way to understand a program is to simulate it in your head, which is what professional programmers do but a hard ask for a 10-year-old.

Victor’s essay focuses on richer environments than view-source: live coding, scrubbable timelines, visible state. View-source is the smaller, older, more durable cousin of those ideas. It doesn’t show the runtime in motion. It does show the source as written, mapped to the result on screen. That’s enough to start building an accurate mental model of how the page came to be.

The deeper claim sits inside Mitchel Resnick’s argument for transparent creative environments.³ The MIT Lifelong Kindergarten group has argued for two decades that learnable systems are systems whose workings are exposed to the learner. The argument echoes back to Seymour Papert’s 1980 case for the LOGO turtle: kids learn computing by writing code they can see run, not by being told what code is.⁴ The studio inherits the lineage. Plain HTML is the modern LOGO turtle for the web.

Honest caveat: view-source alone doesn’t make a kid into a developer. It removes one barrier. The kid still needs projects they care about, an AI partner who can keep up with their ambition, and an audience that will look at what they ship. The studio supplies those too. But view-source is the unfancy, easy-to-overlook piece without which the others lose half their power. Inspectability is the lever. The kid’s curiosity is the force on the lever. The studio is built to make both as easy to reach as possible.