CodePen's Babel Strategy Balances Legacy Compatibility and Modernization

Original Title: 415: Babel Choices

TL;DR

  • Adopting @babel/preset-env for new Pens streamlines JavaScript transformations by automatically adapting to browser support targets, preventing the need for manual plugin management and reducing technical debt from outdated proposals.
  • The new CodePen editor's "block" concept, with version locking, ensures backward compatibility for existing Pens while allowing for independent evolution of new features, preventing unexpected breakage.
  • Migrating Classic Pens to the new editor uses a "tweener" Babel configuration that supports 99.5% of old functionality without the cruft, balancing backward compatibility with modern standards.
  • The decision to omit obsolete Babel plugins, like nullish coalescing, from the default configuration simplifies tooling and reduces maintenance burden, relying on modern browser support.
  • Providing an editable Babel configuration in the new editor offers control to advanced users, while its hidden placement ensures simplicity for those who prefer not to manage it.
  • The "block" system's versioning strategy, exemplified by the "tweener" Babel config, aims to minimize future technical debt by making deliberate, one-time decisions about feature support.

Deep Dive

The transition to CodePen's new editor necessitates a fundamental re-evaluation of how processing blocks, specifically Babel, are configured. This shift moves from a simplified, opaque system in the old editor to a more controllable, versioned block system in the new one, creating a tension between maintaining backward compatibility for existing pens and embracing modern JavaScript development practices.

The core of this transition lies in CodePen's new "block" concept, which allows for more granular control over processing tools like Babel. In the old editor, Babel was a simple dropdown selection, abstracting away complex configurations. The new editor introduces editable Babel blocks, offering users control over plugins and presets, and crucially, locking in specific versions. This versioning is a key design choice; it ensures that a pen's processing won't unexpectedly break due to updates, while also allowing CodePen to evolve new versions of blocks independently. However, this presents a challenge when migrating millions of existing "Classic Pens." The chosen approach for converted pens is a "tweener" Babel configuration. This hybrid config aims to support the vast majority of legacy Babel functionality without carrying over obsolete or unnecessary plugins, striking a balance between compatibility and modernization. For new pens, CodePen offers a modern, editable Babel block, primarily leveraging @babel/preset-env for current JavaScript features and optional JSX processing, reflecting contemporary development trends. This deliberate choice to not offer a fully open-ended plugin selection for new blocks, while understandable from a maintenance perspective, represents a current limitation that may evolve.

The implications of this Babel configuration strategy extend to how developers experience CodePen and how the platform manages technical debt. By opting for a "tweener" configuration for converted pens instead of a full legacy block, CodePen prioritizes efficiency and reduces immediate technical debt. This approach assumes that most legacy Babel functionality has either become standard JavaScript or has fallen out of favor, simplifying the transition. However, this decision requires careful validation to avoid breaking existing pens, a process that involves significant verification work. The SAS processor, for instance, necessitated a separate "legacy" block due to greater divergence between old and new versions, highlighting the trade-offs in managing complex integrations. Ultimately, CodePen's strategy with Babel aims to provide a modern, adaptable platform for new development while carefully navigating the complexities of preserving the functionality of its extensive existing user base.

Action Items

  • Audit Babel configuration: Identify 3-5 core plugins used in the legacy config and evaluate their current relevance against TC39 proposal stages.
  • Create Babel runbook template: Define 5 required sections (setup, common failures, rollback, monitoring) for managing Babel configurations and preventing knowledge silos.
  • Measure Babel transformation impact: For 10-20 converted pens, analyze the difference in output between the legacy and "tweener" Babel configurations.
  • Track Babel plugin adoption: Monitor usage of new Babel features (e.g., decorators) in newly created pens to inform future configuration decisions.

Key Quotes

"Probably the best way to use Babel is to just use the @babel/preset-env plugin so you get modern JavaScript features processed down to a level of browser support you find comfortable."

Chris explains that the recommended approach for using Babel is to leverage the @babel/preset-env plugin. This plugin simplifies the process by transforming modern JavaScript features into a compatible level for older browsers, making development more comfortable.


"But Babel supports all sorts of plugins, and in our Classic Editor, all you do is select "Babel" from a dropdown menu and that's it. You don't see the config nor can you change it, and that config we use does not use preset env."

Chris highlights a key difference in how Babel was handled in the previous CodePen editor. Users could select "Babel" from a dropdown, but the underlying configuration was hidden and unchangeable, notably not utilizing the preset-env plugin.


"We want to give new Pens, which do support editable configs, a good modern config, and we want all converted Classic Pens a config that doesn't break anything."

Chris outlines the dual objective for the new editor's Babel configuration. The goal is to provide a modern, editable configuration for new projects while ensuring that existing pens converted to the new system maintain compatibility and do not encounter errors.


"We're still in the midst of working on our conversion code an verifying the output of loads of Classic Pens, so we'll see how it goes!"

Chris provides an update on the ongoing work for converting existing pens. The team is actively developing and testing the conversion process to ensure that older pens function correctly within the new editor's framework.


"The npm install the npm install bar kind of gets you into trouble when you start talking about libraries and frameworks and other stuff that may or may not really involve actual processing right it's the processing that's the that's the that's what makes it block like in our world"

Robert clarifies the concept of a "block" in their system, distinguishing it from a simple npm install. He explains that a block is characterized by its ability to process code, taking an input and producing an output, which differentiates it from libraries that may not involve code transformation.


"We're going to make some hard decisions now and it'll be the last time ish we need to ever make them."

Robert reflects on the current phase of development, indicating that the team is making difficult choices regarding Babel configurations. These decisions are intended to resolve complexities now, minimizing the need for similar choices in the future as the system evolves.

Resources

External Resources

Books

Videos & Documentaries

Research & Studies

Tools & Software

  • Babel - Discussed as a tool for processing JavaScript features down to a level of browser support.

Articles & Papers

People

  • Robert - Coworker and guest on the podcast discussing Babel choices.
  • Chris - Guest on the podcast discussing Babel choices.

Organizations & Institutions

  • TC39 - Committee responsible for the evolution of the JavaScript language.

Courses & Educational Resources

Websites & Online Resources

  • CodePen - Platform where the podcast episode is hosted and discussed.

Podcasts & Audio

  • CodePen Radio - Podcast where the discussion about Babel choices took place.

Other Resources

  • @babel/preset-env - A Babel plugin used to transform future JavaScript features to compatible versions.
  • JSX - A syntax extension for JavaScript, often used with React, that Babel processes.
  • Nullish coalescing - A JavaScript operator that Babel can transform.
  • Optional chaining - A JavaScript operator that Babel can transform.
  • Private methods - A JavaScript feature that Babel can transform.
  • Logical assignment operators - A JavaScript feature that Babel can transform.
  • Decorators - A JavaScript syntax feature, often used with Lit HTML and TypeScript, that Babel can process.
  • Lit HTML - A library that uses decorators.
  • TypeScript - A programming language that supports decorators.
  • Web Components - A technology that uses custom HTML elements.
  • React - A JavaScript library for building user interfaces, often associated with JSX.
  • Create element - A function used in React for creating elements.
  • Function bind operator - A JavaScript feature that was previously part of the TC39 process.
  • Bourbon - A Sass plugin.
  • Neat - A Sass plugin.
  • Dart Sass - The latest implementation of Sass.
  • Ruby Sass - An earlier implementation of Sass.
  • Node Sass - A Sass implementation.
  • LLM - Large Language Model, mentioned in the context of browser APIs.
  • Bun - A JavaScript runtime.

---
Handpicked links, AI-assisted summaries. Human judgment, machine efficiency.
This content is a personally curated review and synopsis derived from the original podcast episode.