HN Explorer

Show HN: Flashbang – DuckDuckGo bangs resolved locally with a Service Worker (flashbang-dyr.pages.dev)

1 points by t3ntxcles ↗ HN
I like to use DuckDuckGo-style bangs and snaps, they are fast and efficient shortcuts.

However, neither Kagi nor DuckDuckGo resolves them as quickly as I would like and subjectively Google has better search results than DuckDuckGo.

After trying a few local alternatives eg. unduck, unduckified, I wasn't satisfied, the ones I tried briefly loaded a page before redirecting causing visible page flickering, still took time to resolve the actual redirect and lacked advanced features (address-bar autocomplete). Flashbang avoids that by handling the redirect in a Service Worker, before the browser renders anything. On my machine, the added ove rhead is around 0.14ms.

It has 14,470 bangs, custom shortcuts, address-bar suggestions, and works offline once installed (except for suggestions). No runtime dependencies.

Try it: https://flashbang-dyr.pages.dev Code: https://github.com/ph1losof/flashbang

6 comments

[ 3.3 ms ] story [ 21.6 ms ] thread
Sayrus
I always found redirects to be wasteful on mobile connections where latency and packet losses are frequent.

Interestingly Firefox, I get latency that are way worse than Chromium (Median 0.46ms vs 1.2ms, P99 1.3ms vs 1.8ms).

t3ntxcles
Yes, I agree, thanks for testing on Firefox. I use Zen on a daily basis, it is Firefox based and my result is also interestingly around (0.54ms median, 0.68ms mean, 0.90ms P95, 1.2ms p99, min 0.48ms, max 1.3ms) for prefix bangs. I think that the differences come in how each browser may have implemented SW. On benchmarking suite specifically the tail can also come from scheduling, IPC, extensions, timer precision, or other browser work
canary-digital
This is a wonderfully elegant use of Service Workers. Intercepting the request at the browser level to do instant local routing instead of waiting for a round-trip to the search provider is one of those 'why didn't I think of that' hacks.

Quick question on the implementation: How are you managing the storage and lookup for the 14,000+ bangs? Are they just bundled as a static JSON in the SW payload, and does that have any noticeable impact on the browser's memory footprint when the Service Worker activates?

sunnybeetroot
Wow this is excellent, I wish bangs were part of the web spec and all browsers supported it client side. It could work like unlock origin and its filter lists so the websites aren’t coupled and instead are dynamic.
t3ntxcles
Exactly, there’s so much potential beyond search. Bangs could act as general browser-side shortcuts to deep links, so something like !ghsettings could take you directly to GitHub’s settings instead of making you do this manual navigation through the site you are visiting