Nice! Seems very useful if you can drop in and have everything work.
Nitpicking a bit: it's not as much _rendering_ markdown as it's _syntax highlighting_ it. Another interesting approach there could be to use the CSS Custom Highlight API [0]. Then it wouldn't need the preview div, and perhaps it'd even be possible to have non-mono fonts and varying size text for headers.
The animated exploded demo definitely shows formatting differently from plain text (bold is bold, hyphens replaced with bullets.)
4b11b4 4 hours ago [-]
Ya that's true
vmurthy 2 hours ago [-]
Went down the rabbit hole which is the overtype.dev website (nice work btw!) and found and even nicer rabbit hole - https://hyperclay.com/ Single HTML apps :). Enjoy!
dcreater 47 minutes ago [-]
I don't say this often or lightly: my mind is blown.
Why is this not catching fire? Especially in the day of vibe coding this is a far better and far more effective route to app building
runako 1 hours ago [-]
This reminds me of some of the better experiments in mid-aughts Web dev, and is exactly the kind of project that helps push standards & user expectations forward.
dchest 7 hours ago [-]
Looks good!
Some links I've collected in the past that describe this approach:
Love the simplicity. These sort of “less is more” solutions should become more prevalent as average code volume continues to rapidly increase
mmastrac 7 hours ago [-]
This is pretty nice, though I'd suggest you call it a transparent syntax highlighter.
For https://grack.com/demos/adventure/, I used a hidden <input text> for something similar. I wanted to take advantage of paste/selection and all the other goodies of text, but with fully-integrated styling.
Like you, I found that standard text input boxes were far more interesting than contentEditable because they're just so simple overall.
I think there's probably an interesting middle ground here where you render real markdown with the textarea effectively fully hidden (but still with focus), emulate the selection events of the rendered markup into the textarea, and basically get a beautiful editor with all the textarea solidness.
rockwotj 2 hours ago [-]
Fun fact: this is how github adds syntax highlighting in its search bar. A while back I built the same syntax highlighting in Shortwave (an email client) using the same “view on top of a transparent input” trick. Pair it all with the following blog, for a top notch search UX
If it were a WYSIWYG editor, there'd be previews for images. But it seems like it's just syntax highlighting for textareas. Nice project either way, but false advertising.
calmworm 5 hours ago [-]
I didn’t see an option for images. Am I missing something?
macintux 5 hours ago [-]
I assume that was the point. The parent commenter feels "WYSIWYG" by definition includes images.
reactordev 6 hours ago [-]
This is actually really clever. Just don’t let it balloon out to be a 500kb full fledged WYSIWYG editor, just keep it simple like you do.
janwilmake 12 hours ago [-]
Really cool! I just love the simplicity of it: has no drawbacks compared to regular textarea, but has lots of benefits. you basically improved textarea, by a lot!
I also made a similar thing a while ago called contextarea.com, maybe, I should add overtype!
ikurei 7 hours ago [-]
Having to use a monospaced font is a pretty big drawback. To me, it means I wouldn't use this for a product that wasn't intended for a techie programmer audience.
Not that it isn't a really cool project! I'm only saying it has clear drawbacks.
rendaw 3 hours ago [-]
I made something similar! https://github.com/andrewbaxter/malarkdowney - The main difference (I think) is that mine applies h* style changes and isn't visually separated from the rest of the page. I.e. it's not just syntax highlighting, it's a more fully-blown output preview.
The text overlay approach doesn't work if you want width-affecting/height style changes (I assume) since that'd cause the overlay to stop matching. The downside is contenteditable cursor movement is broken for inexplicable reasons.
This isn't really WYSIWYG because it keeps the formatting symbols like * or # etc.
lifthrasiir 4 hours ago [-]
Still, what you see is what you get (plus some formatting symbols). It's marginally WYSIWYG.
mosselman 9 hours ago [-]
Very cool! So simple, I love it.
One thing that would be great is a bit better support for lists (todos, unordered and ordered) where when you press enter once it will add another `-` or `- [ ]`, etc item and when you press it a second time it becomes a blank line.
tomsmeding 7 hours ago [-]
In Firefox on Android, the bold font is wider than the upright and italic fonts, breaking alignment.
(It works fine in Chrome on the same Android phone. Android 16, Firefox 141.0.3)
lifthrasiir 4 hours ago [-]
In fact, depending on font-synthesis [1] and the exact choice of fonts (even when they are monospaced), the alignment can be easily off. That's why this approach only works to some extent and not universal. One possible remedy is to wrap each grapheme into a cell that contains both fonts, where the visible one is bolden and the invisible one affects the advance width. But then you lose ligatures. (Personally I don't like ligatures in coding fonts so it's plus for me, though.)
This is a nifty little project. If I wasn't already neck deep in blocknote adoption in a small experiment I'm doing, I'd be taking this for a spin.
I noticed on the site the really cool animation you got has a 1px solid border on one of the overlays in firefox. Figure you might care since it's clearly supposed to be flashy.
Nice, I was playing around with Milkdown. it's pretty cool: https://milkdown.dev/playground. It's like a block editor like notion for markdown so you don't need the split pane markdown/preview either
ingigauti 9 hours ago [-]
Great idea & solution
I noticed toolbar is missing from options doc, reason I went looking was if I could add my own custom button to the toolbar
nbbaier 1 hours ago [-]
Isn't this just syntax highlighting and not wysiwyg?
ZYbCRq22HbJ2y7 2 hours ago [-]
That is not just a textarea, but it is a pattern seen in many other projects
albert_e 1 hours ago [-]
Minor typo:
> A PEAK UNDER THE HOOD
I think you meant "PEEK"
Tmpod 6 hours ago [-]
As it is, and without the toolbar, this really reminds me of how this[0] neovim plugin renders Markdown in the terminal. One of its nice features is doing syntax highlighting inside fenced code blocks (through tree-sitter I believe).
The scroll syncing in the demo doesn’t seem to work well on iOS Safari. I can’t scroll all the way to the bottom.
wesz 6 hours ago [-]
I used exactly the same approach years ago working on code editor with js evaluation - http://labs.onether.com/javascript-sandbox/ (this is some old version only with whitespace characters, it also had syntax highlighting but i couldn't find it).
Anyway, nice work mate.
pyromaker 5 hours ago [-]
I also got frustrated with text editors and decided to build something for myself too, so I don't have to repeat the process over and over.
Smart! I’ve been working with contenteditable for 3 years. You found a great shortcut!
aschelch 12 hours ago [-]
Looks awesome. Like the simplicity. I'll keep that in mind for future project ;)
(Btw, there might be a typo on the landing page on the set up part. There is 2 times de <div> instead of the textarea i guess;))
Edit: and the link to the Github is brocken
panphora 12 hours ago [-]
The idea is that two instances of overtype would be initialized inside those divs!
indigodaddy 5 hours ago [-]
This is pretty awesome. Now I’m just a dumbo sysadmin with limited webdev/JS skills, so is there a high level way to integrate this into a site so that it could create MD files that could be saved server side?
small_scombrus 5 hours ago [-]
Most JS/TS runtimes have filesystem modules, at it's simplest/least secure you could implement it with client-side fetch and:
On get request - find matching .MD file and return
On put request - write to given location
philo23 8 hours ago [-]
The first time I saw this technique was while trying to figure out how GitHub styled the keyword:value tokens in their search box. It's a very cool technique, and you've done a very nice job of integrating it with a markdown parser!
Only down side to it is that you cant apply any padding to the styled inline elements.
ForceBru 5 hours ago [-]
I thought it should be extremely portable ("everything just works, it's native"), but it doesn't work on iOS 9.3.6. It doesn't even let me input text into the textarea...
A natural extension seems to be a source code editor with syntax highlighting, like those used in https://marimo.io/, Jupyter, https://plutojl.org/ and other notebook-like Web editors.
acherion 5 hours ago [-]
I'm not sure why you are testing in iOS 9.3.6. (which was released in 2015), when the documentation says support for Safari is for versions 16 and above.
bullen 4 hours ago [-]
Anyone knows a good in browser coding editor widget?
That supports color coding for different languages?
farley13 3 hours ago [-]
Codemirror is pretty decent. Last time I looked for this (6+ years ago) it's what we landed on for an internal tool. Things may have changed tho!
drob518 6 hours ago [-]
This is cool (and amazingly simple). Would be even cooler than it already is if it would syntax highlight code in code blocks, too.
neilv 6 hours ago [-]
Am I doing it wrong?
The animation shows variable-pitch fonts, but the demo seems to be all the same fixed-pitch font for me. (On Firefox ESR and Chromium.)
skyzouwdev 6 hours ago [-]
This is honestly brilliant. I love how you leaned into the constraints instead of trying to hide them, and the transparent textarea trick is such a clever hack. The fact that you got it down to 45KB while keeping undo/redo, mobile keyboard, and accessibility makes it feel like a breath of fresh air compared to bloated editors. Definitely bookmarking this for my next project.
jackbridger 4 hours ago [-]
12 pages of docs vs it’s a textarea. Great job, gonna try it out.
maz1b 7 hours ago [-]
Nice job. How is this different than marked on npm?
walterlw 6 hours ago [-]
would absolutely love this for a personal note-taking project, but having image support and some sort of auto-completion for commands, lists, tags etc is crucial for something i'd use every day on desktop and mobile.
Still love seeing more options for different purposes.
nm980 11 hours ago [-]
Can you send the GitHub link again?
And how does this handle rendering larger documents?
is there a way to show the rendered preview (not with the markdown characters)
jerpint 7 hours ago [-]
This is great! Gonna try this on my next project
octobereleven 9 hours ago [-]
Love this. Pretty much markdown on steroids!
sdairs 7 hours ago [-]
This is really nice
nodesocket 9 hours ago [-]
Very cool. I’m gonna implement into my hobby project today and see how it goes.
breakfastduck 9 hours ago [-]
I really like the simplicity of this.
I have a couple projects I could see this being really useful in, at least as an option instead of pure plain text. I still feel like consumers don't like markdown though, it's frustrating.
One thing I noticed, when doing a list (bullet, numbered etc) it would be great if the list continued on barrage return (enter) - most general users would expect that I think.
knoopx 7 hours ago [-]
very nice!
Bengalilol 9 hours ago [-]
> That's it. No npm. No build. No config.
That's it, I am loving it.
sitkack 7 hours ago [-]
If it doesn't have an NPM build, it isn't a serious project. Not using anything w/o a build.
neilv 6 hours ago [-]
If it doesn't work with crack pipes, it's not a serious pharmaceutical.
vid 6 hours ago [-]
I agree with sitkack. npm (packaged software) is really handle to bundle code and keep a repo up to date. But I guess if you just want a markdown editor on a page, this is fine.
3836293648 5 hours ago [-]
You are arguing two (subtly) different points. Not requiring npm or any build step is great. Always.
Having it available to simplify integration into larger projects is also great.
These two things are entirely orthogonal, even if this only does the first one.
vid 1 hours ago [-]
It's fine that the points are different.
If you need to use npm in the rest of the project, which can be helpful for any project that uses front end Javascript, having one library (essentially) that uses a different mechanism is not great.
I have built many projects and while I swore at convoluted bundlers in the past, they are pretty nice these days.
Nitpicking a bit: it's not as much _rendering_ markdown as it's _syntax highlighting_ it. Another interesting approach there could be to use the CSS Custom Highlight API [0]. Then it wouldn't need the preview div, and perhaps it'd even be possible to have non-mono fonts and varying size text for headers.
[0] https://developer.mozilla.org/en-US/docs/Web/API/CSS_Custom_...
Why is this not catching fire? Especially in the day of vibe coding this is a far better and far more effective route to app building
Some links I've collected in the past that describe this approach:
- https://css-tricks.com/creating-an-editable-textarea-that-su...
- https://github.com/WebCoder49/code-input
I believe https://grugnotes.com also does this for markdown.
For https://grack.com/demos/adventure/, I used a hidden <input text> for something similar. I wanted to take advantage of paste/selection and all the other goodies of text, but with fully-integrated styling.
Like you, I found that standard text input boxes were far more interesting than contentEditable because they're just so simple overall.
I think there's probably an interesting middle ground here where you render real markdown with the textarea effectively fully hidden (but still with focus), emulate the selection events of the rendered markup into the textarea, and basically get a beautiful editor with all the textarea solidness.
https://blog.superhuman.com/delightful-search-more-than-meet...
I also made a similar thing a while ago called contextarea.com, maybe, I should add overtype!
Not that it isn't a really cool project! I'm only saying it has clear drawbacks.
The text overlay approach doesn't work if you want width-affecting/height style changes (I assume) since that'd cause the overlay to stop matching. The downside is contenteditable cursor movement is broken for inexplicable reasons.
https://sylvainpolletvillard.github.io/spell/demo.html
One thing that would be great is a bit better support for lists (todos, unordered and ordered) where when you press enter once it will add another `-` or `- [ ]`, etc item and when you press it a second time it becomes a blank line.
(It works fine in Chrome on the same Android phone. Android 16, Firefox 141.0.3)
[1] https://developer.mozilla.org/en-US/docs/Web/CSS/font-synthe...
I noticed on the site the really cool animation you got has a 1px solid border on one of the overlays in firefox. Figure you might care since it's clearly supposed to be flashy.
I noticed toolbar is missing from options doc, reason I went looking was if I could add my own custom button to the toolbar
> A PEAK UNDER THE HOOD
I think you meant "PEEK"
[0]: https://github.com/MeanderingProgrammer/render-markdown.nvim
Anyway, nice work mate.
https://www.texteditors.dev
(Btw, there might be a typo on the landing page on the set up part. There is 2 times de <div> instead of the textarea i guess;))
Edit: and the link to the Github is brocken
On get request - find matching .MD file and return
On put request - write to given location
Only down side to it is that you cant apply any padding to the styled inline elements.
A natural extension seems to be a source code editor with syntax highlighting, like those used in https://marimo.io/, Jupyter, https://plutojl.org/ and other notebook-like Web editors.
That supports color coding for different languages?
The animation shows variable-pitch fonts, but the demo seems to be all the same fixed-pitch font for me. (On Firefox ESR and Chromium.)
And how does this handle rendering larger documents?
https://medv.io/codejar/
I have a couple projects I could see this being really useful in, at least as an option instead of pure plain text. I still feel like consumers don't like markdown though, it's frustrating.
One thing I noticed, when doing a list (bullet, numbered etc) it would be great if the list continued on barrage return (enter) - most general users would expect that I think.
That's it, I am loving it.
Having it available to simplify integration into larger projects is also great.
These two things are entirely orthogonal, even if this only does the first one.
If you need to use npm in the rest of the project, which can be helpful for any project that uses front end Javascript, having one library (essentially) that uses a different mechanism is not great.
I have built many projects and while I swore at convoluted bundlers in the past, they are pretty nice these days.