DEV Community: Islam Hafez

You Don't Use Linked Lists. But They're Running Half Your Software.

Islam Hafez — Sat, 27 Jun 2026 14:13:23 +0000

The data structure everyone learns for interviews and forgets by Monday — and why that's exactly backwards.

Here's the honest version of what most linked list tutorials skip:

You are almost certainly never going to write a linked list in JavaScript. Not in production. Not in a side project. Your language's built-in array already handles dynamic sizing, and it does it faster than a linked list in most cases, for reasons we'll get into. The interview circuit trained you to implement one on a whiteboard, and that's fine — but it created the wrong mental model. You walked away thinking linked lists are a data structure you might use. They're actually a data structure you need to understand — because they're hiding inside the tools you use every day, and knowing they're there changes how you reason about performance.

Your browser's back/forward navigation? Doubly linked list. Your text editor's undo history? Doubly linked list. The LRU cache inside every high-traffic web server, CDN, and database query optimizer? A doubly linked list fused with a hash map. Redis's LPUSH/RPUSH commands operate on a linked list. The Node.js event queue has linked list characteristics. The Linux kernel's process scheduler uses circular doubly linked lists internally.

They're not a relic. They're infrastructure. You just can't see them because they're one layer below where you usually work.

So let's learn them the right way — starting with the hardware, not the textbook.

Why Memory Layout Is the Whole Story

Before you write a single node, you need to understand the one thing that determines when a linked list wins and when it loses: cache locality.

Your CPU doesn't read from RAM one byte at a time. It's too slow for that — a RAM access takes 200–300 CPU cycles, while a cache hit takes 4. So the CPU plays a prediction game: when you access a memory address, it automatically pulls in the surrounding 64 bytes (a "cache line") on the assumption that you'll need nearby data next. This is called spatial locality, and it's why arrays are fast.

When you store an array of numbers, they sit next to each other in memory. When you loop over them, the CPU loads the first element — and gets the next 15 for free in the same cache line. It's reading ahead before you even ask.

Array in memory:
[ 10 | 20 | 30 | 40 | 50 | 60 ] → contiguous, cache-friendly
  ^                               one cache fetch, all 6 loaded

A linked list destroys this. Each node is a separate heap allocation, scattered wherever the allocator found space. Following a next pointer means jumping to an arbitrary memory address — potentially on a completely different cache line, triggering a new RAM fetch, costing those 200–300 cycles, every single time.

Linked list in memory:
[10 | ptr] ──→ [20 | ptr] ──→ [30 | ptr]
 0x1a04          0x7f82         0x3c11
 (separate allocations, scattered across memory)

In practice, benchmarks consistently show linked list traversal running 10–100x slower than array traversal for large datasets — even though both are O(n) on paper. Big-O notation lies to you about this. It ignores constants, and the constant for "RAM access" is enormous on modern hardware.

This isn't a reason to dismiss linked lists. It's the reason to understand exactly when their advantages outweigh this cost. That answer is more specific than most tutorials admit.

Singly Linked List — The Minimal Form

A singly linked list is a chain of nodes where each node holds data and a pointer to the next node. That's it. No backward travel. No shortcuts.

class Node {
  constructor(value) {
    this.value = value;
    this.next = null;
  }
}

class SinglyLinkedList {
  constructor() {
    this.head = null;
    this.size = 0;
  }

  // O(1) — we know exactly where the head is
  prepend(value) {
    const node = new Node(value);
    node.next = this.head;
    this.head = node;
    this.size++;
  }

  // O(n) — must walk to the end
  append(value) {
    const node = new Node(value);
    if (!this.head) {
      this.head = node;
    } else {
      let current = this.head;
      while (current.next) current = current.next;
      current.next = node;
    }
    this.size++;
  }

  // O(n) — must walk to find it
  delete(value) {
    if (!this.head) return;

    if (this.head.value === value) {
      this.head = this.head.next; // drop the head, O(1)
      this.size--;
      return;
    }

    let current = this.head;
    while (current.next) {
      if (current.next.value === value) {
        current.next = current.next.next; // skip the node, O(1) once found
        this.size--;
        return;
      }
      current = current.next;
    }
  }

  toArray() {
    const result = [];
    let current = this.head;
    while (current) {
      result.push(current.value);
      current = current.next;
    }
    return result;
  }
}

Notice something about delete: finding the node is O(n), but the actual removal is O(1) — you just redirect one pointer. No shifting. No copying. No reorganizing memory. Compare that to an array, where deleting from the middle means shifting every subsequent element one position left — O(n) work even after you found the element.

This is the trade-off in one sentence: linked lists pay for access with their insertion/deletion advantage.

The singly linked list's natural shape is a stack — you push and pop from the head, both O(1), never need to go backward. It also fits a task queue where you only ever consume from one end.

What it genuinely can't do: random access. If you want the 500th element, you walk 500 nodes. There's no formula. This alone disqualifies singly linked lists from most use cases where you're searching or indexing.

Doubly Linked List — Where It Gets Actually Useful

Add a prev pointer to every node and something real changes: you can traverse in both directions, and — critically — you can remove a node in O(1) if you already have a reference to it.

class DNode {
  constructor(value) {
    this.value = value;
    this.next = null;
    this.prev = null;
  }
}

class DoublyLinkedList {
  constructor() {
    this.head = null;
    this.tail = null;  // tail pointer makes append O(1)
    this.size = 0;
  }

  // O(1) — we hold both ends
  prepend(value) {
    const node = new DNode(value);
    if (!this.head) {
      this.head = this.tail = node;
    } else {
      node.next = this.head;
      this.head.prev = node;
      this.head = node;
    }
    this.size++;
  }

  // O(1) — tail pointer, no walking required
  append(value) {
    const node = new DNode(value);
    if (!this.tail) {
      this.head = this.tail = node;
    } else {
      node.prev = this.tail;
      this.tail.next = node;
      this.tail = node;
    }
    this.size++;
  }

  // O(1) — given the node directly, no searching required
  removeNode(node) {
    if (node.prev) node.prev.next = node.next;
    else this.head = node.next; // it was the head

    if (node.next) node.next.prev = node.prev;
    else this.tail = node.prev; // it was the tail

    node.next = node.prev = null;
    this.size--;
  }

  // O(1) — both ends accessible instantly
  removeHead() { if (this.head) this.removeNode(this.head); }
  removeTail() { if (this.tail) this.removeNode(this.tail); }
}

The removeNode(node) method is the entire reason doubly linked lists exist in serious systems. When you have a direct reference to a node — not a value you need to search for, but the actual node object — deletion is just pointer surgery. Four pointer updates. Done.

This changes everything for the use case that actually matters.

The One Pattern Where Linked Lists Are Irreplaceable

The LRU (Least Recently Used) cache is the canonical real-world use case — and it's worth understanding in detail because it appears in CDN edge nodes, database query planners, CPU cache replacement policies, DNS resolvers, and web server in-memory caches.

The problem: you have a cache with limited capacity. When it's full and you need to add something new, you evict the item that was accessed least recently. You need:

O(1) lookup: "Is this key in the cache?"
O(1) insert: "Add this new key-value pair"
O(1) eviction: "Remove the least recently used item"
O(1) promotion: "This key was just accessed, move it to 'most recently used'"

An array can't do this. When you access an item, you need to move it to the "recently used" position — that's O(n) shifting. A hash map alone can't do it either — it has no concept of order.

The solution is a doubly linked list paired with a hash map:

class LRUCache {
  constructor(capacity) {
    this.capacity = capacity;
    this.map = new Map();       // key → node (O(1) lookup)
    this.list = new DoublyLinkedList(); // ordered by recency
  }

  get(key) {
    if (!this.map.has(key)) return -1;

    const node = this.map.get(key);
    this.list.removeNode(node);   // O(1) — we have the node directly
    this.list.prepend(node.value); // O(1) — move to head (most recent)
    this.map.set(key, this.list.head);

    return node.value.val;
  }

  put(key, val) {
    if (this.map.has(key)) {
      this.list.removeNode(this.map.get(key)); // O(1)
    } else if (this.list.size >= this.capacity) {
      // evict the tail — it's the least recently used
      this.map.delete(this.list.tail.value.key);
      this.list.removeTail(); // O(1)
    }

    this.list.prepend({ key, val }); // O(1)
    this.map.set(key, this.list.head);
  }
}

Every operation is O(1). The hash map gives instant lookup. The doubly linked list maintains order and provides O(1) removal because we store the node reference in the hash map — we never search for the node, we go directly to it.

This is the move that makes the whole structure work. The hash map stores node references, not values. When we access a key, we pull the node directly out of the middle of the list and move it to the head — no traversal. That's only possible with a doubly linked list where removeNode doesn't require knowing where the node is in the sequence.

The Honest Comparison

Most tutorials give you a comparison table. Here's one that's actually honest about modern hardware:

Operation	Array	Singly LL	Doubly LL
Access by index	O(1)	O(n)	O(n)
Search by value	O(n)	O(n)	O(n)
Insert at head	O(n) — shift all	O(1)	O(1)
Insert at tail	O(1) amortized	O(n) or O(1) w/ tail ptr	O(1) w/ tail ptr
Delete at head	O(n) — shift all	O(1)	O(1)
Delete in middle (by value)	O(n) find + O(n) shift	O(n) find + O(1) remove	O(n) find + O(1) remove
Delete by node reference	—	—	O(1) ← the whole game
Memory per element	Low (just data)	Medium (+1 pointer)	Higher (+2 pointers)
Cache performance	Excellent	Poor	Poor
Traversal speed in practice	~10–100x faster	Slow	Slow

The "delete by node reference" row is the one that matters. It's the entire reason doubly linked lists exist in production systems. Everything else, arrays do better or equal for most workloads — because of cache locality, not because of Big-O.

If you're choosing between array and linked list for a problem where you're iterating through data, an array wins even if your Big-O analysis says they're equal. The constant factor of cache performance is that significant.

When to Actually Use Each One

Reach for a singly linked list when:

You're building a stack and want textbook clarity (though an array works fine here too)
You're implementing something where you only ever add/remove from one end
Memory is extremely tight and you can't afford the extra prev pointer

Reach for a doubly linked list when:

You need O(1) deletion and you'll have direct node references (LRU cache, undo history where each action holds its own node)
You're building anything that requires backward traversal without a second pass
You're implementing a deque (double-ended queue) with O(1) operations at both ends

Don't reach for either when:

You're just storing and iterating over data — use an array
You need frequent random access — use an array
You're searching by value — use a hash map or sorted array with binary search

The deeper point: linked lists are most valuable not as standalone structures but as the ordered component inside composite structures. The LRU cache doesn't use a linked list instead of a hash map — it uses them together. That combination produces something neither could achieve alone. That's the real lesson.

Where They're Already Running in Your Stack

Without writing a single line of linked list code, these structures are running around you right now:

Node.js — The timers module maintains doubly linked lists to track setTimeout/setInterval expiry. The http module uses them for connection pools.

V8 (Chrome's JS engine) — The garbage collector uses linked list-like structures to track object generations and manage the free list of available memory blocks.

Redis — LPUSH/RPUSH/LPOP/RPOP operate on a linked list. Redis lists are actually a hybrid (ziplist for small sizes, linkedlist for large), but the interface is a linked list.

Linux kernel — The process scheduler's run queue is a doubly linked list. The list_head structure in the kernel source is one of the most used data structures in any OS codebase.

Your browser's navigation — Every window.history.back() and window.history.forward() is a doubly linked list traversal.

You've been using linked lists constantly. You just didn't know their name.

The Real Reason to Learn This

Interview prep is the wrong motivation to learn linked lists. The right motivation is this: understanding why a doubly linked list paired with a hash map gives you O(1) everything for an LRU cache — that kind of reasoning is what separates engineers who design systems from engineers who just implement requirements.

When someone at a senior system design interview says "we need an LRU cache with O(1) get and put" and you immediately know the structure — and, more importantly, you know why that structure works at the hardware level — that's not trivia. That's thinking.

The data structure is simple. The thinking behind it isn't.

Code examples are in JavaScript for readability. The concepts apply identically in Python, Go, Rust, or any other language. In production systems you'd typically use the language's built-in deque or list structures rather than rolling your own — but understanding the internals is exactly the point.

Cheers !

Monolithic vs Microservices

Islam Hafez — Sun, 21 Jun 2026 10:02:55 +0000

Intro

Ever heard the words "monolithic" and "microservices" tossed around in tech conversations? Don't worry if they sound a bit confusing – you're not alone! These terms are hot topics in the world of software design, and for good reason.

In this article, we're going to break down what monolithic and microservices mean. We'll compare them in simple terms and talk about when you might want to use each one.

Monolithic and microservices are both types of software architecture. In simple terms, architecture is just a fancy word for the overall design of a computer program - it's the plan that lays out how all the pieces of the software will fit and work together. These are just different ways to build web applications.

We are going to understand each architecture with the help of an example.

We'll consider designing an online travel booking web application that offers hotel reservations, flight bookings, and train ticket purchases, along with payment processing and user account management for understanding these architectures.

We will be discussing these architectures concerning backend logic.

Monolithic

In a monolithic architecture, we would design the application as a single, unified system. All the code for every feature would reside within one codebase(project). This includes:

Hotel booking functionality
Flight reservation system
Train ticket booking
Payment processing
User authentication (sign-up and login)

The entire codebase, encompassing all these functions, operates as one cohesive unit.

In a monolithic architecture, you build and deploy the entire application as one single unit. This means you have to use just one technology stack for the whole app, whether it's Java with Spring Boot, Python with Django, JavaScript with Node.js, or any other combination.

Monolithic architecture is often the go-to choice for small startups, personal projects, or companies that don't deal with a huge user base.

Benefits of Monolithic Architecture

Easier to Develop:

You work with a single codebase, which means less complexity to manage.
All parts of your application are in one place, making it simpler to understand the overall structure.
When you need to add new features, you can easily integrate them into the existing codebase.
Testing is more straightforward because you can run all tests in one go.

Easier to Manage:

Deployment is simpler because you're dealing with just one application.
You only need to monitor and maintain a single system.

These advantages make monolithic architecture a practical choice for smaller projects or teams that want to get their application up and running quickly without dealing with the complexities of more distributed systems.

Challenges with Monolithic Architecture

Some major issues that come with using a monolithic architecture include:

Single Point of Failure

In a monolithic setup, all parts of the application are tightly interconnected. This means if something goes wrong in one area—like a bug or performance issue—it can affect the entire system. Imagine if a glitch in one feature causes the whole app to crash, leaving users unable to access anything. This dependency on a single codebase makes the system vulnerable to widespread failures, impacting reliability and user experience. It also limits flexibility in updating and scaling different parts of the app independently, which can lead to more downtime and operational headaches.

Redeployment

Imagine we need to make a minor update to improve the payment functionality in our application. Even though it's a small change, we have to redeploy the entire app. This can be incredibly frustrating. A simple tweak to one part of the system forces us to go through the whole deployment process again, involving all components of the app, even those not affected by the change. This not only wastes time and resources but also increases the risk of introducing new bugs and downtime, making the process unnecessarily cumbersome.

Scaling Issues

When user traffic spikes, a monolithic application can struggle to cope. Every part of the app—from hotel bookings to payments—feels the strain on the single server. This overload leads to slow responses, timeouts, and errors, frustrating users.

To manage increased traffic, you typically need to scale horizontally by deploying multiple copies of the entire app across many servers.

However, this method is inefficient because it requires replicating the entire application, even for parts that don't need more resources. And with scaling, comes a hefty bill to manage.

Balancing performance needs with cost efficiency becomes challenging. Scaling down during quieter periods also poses challenges, including safely decommissioning excess servers without disrupting service and managing data consistency.

These challenges highlight why monolithic architectures struggle with fluctuating loads and why organizations often turn to more flexible solutions like microservices, which offer better scalability and cost management capabilities.

Lots of Dependence(Rigid)

If too many developers are working on the same codebase, even making a small change can become problematic. Each change can impact other parts of the application, leading to conflicts and dependencies that need to be resolved. This often results in longer development times, as developers must coordinate closely, perform extensive testing, and handle merge conflicts. The interdependence of various components means that a small tweak by one developer might require adjustments or fixes in seemingly unrelated parts of the code, complicating the development process and slowing down progress.

Solution

Enter microservices:

And one of the pioneers in adopting microservices was the renowned media streaming platform, Netflix. Originally built on a monolithic architecture, Netflix faced significant challenges as its user base grew exponentially. With millions of subscribers globally streaming movies and TV shows simultaneously, the monolithic approach struggled to handle the increasing traffic efficiently.

This led Netflix to innovate and transition towards a microservices architecture, marking a pivotal shift in how modern applications are designed and operated. Today, Netflix operates using hundreds of microservices to power their application. This architectural shift has become a standard for high-traffic applications.

Netflix’s adoption of microservices revolutionized the way large-scale applications handle scalability, flexibility, and user experience.

For more info check out these blogs published by Netflix:
https://netflixtechblog.com/tagged/microservices

Similarly, Atlassian noted in their monolithic vs microservices blog:

In January 2016, we had about 15 total microservices. Now we have more than 1300. We moved 100K customers to the cloud, built a new platform along the way, transformed our culture, and ended up with new tools. We have happier, autonomous teams and a better DevOps culture.Microservices may not be for everyone. A legacy monolith may work perfectly well, and breaking it down may not be worth the trouble. But as organizations grow and the demands on their applications increase, microservices architecture can be worthwhile.

Reference:
https://www.atlassian.com/microservices/microservices-architecture/microservices-vs-monolith

Microservices

To sum up microservices in one phrase: don't put all your eggs in one basket.

In a microservices setup, we take a big application and break it down into smaller, manageable pieces, each handling a specific function. These smaller pieces, or services, operate independently, have their codebase, and can be developed and deployed on their own. This makes them loosely connected, allowing for greater flexibility and easier management.

Microservices architecture is generally not adopted by small teams or small organizations. It is more commonly implemented by large companies with millions of users and thousands of developers, such as Amazon, Uber, Netflix, Airbnb, etc.

Deciding the Number of Microservices

When transitioning from a monolithic application to a microservices architecture, we need to divide the single, unified application into multiple smaller, independent services.

But the question arises: how many independent services should a monolithic application be divided?

There's no exact answer or strict rule for this—it varies from company to company based on their specific business needs. For example, in our monolithic travel application, the company might choose to split it into smaller services like payments, hotel bookings, flight bookings, authentication, and train bookings. This way, the monolithic travel application becomes five separate microservices, each handling a specific part of the application and working together.

Benefits of Using Microservices

Independent Deployment (Isolation development and Deployment)

One of the key advantages of a microservices architecture is the ability to independently deploy individual services. The independent deployment results in major cost savings, lower downtime, and more time saved as we don't have to redeploy the whole application. In this approach, each microservice has its own:

Codebase
Development team
Database
CI/CD pipeline

Independent deployment means you can update, modify, or scale a single service without affecting the entire application. Changes to one service don't require redeploying the whole system.

Flexible Scaling (granular scaling)

Flight Booking Service: During a flash sale on airline tickets...
Hotel Booking Service: If it's the off-season...
Payment Service: Increased activity...
User Authentication and Signup Service: Moderate scaling...
Train Booking Service: Base capacity...

Technology Flexibility

Each service can use different technologies best suited for its needs.

But how do microservices interact with each other?

There are three major ways for microservices to communicate:

Synchronous Communication
Asynchronous Communication
Service Mesh

Synchronous Communication

API Endpoints
Request-Response Mechanism
Real-Time Interaction

Asynchronous Communication

Using Message Brokers

Producer → Broker → Consumer

Service Mesh: Brief overview

A service mesh is a system that helps microservices communicate efficiently and securely using sidecar proxies.

Issues with Microservices

Complex to Develop

Management Overhead

High Infrastructure Cost

Because of these challenges, small teams or startups often prefer not to use microservice architecture.

Summary: Choosing Between Monolithic and Microservices

When to Use Monolithic Architecture:

Simple Apps
Small Teams
Lower Costs
Quick Development
Easy Management

When to Opt for Microservices:

Big and Complex Apps
Need to Scale
Multiple Teams
Frequent Updates
High Reliability
Different Tech Needs

This article is based on and adapted from content originally published by Unlogged.

Cheers!

Happy Coding.

TOON: Token-Oriented Object Notation – A Complete Guide for LLM Data Efficiency

Islam Hafez — Thu, 11 Dec 2025 12:19:14 +0000

Token-Oriented Object Notation (TOON) is a compact, human-readable encoding of the JSON data model, specifically designed to minimize tokens and simplify structure for Large Language Models (LLMs). It acts as a drop-in, lossless representation of JSON, allowing developers to use familiar JSON programmatically while converting to TOON for efficient AI input.

TOON merges YAML’s indentation-based structure for nested objects with CSV-style tabular arrays for uniform data. Its primary strength is with uniform arrays of objects—multiple fields per row with consistent structure—achieving compactness similar to CSV, while maintaining explicit schema information for reliable LLM parsing. For deeply nested or non-uniform data, standard JSON may remain more efficient.

Why TOON?

With AI becoming more accessible, context windows are expanding, but tokens still cost money. Standard JSON is verbose:

{
  "context": {
    "task": "Our favorite hikes together",
    "location": "Boulder",
    "season": "spring_2025"
  },
  "friends": ["ana", "luis", "sam"],
  "hikes": [
    {"id": 1, "name": "Blue Lake Trail", "distanceKm": 7.5, "elevationGain": 320, "companion": "ana", "wasSunny": true},
    {"id": 2, "name": "Ridge Overlook", "distanceKm": 9.2, "elevationGain": 540, "companion": "luis", "wasSunny": false},
    {"id": 3, "name": "Wildflower Loop", "distanceKm": 5.1, "elevationGain": 180, "companion": "sam", "wasSunny": true}
  ]
}

TOON conveys the same information with fewer tokens, combining YAML-style indentation and CSV-style tabular arrays:

context:
  task: Our favorite hikes together
  location: Boulder
  season: spring_2025
friends[3]: ana,luis,sam
hikes[3]{id,name,distanceKm,elevationGain,companion,wasSunny}:
  1,Blue Lake Trail,7.5,320,ana,true
  2,Ridge Overlook,9.2,540,luis,false
  3,Wildflower Loop,5.1,180,sam,true

Key Features

Token-Efficient & Accurate: TOON achieves up to 74% accuracy versus JSON’s 70% while using ~40% fewer tokens in mixed-structure benchmarks.
JSON-Compatible: Encodes objects, arrays, and primitives with deterministic, lossless round-trips.
LLM-Friendly: Explicit [N] lengths and {fields} headers provide clear schema information for reliable parsing.
Minimal Syntax: Indentation instead of braces, minimal quoting, YAML-like readability with CSV compactness.
Tabular Arrays: Uniform arrays collapse into tables, declaring fields once and streaming row values line by line.
Multi-Language Ecosystem: Implementations exist in TypeScript, Python, Go, Rust, .NET, and more.

Media Type & File Extension

File extension: .toon
Media type: text/toon
Always UTF-8 encoded.

When Not to Use TOON

Deeply nested or non-uniform structures: JSON compact may use fewer tokens.
Semi-uniform arrays: Token savings are reduced.
Pure tabular data: CSV may remain slightly smaller than TOON.
Latency-critical applications: Test performance against your specific model and setup.

Benchmarks

TOON consistently reduces token usage while improving comprehension across four major LLMs:

Efficiency Score: Accuracy % ÷ Tokens × 1,000
Mixed-Structure Track: TOON uses 39.6% fewer tokens while improving accuracy over standard JSON.
Flat-Only Track: TOON slightly exceeds CSV token count (+6%) for added structure and reliability.

Detailed per-model benchmarks show TOON outperforms JSON, YAML, and XML across varied datasets while remaining competitive with CSV on flat tabular data.

Installation & Quick Start

CLI (no installation required):

npx @toon-format/cli input.json -o output.toon
echo '{"name": "Ada", "role": "dev"}' | npx @toon-format/cli

TypeScript Library:

npm install @toon-format/toon

Example usage:

import { encode } from '@toon-format/toon'

const data = {
  users: [
    { id: 1, name: 'Alice', role: 'admin' },
    { id: 2, name: 'Bob', role: 'user' }
  ]
}

console.log(encode(data))
// users[2]{id,name,role}:
//   1,Alice,admin
//   2,Bob,user

Playgrounds & Editor Support

Official Playground: Convert JSON to TOON in real time, compare token counts, share experiments.
Editor Support: VS Code extension, Tree-sitter grammar, Neovim plugin, and YAML highlighting for other editors.

Using TOON with LLMs

TOON’s structure is self-documenting. When prompting LLMs:

Wrap data in TOON code blocks.
Provide [N] lengths and {fields} headers.
Use tab delimiters for token efficiency.

Other Implementations

Official: .NET, Dart, Go, Java, Julia, Python, Rust, Swift
Community: Apex, C++, Clojure, Crystal, Elixir, Scala, Lua, OCaml, Perl, PHP, R, Ruby, Kotlin

TOON is stable, but still evolving. Contributions, feedback, and experimentation are encouraged.

Summary:
TOON provides a token-efficient, readable, LLM-friendly alternative to JSON, especially for uniform arrays of objects. It reduces token costs, increases parsing reliability, and is easy to integrate with existing JSON workflows. For developers working with LLMs at scale, TOON is a powerful addition to the toolset.