Alternative Assets, Open Source Infrastructure and Data Standards

Posted on by Rob Larsen

For the past few years, a big portion of my professional energy has been focused on managing scale, overseeing engineering teams, and navigating corporate technology strategy in private equity and traditional asset management. Global finance!

It was challenging work, but it pulled me away from a fundamental truth: I am a builder who loves to solve interesting technical problems.

I’m fixing that starting now. I’m looking to once again consult full-time (more on that later) and I’m going to start to put significant effort into open source once again.

To kick off this chapter, I have launched a new foundational project alongside my longtime stewardship of the HTML5 Boilerplate (H5BP) organization (more news on that to come!)

Introducing alt-asset-spec

The alternative asset market—encompassing everything from high-end collectible comic books to luxury watches—has scaled into a sophisticated, multi-billion-dollar industry. However, the data architectures running beneath modern marketplaces are incredibly fragmented, relying on siloed, proprietary schemas to track historical records.

alt-asset-spec is an open-source, type-safe TypeScript specification designed to standardize fields for asset authentication, deep provenance ledgers, and transaction velocity. I am actively using this standard to migrate and unify my own extensive, multi-decade comic book market research databases to battle-test its structural integrity.

What’s Next

  • This site, along with my GitHub and my YouTube channel, will be moving back to active status. That’s going to be a lot of fun.
  • Review the Code: You can track the active commits, open issues, or contribute to the new data standard directly on the alt-asset-spec repo.
  • Let’s Build: If your startup or platform is scaling high-throughput architecture or navigating complex data integrity bottlenecks, let’s connect via Palatino Consulting.

Let’s have some fun!

Why Tooling Performance is No Longer a “JavaScript” Problem. Let’s Go?

Posted on by Rob Larsen

In general, the JavaScript ecosystem has operated under a simple rule: web development tools should be written in web development languages. Since we could (thanks Node,etc.) we should! I remember when this started and it’s been fun, of occasionally frustrating as we inevitably ran into performance issues as JavaScript codebases got larger and larger and more complex.

We accepted the overhead as the cost of a unified ecosystem. Which, in a lot of ways, makes sense. I certainly appreciate the fact that I can, with my primary language of choice (JavaScript in one form or another) work from snout to tail on the tools that drive development for me.

With the public preview of TypeScript 7.0 (Beta), Microsoft has officially flipped the script. The headline change of the 7.0 release isn’t a shiny new type utility or fancy syntax. It is a complete structural migration. The core compiler and type-checking engine have been systematically ported from TypeScript/JavaScript into Go, exposed through a new native binary executable called tsgo. The results are apparently crazy. In large monorepos and sprawling enterprise codebases (like the VS Code repository) compilation and type-checking benchmarks are clocking in at up to 10 times faster, while memory footprints drop by more than half. That’s nutty.

What makes Project Corsa (the codename for the native rewrite) brilliant is its conservatism. The TypeScript team didn’t try to reinvent the type system or fix decades-old design quirks from scratch. Instead, they focused on absolute semantic parity. The Go codebase was methodically mapped against the existing compiler’s behavior. It is designed to pass tens of thousands of legacy compliance tests, ensuring that the structural identity of your current types remains completely unchanged. It scales file parsing and emit pipelines natively across hardware threads using Go’s concurrency primitives, bypassing the single-threaded bottlenecks and V8 heap limits that have plagued massive tsc processes for years.

Developers can test the native performance gains today by fetching the preview package:


npm install -D @typescript/native-preview@beta
npx tsgo --noEmit

For teams running massive pipelines where type-checking acts as a persistent bottleneck, tsgo is a massive win.