While the tool looks promising, there are several red flags that come to mind that make me hesitant at wanting to roll out a Production-quality documentation site based upon it.
First is the fact that the software is licensed under the AGPL, which seems rather heavy-handed for a platform that claims to be Open Source -- while largely being built by a "1-Man Operation" -- and yet claims to seek contributions from the Open Source community.
I get it, you've put years' worth of your heart and soul into building the platform.
To be brutally honest, though... either make it Open Source under a permissive license such as the MIT License (attracting more competent Coders to the ecosystem, while allowing them the incentive of retaining rights to their Value-Added "secret sauce" enhancements); ..
.. or make it a proper Busines Venture and build out the complete product as a Closed-Source solution. Nevermind all those "Coming Soon!" tags on features that are well over 2 years old now; and nevermind the author is hinting at a "3.0" upgrade to the largely feature-incomplete "2.0" stable version.
Some of the features that I would want, in order to consider wiki.js complete enough to roll out into Production are Custom Theme Support, Blog Template Support, and some means of Access Control.
Designers should be presented with a WYSIWYG environment and allowed to manipulate in a manner similar to other tools they have.
I was very much looking forward to writing blogs AND combining or linking them to Wiki-style documentation here. Sadly, Blog support is non-existent. There is no apparent breakout for a Post data type, versus a Page data type (as you would see in WordPress, for example).
Nevermind there would need to be a whole other means of navigating through Posts -vs- Pages (Pages via Navigation Tree, and Posts via Chronological Order or Category Name).
And then there's a sticky issue when it comes to searching for content by Tags -- keep Posts and Pages separate, or join them together as the results of a Tag Cloud?
Of course, for most Wiki Pages, the default audience would be Public (requiring no Access Group Memberships to view).
Access Control seems half-baked at best right now. There is support for Users and Groups, but.. again, brutally honest.. what's the point of establishing those, if not to implement Role-Based Access Control (RBAC)?
Nevermind the glaring missed-opportunity here: If you've got good content that people are interested in, there's eCommerce opportunities in selling ACCESS to the locked or private content. Imagine writing a Tutorial Course, setting the first chapter as a freebie teaser, and hooking the reader into purchasing the more advanced detailed chapters of the course.
Derp! Looks like I didn't spend enough time working with this Wiki solution. There is indeed a mechanism in place for Data Hiding and Access Control. Excellent, that is a huge gaping hole that I don't have to consider implementing on my own.
To be honest, now that I've had more time to explore the system, all that's really needed for my purposes is the addition of a "BLOG" module that sorts and filters pages (somehow marked as "posts" for the blog) in Chronological order of a Published-At data field. If I can manage that missing bit, then the last remaining bit (developing custom themes) would be something relatively worth the time-investment.
While I could spend time writing my own Wiki engine... I have other time consuming tasks on my list, and am at a point where it's better to buy than build. Had wiki.js been at a more mature state (and relaxed License), I might be inclined to stick around and whip up some contributions (particularly in the ACL data hiding stuff; while keeping the eCommerce Unlock/Sales feature private for myself).
Overall, though - it is a useful little Wiki Engine. Yeah, a little rough around the edges, but hey, it's offered for free (as in beer), and is largely done by a single guy. I really like the ability to insert a FLOWCHART or Diagram directly into the Wiki Document -- that's some excellent Code-Fu, and could otherwise be a killer-feature that gives wiki.js an advantage over more established Content Management Systems.
... a bit frustrating that Markdown Syntax doesn't have an easy way to indent blocks. I'd much prefer to indent such blocks, and maybe set the background a different shade to set it apart from the content.
echo "Hello World"
Looks great, easy to set up (especially if you've got Docker ready to roll), and a strong contender. I expect more adoption in the coming years, and look forward to seeing it mature. Sadly, it just doesn't meet my needs for a quick and immediate Production rollout at this time.
Maybe I'll stick around and hack on it here (RubyJedi.com) as a playground project. We'll see.