I wish Office 365 would hire someone like the author. Online Word never renders the same as it would in the Desktop software...and this matters. I deal with only modestly complex documents when I write grants but I do need to stay within page length limits for sections, I need some layout stability...so I inevitably fire up my Windows VM to run the application.
Before anyone suggests LateX, I know, I know, but when you write collaboratively, you don't always get to choose the platform.
This looks great. I've been impressed at how flexible CodeMirror is though. When I started EtherPK (https://app.etherpk.com) I made a bet that CodeMirror could help me build an editor that could combine outliner blocks, standard prose and rich overlays / graphics / embeds in one editor. I was concerned that I'd hit a road block (I presumed Logseq used custom HTML, nested divs and click position mapping for rendered text to the underlying input for a reason), but 9 months in I couldn't be happier with my choice, and it's a blazing fast editor that feels really nice and light to type in (live demo: https://app.etherpk.com/demo)
This looks slick but I think you need a better way to market it.
The 2D canvas part is the norm for anyone who wants performance. Working with the DOM becomes painfully slow and resource intensive the moment you add syntax highlighting, spell checking, and other visual chrome, to large documents.
This is why Monaco (the editor widget behind VSCode) is a canvas. Why terminal emulators built with web technologies use canvas. And so on.
So I wouldn’t say the canvas part of the heading is a differentiator.
> The 2D canvas part is the norm for anyone who wants performance. Working with the DOM becomes painfully slow and resource intensive the moment you add syntax highlighting, spell checking, and other visual chrome, to large documents.
This is wildly wrong. 2D canvas is consistently slower than letting the browser handle the rendering, so long as you avoid making the DOM too complex, and possibly monitor the viewport and only keep some of the content in the DOM at a time (though for most applications it’s somewhere between harmful and not useful, and it definitely adds a lot of complexity).
> This is why Monaco (the editor widget behind VSCode) is a canvas.
It isn’t.
> Why terminal emulators built with web technologies use canvas.
Why on earth would you build with web technology, if you’re then going to use canvas? I can’t immediately think of any that match your description (though I have no doubt that in-browser ones using canvas exist).
I wrote a similar tool to this many years ago that used JATS as an internal document model, using contentEditable, and I can relate to the pain you refer to. Getting the semantics right in cases where you split or join text that has varying types of nested context was hard.
I like what you did here in terms of the cursor that points one way or the other: it tells you if you're in "normal" mode, or for example, in a bold region. I don't think I've seen that before so, if you made it up, that itself is a cool invention.
We should chat (check bio)! For almost a decade now I’ve been working on a writing tool that might benefit from it. I build occasional forks with procgen on top it. That being said better bidi handling is something I’m most interested in.
Enso.sonnet.io - what I’m talking about.
(On untested.sonnet.io you’ll find notes about the experiments / toys related)
Not bad! But it got slow after I pasted the text of a random blog post 20 times or so. I don't think this will work for writing a book. But for short to medium length notes, it will do fine.
Ok the custom rich text latex editor is really cool. But I'm on a tablet and stuff like selecting text is a bit awkward (the up down auto scroll is not exactly the same as the native one and isn't as precise as the native one).
Cool idea! I approve of the privacy oriented design. But it looks like you didn’t actually test this on iOS as automatic text correction is completely broken.
Also your website appears to have been written and generated entirely with an LLM. That doesn’t inspire trust.
There’s no better way to get a lot of testers than to have a Show HN.
I’ll confirm - there are cursor bugs on iOS. Both on newlines and autocorrect.
I’m personally more forgiving of an LLM “helped” site, if it looks like there was a human in the loop for the process. An LLM has more context about the design goals and architecture than the reader, so if it’s an informative page, I’m not personally bothered.
A human is needed to show how app’s technical features are relevant to a particular audience with a shared social context. As the LLM is not (and should not ever be) a participant in that social environment, any marketing it generates will almost certainly land as tone deaf or presumptuous.
I wish Office 365 would hire someone like the author. Online Word never renders the same as it would in the Desktop software...and this matters. I deal with only modestly complex documents when I write grants but I do need to stay within page length limits for sections, I need some layout stability...so I inevitably fire up my Windows VM to run the application.
Before anyone suggests LateX, I know, I know, but when you write collaboratively, you don't always get to choose the platform.
This looks great. I've been impressed at how flexible CodeMirror is though. When I started EtherPK (https://app.etherpk.com) I made a bet that CodeMirror could help me build an editor that could combine outliner blocks, standard prose and rich overlays / graphics / embeds in one editor. I was concerned that I'd hit a road block (I presumed Logseq used custom HTML, nested divs and click position mapping for rendered text to the underlying input for a reason), but 9 months in I couldn't be happier with my choice, and it's a blazing fast editor that feels really nice and light to type in (live demo: https://app.etherpk.com/demo)
This looks slick but I think you need a better way to market it.
The 2D canvas part is the norm for anyone who wants performance. Working with the DOM becomes painfully slow and resource intensive the moment you add syntax highlighting, spell checking, and other visual chrome, to large documents.
This is why Monaco (the editor widget behind VSCode) is a canvas. Why terminal emulators built with web technologies use canvas. And so on.
So I wouldn’t say the canvas part of the heading is a differentiator.
> The 2D canvas part is the norm for anyone who wants performance. Working with the DOM becomes painfully slow and resource intensive the moment you add syntax highlighting, spell checking, and other visual chrome, to large documents.
This is wildly wrong. 2D canvas is consistently slower than letting the browser handle the rendering, so long as you avoid making the DOM too complex, and possibly monitor the viewport and only keep some of the content in the DOM at a time (though for most applications it’s somewhere between harmful and not useful, and it definitely adds a lot of complexity).
> This is why Monaco (the editor widget behind VSCode) is a canvas.
It isn’t.
> Why terminal emulators built with web technologies use canvas.
Why on earth would you build with web technology, if you’re then going to use canvas? I can’t immediately think of any that match your description (though I have no doubt that in-browser ones using canvas exist).
I wrote a similar tool to this many years ago that used JATS as an internal document model, using contentEditable, and I can relate to the pain you refer to. Getting the semantics right in cases where you split or join text that has varying types of nested context was hard.
I like what you did here in terms of the cursor that points one way or the other: it tells you if you're in "normal" mode, or for example, in a bold region. I don't think I've seen that before so, if you made it up, that itself is a cool invention.
Same thing was done in Flash back in the day :)
We should chat (check bio)! For almost a decade now I’ve been working on a writing tool that might benefit from it. I build occasional forks with procgen on top it. That being said better bidi handling is something I’m most interested in.
Enso.sonnet.io - what I’m talking about.
(On untested.sonnet.io you’ll find notes about the experiments / toys related)
Not bad! But it got slow after I pasted the text of a random blog post 20 times or so. I don't think this will work for writing a book. But for short to medium length notes, it will do fine.
Ok the custom rich text latex editor is really cool. But I'm on a tablet and stuff like selecting text is a bit awkward (the up down auto scroll is not exactly the same as the native one and isn't as precise as the native one).
But still this is an awesome project!
What UI library did you use? Looks clean.
Cool idea! I approve of the privacy oriented design. But it looks like you didn’t actually test this on iOS as automatic text correction is completely broken.
Also your website appears to have been written and generated entirely with an LLM. That doesn’t inspire trust.
There’s no better way to get a lot of testers than to have a Show HN.
I’ll confirm - there are cursor bugs on iOS. Both on newlines and autocorrect.
I’m personally more forgiving of an LLM “helped” site, if it looks like there was a human in the loop for the process. An LLM has more context about the design goals and architecture than the reader, so if it’s an informative page, I’m not personally bothered.
But I’m probably in the minority.
A human is needed to show how app’s technical features are relevant to a particular audience with a shared social context. As the LLM is not (and should not ever be) a participant in that social environment, any marketing it generates will almost certainly land as tone deaf or presumptuous.
That’s the “human in the loop” part. Use the LLM to generate a copy and the human to refine it.
If you think successful campaigns these days are always entirely done by humans, then I’m afraid you’re mistaken.