Adding Search to This Blog

Author: Jake Bauer | Published: 2020-07-06

A few days ago I posted online about the really simple solution I came up with for searching on my blog. Since then, I’ve had a few good replies about ways I could make it better. One suggestion in particular fit with the themes and goals of this website so I went ahead and implemented it to improve the search experience.

Evaluating Other Suggestions

First, let’s talk about some of the other suggestions made. There was the suggestion from Amolith of secluded.site that I use a tiny, JavaScript-less, static search engine called Tiny Search and the suggestion from Kev Quirk of kevq.uk who mentioned that DuckDuckGo provides an embeddable search bar in the form of an iframe. Both were great suggestions, but let’s look at why I think they wouldn’t work for my site.

Tiny Search is a really clever and interesting project, but it achieves its functionality through WebAssembly. WebAssembly is a new web technology created to allow web-native apps to run far faster and far more efficiently than if they were written in JavaScript. Unfortunately, this means that basically only the three big browser engines support it: Gecko (Firefox), Blink (Chrome and its derivatives), and WebKit (Safari and its derivatives). That means anybody browsing my site with an alternative browser such as Lynx or w3m won’t be able to make use of it. I could provide a fallback, but the other reason why I didn’t choose it is because it advertises itself as being between “50kB-100kB gzipped” which is very large when put in context with the average size of one of my pages being 10-20kB for an entire page, or ~6-7kB for just the HTML.

I played around with Kev’s suggestion of the DuckDuckGo iframe and it worked quite well and was very easy to generate and add to my page. However, it had the same issues as Tiny Search where it would balloon the size of the blog page by up to 3x its original size, and it would make 3 third-party requests to load in the necessary assets. Also, iframes are not supported by Lynx or w3m but it was trivial to add a fallback for those browsers. The main issues that I had with this method were the third party requests and large size of the loaded assets.

To summarize, I didn’t go with the above two suggestions because of the use of unsupported technology in browsers which I target and because of the size of the assets which would be required to make them functional. Both are trivial in the context of many contemporary sites, but I like to keep my site as slim as possible and I like to maintain compatibility with alternative browsers.

The Solution I Chose

However, Oscar Benedito suggested something which caught my eye and which I didn’t even know was possible: a form that makes a request to DuckDuckGo. This solution uses technology that has been supported in every web browser for decades and adds a mere 300 bytes to the size of the page since it’s just a plain HTML form. This is what I have which now powers my site’s search:

<form action="https://duckduckgo.com/" method="get">
    <input name="sites" type="hidden" value="www.paritybit.ca/blog">
    <input aria-label="Search this blog." name="q" type="text"
        placeholder="Search This Blog">
    <button aria-label="Submit search query.">&#128270;</button>
</form>

That’s it! Instead of a link to a DuckDuckGo search where users would have to type their search query in after clicking it, users can now type their query into this form and they will be sent to a DuckDuckGo page with the results. This still improves the UX while keeping the page small and using features supported in browsers like Lynx and w3m.

This is my sixty-second post for the #100DaysToOffload challenge. You can learn more about this challenge over at https://100daystooffload.com.