Design Decision : Serverside or Client Side

Planning to implement MarkDown Preview UI + Markdown Support for a chat application in development.

Web framework is python-tornado

MarkDown Lib i am looking is : remarkable (Faster than commonmark but follows commonmark specs)

For serverside Commonmark Ref implementation .

###Advantages :

###Things i need:

  • clientside security implications of unsafe html ( attacker can just make a http post to bypass markdown preview editor and inject )
  • Server Side performance of Markdown rendering or Markdown Verification
  • Scalablity due to that i am implementing markdown enabled
  • Syntax Highlighting (Commonmark dosen’t support it)

What will be the optimum for both User Experience , Server performance and Security ?

  • Client side Preview + Rendering with Server side verification (But server side verification will take about same performace as rendering? , Will it verify syntax highlighted results ? )
  • Client Side (Just preview) with server side Rendering (Performance issue , need to plug syntax highlight (pygments) to commonmark.
  • Client Side both rendering and Preview , nothing at server side (No Security at all, Highest performance , sytaxhighlight support) .

Client-side + Server-side rendering sounds the safest route.

You probably want to use markdown-it for the client side.

If you want to work on CommonMark-py (or my slightly more featured version) would be great. Adding pygments to the default renderer should be quick.

I am thinking about another route.

  • On client side , markdown preview editor
  • On POST , store Raw markdown in DB.
  • On GET , Render the Stored markdown , stripping the unsafe HTML tags before Rendering.

I think it is Optimum for both Performance and Security.

This enable easy editing of documents too, without needing to convert back.

Any thoughts?

I have a question , what is the difference between Reference Implementation of JGM’s Python CommonMark (which is updated frequently) vs CommonMark-py ?

CommonMark-py is the js reference ported to python and yes, could enjoy more attention.

whate are advantages vs the reference implementation : CommonMark .

The python one is in python so you can render it using the ast directly instead of having the C version produce the json and from it deserialize to ast.