Show HN: An open-source, collaborative, WYSIWYG Markdown editor | Hacker News Reader

Show HN: An open-source, collaborative, WYSIWYG Markdown editor

editor.vrite.io

460 pointsarek_nawo128 comments

Inspired by the design and UI/UX of apps like Notion, and utility of open-source apps like StackEdit, I decided to create a minimalistic, local-only WYSIWYG Markdown editor.

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/

Open articleView on HN

Congrats on building and shipping something!

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.

[0]: https://daringfireball.net/projects/markdown/

These Wysiwyg MD editors are either very popular to make or use though. I don’t know why.

Because I want to store my document's data in a standard text-only human-readable human-editable format, but be able to do the majority of my writing more easily and with wysiwyg which is an free, automatic and space-conservative preview.

I think there is use for good WYSIWYG-Markdown integration. Can't really speak for others but, when writing longer forms of content (technical blog posts, docs, etc.) Markdown becomes a bit more difficult for me to navigate. I always fallback to a visual editor (even if it's just StackEdit) and then try to somehow convert that content back to Markdown destination (which can sometimes be hard).

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.

> primary format is JSON

the primary format is prosemirror document format, rather than JSON (even tho it is in JSON).

I've wanted this when the primary requirement was a WYSIWYG editing experience acceptable to business users. Neither HTML nor Markdown were acceptable and while it's perhaps more accepted today, there are still huge audiences which won't touch anything looking like code. The options available generated terrible HTML on the backend that wouldn't roundtrip or resulted in problems when the overall site design was changed. I'm completely onboard with your feelings as a technical person.

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/.

Only some developers like markdown, the rest of the world just expect things to work like Word.

Things like this can bridge the gap.

> work like Word

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.

> work like Word.

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.

> ... rest of the world just expect things to work like Word

While having absolutely no idea how to actually use Word.

> From my experience, the benefit of Markdown is that it eliminates the need for WYSIWYG, because WYSIWYG is awful to work with.

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.

StackEdit[0] pretty much perfected what I needed out of a markdown editor - I just need somewhere to write my tickets/docs that wasn't Github so that I could format it properly while writing. I still use it from time to time

[0]: https://stackedit.io/

Same! I wished there was a native app with the same layout as StackEdit. Btw both the website [0] and the library [1] are open source.

[0]: https://github.com/benweet/stackedit

[1]: https://github.com/benweet/stackedit.js

StackEdit looks really nice! Does it support concurrent edits from several users? (as several etherpad-like services do)

No I don't believe it supports collaboration, though I could be wrong. This is really a pretty notepad with great Markdown integration, nothing much more (which is why it's still good!)

I think there’s a place for WYSIWYG Markdown, and actually, Markdown’s simplicity actually seems like a good opportunity to simplify WYSIWYG and make it mobile-friendly (this tool does not seem to be, so I’ve yet to try it…). In fact, most of us use WYSIWYG Markdown daily in apps like Slack without even thinking about it. That said, I think any general, open solution needs to offer “manual/WYSIWYG” toggles the same way we see “manual/preview” toggles on DockerHub/GitHub, ideally also maintaining cursor position. Markdown’s benefit is definitely its simplicity, but that doesn’t necessarily mean it obviates the utility of WYSIWYG editing.

I support a markdown WYSIWYG flow and it is a constant source of pain for our users. At this point I just tell our users to write markdown plain - and after a 10 minute tutorial, everyone is comfortable doing that.

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.

Same problem with the comment box in Reddit.

I always get a good chuckle when I see comments that get unexpectedly processed as a new ordered list. Like if replying to a 3-item comment by starting with "4. " which renders as "1. " -- for the sake of users who don't know these nuances of markdown, I wish it strayed a bit further to accommodate them.

Bold, italics, links, etc. -- sure, false positives there are rare enough and the means of correcting mishaps are intuitive enough. The OL issue though... so many go uncorrected.

> the worst markdown experiences in existence

This title belongs to ClickUp.

You might like Joplin's approach. It's exactly what you described: you can toggle WYIWYG and plain text.

I love Obsidian's WYSIWYG implementation. It is WYSIWYG until you the cursor is touching any formatted element, at which point it reveals the Markdown that makes it appear that way e.g. h1 titles appear large, but clicking on them reveals the # at the start of the line

Hybrids like this are a nice advance over WYSIWYG imo. There's similar, partial live preview functionality in LyX and Emacs' Org mode as well, and I love those.

Sounds great. I couldn't (quickly) find any screenshots, so I might just download and try.

FWIW, WordPerfect's "reveal codes" feature remains my ideal solution.

Long before the advent of desktop publishing and GUIs and markup languages. Split screen horizontally, vs vertically side-by-side, with WordPerfect's own nomenclature for formatting attributes. Edit in either screen. Live cursor shown in both screens. Live updates back and forth.

Heaven.

I haven't used WordPerfect for decades, so my bias might just be nostalgia.

I get what you’re saying, but if most people thought this way products like Obsidian would never be as successful as they are. If you look at what gets added to md documents to support all the different plugins in the community, it’s pretty crazy and a far cry from textbook markdown language.

There is a way to publish a doc without looking like it's been marked up with tags - it's WYSIWYG, and it's by design impossible to achieve by... placing tags right there for everyone to see (though with some syntax highlighting you can make it less visible, bringing it closer to WYSIWYG again!

Markdown especially fails with anything remotely complicated like tables or even something trivial like font size/color

Markdown makes sense for devs who are in a code editor all day and might need to write some documentation and publish that to HTML, without needing opening/closing HTML tags for everything.

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.

> actually wastes time because of the "___" and "|" scaffolding required.

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|

Etc

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.

> it's not harder to make then the equivalent html version

Much easier, I'd say.

    <table>
      <tr>
        <th>Header one</th>
        <th>header two</th>
      </tr>
      <tr>
        <td>Column value 1</td>
        <td>column value one</td>
      </tr>
      <tr>
        <td>value two</td>
        <td>value two</td>
      </tr>
    </table>

Cleaner? Yes. easier? No.

Also note that you haven't actually done the same as my example.

You're missing <thead> and <tbody>

I don't know.

It's easier to remember the html tags and to see if they are correct.

In markdown I have to remember the weird punctuation and get the | counts exactly correct.

I think this is background and person dependent. I find it easier to remember the markdown syntax than the html tags

HTML is internally consistent. The atom of HTML is the tag. It makes it easier to remember and to learn new ones. Markdown is composed of arbitary punctuation which is harder to remember.

For making something bold, there's low friction in wrapping it in asterisks compared to the HTML version. It's fast, easy and works.

For making a link, the friction is higher because you have to remember the link/text order, and the link/text punctuation. There's a what, one in four chance of getting it right if you haven't memorised it? It always trips me up and I have to go and look it up.

Whereas a link in HTML is pretty much the same format as everything else in HTML.

I think Markdown excels for short or limited things that consist of headings, lists and inline formatting, like blog-posts and comments and ReadMes, but I find it doesn't scale well.

It is much, much harder to maintain a markdown table. You can keep html table cells on separate lines, and have newlines in them. Can't with markdown tables.

Now that I can agree on. Thankfully, md accepts inline html, so you can always just fall back to it for tables if you expect modifications in the future.

Though for the record, you should bee able to escape newlines with a backslash. That admittedly makes the md table into a total disaster, so not suggesting it as an actual option.

"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."

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.

Depends on what you're doing. If your content is just headings, bold/italic, and links, I think it's eminently readable. Code snippets are obviously niche but are a solved problem.

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 think it's eminently readable

This. And proper line breaks help a lot, too. There's a reason single line breaks are ignored.

> People have mentioned tables here, and...yeah, they're messy, ...

IIRC, the "original" markdown does not include tables. They've been added by GitHub (I think), because it made sense for them, and many parsers started to adopt. I agree they are not easily readable in "source mode". It helps to properly align stuff, though, but it's a PITA.

> proper line breaks help a lot, too. There's a reason single line breaks are ignored.

Documents that don't hard-wrap (they could opt to hard-wrap without consequence, to your point), when viewed somewhere that doesn't make it trivial to engage soft-wrap, are much more of an issue than the tag barf mentioned earlier, IMHO.

Yeah. A lot of stuff was added later. The original spec was pretty loose, which is why CommonMark became a thing.

See

https://blog.codinghorror.com/standard-markdown-is-now-commo...

and linked previous blog posts if you (or anyone else reading this) are interested in the history.

I edit a markdown-based website for a living. I'd say that it works really well, but a proper text editor theme makes a big difference.

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.

That's logical, but there are plenty of Markdown WYSIWYG editors out there, so this is not unusual. Quilljs is a famous example.

> WYSIWYG is awful to work with.

Nearly the entire planet uses WYSIWYG and prefers it

I think people wouldn't prefer it if they actually knew something different. Non-tech people don't even know there's a world outside MS Office suite of tools, which shove you to WYSIWYG by design. From experience when showing somebody LaTeX, it's an eye opener people didn't know existed.

It's a "the worst choice, except for every other choice" sort of thing.

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.

The problem there is having to manually maintain code. Once we start abandoning useful technology to maintain the status quo, we don't get progress

use case for me is: please the product managers with "must has WYSIWYG" but it won't drive me insane to use it

No, it's actually great. The non-tech people can use your WYSIWYG editor, while you save your document as Markdown (which can be parsed, validated, etc.)

I think is a marketing issue.

If you say a WYSIWYG editor that can transparently import/export to markdown it sounds more attractive (at least to me).

That's so true! I have a really hard time categorising what Vrite Editor, let alone the entire Vrite is. I can't really describe it in detail as it'd be too long and, to keep it short, some messaging is lost in the process. "WYSIWYG Markdown editor", "headless CMS for technical content" are just some of my latest tries. I think I'm getting better at it, but it's not easy.

Yeah, I see where you're going here. I guess I'd be skeptical until I see it in action for awhile and am confident that it's not generating nonsense under the hood, which is a top complaint about WYSIWYG editors.

Agreed. The first thing I do in any markdown editor (eg Obsidian) is disable the WYSIWYG.

> From my experience, the benefit of Markdown is that it eliminates the need for WYSIWYG, because WYSIWYG is awful to work with.

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).

> For most users, the opposite is true. They understand WYSIWYG well and that is how most things work.

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.

Teams’ editors aren’t even the same between chats (e.g. DMs and discussion on a meeting) and channels in a “Team”. Which seems so odd and unnecessary it makes me curious how they ended up needing such a confusing and seemingly redundant editor.

As far as slack goes I don’t usually need to futz with the format buttons. Back ticks start and close the monospaced strings and code blocks, underscore and asterisk start and stop emphasis and bold, > starts quotes and newline +backspace drops the formatting (same with ordered and unordered lists).

This means that either you don't get to see what your document is going to look like while you write it, or you have two copies of the document open at the same time (one showing the preview) and move your eyes between them, and neither feels good.

You only need to check the preview once before saving, and eventually correct an issue if some appear, which is quite rare if you are using a decent text editor.

I think Obsidian's "live preview" editing mode is a great counterpoint to this. I'm pretty sure it's the first WYSIWYG editor I've ever used, in 30-odd years of computing, that hasn't pissed me off.

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.

It's the only good thing about Obsidian that doesn't require dependency on some random git repo ("extension").

I'm a bit confused about that. I have heard of but haven't really tried Obsidian. How does what you're describing differs from so-called "Markdown shortcuts" (implemented in my editor and other popular ones like Notion)? You can type in most inline markdown and it's automatically converted to WYSIWYG-styled text. All these shortcuts are described here: https://docs.vrite.io/content-editor

How does it differ from Obsidian? Out of curiosity.

I think the difference is that Obsidian is 100% backed by a folder of plaintext markdown files which can be managed/viewed/edited/versioned however you like.

It's not revolutionary but I like it

In this case, yeah. That's not my goal. However, if a "raw" preview in MD (or other format) is available and editable), plus maybe a Git integration then I think this could be on a compareable level.

Either way, seems like I'll have to check out Obsidian.

> How does it differ from Obsidian? Out of curiosity.

I am not OP, but I am a heavy Obsidian user. Obsidian has 2 different editing modes [0]: "Live Preview" and "Source mode". Your implementation and Obsidian's Live Preview editing mode implementation are very similar at-a-glance; yours is a bit more interactive / "GUI-forward".

Here's an example of what Live Preview mode looks like [1].

I'm surprised how many people here like Live Preview editing mode in Obsidian though — it drives me insane constantly shifting the bits under / around my cursor... it's very distracting. I mostly use their Source mode editing mode for that reason.

That said, I did not see an equivalent of Reading view mode from Obsidian in Vrite in a few minutes of playing with it. It would be nice to see that added to prevent accidental edits when browsing a doc you don't edit to change (similar to Vim's modes).

[0]: https://help.obsidian.md/Editing+and+formatting/Editing+and+...

[1]: https://help.obsidian.md/Live+preview+update

I haven't used the OP's application, but I've used a variety of other WYSIWYG markdown editors. It's true that WYSIWYG is kind of pointless for READMEs or what have you, but for writing prose it's very useful to continuously understand what your output will actually look like. (And writing prose in markdown is great because you have a plain text, easily manipulated & cross-compiled storage format that you can read the plain text of easily if you have to)

Ah, the joys of contenteditable HTML elements... Such an under-specified and utterly horrible part of the web specs.

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!

It uses Prosemirror, which is pretty well tested.

Safari is actually much better than some when it comes to contenteditable. For one, Safari (along with Chrome, Edge, Android Webview, etc.) supports the plaintext-only attribute for contenteditable, which Firefox does not. That means you don't have to worry about getting some ugly blob of broken HTML pasted into your document.

TIL abuot plaintext-only. Thank you, that's very useful.

You're welcome. There are some minor inconsistencies (e.g., some browsers add a normal newline when one is pasted in, while others insert a <BR>, which seems like broken behavior to me), but dealing with those inconsistencies is much easier than dealing with random chunks of HTML being pasted in.

> We're sorry but Vrite currently doesn't support small viewports.

> 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.

Sorry for that. Forgot to include it in the drawbacks. I tried the editor as-is on iOS and it wasn't a good experience. All the menus (for blocks and inline) just mess with the OS's built-in menus and aren't good for touch. I'm working on a dedicated layout for mobile, though it'll likely only go so far. For mobile it's really difficult to create a compelling WYSIWYG editor on the Web.

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.

CodeMirror (from the same author as ProseMirror the library under TipTap) works great on mobile, you should consider it over Monaco for that feature.

I know. I've explored pretty much all the options when working on this and Monaco and CM are definitely top choices. That said, for languages I'm working with (web) and for the future potential of e.g. connecting to remote language server, Monaco is a better choice. Will see if switching between CM on mobile and Monaco on desktop will be doable.

How are you using TipTap with Monaco instead of ProseMirror, do you have the bindings/plugins working the same way?

How does this compare to something like Milkdown using markdown as a native format?

I see you solved some of the hard problems (tables, etc.) with Yjs and CRDT in general.

Are the backend components also open source?

TipTap is built on ProseMirror. Basic elements of the editor are made in TipTap, while for more advanced use (tables, menus, integrating code editor) I had to tap into ProseMirror.

I'm not really familiar with Milkdown so I can't say.

The entirety of Vrite is open-source under AGPL-3.0 license (with parts under MIT): https://github.com/vriteio/vrite

I don't think there's really any good solution for phones... text editing is probably always going to suck there. Maybe just try your best to get it working on tablets? CodeMirror (ProseMirror's sister project) works okay on iPads, in my experience.

It even shows that message if I request the desktop site.

I don't care if it works well on mobile, just show render something so I can kind of play with it.

Nice, building with TipTap/ProseMirror is such a joy.

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.

It would be great if there was a mode that allows you to see the full markdown syntax (while still applying formatting implied by the markdown). I personally find it strange to remove / add invisible characters.

I agree. Will consider adding that.

Indeed, perhaps a middle ground would be something like concealment as described/demoed in Gilles Castel's workflow [0]. This way you can see the formatted content without the tags/markdown but get access to the unformatted markdown to edit/correct.

[0] https://news.ycombinator.com/item?id=19448678

I specifically really enjoy using HackMD because you get a naked markdown editor on the left, and the rendered version on the right. I haven't used it for a while, so I'm not sure if these features have been added, but at the time I was heavily using HackMD, there was no linting/auto-formatting available in the linter, unfortunately.

A little dissapointed to see ProseMirror not mentioned.

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.

https://prosemirror.net

Yeah, my bad. Already mentioned it in one of the other comments and it's also noted in the docs. I had to tap a lot into PM to implement more advanced features so it definitely should have been included.

Thanks for sharing! Looks awesome!

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.

Skimmed the comments but didn’t see mention of :

Open source — MarkText https://github.com/marktext/marktext

Not open source — Typora https://typora.io/

Open source —

https://hackmd.io/

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.

Vrite as a whole can be referred to as a headless CMS, though it’s different compared to other tools in this category.

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.

Thanks for detailing this. Does it support math(Jax)/latex/katex ?

Not yet. That’s in the pipeline.

I've been wanting this. Like an Etherpad that feels better and works on Markdown. I'll definitely have a look!

I've been working on content management systems for pretty much my entire career since the 90s, so I've seen my fair shares of editors. I understand the comments that markdown is incredible, as well as those that that markdown is horrid, that WYSIWYG is or is not compatible with markdown, etc.

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.

> WYSIWYG is or is not compatible with markdow

Markdown keyboard shortcuts in WYSIWYG editor works well together.

Tangent, but does anyone have any resources they link for writing something like this? I want to write (experiment, more likely) a thin layer over an editor for some basic highlighting of markdown stuff and a couple autocomplete-like features from the DB (ie link to existing records).

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 understand the motivation behind creating a local-only WYSIWYG Markdown editor, but I can't help but feel conflicted about it. Markdown was designed to prioritize simplicity and readability, allowing documents to be published as plain text without any markup clutter. Introducing a WYSIWYG editor seems to contradict the essence of Markdown itself. While I appreciate the effort and consideration for different use cases, the combination of Markdown syntax with a WYSIWYG editor strikes me as odd. However, everyone has their own preferences, so perhaps there is a balance to be found between simplicity and flexibility. Keep exploring and iterating, and who knows, you might discover the sweet spot that works for you and your users.

> I personally find the combination of Markdown syntax with a WYSIWYG editor to be a bit odd.

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.

A lot of folks only care about the visual output of Markdown with little regard for the HTML semantics of the output or the plaintext legibility. This is why tools like these are created. Its also the audience that made READMEs no longer plaintext readable—embedded with all sorts of HTML, graphics, badges, manual table of contents, center tags, etc. Meanwhile the focus on the visual will help increase the rampant abuse of > to put a box around things instead of a semantically denoting blockquotes for quoting sources.

Is anyone else using an internal wiki engine like Outline or Wiki.js, for their company or community?

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.

I'd like to encourage you to check out Vrite as a whole. I'm actively working on this to make it better for documentation and knowledge base management. Good UI and UX are among my top priorities.

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.

I went down that rabbit hole as well, and I also settled on Outline for our business. We haven't widely deployed it yet, but it's been working great during our limited testing. It is sorely missing robust embeds, however!

you say that the editor is a standalone app, but i'm not seeing a link to that anywhere, only to vrite itself. also no mention of how to get the editor separately (or that that's even a thing) on the vrite readme.

funny how many layers you can put on top of prosemirror and claiming to have implemented real time collaboration.

Neat! I write every blog post / documentation in Markdown, so I'll definitely be following your progress!

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>

Yeah, generic embeds aren't allowed - only CodePen, CodeSandbox, and YouTube. In Vrite, all the embeds are actually processed separately when auto-publishing to different platforms (e.g. Medium, Dev.to, Hashnode), that's why I don't want to allow generic iframes.

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).

interesting, I checked out the md, and it looks like you don't capture your embeds there, so the youtube embed is just gone from the markdown... I would expect it to at least show up as a link.

The main output is JSON ProseMirror format. Other formats are processed from this JSON using Transformers and Vrite SDK: https://github.com/vriteio/vrite/tree/main/packages/sdk/java...

In the GFM transformer I try to follow GitHub Flavored Markdown spec, which technically doesn't support embeds. Since I didn't find any "common" syntax to use for the embeds, I just left them out. They're still there in JSON and HTML outputs.

That's one of the drawbacks of MD. That said, I plan to add an option like Markdoc, which has clearly defined spec for implementing custom blocks like embeds.

That said, for now, if you sign up for the full Vrite CMS, you can create a custom Transformer and process the output so that embeds are included in your desired format. That's what I'm doing for auto-publishing extensions for platforms like Dev.to and Hashnode. I don't know what your use-case is, but I thought it's worth noting.

Ok, makes sense!

> 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!

It looks beautiful and is very user friendly. Congrats!

Congrats! Having wrestled a lot with contenteditable I realize this is no easy feat.

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!

Congrats on the launch! Unfortunate name clashing with Vite. I'm afraid Google will autocorrect to "Did you mean Vite?" a lot. I wouldn't name something "Rhails" for the same reason. If you change the name maybe you get much better SEO so your cool project has better reach!

Looks nice! I might give it a try when I get the chance.

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.

- I don't quite understand what "metadata" you're referring to?

- 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.

> what "metadata" you're referring to

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/)

For those interested TipTap is doing the heavy lifting here – https://tiptap.dev/examples/default

Forgot to mention underlying ProseMirror (https://prosemirror.net/) as well. It's doing "even-heavier" lifting and is necessary for implementing more complex mechanisms like the code editor integration or various side-menus.

Yesterday, someone posted a really nice editor too.

I wish one of this is available as a custom element with attributes and callbacks, and I can just use it.

I can see how this would be useful, though there are some options already available that can do that, e.g. Editor.js or BlockNote.js.

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.

Nice. I have been on the lookout for a collaboration platform to keep docs + help plan dev, will give Vrite a look as well.

Nice! If you have any feedback or feature requests afterwards definitely let me know on GitHub.

I like it! I would prefer an icon bar along the top or side, rather than have to select text for the icons to show up

Looks great on Chrome. It completely hangs Safari, though. Version 16.3 (17614.4.6.11.6, 17614)

For me Safari seems to be working fine, except some broken styling. Will try to explore more and fix what I can.

Wondering why it refuses show on an iPhone pro max? The display resolution is 2796 x 1290

I want MarkDown & CSVs to just eat Microsoft's lunch at some point

Haven’t used it yet, any support for Mermaid diagrams?

Not yet, but if you like what you see and would like to see the diagrams added, please open an issue or discussion on GitHub. This will help manage things better.

I want MDX support instead.

Try motif.land

If you decide to sign up for Vrite, it provides a JSON output accessible through the API. You can then process it to any format you want using JS SDK and Transformers.

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.

Reply on news.ycombinator.com