Live data from Hacker News

Switching Rich Text Editors, Part 1: Picking Tiptap

ashbyhq.com

11–20 of 54 posts

Re: Switching Rich Text Editors, Part 1: Picking Tiptap

#11
ToastUI (https://ui.toast.com/tui-editor), which builds on ProseMirror, was really easy to set up and has been very stable for us. It's a WYSIWYG editor that just renders markdown, which is what we wanted to have as the base representation for written content so we have some portability later depending on how our product evolves.

Re: Switching Rich Text Editors, Part 1: Picking Tiptap

#12
I use TipTap as a rich text editor in my open-source weekly journaling app.[0]

One of the big gotchas I've had with TipTap is that it's extremely sluggish once you get to more than 300 words or so and you're using different formatting options. There's a multi-second delay between typing the word and the text appearing in the screen.

The APIs are pretty nice, and I was able to convert to/from Markdown with it easier than other solutions I looked at, but the performance really reduces usability.

I've only used the FOSS version, so maybe TipTap Pro is better.

[0] https://github.com/mtlynch/whatgotdone

Re: Switching Rich Text Editors, Part 1: Picking Tiptap

#14
post #10

i had no idea what ashby was or how they were using tiptap, so i clicked on the logo at the top of the page - and i still have no idea what ashby is, or how they are using tiptap!

They seem to be enterprise focused. I guess they want to pick their customers, not the other way around.

Re: Switching Rich Text Editors, Part 1: Picking Tiptap

#15
post #12

I use TipTap as a rich text editor in my open-source weekly journaling app.[0] One of the big gotchas I've had with TipTap is that it's extremely sluggish once you get to more than 300 words or so and you're using different formatting options. There's a multi-second delay between typing the word and the text appearing in the screen. The APIs are pretty nice, and I was able to convert to/from Markdown with it easier t…

Are you sure that it's not something else interfering with TipTap? Their long demo https://tiptap.dev/examples/book which has 200,000 words was still very responsive.

Re: Switching Rich Text Editors, Part 1: Picking Tiptap

#16
post #12

I use TipTap as a rich text editor in my open-source weekly journaling app.[0] One of the big gotchas I've had with TipTap is that it's extremely sluggish once you get to more than 300 words or so and you're using different formatting options. There's a multi-second delay between typing the word and the text appearing in the screen. The APIs are pretty nice, and I was able to convert to/from Markdown with it easier t…

Are you sure that it's not something else interfering with TipTap? Their long demo https://tiptap.dev/examples/book which has 200,000 words was still very responsive.

That page just freezes the browser using Brave on Android.

Re: Switching Rich Text Editors, Part 1: Picking Tiptap

#17
Very timely topic. For those of us looking for more flexible options, like for an online news publication that needs to show well placed and sized images and so on, I wonder what everyone is using that isn’t Wordpress but has the same sort of core functionality.

Like for example if you wanted a Wordpress style story editor in rails is there an obvious option?

Re: Switching Rich Text Editors, Part 1: Picking Tiptap

#18
> A significant disadvantage was that we couldn't have both 0.47.x and 0.63.0 in our application simultaneously.

You definetily can! We used Slate `0.47.x` at Leadsimple[0] and we went through the same hustle and decided to go with Slate again! We have both versions running in production for 3 months now, and we didn't have any problem. You can add separate versions of the same library using a feature of `yarn` which allows you to declare `"slate": "^0.47"` and `"slate-latest": "npm:slate@^0.72.0"`. Then, in your code you just need import `slate` when you want the older version, and `slate-latest` when you use the new one. We also had to inline some stuff because `yarn` isn't the smartest when solving dependencies, but it sure is possible :). It wasn't easy, but the end result is amazing, and REALLY fast, hasn't caused any problem to us.

[0] https://www.leadsimple.com

Re: Switching Rich Text Editors, Part 1: Picking Tiptap

#19
post #13

This analysis that GitLab did was really valuable for helping me do my research on an editor architecture for my app. It almost reads like a blog post, it's an incredibly well-written issue. https://gitlab.com/gitlab-org/gitlab/-/issues/273238

Yeah this is fascinating, thanks for sharing. Also the proof-of-concept issue has lots of great detail and challenges; https://gitlab.com/gitlab-org/gitlab/-/issues/231725

Re: Switching Rich Text Editors, Part 1: Picking Tiptap

#20
post #8

Ah, the joy and horror of rich text editors. I completely understand the selling points and the attraction, but I gave up on 'm for my projects. Not saying that OP must do the same, though. I eventually settled for plain text in a simple textarea, with basic possibilities for markup by allowing Markdown. No more struggling with different browsers, no struggling with how the RTE looks and feels, no incompatibility iss…

I try to argue for this approach as much as possible but it rarely gets through to product people.

A slick interface and the age old adage "don't make me think" are hard to argue with. ;)
Post reply on HN