In 1996, I worked on one of my first real search engines: an early Java applet that indexed a few thousand documents (for 3M Healthcare if I remember right…), distributed in parallel on CD-ROM (because laptops didn’t have wireless internet back then…) and on an early intranet website. It had instant word completion, which felt revolutionary at the time, and it used an early TF-IDF index with a static offline indexing process.
That architecture pattern stuck with me.
Eddie is a modern version of the same core idea: precompute aggressively, ship static index, answer queries fast at runtime with no backend.
Also, clear status up front: Eddie is still experimental alpha/beta software. I’m also making heavy use of AI coding assitants - exploring the best workflows to produce higher quality software with those.
1) What this is Link to heading
Eddie is a build-time indexer plus a browser runtime for static sites.
- Build time: parse content, chunk it, generate embeddings, build BM25, write
index.ed(get it… indexed). - Runtime: load
index.ed, embed user query, run hybrid ranking, return results. - Optional mode: experimental “full bot mode” Q&A exists, but retrieval is the core feature right now.
The design goal is high-quality retrieval without introducing a search backend.
2) Competitive analysis Link to heading
High-level positioning:
- Eddie: hybrid retrieval, fully client-side runtime, early but ambitious capability envelope.
- Pagefind/Lunr: excellent keyword-first paths with lighter client payloads.
- Algolia/kapa.ai/DocsBot: server-first SaaS with strong managed capability and recurring cost/dependency tradeoffs.
Comparison table (cost, server, client payload on disk):
| Tool | Cost | Server required | Approx client size on disk |
|---|---|---|---|
| Eddie | Free | No | ~3,000 KB runtime bundle |
| Pagefind UI | Free | No | ~200 KB |
| Lunr.js | Free | No | ~30 KB |
| Algolia DocSearch (client bundle) | Free for OSS / paid tiers | Yes | ~500 KB |
| kapa.ai | Enterprise | Yes | n/a (server-heavy architecture) |
| DocsBot | $16–$416/mo | Yes | n/a (server-heavy architecture) |
3) Roadmap Link to heading
Near-term roadmap priorities:
- More first-class CMS/SSG integrations (Astro, Docusaurus, MkDocs, Eleventy, Jekyll).
- Better chunking strategy controls and presets.
- Multilingual support and multilingual relevance testing.
- Model benchmarking suite for model selection.
- Build-time Q&A corpus generation for better grounded responses.
4) Optimization status Link to heading
Current state is simple:
- It works.
- It is still early.
- The library itself is still bigger than I want. (ends up at about 1MB over the wire)
Current index artifact for this site:
index.ed: ~520 KB
That is good enough to ship and iterate on, but there is still clear optimization work ahead.
Next large optimization steps are already acknowledged in the roadmap/issues:
- segmented/sharded indexes for larger sites
- further compression/format refinements
- broader benchmarking and size budgets
If you want to follow progress, watch/subscribe to the repo: