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.
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.
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.
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.
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.