[HN Gopher] Show HN: An open-source, collaborative, WYSIWYG Mark...
___________________________________________________________________
Show HN: An open-source, collaborative, WYSIWYG Markdown editor
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/
Author : arek_nawo
Score : 351 points
Date : 2023-06-23 12:40 UTC (10 hours ago)
(HTM) web link (editor.vrite.io)
(TXT) w3m dump (editor.vrite.io)
| sergiotapia wrote:
| 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!
| WolfOliver wrote:
| funny how many layers you can put on top of prosemirror and
| claiming to have implemented real time collaboration.
| samwillis wrote:
| 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.
| dbrgn wrote:
| 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!
| Turing_Machine wrote:
| 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 wrote:
| TIL abuot plaintext-only. Thank you, that's very useful.
| Turing_Machine wrote:
| 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.
| twsted wrote:
| It uses Prosemirror, which is pretty well tested.
| 0xbadcafebee wrote:
| 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
| johnwheeler wrote:
| 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.
| toastal wrote:
| 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.
| misnome wrote:
| > 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.
| [deleted]
| nip wrote:
| 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>
| arek_nawo wrote:
| 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).
| amendegree wrote:
| 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.
| arek_nawo wrote:
| 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/sd
| k/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.
| nip wrote:
| 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!
| masukomi wrote:
| 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.
| tommoor wrote:
| For those interested TipTap is doing the heavy lifting here -
| https://tiptap.dev/examples/default
| arek_nawo wrote:
| 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.
| ch_sm wrote:
| 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.
| villgax wrote:
| I want MarkDown & CSVs to just eat Microsoft's lunch at some
| point
| thekingshorses wrote:
| 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.
| arek_nawo wrote:
| 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.
| Brendinooo wrote:
| 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/
| TechBro8615 wrote:
| Agreed. The first thing I do in any markdown editor (eg
| Obsidian) is disable the WYSIWYG.
| egonschiele wrote:
| That's logical, but there are plenty of Markdown WYSIWYG
| editors out there, so this is not unusual. Quilljs is a famous
| example.
| zerkten wrote:
| 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/.
| pseudocomposer wrote:
| 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.
| dadoomer wrote:
| You might like Joplin's approach. It's exactly what you
| described: you can toggle WYIWYG and plain text.
| [deleted]
| vorpalhex wrote:
| 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.
| StackOverlord wrote:
| Same problem with the comment box in Reddit.
| hunter2_ wrote:
| 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.
| chatmasta wrote:
| > the worst markdown experiences in existence
|
| This title belongs to ClickUp.
| pavo-etc wrote:
| 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
| pxc wrote:
| 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.
| wouldbecouldbe wrote:
| Only some developers like markdown, the rest of the world just
| expect things to work like Word.
|
| Things like this can bridge the gap.
| reportgunner wrote:
| > _... rest of the world just expect things to work like
| Word_
|
| While having absolutely no idea how to actually use Word.
| Turing_Machine wrote:
| > 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.
| lostlogin wrote:
| > 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.
| solarkraft wrote:
| > 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.
| indymike wrote:
| > 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 wrote:
| > 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 wrote:
| 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).
| throwawaaarrgh wrote:
| > WYSIWYG is awful to work with.
|
| Nearly the entire planet uses WYSIWYG and prefers it
| Brendinooo wrote:
| 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.
| 0xbadcafebee wrote:
| 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
| lpcvoid wrote:
| 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.
| herpdyderp wrote:
| use case for me is: please the product managers with "must has
| WYSIWYG" but it won't drive me insane to use it
| rpodraza wrote:
| 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.)
| meesles wrote:
| 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/
| luuuzeta wrote:
| 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
| Reitet00 wrote:
| StackEdit looks really nice! Does it support concurrent edits
| from several users? (as several etherpad-like services do)
| replwoacause wrote:
| 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.
| eviks wrote:
| 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
| cjbprime wrote:
| 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.
| prmoustache wrote:
| 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.
| avgcorrection wrote:
| These Wysiwyg MD editors are either very popular to make or use
| though. I don't know why.
| sbjs wrote:
| 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.
| arek_nawo wrote:
| 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 wrote:
| > primary format is JSON
|
| the primary format is prosemirror document format, rather
| than JSON (even tho it is in JSON).
| cientifico wrote:
| 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).
| arek_nawo wrote:
| 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.
| Brendinooo wrote:
| 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.
| thaumaturgy wrote:
| 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.
| 111111IIIIIII wrote:
| It's the only good thing about Obsidian that doesn't require
| dependency on some random git repo ("extension").
| arek_nawo wrote:
| 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.
| philomath_mn wrote:
| 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
| arek_nawo wrote:
| 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.
| tedmiston wrote:
| > 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/Editin
| g+and+...
|
| [1]: https://help.obsidian.md/Live+preview+update
| wmeredith wrote:
| "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 wrote:
| 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 wrote:
| > 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.
| Brendinooo wrote:
| 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.
| hunter2_ wrote:
| > 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.
| nicbou wrote:
| 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 wrote:
| 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 wrote:
| > _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.
| Turing_Machine wrote:
| > 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>
| 411111111111111 wrote:
| Cleaner? Yes. easier? No.
|
| Also note that you haven't actually done the same as my
| example.
|
| You're missing <thead> and <tbody>
| hgsgm wrote:
| 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.
| condwanaland wrote:
| I think this is background and person dependent. I find
| it easier to remember the markdown syntax than the html
| tags
| throwawaaarrgh wrote:
| 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.
| 411111111111111 wrote:
| 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.
| solarkraft wrote:
| I've been wanting this. Like an Etherpad that feels better and
| works on Markdown. I'll definitely have a look!
| codingdave wrote:
| 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 wrote:
| > WYSIWYG is or is not compatible with markdow
|
| Markdown keyboard shortcuts in WYSIWYG editor works well
| together.
| revskill wrote:
| I want MDX support instead.
| arek_nawo wrote:
| 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.
| Wurlitzer wrote:
| Try motif.land
| CGamesPlay wrote:
| Looks great on Chrome. It completely hangs Safari, though.
| Version 16.3 (17614.4.6.11.6, 17614)
| arek_nawo wrote:
| For me Safari seems to be working fine, except some broken
| styling. Will try to explore more and fix what I can.
| erezsh wrote:
| 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.
| arek_nawo wrote:
| - 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.
| erezsh wrote:
| > 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/)
| bighoki2885000 wrote:
| [dead]
| cmer wrote:
| It looks beautiful and is very user friendly. Congrats!
| unshavedyak wrote:
| 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.
| hhh wrote:
| Haven't used it yet, any support for Mermaid diagrams?
| arek_nawo wrote:
| 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.
| lewisjoe wrote:
| 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
| arek_nawo wrote:
| 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.
| jitl wrote:
| > 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.
| arek_nawo wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| tmzt wrote:
| 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?
| arek_nawo wrote:
| 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
| paholg wrote:
| 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.
| Palmik wrote:
| 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.
| ddejohn wrote:
| 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.
| DistractionRect wrote:
| 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
| arek_nawo wrote:
| I agree. Will consider adding that.
| MitPitt wrote:
| 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.
| cmer wrote:
| 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!
| arek_nawo wrote:
| 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.
| YousefED wrote:
| 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!
| HeckFeck wrote:
| Nice. I have been on the lookout for a collaboration platform to
| keep docs + help plan dev, will give Vrite a look as well.
| arek_nawo wrote:
| Nice! If you have any feedback or feature requests afterwards
| definitely let me know on GitHub.
| [deleted]
___________________________________________________________________
(page generated 2023-06-23 23:00 UTC)