DuckDuckGo – two non-JavaScript versions of search results • Hacker News Board

Re: DuckDuckGo – two non-JavaScript versions of search results

#41

Post by blisseyGo » Fri, Mar 05, 2021, 1:24 AM UTC

nerdponx wrote: post #30

benhoyt wrote: post #17

As someone who's just written about the "small web" [1], this warms my heart. The lite version is probably a little too bare-bones for most people's tastes, but it sure is tiny -- great for people on very slow or flakey connections. Some numbers: HTML homepage transfers 34KB (94KB uncompressed) over 6 requests. HTML search results page transfers 133KB (248KB uncompressed) over 31 requests. Lite homepage transfers 13K…

DDG lite works great in Lynx! I hope it never goes away.

Is there a lite version of Google search? How does Lynx work for Google searches?

Re: DuckDuckGo – two non-JavaScript versions of search results

#42

Post by solox3 » Fri, Mar 05, 2021, 1:30 AM UTC

It will be interesting if either one of these eventually returns image and video results as well.

Re: DuckDuckGo – two non-JavaScript versions of search results

#43

Post by MarkLowenstein » Fri, Mar 05, 2021, 1:59 AM UTC

zelphirkalt wrote: post #10

metalliqaz wrote: post #4

the 'html' version is nice. the 'lite' version is so barebones, I can't imagine anyone actually using it. It almost seems like it's meant for scraping

It is so fast and clean, I just set it as my duck keyworded search. I'm not on a search engine for the looks, but for the results. The faster I get them and the fewer things there are to distract the eye, the better for me.

A guy at work made a no-frills search results viewer that was just a standard Windows UI ListView (table) window with one result per row. Best search page I ever saw, because you could see 40 results at a time instead of 10.

Re: DuckDuckGo – two non-JavaScript versions of search results

#44

Post by eyelidlessness » Fri, Mar 05, 2021, 3:18 AM UTC

I honestly don't care if they use JavaScript (responsibly, which I think they do), but why not ape the user research the other search engines have done and use real pagination? It's not like Google and Bing and etc don't know that you can append DOM nodes.

Re: DuckDuckGo – two non-JavaScript versions of search results

#45

Post by Seirdy » Fri, Mar 05, 2021, 3:24 AM UTC

boogies wrote: post #29

benhoyt wrote: post #17

As someone who's just written about the "small web" [1], this warms my heart. The lite version is probably a little too bare-bones for most people's tastes, but it sure is tiny -- great for people on very slow or flakey connections. Some numbers: HTML homepage transfers 34KB (94KB uncompressed) over 6 requests. HTML search results page transfers 133KB (248KB uncompressed) over 31 requests. Lite homepage transfers 13K…

These are great, and I’m glad to be able to use them without direct contact with “Big Tech” and the tracking bloat that entails, but as I understand it DuckDuckGo is more or less a glorified — albeit relatively glorious and pleasant — proxy to Big Tech’s Bing (well, more, not less, because it does add some great conveniences like the IIUC formerly open source Instant Answers¹ and !bangs, and some fraction of results…

DuckDucGo's classic link results are verbatim from Bing (or sometimes Yandex instead). DuckDuckBot is only used to grab favicons and a subset of its rich results (instant answers, zero-click info).

Don't take my word for it; you can compare DDG and Bing results for esoteric queries side-by-side. The order of the results may vary since search results aren't deterministic, but you'll find them to be otherwise identical. You can also ask staff in help channels about the details of where link results are sourced from.

Re: DuckDuckGo – two non-JavaScript versions of search results

#46

Post by eyelidlessness » Fri, Mar 05, 2021, 3:26 AM UTC

benhoyt wrote: post #17

As someone who's just written about the "small web" [1], this warms my heart. The lite version is probably a little too bare-bones for most people's tastes, but it sure is tiny -- great for people on very slow or flakey connections. Some numbers: HTML homepage transfers 34KB (94KB uncompressed) over 6 requests. HTML search results page transfers 133KB (248KB uncompressed) over 31 requests. Lite homepage transfers 13K…

1. My site is also smol, but brand new and probably doesn't warrant a mention here, but respect for smol web!

2. > Because most people only view one or two articles on my site, I include my CSS inline. With HTTP/2, this doesn’t make much difference, but Lighthouse showed around 200ms with inline CSS, 300ms with external CSS.

With respect, this seems to be the frontend consensus and it... just doesn't make sense to me. Unless you expect the majority of your traffic to never hit a cache header on that external CSS. That 100ms perf hit (which is probably a warning sign that something's wrong with your assets or server config anyway) should be a one time affair, and not repeating that payload over and over surely makes up for it in the sub-200ms responses after.

Re: DuckDuckGo – two non-JavaScript versions of search results

#47

Post by freediver » Fri, Mar 05, 2021, 4:27 AM UTC

aerovistae wrote: post #26

Holy shit the lite version is fast. Comparing to google search it's not even close...wow.

Looking at the network inspector, "lite" version search results load in about 900ms - 1.4sec for non-cached queries. That is fast only compared to the rest of the "big web" maybe, but not _that_ fast in absolute terms (and for context, Google full search results load in usually that much). The bottleneck for DuckDuckGo is probably the Bing API (usually 600-700ms response) for which there is no way around.

If you want to see a fast web search engine try https://rightdao.com

I am not affiliated with them in any way. But their search results come back at 70ms (with network latency included) and that is darn impressive!

Re: DuckDuckGo – two non-JavaScript versions of search results

#48

Post by freediver » Fri, Mar 05, 2021, 4:33 AM UTC

benhoyt wrote: post #17

As someone who's just written about the "small web" [1], this warms my heart. The lite version is probably a little too bare-bones for most people's tastes, but it sure is tiny -- great for people on very slow or flakey connections. Some numbers: HTML homepage transfers 34KB (94KB uncompressed) over 6 requests. HTML search results page transfers 133KB (248KB uncompressed) over 31 requests. Lite homepage transfers 13K…

I'll play devil's advocate as an engineer.

"HTML" version shows no images, just text and favicons. The total size of visible text content shown on the page is about 4KB (just did a count of characters on the page for "steve jobs" query). DDG shows those 4KB using 248KB of data.

1. That is not _that_ small. It's only small compared to the rest of the web, but not in absolute numbers, or in comparison to useful content shown.

2. The content to data ratio comes at 1:62. Or for one character shown on screen you are transferring 62 bytes of stuff. For context, Wikipedia page for Steve Jobs, which also includes multiple images, is 1.08MB and content is 128KB for a content to data ratio of about 1:9. So DuckDuckGo could in theory do ~7x better than this.

Sorry, as an engineer, not impressed at all!

Re: DuckDuckGo – two non-JavaScript versions of search results

#49

Post by divbzero » Fri, Mar 05, 2021, 4:48 AM UTC

benhoyt wrote: post #17

As someone who's just written about the "small web" [1], this warms my heart. The lite version is probably a little too bare-bones for most people's tastes, but it sure is tiny -- great for people on very slow or flakey connections. Some numbers: HTML homepage transfers 34KB (94KB uncompressed) over 6 requests. HTML search results page transfers 133KB (248KB uncompressed) over 31 requests. Lite homepage transfers 13K…

These are fast!

Noticeably faster than the default JavaScript DDG.

Re: DuckDuckGo – two non-JavaScript versions of search results

#50

Post by userbinator » Fri, Mar 05, 2021, 4:56 AM UTC

Up until not long ago, Google search result pages worked well without JS, and if you sent a suitably old UA header, you'd get the "original" version without mangled URLs or any of the other bloat. Then in 2019 or so, in what I consider to be an extremely hostile move, they started redirecting (using meta tags) to a horrible dumbed-down mobile-ish version and using styles-removed-by-JS to "hide" the actual content of the "full" version (which has the "modern" mangled URLs) if you managed to reach it anyway, so all you'd see was a blank page. It's almost like they were deliberately trying to make something that only worked in the latest version of Chrome or whatever few other "modern" browsers exist today, and decided to force non-JS users to a worse experience than they had had for the past decade or more. Nothing a filtering proxy can't fix (and I brought back true URLs at the same time), but I was absolutely incensed when that happened.

I don't think a search engine should ever require JS to be usable. The existence of search engines[1] predates the existence of JS, and of course the HTML mechanism of form submission and displaying a list of links predates both of those.

[1] https://en.wikipedia.org/wiki/JumpStation