Hacker News new | past | comments | ask | show | jobs | submit login
Jeff Atwood on growing Discourse (indiehackers.com)
218 points by ChanningAllen on May 2, 2017 | hide | past | favorite | 158 comments

For anyone who has to deal with the pain of reading Discourse message threads, you can append ?_escaped_fragment_ to the URI to get a JS-free page that loads completely immediately and doesn't unload when you scroll.

I have no idea why this user-hostile functionality is present by default. It breaks ctrl+F, ctrl+S, the scrollbar, and loads of other browser functionality.

All forums with large threads have to paginate for performance, including HN. Discourse's infini-scroll feature is best understood as "automatic page turning."

In a paginated thread, you can only Ctrl-F for stuff on the current page, and Discourse is no different; it's no more "broken" than a traditional paginated forum with manual page turning. Similarly, you can only Ctrl-S to save the current page, not the whole thread.

Many forums have a "search in this thread" feature, and Discourse does, too. In fact, if you click in the page and press Ctrl-F, it intercepts the keystroke and shows Discourse's "search in thread" search box; some forums with manual page turning do the same thing.

Some people seem to get really pissed off at automatic page turning; I kinda understand why, but there are clear arguments for automatic page turning. Why make the user click "Next Page" when the software could do it for you? You'll notice that all of the most popular feed-based sites (Facebook, Twitter, Pinterest, Instagram) use automatic page turning, too, and that's because experiments show that people engage more when automatic page turning is enabled.

None of this will make you any happier with APT, but hopefully it will annoy you slightly less to know that this is a data-driven decision and not done specifically to annoy you.

> All forums with large threads have to paginate for performance, including HN.

I can read "War and Peace" [1] as an HTML document on my 7 year old cheapo Android phone. The browser even "streams" the data, displaying each chunk as it loads over a slow connection.

As far as I know, you're correct that all forum software I've used paginates large threads, but I'm curious if they "have" to - as in, I think a team could probably build forum software that didn't paginate large threads (for reasonable definitions of "large") and still have good performance on a wide range of devices, if they were willing to make the necessary trade-offs. Whether those trade-offs are worth making, I don't know.

[1] http://www.gutenberg.org/files/2600/2600-h/2600-h.htm

Well, for one thing, there is nothing relational about a giant HTML document. But for another, is a page that long really the ideal experience for a discussion forum?

Why not allow the user or client define the pagination experience?

You can get and read War and Peace (or other similarly large books -- I frequently reference Adam Smith's Wealth of Nations) at Project Gutenberg. As a single HTML file.

The ability to search for any particular text instance within that document through browser capabilities is useful.

As is, I agree at times, the ability to present the information as some sort of consistently paginated context.

I'm thinking that somewhere between the 21st and 42nd centuries, computers might advance to a state where this is in fact possible.

If I wanted to search a discussion thread I'd rather use a search function.


I suppose you're going to respond with something along the lines of "because it's better than the browser's search function".

But again: why is that?

Why do the built-in browser tools suck as badly as they do?

Example, outside of search: I realised some months back that a chief reason we have browser Reader Mode features, to uncrappify crappy site CSS, is because browser default styling ... is so horrible.

And again: why is that?

Why do we have craptastic CSS entity defaults when, with a very little work, every page could look, without any styling at all, pretty damned readable:


(And if that's not your cuppa, then themes such that you get what you want -- Night Mode, or whateves.)

Whatever browsers are being built for, it's not the people actually using them.

/me looks suspiciously at Chrome => Google => Advertising....

Gee... I wonder why that might possibly be.

Well for one thing a browser search function can't distinguish between post content and the rest of the page. Also just one endless stream for a thread is practically unreadable.

And you realise that the browser has literally parsed the entier document object mode. If there's a semantic structure to be found, the browser knows what it is.

Again: why is cabapility-in-the-browser so impossible to provide?

Why isn't "search post" vs. "search comments" something scoped into a browser? If comments are a ... not entirely novel or unknown concept within Web design and activity, why are the abilities, say, to have browser-generated lists of authors, or search by author, or post/comment distinctions, or persistent reputations of commentators so that I can tell if @dredmorbius@news.ycombinator.com is just an asshat or a space alien cat who really knows where his towel is (and independent of whether or not dredmorbius maps to any particular known "real name")?

It's not like the question's just come up within the past 5 hours.

Really: Why is the browser so fucking limited in this regard?


War and Peace in HTML on Gutenberg is 12,000 paragraph tags, which is a lot but it's very easy to find forum threads with more than 12,000 posts. And each post is more than a paragraph tag, it's probably more like a dozen: the author name, an icon, the date, controls, etc.

Even Chrome on my i7 doesn't instantly respond when loading those Gutenburg URLs.

The linked book is 3.9 MB. That you would have to reload every time a new post was appended to the end. This is a terrible counterexample.

I'm not sure I understand the connection? My argument was that War and Peace sounds like an incredibly big thing to load because it took people a long time to read it in high school, but it's actually pretty simple, structure-wise, when compared to a discussion forum.

I may have replied to the wrong parent. We are in agreement. :)

HN doesn't paginate comments any more.

Here's a thread with 970 comments for example:


And the comments on that page (840kB) are smaller than the Javascript on a discourse site (4MB).

yes, but the minute you click a _second_ page, the Javascript app is already loaded, and we request only JSON for the new data.

Also this 4MB number isn't correct; I count 700kb. Feel free to double check my work:


Are you really arguing that Discourse's superior linear complexity outweighs the huge constant cost in any meaningfull scenario? At 4mb/840kb * 970 comments, disregarding any additional JSON data that Discourse loads, a Discourse thread would need to have 4974 comments before its strategy is more efficient than Hackernews.

Jeff, I respect you, but I don't understand where you are going with that comeback.

Think of Discourse as a JavaScript app you load on your phone. Yes there is that unavoidable first time install on first page load, but once the app is installed, all it needs to render the page is the JSON data that makes up the comments -- which is very efficient, far more efficient than a full HTML page load of a traditional website.

So how you feel about this depends on "how often you use the app". If you only plan to visit that one page, ever, then it's not a great tradeoff (though 700kb -- no idea where you are getting 4MB from -- of images is basically nothing on a webpage these days). If you visit many discussions and many pages, it's a win.

In other words a single discussion doesn't need 4000 comments, you just need to read 4000 comments across all discussions all time. I'm not sure your math is correct here, either: I just visited meta.discourse.org in incognito mode and I see about.. 700kb of javascript?


I'm sorry but I don't know where you are getting 4 megabytes out of 700kb. See above screenshot.

Answering Macha, below:

- Your chosen example is missing http/2 so requests aren't batched

- Discourse homepage by default shows user avatars for each participant, up to 5 in each topic, so there will be "more images"

I suggest testing with meta.discourse.org (hosted) or discourse.codinghorror.com (self-hosted) to make sure you're looking at apples to apples, and properly configured sites.

Not the parent poster, but going to the first Discourse forum in my history:


72 requests, 50s load time, 3.5mb data. It would have been smaller if you'd served the screenshot of the page.

HN for comparison:


6 requests, 50kb, 0.72s

Now how about your contemporary forum competition.

Here's a Xenforo forum:


19 requests, 2mb, 5s

And that's with the massive background image you can see, which is 1mb in size by itself.


Since Jeff stated the comparisons weren't apples to apples, xenforo.com/community vs meta.discourse.org . Both boards running in basically stock configuration from their own sites:

* Xenforo.com: 43 requests, 1.4mb, 4s

* meta.discourse.org: 73 requests: 3.2mb, 4.5s


Definitely a better showing than the ACEO forums, but still loses the comparison.

Too lazy to take more screenshots, but reddit is 50 requests, 1.3mb, 3s for comparison.

This isn't remotely apples to apples; for example, HN has zero avatars, Xenforo has zero avatars, whereas Discourse shows up to five avatars per topic, of which there are many on the homepage.

I'm unclear where you are getting 3.2MB from, since sorting by filesize, here are the largest network requests at meta.discourse.org:


As you can see, starting at 11.5kb and below it's all images (avatars).

I suppose you could try with images disabled. If you want to make a case that 'not showing avatars by default uses less bandwidth', then I guess I can agree with that. But these images won't affect actual load time, as images rez in later, and all the dimensions are set on the page.

Thanks for the reply. You have me convinced with amortizing the cost of js over multiple visits rather than a single thread.

Regarding the 4mb thing, I pulled it out of 1wd's comment. It would be best if 1wd came back and explained. That said, I believe the discrepancy is probably between the size of compressed javascript in the network and it's uncompressed size. Firefox dev tools show 3.1mb for meta.discourse.org. I don't know how to view the total size in Chrome's dev tools, but if you click the "use large request rows" in the Network tab you will see that application.js by itself takes up 1.5mb.

I'm sure they could get that 4mb down if they removed all text formatting, media, quotes, replies, editing tools, user icons, and pagination.

There's a lot of other things Discourse threads have (media, collapsing, proper markdown, editing toolbars etc.).

HN has collapsable threads and uses tables for layout, which aren't exactly efficient markdown, so makes the opposite point you're trying to make.

Namely, even with bloody awful markdown, HN still delivers 1000 comments in 1/4 of the bytes.

Another interesting idea, as almost everyone doesn't actually comment, wouldn't it make more sense to load the editor javascript dynamically? As far as I know, the silent majority read comments but never reply. In fact, I vaguely remember Jeff even having a blog post that most people never participate, they just consume (could be wrong!).

Also, I haven't kept up with it, but mobile browsers used to have fairly aggressive cache invalidation to save space on the phone, so serving big chunks of JavaScript in the hope it might get reused one day wasn't actually a great idea.

> Namely, even with bloody awful markdown, HN still delivers 1000 comments in 1/4 of the bytes.

Are you sure this is correct? I count 700kb of total content (including the actual HTML and CSS), not 4mb, so I think your comments are premised on a number that's off by almost 6X?


Sorry! Was just repeating a number further up the thread, should have checked myself. Worse still, you'd already corrected him and I didn't notice :(

It is encouraging to see someone as high profile as you taking the time to have a evidence-based debate on the internet.

When did they make that change? A month ago or so, I remember having to click a link at the bottom of a page to load more comments.

I've been on HN for a long time (this is not my first account even) but I had completely forgotten about pagination on HN. Even when you talked about it I only get a vague feeling that I've seen it ever. Probably I have seen it but still it feels like the sort of memory that one has of something that didn't actually happen but which you have a "memory" of because someone told you it happened.

I guess I usually simply stop scrolling before I get to the very bottom of HN.

Just to be clear though, are we talking about a "next" link at the bottom of the page, or Reddit-style "continue" links for subtrees of comments beyond a certain depth?

Same. I think that they enable it on a case-by-case basis as load gets high. Also, the "Who's hiring?" threads do not typically spawn active subthreads, so that may make them more cacheable/easier to load.

>Similarly, you can only Ctrl-S to save the current page, not the whole thread.

This brought me to thinking why browsers still save page as source code and not as serialised actual DOM? I mean developers still could use curl to save source code, but regular users will save what they see on the screen, similarly to printing to PDF.

What do you mean? Browsers do serialise the actual DOM.

I know this because I once saved a JS-heavy page and when I loaded it back into the browser, I discovered the JS-generated menus were already present in the source and were re-generated by the JS each time the page loaded.

>re-generated by the JS each time the page loaded.

yes, regenerated because js files are also stored. So the menu generating functions and all constants needed to generate menus were probably present in downloaded js files. But imagine, site that is also fetching data via ajax and render that data somehow. When you save and then reopen saved page, you might not get exact state as you were in time of saving. There are many reason why state would be different (you could be logged off, etc...) So if you send saved page to somebody, he/she will see different state of page than you. All of this could be eliminated if browsers saved state of DOM instead of page source code (and js,css resources).

We made a feature, where we capture a CTRL+P and open a new window with the full topic and start the print, so it's easier to save a big topic to PDF and read it offline.

I don't care that it does it, but I do wish they would develop it on underpowered computers.

The tone of your message feels rather condescending, which is frustrating in the face of software usability issues. I think that in general it's a good idea to treat people's complaints as well-founded, even if they don't know exactly how to describe the underlying problem.

I don't think it's the case that I and other users don't know what we want. I do believe that "people engage more" on infinite-scroll-style pages, but I have no reason to believe this makes them happier or more productive. On the other hand, the jerkiness/glitches, breakage of common navigational tools, and slowness of Discourse pages are very annoying.

I should have been more descriptive than simply saying "broken", but I figured I was probably preaching to the choir and so I didn't go into details. In particular, it becomes much harder to use tools like ctrl+F and ctrl+S because the page content is dynamic and after scrolling down a little there's no way to easily tell which bits of the page are still loaded and which aren't. ctrl+F is useful not just for initially locating a key phrase, but also for jumping between bits of the page you've already read for comparison. In a manually-paginated thread this works fine, and I know for sure whether posts are on the same page (where I can use ctrl+F) or different pages (which I can open in separate tabs).

Basically, it becomes very difficult for a user to maintain an accurate mental model of the page content that they're using a browser to interact with. This is quite different from static pagination systems, where scrolling never changes page contents.

The scrollbar really is broken, because users expect its size to show the length of the page, which no longer holds for Discourse or other infinite-scroll pages. The fact that Discourse unloads earlier content makes this even worse, as you can't even remember an old scrollbar position to scroll to something you just saw or scroll halfway to the top to go halfway to the start of the page. Yes, Discourse does provide an alternative way to see some of this information, but user interface changes (having to move from the native scrollbar to the Discourse summary box) are frustrating for users: they break muscle memory and require learning a new interface, since they never work quite the same as the other one.

It makes me no less upset to hear that data was involved in the decision to ignore users' needs. I don't think it's intentional to annoy users, but hearing that there was some level of analysis involved rather than mere accident is upsetting because it shows the slight to be willful. I don't think websites should push worsened usability on their users in the name of driving up engagement metrics.

I think the arguments about automatic vs. manual page turning mostly come down to questions of control and implementation quality: users want to be in control (because the computer is a tool, and tools must be predictable), and it's difficult to avoid bugs when implementing automatic page turning on the Web. I'm not sure exactly why the latter is the case, but I've never seen a system without glitches in the history list, visual glitches, or slowness.

Not sure why you're getting downvoted. Infinite-scroll pages are pretty well-documented to be shit. Even Facebook crashes or slows down to a crawl if I scroll enough (lol?). There might be a good idea somewhere in there, but current implementations fall short.

You know what just occured to me -- Slack is effectively 'inifinite scroll' too (no pagination), of quite a bitof content sometimes... and I don't think people complain much about this aspect of Slack. Wonder how they managed to get it right.

Because Slack is a chat system and you typically just care about the most recent messages (which are always displayed). I find scrolling back in Slack to actually be very irritating, when I have to do it. It's slow and the view jumps around whenever the next page loads in. (The UX on the search functionality is also fairly lacking.)

Yeah, people basically don't care at all about chat history. Chat is short-term memory; forgetting is a feature.

They add a nice ("109 comments since April 30th") link to click at the top of the chat window that does exactly what it says. Also there's a custom search box so ctrl+F isn't as broken.

How else to you handle an infinite thread of media without completely destroying browser performance? Seems to be an foundational internet issue.

I mostly agree with your post, but I would suggest refraining from accusing others of a "condescending tone" when it's unclear, at least when it's not blatant. I think you're getting downvotes because you seem overly defensive.

He appears to have accepted your statement without hostility and provided a fair reply. Please be careful not to interpret the lack of a pandering tone or excessive niceties as condescension. Remember, project runners hear complaints all day every day, they're never going to be able to make everyone happy, and this is a technical audience.

100% agreement from me.

Breaking ctrl+f gets my blood boiling every time I have to use a Discourse site. I've recently started to have to use one, and searching for anything is incredibly hard. Ctrl+F will bring up their own hijacked search. But by default it searches for new topics. Ok, switch it to the current topic only for search. Great, now it just shows you the entire post, and doesn't highlight your search term.

I already knew where the post was, because I scrolled down to it. I don't need to be told where it was, I need to know where the specific phrase I searched for is.

I've seen complaints about it from the past, but given that 3 years has passed and it's still like that, I just give up any hope of being productive when having to use a Discourse site.

It's really surprising to see these sorts of problems in Discourse as Jeff is usually absolutely obsessed with user experience.

simply press CTRL+F twice. Note that on small topics, CTRL+F will work as you expect as the entire topic fits on one "page"

Yeah. It's weird given he got it so right at SE and SO was just totally better than Yahoo Answers and Experts Exchange, but as a user, I hate discourse boards and would much rather good old 00s vBulletin or phpBB

This is a case of "second system syndrome" (as I've heard it called).


(C2's new design is a bit of that in itself, IMHO.)

As I like to say, if nobody hates what you're doing, it isn't very interesting.

vBulletin 3 was the gold standard and phpBB the second best.

StackOverflow has such a nice UI and UX. The UI is nice in Discourse too, but its UX needs more work. Bigger forums are hard to follow, infinite scroll comes with its own problems. The themes waste too much screen space.

Recently I've spent a certain amount of time on forums trying to troubleshoot a problem on an older car, and I'm having trouble agreeing with the statement that vBulletin was any kind of gold standard. There's just so much... junk. Huge post signatures, user badges, post counts, other post metadata... It's remarkably hard to skim a thread for relevant information.

A lot of that comes down to the quality and composition of the community you're looking at. The site admins have a lot of switch and levers to adjust the look and feel of a default vBulletin or phpBB install, and most communities' forums tend to end up having a similar aesthetic to the cars owned by the user base; anywhere from super bling'd out to subdued professionalism. The informational content seems to follow similar lines: some forums are populated by people who need hand holding through every step of an oil change, and others have more seasoned shade tree mechanics that just need some tips on how to do something without access to the factory tools.

All of that stuff (post counts / signatures / badges) was part of trying to encourage it to be a community.

Can't figure out why you are being downvoted.

Post counts: a metric for how long they have been here, also an attempt to let new members know if this person knows what they are talking about. Yes, post count is a poor metric for level of knowledge, but measuring level of knowledge is not an easy problem(see controversy over IQ tests). Displaying upvotes could be better, but see reddit where people post the same dumb jokes to farm karma, or steal jokes from other subs.

Signatures: People like to express themselves. I'm not a fan of this one either, but hey. It can be useful when you see someone say something intelligent/helpful/etc, and their signature has a list of threads they started. You might find those threads filled with useful info.

Badges: This encourages desirable behavior. It can also help identify those who have a high level of knowledge.

I would add avatars: Have you every heard someone say they can remember faces, but not names? This is an attempt to help members identify each other.

Edit: post metadata: seeing the number of upvotes on a post gives you an idea on whether it is true or not.

Yeah, 100% this. For signatures, it's also (in a lot of cases) because people see the signature backlink as a 'reward' for using the community. Like "if I post content on a regular basis, you'll let me link back to my own site/social media presence in my signature".

This itself causes some issues (like with spammers joining simply for the 'SEO' benefits), but it's enough of a pattern that changing it will often kill a forum dead, especially in the webmaster/tech/marketing field.

Other things that encourage members (but that are often seen as clutter) include reputation systems (like the green bars vBulletin had), forum cash (points given for posts and other actions), fictional shop items (purchased with said forum cash), etc. Again, a lot of people on these forums rather like said systems and often find them useful, even if to an outsider that might be seen as overwhelming.

Discourse was a missed open-goal. Forum software was horrible, and Discourse were a smart team at the right point-in-time.

Unfortunately, they blew it. They created an over-engineered, over-complicated, bloated, heavy mess. Jeff bet on Moore's Law meaning that bandwidth/speed would eventually negate the bloat, but instead the world moved to low powered devices with mobile bandwidth.

They've spent years trying to get infinite scrolling working OK and installation OK. Why? Imagine if they'd actually used all their brainpower on features that forum owners actually wanted: automated spam tools, automated admin tasks, one-click install to any hosting plan (yes using PHP if necessary).

All the years of wasted talent, and now the other forum products have overtaken them on usability/maintainability. And they are STILL trying to fix the hijacked browser search feature, that you get lost in infinite scroll, and that you need to run a separate VM to run something as simple as forum software.

LESSON: beware second-system-syndrome, beware the CEO who has personal tech vendetas which are misaligned with your product strategy, and beware creating a team consisting solely of talented engineers who will do one thing: OVER-ENGINEER.

It's interesting to hear someone else say this because all I'd really heard before this comment thread today was good things about Discourse.

I ran my own Discourse forum for a while. Users liked it well enough, but eventually I switched to using the free Steam community forums (it was a forum for a game) because it was costing me every month to run a separate server for it on Amazon.

During Discourse's life it also changed recommended install methods and auto-updates would occasionally break, so it was work to maintain. To be fair a lot of this was on relatively early versions.

I also found the Ctrl-F breaking and infinite scroll much more annoying than useful and tried to tell them[1] along with others. They listened somewhat and switched to only taking over Ctrl-F on long pages, but it's still not great. In fact I just tried to Ctrl-F for my post on the page I linked and got taken to my profile page instead.

[1] https://meta.discourse.org/t/discourse-taking-over-ctrl-f/16...

Just as a side note, you said you hosted the Discourse on AWS, but Digital Ocean have a $10/month automated, one-click deployment which includes TBs per month of bandwidth.

Perhaps that's an option should you choose to self-host again? :-)

Definitely. That wasn't an option when I first created the forum. Nor was using Docker. I changed my forum to Docker later, but things could still go wrong occasionally. There's a nice web interface for updating to newer forum versions but that still broke once or twice.

simply press CTRL+F twice.

I tried to cover that in the example I gave at the link I posted. The forum link in the example is broken now since this was 2014 but the idea still holds:

Imagine Jimmy wants to know how to pin a topic on a Discourse forum. He searches Google for pin topic discourse or whatever, and he sees a result with a text preview saying "...icon in the upper right to get the staff menu for the topic; select Pin Topic."

That looks right, so he ends up here: http://www.phylobabble.org/t/discourse-admin-quick-start-gui...

That's a big post, so he Ctrl-F searches for "pin topic". Normally his browser would already be highlighting the text in the post, but nothing happens, so he tries clicking on the only result. This just refreshes the page and puts him back at the same post.

At this point Jimmy either leaves the forum to try another result that doesn't hijack his browser search, combs the whole thread manually, or mashes Ctrf-F enough that he discovers the Ctrl-F-F override and types "pin topic" again, instantly highlighting the section that he wanted all along.

How is the average person supposed to know to do that?

The average person doesn't use ctrl+f/cmd+f; but still, for the ones who do, having to press it twice breaks muscle memory, it draws attention that something is broken or doesn't work quite like everything else.

the type of people that prefer the generic browser facilities over custom search aren't "average people".

Would these "average people" try to press Ctrl+F? If the argument is that most of the public is ignorant to the client-side jumping/highlighting facilitated by Ctrl+F, what purpose does overriding Ctrl+F serve? It seems that people who press Ctrl+F would have an expectation of what should happen next, and people who want custom search would move their mouse to the search bar and click.

Maybe a better compromise would be including a modal or a hint highlighting the site-wide search box without suppressing the native Ctrl+F functionality.

I feel like I'm a pretty average person.

My instinct when I'm looking for something is to Ctrl+F, not scour the UI for a search bar.

Anecdotally, I know people who are not programmers who are the same way.

if you're here, you're not an average person

In my opinion, it is a truism in software that it takes three years to build the thing you originally set out to build. This was true of Stack Overflow, and it's also true of Discourse.

We're supposed to be building software with the users, while observing them, while participating alongside. This takes a few years to get right.

No plan survives contact with users, and that's as it should be.

It's also likely a truism that the things that add value and the things that make money converge into a Venn diagram, not always for the best.

    > one-click install to any hosting plan (yes using PHP if necessary).
I think you had to be fair on this - that requirement accounts for a large amount of the design compromises that make other products so poor.

Breaches on popular PHP forum software account for a disproportionate amount of the breaches we regularly hear about. It's caused issues for Linux Mint, Ubuntu, and the "Cosbycoin" compromise is hard to forget. I can't complain about any particular vendor because they have all had their share of issues in this space.

Yes, you can write good PHP - but start saying "one click on any hosting plan" and suddenly composer is out the door, every file is owned by the user the web servers runs as and you start pollyfilling for ancient versions. It means you can't assume SSL will exist, it means you can't get updates using git or any sane automation strategy, and look at how Wordpress deals with cron.

Wordpress is regularly lambasted for their support of ancient versions of PHP, which is something they do primarily to meet this goal.

In interested in what other options are out there. I rarely see Discourse on the open Internet and I cringe every time I get tempted to sign up to an old SMF or vBulletin installation.

A week or two ago I was evaluating Discorse and by chance exchanged a few posts with Jeff, who to be frank seemed a little thin skinned.

Questions about feature priorities or technical architecture were met tersely and with a demand to know what kind of software I had ever built personally. So he wanted my resume rather that just discussing the merits of whatever topic.

Wasn't going to mention it but somehow your comment seemed to click.

Not sure what you mean about a tech vendetta, sounds like the tail end of a story.

This was _literally_ your opening sentence (look it up if you don't believe me):

"I’ve started to research Discourse as a general solution and started with embed capabilities. To be frank the whole situation seems to be a bit of a mess."

To be frank, I would describe what you posted more as rants than actual discussions about features. You wanted Disqus and were pretty rude about it. That's not what we're building at Discourse. If you have a problem with that, sorry.

You label that discussion as a rant, rather than honest questions about what Disourse users are asking for and architecture decisions? Wow.


I fully acknowledged the difficulty of your task, and tried to break down feed back into specific, actionable items.

Getting constructive criticism is not always fun, but it's part of our job. Besides that some people posting there are potential customers. Why call them ranters instead of a simple, we agree to disagree?

> who to be frank seemed a little thin skinned

seems apt, lol

How is this any different from traditional pagination? My understanding is that discourse is essentially just removing the necessity to click a tiny number every time you want to view the next page.

Honestly, I think I (and a lot of people here) would probably prefer the numbers to what Discourse has at the moment. At least with numbered pagination you can choose to view page [whatever] to narrow down the posts you want to view. On Discourse you either scroll like mad and slowly load in crap, or click the last post and slowly scroll back up.

If I know something useful is on page 10... well I'm just out of luck.

Asking some questions because I'm legitimately curious, I'm not super familiar with Discourse... but from admin'ing some other forum platforms, their choices seem logical to me. Is the implementation just bad?

>At least with numbered pagination you can choose to view page [whatever] to narrow down the posts you want to view

Assuming you mean sequentially, isn't this the same as scrolling but with a click involved? If you don't mean sequentially, how would you know which page to click?

>If I know something useful is on page 10...

How do you know something useful is on page 10? Is it normal for forum users to remember specific page numbers within a post?

Reasons you might want to address page numbers: Jumping ahead helps with skimming. You might (roughly) remember where you left off last. Other threads and page numbers are referenced in other threads (yes, people could link, but they don't always do)

I also like page sizes as "breaks" to follow up on links etc.

Discourse's implementation of infinite scroll isn't all that bad (it keeps position properly and doesn't seem to have strange glitches, although I haven't tried it on a bad connection), and at least navigation elements are there. But they feel strange and trip me up every time: the secondary "scroll bar", or in thinner browser windows the "progress bar" at the bottom that overlays the post content and you have to click to get the scroll bar pop up. It feels like a mobile app, half-way designed for touch, not a forum.

Interesting. Thanks for taking the time to explain.

Yes, it is actually pretty normal to remember such things, if it's a thread that you have read before, or otherwise kept track of.

At least for posts, on discourse forums I see a control on the right where I can go to specific posts. It's useful because it also shows you what date you are jumping to.

Sure, but how frequently would you know that something useful is on page 10? It doesn't seem like a very common use case to me. You can only optimize so many things at one time. Maybe this is a thing that's worth optimizing, but I think it's debatable.

I have been following Jeff's blog since a little after I started programming. I have seen his articles—especially those having strong opinions—criticised vehemently. Jeff even wrote post about people who email him how they hate his blog. But, I find it delightfully amazing that he stuck to his programming roots and found two successful ventures nonetheless.

I think he's a great example of power of doing things. He didn't start a blog with any objective other than just to write. And he wrote prolifically. If you follow his blog posts, you'll realise that he's rarely more than a person who loves computers. But, because he did things without dissuasion, he kept improving, until the success started building on his efforts.

Definitely an example of perspiration over innovation.

So many devs and "idea guys" dismiss flawed ideas and wait around for that one great idea that will launch their career, not realizing most popular libraries/sites/etc. started as a pretty basic and flawed concept that was iterated into a work of art.

Ideas are worthless, execution is everything.

I'm one of those people who don't like his blog, I've never emailed him tho. It's just personal preference to not like his style of writing and random bolding / underlining everywhere where he doesn't need to.

But no one should ever like they can't achieve anything just because a bunch of people don't like them or say mean things.

Just continue to do what you enjoy and ignore those who don't care for your passion.

There's a great early SO podcast with Jeff A. and Joel Spolsky (Fogcreek) where they argue about whether developers should know C and/or C++. Joel is rigidly in favor of it, whereas Jeff thinks it's pointless. It's a great back-and-forth, hearing these two successful guys scratching their heads at each other's comments and stubbornness.

Is this the one you were referring to? https://stackoverflow.fogbugz.com/default.asp?W87857

Discourse is so heavy and error-prone for the simple task it executes that I imagine anyone wanting to run it reliably must hire the Discourse team for a ton of money.

So probably what this article is saying is that the key to make money is to build yourself a name, then use it to sell crappy software and sell the support.

I had a lot of trouble keeping Discourse running on my own. There are a lot of moving parts and a ton of configuration to keep track of. Making changes or even updating the instance were tasks I dreaded because of the likelihood something would break. It requires a lot of system resources. I like Docker a lot in many situations, but with Discourse it only seemed to reduce visibility into the problems I was having.

I have to say the folks on meta.discourse were helpful though.

In the end, the users decided—I ended up integrating a Mailman 3 server with the website, and we're in the process of switching over to it. The users preferred the simplicity of LISTSERV-style mailing lists over a web forum. This probably would've happened no matter the choice of forum software, but I can't help but think Discourse's unpleasant UX played a part in them reaching that consensus.

You must have a fairly techie and older audience. I have to say as harsh as I've been on Discourse in this thread, I'd still take it over listserv.

Yes, academics who (generally) started their careers in the 1990s and are used to listserv-style communication. They kept wanting to interact with Discourse through email, but it wasn't the experience they were looking for.

I have a Discourse forum that I run on my own, and it has been a fairly pleasant experience overall. Initial installation was a bit problematic because of a bug that they have that doesn't properly handle # in mail server password (https://meta.discourse.org/t/discourse-app-yml-doesnt-like-e...) - it so happened that my mail password was auto-generated, and did contain that symbol in it. But other than that, it all went pretty smooth.

I've done a few updates, and it was all entirely via the web interface, with a single click on "Update" button and watching it do its thing. Zero issues so far.

I'm not sure what you mean by "ton of configuration". It seems like most things just worked the way they were set up out of the box. I keep fiddling with various user- and posting-related settings, but that's mostly out of curiosity more than any kind of need.

Interesting. I was able to get Discourse running ... on heroku no less, and I haven't had to futz with it in the months since. It just hums along on its own, but then again I'm a pretty experienced Ruby/rails engineer.

We have hundreds of live Discourse sites running the $10/month self supported Digital Ocean (or whatever cloud you like) version for literally years without any issue at all: https://github.com/discourse/discourse/blob/master/docs/INST...

I used to do all these installs for people by hand, and personally support them to ensure that we had indeed built something that was easy to support long term. I stopped doing this after a few years because I knew we had.

It's probably part of the choosen language and framework, and certainly helps sales that it's not so easy to get it running.

It's certainly not as simple to get started as with Nodejs npm or LAMP stack. But there are already easy to install discourse forum clones that use Node.js or PHP as backend language (use Google to find them).


two of several clones that run on Node or LAMP stack (I am not related to any of them)

Nodejs: https://github.com/NodeBB/NodeBB

PHP: https://github.com/flarum/core

Yeah, I know the web hosting landscape has changed since WordPress took off, but if the goal of Discourse was to be the WordPress of forums, using Ruby and Postgres instead of PHP/MySQL seems like a big misstep.

As was having the system not well suited to running on shared hosting accounts. That's because (for good or bad) the vast majority of websites are hosted on fairly cheap shared hosting accounts on large webhosts, where access to the server is heavily restricted and language choices are often limited to PHP/MySQL.

WordPress (and most traditional forum scripts like phpBB) work fine in these situations. Just upload a few files, set up a database and run the installer to get the thing working.

Discourse doesn't. It also generally isn't integrated into one click install software like Softaculous or Fantastico. This means that the audience using a typical shared host like Hostgator and clicking a button in their CPanel to set up their site can't easily use Discourse like they could WordPress.

So yeah, that's an issue here too. Discourse just requires too much control over your server for most shared hosting accounts and can't easily be integrated into one click install setups/setup by merely uploading a bunch of files. So the mass market won't ever touch it.

I think vps is the new web host. We have products like cloudron, yunohost coming up to serve that market.

Well also, they seem to have a weird idea of what "modernizing" a web app means. While it's true that traditional web forums have plenty of usability issues, I don't really think Discourse actually solves them. It just hides them with fancier ones IMO.

When Jeff Atwoord originally announced Discourse he claimed his biggest goal was to kill off PHP for good, and he wrote Discourse in Ruby specifically to convince everyone else to move off of the "one true holdout" that PHP still dominated... online forums.

I'm honestly not a huge fan of Jeff Atwoods, and that started long before he started SO. To me it just feels like he's a bit too idealistic in his approach to things.

Funny that he would say that. Co spidering the fact that a huge majority of ALL web based open source software seems to be PHP even today.

Flarum is not ready for production yet, and using NodeJS is far from the cheap stack of LAMP.

Also, id like to hear what's the reasoning behind using MongoDB for a forum. I mean, I'm just learning this stuff but a forum seems to be a perfect case for a relational DB.

I don't know about "perfect", it certainly can fit the relational mold though.

I'll take a shot in the dark and say that the advantage of using a NoSQL platform to host a forum is that you can very quickly load all resources relating to a post by storing them in one database document.

That does mean you probably need to polyfill certain functionality, but the traditional case for NoSQL is made by saying a blog can load a given post's comments, media, etc. with one query. Forums are a similar animal.

Mmm, but then, why not use NoSQL for everything? I say again, I'm just a beginner into programming but it seems that PostgreSQL would require a shitload of work to really go slow. Also in forums you know your data schema, nothing will change in terms of what data you need.

It's true traditional databases require you to think through your solution before you go implementing it, but this is not necessarily a bad thing.

NoSQL is great for prototyping and being productive fast, but that productivity comes with a lot of pitfalls. Pitfalls by the way that many devs have been blissfully ignorant of for decades because they have been insulated from them by normalized relational databases.

Unless you are experienced with/aware of those pitfalls, I would almost make a blanket statement that a traditional SQL database should be the default solution for the backend until you can explain why NoSQL is a better fit for a given project.

Also, what makes you think PostgreSQL is slow? What is "slow" to you?

Thank you for the explanation. And I meant just the opposite with postgresql. I use it as a sort of data warehouse with a lot of work in a really modest VPS and it works perfectly.

But when has this actually been a problem to solve? I've been a regular on tens, maybe a hundred forums over the last 20 years. The vast majority of them don't have performance issues.

The developer community area of Atlassian switched to Discourse recently. I really like it!


I didn't really quite grasp the full picture of what was going on before. Seemed to be a mix of google groups and confluence. This is much better. Also interesting to see Atlassian walking away from their dog food in this case.

A cynic will say that if Atlassian walking away from their 'dog food' made their online community easier to use, maybe they should also take a few lessons for the likes of JIRA as well. Because as someone who's used the latter... well, they seem pretty bad at making their software easy to understand or use.

I think they use Discourse too, just look at the html.

I really dislike using Discourse for some reason. The concept seems really good, but using it just makes me unhappy. I just don't find it to be a good user experience.

Why & what exactly?

There is no reason why such a simple interface cannot be native. The fact that you drag along the entire browser engine with HTML and CSS just boggles my mind. If a message cannot be sent because of minor latency problems, the discord client acts up as if a solar storm destroyed much of today's electronics.

EDIT: Oh, how awkward. Yes, I was thinking of Discord.

You are probably confusing Discord with Discourse.

(On the topic of Discord the chat app)

There is at least one reason: to share a code base between the web and "desktop" version of the app.

Doesn't raising seed-funding stop you from being an "Indie Hacker"?

It doesn't. I know it's broad, but my definition[0] of an "indie hacker" is anyone who's making money from customers rather than an employer. I've never discriminated based on funding, which is why I've had the "bootstrapped vs raised money" filter[1] on the homepage from the beginning.

Personally, I'm partial to early-stage tech bootstrappers, which is one reason why I've interviewed so many people from that niche. It's just a lot more near and dear to my heart, and those are the people who tend to struggle to get coverage elsewhere.

But it's worth branching out, because other entrepreneurs have valuable experiences to share, too. And to the extent that we can get even well-funded companies to share their revenue numbers and behind-the-scenes strategies, that's a good thing for all of us imo.

[0] https://www.indiehackers.com/about

[1] https://media.giphy.com/media/l4FGycUhVUpsBuoqQ/source.mp4

> It doesn't. I know it's broad, but my definition[0] of an "indie hacker" is anyone who's making money from customers rather than an employer.

So... once you hire your first employee and the staff is no longer exclusively founders/owners... the founders/bosses are still 'indie hackers', but the employee is not? Or none of them are anymore, you can only be an 'indie hacker' if the entire staff is founder/owners with no employees?

When only bosses can be 'indie', hmm. I guess that is a pretty good synecdoche of a certain kind of bay area techno-capitalist-hipsterist ideology.

There are many more blurry lines than that. For example, is a contractor an indie hacker? Technically they get paid by clients, not employers. But they're also directly trading hours for dollars, and rarely make for good interviewees. Etc.

At the end of the day, we can spend a lot of time bike shedding about semantics and the name "Indie Hackers," but what's more important is the overall purpose behind the site — a place for entrepreneurs to learn from each other and share their experiences transparently. Sometimes those entrepreneurs will be the Jeff Atwoods and Bezoses of the world, and that's just fine.

Yes. The interview might have value in itself, but it is odd placed at indie hackers.

The reality of a big shot in SV raising venture capital money is a lot different of mine, a struggling "indie hacker".

But they use Stripe! /s

I would tend to agree, especially if it's something from the get-go.

If I had to defend it, though, I'd say that _every_ indie startup has seed money. Most of the time, it's from the founder, who commits their own time and money to the project. In this case, they got others to commit their money.

But it's definitely a blurring of the line between indie startups and rocket ship startups.

Self-funded seed money is pretty much what defines as "independent". I see a very clear line here, no blur at all.

The blur I see is that one could argue the defining feature of indie startups is not that they're "independent" but that they're a reaction against rocket ship startups (startups in the sense that most VCs in Silicon Valley define it).

If that's the defining feature of an indie startup, that it's counter to a regular startup, then being self-funded is only one of many ways that indie startups can differentiate themselves.

All that said, I think the information from the interview itself _is_ valuable. As long as Indie Hackers doesn't become flooded with non-indie startup stories, and as long as the readership is aware that the lessons Jeff Atwood learns may not be applicable to them (which is true of any story on Indie Hackers, really), then it's okay.

Depends on who it's from imo.

They've also featured Nathan Barry, who is neither indie nor a hacker. He's a popular blogger/author who used his considerable profits from that career to hire a team to build ConvertKit for him.

I'm not actually sure what Indie Hacker's idea of an idie hacker is.

Meh, if their advice is useful to an 'indie hacker', then why not have it?

Because it dilutes the focus of the site!

There are all kinds of people who give "useful advice" that could, in theory, help an indie hacker, but are actually aimed at a general audience. In the extreme case, consider diet and beauty tips, relationship advice or stock investing strategies. Yes, those things are useful to many if not most indie hackers but they're also easily found on more general sites and can easily crowd out more focused content.

I agree with your general point, but both Jeff Atwood and Nathan Barry are far from crossing any reasonably-drawn line.

Just my own personal feedback here: I've really enjoyed the site, but the Nathan Barry interview decreased my interest in the site a bit.

It's because, for me personally, the thing that makes IH special is the stories of people who didn't have degrees from elite schools, family wealth or VC funding and still successfully built something sufficient to cover their living expenses or even start hiring employees. Stories about people who do a lot with a little are a blueprint that can be applied by people of just about any background. Stories of parlaying medium-sized fortunes into large ones are most useful to people who already have medium-sized fortunes.

To be clear, I don't dislike interviews with founders of large companies. I sometimes watch them on youtube and have read books about many of the largest tech companies. It's just more useful for me to learn about how people went from 0 to 60 rather than from 60 to 200.

IH is still my favorite place on the internet for that, which is why I care about how well it serves that role. You'd have to dilute it quite a bit before it fell behind the next best alternative, though.

Thanks for the feedback. What I might end up doing in the long-term (still in the brainstorming phases) is increase the number of interviews across the board. That means more big company interviews and more small company interviews. Then At the same time, I'll work on making it a bit easier to focus on exactly the stories you care about.

Discourse is really a pain to self-host :/ I hate the whole Dockerized install thing. Why not just provide simple instructions on how to deploy and we can use Docker if we want to? Don't get me wrong, I like Docker but the way discourse does it is totally over-engineered.

That's just one way to run it. I actually run it on heroku without docker with no problems at all ... had to make a few edits here and there, but once I got it up I haven't had to touch it and its been humming along just fine for months now.

> Don't target the low end market if you can avoid it.

Disagree with this statement. There is money to be made in the low end market, and it's not as bad as you expect it to be.

I don't disagree with the statement in its intended context. He's speaking to startups here, who don't have an established product yet, and don't know if their product even reliably solves a business need.

In that context, this is excellent advice. Once the product is built and already making you money, then you can easily pivot and see if there's any profitability in marketing the now-sustainable product to the lower end segments. But don't start there unless you really know what you're doing, because the low margins in that market amplify your risks.

It's a pretty rough life for a small company to target the low-end. There's money there, but the low-end market also demands more time, if you aren't extremely careful about how you implement your sales/support process.

Some products just aren't an upmarket product...mobile apps, for example. But, if there's a way to target your product to people who have a budget, you're going to have a much nicer time scaling up...you'll have money to hire people (and to a lesser degree, other resources that cost money) to do so. It takes a lot of $5/month sales to pay for one employee. But, $200/month sales add up really fast.

It's easier to start high-end and open up the low-end than it is to start at the low-end. There's a clearer method of prioritization (working on features for paying customers first) and you can spend more time making high paying customers happy rather than trying to retain hundreds.

Depends on what you're doing. For example my business is built on catering to the lower end of a service who can't justify the high end prices.

Right, that's totally reasonable — but it's harder because you by default have to attain and retain more customers.

examples or stories or any reason at all we should take your word for it?

Digital Ocean, Linode, LowendBox community just to name a few.

Has he complained about Android JavaScript performance yet?! :)

I'm not sure about all the negative comments.

I have the exact opposite experience. I really like discourse. We run it now since two years with exactly one issue when I did an update, but that was more or less my fault being not on 'stable' but on 'beta'. Self-hosting is not complex although I wouldn't want to do this without the docker they offer.

What I like about discourse

* discuss in real time (!)

* if you prefer email then you can get it, ask questions via email or get answers there if you are not online

* mute specific topics or subscribe only to a few categories

* you can like answers without having to say '+1'

* simple to self-host IMO

* open source

* our community likes it too ('it is simple to use and does what it should')

* the inbuild search is good

There are parts that work better than with Github:

* The email response is bundled over 10 minutes before sending, reducing emails a lot and allows for fast edits!

* you see in your notification where you get likes (you don't get emails because of this of course)

What I don't like:

* performance feels not that great for longer threads (similar problem on github IMO)

I think anyone paying attention knows the world went from lots of phpBB community websites straight over to Reddit. Reddit is hideous, but man, it's easy to use, and accessible.

I don't think I ever saw a successful community run on top of discourse.

Funnily enough, the phpBB (old, static, boring but predictable) vs Discourse (new, fancy, JS-laden) debate is literally going on on Reddit right now as they told the mods they're going to take away custom subreddit CSS for the new design since it's a fundamental rewrite (and replace it with theming tools which they have denied are going to be as limited as colour pickers, but we'll see), which judging by the mobile site will be a card-based, infinite scrolling, React app.

I've never seen a successful community run on top of Discourse either. However, that's because:

1. The people who like internet forums and more traditional communities don't seem to like it very much, and prefer sites using traditional scripts like phpBB or vBulletin or XenForo.

2. Those who find forums outdated find Discourse as or even more confusing than traditional forum scripts and don't really see the point in it.

So the succesful forums opening at the moment pick something else, because that's what their userbase wants. The ones trying to use Discourse for something new struggle because the software is offputting for their members and doesn't attract the new audience Jeff Atwood thinks it will. And the sites that switch to Discourse usually realise only too late that A: their forum problems are often down to their management and the state of society rather than the software and B: that their regulars detest the new design.

Discourse just doesn't seem to appeal to pretty much anyone.

> Don't target the low end market if you can avoid it.

But make sure you never mention it explicitly or else millions of angry users from a country will give a 1-star rating to a totally different app that happens to sound a bit like yours.


I'm interested in how to grow community. They started with press release, got 3 customers by offering them everything free + full "white glove" support, court more paying customers, scale infrastructure.

"Sell to people who have money!" is the sole recommendation from these bootstrapper-idols in the startup community, like Patrick McKenzie and related.

Still, if you want peace of mind, try selling to people who don't have money, but who will also not require you to give them support night and day, to write complex contracts and have a lawyer, to have a dedicated helpdesk and to write custom code for.

If you want money, money and money, ok, this is probably fine advice, but not all people want that. Many people, I believe, want to write software they enjoy.

> I believe, want to write software they enjoy.

Which is pretty tricky if you don't have money.

Wow, you are so smart!

> "Sell to people who have money!"

As opposed to optimizing your product so that poor people can enjoy it too.

>And of course we have the open source version for people with low or no budget, and our free GitHub program for popular open source communities.

It's free software.

You say that, but many devs do precisely what you're talking about.

They compete with existing frameworks to solve problems starving devs are having instead of looking around for the problems that small to medium-sized businesses are struggling with and getting little to no help with.

Enjoyable article. If you liked this article, then you might also like some of Jeff's other articles like this one about Why Do Computers Suck at Math: https://blog.codinghorror.com/why-do-computers-suck-at-math/

This Atwood fellow seems to know his CS. He should set up some kind of support forum that devs can use to get help with their coding problems.

Hmm what should it be named?

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact