The usual suspects like jsfiddle, codepen, jsbin etc have too many elements on the screen for my liking and often lag. So I made my own today.
i like how simple it is. squarefree html editor is another similar webpage that has been around for almost two decades
Ha interesting, I could feel the lag in keystrokes, and it looks like it just updates in a 150 ms tick loop…
https://stackedit.io/ is doing something more interesting to get low latency, which I’m trying to figure out. Looks like it relies on google-diff-match-patch to selectively update parts of the doc? Not quite sure but that’s what I think.
Although it has a harder problem, because it has to run a Markdown renderer in JS, not just the browser’s native HTML renderer.
var textarea = window.editbox.document.f.ta;
var d = dynamicframe.document;
I was thinking about adding diff patches, but I came to the conclusion that it is not feasible for the use case I am tackling with the editor. The reason is state.
To test the behavior of a whole page, you want the state to be the same as if it was just loaded.
If the page gets too big and causes lag, unticking the “realtime” checkbox helps.
But I do want to experiment with the diff strategy for a Markdown editor. I think it’s a fun little problem since I don’t even know how it’s done right now.
I’m wondering if the slow part is the markdown rendering, or the entire DOM update. That is, do you need to diff the left side, the right side, or both? It’s possible rendering Markdown on every keystroke is acceptable, but updating the entire DOM isn’t. I’ll have to check what StackEdit does specifically.
It seems related to virtual DOM, something I don’t know much about, but which seems here to stay (React, Preact, Elm, etc.)
I rarely have JS in my pages, and if I do, it’s often in an iframe like a YouTube embed. I often have CSS though.
Though it looks like jsfiddle has Ctrl-Enter as a shortcut, and maybe that’s a reasonable compromise …
This is cool … on my core i7 desktop, it works well on Chrome. But I can feel the lag in Firefox, even on a small doc. It has to render all the HTML on every keypress, which isn’t very easy apparently.
On a big doc I would expect the lag to be greater.
As mentioned in a sibling coment, StackEdit is doing something pretty interesting to get low latency. StackEdit uses this JS markdown library internally, and if you try this demo out:
You can see it’s REALLY slow to render Markdown on every keypress. Whereas StackEdit feels very responsive, because they’re doing something smarter.
If anyone wants to help me figure that out, I’d be grateful! It’s a 20K line JS app (which is very “local first”, relies on the cloud very optionally, which is great). I write small pieces of JS but I’ve never written an “app” or even worked on an app in JS.
I actually wrote the last 2 posts on the Oil blog in the browser. It’s a lot easier to write with realtime preview.
I think no one should be surprised that I’m a vim/tmux/bash kind of person, but that’s just because they’re the fastest tools for many jobs. I’m not dogmatic about it. An editor with a GUI is demonstrably better for making rich blog posts. I got the posts out faster.
Hm I guess the experiment I should do is hook up markdown-it to this web page, then load up my latest blog post, and see how fast it is … That is sort of a mini-Stackedit.
Oh this is fun. I had written one of these for a web development course I once taught. I put CodeMirror on the top, and I integrated emmet with it for HTML abbreviation expansion. I always wanted to open source it, but never got around to it.
This looks great and the source is super simple. Great work, thanks for sharing.