A history of code sandboxes

Type some code, see it run, send someone a link. The idea feels so obvious now that it's easy to forget somebody had to invent each piece of it — and that the pieces arrived years apart, from different directions, for different reasons. This is the story of the code playground: two and a half decades of tools built around one instinct — a link that holds a complete, self-contained artifact — with increasingly elaborate infrastructure built up, and then partly shed, along the way.

Before the timeline, one distinction worth holding onto, because it organizes everything that follows: some of these tools are about sharing — moving a finished piece of code from one person to another, where nothing gets made in the tool itself. Others are about building and sharing — the browser is where the thing actually gets written, and what travels afterward is the full, live, editable source. Someone opens your link and gets the real thing: they can fork it, change it, and keep going from exactly where you left off. Watch which side of that line each tool lands on.

2002 — Pastebin: the actual ancestor

The category's DNA doesn't come from any browser capability. It comes from IRC.

Pastebin was built by Paul Dixon and launched September 3, 2002 — a full seven years before the first real JavaScript playground. It grew out of the #php IRC channel, built for collaborative code review over chat (inspired by an even more basic tool, parseerror.com/paste). Written in PHP; Dixon sold it in 2010 to Jeroen Vader, who modernized it with accounts and new versions.

Here's the important thing: Pastebin is not a playground. No live preview, no execution, no editor panes. Just plain text storage with syntax highlighting and a shareable URL. It's the "paste a snippet, get a link" half of the idea — a full generation before anyone added the "and see it run" half. But the URL-as-the-artifact, the syntax highlighting, the share-by-link culture — all of it starts here.

(A footnote on where that path led: Pastebin later became infamous as the place hacked data dumps got posted — Anonymous, LulzSec, Ashley Madison. A very different cultural trajectory than the playground tools took.)

2007–2010 — The server-side attempts, and why they're a harder problem

Almost everything on this timeline runs JavaScript, HTML, and CSS — which execute in the visitor's own browser. The playground never has to run anyone's code on its own servers. That single fact is why "live as you type" is basically free for the JS tools. Server-side languages don't get any of that for free, and a cluster of tools proves people were trying anyway — starting even earlier than the JS side did.

Codepad.org — built by Filip Stanek, launched 2007. Genuinely the earliest execution tool on this whole timeline, two years before JS Bin. Paste code in C, C++, D, Haskell, Lua, OCaml, PHP, Perl, and more; it runs server-side; you get a shareable link. Pastebin plus execution, arriving just as Pastebin itself was maturing.

Ideone.com — launched 2009 out of Gdynia, Poland, right alongside JS Bin. Same idea, much wider: 60+ languages over time, custom stdin, public/private/secret visibility. Probably the most-used general-purpose one of these for years. Still running.

Notice what neither of them has: no live preview, no editable panes, no fork-and-continue. They're "run it once, see the output, share the link" — a third bucket between pure sharing and real building. That's not a limitation they grew out of later; it's a direct consequence of the economics. A JS playground can re-run on every keystroke because the browser does the work for free. Codepad and Ideone never had that option for C++ or PHP, so click-to-run was the only sane design from day one.

Python Tutor (pythontutor.com) — the education-angle one. Built by Philip Guo starting in 2010 as a grad-student project (published as a SIGCSE paper in 2013), with a different goal entirely: not "run this and show me output," but "show me how this ran." It's designed to imitate what an instructor draws on the blackboard — step-by-step visualization of the call stack, heap, and variable references as code executes. The frontend sends your code to a backend, which runs it and returns a full execution trace, one entry per step, rendered as diagrams. For C and C++ it uses Valgrind to safely walk data structures in memory. That's a meaningfully higher bar than Codepad or Ideone: it's not enough to run the code and capture stdout — you have to instrument the interpreter itself. It now covers Python, Java, C, C++, JavaScript, TypeScript, and Ruby.

Why is server-side just harder, in general?

• No free sandbox. JS gets the browser's security model for free — same-origin policy, no filesystem, no syscalls. The browser vendor already built it. Python or C code has to run on the playground's own servers, so the operator builds or rents the sandbox: containers, resource limits, timeouts, network egress blocking, filesystem isolation.
• No free "live as you type." You can't spawn a fresh process on every keystroke — that's real compute cost per run. So these tools are click-to-run or debounced, never truly live.
• Real attack surface. A stranger's code on your infrastructure can try to read other users' data, attack the host, or turn your sandbox into a spam relay. That's a genuine adversarial security problem, not a UX one.

And PHP specifically has it worse than most. Its standard library ships with functions that talk directly to the host by default — exec(), system(), passthru(), shell_exec(), file_get_contents() on arbitrary URLs — so sandboxing "plain PHP" means disabling a big chunk of the language or trusting a blacklist, and blacklists keep leaking (there's a real-world case of a CMS that tried to sandbox Twig templates by blacklisting dangerous PHP functions, and it was bypassable). PHP also assumes it's living inside a full web-server context — Apache or Nginx, PHP-FPM, historically a filesystem and database close by — a much messier starting point than Python's clean "run script, capture stdout" story. The PHP tools that do exist lean into the mess rather than fighting it: 3v4l.org's whole pitch is running your one snippet across 400+ PHP version/extension combinations simultaneously — as much a compatibility-testing tool as a playground, and it only makes sense because PHP's runtime landscape is that fragmented.

2009 — JS Bin

Built by Remy Sharp. The core idea: collaborative JS debugging in context — paste, share the URL, someone else pokes at it and resaves. Its live "CodeCasting" — the viewer's browser updating in real time as you type — ran on Server-Sent Events, which was still a brand-new HTML5 spec at the time. Started as PHP, fully rewritten in Node.js in 2012. Open source, self-hostable, with genuinely useful preprocessor support early on.

But: utilitarian UI, no community or discovery layer, never a "destination." It's still running today, quietly — more debugging tool than hangout.

2010 — JSFiddle

Built by Piotr Zalewa, with UI by Oskar Krawczyk. JSFiddle gave the category its canonical shape: the four-pane HTML / CSS / JS / Result layout. "Here's a fiddle" became developer vocabulary — the default way to attach a repro case to a bug report or a Stack Overflow question.

There's no new-technology story here — JSFiddle won on format, not on a fresh API. Under the hood: CodeMirror as the editor (the same component nearly everyone else on this list used too), and MooTools — an old JS framework — well past its expiration date. Only recently did it swap the editor for Monaco (VS Code's editor component). The visual design froze around 2012–2014 — grey chrome, small type — and stayed there while ads crept in. Still running. Still looks like 2011.

2011 — Dabblet

Built by Lea Verou as a one-person side project, in reaction to JSFiddle's JS-centrism — a tool for pure CSS and HTML experimentation. It had inline value previews (color swatches next to your color values) before real code editors did.

Two architecturally interesting choices. First, it used GitHub Gists as its storage backend instead of a database — a serverless-ish move only possible because the Gists API was itself new. Second, it launched with its own hand-rolled syntax highlighter — which Verou later spun out and grew into Prism.js, now a widely-used standalone highlighter in its own right. A playground's internal plumbing becoming shared infrastructure for everyone else: hold that thought, it recurs.

The big miss: Dabblet launched with no JavaScript pane — only inline onclick= handlers worked at first. A JS tab came later, too late to matter. And as a solo unfunded project, it had no way to keep pace once funded competitors arrived. Long dormant now — though it's worth saying that Dabblet was probably never meant to be a business. It was a gift to the community that happened to be ahead of its time. The tool that arrived a year later had very different intentions.

2012 — CodePen

Founded by Chris Coyier, Alex Vazquez, and Tim Sabat — and unlike Dabblet, CodePen was meant to be a business from day one: three founders, a product strategy, a plan. The differentiator was community: profiles, hearts, following, a front page of trending Pens. CodePen shifted the entire category from "debugging tool" to "portfolio and inspiration feed."

Like JSFiddle, no new-tech story at launch — CodePen won on timing and format. And the timing was extraordinary: CSS3 was rolling out module by module (transforms, transitions, animations, gradients, @font-face, media queries) — perfect demo material. HTML5 hit Candidate Recommendation in 2012 with mobile exploding the same year. Responsive design (2010) and Bootstrap (2011) were brand new. "Front-end developer" was crystallizing as its own identity. Dabblet and JSFiddle arrived a beat too early, before that community had coalesced — and Coyier brought a built-in audience from CSS-Tricks, so CodePen didn't start from zero.

The stack: Ruby on Rails backend, React frontend, PostgreSQL, and — again — CodeMirror for the editor.

Some markers along the way: the 2015 Sparkbox redesign brought in an outside agency three years post-launch, with a real research phase (a 500-person survey, ten user interviews, ethnographic observation), documented publicly month-by-month on a companion microsite. The Projects feature later added multi-file editing and a build process — closer to a lightweight IDE than a single-file Pen. And CodePen 2.0 (July 2026) is a from-scratch rebuild folding Classic Pens and Projects into one editor — npm support via import maps and esm.sh (import maps only got solid cross-browser support in the last few years), and realtime collaboration rebuilt on Y.js and CRDTs, replacing a FirePad → Firebase → PubNub → Ably lineage. CRDT tooling only recently matured enough to trust in production.

The team has stayed small and named — Coyier, Vazquez, Marie Mosley, Rachel Smith, Stephen Shaw (Tim Sabat is no longer on the team page). And CodePen kept reinvesting in visual design across every redesign — for a "show off your work" product, looking good was actually load-bearing. Still the dominant tool in the category.

~2013 — Plunker

Built by Geoff Goodman, later backed by ag-Grid. Plunker came out of the early AngularJS moment and differentiated on multi-file projects versus single snippets — and it was built entirely in AngularJS, literally dogfooding the framework it was mostly used to prototype. It's also the one major outlier on editor choice: the Ace editor (from Cloud9, itself fairly new) instead of CodeMirror, plus SystemJS for in-browser module loading — solving multi-file JS dependency resolution client-side before that was common.

For years it was embedded in Angular's own documentation — a captive audience. But it never modernized past its early-2010s look, and it had tied its fate to one framework's popularity. As Angular's dominance faded, so did Plunker. Effectively discontinued.

2015 → 2017 — HyperDev → Glitch

Built by Fog Creek Software (Joel Spolsky's company), rebranded as Glitch in 2017 under CEO Anil Dash. This was a jump in kind, not degree: full Node/Express backends, instantly remixable full-stack apps. The enabling technology was lightweight per-project containers — only cheap and practical to spin up instantly because Docker was barely two years old at that point.

Glitch had the friendliest, most playful design of the whole bunch — bright colors, a mascot, remixing framed as fun rather than "forking." But the thing that made it lovable — free, open, no gatekeeping — is exactly what made it expensive and abuse-prone at scale. Fastly acquired the company in 2022 and shut down project hosting on July 8, 2025, citing cost and misuse. A clean case study in what happens when a joyful free tool meets real hosting economics.

2017 — CodeSandbox

Created by Ives van Hoorne as the React-ecosystem answer: real npm packages, real project structures, not vanilla-JS demos. The enabling tech was a custom in-browser bundler backed by Service Workers — caching and intercepting requests so bundling happens client-side with no server round-trip. Service Workers had only just reached solid browser support.

The stack: a React editor with Monaco (VS Code's actual editor component) embedded, an Elixir backend API, TypeScript microservices, Postgres plus two Redis instances, and a Gatsby marketing site. Clean, IDE-like design from day one — CodeSandbox skipped the "ugly early era" the 2010–2012 tools went through.

Its most durable contribution might be Sandpack: the in-browser bundler, running internally since 2018 (first shipped to npm as a package literally named react-smooshpack), open-sourced under the Sandpack name in late 2021 so anyone could embed a live, editable code example on their own site without depending on CodeSandbox at all. Sandpack 2.0 (2023) added its own in-browser Node.js runtime. It now powers the interactive examples in React's own official docs, among others — a playground's internals becoming shared infrastructure for the rest of the web, the same pattern as Dabblet's highlighter becoming Prism. CodeSandbox itself has recently pivoted hard toward AI and cloud-dev-environment positioning, drifting away from "casual public playground."

2017 — Flems: the minimalist counter-reaction

Built by porsager, shown publicly via a "Show HN" post in June 2017 — and deliberately the opposite instinct from everything else happening at that moment. While CodeSandbox and StackBlitz raced toward full project structures and real backends, Flems went the other way: as small and dependency-free as possible.

Its trick is the most radical version of "no backend" on this entire timeline: no server at all after the page loads. Your code is compressed directly into the URL itself — one step further than Dabblet's Gists trick, which still needed GitHub behind it. There's nothing to save and nothing to fail; the address bar is the saved state. It even ships as a single HTML file that is simultaneously valid JavaScript — the JS hidden inside HTML comments and the HTML hidden inside JS comments — so the same file works as both the module you import and the iframe document it runs in.

Flems positioned itself explicitly for embedding — documentation, presentations, GitHub issues — not as a destination site with a homepage and a community. Same category as CodePen, opposite bet: CodePen won by building the biggest possible surface area; Flems bet on the smallest possible surface area that still works anywhere.

2018 (→ 2021) — StackBlitz

The clearest "genuinely impossible before" case on the whole list. StackBlitz's enabling technology is WebContainers — a full Node.js compiled to WebAssembly, running natively inside the browser tab, with no server-side container per session. It needed WebAssembly to mature first; nothing like it could have existed earlier. The payoff: near-instant boot times and no server round-trip. The tradeoff: some native Node modules and APIs simply don't work inside a browser sandbox.

The editor experience is explicitly VS Code's own (Monaco). StackBlitz positioned itself as a serious dev environment, not a discovery platform — it never built anything like CodePen's browse culture. Hold onto WebContainers, though; it comes back in a surprising way.

2021 — Hugging Face Spaces: a genuine fork in the lineage

Launched October 2021, and shaped differently from everything above it: Python-first rather than JS-first, built for showing off a trained model rather than prototyping a webpage. Spaces are actual Git repositories — you push commits, same as any repo; there's no "type in a pane and watch it live-update." SDK options: Gradio, Streamlit, custom Docker containers, or plain static HTML.

It belongs on this list because the "code playground" idea genuinely forked into two lineages. One stayed web/JS and became everything above. The other became "how do I let a stranger try my ML model in a browser?" — and Spaces is the dominant answer to that second question the way CodePen is to the first. It grew fast because it filled a real gap: nobody wants to pip install a stranger's research code just to try it. By late 2021 it had already hosted 12,000+ open-source ML demos.

2023–2024 — The AI-builder generation: input stops being code

Everything up to this point assumes a human typing code into a pane. This generation assumes a human typing a description — and an AI model producing the code. The editor pane becomes optional, sometimes just a window onto what the model wrote.

• v0 (Vercel) — announced September 2023, public beta October 11, 2023; the alpha waitlist pulled 100,000+ signups in three weeks before it even opened. Scoped narrowly at first — describe a UI component, get back React code using shadcn/ui and Tailwind, with a few design variations to pick from — then expanded well past "component generator" through 2024–2025.
• Lovable (Stockholm, 2023, originally called GPT Engineer) — outputs React + TypeScript + Supabase apps with GitHub export. One of the fastest-growing startups in European history: reportedly $20M ARR within two months of relaunching under the Lovable name.
• Replit Agent — launched September 2024. Replit itself is much older (founded 2016 by Amjad Masad as a general browser-based IDE, predating almost the entire AI-builder wave) and had been a flat-revenue business for years. The Agent layer — a chat-based pair-programmer that configures the environment, installs dependencies, and executes code on your behalf — took the company from roughly $2.8M to $150M in annualized revenue within months of shipping.
• bolt.new (StackBlitz) — launched October 3, 2024, via a single tweet, and went viral immediately: $60K ARR on day one, $40M ARR within five months. And here's the callback: bolt.new is built directly on StackBlitz's own WebContainers — the same in-browser WebAssembly Node runtime from 2021 — now paired with an AI model (initially Claude 3.5 Sonnet) doing the code generation. The earlier, commercially underwhelming infrastructure bet became the exact substrate for a completely different, explosively successful product three years later.
• Claude Artifacts (Anthropic) — shipped June 21, 2024, alongside Claude 3.5 Sonnet. A different shape again: generated code, small apps, and documents render inline in a side panel during a chat conversation, rather than living at their own standalone URL like everything else on this list.

The throughline worth naming: this generation isn't competing on editor UX, storage tricks, or execution infrastructure the way 2009–2021 did. It's competing on model quality — and the "playground" part has become almost incidental, a place to watch code appear and run rather than a place to write it.

On the sharing-versus-building axis, most of these are still firmly build-and-share: v0, Lovable, bolt.new, and Replit Agent all hand you a real, forkable, deployable codebase — it's just that a model wrote the first draft instead of you typing every line. Claude Artifacts sits closer to the sharing end: usually a single self-contained piece, shareable by link, without the "fork this whole project and keep building" structure of CodeSandbox or StackBlitz.

The educational fork — running alongside all of it

There's a second family tree that's been growing this whole time, and it's the one our own tool actually descends from: playgrounds built not for sharing or portfolio-building, but for teaching. It runs parallel to everything above, occasionally crossing over, and it carries its own cautionary tale.

W3Schools' Tryit Editor may be the oldest type-and-run editor on the web, full stop. W3Schools launched in 1998, and the Tryit Editor is old enough that nobody seems to have recorded when it appeared — plausibly predating Pastebin, and certainly predating every playground above. Which slightly rewrites the opening of this piece: the educational side may have had the playground before the sharing side did. It just never had the URL-as-artifact idea — a Tryit session was for you, in the moment, next to the reference material. No link, no save, no community. Sound familiar? Hold that thought.

TryRuby (around 2005) came from why the lucky stiff — _why — whose 2005 OSCON talk explored how to teach programming and make it appealing to newcomers. A Ruby prompt in the browser, talking to a server that ran your code: server-side pedagogical execution before Codepad existed. When _why famously vanished from the internet in 2009, Envy Labs — Gregg Pollack's Orlando shop — rebooted TryRuby and took over its hosting.

That thread leads directly to Rails for Zombies (2010) and Code School (2011). Rails for Zombies taught Ruby on Rails entirely in the browser: watch a video, then complete lab exercises in an in-browser editor. Code School wrapped that format into a company — screencasts plus in-browser challenges, with course badges and points baked in from early on. Note the date: Rails for Zombies predates Codecademy, which complicates the usual story of who gamified coding education first. Code School's arc is the cautionary one: acquired by Pluralsight for $36 million (announced January 2015), then shut down on June 1, 2018, dissolved into a generic course library. A beloved brand with a real point of view, gone the same way Glitch went — the joyful thing meets the acquiring company's economics.

Codecademy (launched August 18, 2011, by Zach Sims and Ryan Bubinski) is who took gamification mainstream: points, badges, streaks, wrapped around an in-browser editor with step-checking. Its Code Year campaign made "learn to code" a New Year's resolution. Whatever you think of the model — and we'll get to that — the scale was real, and it defined what "interactive coding education" meant to the general public for a decade.

Khan Academy's computer science environment (August 2012, built by John Resig — the creator of jQuery) was the most pedagogically ambitious of the era: a live editor where the canvas re-renders as you type, with recorded "talk-throughs" whose audio syncs to the editor itself — the lesson is the playground. It landed in the same intellectual moment as Bret Victor's "Inventing on Principle," and it was a genuine bet that seeing code respond instantly is itself a teaching method. That's the same bet every JS playground above makes incidentally; Khan Academy made it on purpose.

freeCodeCamp (October 2014, Quincy Larson) scaled the challenge-and-validation model further than anyone — a nonprofit with a single-track curriculum, thousands of in-browser challenges, certifications as the reward structure, millions of learners.

MDN closes the loop. Interactive examples embedded directly in reference pages arrived in the late 2010s, and the full MDN Playground launched in mid-2023 — any live sample on any MDN page can now break out into a full editing environment. Notably: no gamification. No points, no streaks. The embed exists to make the documentation touchable — which, of everything in this section, is the instinct closest to ours.

The negative side, named plainly

Gamification optimizes for continuing, not for understanding. A streak measures that you showed up, not that you can do anything. The green checkmark on a passed challenge grades output-matching — did your code produce the expected result — which quietly replaces the more important judgment call a developer actually has to learn: does this work, and how would I know? And the ever-present, pre-configured editor box has a subtle cost: learners who've completed hundreds of challenges but have never created a file on their own machine, never set up a project, never worked without the rails. The community even has a name for the resulting condition — tutorial hell — and the gamified platforms, whatever their genuine reach, industrialized it.

None of this means the educational fork was a mistake. It means the sandbox is a dosage problem: powerful for touching a concept in the moment, corrosive as the place where all the work happens. Which is the design position our own tool takes — deliberately, and next.

June 2026 — CodeStudy: our own

CodeStudy is the tool we built in-house at Perpetual Education — a bundled, self-hosted replacement for CodePen embeds, deliberately not a hosted external service. The stack is Vue 3 + CodeMirror 6: the same editor lineage running through JSFiddle, CodePen, and (via Prism) Dabblet — the same component still being reached for fifteen years after Dabblet used an early version of it.

How it plugs in: the component itself is standalone and framework-agnostic — it doesn't know or care what feeds it. In practice, our LMS feeds it context, and a basic PHP server adapter handles the execution side — but that adapter is swappable by design. The same component could sit in front of any backend that speaks its protocol. That separation — standalone renderer plus pluggable server adapter — is a real architectural decision, not an accident.

An example is just data: a set of files (HTML / CSS / JS / PHP) plus a zones layout arranging editor panes and special panes — output (an iframe preview), console (capture), and browser / response panes built specifically for teaching PHP. Each example is a study post on the PE site — embeddable inline in a lesson, or standalone at its own URL.

It's not one fixed exercise format but a ladder of configurations: output-only demos (interact before you see code) → read-only code → HTML/CSS beside live output → JS with console output → full editable playgrounds → PHP examples where you click "Request" and watch the round-trip. Editable examples pair a locked setup file with an editable try file; edits live-preview with a debounce but are never persisted — refresh resets to the authored version, on purpose. And it sits alongside a second, deliberately different mode: Specimens (static, hand-marked snippets via Prism — "stop and read") versus Sandboxes (CodeStudy itself — "try it yourself"). Two modes kept side by side, not one replacing the other.

The PHP-specific teaching trick is a direct callback to the "why server-side is harder" section above: the runner adds a deliberate ~500ms artificial delay to the request/response cycle, so request → processing → response is felt as separate steps rather than arriving instantly like a client-side playground. The round-trip itself is the lesson, not something to hide. Same reasoning behind the response pane being separate from generic console output — a distinction no other tool on this list bothers making, because when you're teaching HTTP, that distinction is the actual point. Grid lines are a built-in pane concept too — none of the commercial tools have an equivalent, because none of them are trying to teach layout mechanics specifically.

Scoped small and in-context: one concept, a few short files, minutes of interaction — not a sitting, though a lesson can stack several in sequence. Explicitly not included, on purpose: no challenges, validation, or auto-grading; no student accounts or saved work; not built for mobile (complex examples get a fallback card — the philosophy being that mobile is for reading and watching, not editing). Read against the educational fork above, those exclusions are a position, not missing features: everything the gamified platforms used to keep you in the box, left out — because the box is for touching the concept, and the real work happens outside it. And the "forget about it for a year" test was a real design constraint: being bundled and dependency-free at runtime is the whole point, relative to depending on an external embed.

The threads that run through all of it

Timing against what just became possible. JS Bin, Dabblet, Glitch, CodeSandbox, StackBlitz, and CodePen 2.0 each timed themselves to something that had just become possible — Server-Sent Events, the Gists API, cheap containers, Service Workers, WebAssembly, import maps plus mature CRDTs. JSFiddle and original-era CodePen are the outliers: they won on format and community, not a new capability. Flems belongs in this thread at the opposite extreme — rather than riding a new capability, it rode the absence of a need for one, pushing the "no backend" idea all the way to "no backend at all." And the best sequel: StackBlitz's 2021 WebContainers bet, which didn't make much money as a standalone IDE, became the exact infrastructure bolt.new rode to explosive growth once an AI model was put in the driver's seat instead of a human.

Design as survival. The tools with no real moat — JS Bin, JSFiddle, Plunker — froze their UI around 2012–2014 and stayed there while the ecosystem moved on. CodePen kept reinvesting in design, redesign after redesign. Probably not a coincidence that it's the one still standing at the center of the category.

The shared component underneath almost everything: CodeMirror. JSFiddle, CodePen, and Dabblet's lineage all leaned on the same open-source editor, built by one person (Marijn Haverbeke) and reused across the entire category for over a decade. Plunker's Ace is the one real exception. Then, starting with CodeSandbox and StackBlitz and spreading to JSFiddle's own rewrite, the category quietly migrated to Monaco — VS Code's actual editor component, pulled out and embedded elsewhere. Almost none of these companies built their own text editor. They built everything else — community, hosting, bundling — around a component nobody wanted to reinvent. Sandpack fits the same pattern one layer down; Dabblet's highlighter becoming Prism fits it too. CodeStudy sits in the same lineage — CodeMirror 6, the same component, still.

The bookend. Pastebin (2002) is where "paste it, get a URL, share the URL" came from — no execution, just text and a link, born of IRC culture. Everything from JS Bin through CodePen 2.0 is that same idea plus live execution, with increasingly heavy infrastructure behind the "plus execution" part. Flems (2017) is almost a return to Pastebin's original minimalism — but keeping the execution: no server, no account, no save button, the URL just is the artifact again. The category starts and nearly ends on the same instinct, with two-plus decades of infrastructure built and partly shed in between.

And one last contrast, which is really the reason this piece exists: every tool on this timeline optimized for making execution feel instant and effortless. CodeStudy is the one built to make a specific kind of effort and delay legible — because for us, the delay is the lesson.