My biggest complain so far of Prosemirror is that everyone is recreating the same things. Prosemirror core intentionally doesn't handle a lot and is easily extandable. But as result everyone is recreating the same Plug-ins.
Wondering if that would be a good thing if Marijn created some kind of official marketplace for Plug-ins
What is this providing over ProseMirror on which it's built? Like, why would I choose this library instead of just using ProseMirror directly? Adding such a page to the docs might be helpful. Here's a great example of what such a comparison might look like: https://github.com/colinhacks/zod#comparison
Hey thats a great feedback, I am planning to address this in the coming weeks.
For anyone reading this, the gist is that it complements Prosemirror by providing pre-cooked components that you can use in your project. If you need more advanced functionality, bangle doesn't stand in your way and you can extend it to your hearts content with Prosemirror.
This seems to be built on top of the venerable ProseMirror.
Had developed something slightly similar (for now primarily used in-house and API is somewhat clunky and unstable): essentially, a wrapper around ProseMirror that makes it easy to use in React, and introduces an additional abstraction that combines schema features and related editor plugins. Thought someone can make it better, and maybe this is that project.
Tangentially, a cool thing would be to unite ProseMirror with Automerge. That’d enable some killer collaborative editors.
> Tangentially, a cool thing would be to unite ProseMirror with Automerge. That’d enable some killer collaborative editors.
Prosemirror already has collaboration baked into it and I have a very rough initial version of it working (see https://github.com/bangle-io/bangle.dev/tree/master/collab). My question for you is what benefit will using Automerge provide over the inbuilt collaboration API?
I have been following remirror since the start and also started working on bangle.dev at the same time.
bangle.dev aims to add little API overhead on top of Prosemirror (PM) whereas Remirror tries really hard to hide the PM API and attempts to provide its own React-ish abstraction. This might be a totally fine choice, but I went with the route of building reusable components instead of abstractions.
I'm glad to hear this! Using Remirror worries me because it injects an abstraction between our code and PM.
However, when I look at your docs, it's not clear it's a different in approach from Remirror. The imports are all from bangle.dev which makes it seem like the same approach.
I would love to see a doc explaining the "API overhead" and how to use PM directly. I want to feel confident I can easily drop back down to PM if Bangle doesn't have a feature I need or implements it in a way that won't work for our use case.
Really excited to see this approach! Shared PM plugins are a great idea!
Ours looks fairly similar in the core concept. Less polished. A bit older. Will have to take a detailed look at remirror later!
Update: I created an abstraction called “feature” that seems to be similar to the extension concept, but different. Through features, editor creator can contribute related schema aspects and plugin views. Schema is always there and is not handled by a separate feature, however.
Very cool! If you are considering codemirror 6, the author had a nice little talk at fosdem this year that goes into a bit of the features and design: https://fosdem.org/2021/schedule/event/codemirror/
I really hate all these "fancy editor in the browser". They're all really awful (slack's being the worst) and do not work well with edit-in-your-favorite-editor plugins like Firenvim or GhostText.
I'll prefer simple textareas that accept markdown everytime.
I tried to use slateJS initially, but I found the project to be slow (it was using ImmutableJS back then) and even though it claims it can support collaboration, it doesn't actually support it which is a deal breaker for me.
Slate.js, even after change to Immer is slow. IMHO (as a person who actively observes the development, sometimes participate in their Slack) the "performance" is not taken seriously in this project. In last few months they provided few PRs that improved few cases, while breaking others. I am impressed how many projects are using it [0], because it has problems to handle editing and pasting huge documents. I also see many PRs from community focusing on optimization but they are ignored, stalled or prematurely closed. It also does not handle IME properly, which is a major problem for many languages. However, I see maintainers started to be more active, so all problems I have mentioned might be fixed soon.
