Show HN: FixBrowser – a lightweight web browser created from scratch

Original Article ↗ Hacker News Discussion ↗

Overall reception

  • Many commenters find the project impressive, “artisanal,” and philosophically appealing, even if not yet practical for daily use.
  • Others are skeptical it can compete on speed, simplicity, or site compatibility with mature engines, especially without JavaScript.
  • Several people express appreciation for the courage to release such an opinionated browser and say they’d like to keep a copy installed if it becomes reasonably complete.

JavaScript-free design & web compatibility

  • Central design choice: no JavaScript engine; instead, one-way layout and rendering without DOM mutation support.
  • Supporters like the simplicity and security benefits, and note they already browse largely without JS.
  • Critics argue most of the modern web (SPAs, commerce, social media, banks, maps) depends on JS and will break, limiting the browser to blogs and simpler sites.
  • There is debate over whether “fixing” the web by removing JS helps or just further cripples an already messy platform.

Fix scripts & FixProxy

  • Fix scripts run on HTML/CSS (often via FixProxy) to restore usability to JS-heavy sites, then output sanitized HTML/CSS for any browser.
  • Author and some users report good real-world results, needing a mainstream browser only for a small minority of sites.
  • Some see FixProxy as at least as interesting as the browser, likening it to a more radical, preprocessing version of extensions like uBlock.

Performance, privacy, and tracking

  • Removing JS and dynamic DOM is seen as a huge simplifier and performance win.
  • Some suggest alternative approaches: partial JS/DOM support with aggressive blocking of specific APIs, network limits, and CORS.
  • ETag and similar tracking features are deliberately omitted; one commenter suggests optional, per-site enabling for caching.
  • Others point out that tracking is possible even without JS and that a highly distinctive client may be fingerprintable.

Implementation choices: FixScript, toolkits, VCS

  • The browser and tooling are written in a custom language, FixScript, described as memory- and thread-safe, C-portable, and relatively small.
  • This increases uniqueness but also raises concerns about attracting contributors.
  • GUI is toolkit-agnostic with backends for Cocoa, GTK, Haiku, and Win32; FLTK and Qt are discussed, with strong opinions about C vs C++ “bloat.”
  • Source is available as a ZIP, but there’s no public VCS repo; this draws repeated criticism for hindering collaboration and transparency, especially given donation requests.
  • Author uses Monotone privately; several commenters recommend exposing at least a read-only public repo (any VCS).

Ecosystem comparisons & alternatives

  • Compared to Dillo, NetSurf, Ladybird, uzbl, and Electron-style apps.
  • Some suggest using Servo or embedding existing engines (CEF, Ladybird) without JS or as an opt-in for specific tabs/sites.
  • There’s interest in using FixBrowser for kiosks, SSR-backed desktop apps, and low-resource or legacy systems.

Future directions & feature suggestions

  • Ideas raised: optional CEF/Ladybird embedding, per-site JS/ETag/CSS controls, extension system for fix scripts and protocols, non-Unicode text support, and user-controllable updates.
  • Some propose plug-in scripting engines (V8, SpiderMonkey, Python, others), while others argue that non-JS scripting would fragment standards.
  • One user reports Microsoft Defender flagging the download; the cause is unclear.