WASM Compatibility Analysis

This document analyzes each module in fresh-editor for WASM compatibility, identifying blocking dependencies and potential solutions.

Key Insight: Ratatui is WASM-Compatible

Ratatui itself is WASM-compatible. The library is a rendering abstraction that writes to a Buffer of Cells. The platform-specific part is only the backend (like crossterm) that handles actual terminal I/O.

With default-features = false, ratatui provides:

• ✅ Color, Style, Modifier - styling types
• ✅ Rect - layout rectangles
• ✅ Buffer, Cell - terminal buffer abstraction
• ✅ Frame - rendering frame (backend-agnostic)
• ❌ crossterm backend - native terminal I/O (optional)

Ratzilla provides a WASM backend for ratatui that renders to browser canvas/DOM.

Summary

Key insights:

1. Syntect is WASM-compatible with fancy-regex feature → syntax highlighting for 100+ languages
2. All tree-sitter features have WASM fallbacks → indentation, reference highlighting work without tree-sitter
3. Crossterm event types are WASM-compatible → KeyEvent, MouseEvent, etc. are pure Rust data structures

Remaining blockers:

1. crossterm terminal I/O - actual terminal read/write not available in WASM, use Ratzilla backend
2. tokio/async in services - gate behind runtime
3. PTY/signals - inherent platform limitations
4. crate::input module - depends on crossterm I/O for event reading

Layer 1: MODEL (14 files) - 100% WASM-Ready ✅

All model files are pure Rust. Already compilable to WASM.

Status: ✅ Complete - no changes needed.

Layer 2: PRIMITIVES (21 files) - 100% WASM-Ready ✅

All Features Have WASM-Compatible Implementations

Every primitive feature now has a pure-Rust WASM-compatible implementation:

WASM-Ready (All 21 files)

Runtime-Enhanced (4 files)

These modules provide enhanced features using tree-sitter AST analysis. WASM builds use the pure-Rust alternatives above.

Layer 3: INPUT (14 files) - 21% WASM-Ready

Blocker: crossterm::event types

The input layer uses crossterm::event::{KeyCode, KeyEvent, KeyModifiers} for keyboard handling.

WASM-Ready (3 files)

Needs Abstraction (11 files)

Recommended Solution

Create abstract input types in fresh-core:

/// Platform-agnostic key code
#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash)]
pub enum KeyCode {
    Char(char),
    Enter, Esc, Backspace, Delete, Tab,
    Left, Right, Up, Down,
    Home, End, PageUp, PageDown,
    F(u8),
}

/// Platform-agnostic modifiers
#[derive(Debug, Clone, Copy, Default)]
pub struct Modifiers {
    pub ctrl: bool,
    pub alt: bool,
    pub shift: bool,
    pub super_key: bool,
}

/// Platform-agnostic key event
#[derive(Debug, Clone)]
pub struct KeyEvent {
    pub code: KeyCode,
    pub modifiers: Modifiers,
}

// Conversions
#[cfg(feature = "runtime")]
impl From<crossterm::event::KeyEvent> for KeyEvent { ... }

#[cfg(feature = "wasm")]
impl From<web_sys::KeyboardEvent> for KeyEvent { ... }

Effort: 1-2 days to create abstraction and update input layer.

Layer 4: VIEW (70+ files) - 70% WASM-Ready

Key Insight

Most view files only use ratatui types (Color, Style, Rect, Buffer), which are WASM-compatible. The blockers are:

1. crossterm::event - Input handling in some view files
2. Terminal I/O - Actual rendering to terminal (use Ratzilla instead)

WASM-Ready (~50 files)

Files using only ratatui types (no crossterm):

Needs Gating (~16 files)

Files with crossterm input handling:

Inherent Blockers (~4 files)

WASM Rendering Strategy

For WASM, use Ratzilla as the ratatui backend:

// Native (runtime feature)
#[cfg(feature = "runtime")]
use ratatui::backend::CrosstermBackend;

// WASM (wasm feature)
#[cfg(feature = "wasm")]
use ratzilla::backend::DomBackend;

This allows the same rendering code to work on both platforms.

Layer 5: SERVICES (38 files) - Mixed

WASM-Ready (5 files)

Needs Gating (28 files)

Inherent Blockers (5 files)

These are fundamentally incompatible with browsers and must remain runtime-only.

Layer 6: APP (37 files) - Needs Refactoring

The app layer orchestrates all other layers. Key changes needed:

Revised Refactoring Plan

Phase 1: Input Abstraction (3-5 days)

1. Create KeyCode, Modifiers, KeyEvent in fresh-core
2. Add conversion traits for crossterm (runtime) and web_sys (wasm)
3. Update input layer to use abstract types
4. Update view files with input handling

Phase 2: Backend Abstraction (1 week)

1. Add Ratzilla dependency for WASM builds
2. Create backend selection based on feature flags
3. Update app layer to use selected backend
4. Test with both backends

Phase 3: Service Gating (3-5 days)

1. Gate LSP, plugins, terminal behind runtime
2. Abstract clipboard with trait
3. Update filesystem operations to use FileSystem trait
4. Provide WASM stubs where needed

Phase 4: Integration & Testing (1 week)

1. Build WASM target
2. Create browser demo
3. Performance testing
4. Cross-browser compatibility

Revised total effort: 3-4 weeks (down from 10-12 weeks)

Current Status

Model layer: ✅ 100% WASM-compatible Primitives layer: ✅ 100% WASM-compatible

Completed:

• ✅ Model layer WASM-compatible
• ✅ FileSystem trait abstracted with NoopFileSystem for WASM
• ✅ Event streaming gated behind runtime
• ✅ Config runtime-specific functions gated
• ✅ WASM feature flag added to Cargo.toml
• ✅ Basic wasm module with WasmEditor wrapper
• ✅ Syntect enabled for WASM with fancy-regex feature (pure Rust regex)
• ✅ Grammar module WASM-compatible (TextMate grammar loading via syntect)
• ✅ Theme types WASM-compatible (view/theme/types.rs)
• ✅ Syntax highlighting: textmate_engine.rs (100+ languages)
• ✅ Auto-indentation: indent_pattern.rs (pattern-based)
• ✅ Reference highlighting: reference_highlight_text.rs (text matching)

Next steps:

1. Input abstraction (biggest remaining blocker)
2. Add Ratzilla for WASM rendering
3. Gate remaining services