quill VS TOAST UI Editor

I started with Quill... wound up hitting lots of challenges. There are bugs/issues like, "don't add extra margin or it will be converted to extra spaces." I also struggled to embed Quill into an HTML form element, which I though would be easy.

Fair enough. Look maybe into more of a utility like Quill? https://quilljs.com/

I agree. Yes, you can. Quill is the example here.

Actually, back in 2015 when we started prototyping CKEditor 5, we started with this approach as well. Our goal from the beginning was to combine real-time editing capabilities with an engine capable of storing and rendering complex rich-text structures (nested tables, complex nested lists, other rich widgets, etc.). We quickly realized that a linear structure is going to be a huge bottleneck. In the end, if you want to represent trees, storing them as a linear structure is counterproductive.

So, we went for a tree model. That got many things in the engine an order of magnitude harder (OT being one). But I choose to encapsulate this complexity in the model rather than make it leak to particular plugins.

In fact, from what I remember, https://github.com/quilljs/quill/issues/117 (e.g. https://github.com/quilljs/quill/issues/117#issuecomment-644...) is a good example of issues that we avoided.

I also talked to companies that built their platforms on top of Quill. One of them ended up gluing together countless Quill instances to power their editor and overcome the limitations of the linear data model but is now looking for a way to rebuild their editor from scratch due to the issues (performance, complexity, stability).

So, yes. You can implement a rich-text editor based on a linear model. But it has its immediate limitations that you need to take into consideration.

I've always used Quill and always satisfied with it. It can be adapted to React Native as well. Despite the most popular RTE is Draft js it has some limitations on mobile.

NgPrime has this editor if you’re using it already for components. Or Quil could work

Quill

The few I have seen out there are flask-blogging, tiny-blog, and maybe quill?

So if one were to use https://quilljs.com/ as /u/ike_the_strangetamer suggested and just include a disclaimer that the site doesn't support pasting in some things, would that work?

In short there are two different types of keyboards. One type, like GBoard sends entire words once you select an autocorrect recommendation from the list... it sends the whole word, all its characters, all at the same time [acts almost like pasting], whereas other keyboards send letter-by-letter. If you think about how autocorrect on phones work nowadays, if you type the word wrong, but then tap on the correct word on your keyboard, keyboards now have the ability to delete and replace entire words (and not just characters). So because of this, some android keyboards don't actually send the absolute cursor / text-selection position anymore. Instead they send it relative to the last words you've selected. You can see other note taking apps and editors plagued by keyboard issues due to this exact phenomenon on Android here as well, mainly relating to newline characters. (while the newline is added, cursor isn't updated etc) : Microsoft OneNote, Workflowy, CKEditor, Quill, RichEditor for Android, etc... Since you mentioned that your issue happened -after- you selected / copy / pasted some text, I cannot eliminate the possibility that an android os flavor (or its selection handling, since it's different for each android version and os vendor) / keyboard / browser might also be the cause. I.e. in Android Firefox, there is a bug and you cannot select words inside rich text editors by double tapping on them like you can in any other browser. This bug has been around for -6 years- now. Affecting even Github on Firefox Android. We also chimed in and tried to keep it moving, and despite our best attempts, after 2 years, Mozilla just closed the issue without even fixing the bug. You can see relevant links here. So unfortunately, browsers and keyboards on Android can cause really strange issues, and we cannot anticipate all the weird and unexpected ways they might break. 3 ) Since you also mentioned copy/pasting stuff, often people experiences issues like this when they use things like clipboard syncing tools on Android (i.e. pushbullet, or on iOS iCloud's clipboard sync etc) Because you never know what was leftover in the clipboard at the time you copy pasted, and sometimes if the sync is delayed, these things may misbehave, and paste twice, or with a delay, or paste a blank return key unexpectedly etc. 4 ) This is the silliest but still likely scenario that I still have to mention. Sometimes, depending on the OS/Browser combo, when users copy paste text from Cryptee while it's in dark mode, paste it into another part of the document, then open the document in light mode, it causes text to have white color, and makes it look invisible, causing panic.

If you need a WYSIWYG markdown editor you can try Toast UI Editor or simply use Markdown Live add-on for Visual Studio Code

- Toast UI Editor: https://ui.toast.com/tui-editor

https://github.com/nhn/tui.editor Might be close to what you are after.

Can you elaborate a bit more on this part, please?

> I'm thinking of building a text-annotation based app _alone in my spare time_. The core usage loop is about viewing and interacting with "visual markup" applied to a body of text. So lots of tooltips/hoverbars I guess.

Or show us a mockup... doesn't have to be anything fancy, just like a pen and paper sketch or a simple Figma.

I'm asking because it kinda sounds like you're wanting to do something like an online IDE or Google Docs, where you're manipulating a body of text in the style of a rich text editor. If that's the case, it's possible the HTML DOM model isn't quite the right fit for you... you may find it better to abstract over a Canvas or WebGL object instead of trying to shoehorn that experience into the raw DOM. That way you have full control over rendering, outside of the normal layout/styling/rendering loop. It might also make a good case for a single-page app (at least the majority of the editor itself would be, and the other stuff -- marketing, blog, etc. -- can be routed to individual pages).

In that case, it wouldn't be so much a question of "framework" in the sense of React, Vue, etc., which traditionally work on the DOM. It might be more a question of "engine", like whether to use something like PixiJS to manipulate the graphics layer vs rolling your own. State management can be done with something like Redux (even without React), or if you choose to use a frontend framework for the rest of it, you can maybe use their state solution with your rendering engine.

In addition to choosing a low-level graphics lib, you can also look at some existing rich text markup solutions. A CMS I used had a good blog post on this: https://www.datocms.com/docs/structured-text/dast#datocms-ab... along with their open-source editor: https://github.com/datocms/structured-text

A more widespread one is the toast UI editor: https://ui.toast.com/tui-editor

I know you're not just working in Markdown, but these give you an idea of what it's like to work with complex text trees in JS.

Once you have the actual text editor part figured out, choosing the wrapper around it (again, just for marketing pages, etc.) is relatively trivial compared to the difficulty of your editor app. I really like Next.js myself (if you choose React), but I don't think you could really go wrong with any of the major choices today... React/Vue/Svelte/etc. And it looks to me like the complexity of your site wouldn't really be around that anyway, but the editor portion.

Lastly: I don't think ANY JS tool or package is going to be maintained in 10 years. Frankly, 2 years is a long time in the JS ecosystem :( I'm not defending this phenomenon, I hate it too, but that's the reality of it. If long-term maintenance is a goal of yours, you might want to consider writing abstraction layers over third-party tools you use, so you can easily swap them out when future things come out (because they will). The web itself is changing too fast for libraries to keep up; instead, people just write new ones every few years. An example of this is the pathway from the Canvas to WebGL to workers to WASM (and how to juggle heavy computational vs rendering loops around)... a lot of the old Canvas-based renderers, which were super powerful in their time, are now too slow vs the modern alternatives. Nobody is going to port the old stuff over, they just make new libs. It's likely that trend will continue in the JS world (that whatever you write today will be obsoleted by a new web API in a few years).

Lastly, as an aside, TypeScript is a superset of JS... if you find a JS project/lib/plugin that you want to use, there will often be types for it made by the community (https://github.com/DefinitelyTyped/DefinitelyTyped) , or you can write your own types for it. I don't really have an opinion about TypeScript vs writing in some other language and compiling to JS, but it would probably be easier to find help (especially frontend) in the future if you stick with TypeScript instead of convoluting your stack with multiple languages. Sounds like most of your app will be clientside anyway with limited backend needs.

---------

Tech aside... have you considered partnering with a frontend dev for this? I know you said "alone", but just having someone set up the basic skeleton of such an app with you for the first month or two could be super helpful. Or a UX person to help you with some of the interactions before you start serious coding. They don't have to be with you the whole journey, but maybe they can help jumpstart your project so you can then work on adding features & polish in your spare time, instead of figuring out basic architecture? Unless, of course, that's the part you actually enjoy. In that case, don't let anyone rob of you that :)

Have fun! Sounds like a cool project.

I think the Toast UI Editor can achieve what you want, and it does a pretty good job at that. Is built upon ProseMirror. Won't be a lot else out there since it's actually quite a hard thing to achieve once you get into the detail.

Ideas to add: - add markdown editor that works via plain JS - ability from UI to rollback to previous note version (git checkout) - Ability to create directories for notes

To make it as brief as possible, this post will only deal with some of the issues that you might encounter while implementing ToastUI Editor inside Next.JS projects.

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.