Think of it like this... you're basically only coupling yourself to ProseMirror. That's the schema you're storing in your database. TipTap is a set of libraries that you can use for your web app etc... but if you ever find it insufficient, you're free to role your own thing.
ProseMirror has been around for a long time and is unlikely to be going anywhere, but having a company with VC funding using it as its base helps ensure that if ProseMirror got abandoned, it'd likely get picked back up by TipTap or some other interested party.
Even if you're building your own editor, unless your editor has a need that ProseMirror's schema doesn't account for or solve it makes sense to use it.
On the contrary, the company with VC may be a bummer after some years and the VC wanted to get ROI: prices started to increase (or appear), change of strategy and abandon/remix the tool, close the store…
Being free and open source surely helps.
I think the future of an open source project and the company behind it really depends on the founders. If open source is really in their DNA, they will fight for it. If everything goes wrong, at least the open source code will remain. The closed code will most likely disappear with the company.
Thanks for your feedback! We really need people like you to point out when things are going in the wrong direction. It's often a difficult balance between making money and giving back to the community. So we need your outside perspective!
With Tiptap we are trying to make it easy to build modern editors. The demands on the usability of an editor are getting higher and higher because of tools like Notion. Building a tool like this from scratch is pretty hard. That's why we used Prosemirror as a solid foundation, but in our daily work of developing editors for our projects we came to the point that we really need an additional layer of abstraction to reduce recurring code that you don't want to write over and over again. Yes, with our layer we made some decisions about how an editor framework should behave, but with our extension-based architecture in Tiptap, which ProseMirror also has, you can extend both layers separately.
As a contributor to the previous version of Tiptap, and as a developer that built extensions into it, I encountered the exact same problem of having to learn two different APIs while trying to build more advanced features.
Out-of-the-box libraries like Tiptap are great when their extensions or components fully cover your use case. But when you need to customize or own the code itself, the secondary abstraction becomes leaky and you start to fight against it.
Because I was building a note-taking app, I spent most of the time working on the rich text editor. Eventually, I just ripped the bandaid off and wrote a new library that was architected off Tiptap but was a thinner abstraction on top of ProseMirror.
With hindsight, I can definitively say that was the better personal choice. The last time I used Tiptap was in 2020, and since then its API has evolved to a point where my knowledge is way outdated. On the flip side, ProseMirror has been extremely stable, improving with a non-breaking typescript rewrite. Digging into the internals of ProseMirror, learning how it has been built and maintained, contributed massively to how I write code today.
That being said, the journey of moving off Tiptap to ProseMirror took a couple of months for a junior dev. So I can understand how a market for it exists. My only wish for Tiptap now is for it to reduce its API overhead on ProseMirror, and instead build more advanced ProseMirror-compatible plugins that require a backend. Collaborative editing (comments, annotations), version control and schema migration, etc are all exercises normally left up to the developer that can be solved by Tiptap well.
A few years ago I evaluated rebasing Notion’s editor on various editor frameworks. ProseMirror came out at the top of my list, but I wasn’t sure how to rank TipTap.
Having more batteries included is good, but I’ve found that layers of abstraction can really get in the way. For example if I need to fix a bug with Android Gboard input, without a framework I can exactly control the DOM structure and input handling, but the downside is no one fixes the bug for me. With ProseMirror, I’d need to tunnel through 1 layer of abstraction and/or patch 1 layer of abstraction. With Tiptap, maybe I’d need to fork-and-patch both you and ProseMirror? Each layer also increases our maintenance liability. If the ProseMirror author decides to retire or take the library in a direction that doesn’t work for us, then we need to fork and maintain it. If both you and the ProseMirror do that, we have more code we need to maintain.
Ultimately I decided adopting a library was too risky, and opted to improve our native ComtentEditable handling. Because our product’s selling point is an editor, we want to control our own destiny.
For others who can afford a library but still need to weigh the risks of that abstraction stack, can you share some insights?