Show HN: Flashbang – DuckDuckGo bangs resolved locally with a Service Worker | Hacker News Reader

Show HN: Flashbang – DuckDuckGo bangs resolved locally with a Service Worker

flashbang-dyr.pages.dev

19 pointst3ntxcles8 comments

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

Open articleView on HN

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).

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.56ms median, 0.59ms mean, 0.78ms P95, 0.94ms 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

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?

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.

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

It would also be cool if such bang lists were supported by websites officially, allowing a fast navigation

Work on Chrome, and on Firefox.

Doesn't work on Tor browser (security level standard) or Safari with Lockdown enabled.

Hi @khurs, I think that it is related how Tor and Safari Lockdown handles SW. If SW usage is blocked this is incompatible with current architecture. I will think what we can do about it and come back to you. Meanwhile open to PR's in helping to resolve it!

Reply on news.ycombinator.com