Get the top HN stories in your inbox every day.
Brendinooo
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.
pseudocomposer
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.
pavo-etc
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
specialist
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.
pxc
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.
vorpalhex
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.
chatmasta
> the worst markdown experiences in existence
This title belongs to ClickUp.
StackOverlord
Same problem with the comment box in Reddit.
dadoomer
You might like Joplin's approach. It's exactly what you described: you can toggle WYIWYG and plain text.
undefined
indymike
> 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).
pxc
> 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.
brazzledazzle
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).
arek_nawo
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.
chii
> primary format is JSON
the primary format is prosemirror document format, rather than JSON (even tho it is in JSON).
thaumaturgy
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.
arek_nawo
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.
tedmiston
> 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+...
philomath_mn
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
111111IIIIIII
It's the only good thing about Obsidian that doesn't require dependency on some random git repo ("extension").
zerkten
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/.
BowBun
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
luuuzeta
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.
Reitet00
StackEdit looks really nice! Does it support concurrent edits from several users? (as several etherpad-like services do)
BowBun
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!)
wmeredith
"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.
Brendinooo
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?
psytrx
> 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.
nicbou
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.
rchaud
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.
411111111111111
> 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|
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.
throwawaaarrgh
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.
Turing_Machine
> 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>dbrgn
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!
twsted
It uses Prosemirror, which is pretty well tested.
Turing_Machine
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.
dbrgn
TIL abuot plaintext-only. Thank you, that's very useful.
Turing_Machine
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.
jitl
> 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.
paholg
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.
arek_nawo
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.
Turing_Machine
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.
jitl
CodeMirror (from the same author as ProseMirror the library under TipTap) works great on mobile, you should consider it over Monaco for that feature.
arek_nawo
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.
samwillis
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.
Palmik
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.
DistractionRect
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.
ddejohn
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.
arek_nawo
I agree. Will consider adding that.
lewisjoe
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.
arek_nawo
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.
ch_sm
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.
d4rkp4ttern
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 —
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.
arek_nawo
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.
d4rkp4ttern
Thanks for detailing this. Does it support math(Jax)/latex/katex ?
arek_nawo
Not yet. That’s in the pipeline.
solarkraft
I've been wanting this. Like an Etherpad that feels better and works on Markdown. I'll definitely have a look!
codingdave
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.
mlajtos
> WYSIWYG is or is not compatible with markdow
Markdown keyboard shortcuts in WYSIWYG editor works well together.
unshavedyak
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.
johnwheeler
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.
misnome
> 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.
undefined
toastal
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.
Get the top HN stories in your inbox every day.
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/