Architecture: Session 135: Should GoGrab build custom parsing engines (mar...

Documentation for Sessions

🏗️ Architecture: Session 135: Should GoGrab build custom parsing engines (mar...

Date: 2026-02-22
Time: 19:54:58 UTC
Session: gspace1-135.3
Agent: angular
Confidence: 95%
Status: ✅ Documented

📋 Decision Context

Question:

Session 135: Should GoGrab build custom parsing engines (markdown, syntax highlighting) from scratch, or wrap battle-tested open-source libraries in custom Angular components?

Task: Establish Build vs Buy principle and replace custom parsing engines with proven libraries

🎯 Decision Made

Chosen:

Wrap proven libraries in custom components — 'Build the UI, Buy the Engine' principle. Custom-build visual/UX components (emoji picker, drag-drop, portals, theme system). Wrap battle-tested libraries for parsing/processing engines (markdown, syntax highlighting, rich text, date math). Our @libs-ux components own the UX surface (SCSS, theme tokens, Angular API). The library is a hidden implementation detail.

Options Considered:

  1. Build everything custom (zero external deps, full control, Session 133 approach)
  2. Wrap proven libraries in custom components (Build the UI, Buy the Engine)
  3. Use external libraries directly without wrappers
  4. Hybrid: custom for simple cases, external for complex ones

💭 Reasoning

ROOT CAUSE: Session 133 built ux-code-highlight (425 LOC, 9 languages, regex tokenizer) and ux-markdown (371 LOC, custom parser). Analysis revealed: (1) ux-code-highlight only covers 9 languages vs 300+ in PrismJS — users pasting Go, Rust, C#, Java, Ruby, Swift get zero highlighting. This is a CORRECTNESS problem. (2) ux-markdown covers ~70% of CommonMark — missing: reference links, nested blockquotes, HTML blocks, escaped characters, list continuation edge cases. Every markdown bug in chat is OUR bug to fix. (3) Parsing engines have thousands of edge cases discovered over years of community use. Regex-based tokenizers cannot handle nested contexts (template literals with expressions, JSX mixed with TypeScript). (4) The 'zero external dependencies' philosophy was correct for UI (emoji picker at 582 LOC is fine — no good framework-agnostic alternative exists, and UI is our design identity). But it was WRONG for engines: marked is 30KB gzipped with 33K stars and CommonMark compliance; PrismJS has 300+ languages. The maintenance cost of custom parsers exceeds the dependency cost. WHAT WOULD MAKE THIS WRONG: If we needed offline-first with extreme bundle size constraints (sub-50KB total), or if marked/prism introduced breaking changes frequently. Neither applies — both libraries are stable (marked v17, prism v1.30). EARLY WARNING SIGNALS: Users reporting misformatted markdown, code blocks with wrong coloring, or feature requests for unsupported languages.

📁 Files Involved

🔗 Related

Auto-generated by MCP Smart Consolidation