Show HN: Repaint – a WebGL based website builder

Original Article ↗ Hacker News Discussion ↗

A new WebGL‑based website builder called Repaint is drawing praise for its smooth, Figma‑like UX and ambitious custom rendering engine that reimplements much of CSS and text layout. Commenters are especially interested in its potential as a “design tool for real code,” but many see the lack of guaranteed HTML/CSS export and self‑hosting as a dealbreaker, warning against being locked into a proprietary hosting platform. Technical threads dig into performance at scale, text rendering complexity, responsiveness, SEO and accessibility, with users proposing features like code export to React, open standards for the internal document model, and an SDK or embeddable editor.

Overall reception

  • Many commenters are impressed by the technical ambition and smoothness of the editor, especially given it’s WebGL-based.
  • Several say they’re eager to try it and see it as a promising alternative to existing tools, though some won’t sign up without clear code export options.

Positioning vs incumbents (Webflow, Framer, Figma, Wix)

  • Team frames it as Figma-like UX combined with HTML/CSS fidelity, contrasting with Webflow’s perceived clunkiness and Framer’s divergence from “real” code.
  • Others note that for simple marketing/landing pages, mature incumbents with built-in analytics, templates, and funnels are still attractive.

Code export, hosting, and “walled garden”

  • This is the most contentious topic. Many say lack of HTML/CSS (or React) export is a deal-breaker and call this “digital feudalism.”
  • Desired options: static HTML/CSS export, React/component export, Git-based sync, self-hosting, or at least downloadable “frozen” output.
  • Motivations: control over infra, integration with existing stacks (Vercel, GitHub Pages), long-term data sovereignty, and avoiding lock-in or price shocks.
  • The team is reconsidering, exploring code export and alternative business models but has no concrete plan yet.

Responsiveness, semantics, SEO & accessibility

  • Current workflow is desktop-first with breakpoints; some question this vs mobile-first.
  • Commenters highlight need for semantic tags, better defaults, and integrated SEO/a11y checks.
  • The product already scores decently on Lighthouse but not top-tier; future improvements and per-element tag control are planned.

Rendering engine, WebGL, and text layout

  • Many recognize the difficulty of reimplementing CSS and text rendering; there’s detailed discussion of fonts, metrics, HarfBuzz, Skia, etc.
  • Team notes brutal effort to match browser text/layout and that they currently focus on Latin script, with ligatures and complex scripts deferred.
  • Some question whether WebGL is necessary vs smart caching; others argue GPU-driven editors enable Figma-level smoothness.

Performance & visual quality

  • Discussion about FPS: some say 30+fps feels better; others note designers may not need very high frame rates.
  • Aliasing at certain zoom levels is observed; suggestions include shader-based AA, supersampling, and accumulation-buffer style techniques.
  • Team is open to WebGPU in future and considering a C++/WASM core for performance.

UX, onboarding, and feature requests

  • Playground without signup exists but is hard to discover from the main site; several request ungated, more-visible demos.
  • Requests include: Figma import, HTML/CSS import, semantic IDs for post-processing, CMS/data integrations, relative CSS units (rem/em/vw/container units), component libraries, SDK, and embedding the editor into other apps.
  • Some want the rendering engine itself open sourced as a general-purpose canvas/graphics platform.

Internationalization and input

  • Current text system struggles with emojis, IMEs, and non-Latin scripts; users report broken input and missing context menus.
  • Team acknowledges it’s Latin-focused so far and treats broader i18n as future work.