JSON's Dominance and Problems

• JSON ubiquitous for web data access - almost every API returns JSON responses
• JSON replacing HTML in many places, especially with single page app (SPA) model
• React/SPA paradigm: send tiny HTML files → JavaScript downloads → API calls with JSON → UI rendering
• JSON has significant flaws:
  • Weird encoding/decoding behaviors across languages/versions
  • JSON5 fixes problems but limited support
  • No trailing commas or proper undefined support
  • Frequent unexpected behavior issues

Historical Context: HTML as Original Solution

• Pre-JSON era: servers sent HTML directly to users
• HTML excellent standard for taking server information and presenting to users
• SPA model so compelling that HTML sending from servers largely stopped
• Large projects now: tiny HTML + JavaScript tag → JS downloads → API calls → UI rendering

HTMX as Alternative Solution

• No longer need separate API and client with strong relationship requirements
• Eliminates need for APIs, schemas, type definitions between client/server
• Server sends correct HTML directly
• When changes occur: server sends updated HTML for specific spots
• Payload size concerns unfounded:
  • JSON over-fetching common (entire user object for just name in div)
  • Correct HTML guarantees smallest possible representation
  • Often ends up being smallest sendable payload

Server-Side Rendering Benefits

• HTML template serialization: ~1-2 milliseconds of work
• React/JS approach requires sending every possible HTML permutation in JavaScript blob
• Mobile platform challenges:
  • New post types not in Android/iOS binaries can't render
  • Users on old app versions (years old) can't handle new features
  • Fallback solutions needed (web embed, etc.)

Industry Examples and React Server Components

• Facebook, Google/YouTube, other big platforms use server-defined UI behavior model
• Define data shape AND UI behavior on server → send to client
• React Server Components inspired by this mindset
• Benefits:
  • No API definition needed for client data
  • No JavaScript-land fetching required
  • Serialized HTML stream from server fills components
  • Client only needs to know what/where to render

Post-JSON Future Vision

• HTML/markup-based standard instead of database standard for server-client communication
• Button clicks return HTML updates instead of JSON state instructions
• Eliminates JavaScript bundle requirements for all possible content
• Removing unnecessary walls between server and client
• Not truly "post-JSON" but "post-APIs" - removing artificial barriers