Bloomberg JS Blog

Temporal: The 9-Year Journey to Fix Time in JavaScript

2026-03-11T00:00:00Z

Welcome to our blog! I'm Jason Williams, a senior software engineer on Bloomberg's JavaScript Infrastructure and Terminal Experience team. Today the Bloomberg Terminal runs a lot of JavaScript. Our team provides a JavaScript environment to engineers across the company.

Bloomberg may not be the first company you think of when discussing JavaScript. It certainly wasn't for me in 2018 before I worked here. Back then, I attended my first TC39 meeting in London, only to meet some Bloomberg engineers who were there discussing Realms, WebAssembly, Class Fields, and other topics. The company has now been involved with JavaScript standardization for numerous years, including partnering with Igalia. Some of the proposals we have assisted include Arrow Functions, Async Await, BigInt, Class Fields, Promise.allSettled, Promise.withResolvers, WeakRefs, standardizing Source Maps, and more!

The first proposal I worked on was Promise.allSettled, which was fulfilling. After that finished, I decided to help out on a proposal around dates and times, called Temporal.

How Does JavaScript Change? #

JavaScript is unique in that it runs in all browsers. There is no single "owner," so you can't just make a change in isolation and expect it to apply everywhere. You need buy-in from all parties. Evolution happens through TC39, the Technical Committee responsible for ECMAScript.

Proposals move through a series of maturity stages:

Stage 0 - Idea
Stage 1 - Problem space accepted
Stage 2 - Draft design chosen, but work to continue
Stage 2.7 - Proposal approved in principle; awaiting testing and feedback
Stage 3 - Implementation and feedback
Stage 4 - Standardized

In 2018, when I first looked at Temporal, it was at Stage 1. The TC39 Committee was convinced the problem was real. It was a radical proposal to bring a whole new library for Dates and Times into JavaScript. It was:

A replacement for Date
Providing different DateTime Types (instead of a single API)
Immutable
Adding first-class time zone and calendar support

But how did we get here? Why was Date such a pain point? For that, we need to take a step back.

A Product of Its Time #

In 1995, Brendan Eich was tasked with a 10-day sprint to create Mocha (which would later become JavaScript). Under intense time pressure, many design decisions were pragmatic. One of them was to port Java's Date implementation directly. As Brendan later explained:

It was a straight port by Ken Smith (the only code in "Mocha" I didn't write) of Java's Date code from Java to C.

At the time, this made sense. Java was ascendant and JavaScript was being framed as its lightweight companion. Internally, the philosophy was even referred to as MILLJ: Make It Look Like Java.

Brendan also noted that changing the API would have been politically difficult:

Changing it when everyone expected Java to be the "big brother" language would make confusion and bugs; Sun would have objected too.

In that moment, consistency with Java was more important than fundamentally rethinking the time model. It was a pragmatic trade-off. The Web was young, and most applications making use of JavaScript would be simple, at least, to begin with.

The Web Grew Up, Date Didn't #

By the 2010s, JavaScript was powering banking systems, trading terminals, collaboration tools, and other complex systems running in every time zone on earth. Date was becoming more of a pain point for developers.

Mutability #

Developers would often write helper functions that accidently mutated the original Date object in place when they intended to return a new one:

const date = new Date("2026-02-25T00:00:00Z");
console.log(date.toISOString());
// "2026-02-25T00:00:00.000Z"

function addOneDay(d) {
  // oops! This is mutating the date
  d.setDate(d.getDate() + 1);
  return d;
}

addOneDay(date);

console.log(date.toISOString());
// "2026-02-26T00:00:00.000Z"

Inconsistent Month Arithmetic #

const billingDate = new Date("Sat Jan 31 2026");
billingDate.setMonth(billingDate.getMonth() + 1);
// Expected: Feb 28
// Actual:   Mar 02

Sometimes people want to get the last day of the month and fall into traps like this one, where they bump the month by one, but the days remain the same. Date does not constrain invalid calendar results back into a valid date. Instead, it silently rolls overflow into the next month.

Ambiguous Parsing #

new Date("2026-06-25 15:15:00").toISOString();
// Potential Return Values:
// - local TimeZone
// - Invalid Date RangeError
// - UTC

In this example, the string is similar, but not identical, to ISO 8601. Historically, browser behavior for "almost ISO" strings was undefined by the specification. Some would treat it as local time, others as UTC, and one would throw entirely as invalid input.

There's more, much more, but the point is that Date has been a pain point for JavaScript developers for the past three decades.

The Library Era #

The Web ecosystem had no choice but to patch Date's shortcomings with libraries. You can see the sheer rise of datetime libraries below. Today, they add up to more than 100 million downloads a week.

Leading the charge was Moment.js, which boasts an expressive API, powerful parsing capabilities, and much-needed immutability. Created in 2011, it quickly became the de facto standard for handling date and time manipulations in JavaScript. So surely the problem is solved? Everyone should just grab a copy of this and call it a day.

The widespread adoption of moment.js (plus other similar libraries) came with its own set of problems. Adding the library meant increasing bundle size, due to the fact that it needed to be shipped with its own set of locale information plus time zone data from the time zone database.

Despite the use of minifiers, compilers, and static analysis tools, all of this extra data couldn't be tree-shaken away, because most developers don't know ahead of time which locales or time zones they'll need. In order to play it safe, the majority of users took all of the data wholesale and shipped it to their users.

Maggie Johnson-Pint, who had been a maintainer of Moment.js for quite a few years (alongside others), was no stranger to requests to deal with the package size.

We were at the point with moment that it was more maintenance to keep up with modules, webpack, people wanting everything immutable because React, etc than any net new functionality

And people never stop talking about the size of course.

In 2017, Maggie decided it was time to standardise dates and times with a "Temporal Proposal" for the TC39 plenary that year. It was met with great enthusiasm, leading it to be advanced to Stage 1.

The Champions Assemble #

Stage 1 was a big milestone, but it was still far from the finish line. After the initial burst of energy, progress naturally slowed. Maggie and Matt Johnson-Pint were leading the effort alongside Brian Terlson, while simultaneously balancing other responsibilities inside Microsoft. Temporal was still early enough that much of the immediate work was unglamorous: requirements gathering, clarifying semantics, and translating "the ecosystem's pain" into a design that could actually ship.

At Bloomberg, that pain wasn't theoretical.

We run JavaScript at scale across the Terminal, using underlying runtimes and engines such as Chromium, Node.js and SpiderMonkey. Our users, and the financial markets in which they invest, span every time zone on earth. We pass timestamps constantly: between services, into storage, into the UI, and across systems that all have to agree on what "now" means, even when governments change DST rules with very little notice.

On top of that, we had requirements that the built-in Date model simply wasn't designed for:

A user-configured time zone that is not the machine's time zone (and can change per request).
Correct historical time zone behavior driven by IANA Time Zone Database (tzdata) updates.
Higher-precision timestamps (nanoseconds, at a minimum), without duct-taping extra fields onto ad-hoc wrappers forever.

In parallel with Maggie bringing Temporal to TC39, Bloomberg engineer Andrew Paprocki was talking with Igalia about making time zones configurable in V8. Specifically, they discussed introducing a supported indirection layer so an embedder could control the "perceived" time zone instead of relying on the OS default. In that conversation, Daniel Ehrenberg (then working at Igalia) pointed Andrew at the early Temporal work because it looked strikingly similar to Bloomberg's existing value-semantic datetime types.

That exchange became an early bridge between Bloomberg's production needs, Igalia's browser-and-standards expertise, and the emerging direction of Temporal. Over the years that followed, Bloomberg partnered with Igalia (including via sustained funding support) and contributed engineering time directly into moving Temporal forward, until it eventually became something the whole ecosystem could ship. Andrew was looking for some volunteers within Bloomberg who could help push Temporal forward and Philipp Dunkel volunteered to be a spec champion. Alongside Andrew, he helped persuade Bloomberg to invest in making Temporal real, including a deeper partnership with Igalia. That support brought in Philip Chimento and Ujjwal Sharma as full time Temporal champions, adding the day-to-day focus the proposal needed to keep moving ahead.

Richard Gibson (now an ECMAScript editor) volunteered as a Stage 3 reviewer in 2018, but over the years also cleaned up and directly contributed specification text for a smooth and comprehensible integration with the rest of the language.

Shane Carr joined the Champions team, representing Google's Internationalization team. He provided the focus we needed on internationalization topics such as calendars, and also served as the glue between the standardization process and the voice of users who experienced pain points with tools related to JavaScript's internationalization API (Intl), such as formatting, time zones, and calendars.

Finally, we had Justin Grant, who joined the Temporal champions in 2020 as a volunteer. After 10 years at three different startups that managed time-stamped data, he'd seen engineering teams waste thousands of hours fixing mistakes with dates, times, and time zones. Justin's experience grounded us in real-world use cases, helped us anticipate mistakes that developers would make, and ensured that Temporal shipped a Temporal.ZonedDateTime API to help make DST bugs a thing of the past.

Other honorable mentions not on this list include Daniel Ehrenberg, Adam Shaw, and Kevin Ness.

The Current & Past Champions of Temporal #

Maggie Johnson-Pint (Microsoft)
Matt Johnson-Pint (Microsoft)
Brian Terlson (Microsoft)
Richard Gibson (Agoric)
Philipp Dunkel (Bloomberg)
Ujjwal Sharma (Igalia)
Philip Chimento (Igalia)
Jason Williams (Bloomberg)
Shane Carr (Google)
Justin Grant (Invited Expert)

How Temporal Looks Today #

Temporal is a top-level namespace object (similar to Math or Intl) that exists in the global scope. Underneath it are "types" that exist in the form of constructors. It's expected that developers will reach for the type they need when using the API, such as Temporal.PlainDateTime, for example.

Here are the types Temporal comes packed with:

Temporal.ZonedDateTime #

If you don't know which Temporal type you need, start with Temporal.ZonedDateTime. It is the closest conceptual replacement for Date, but without the "footguns."

Date represents:

An exact moment in time (internally, milliseconds since epoch)
Interpreted through the machine's current time zone
With implicit, mutable behavior

Temporal.ZonedDateTime represents:

An exact moment in time
With an explicit time zone
With an explicit calendar
And full daylight-saving correctness
All as an immutable value

If you're currently writing:

const now = new Date();

The Temporal equivalent is:

const now = Temporal.Now.zonedDateTimeISO();

The above example uses the Now namespace, which gives you the type already set to your current local time and time zone.

This type is optimized for DateTimes that may require some datetime arithmetic in which the daylight saving transition could potentially cause problems. ZonedDateTime can take those transitions into account when doing any addition or subtraction of time (see example below).

// London DST starts: 2026-03-29 01:00 -> 02:00
const zdt = Temporal.ZonedDateTime.from(
  "2026-03-29T00:30:00+00:00[Europe/London]",
);

console.log(zdt.toString());
// → "2026-03-29T00:30:00+00:00[Europe/London]"

const plus1h = zdt.add({ hours: 1 });

console.log(plus1h.toString());
// "2026-03-29T02:30:00+01:00[Europe/London]" (01:30 doesn't exist)

In this example, we don't land at 01:30 but 02:30 instead, because 01:30 doesn't exist at that specific point in time.

Temporal.Instant #

Temporal.Instant is an exact moment in time, it has no time zone, no daylight saving, no calendar. It represents elapsed time since midnight on January 1, 1970 (the Unix epoch). Unlike Date, which has a very similar data model, Instant is measured in nanoseconds rather than milliseconds. This decision was taken by the champions because even though the browser has some coarsening for security purposes, developers still need to deal with nanosecond-based timestamps that could have been generated from elsewhere.

A typical example of Temporal.Instant usage looks like this:

// One exact moment in time
const instant = Temporal.Instant.from("2026-02-25T15:15:00Z");

instant.toString();
// "2026-02-25T15:15:00Z"

instant.toZonedDateTimeISO("Europe/London").toString();
// "2026-02-25T15:15:00+00:00[Europe/London]"

instant.toZonedDateTimeISO("America/New_York").toString();
// "2026-02-25T10:15:00-05:00[America/New_York]"

The Instant can be created and then converted to different "zoned" DateTimes (more on that later). You would most likely store the Instant (in your backing storage of choice) and then use the different TimeZone conversions to display the same time to users within their time zones.

Temporal.[PlainDate, PlainTime, PlainDateTime, PlainYearMonth, PlainMonthDay] #

We also have a family of plain types. These are what we would call "wall time," because if you imagine an analogue clock on the wall, it doesn't check for daylight saving or time zones. It's just a plain time (moving the clock forward by an hour would advance it an hour on the wall, even if you did this during a Daylight Saving transition).

We have several types with progressively less information. This is useful, as you can choose the type you want to represent and don't need to worry about running calculations on any other un-needed data (such as calculating the time if you're only interested in displaying the date).

These types are also useful if you only plan to display the value to the user and do not need to perform any date/time arithmetic, such as moving forwards or backwards by weeks (you will need a calendar) or hours (you could end up crossing a daylight saving boundary). The limitations of some of these types are also what make them so useful. It's hard for you to trip up and encounter unexpected bugs.

const date = Temporal.PlainDate.from({ year: 2026, month: 3, day: 11 }); // => 2026-03-11
date.year; // => 2026
date.inLeapYear; // => false
date.toString(); // => '2026-03-11'

Calendars #

Temporal supports calendars. Browsers and runtimes ship with a set of built-in calendars, which lets you represent, display, and do arithmetic in a user's preferred calendar system, not just format a Gregorian date differently.

Because Temporal objects are calendar-aware, operations like "add one month" are performed in the rules of that calendar, so you land on the expected result. In the example below, we add one Hebrew month to a Hebrew calendar date:

const today = Temporal.PlainDate.from("2026-03-11[u-ca=hebrew]");
today.toLocaleString("en", { calendar: "hebrew" });
// '22 Adar 5786'

const nextMonth = today.add({ months: 1 });
nextMonth.toLocaleString("en", { calendar: "hebrew" });
// '22 Nisan 5786'

With legacy Date, there's no way to express "add one Hebrew month" as a first-class operation. You can format using a different calendar, but any arithmetic you do is still Gregorian month arithmetic under the hood.

If you tried to approximate this with Date, it might look like:

const legacyDate = new Date(2026, 2, 11);
legacyDate.toLocaleDateString("en", { calendar: "hebrew" });
// '22 Adar 5786'
legacyDate.setMonth(legacyDate.getMonth() + 1);
legacyDate.toLocaleDateString("en", { calendar: "hebrew" });
// '24 Nisan 5786'

This adds one Gregorian month (March → April). When you then display the result in the Hebrew calendar, you land on a different day, 24 Nisan rather than 22 Nisan, because the calendars don't have the same month structure or month lengths.

Temporal.Duration #

Our final type is Temporal.Duration. Duration is straightforward and can be used with any of the other types when adding and subtracting. Another useful feature of Duration is showing it in different units, like the example below:

const duration = Temporal.Duration.from({
  hours: 130,
  minutes: 20,
});

duration.total({ unit: "second" }); // => 469200

Most datetime libraries already have a duration type, so it made sense to include one. It also complements the other types by allowing the developer to compare Times or DateTimes and getting back a Duration type.

Implementation #

Implementing Temporal was a challenge. It is a very large proposal that brings more changes to JavaScript than any other proposal in the programming language's history. Some specific challenges include:

This GIANT spec is bigger than all of ECMA-402 (The Internationalization spec); this made it hard (but not impossible) for a single person to implement
The volatility of the spec created a moving target. There have been changes to the spec over the years, which meant implementations have struggled to keep up.
Browsers demand that nearly all aspects are efficient and performant.

Temporal is the biggest addition to ECMAScript since ES2015

Whilst Firefox was able to implement Temporal as it was being specced - thanks to the great work of André Bargull (known online as Anba) - not all browsers or engines were able to work on Temporal during its earlier stages. This means that a lot of catch-up was needed by the later parts of Stage 3.

Temporal, by the number of tests added to the official test suite for ECMAScript (Test262), is the biggest addition to the ECMAScript spec. Temporal today has ~4,500 tests, a high number compared to some of the other built-ins, including its predecessor, Date.

In the June 2024 plenary, the Google Internationalization team and Boa decided to collaborate on the implementation of Temporal and to work on a Rust library that could serve both engines. The library is called temporal_rs. Over the course of 2024 and 2025, it ramped up the implementation of Temporal thanks to the work of Kevin Ness, Manish Goregaokar, Jose Espina and students from the University of Bergen. Today temporal_rs passes 100% of all tests and now serves other engines outside of V8 and Boa!

temporal_rs is pretty unconventional. It's rare, if not unprecedented, for multiple engines to collaborate on a shared library to implement a TC39 proposal. Not only did this work, but also it was a huge success. temporal_rs meant that there was:

Reduced barrier to entry: The students and other collaborators didn't need to understand the V8 or Boa codebase to contribute to the library.
Improved long-term maintenance: temporal_rs has a team of maintainers who will continue to work on the library even after Temporal has reached Stage 4. This provides developers with a stable location to raise issues, report bugs, or even contribute improvements themselves with engines as stakeholders.
Higher quality code to review: Because temporal_rs is scoped as a library, it means that reviewing it was easier because you didn't need the context of a whole engine. Also the library uses modern Rust features, such as the built-in linting (Clippy), formatting (Rustfmt), and CI tests against engines.

Shipped & Standardized #

Earlier today, Temporal reached Stage 4 in the TC39 staging process, which means it will be part of the next annual ECMAScript specification (ES2026). However, you don't need to wait until then - you can use it today!

Temporal is already supported across:

Firefox v139 (since May 2025)
Chrome v144 (since January 2026)
Edge v144 (since January 2026)
TypeScript 6.0 Beta (since February 2026)
Safari (Partial Support in Technology Preview)
Node.js v26 (TBC)

What's Next? #

There's still plenty of work to do for Temporal, such as figuring out how it integrates with the rest of the Web ecosystem. We've had years of Web APIs working with or around the Date object, and those same APIs must be compatible with Temporal objects too. Here are some examples:

Integration With Date Pickers #

Developers will want to use Temporal with date pickers. Right now, that isn't possible (it may be possible to patch via a polyfill but there is nothing in the standard today). As we improve the ergonomics of using Temporal, we will need to add support in areas where Date is used today. One example is input types that are datetime related. See below:

<input type="date" />
<!-- element.valueAsPlainDate -->
<input type="time" />
<!-- element.valueAsPlainTime -->
<input type="week" />
<!-- element.valueAsPlainDate -->
<input type="month" />
<!-- element.valueAsPlainYearMonth -->

Supplementing DOMHighResTimeStamp #

Due to Temporal Instants supporting time down to nanoseconds, they could be used anywhere a DOMHighResTimeStamp is used. In the following example, we can use an Instant to set a cookie expiry, where normally we would have previously used a DOMHighResTimeStamp.

cookieStore.set({
  name: "foo",
  value: "bar",
  expires: Temporal.Now.instant().add({ hours: 24 }).epochMilliseconds,
});

And there's certainly more. What is certain is that the JavaScript community will continue working hard to bring Temporal not only to the Web platform, but also any other libraries that make use of Date today.

A Better Time for JavaScript #

Temporal is the result of nearly a decade of work across companies, engines, and individuals. It represents:

Years of consensus-building inside TC39 that was informed directly by the ecosystem's prior art
Implementation work across multiple JavaScript engines
Collaboration between Microsoft, Google, Mozilla, Bloomberg, Igalia, Boa, and many independent contributors
And a rare example of shared infrastructure in the form of the temporal_rs library

We are proud to have funded and supported Igalia's work on Temporal for many years. That investment, combined with open collaboration, successfully helped move the proposal from idea to specification to shipping reality.

The success of temporal_rs demonstrates something important: new language features don't have to mean duplicated effort across engines. Shared, high-quality open source infrastructure can reduce costs, increase consistency, and accelerate innovation across the Web ecosystem.

Temporal is not just a better API. It's proof that the JavaScript community can solve long-standing problems together.

After nearly 30 years, JavaScript finally has a modern datetime API.

And this time, we got it right.

Source Maps: Shipping Features Through Standards

2026-03-10T00:00:00Z

Source maps are a vital part of modern web development. Today, we have an official standard, a large group of members, and many exciting features in development! But it wasn't always this way.

It may surprise you to learn that, for years, there was no official standard describing the source map format. On one hand, it is incredible that for 10 years, bundlers, browsers, and devtools worked together with only a shared Google Doc between them! On the other hand, it became impossible to add new features, deprecate old features, and build the necessary devtools to support dozens of deviations.

Why do we need Source Maps? #

Web development used to be simple! You’d write a bit of JavaScript, stick it in a <script> tag, and send it to your users. This also made debugging very simple: the code that ran on the website was the exact code you authored.

As web development became more complex, tools began to emerge to optimize large JavaScript applications. In 2009, Google released Closure Tools, a suite of tools meant to address the growing complexity with applications like Google Maps, Google Docs, and Gmail.

Closure Tools consisted of four discrete tools: an optimizing compiler, a template language, a JavaScript framework, and a developer tool. The compiler would eventually become Google’s Closure Compiler and the developer tool would heavily influence the future of Chrome DevTools.

The compiler and devtools have always gone hand-in-hand, and they form an important relationship that exists to this day. If developers are going to use a compiler to optimize, minify, and alter their source code, they will need devtools that will allow them to map the generated compiler output back to their source code! That is exactly the gap that source maps address.

What’s inside a source map? #

Now that we know what purpose source maps serve, let’s dive into what information is inside a source map file.

A source map is just a JSON file. Although some of the fields include encoded data, it should be mostly readable if you open a .map file in your favorite IDE. As an example, in out.js.map, you'll probably see something like this:

{
  "version": 3, // Always the integer 3
  "file": "out.js", // Optional: name of the generated file
  "sourceRoot": "", // Optional: prefix prepended to each entry in "sources"
  "sources": ["foo.js", "bar.js"], // Required: list of original source URLs/paths (or null)
  "sourcesContent": [null, null], // Optional: inlined source text, aligned with "sources"
  "names": ["src", "maps"], // Optional: symbol names referenced by "mappings"
  "mappings": "A,AAAB;;ABCDE", // Required: encoded mapping data (base64-VLQ deltas)
  "ignoreList": [0] // Optional: indexes into "sources" considered "third-party"
}

We can interpret most of the file simply by reading it! It has the name of the generated JavaScript file, the one or more source files that went into it, what code was in each of those files, and a list of any files to mark as third-party or library code! The only part we can’t read plainly is the mappings field.

How mappings work #

Let’s think about mappings for a minute. What information would we need to accurately trace the location where a developer might set a breakpoint in a generated file like bundle.js all the way back to the exact file and position it came from in a source file like App.ts?

What information do we need in mappings? #

All we really need is:

For the generated file
- Filename
- Line
- Column
For the source file
- Filename
- Line
- Column

Conceptually, we could imagine representing these with arrays of numbers, assuming we also had an array of file names. We could design something like:

{
  "sources": ["foo.js"], // One original source file
  "mappings": [
    [0, 1, 2] // "sources" index 0, line 1, column 2
  ]
}

But now we need a way to map a position in the generated code to one of these mappings. So maybe we add a new field that contains mappings for each line in the generated file, pointing to an entry in our mappings array! Something like:

{
  "sources": ["foo.js"], // One original source file
  "mappings": [
    [0, 1, 2], // "sources" index 0, line 1, column 2
    [0, 1, 20]
  ],
  "lineMaps": [
    [1, 1, 1, 1, 1, 2, 2, 2, 2, 2] // The first 5 columns all map to the first entry in the `mappings` array and the rest map to the second entry
  ]
}

You could reduce the source map size by omitting duplicates in the lineMaps array. So, the same information could be represented like:

{
  "sources": ["foo.js"], // One original source file
  "mappings": [
    [0, 1, 2], // "sources" index 0, line 1, column 2
    [0, 1, 20]
  ],
  "lineMaps": [
    [1, , , , 2, , , , 2] // The first 5 columns all map to the first entry in the `mappings` array and the rest map to the second entry
  ]
}

This would work nicely! The only real problem is, lineMaps is going to be enormous for large files. Even using sparse arrays, you will have an array entry per character! Even a modest web app, when minified, will contain between 200,000 and 2,000,000 characters.

This per-character mapping model was actually used in early source map revisions (1 and 2), before being replaced in Revision 3.

Revision 3: The modern source map #

Reducing the size of source maps became a top priority as JavaScript bundles grew into hundreds of thousands, and eventually millions, of characters.

Revision 3 (written in 2011, still the format we use today) made four key architectural changes to dramatically shrink map size:

Moved from per-character mapping IDs to segment-based source location entries
1. Instead of mapping each character in a generated file, it only keeps track of where the mapping changes.
mappings is now a string, containing segments encoded using Base64 VLQ
Removed the lineMaps array
1. Instead of two arrays that reference each other, we now have one mappings string, which encodes, for each segment, the:
  1. Generated column
  2. Source index
  3. Original line
  4. Original column
  5. Optional name index
2. Note: Generated lines are separated by ; in the mappings string.
Switched from absolute to relative encoding
1. Instead of storing generatedColumn: 120, we now store generatedColumn: +3.

With Revision 3, the source map above can be represented like:

{
  "version": 3,
  "file": "bundle.js",
  "sources": ["foo.js"],
  "names": [],
  "mappings": "AAAE,KAAI"
}

These changes mean source maps are much smaller (thanks to VLQ) and much easier to encode and decode.

A decade without a standard #

Revision 3 landed in 2011 and it worked well! It worked so well that the entire web ecosystem decided to stop touching it for years. New bundlers spun up, emitting Revision 3 source maps, while browsers continued to build devtools that would consume Revision 3 source maps.

Things were going great in the sense that breakpoints always landed in "roughly" the right spot. But the state it was in made it impossible to add new features, deprecate old behaviors, or correct ambiguity.

Adding a new feature without a standard #

Despite the complications, one new feature did manage to make its way through the ambiguity and into bundlers and devtools alike!

As JavaScript frameworks began to grow in popularity, a common problem that faced developers was the need to step through callstacks consisting of dozens of framework files and only a few files they authored. In 2014, Google’s Chrome DevTools allowed developers to create ignore lists, specifying files or patterns they wished to exclude from stack traces and step-through debugging.

This was great, but it would be far better if bundlers could let devtools know which files to ignore without forcing the developer to manually go through and list files. To solve this problem, in 2022, Google began looking for an x_google_ignoreList array inside source maps. If found, they would automatically add any files in the array to their DevTools ignoreList.

This feature was so popular that Firefox began to support x_google_ignoreList in 2023! This is an amazing success story about open source tooling, web frameworks, and browsers collaborating without a formal group or standard. However, it also made it abundantly clear that we needed an easier way to communicate.

While adding the ignoreList was successful, most large companies wanted a way to decode function names in stack traces, and this became incredibly difficult to coordinate without a standard.

Imagine the following code:

// sample.js
const penne = () => {
  throw Error();
};
const spaghetti = () => penne();
const orzo = () => spaghetti();
orzo();

If you don’t transpile, optimize, or bundle your code, you will get perfectly readable stack traces! But if you do, you will likely end up reading through callstacks with single letter function names that are impossible to trace back to your source code.

// **original** output                           // **compiled** output
Error                                            Error
    at penne (sample.js:2:33)                        at r (out.js:1:82)
    at spaghetti (sample.js:3:25)         vs         at o (out.js:1:97)
    at orzo (sample.js:4:25)                         at n (out.js:1:107)

To solve this problem, Bloomberg created pasta-sourcemaps. Pasta takes advantage of the same x_ prefix by adding a x_com_bloomberg_sourcesFunctionMappings to our source maps. We can then parse this list back out in our devtools and apply the original function names back to the stack traces.

Though this feature was wanted by all browsers and most devtools, it was too large and too complex to simply ship. Although Chrome did ship support for pasta-sourcemaps behind a flag, it became abundantly clear we needed an official group to discuss this feature’s intricacies.

TG4 #

In 2023, Bloomberg set out to begin the process of standardizing source maps. We began, as many inspirational tech stories do, meeting in a humble Google office in Munich. We gathered a group of engineers from Bloomberg, Google, Mozilla, Vercel, Igalia, and JetBrains and began organizing years worth of questions and confusions around source maps from the ecosystem-at-large.

With our new group of constituents involved in browsers, devtools, compilers, and open source, we shopped around for a "venue" for the source map standard and landed on Ecma International, the same industry association that TC39 uses.

In October of 2023, we became an official Task Group underneath the TC39 umbrella.

Our Task Group (TC39-TG4) spent 2024 working through an enormous backlog of issues filed against source maps. Topics discussed included improving correctness, formalizing unofficial features, writing specification text, creating tools to validate and test source maps, and new features we would add after we became an official standard.

At the end of 2024, we were officially standardized as ECMA-426.

Future Work #

In 2025, we began to dream big with ideas for new features. We came up with five ideas and began work to implement two of them: Scopes and Range Mappings.

Scopes #

The Scopes proposal builds off Bloomberg’s pasta-sourcemaps, but generalizes the idea far beyond function names. The goal is to let source maps reflect the realities of modern JavaScript compilation by embedding scope and binding information directly into the map (instead of forcing devtools to re-parse your sources and "guess").

That gives bundlers and devtools a common language to communicate things like:

Functions that were inlined by the compiler
- So a debugger can reconstruct missing stack frames, and "Step Over / Step Out" behaves like the original code even when the runtime no longer has a real function boundary.
Variables that were renamed, folded, or erased
- Including cases like minification renaming, constant folding, or compilation patterns where a "real" authored binding doesn't exist as a variable in generated JavaScript at all.
The scopes that were removed or introduced by transforms
- So devtools can hide compiler-internal frames/scopes, and revive original ones, without each tool inventing its own heuristics.
How to compute a binding's value in generated code
- The proposal can encode expressions a debugger can evaluate in the generated scope to present the "original" binding value back to the user.

Range Mappings #

Range Mappings is a much smaller (but extremely practical) idea: sometimes we want a mapping to apply to an entire range of text, not just a single point.

Today, mappings are essentially "pins" in the generated file. If a tool asks "what is column 137 mapped to?" and there isn’t an exact pin at 137, consumers usually fall back to the closest previous mapping on that line. That loss of precision becomes especially painful when you try to compose source maps (TypeScript to JS, then JS to minified JS), because you can only reliably compose mappings that exist in both maps at exactly the right places.

Range mappings address this by letting a generator mark specific mappings as "range mappings," meaning:

Assume every character after this mapping (up to the next mapping) is mapped by applying the same offset into the original source.

In other words, you get the precision of "map every character," without actually emitting a mapping per character. This is particularly powerful for transforms like "strip types," in which huge stretches of runtime code are identical.

To avoid breaking the mappings field, the proposal adds a new field, rangeMappings, that encodes (per generated line) which mapping segments should be treated as range mappings.

Range Mappings Example #

Imagine you have a JavaScript file with a comment at the top that you plan to strip out.

// header comment we will strip
console.log("hi");

After you compile it, you get this result:

console.log("hi");

Without Range Mappings, the source map for the following operation would look like:

{
  "version": 3,
  "file": "out.js",
  "sources": ["input.js"],
  "sourcesContent": ["// header comment we will stripnconsole.log('hi');n"],
  "names": [],
  "mappings": "AACA"
}

This works well, except we will lose all column precision. The source map says "I know things on line 1 used to be on line 2," but that’s all.

With Range Mappings, we can specifically say that line 1 used to be on line 2 and it is a range mapping, so preserve the column information!

{
  "version": 3,
  "file": "out.js",
  "sources": ["input.js"],
  "sourcesContent": ["// header comment we will stripnconsole.log('hi');n"],
  "names": [],
  "mappings": "AACA",
  "rangeMappings": "B"
}

This approach allows browsers to provide greatly improved experiences with their console and step-through debugging, with no added cost to the user.

Wrapping up #

For years, source maps have "just worked" based on a shared understanding across browsers and tools. ECMA-426 gives us a real specification and a place to evolve.

This process has been an incredible ride, and I think it really highlights the best parts of open source. So many people with knowledge to share have put in hard work to benefit the entire JavaScript ecosystem.

If you’re a bundler author, a devtools engineer, or you maintain anything that produces or consumes source maps (error monitoring, replay debuggers, etc), TG4 is exactly where we want your input. The proposal work is happening in the open and we would love to hear from you!

If you are a consumer of source maps, stay tuned! Scopes and Range Mappings will be coming to browser devtools near you soon!

Intro

2026-03-09T00:00:00Z

Hello, world 👋

This is a new blog written by engineers, for engineers. On it, we will be publishing technical content from Bloomberg folk who work on our thriving JavaScript environment. This also includes web/web-adjacent technologies, and it very much includes TypeScript. After all, TypeScript is JavaScript plus types.

Why now? A better question is perhaps: why not sooner? For more than 20 years, JavaScript has powered the Bloomberg Terminal, which is used by more than 350,000 financial professionals around the world. During this time, thousands of Bloomberg engineers have shipped more than 10,000 apps, accumulating more than 100 million lines of server-side and client-side JavaScript code. We have a strong interest in maintaining open web technology (as well as the adjacent runtimes and tooling) as a robust, long-lived technology basis for our business. Correspondingly, for over a decade, we've participated seriously in the broader web community through technical contributions to its foundations, financial support, and deep engagement in standards groups like TC39.

Much of this participation has long been visible through a variety of sources (but only if you know where to look). It includes:

Our firm’s public GitHub repo and open source projects we’ve published for the JS community (like Stricli and ts-blank-space);
Proposals for new JavaScript features (like Array.prototype.toSorted and Promise.withResolvers);
Various TypeScript language features seen in TypeScript 3.8, 4.3, and 5.5;
Contributions to JavaScript tooling (including pasta-sourcemaps) and Node.js;
New web performance metrics (like Container Timing);
Conference talks (such as at JSConf and Perf.now) and social media;
Hosting meetups, collaboration summits, standardization meetings; and
Occasional long-form guest blog posts.

A lot of this has been done in collaboration with partners such as Igalia, as well as institutions such as Ecma International, OpenJS, Unicode, and the W3C.

But we've never had a central place to bring it together to share what we've done or what we're up to next. This new blog will hopefully solve that problem!

Stay tuned for some exciting posts in the next few days! 😉