I would rather want a Typora-like (but nicely embeddable) MarkDown editor with realtime visualization (instantly applying relevant visual formatting to MarkDown elements) to ensure user's mental model of the document and the actual underlying model are always the same. IMHO classic WYSIWYG editors are evil.
Slate – A completely customizable framework for building rich text editors
31–40 of 52 posts
Re: Slate – A completely customizable framework for building rich text editors
#32Have been building https://saga.so with Slate for the last 12 months.
Can confirm it was a bumpy ride, but it also gave back a lot. The main reasons for using Slate over Prosemirror were the almost complete API for managing and editing a block based page, and the fact that it's written in Typescript (although partial types support is a recent addition).
We still have quite a few Slate-related bugs, and the size of our extension code to cover for slate bugs/omissions or to extend the behavior in general is now many thousands of lines long, but wouldn't have chosen anything else.
We tried Prosemirror at the beginning and it was very hard to get into. We checked again when TipTap came out (which is a wrapper of Prosemirror), but all our advanced custom logics would have had to be rewritten in Prosemirror so we abandoned the idea very easily. But we support the team behind Tiptap on another open source project, Hocuspocus, which is a client/server wrapper for Yjs, a library for collaboration with a focus on text editors.
In the end, I have PTSD from Slate, but also, we couldn't have done it without it, so thanks Ian if you're reading this!
* my first comment on HN after years of lurking!
Re: Slate – A completely customizable framework for building rich text editors
#33Word of warning, their readme says 'Some of its APIs are not "finalized" and will have breaking changes over time as we discover better solutions.' I started using this library several years ago and have eventually had to rework it using prosemirror because I just couldn't keep up with the breaking changes. Both libraries work in very similar ways, with slate using React for its rendering layer. However Prosemirror h…
This has been my experience with Slate few years ago. The breaking changes were too frequent to stay productive and the project needed more baby sitting than we'd have liked.
Re: Slate – A completely customizable framework for building rich text editors
#34I also had a to pick a rich text editor to build a "better Confluence" [1]. Initially started with Quill, but Quill is really limited and for example can't support rich text inside tables, only simple text.
So after some research I picked prosemirror which is used by Confluence but prosemirror is the harder to learn and the most flexible, there was also Slate which is used by Slite but it was not as flexible as prosemirror and less robust . Notion and Google docs are using their own custom editor BTW.
If you are looking for a rich text editor, there are surprisingly a lot of ressources. Either search for "rich text editor", "slate vs prosemirror" in Google, or my preferred way to get quality information. Search "prosemirror" in the HN search and read the threads [2]
The big complain I have with prosemirror is the fact that there is no official repository of Plug-ins instead everyone is rebuilding everything
[2] https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
Re: Slate – A completely customizable framework for building rich text editors
#35The recent changes to the API in 0.50 look good. The number of iteration passes really shows. Out of the available open source editor frameworks, Slate is probably most similar to Notion’s internal editor system. If I had to rebuild on a framework tomorrow, it’d be Slate or ProseMirror. Still if I used Slate it would be with the expectation that I’d end up owning an aging fork of a forgotten version at some point.
What features of Slate put it closest to Notion's editor compared to other frameworks besides the obvious one that Slate's view layer is built on top of React?
Is it somehow that Slate is more suitable handling asynchronous data (e.g. server generated uuids for each block, recursively fetching content for each block and its children)?
Re: Slate – A completely customizable framework for building rich text editors
#36Question. I'm building a .NET CMS, and want "on page editing". This entails having a string property mapping to, lets say, a headline.
So while editing on page, I want to click the rendered heading and be able to select text and start editing it - without necessarily being able to influence the HTML in any way. Just the text, no styling.
tldr of above: dont allow ctrl+b or pasting of styled content (and probably prohibit enter presses or pasting newlines), only plain text.
Also, if the heading is an inline element inside the h1 element, and its bunking together with other stuff (icons or whatnot), editing of the headline span only should still work.
tldr - edit an elements text inline, in fact the element may be display:inline itself
I had immense difficulty getting this to work with Quill - it wasn't customizable enough. Would Slate work?
Re: Slate – A completely customizable framework for building rich text editors
#37I also had a to pick a rich text editor to build a "better Confluence" [1]. Initially started with Quill, but Quill is really limited and for example can't support rich text inside tables, only simple text. So after some research I picked prosemirror which is used by Confluence but prosemirror is the harder to learn and the most flexible, there was also Slate which is used by Slite but it was not as flexible as prose…
> there is no official repository of Plug-ins instead everyone is rebuilding everything
To be fair, both Slate and ProseMirror call themselves frameworks for building rich text editors as opposed to drag-and-drop editors themselves.
The best way to build an editor yourself then would be to look at other existing editors using the same framework, and try to understand the architecture and usage.
Re: Slate – A completely customizable framework for building rich text editors
#38Have been building https://saga.so with Slate for the last 12 months. Can confirm it was a bumpy ride, but it also gave back a lot. The main reasons for using Slate over Prosemirror were the almost complete API for managing and editing a block based page, and the fact that it's written in Typescript (although partial types support is a recent addition). We still have quite a few Slate-related bugs, and the size of ou…
> and the size of our extension code to cover for slate bugs/omissions or to extend the behavior in general is now many thousands of lines long
yikes, but if it's working now then just tech debt for the future.
I initially investigated using slate.js, prosemirror, and draft.js for my project https://sqwok.im but ended up writing my own parser instead, learning quite a bit about such fun api's as browser Range(), and the many pitfalls of cross-browser compatibility. It was laborious but got it to a place I'm happy with.
Congrats on Saga! It looks like something I might use and I dig the UI.
Re: Slate – A completely customizable framework for building rich text editors
#39Have been building https://saga.so with Slate for the last 12 months. Can confirm it was a bumpy ride, but it also gave back a lot. The main reasons for using Slate over Prosemirror were the almost complete API for managing and editing a block based page, and the fact that it's written in Typescript (although partial types support is a recent addition). We still have quite a few Slate-related bugs, and the size of ou…
Curious if you looked into Editor.js at all when building?
Im in the middle of sizing up text editors myself, seems like editor.js would require less work, but wondering if I’m missing any red flags and should go with Slate or tiptap (prosemirror) instead.
At some point down the road I’d love to implement collaborative editing.
Re: Slate – A completely customizable framework for building rich text editors
#40Have been building https://saga.so with Slate for the last 12 months. Can confirm it was a bumpy ride, but it also gave back a lot. The main reasons for using Slate over Prosemirror were the almost complete API for managing and editing a block based page, and the fact that it's written in Typescript (although partial types support is a recent addition). We still have quite a few Slate-related bugs, and the size of ou…
> and the size of our extension code to cover for slate bugs/omissions or to extend the behavior in general is now many thousands of lines long yikes, but if it's working now then just tech debt for the future. I initially investigated using slate.js, prosemirror, and draft.js for my project https://sqwok.im but ended up writing my own parser instead, learning quite a bit about such fun api's as browser Range(), and…
I know it sounds like tech debt...and it is. But we're to a point where we could potentially be able to integrate those extensions back into the core library and our slate-saga, so it's eventually paying back.
We really needed extensive text manipulation, so starting from Slate gave us a considerable initial boost, but congrats on building your own parser!
Congrats to you and if you try out Saga, let us know about it :)