It's buggy, prone to spam, probably not secure, missing features, etc. Probably should've named it an alpha, almost. But if you're game you could give it a spin - we're running our support forum on it currently. Will fill out that roadmap tomorrow :)
I work for Pusher and I have upgrade your account to a business plan for now.
We always love to help up and coming product, especially open source ones so drop me an email at sylvain@pusher.com to discuss this further. Happy to help.
This is very kind of you and Pusher, but I have to be honest, if I'm to ever consider hosting something like this I'd like the option to be entirely self hosted and not reliant on external services.
You can also get something up an running in Go very quickly that should scale pretty well and might make deploys easy since you can just compile to binaries.
Fair points. I guess I consider esoTalk to be somewhat of a lost cause in terms of the way it's built. It's a pain to implement fixes and features, maintain, and is pretty limited in what it can do (and how it can be extended). Simply put, I didn't enjoy working on it.
When I said "I have produced some low-quality code and APIs that will surely need revision", I'm mostly talking about more semantic things like class naming and organization. The majority of Flarum's architecture is very solid, testable, and will be easy to maintain. Doesn't compare to esoTalk.
Admittedly, if I just wanted to start a business and make some cash, you're right: I probably could've just persisted with esoTalk. But it's not all about money – it's also about doing the best work that I can, enjoying it, and making damn good forum software with great potential.
There will eventually be a migration path from esoTalk to Flarum, and I still merge PRs from time to time... so I like to think I'm not completely abandoning the esoTalk folk!
Mind reporting an issue for this? (https://github.com/flarum/core/issues) I can't test directly because I'm using a Mac, but it would be great if we can continue investigating on GitHub :)
We built Flarum to be highly extensible, so something like this could easily be implemented! Eventually we'll probably make an official Q&A extension too. If you want to learn more about Flarum's extensibility, check out http://flarum.org/docs/extend/.
It doesn't at the moment! D: That's something we plan to address very soon though. Not sure what specific strategies we'll implement – will sit down and nut it out in the next week or two. https://github.com/flarum/core/issues/271
Can I ask specifically what you don't like about the direction Discourse/Flarum are taking?
I can't hope to compete with Discourse on features (yet!), but I think Flarum's elegance sets it apart. Out of the box, it's pretty, fast, easy to use, and works beautifully on mobile. And it's written in PHP, so is super easy to install – any low-end shared host will do.
I like the fact that Flarum has an html-only version for browsers with disabled javascript, but it seems to be an alternate implementation, not the same content with less interactivity as it would be expected - it shows much less information and doesn't seem to have feature parity with the interactive version.
This means that the software will only be usable from interactive sessions on "standard" mainstream browsers, and won't be easy to integrate with batch-processing tools (like web scrappers or data warehousing) or non-standard environments (anything enabled for the semantic web or developers creating handcrafted personal scripts to enhance their workflows). Classic "static" forums don't suffer from such limitations, being based on simple html and having predictable navigation structures.
Ok - I see how it solves the automation problem. But it means that humans and bots are accessing different web resources to get the same content - it abandons the original idea of the World Wide Web where a single content resource was expected to be used by humans and computers alike using a unified, simple syntax.
Are you talking about content negotiation? I don't think a "single content resource" really makes sense. When humans access a page, they aren't just looking at a single resource, they're looking at a blend of disparate resources (e.g. all the content in the navigation, sidebar, footer, peripheral sections, etc). Hence the need for a dedicated API that returns pristine data.
> it abandons the original idea of the World Wide Web where a single content resource was expected to be used by humans and computers alike using a unified, simple syntax.
I believe we are long past that idea, it's just too much of a restriction for the web in order to compete for audience with other technologies (meaning apps).
Thanks! The compiled source (http://flarum.org/download) should run on shared hosting no problems. The bash scripts are only for building that ZIP that we put up for download, and setting up a Vagrant development environment. See http://flarum.org/docs/contributing for more info.
We output a copy of the page's data within <noscript> tags. (e.g. http://discuss.flarum.org/?nojs=1) Admittedly it's currently pretty bare-bones and not actually very optimized, haha
