Framework Building Motivation

• Inspired by Waku's minimal server component framework approach
• Next.js has good DX after years of development but accumulated tech debt shows
• Desire for framework taking Next.js strengths without legacy baggage
• Would mostly rebuild Next.js with minor changes:
  • Add config-based routing option
  • Remove magic exports
  • Minimal cleanup/recreation approach (like Preact to React)

Convex Sponsor Segment

• Demo of T3 chat-style app with real-time sync
• Backend automatically deployed in same project
• Query handling: collect messages from DB, return them
• Send message: insert body/author, list last 10 messages, schedule action
• Action runs outside quick updates for API calls/external sources
• Streams text to Gemini, updates data with ctx.run.mutation
• Type-safe TypeScript throughout
• Real-time sync eliminates stale data issues

Dynamic I/O Game Changer

• Major breakthrough in Next.js caching/reusing components
• Eliminates compiler hacks for identifying dynamic vs static elements
• Uses async nature of dynamic code for identification
• Single runtime hack: runs React render, takes output, kills async parts before response
• Double setImmediate trick skips async queue, ejects with synchronous parts
• Would have required building complex compiler without this discovery
• Makes framework building easier and improves DX

Tech Debt Accumulation Problem

• If started framework year ago, would be at v0 now
• Dynamic I/O discovery would require throwing away half the work
• Would end up wrapping tech debt with tech debt
• Same problem that caused Next.js current issues

Next.js Evolution Timeline

• 2021: Server components + app router (huge monumental changes)
• 2022: Server actions (rougher edges, more potential wins)
• Changes getting smaller each year
• Still rough edges and undocumented behaviors

Server Action Performance Gotchas

• revalidate_path nukes all cache entities in path
• cookie.set doesn't nuke cache
• Performance difference example:
  • revalidate_path: slow, nukes forever-cached get_all_pokemon
  • cookie.set with random value: significantly faster
• Behavior undocumented, team confirmed after inquiry
• Edge cases for performance optimization lunatics

Framework Building Reality Check

• By time custom framework complete, 5+ new features would emerge
• Same complexity problem with less time/incentive
• Two framing options:
  • Trust Next.js team to do right things
  • Changes too fast, would go insane trying to keep up
• Reality between both, leaning toward excitement

Ecosystem Innovation Spread

• Elixir adopting streaming benefits (shell before data query)
• Vue exploring server-only components
• React innovations spreading to other ecosystems
• Exciting cross-pollination of ideas

Personal Motivation Analysis

• Building framework would reduce excitement for new features
• Many developers frustrated with new React releases (more work)
• Framework builders face stress with new releases
• Wants to maintain excitement about ecosystem innovations
• Prefers using best tools vs building tools

Next.js Performance Example

• Turbo version demo: extremely fast in dev server
• Production even faster
• Simple elegant cookie handling
• Hidden div pre-renders next Pokemon images
• Server updates HTML directly
• No complex workarounds needed
• Code describes exactly what's happening
• Less framework-specific, more JavaScript knowledge required