Hacker News Reader

Comment by Gigachad | Hacker News Reader

It needs to so that it can search on the backend and show you all instances of that search rather than just what the currently loaded DOM elements contain.

View on HN

On pretty much any other web page, Ctrl+F will search whatever is on the page; why should Discourse be any different?

I don't mind them having a server-side search function that actually searches the entire thread. I do mind having a heavily-used shortcut hijacked to behave in a non-standard way.

Try pressing CTRL+F twice and see what happens

Oh, I'm well aware of this workaround. The problem is that Ctrl+F is muscle memory by now, so I usually hit it and immediately start typing... then notice that it's the wrong search, swear, hit it again, and type again.

Because to remain performant, modem sites remove elements that have been scrolled too far off the page. So native ctrl + f would not be searching very much at all.

I don't see the problem with this tbh. When you create a JS app, you lose a lot of the native features of the browser and it becomes your own responsibility to reimplement them in a correct way. As long as the site pulls it off flawlessly, this is ok to me.

And from what I have seen, discourse does do this well.

> to remain performant, modem sites remove elements that have been scrolled too far off the page

This is done to remain performant specifically when the website thinks infinite scrolling is a good idea. In my experience it very rarely is, with the Ctrl+F thing being just one of the reasons why.

This is a great example of a "feature" that seems to make sense but, for reasons I can't quite put my finger on, really bothers me.

Maybe it's that Discourse's search functionality didn't really work well, or suddenly started searching across threads rather than only the current one (IIRC); maybe it's that it's the only system I can think of (other than google docs) that hijacks the shortcut, but it gave me a very negative first impression of the tool.

For another similar example, the Blendle website (note - not the app!) hijacks Esc when reading an article, and interprets it as a shortcut to return to the main page of the site. I actually reported it as an issue to them, and they said it's by design and not going to change. :/

What if I want to search only currently loaded DOM elements?

Usually you repeat the search hotkey to activate the browser's native search function.

On most modern apps, this is pretty much just what is on the screen right now + a little on the top and bottom. The elements get removed/reused once they scroll off the page for performance.

I only see this as an issue if the site does not reimplement find so that it is able to deal with this.

Why can’t we just use normal forum software from the 2000s, but with security patches?

Because no amount of security patches can fix 00s forum software designed without modern security in mind. And the average user _likes_ Discourse. They don't give two shits that Ctrl + F is hijacked because it does exactly what they want. It finds the text. They don't want excuses like "Oh well it doesn't find that text because you didn't scroll down to load it". They don't want to click through 100 pages of thread.

I use that forum every day, and it hasn’t had any major security problems for the 15 years or so it has been used. I’m not seeing what you’re talking about.

Does the average user likes Discourse? My anecdotal experience hosting a Discourse forum for non-techies is certainly not indicative of that.

I think this is one of the greatest fallacies in modern data science. We only know what we can measure. There's no data on the opportunity cost of design decisions.

In other words Discourse only has metrics on people who use Discourse.

I think this is probably why sign-up metrics are so common but those are perverse as well. How much do you set yourself back if you only work for people willing to sign up?

What kind of security problems are you talking about?

That seems like a direct consequence of the non efficient infinite scrolling that they implemented.

Their method seems really efficient to me. It infinitely scrolls, feels like it's actually native, and hijacks the shortcuts to make them work as if it was native.

I really like their timeline scrollbar as well which lets you easily move through hundreds of posts very quickly and has become a pattern in many apps like Google Photos and Telegram.

It does not hijack the shortcuts to "work as if it was native", because there's no way to know how the native function works in every browser, in most cases.

Let's look at Ctrl+F again. The standard Chrome search toolbar is search-as-you-type, highlighting occurrences immediately. It also shows the total number of occurences found on the page, and has arrows to navigate to next/previous. It also doesn't auto-hide (and thus lose focus) if you scroll the page.

What does Discourse replace it with? A search toolbar that requires an explicit submission to even start searching - and then, instead of actually scrolling to the occurrence of the search term, it shows a dropdown with snippets of posts in current scope that matched the term, highlighting it much like a search engine would.

So it basically has nothing to do with the native function that it hijacks, other than the broad concept of textual search.

What do you mean by "native" here? Is pagination non-native?

Reply on news.ycombinator.com