Hacker News new | ask | show | jobs
by kamac 2981 days ago
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.

3 comments

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.