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

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

* * *

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

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

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

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.

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

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

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

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.

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

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.

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.

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 professors 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 actually proficient, especially in a professional context. And 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.

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

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

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)