arthurtw

Those terms are for the site, not for the text editor. :-) I might open source the editor when I have time.

Not yet. I might do that later, but it requires some cleanup work.

The code has three parts: Markdown to HTML text, HTML DOM to Markdown, and the editor. The total size is about 30KB uncompressed (27KB JS + 3KB CSS). It didn't use any icon font or images.

Wow, that's fun. No wonder few applications use "/" for hotkey combination. Maybe I should use a different key, say, ".".

Yes, its HTML editing is pretty basic. I did not intend to make a full-blown HTML editor. There are already many ones.

My goal is to make Markdown and HTML editors working together. I want to support Markdown because it's very productive for long-form article writing.

Yes it follows CommonMark, but is stricter for safety consideration (e.g. does not allow scripts).

It does not force you to use mouse click on GUI elements. You can use `⌘`+`/` (or `Alt`+`/` on Windows) to switch between WYSIWYG/Markdown modes. Actually it's the preferred way unless you are on mobile devices.

The default mode is WYSIWYG since Markdown syntax frustrates people who don't know Markdown well.

Thanks for mentioning Typora! It's an interesting implementation. I've thought about that approach (in-place real-time preview as you type Markdown text) before, but inside a browser, it's too cumbersome to fight against the inconsistent contenteditable behavior.

I believe OP means a WYSIWYG editor is much better than Markdown.

In terms of a markup language in pure text, I think Markdown is your best bet. Folks in CommonMark.org tries to "standardize" Markdown. Our implementation in Twincl.com follows that standard as much as we can.

Didn't you use existing rich text editors like TinyMCE or CKEditor?

At least you must be careful when using multiple Facebook accounts from the same computer. It might cause your main Facebook account locked, and take you a while to have Facebook unlock it for you.

Forum anonymity (or more precisely, disposable account) is the source of moderation pain and the reason of suboptimal forum content quality. It's one of the main issues I want to address from day 1. If FB account puts a lot of people off, I may consider adopting SMS verification sooner, or change the yearly subscription to a one-time small fee.

It seems Markdown editing is a red flag for broader adoption. I've thought about a dual approach before: allow casual users to edit with GUI, and provide the Markdown editing capability for pro users.

I do not have a fool-proof way to prevent plugin copying. If somehow it's widely copied, it's not a bad thing (to most people), too.

Exactly. That's why we did not use Google identity service. Google accounts are disposable, while Facebook enforces one-account-per-person policy.

Maybe you are right. But Reddit uses Markdown, too, and people seem OK with that? Most redditors are not developers.

You can use a verified Facebook account to join Twincl site for free. Ideally, we should use our own SMS verification process to prevent disposable accounts - maybe when we have money. Since Facebook does a decent job of fraud account prevention, we leverage their work for now.

Thanks for your comment. We'll take that into account.

> 2. Static compilation. This makes a massive difference over Python in terms of catching and correcting problems at compile time vs run time.

Correct. When comparing a static programming language to a dynamic one such as Go vs Python, this is a critical difference. It impacts system stability (production outage rate) and code maintainability a lot, the two characteristics a long-running product desperately needs.

But Go is not comparable to C. Go is garbage-collected, so unlike Rust, it is not a true system programming language (i.e. not low-level enough). On the other hand, it is not high-level enough. It lacks many advanced language constructs, and its type system is rather limited. Simplicity is a big merit of Go, but it's too limited IMO.

Go solves many software development problems for large engineering teams, so I think its ecosystem will keep growing for a while.

Bingo. With `regex!(r"[a-zA-Z0-9_]+")`, Rust finally runs faster than Nim. I’ve updated the article.

Yes, I think Nim deserves more attention, and that’s part of the reason I wrote this article.

Good point! I’ve updated the article accordingly. I learned the Entry thing a few months ago, but Rust’s BTreeMap did not support the entry API at that time, so my code did not use it. Then I totally forgot about it when writing this blog...

I chose it because I wanted to learn Rust by implementing my own BTreeMap struct. I admit it’s not a good choice performance-wise, and made the comparison with Nim less meaningful.

I’ve updated the code and article with HashMap. It runs about 6~7% faster than BTreeMap.

It turns out `collections::HashMap` runs about 6~7% faster than BTreeMap. I will update the article to include results of both data structures.

I’ll try that later, though the Nim version is fast enough after using -d:release flag.

That should explain it. I’ve removed the line as it’s no more mysterious...

I’ve added additional results with Nim’s --boundChecks:on flag. Thank you two for the suggestions.

Oh, my bad. The numbers differ a lot (2~2.5x faster). I’ve updated the article.