Some features worth highlighting:
- Monaco editor and Prettier integration for code snippets
- Tables (apparently the holy grail of WYSIWYG editing)
- Embeds (for CodePen, CodeSandbox and YouTube, most useful for HTML or JSON exports)
- Accepts Markdown paste-in, and "exports"/generates HTML, Markdown and JSON outputs
- Collaboration (with real-time awareness and initial commenting system, available only when logged in)
- GPT-3.5 integration (only when logged-in with the corresponding extension installed)
Stack used: TipTap, Solid.js, HocusPocus, Fastify, tRPC.
Some notable drawbacks:
- No mobile support
- Collaboration available only between signed-in users, in the same workspace;
- I tried my best to support most common Markdown formatting, pasting and in-editor shortcuts, though there might still be room for improvement
- Self-hosting isn't easy right now, though you should be able to figure it out from the source code
The editor itself is a standalone app, extracted from the larger Vrite CMS project (https://github.com/vriteio/vrite) which you can also test out (only with sign-in) here: https://app.vrite.io/
That said, from the original document about Markdown[0]:
> The overriding design goal for Markdown’s formatting syntax is to make it as readable as possible. The idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions.
From my experience, the benefit of Markdown is that it eliminates the need for WYSIWYG, because WYSIWYG is awful to work with.
Put those two things together, and it's weird for me to see Markdown used like this. Not saying it's wrong or bad or whatever, just that it's weird and seems to cut against the spirit of the thing.
Slack's "markdown" is horrifically broken and one of the worst markdown experiences in existence. I believe they no longer even refer to it as markdown since they have strayed so far from the spec.
For most users, the opposite is true. They understand WYSIWYG well and that is how most things work.
For developers, WYSIWYG is difficult because it is usually tightly coupled to very complex formats which require very complex data structures to represent. Markdown seems an nice, limited format that would make for a nicer, saner WYSIWYG for developers (except the inline HTML part of the spec).
Most users know how to muddle through with WYSIWYG, but they also lack experience with actually reliable editing environments. So they just take for granted all of the fighting they have to do with the semi-hidden state of the WYSIWYG editor.
99% of WYSIWYG users also fail to use their word processors correctly even on the terms of those word processors themselves. They most often totally eschew templates and page/paragraph/character styles in favor of manual formatting changes that all individually 'look right', turning all sizeable documents into unmanageable messes when it comes to consistency or formatting changes. It would be generous to describe this norm as actual proficiency, especially in a professional context.
Moreover, it's clear that the WYSIWYG paradigm itself is what invites this widespread incompetency and poor document quality. Why manage things in a systematic, organized, or efficient way when you can watch the document take shape before your eyes by highlighting individual words and manipulating their appearance or padding things with spaces, without having to give a thought to the structure of your document in advance?
> Markdown seems an nice, limited format that would make for a nicer, saner WYSIWYG for developers (except the inline HTML part of the spec).
WYSIWYG is not in fact less buggy with Markdown, as can be witnessed in the unholy WYSIWYG-Markdown unions of, e.g., Teams and Slack. You still inevitably end up fighting the system just to get your cursor to stop adding text with that formatting, or to escape that quote box, or whatever.
Vrite's primary format is JSON, but with MD shortcuts, parsing on paste and parsers converting JSON to MD, I think it integrates quite nicely in most cases.
the primary format is prosemirror document format, rather than JSON (even tho it is in JSON).
You type markdown, and as you go along, it renders the markdown into its presentation style: italics are italicized, links turn blue and underlined and clickable, lists become lists, and so on.
And so there certainly is a visual difference between "plain text" markdown and "rendered" markdown, but behind-the-scenes you still have a markup language that is less awful than all the other markup languages.
How does it differ from Obsidian? Out of curiosity.
Using Markdown as the storage format solved the problem because it is consistent and templates can easily be updated to support design updates. The problem is now finding a WYSIWYG editor that supports Markdown. I'm glad there is more going on this space, but StackOverflow helped me a lot with https://editor.stackoverflow.design/.
Ha! I've never read that, but having used Markdown quite a bit, they have entirely failed that goal. A Markdown document is parsable by a human, but it still looks like content surrounded by tag barf that failed to render.
People have mentioned tables here, and...yeah, they're messy, but I wonder how common of a use case that is for your average WYSIWYG user?
I tweaked my Markdown theme to make headings bolder, links linkier, and blocks blockier. Sublime also collapses link URLs.
This keeps the text very readable, while letting me edit text with powerful tools. There's a table of contents plugin, but Cmd + R is a much faster navigation tool.
For everybody else, Markdown doesn't save any time, and doing things like creating tables actually wastes time because of the "___" and "|" scaffolding required. Of course you could use a Markdown table generator online but that's just WYSIWIG by another name.
I think you might be under a mistaken assumption here, because I don't think that this is factual.
The only way I could see your misunderstanding is if you think the quantity of whitespace in markdown tables is important, which it isn't.
This is a working md table and it's not harder to make then the equivalent html version
|Header one|header two|
|---|---|
|Column value 1|column value one|
|value 2|value two|
Wherever what's preferable is another story though.
Personally I dislike writing plain html, and would always prefer another template language to generate it, but that's just preference.
Things like this can bridge the gap.
This instantly makes me think about spending 20 minutes trying to get a picture to stay where I put it and have text neatly formatted. Word peaked some time ago and I don’t even know what it is now.
The app? The online thing? The teams thing? They aren’t actually fully compatible and it’s awful.
I haven't used Word much for a while, but the first thing that came to mind here was "You mean like typing a comma and suddenly your picture moves 15 pages away?".
:-)
That said, this is pretty neat. I'm not wild about Monaco because it was crap on mobile the last time I looked (which has also admittedly been a while... at that time, anyway, CodeMirror was the only one I could find that didn't suck on mobile), but still, this appears to be a very worthy project for its use case.
While having absolutely no idea how to actually use Word.
I can't tell you you're wrong because it's your experience, but ... mine is the opposite.
I don't like having to think about the markup, just show me what it looks like (no, not the "18px Arial #000 bold" kind, the "this is a headline" kind).
There are a few rich text editors, but they're all not very markdown compatible. But markdown is the format you almost always need for sharing and storing.
If you say a WYSIWYG editor that can transparently import/export to markdown it sounds more attractive (at least to me).
Markdown especially fails with anything remotely complicated like tables or even something trivial like font size/color
Nearly the entire planet uses WYSIWYG and prefers it
WYSIWYG almost always generates nonsense in the underlying code, which can be very difficult to work with when it comes time to style that code. And since I'm a frontend guy, this is something I'm always having to debug.
> Please resize your browser window or visit Vrite from a desktop browser.
:( although I get it. In my experience Android and to a lesser degree iOS input is the hardest part of building these kinds of editors.
I don't care if it works well on mobile, just show render something so I can kind of play with it.
Plus, for Vrite Editor, the Monaco Editor used for code snippets doesn't officially support mobile (and it's a hit or miss in my experience) so it'll likely have to be disabled there.
I'm sure you had a lot of fun fighting Safari in general, and also the diverging handling between Chromium and Firefox (for example when pressing the Enter key). Even just changing certain CSS properties on the root editor element will cause the resulting markup on certain key inputs to be different.
I admire that you pulled it off, and hope that you have a big collection of cross-browser integration tests for catching all the regressions that will inevitably happen :) Good luck!
Do you accept "embed" requests? I tried embedding an Iframe but it did not work (instead displayed a code-editor view) and would happily join the list of embeds with SimplePDF
<iframe src="https://embed.simplePDF.eu/editor">
</iframe>That said, I do plan to add some more embeds to the core (e.g. Twitter) but others will likely be supported through custom content blocks and extensions.
That said, definitely report any feedback or feature request you have (if not as an issue then possibly as a discussion).
> That said, I do plan to add some more embeds to the core (e.g. Twitter) but others will likely be supported through custom content blocks and extensions.
> That said, definitely report any feedback or feature request you have (if not as an issue then possibly as a discussion).
I’ll open a discussion on the repo then! Thanks a lot for taking the time to answer!
Open source — MarkText https://github.com/marktext/marktext
Not open source — Typora https://typora.io/
Open source —
I’ve used all three, the first two are are WYSIWYG. All are collaborative. HackMD has a nice two window editor that renders MD as you type.
Curious how Vrite compares with these.
Essentially it’s a toolkit intended primarily for technical content (like programming blogs or docs), with multiple features in one:
- WYSIWYG editor focused on good UI/UX (including good support for code), and collaboration;
- Kanban dashboard (and other views in the future) for managing the content and its production process; Especially useful for larger teams;
- The “headless CMS” part for hosting and delivering content and related assets; This includes API and Extension system; (in the future planned additions are asset optimization and Git integration)
So, tl;dr; it’s a lot more than the mention tools and I’m still looking for a way to categorize it clearly.
I can see where you are coming from in terms of wanting to stay "true" to the intention of being able to read the plain text (although it always supported the html escape hatch from the beginning), but for me personally the value is that I can write in something WYSIWIG, and drop photos/screenshots/diagrams/sketches into my notes without having to switch back and forth (or have a preview-window by the side taking double the space) - with the absolutely crucial feature that I can do so without being beholden to a single app or nonportable file format.
I mainly use Obsidian for this now, but if I wanted to switch away the Obsidian-only features are small/unobtrusive enough that I wouldn't really miss them; I can edit things remotely on the terminal easily enough; and in the end the entire thing is just a git repository of markdown files.
I am stuck self-hosting Outline because it has the most intuitive navigation and wysiwyg for non-IT people.
I wonder if any better alternatives appeared since then.
There's already Kanban for better management of content production process and I'd say the editor is comparable to Outline. Other views and more editor features are on the way.
Still, as I'm updating it almost daily, self-hosting isn't easy right now. I plan to have a stable version sometime in Q3 of this year, with self-hosting and more features so keep an eye out on that if you're interested.
A few nitpicks:
- It would be nice if exports included the metadata as comments
- When I move my cursor over a code block, any key I press that isn't Enter will erase it, when really I just want to enter the code block and start writing. If I wanted to delete it, I could press del/backspace.
- Makes sense. These are the kind of edge cases to figure out with special blocks like code. In theory, the selection you have before enter is a block selection, which would usually remove the block when anything is inserted (enter is specifically handled to move focus to the code editor). Will consider making other characters do the same.
Metadata as in author, tags, and such, which your app allows to add outside of the actual contents.
I think it's nice to have, and even nicer if I could export/import them. Maybe support something like [this](http://fletcher.github.io/MultiMarkdown-5/metadata.html) or [this](https://peterbabic.dev/blog/yaml-metadata-in-markdown/)
MDX doesn't make a lot of sense though as, with the supported features, it's basically the same as pure MD. That said, custom content blocks are in the pipeline and once that's added, MDX, MarkDoc and other formats will work really nicely with Vrite.
It's an amazing rich-text editing toolkit that provides all the bits and pieces needed to write any kind of rich-text editor. Tiptap is a wrapper over ProseMirror for minimizing the vast API surface and providing simpler configurations.
The project is using TipTap and that is mentioned.
At the end of the day, different users have different preferences and different use cases have different needs. This should not be news to anyone who works in software.
So I'd venture that this particular editor is definitely an atypical mix of possibilities, but there probably is an audience for it. And while I'm not currently in that audience, I am interested in where this goes over time as OP gets feedback and evolves the idea.
Markdown keyboard shortcuts in WYSIWYG editor works well together.
I wish one of this is available as a custom element with attributes and callbacks, and I can just use it.
Vrite's goal is to be more like a self-hostable writing platform/tool, so making the editor into custom element isn't really on the roadmap. If anything, it would be embeddable but not customizable, which limits possible use-cases.
Not mentioned (but inferred from TipTap + HocusPocus, the guys that originally built both are awesome BTW) this is using the Yjs CRDT (conflict free replicated datatypes) library and its bindings to ProseMirror to provide the underlying realtime collaborative system. Again absolute joy to work with these tools.
This is one of my favourite stacks.
If it’s Markdown however, in my personal opinion, it should show the Markdown syntax, too, and not hide it. E.g. the headlines should have the editable ### next to them. Too many editors that "support" Markdown get this wrong. Can’t find the link now, but John Gruber agrees.
I hear writing these editors over a content-editable (or whatever) field is super difficult. So.. are you aware of any good sources of information to mitigate the pain?
Note that this would, i believe, be an entirely ground up write. As i'll probably experiment writing it in Rust. Rather than building on top of existing solutions like Prosemirror/etc.
I'm building a similar library, but with a block-based (Notion style) approach, also on top of Prosemirror (see https://www.blocknotejs.org) - great to see more projects in this problem space! Welcome any feedback!