IO vs JSON
A detailed comparison of Internet Object and JSON: schema support, size efficiency, number formats, and more. See the benchmark data below.
Lower is Better -
GitHub
| 10 Records | 1113 | 2022 |
|---|---|---|
| 100 Records | 10021 | 19667 |
| 500 Records | 51279 | 98778 |
| 1000 Records | 99819 | 197766 |
Differences
Feature by Feature Comparison
Internet Object offers schema-first design, smaller payloads, native BigInt support, and streaming capabilities that JSON lacks. Compare features side-by-side.
#Structure
Document-Oriented with Headers vs Flat Structure
IO employs a
document-oriented format with a clear separation between header and data sections. It also supports multiple
data sections for separate schema enforcement, facilitating more organized and modular data management.
This document-oriented format allows multiple schemas to be defined and applied within a single document.
JSON uses a flat structure without native support for header and data section separation, potentially complicating data organization and manipulation in complex applications.
#Verbosity
50% Smaller in Bytes, ~30% Fewer LLM Tokens
IO is designed to be thin and non-verbose, providing a significant reduction in data size. A non-minified version of IO is about 50% smaller than minified JSON in bytes, and uses ~30% fewer tokens for LLM APIs (GPT-4, Claude, etc.). This offers substantial benefits in terms of efficiency, speed, and cost savings, especially over network transmissions and AI workloads. Best results seen with datasets of 10+ records.
JSON is more verbose, with each data record repeating the same keys (e.g., username, firstName, lastName), which can lead to increased data size, higher LLM token counts, and slower processing times, particularly when dealing with large datasets.
#Schema
Schema-First with Type Safety vs No Native Support
IO inherently supports a schema-first approach, boasting an easy-to-define and human-friendly schema language. It accommodates both in-document and out-of-document schemas, enforcing type safety at parse time and catching errors before they reach your application code. This enhances data integrity and validation without necessitating external libraries.
JSON, on the other hand, lacks built-in schema support. Implementing schemas in JSON requires separate libraries, such as JSON Schema, which can be verbose and cumbersome to manage. Type validation must happen at runtime in application code, potentially allowing invalid data into your system.
#Multiple String Types
Versatile String Handling vs Simple Strings
IO distinguishes itself by supporting multiple string types, including open strings, regular strings (enclosed in single or double quotes), and raw strings (which do not escape characters, useful for complex patterns like regular expressions). It also has built-in support for multiline strings.
JSON string handling is simpler, with no explicit support for multiline or raw string formats, limiting its flexibility in representing complex text data.
#Multiple Number Types
Multiple Formats & Arbitrary Precision
IO provides comprehensive number support with multiple literal formats
including Decimal, Binary (0b), Hexadecimal (0x), and Octal (0o). Beyond standard numbers,
IO supports BigInt for arbitrary-sized integers and RDBMS-like arbitrary precision decimal numbers for financial calculations
and scientific computing. It also handles special values like Inf, -Inf, and NaN.
JSON is limited to decimal numbers only, with no native support for alternative number formats, BigInt, or arbitrary precision decimals. Special values like infinity and NaN are not part of the JSON specification, limiting its use in scientific, financial, and specialized numerical contexts.
#Date and Time
Native Date Support
IO has built-in support for ISO 8601 date and time formats, allowing automatic conversion to and from native date objects during serialization and deserialization.
JSON inherently does not support date objects. While some parsers convert dates to ISO 8601 strings during serialization, they do not automatically revert to date objects upon deserialization.
#Binary Data
Built-in Base64 Support
IO includes built-in support for base64-encoded binary data, with parsers responsible for the seamless serialization and deserialization to and from language-native byte arrays.
JSON - While base64 strings can be used to represent binary data, they are treated as strings rather than binary bytes, necessitating additional handling for binary data.
#Streaming Friendly
Independent Object Structure vs Nested Arrays
IO is inherently streaming-friendly with each data record being independent. The schema-first design allows parsers to process records as they arrive without needing to load the entire document into memory, perfect for real-time data processing and large datasets.
JSON arrays and nested objects must be fully parsed before processing, which can complicate the handling of large datasets in streaming contexts and require significant memory overhead.
#Variables
Native Variable Support for Reusability
IO includes native support for variables (using $ prefix),
enabling value reuse throughout the document. This reduces redundancy, improves maintainability, and keeps documents DRY
(Don't Repeat Yourself).
JSON does not support variables natively, requiring external mechanisms or preprocessing to achieve similar functionality, adding complexity to the workflow.
Connect with Us!
Share your insights, learn from others, and contribute to the evolution of Internet Object. Your expertise can help shape the future of data serialization. Learn more and join us on our community page!
#Comments
Built-in Comment Support
IO natively supports single-line comments using
#, allowing you to document and annotate data directly within the document. This makes IO files self-documenting and easier to maintain.JSON does not support comments by specification, which can make documentation and maintenance more challenging. While some parsers allow non-standard comments, they break JSON compatibility.