Infinite scrolling on the threads combined with a very slow loading. A thread of 30 replies will not load everything, even though 30 replies is probably less than 1Mb of data.
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.
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.
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. :/
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.
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.
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?
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.
I've found loading to be extremely fast. Way faster than pagination on most traditional forums, even over a slow mobile connection. On desktop it usually loads faster than I can scroll. Guess it depends on which server you're using?
Same here. The old vBulletin / PHPbb format felt positively archaic once I got over the shock of how different the basic interactions are.
I can understand some hesitance from people who are naturally wary of infinite scrolling, as the vast majority of implementations are terrible. Where Discourse succeeds, though, is in managing state such that it doesn't feel brittle when you're deep into a thread's history. The developers built an infinite scroll that has feature parity with classic pagination, plus the far better UI of a "timeline" scrollbar.
I concur. I somehow skipped PHPBB and VBulletin (I was more of a newsgroup/IRC kinda guy) and always found them super clunky and a step backwards compared to newsgroups, if only because of the lack of proper threading.
Discourse is comparatively very pleasant I thought.
Curious what you mean by lack of proper threading in phpBB and vBulletin? Are you talking about threading of responses within a broader "Thread" (top-level post entry)
Because each of those entries on that page are a thread to me, but if discussions within a thread go off on a tangent there's not really a way to group/organize those sub-threads.
