The Type Problem Nobody Talks About
You build a web app. Your Python backend calculates a price: Decimal("99.99"). You serialize it to JSON.
JSON has no Decimal type. Your 99.99 arrives in JavaScript as a float — and
0.1 + 0.2 === 0.30000000000000004. Your invoice is wrong. Your accountant is angry.
So you convert Decimal to string before sending. Now the frontend needs to know which strings are "actually numbers" and convert them back. You add a schema. Or a convention. Or a separate metadata field. For every type. In every endpoint.
Dates? Same story. datetime(2025, 1, 15, 10, 30) becomes "2025-01-15T10:30:00" — is that UTC? Local? The frontend guesses. Half your bug tracker is timezone issues.
TYTX solves this by embedding type information directly in the value. "99.99::N" is a Decimal. "2025-01-15::D" is a date.
The sender tags, the receiver hydrates. No schema negotiation, no out-of-band metadata, no guessing.
When does this actually matter?
Financial data
Prices, invoices, tax calculations — Decimal roundtrips without floating-point surprises. "999.99::N" stays 999.99, always.
Date/time across timezones
Dates stay dates, datetimes are always UTC with explicit ::DHZ suffix. No more "is this local or UTC?" bugs.
Multiple transports
Same typed data over JSON, XML, MessagePack, or query strings. Switch transport, keep types.
Multi-language apps
Python backend, JavaScript frontend. Types survive the round trip. Same library on both sides.
Zero-config
No schema files, no code generation, no build step. pip install genro-tytx and go.
Backward compatible
TYTX values are valid JSON strings. Any JSON parser can read them. Type-unaware code just sees strings.