ProseMirror 1.0

Hello, from The New York Times CMS team. We have been working with ProseMirror for the last year and a half or so. Congratulations, it's great to see this finally reach 1.0!

Some of the things we've found really great about working with ProseMirror:

- Separation of the data model from the rendered display has allowed us to extract things like tracked changes and comments which we traditionally embedded as HTML tags in TinyMCE. This leads to less cleaning and prevents inadvertent publishing of metadata.

- Unidirectional data flow makes it work well with applications that use this type of data architecture.

- Separation of modules (prosemirror-state, prosemirror-model, etc) has allowed us to quickly write better tests around our editor code.

- Decorations have been great for implementing the previously mentioned metadata aspects of our editor like comments and change tracking. They're useful for features like our custom spell checking implementation, which checks for Times style in addition to normal spelling/grammar.

- Node views allow us to implement rendering in our own way. We've been rendering React components into them which will eventually allow us to share code between our editing environment and our user facing web stack. They also allow use to render the same editor schema in different ways depending on the context/view they are being used in.

- The step/transaction model has allowed us to move from what was previously a set of additions and deletions persisted within the document to a calculated change tracking implementation. This allows both for a cleaner document but also allows for a wider range of tracking (i.e. show the differences between versions 10 and 15) rather than a static current vs the last "accepted" version comparison.

- Prosemirror’s plugin system is really simple and flexible and has allowed us to add new features to our editor rapidly in a modular way without interfering with other features (comments, custom spell checking, custom find/replace, etc).

The true test of ProseMirror, SlateJS, and all these new augmented text-editors will not be comments, posts or even blog articles.

It will be Wikipages.

A visual editor for a wikipage is the crystallization of the semantic-content conflict as described eloquently by https://en.wikipedia.org/wiki/WYSIWYM

To date, despite a stream of donations and years of development, Wikimedia has failed to develop an editor that is better, by productivity and other lagging metrics, than just editing a text-field:

https://en.wikipedia.org/wiki/VisualEditor https://www.theregister.co.uk/2013/09/25/wikipedia_peasants_...

Increasingly, I believe what we really need is an enhanced markup editor-- where bolded text is bolded text, a quote is automatically highlighted as a quote, but links look like (check this link out)[http://example.com]. The ideal would be to forgo the "drop down to normal text editor" button and have the only & best way to edit be through the new editor.

If you press backspace in an empty list item in the demo, you can continue the item above. The schema is tree-shaped, so you don't have the usual awkwardness about nesting things.

Or, if you mean lists starting at something other than 1.--The schema used in the examples actually supports a `start` attribute on numbered lists, but the UI doesn't currently expose it.

Have you looked at Quill https://quilljs.com/? I was looking at text editors yesterday for a new project, where I want to represent images as either custom tags or placeholders that get transformed (in the system the image is known by its storage ID, not a URL) and Quill looked easier to work with than ProseMirror.

I used ProseMirror back in the day (well over a year ago now) on a site I was working on and it ended up being a nightmare to maintain. It would break on every new version, screw up the build process, error constantly in mysterious ways that forced you to dive into the internals... At the time it was not designed with the state-view architecture either, making it harder to reason about.

I ended up scrapping it entirely for Quill and it was a massive relief.

In my opinion as a mostly-uneducated observer to this project, it is exactly the kind of project that would benefit massively from static type-checking. I can't count the number of times things broke on an upgrade because of simple bugs in the code where `undefined` would trickle through function calls or function interfaces were updated and other parts of the codebase were not updated in accordance. These are not hard problems to solve, but if you're dogmatic about using vanilla JS with as little build step as possible, you're going to run into these all the time.