One more point to consider: CodeMirror is not accessible for blind users with screenreaders, as it just presents an empty text area. While Monaco is acdcessible, at least VSCode is. This used to cause a lot of pain for blind people using Jupyter, which uses CodeMirror (or at least used to).
I presume that is because it is a complicated feature, but not technically impossible? Although perhaps using contentEditable* makes an implementation more difficult?
* From article: “CodeMirror would achieve that by leaning on native browser text editing (via contentEditable) rather than implementing text editing entirely in the library/javascript.”.
Edit: from https://blog.replit.com/codemirror “CodeMirror 6 is a complete rewrite of the CodeMirror editor with a focus on accessibility, touchscreen support, and extensibility.”. I expect that marjin really cares about accessibility. However, in my limited experience, as a lone developer I couldn’t make our complex product properly accessible unless that was the focus of say six months effort, which we couldn’t afford at the time.
Ah, you're right, CodeMirror 6 appears to be more accessible. However it still only shows one line at a time. So that's still worse than Monaco. Monaco can show one or two hundred lines at a time. So with CodeMirror 6 I still would have to read text line by line without any way to skip a function for example, which is unnecesarily tedious.
Sure, I understand that people don't have infinite time to spend on perfect accessibility. I was careful not to have any blaming tone in my message.
The article says that the new version of CodeMirror uses a contenteditable and native selection, which I would expect to pretty much "just work" with screenreaders - is that not true?
This is mostly accurate for CodeMirror version 5. But this article is talking about version 6, which was intentionally built in a way that avoids the problem.
