Flarum vs nodeBB

justshipit

I am about to set-up forum and would love to use Flarum but looking at current codebase where I am having challenges even to hard-code custom navigation I will be looking for another platform. I stumbled upon nodeBB and it seems to be the closest to Flarum if it comes to user experience. Now 2 questions:

Does anyone used nodeBB before?? What are the major differences between Flarum and nodeBB? And why would you like to go for X over Y?
If I go for node and later want to switch to stable (non beta) version of Flarum, how challenging it will be to migrate database with accounts and posts?

Appreciate all constructive responses!

ron_jeremy

justshipit I fooled around with NodeBB and Discourse test forums for a few weeks. I found Discourse more 'robust' than NodeBB. What I mean by that is changing a theme or even changing a theme color would sometimes bring down my NodeBB forum, but I did not see this type of instability with Discourse. However, Discourse needed more cpu and ram to feel a snappy as NodeBB.

It's all a moot point anyway, since I feel Flarum is better than both those options. It would not surprise me to see many people starting to use Flarum in production as it approaches beta six or seven since the software is already very stable and will likely have implemented a few key missing features by then.

Another option would be to use a forum engine with a very easy migratory path to Flarum, something like EsoTalk, FluxBB, etc.

jordanjay29

Well, the underlying software is different. Flarum is built on PHP (even though it makes heavy use of Javascript, PHP is where all the fun stuff happens). NodeBB is built on node.js. So the big difference is the kind of servers you can use, node.js will (for the most part) need a dedicated server like a VPS or a whole box just for its websites, while a PHP application can run on most any shared hosting out there. There's some other dependencies and specifics, but that's the main requirement for either one.
I'd expect that, eventually, someone will write a proper importer/converter for popular forum softwares like node.js. You might not be able to import everything across, and you would have to switch servers (or be on a server that you can rework to host Flarum) in order to do it. There's no telling when some importer might be out, it could be tomorrow or it could be next year, so unless you're savvy and could build it yourself, you're at the mercy of whoever will want to write it.

Hope that helps. I understand the dilemma, I went through the same thing before I came to flarum. Maybe if you tell us what you're looking to do with the site, we can better help you decide!

justshipit

Thank you @jordanjay29 and @ron_jeremy !

@ron_jeremy EsoTalk is an option!

To be honest, I don't mind to start using Flarum in production right now if I can be sure I won't loose/break the data (accounts + posts) during upgrade to newer versions. I can survive without having customised header for some time.

jordanjay29

justshipit To be honest, I don't mind to start using Flarum in production right now if I can be sure I won't loose/break the data (accounts + posts) during upgrade to newer versions.

That's really the thing we can't guarantee.

justshipit

@jordanjay29 I understand this is now a priority to make it bullet-proof for updating Flarum version without data loss? ?

Davis

justshipit Flarum is a very viable option so long as you religiously backup your user database ?

luceos

justshipit There is a guarantee you won't lose data, because updates won't be forced. The question is will your current data work with a higher version and whether you corrupt your own database by trying to upgrade ..

At this point in beta design choices are made that require either a very complicated update process or change one line in one of the original files of Flarum core.

1. simple but possibly non-forward compatible change

For instance an issue exists that require one change in a database table creation file or a complex upgrade script. If you've read @Franz response, it's suggested to do the easy fix, because "I think we can just cheat (we're still beta, hey) and fix it in the existing migration". And that's a logical choice, there is no reason to complicate an initial installation with upgrades meant for a non-stable release.

So how does that effect your installation?

Simple, once that change has been added to a new release and your code seems to break, you will have to run those database changes manually. Can you do that? Will you lose data when you do? That's all up to you.

2. complexer forward compatible change

Another example is the addition of this migration, added in December of last year. It changes the column type of "value" in the "settings" table to text instead of blob. Which allows for easier editing of those fields with a database tool.

This is a great example of a change that could have been modified in the initial database migration, but was added seperately to ease upgrading.

what can you do?

don't use an unstable version; the obvious choice.
make backups before upgrading, not a suggestion but a requirement (database and files please).
don't upgrade; I mention this because it's an actual choice, but not a valid one ? because upgrades might patch security issues.
get help when you get stuck during upgrades you do yourself.

conclusion

We advice everyone to not use Flarum in production because it's not stable. Whether you like a challenge and are up to get your hands dirty is up to you, we won't force you against using Flarum beta or deny you the freedom to ask questions.

lichengkun135

Can we talk about this topic again now? 😂

luceos

lichengkun135 flarum is stable now 👍

Jishnu

lichengkun135 😃😃😃