Hacker News new | comments | show | ask | jobs | submit login
Show HN: Slate-md-editor – A markdown editor that allows live editing (github.com)
123 points by chilijung 8 months ago | hide | past | web | favorite | 54 comments

IMO, the markdown editors that format the text you're editing, but still retain the markdown, are the very best. They're a good compromise between readability and functionality. Editors like this (and typora) that obscure the markdown tend to make it more awkward to change a heading level, for example.

I used to agree with this, but since I started using Dropbox Paper as my primary editor, I've changed my mind. I don't need to see the markup if the editor / formatting works consistently.

The different header sizes are immediately obvious without trying to find how many #'s there are. Monospace words and sections are immediately apparent without trying to figure out if i used backticks or apostrophes. And I don't want to "Preview", even if it's a live Preview. I want to see my fully formatted document as I type it without switching context.

On that note, one thing I wish _all_ markdown editors would pick up, and have only seen on StackOverflow, is the "Reference Style" links, where you can denote a link using something like [1], and then list the url below the text. I have never once, ever, needed to know and immediately see a full url while reading or editing text. Inline urls actively make editing and reviewing more difficult.

This is hidden by Dropbox Paper with an actual link as expected, but their export still has inline urls, which is standard, of course, but I don't agree with the standard.

> ... But their export still has inline urls, which is standard, of course, but I don't agree with the standard.

Just to clarify, inline urls are one of the two standard [Markdown link styles](https://daringfireball.net/projects/markdown/syntax#link).

The other is [reference-style][ref].

[ref]: https://daringfireball.net/projects/markdown/syntax#link

Thank you, I hadn't realized that was actually part of the spec. I also hadn't realized how long it had been since I actually read that document.

I think most folks who are comfortable with markdown would agree with this (including me). When I needed a markdown editor for my current project (https://www.contabulo.com), I just forked SimpleMDE (https://github.com/Ionaru/simplemde-markdown-editor), which is my favorite so far, and started hacking at it to add application-specific functionality (amusingly, bringing in a markdown editor about doubled the size of my application javascript over just using a plain 'ol html textbox -- but nobody likes a plain textbox).

I'm personally dubious on live preview as well, depending on the use case. I usually don't find it very useful - unless saving/publishing is some sort of final, irreversible action (submitting resumes to jobs, etc.) :)

OTOH, novice users may like the markdown being obscured, so maybe it's all just a matter of taste.

> novice users

Non-programmers, really. Most people who write in Paper see the markdown as a shortcut, not the underlying truth. This sort of interface for Reddit comments would lower the barrier to entry fairly substantially.

Leaving `#` characters at the start of headings would annoy people more than the ¶ marks in Word. "Why is there this gunk in my text? How do I get rid of it?"

I typed up a large response rebutting this, until I realized that still retain the markdown meant that it was still there visually.

I thought you wanted to type markdown, and then have it transform as soon as it had enough context to do so. Which sounds like the worst of all worlds.

Now that I re-read your comment I understand that I actually agree with you 100%.

This is why I think "decorated" w/key bindings to edit in a structured way is basically the best.

See: org-mode.

When a project appears on HN that's identical to one you're working on… always a sad moment.


Anyway, If you're interested in an open source team wiki built on a very similar editor then check out the underling project, https://github.com/outline/outline

It means free early feedback. For example I'm working on a JavaScript based editor like Atom and vscode, and when I announce it will be very fast and it will be possible to edit GB sized files without any lag. And it will be very thin, less then 10 MB in size. And use less then 100 MB of memory. If it wasn't for the other similar projects I would have no idea about these requirements.

I don’t want to sound like a jerk, but you didn’t know people like things to be fast and memory efficient before the dumpster fire collection of web view “code editors” became popular?

I used to worry too back when I only had a few MB. But now I have several GB's of memory on my dev machine. Also I have not heard people complain about Ecipse et-al, but when it comes to the web and JavaScript it has to be fast, or it will be "slow because of JavaScript".

I have 16GB of memory, and I use a java IDE. It uses more memory than the javascript toy editors do, but it does so much more.

If you just want a text editor, there are dozens of native ones for each platform that don’t require java or javascript and are fast.

It’s when you want stuff like advanced code intel, refactoring, etc that the likes of JetBrains products make the memory usage a good trade off.

Using a boat load of ram to render a text file slowly with no more features than textmate or kedit or what have you “because electron” is fucking stupid.

People definitely complain about Eclipse and Intellij being slow, but you might not notice this unless you work in a java shop.

I kind of can relate, as my last project was finished just after the "Run SQL on CSV and TSV" submission popped up, and my project was the same thing but for XML. So have a star (:

Also, I like the way your dashboard looks like (judging by the screenshot on your website).

I hope you'll share it anyway. I enjoyed working on this in school. My thesis advisor worked on a couple papers on your very topic, but as far as I know, nothing was ever turned into a product: https://pdfs.semanticscholar.org/6d34/878442dfde070ada9846fb...

If you’re interested in customizing a web-based (rich) text-editor, I can’t recommend enough the underlying library, SlateJS (http://slatejs.org).

I’ve been relying extensively on it for a quite big project, it’s been a pleasure to use. Especially if you need to change the editor’s content programmatically.

SlateJS is a really neat way to handle rich text editing. I worked shortly on a project to build a rich email client with SlateJS being the underlying library to power the editor. This introduced some interesting issues though around finding the correct way to serialize and deserialize the html due the way that slates core plugins normalize the slate state when working with the different node types (block, inline, mark, text).

The main issue is how to properly associated each html element to a node type, and fit within the core plugin normalization. This is difficult for having to deal with arbitrary html coming from all the different kinds of email client that choose to represent the html structure in their own unique way. However, this is also where SlateJS shines I believe, as you can just normalize all the different html formats into a single representation.

strong, b, font[style="font-weight:*"], etc => Mark Bold

The library has probably changed quite a bit (last I used it was v0.21), so I don't know if my issues are even there anymore, or have changed in some way since.

Overall though, SlateJS is a really neat project, and really fairly simple, and allows for some awesome things to happen in text editors that previous I would believe to be fairly complicated. This is all thanks to the fact that nodes in the slate state can be rendered as rich ReactJS components.

A simple example of this for our use cases was around using template variables in an html email template. I never got around to actually doing this bit, but a variable could be it's own unique node type in the slate state, and allow us to inject a special react component that would make working with the variables much nicer for our users. In the production editor at the time, these variables were just handle bars `{{ first_name }}`, which a lot of customers accidentally would mess up as they had to write out the syntax.

With SlateJS the vision was to simply render a Variable component that would serialize back down into handle bars, or later down the road take the json serialization of the slate state and render that into our own html for sending out.

I really like the patterns SlateJS uses, and I'm excited for any future projects that will allow me to work with it again.

How does SlateJS compare with ProseMirror from a dev's point of view?

It's working as I'd expect it to, which is good. The only problem I have with it is how it slows down when there's much markdown.

For casual editing though, I still prefer working with a raw markdown file with a live preview. Simply because I feel like I have full control over styling. I can remove bold from text without removing the text itself.

Even on the demo page[0], there's noticeable lag when typing. I have to delete the vast majority of the content for it to feel about as responsive as Google Docs, which still feels far slower than Sublime Text or anything native.

For reference, I'm on a 2012 rMBP with a 2.3 Ghz (turbos up to 3 Ghz when I'm typing) quad core i7.

[0]: https://canner.github.io/slate-md-editor/

I am a maintainer for Slate (the Editor framework this project is based on). I haven't looked at the code for this project but the most likely cause for the speed is the live HTML code view on the right. It might even be rendering and syntax highlighting the preview on every keystroke.

I use Slate and have many of the same features and some additional ones and it is more responsive so if you use this project in your code, you may not see the lag since you probably wouldn't have a live HTML view.

The reason we are developing this markdown live editor is that companies have some non-tech editors, for them raw markdown is hard for them to learn, write without real-time feedback.

I'd love to see some data to back that claim up. I've heard that bandied about as a reason to NOT give people markdown but every system i've heard of being deployed and forcing markdown on their users has been "oh, actually this is really easy. we love it"

It'd be interesting to learn more about what exactly these non-tech editors (that are somehow writing for the web on computing machines) find difficult about Markdown.

Markdown was designed to be really, really, really easy to write. But it was designed by techies based on their own experience mostly. Maybe there's a better, simpler MarkPopular that can be used by a wider user base.

Two things that tripped up my users (and sometimes me) and made a live-preview essential were:

- Links and images. ![]() and []() are something you'll see people consistently reverse.

- Nesting markdown in a list, like images and codeblocks. And forgetting that two newlines will end the list which can create an unobvious result in the live preview.

Markdown is easy to write (unlike BBCode) but not always simple to remember, format, or reason about with its strict whitespace rules (unlike BBCode).

> []() are something you'll see people consistently reverse.

Yeah, I've seen this. To help people remember (not ideal, but useful) is the phrase "Robot brackets for human text, human brackets for robot text."

No idea why it helps, you'd expect the reverse to be equally memorable, but it seems to stick with people.

Heh, and then one still accidentally writes !()[] or ()[].

The other nuisance for my users was that the [] text is optional (and relatively worthless from user POV) in ![]() but not []().

I wonder if `!<url>` for images would've been nice alongside `<url>`.

Reddit + the Reddit Enhancement Suite browse plugin have a decent middleground where all urls are autolinked but image urls have additional expand/collapse UI.

> the other nuisance for my users was that the [] text is optional (and relatively worthless from user POV) in ![]() but not []().

Is it not converted to an alt attribute in the rendered HTML?

So wait. You're saying maybe a more explicit language would be easier to use?

It makes sense. When I was just a kid and computers ran MS-DOS my dad did extensive amounts of work with a text editor that used SGML-like takes in angle brackets (but was like <bi> for begin italic, <ei> for end italic; I don't remember actual details). He was past 35, a classical musician and never a techie before (although obviously he wrote on typewriters before), but he basically learned it after less than half an hour of instructions with the guy who brought and installed the machine. Probably less than 10 minutes.

Maybe we're attracted to Markdown/YAML/Org, etc. out of a love of simplicity that's more due to aesthetics than practicality.

I agree strongly with your pain points.

The other problem a live preview helps with: the inconsistencies between various Markdown implementations/flavors.

But raw editing with live preview gives me the same feedback, doesn't it?

I find it distracting when I have to edit a source file and have to keep glancing back and forth between that and a preview pane. As long as it doesn't get in the way, I can see the advantage in live editing. It feels like dropping down to the raw source is something you only should have to do occasionally.

Agree, this looks like it works, but even in the demo there's a big delay between typing and showing up on the screen.

Looks decent but some odd things happen.

I don't appear to be able to put more than one formatted section in a paragraph. The first one works and the second doesn't.

Here's an example with two paragraphs, firstly with bold followed by italic and second vice versa.


Edit. Also, it appears to add unintended spaces around those formatted words (see `<em> dog</em>`). And I wish HN supported inline code snippets.

Odd. Just tried it and it works fine for me.

Strange. I'm on Chrome 65 on Mac if that makes any difference.

I think ProseMirror potentially solves a similar problem, but is more efficient: https://prosemirror.net/examples/markdown/ (then click the WYSIWYM radio button). ProseMirror's API became stable a few months ago; I recently read straight through the documentation and was very, very impressed (I'm a huge fan of the author marijnh's contributions to open source, and want to integrate ProseMirror into CoCalc and Jupyter notebooks soon). ProseMirror is of course very low level though...

I'd really, strongly, very much like this for the Org file format.

I hope to see a pluggable markdown editor sometime. Pluggable in the sense that the syntax (lexer & parser) are highly configurable and can cater to the needs of the domain. Because in effect most websites, documents, et cetera 1) use a certain flavor of markdown and 2) have extensions.

It would be nice to be able to configure a certain syntax and then have the editor be aware of that syntax. Most editors out there currently only work with a fixed syntax or a fixed set of syntaxes.

YAME, Yet Another Markdown Editor.

NAME, Not ANOTHER Markdown Editor?

This sort of editor makes it impossible to edit text. Say I want to change a link or image.. I have to delete it and insert it again. I prefer editors that show a side by side of markdown and rendered text so I can type/edit markdown but also see the output. I think that's a better compromise than replacing the markdown with live text.

Why people stopped doing solutions that are universal? Does everything need to have react as as dependency is now?

"A markdown editor, that allows you to edit live."

I see this exact grammatical tick, adding a comma where one shouldn't be after a noun clause, all the time. Maybe it's native speakers of some other specific language that tend to do it? Which one?

I—a native German speaker—suffer the same tick. Therefore my guess would be German.

Sentences like the one you quoted have a similar structure as those deconstructed in ReadsLikeGerman[1]. The "that" feels like the equivalent of "der"/"die"/"das" and I have the urge to place a comma in front of it.

[1]: http://wiki.c2.com/?ReadsLikeGerman

edit: rephrased for clarity

> I—a native German speaker

It's hilarious that you had a very similar tic in this response, only with a hyphen instead of the comma... :-)

But that was a correct emdash! Not quite the same.

In fact "A markdown editor -- that allows you to edit live." would be correct, though with a slightly different meaning, sorta treating the latter clause as a surprising bonus, as though you would expect the opposite if you only heard the words "a markdown editor".

later: I realize that the word is actually 'tic', which is a funny error coming from someone talking about others' questionable English.

It's like typora.io ?

I love typora, but this is open source which makes it extendable.

I have to click just to see what is "live editing". So far, it works pretty much like org-mode.

Isn't it obvious from the context what "live editing" is? What else could it be? What term would be preferable?

It's obviously not obvious to everyone.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact