What led to the choice of using Blocknote over other editor packages? Would love to read about the decision making and comparisons between all the editors you considered. Also interested in any other write ups about choosing packages (ex: I see you using hocuspocus which I think is from another editor - TipTap) and why you landed on your particular tech stack.
Maintainer of BlockNote here (and contributor to HocusPocus). I can't speak for Docs as to why they chose BlockNote, but can answer some of your questions. BlockNote is actually built on top of Tiptap - but designed to take away the heavy lifting. As powerful as they are, to build a Notion-like editor on top of Tiptap (or Prosemirror) still requires quite some engineering firepower. We've built BlockNote to come "batteries-included" with common UI components and a simpler API to make it easy for you to add a modern, block-based editor to your app.
That's very cool, as a happy user of TipTap this is the first I've heard of BlockNote - excited to check it out. I've also built a few modest things on top of TipTap and felt a slight "tower of babel" unease, would you mind saying a bit about what BlockNote takes from TipTap which couldn't be accomplished with Prosemirror alone?
This comes from a place of pure curiosity, I don't actually believe this strata of editor packages is in any way inherently bad!
Hey! Not a developer but here are a couple pointers.
As Yousef says below, the text editing bit is hard. We wanted to be build fast and BlockNotejs makes it easy, you get the block stucture, the slash command, you can style your editor and extend with custom blocks. The BlockNotejs team researched the live editing space thoroughly so we could just follow the tracks: BlockNotejs, HocusPocus, Yjs. We "just" had to build the wrapper around with authentication, docs permissions and search and boom you have Docs!
Really cool to be able to test this directly, thanks for setting it up.
I found something I would qualify as a bug: if you click on the right of any text, the cursor is placed at the beginning of the line, where I would expect to have it at the end.
It's not only considered, it's a an actual goal to be 100% usable by everyone. It's already the case for some of La Suite projects. Not quite there yet right now for some others, but it will be.
And I agree, lots of popular, proprietary solutions should do better in terms of accessibility. I believe open-source helps in that regard, as in many others.
Here in La Suite we have some wcag-geeks in the team and regularly include some of our users with disabilities for feedback.
https://react-spectrum.adobe.com/react-aria is used in most La Suite projects. Also we have one frontend developer focused on accessibility and few auditors. We always prioritize accessibility
We also made a small scratchpad you can use to test collaboration features, if it doesn't get too flooded :) https://docs.numerique.gouv.fr/docs/a3f0becc-f2b7-45be-a5e5-...