8 ms·

Fine, I'll build my own text editor

dang 1mo ago
Recent and related: They don't make 'em like Sublime Text anymore - https://news.ycombinator.com/item?id=49209354 https://news.ycombinator.com/item?id=49209354 - Aug 2026 (13 comments)
- asabla 29d ago
  I used sublime text over so many years. Still find it to be a marvel when it comes to large text files, and how well it still handles them
  - cwnyth 29d ago
    I still don't see a point in switching from Sublime to VS Code. If I need to SSH in to my server, I have options there. But Sublime does everything I need it to do and it does it faster and cleaner and just better than the alternatives.
    - Cthulhu_ 29d ago
      At this point the main advantage VS Code has is its ecosystem. I tried to switch back to VS Code a while ago but most of its plugins are outdated / haven't been updated in five years. It's not the whole story of course, but it just feels like it's no longer able to keep up. In hindsight, part of me wishes I stuck with it for longer. I enjoyed working in it in a way that later editors didn't capture. That said, counterpoint, that was when I wrote a lot of JS in the early NodeJS days, when things like typing or even cmd+clicking on references didn't reliably work because there was no standard module system. Memorizing filenames and the like was still important then.
- mangecoeur 29d ago
  I mean… they still make sublime text. Works great.
  - jsymolon 29d ago
    I have a few minor quibbles about sublime, but I still use it for the bulk of stuff.
- a1o 29d ago
  I still use Sublime Text, is it going to be the new Firefox now?
anon291 1mo ago
I am being pushed to use vs code right now by my team, but we already have a fully programmable and scriptable editor called emacs that is 100000x better. I don't understand why everyone just switches to these random tools. Text editing is a solved problem. Most of the supposed advantages of these tools is just a configuration of vim or emacs.
- xedrac 29d ago
  I use emacs daily (with vim keybindings of course), but I completely understand why vscode is so popular. It's extremely easy to get started with, has features galore, and sane defaults. Emacs takes much more effort to get productive with, although this is improving with each release.
  - cosmic_cheese 29d ago
    In general, I find that good defaults are rather undervalued and downplayed in the FOSS world. Configurability is great but without good defaults it can also be a liability. Would-be users will bounce off long before they like the software enough to pore through pages of options.
    - Mashimo 29d ago
      You speak from my heart. How many years did it take Debian to activate syntax highlighting for nano? Is the bash history still very short? So many low hanging fruits. Same with no screenshots on github projects (For GUI projects)
    - kodoman 29d ago
      The terribleness of emacs defaults is over done. I still use p n postfix key combinations to go to previous and next and f b postfix for forwards and backwards, it's just what you get used to, C-w to c-y to kill and yank are also fine and it's not that much to ask the user to change things if they don't like them. Not to mention all the emacs distros that now exist for people who do want a very different configuration. I maintain that default emacs is fine though and if the user wishes to get really in tune with emacs, emacs is one of the most pleasant environments to learn thanks to help pages and how flexible elisp is to evaluate and poke and prod around with and how easy it is to debug. I think most modern editors will try and introduce mutlithreading and other features that emacs did not do due to it's age and is better for it as it means elisp code just works together and less worry about synchronization and other bits that would exist with more modern ways of approaching the problem (not saying the approach it's self is bad, but for an editor emacs and the decisions around it are largely very good and surprisingly so)
pmkary 29d ago
Text editors are like mechanical watches or fountain pens. There is just so much beauty in the machinery that makes them. For me, there are hardly any other modules that are this satisfying to watch being made. Each time I find a new one (a good one like this), with everything on ropes and rendering and I-beam placement computations and ... it feels like a Christmas gift.
- pmkary 29d ago
  [flagged]
  - pmkary 29d ago
    Literally I only praised and wrote how much I love something and how beautiful text editors are. And there are people who cannot stand this :))) oh wow!
    - qsera 29d ago
      Seriously. What is so beautiful about text editors? (I am not the downvoter btw).
      - pmkary 29d ago
        There is just an insane amount of engineering and work you have to do. Measuring text and shaping fonts is a nightmare, computing chart atlases, having infinite scroll with virtual lines coming to and out of the screen, all the strange data structures to preserve optimized decoration rendering, ropes and ropes (hard data structures), navigating with the keyboard, computing which character interaction is closer to the I-beam when jumping up and down, also caching your previous movements to go back where you actually were. CRDT and atomic editing strategies... There are hundreds and thousands of articles and papers and stuff covering these things. It’s just something we take for granted with so much beauty in the background.
        qsera 29d ago
self_awareness 29d ago
Text editing is a solved problem. It's not about the style of cursor, or if rope is used or not. We already have answers to that. It's about remote editing, LSP support.
- boxed 29d ago
  You can prompt yourself all the way to that. I don't have remote editing in my custom IDE because I never need that personally, but LSP/DSP, syntax highlighting, a built-in lazygit clone, git blame, soft wrap, find-in-files, etc all there: https://github.com/boxed/TurboKod https://github.com/boxed/TurboKod
  - self_awareness 29d ago
    By "LSP support" I didn't mean "editor should call this API over HTTP and interpret whatever LSP server responds". It's a lot more than that, and LSP support in editors if often times broken. It's like saying that editor can have full AI support because it can send HTTP requests to an MCP server. But MCP server isn't the end of the problem, it's just a gateway to problems, just like LSP. For example, jdtls is often times broken, clangd sometimes works, sometimes doesn't. Language servers for ruby are a pain to set up. Some time ago LSP for Dart/Flutter worked under vscode, but not in Vim, because Vim had different assumptions how files should be reported to the LSP. Sometimes is the fault of the server itself, but sometimes the editor isn't fully compatible with some particular LSP server's quirks. It's a mess.
    - boxed 29d ago
      Hmm. I guess there needs to be some kind of general test suite editors and LSPs can validate against?
      - artyomsv 29d ago
        [dead]
- rfgplk 29d ago
samus 29d ago
Every time someone has that idea they discover that text editing is hard! Kudos to the author that they considered accessibility as well.
nottorp 29d ago
There really is a fps counter on there. Is the experiment seriously rendering continuously in a loop?
- deleted 29d ago
  [deleted]
akersten 29d ago
Yes, who would have guessed that the <textarea> element, designed specifically for this use case and built into browsers for 3 decades, would be the most performant and behaviorally consistent way to implement editable text. I'm kind of sad the author stopped shedding unneeded complexity there though... we're not really building a text editor yet, we're building a website with a fancy input field. If we want to build a proper text editor we must eschew the bloat that is the web browser too.
- notarobot123 29d ago
  The browser-standards-or-bust moment has past, hasn't it? If you want your app to work the same way across platforms, using browser defaults is not the way to achieve that. If you want users to have a consistent experience within their browser across the web, I get it, but that's not how the Web has worked for a long long time.
- snoopen 29d ago
  So we take a web browser and trim it down to only ever show a single <textarea> element you say? That's what I'm taking away from this. All the hard work for accessibility is already done then right?
  - cyrilng 29d ago
    [dead]
  - akersten 28d ago
    > So we take a web browser and trim it down to only ever show a single <textarea> element you say? I was saying if the goal is "text editor," the web platform is the wrong foundation entirely
stillpointlab 29d ago
I literally just got Fable to write me a text editor. Well, I'll be honest, I got it to wrap the KDE KTextEditor library which is like 90% of a text editor. I had been using Kate which was what an LLM suggested was the closest to something like Sublime Text on Fedora. But even Kate, which was great, had too much going on. So I asked Fable to take the text editor part (KTextEditor) and wrap it using Rust with an LSP server. It took about 2 days but I have a tiny, super fast little editor. I use Sway to manage things like tabs, fuzzel stands in for fuzzy file search, broot stands in for an explorer view. I've already added Markdown preview support. I might get around to some basic git integration. Then I got it to turn that little editor into a note-taking interface that I have bound to a Mod-m key binding to keep notes in ~/Notes. We live in wild times. I hope everyone is taking advantage while they can.
- inatreecrown2 29d ago
  do you want to share your text editor?
  - boxed 29d ago
    I also had Claude write me an IDE: https://github.com/boxed/TurboKod https://github.com/boxed/TurboKod It's obviously not for everyone, but if you fork that repo and prompt your favorite model to make it look and feel like you want, you can get something extremely useful very fast.
    - rfgplk 29d ago
      Actually looks really good
      - boxed 29d ago
        Heh thanks. It started as a joke idea, but now it's my daily driver. Especially the review mode is useful now that so much work goes through LLMs.
  - stillpointlab 29d ago
globalnode 29d ago
The problem with writing an editor if you intend to use it for coding, is not the text editor itself, that's rather simple. The problem is code completion and syntax highlighting. Then whatever system you try to implement becomes just as bloated as the bloatware you're trying to replace.
- bigstrat2003 29d ago
  You don't actually need either of those things for coding. Many, many programmers did just fine without them.
- alansaber 29d ago
  This is just not true at all.
  - globalnode 29d ago
    Which part is untrue? That theyre simple applications or that syntax highlighting and code completion are difficult?
erichocean 29d ago
If you want to do this in Clojure, Clobber[0] is a great base to start from. It can be used in headless-mode, I've hooked it up to the latest JavaFX text editing component it works very nicely. [0] https://github.com/phronmophobic/clobber https://github.com/phronmophobic/clobber
tzs 29d ago
Sometime around 1980-81 I had a part time job while an undergraduate in college doing system programming/admin for the Caltech High Energy Physics department. Rob Pike was the system programmer/admin before me when he was a grad student in high energy physics, but he left to go work at Bell Labs. One day another student, Karl Heuer, and I both were engaging in the common programmer pastime of complaining about the screen editors of the day and saying we could write something better. Somehow this turned into a competition, and we both spent all night racing against each other writing our editors. It was mostly silent except for the typing, interrupted by the occasional announcement of some feature that was now working to hopefully rattle the other. In the morning the other student system programmer/admin, Norman Wilson, got in and saw what Karl and I had been up to. Norman mentioned this in an email to Rob Pike. His response was something close to this: > Everyone writes a screen editor. It's easy to do and makes them feel important. Tell them to work on something useful. It was only a couple years or so later that Rob Pike wrote a screen editor. I wonder if it made him feel important? :-)
- bigiain 29d ago
  I was hoping for this to end with "I wrote emacs, and Karl wrote vi."
  - LtWorf 29d ago
    If Rob Pike is in the story, it happened like yesterday.
  - NooneAtAll3 29d ago
    [flagged]
  - tzs 29d ago
    Hah. Those were some of the screen editors we complained about. Emacs was popularly said to stand for "(e)ight (m)egabytes (a)nd (c)constantly (s)wapping". (8 MB is small by today's standards, but back then it was big. I believe CITHEP's VAX 11/780 was either 4 MB or 8 MB). I don't remember what we didn't like about vi. At the time most of us were not using any screen editor. We were using the version of QED [1] that Tom Duff, Rob Pike, Hugh Redelmeier, and David Tilbrook had ported to Unix. If anyone is curious Karl's editor was named "ted", for "(t)ext (ed)itor". This was surprisingly bland because Karl was known for coming up with great names. For example when the undergraduate hackers who used Caltech's PDP-10 decided to agree on some standards for things like command switch conventions, Karl named the group working on that: the Organization to Define Definitive Hacks Against Catastrophic Kludges, AKA the odd hack committee. Mine was named "smegma", for something like "(s)ophisticated (m)odern (e)ditor with (g)lorious (m)acros (a)bilities". (I don't think I ever did actually get macros in).
qbane 29d ago
Hope the author finds CodeMirror 6 to be a solid foundation. It uses the same contenteditable-based approach but abstracts away all the browser-specific edge cases and quirks for you.
- gushogg-blake 29d ago
  It's an amazing project but I always found the docs lacking. Maybe you'd have to sit down with the code for a while or ask AI to explain it, but there were concepts, like "facets", that seemed crucial but were never really explained. I also found the way the docs sites were structured to be really frustrating and confusing - it always felt like there were pages missing and I was never sure if I was on the right page for the thing I was trying to read about (or even on the right site, as it's split into multiple projects).
  - qbane 29d ago
    It takes a bit of time to get used to the abstractions, but I think it is worthwhile. To make a minimal working text editor you will only need a little surface of API (covered in the system guide [0]), but to do this by yourself you need to know a lot about browsers' internal working and their undocumented quirks, which is much more overwhelming. (you can glance over `@codemirror/view`'s commit history to see what I mean) [0]: https://codemirror.net/docs/guide/ https://codemirror.net/docs/guide/
vintermann 29d ago
I still miss NEdit. Around 2001 when I started getting into Linux seriously, I was also reading a lot about cults - Scientology had recently, infamously, forced Slashdot to take down a comment about their secret practices. One of the things I read was that a common cult trick was to demand that people re-learn basic skills so that they do them the "right" way, like reading (Scientology did that), eating (chew X times!), using the phone etc. So here's this system that demands I need to learn basic text editing all over? Nope, not joining that cult! We Amiga kids had had graphical editors for a long time! So I got the best modern text editor Linux had at the time, NEdit from fermilab. It was almost entirely CUA + the conventions we use today (which aren't entirely what we used in 2001). And the unusual features it had, such as square selection and X-style middle click copying, were quick to pick up. It was also tiny, both in binary size and memory footprint. Sadly it didn't really survive the switch to utf-8. I switched to Slava Pestov's Jedit for many years, and did some cool things with its huge library of extensions. But when VSCode started doing IDE stuff better than most IDEs, I defected to that. Yes yes, electron, Microsoft, I know... but it's just so damn convenient.
- dwedge 29d ago
  This is both the blessing and the curse of terminal based interfaces (I don't like to say TUI anymore since it makes me think of bubbletea style programs now). The curse being that there is way too much initial learning of how to use it (not that much, you can get by with half a dozen vim keys for years - I used vim for a decade before learning yank) but enough to be frustrating at first. The blessing is that once you master the basics they are very quick and very powerful. GUIs are more intuitive but the options have to be visual so they are always cluttered in my opinions. For most software it doesn't really matter but I want my text editor to let me type without latency or visual clutter and almost nothing else is anywhere near as important. I've tried GUIs many times (vscode, sublime, atom, zed, bbedit, intellij) but I always end up back in vim with CLI git to the point that I get asked in screen share sessions to just use a GUI. It's all personal preference
- gtr 29d ago
  I loved nedit back in the day. I wrote my entire PhD thesis in LaTeX using it. I think the only reason I picked it over emacs (which I was using for coding) was that the text line wrapping was sane out of the box.
jdw64 29d ago
There used to be a joke that said, 'A great programmer should try building a text editor.'
- __patchbit__ 29d ago
  Is Emacs the planaria species of text editors?
  - jdw64 29d ago
    Probably. And that makes Vim the cockroach.
joefreeman 29d ago
> I’m good at building garbage! I've also been building my own editor - it's been fun. In my case it's a modal editor, so I ended up rendering with <div>s, but using a <textarea> to capture from the clipboard. https://github.com/joefreeman/aether https://github.com/joefreeman/aether
pizzabearman 29d ago
Vim bindings joke was great
dkersten 29d ago
Interestingly, for me on iOS, all of the examples worked except the textarea one, which didn’t allow me to interact at all.
Sweepline 29d ago
All I wanted was proper multi-cursor editing and Emacs keybindings. Gave up and just started a new `src` folder.
dvh 29d ago
I've been using my own text editor for over decade. Written in Lazarus using SynEdit component. It's trivial.
tom_wang007 29d ago
[flagged]
alwaysmrno 29d ago
Oh God Not another text editor. I swear that text editors are to computer engineers what trains are to mechanical engineers. Or Satisfactory to Systems Engineers
- mr_mitm 29d ago
  Let's see Paul Allen's text editor
- Cthulhu_ 29d ago
  Frameworks / forums / CMSes to PHP developers
- __patchbit__ 29d ago
  The Moon Landing Project text editors may not have survived
zahlman 29d ago
Oddly enough, I've recently started doing a text editor myself. (I'm using Tkinter, and I am implementing a Vim-like editing system with key commands and modes and such, but substantially different from actual Vim.)
lynx97 29d ago
So apparently every half-serious coder will write at least one chess engine and a text editor. Any other program type which gets implemented over-and-over again?
- somat 29d ago
  Static-site generators. Nothing wrong with that, I like to think there are some apps you should probably make yourself, like the blacksmith apprentice making their own tools.
  - lynx97 29d ago
    I wasn't trying to imply there is anything wrong with these practice projects. I have written at least two chess engines maybe. And I am seriouly considering to write an editor, so, there you have it. I kind of got sidetracked by implementing my own rope...
- krapp 29d ago
  If you hang out here, you've probably tried to write a HN clone or client.
rfgplk 29d ago
The single most disappointing fact about (more or less) all text editors on the market today is how god awful their performance is. For most text editors, and when I say most I really do mean _most_, you can very easily start seeing noticeable lag and stuttering when making modifications, or even outright INPUT LAG when entering text. For very tiny buffers <1kB it's a rare occurrence (although bad editors lag there too), but once you start crossing the 10kB size it's dead obvious. For editing buffers >1MB, 99% of them are unusable due to a) writes taking SECONDS (how?) b) scrolling/using the buffer physically lagging out the editor itself. Which is really basic functionality that editors should be able to handle since it's rather trivial to come across a multiMB json/config file. Try a simple benchmark cd /tmp && dd if=/dev/random of=big_file bs=4096 count=10000 [editor of choice big_file] This should really be _trivial_ for any modern CPU.
- gushogg-blake 29d ago
  Having written a canvas-based editor with some non-trivial features like Tree-sitter based multi-language syntax highlighting, performance is actually what impresses me the most about VS Code. Maybe my standards are different but I don't think I've ever noticed it lag even on large files.
- tmtvl 29d ago
  Large files lagging editors is usually because the entire file needs to be parsed for the editor to know how the syntax highlighting and error reporting should work. Making that random big_file and opening it and editing it should be trivial under any editor (works perfectly fine under Emacs because it gets opened in fundamental mode, even opening it in hexl (hex editor) mode is fine), opening a 40M JSON file is a different can of worms (because it's a larger file Emacs will offer to open it in fundamental mode anyway, which means sacrificing QOL features for performance).
- JaydenDomd 29d ago
  [flagged]
Driftbench 29d ago
Been there, done that. It's a rabbit hole, but you learn so much about rendering and input. Good luck!
swiftcoder 29d ago
For some reason on all the canvas based demos, the text cursor is displayed on the line below where actual text insertion happens (at least on Safari). Canvas-based text editor is definitely hard-mode
- neogodless 29d ago
  Same in Firefox (on Windows).
Jean-Philipe 29d ago
OT but I really like the design of this website. It's fresh, it's fun, but still easy to read. Love the AI policy page as well.
syngrog66 29d ago
A mini-vi/vim I might be willing to reinvent for myself, if I ever felt it was needed or a net win. but would (obviously) prefer not. free time & energy are precious
pacMakaveli 29d ago
[flagged]
throwawayffffas 29d ago
Ooof you were not lying about the garbage. Hidden div for scrolling on canvas... Not really judging I make a lot garbage too. If you are going to do custom drawing why bother with the web platform, go native.
krzyzanowskim 29d ago
the Web is probably the most limited platform today to build custom text editor, in terms of text layout, interaction and all the small bits that may matter. It is still lacking proper API to interact with the OS input system outside the browser built-in text capabilities. That's why the <canvas> approach is so painful, and everything else is "limited" by the HMTL and Browser implementation details.
- utopiah 29d ago
  Could use a WASM environment to run tests or a companion app that run wrap in a (Podman) container, to be safe, e.g : const { exec } = require("child_process"); const express = require('express'); const app = express(); app.get('/', (req, res) => { exec("req", (error, stdout, stderr) => { res.json({error, stdout, stderr}) }) }); }); app.listen(3000); I'm not saying it's perfect but took me a minute.
EdZitron2 29d ago
He used AI but his site says “No AI”
- serchinastico 29d ago
  Where do you get he used AI?
  - ycCantCode 29d ago
    The generated code and comments with emoji are very obvious
    - tredre3 29d ago
      Emojis have been over-used by javascript developers for decades. Long before LLMs, the README of any javascript project was filled with emojis. A non trivial amount of projects even add emojis to their git messages! As unpleasant as emojis are in this context, they aren't a reliable tell about AI.
holgerschurig 29d ago
Fine, I do this since several decades. I use an editor-construction kit named "Emacs" to build my own Editor, and IDE, and git porcelain, and organizer, and wiki. And many things more. IDE with e.g. LSP integration, rustix and many other programmer-related modes and enhancements like tree-sitter. Git porcelain with magit. Organizer with Org-Mode. Wiki with denote.
- shuvrojit 29d ago
  The only thing I miss in emacs is concurrency/multi-threading. Apart from that, it's a complete software for me. Anyone can build it to anyone's liking.
  - tmtvl 28d ago
    Emacs has primitive concurrency (see Chapter 40, Threads in the Elisp manual), and because it's a Lisp, having nice concurrency is just a matter of programming.
philippta 29d ago
I recently learned that Odin has fully-featured text editing primitives in its core library. Coupled with the bundled raylib library, it should be fairly easy to build a GUI text editor from scratch. https://pkg.odin-lang.org/core/text/edit/ https://pkg.odin-lang.org/core/text/edit/
deleted 29d ago
[deleted]
rf15 29d ago
> Fine, I'll build my own text editor > “They don’t make ’em like Sublime Text anymore” resonated with a lot of folk. My first kneejerk reaction was, no, Sublime wasn't even that good or performant. We also really don't need another garbage baby's first text editor. But then > I’m good at building garbage! I appreciate the sentiment, and I guess that IS the right approach to the problem, don't take it too seriously. And the rest of the writeup describes some fun basic hoops you have to jump through to build something as simple as a text editor, so good job.
inopinatus 29d ago
I never stopped using Sublime Text so I suppose I am cool again.
jstummbillig 29d ago
> [...] is promising but I’ve noticed strange [...] In a nutshell, the perpetual experience of writing your own (web) text editor.
Isofarro 29d ago
The author travels the same path that ended up eventually with VS Code. Reminds me strongly of Marjin Haverbeke's talk at Full Frontal conf in 2011: https://ffconf.org/talks/respectable-code-editing-in-the-browser/ https://ffconf.org/talks/respectable-code-editing-in-the-bro... - Using Canvas, then contenteditable, and then DOM. Haverbeke went on to create CodeMirror and ProseMirror.
fg137 29d ago
When I saw the title, I thought this is about a native editor. A noble pursuit. As I read on I realized this is about a web based editor. Almost just as noble but I would not wish anyone go down this rabbit hole. You cannot build a good, performant and useful editor without sinking tons of work, as proved by many people. You could create something simple but will very quickly discover all sorts of problems and edge cases with it.
- criddell 29d ago
  The beauty of the word performant is that any thing is performant if your expectations are low enough.
kris-memoket 29d ago
You are truly a very dedicated developer! Thank you so much for your artifacts!
pmarreck 29d ago
The highlit line and cursor are 1 down from the line it thinks it is editing. I see off-by-one errors are still a common bug class, lol EDIT: It's only in the earlier examples. I'm glad you use pulsating cursors. I made this work in WezTerm but it is expensive CPU-wise!
lbriner 29d ago
A text editor is very personal to your use-case and experience, which is why not everyone likes any particular editor. Before I knew about multi-line cursors, I wouldn't have cared a less about whether an editor did that. Now that I know it and use it and love it, I would never choose to use an editor that doesn't have it. But since I not really spent much time identifying what should be quicker for me in a text editor, I am probably much happier still with simple/quick/responsive compared to some of the vi Gods who require at least 8000 macros to be productive and would never live with a mortal text editor (or emacs :-)
threethirtytwo 29d ago
I love this but, Text editors and IDEs are becoming obsolete. This is not a joke.
- tech_army 29d ago
  In what way ? Can you elaborate ? I use it all the time in Linux to edit config files.
  - threethirtytwo 29d ago
    LLMs
eleventen 29d ago
https://overtype.dev/ https://overtype.dev/ exists to let you do exactly this (for markdown). There’s also https://codemirror.net/ https://codemirror.net/ which is like Monaco but more lightweight.
Schlagbohrer 29d ago
How is it possible that Notepad++ still has no Markdown support? Only a few imperfect plugins exist for it and those of us without admin rights on a corporate computer can't install those. Even though Markdown has become an extremely dominant filetype due to AI.
emursebrian 29d ago
In my mind, my computer is pretty beefy: 2.8 GHZ I7 with 16GB of ram. Yet, vendors like Adobe figure out ways to consume all available resources and make performance complete trash. Ironically, VS Code is one of the few programs that feels fast. Meanwhile, Visual Studio feels slow and janky. Between Notepad++ and VS Code, I don't notice much of a difference in performance for what I do. Browers are one of the few applications these days that are still highly optimized and performant. This is what allowed us to replace Adobe AfterEffects with a custom browser-based renderer. We've seen a 10x performance improvement in some cases: 2mins (Browser) vs 20mins (AfterEffects).
wmwragg 29d ago
For the very basic of basic browser based text editors just use this as the URL: data:text/html, <html contenteditable>
- jsrcout 28d ago
  Nice! That's a new one for me.
kqp 29d ago
Seems to me that in the short term everybody screams “DO NOT OPTIMIZE THAT CODE”, in the medium term everybody shrugs “buy a new computer”, and in the long term everybody gradually migrates to the solutions that optimized that code. I think the mainstream narrative around performance optimization is simply wrong. Inefficiency isn’t a constant, it’s a percentage. You look at software that’s 10x as fast and say yours will run that well in 20 years, and it does, but by then the other guy is 100x as fast, the gap is actually wider, everybody’s doing things that take advantage of all that speed, and you’re either 20 years in the past, still dog slow, balancing the two, or given up. Your software stays bad, and it happens again if you wait again, forever. The idea that optimization matters less over time is short-term thinking. It’s not the end-all, of course. Other things matter, context matters, it’s possible to over-invest, it doesn’t matter if your execs can just force people to use it, many of us are genuinely only planning two years out, etc.
- argee 29d ago
  > The idea that optimization matters less over time is short-term thinking. The more you think about things and the deeper you investigate, the closer you get to realizing that most aphorisms, advice, and even "facts" are a combination of best-effort philosophy and selection biases from the lowest common denominator. Add in the Barnum effect and you end up with an ocean of inconsequential platitudes being parroted by every Tom, Dick, and Harry. It's very difficult, requires active effort, and goes against human nature to act rationally. Most people don't even want to do it.
- ChrisRR 28d ago
  In the longer term we regress and start running an entire web browser to run a text editor in javascript
- coffeeindex 28d ago
  Casey Muratori has an interesting talk about how that narrative (“premature optimization is the root of all evil”) came to the mainstream narrative https://youtu.be/hpj6r6CjJf8 https://youtu.be/hpj6r6CjJf8
mikewarot 29d ago
I was a student at Rose-Hulman back in 1981-83. Back then they had a tweaked out 11/70 running RSTS and supporting 144 terminals, and the new spiffy VAX 11/780 running VMS. I found an old 11/40 that had a memory issue to work on, and started learning machine code, etc. Somewhere along the line, I was infected with a love of TECO, a relic of an editor that was said to be the basis for EMACS. I wrote my own version out of nostalgia in 1991. I put it on Github a few years ago.[1] It's only in the past few months that I learned that the first versions of TECO were actually full screen editors, which floored me, as I had always assumed TECO stood for Tape Editor, Character Oriented.... and started with teletype terminals and paper tape. [1] https://github.com/mikewarot/teco https://github.com/mikewarot/teco
owenbrown 29d ago
Check out Quick Memory. It’s a stripped-down, faster Obsidian. All rust, not html. https://qm.venka.com https://qm.venka.com It’s small (zip < 7MB) and fast (launches in 300 ms, opens Moby Dick in < 300 ms). Ping me if you use and something is missing. It’s my daily note-taking app.
marssaxman 29d ago
"Fine, I'll build my own text editor" is certainly a familiar sentence, one I've uttered several times, but it would never in a thousand years occur to me to take the next step in a web browser. Interesting to see such a different approach to the world: thank you for sharing.
demibabs 29d ago
I never understood why people have an issue with VS Code
- iLemming 27d ago
  > why people have an issue with VS Code Indeed. Why people had any beef with: - Borland Turbo Pascal, Turbo C, Turbo C++, Turbo Assembler, Borland JBuilder - Visual Basic IDE, Visual SourceSafe, FrontPage - Dreamweaver, Brackets, TextMate, JetBrains Fleet, etc. It's totally okay to spend years investing in some proprietary editor, IDE, tool, whatever. Just learn how to learn them quickly and learn how to dump that knowledge with no regrets. Never develop muscle memory, never learn keyboard shortcuts, never build extensions. Who cares if you're using it efficiently or as if you just woke up to it this morning? By the time you try to get comfortable in any tool, it may vanish into obscurity or become something else. Do not, I implore you, do not learn Emacs or Vim. They both predate every product on this list and will outlast everything on it. You may eventually get comfortable and even start liking your job. Surely, you don't want to start getting paid for having fun?
c-smile 29d ago
Just in case... In Sciter I have three editing behaviors (element controllers) associated with these elements by defualt: * <textarea> - plain text editor working with single text node. * <htmlarea> - WYSIWYG editor working with a DOM tree. * <plaintext> - editor working with a list of <text> elements. Each <text> element is allowed to have only inline and inline-block subelements and text nodes [1]. <plaintext> is optimized to work as a source code editor. Local editing in one <text> element invalidates text layout of that only element but not the whole content as in case of <textarea>. All editors support ::highlight - to style fragments of text without the need to change underlying DOM. <plaintext> provides streaming API allowing to access content of the element as pure plain text but with methods to ::highlight ranges in it to minimize problems with encodings and mappings of text positions to corresponding node trees and making syntax highlighting simpler: See screenshot: https://sciter.com/wp-content/uploads/2026/09/plaintext-colorizer.jpg https://sciter.com/wp-content/uploads/2026/09/plaintext-colo... <htmlarea> and <plaintext> also support transactional updates allowing to make non-trivial DOM tree mutations undoable as a single operation. [1] behavior:plaintext - https://docs.sciter.com/docs/behaviors/behavior-plaintext https://docs.sciter.com/docs/behaviors/behavior-plaintext
othmanosx 29d ago
I was waiting for the punch line
NikhilChowdaryG 29d ago
[flagged]
xacky 27d ago
It's always yet another yext editor instead of helping get people off Adobe's subscription trap.

dang 1mo ago

Recent and related: They don't make 'em like Sublime Text anymore - https://news.ycombinator.com/item?id=49209354 https://news.ycombinator.com/item?id=49209354 - Aug 2026 (13 comments)

asabla 29d ago
I used sublime text over so many years. Still find it to be a marvel when it comes to large text files, and how well it still handles them
- cwnyth 29d ago
  I still don't see a point in switching from Sublime to VS Code. If I need to SSH in to my server, I have options there. But Sublime does everything I need it to do and it does it faster and cleaner and just better than the alternatives.
  - Cthulhu_ 29d ago
    At this point the main advantage VS Code has is its ecosystem. I tried to switch back to VS Code a while ago but most of its plugins are outdated / haven't been updated in five years. It's not the whole story of course, but it just feels like it's no longer able to keep up. In hindsight, part of me wishes I stuck with it for longer. I enjoyed working in it in a way that later editors didn't capture. That said, counterpoint, that was when I wrote a lot of JS in the early NodeJS days, when things like typing or even cmd+clicking on references didn't reliably work because there was no standard module system. Memorizing filenames and the like was still important then.
mangecoeur 29d ago
I mean… they still make sublime text. Works great.
- jsymolon 29d ago
  I have a few minor quibbles about sublime, but I still use it for the bulk of stuff.
a1o 29d ago
I still use Sublime Text, is it going to be the new Firefox now?

anon291 1mo ago

I am being pushed to use vs code right now by my team, but we already have a fully programmable and scriptable editor called emacs that is 100000x better. I don't understand why everyone just switches to these random tools. Text editing is a solved problem. Most of the supposed advantages of these tools is just a configuration of vim or emacs.

xedrac 29d ago
I use emacs daily (with vim keybindings of course), but I completely understand why vscode is so popular. It's extremely easy to get started with, has features galore, and sane defaults. Emacs takes much more effort to get productive with, although this is improving with each release.
- cosmic_cheese 29d ago
  In general, I find that good defaults are rather undervalued and downplayed in the FOSS world. Configurability is great but without good defaults it can also be a liability. Would-be users will bounce off long before they like the software enough to pore through pages of options.
  - Mashimo 29d ago
    You speak from my heart. How many years did it take Debian to activate syntax highlighting for nano? Is the bash history still very short? So many low hanging fruits. Same with no screenshots on github projects (For GUI projects)
  - kodoman 29d ago
    The terribleness of emacs defaults is over done. I still use p n postfix key combinations to go to previous and next and f b postfix for forwards and backwards, it's just what you get used to, C-w to c-y to kill and yank are also fine and it's not that much to ask the user to change things if they don't like them. Not to mention all the emacs distros that now exist for people who do want a very different configuration. I maintain that default emacs is fine though and if the user wishes to get really in tune with emacs, emacs is one of the most pleasant environments to learn thanks to help pages and how flexible elisp is to evaluate and poke and prod around with and how easy it is to debug. I think most modern editors will try and introduce mutlithreading and other features that emacs did not do due to it's age and is better for it as it means elisp code just works together and less worry about synchronization and other bits that would exist with more modern ways of approaching the problem (not saying the approach it's self is bad, but for an editor emacs and the decisions around it are largely very good and surprisingly so)

pmkary 29d ago

Text editors are like mechanical watches or fountain pens. There is just so much beauty in the machinery that makes them. For me, there are hardly any other modules that are this satisfying to watch being made. Each time I find a new one (a good one like this), with everything on ropes and rendering and I-beam placement computations and ... it feels like a Christmas gift.

pmkary 29d ago
[flagged]
- pmkary 29d ago
  Literally I only praised and wrote how much I love something and how beautiful text editors are. And there are people who cannot stand this :))) oh wow!
  - qsera 29d ago
    Seriously. What is so beautiful about text editors? (I am not the downvoter btw).
    - pmkary 29d ago
      There is just an insane amount of engineering and work you have to do. Measuring text and shaping fonts is a nightmare, computing chart atlases, having infinite scroll with virtual lines coming to and out of the screen, all the strange data structures to preserve optimized decoration rendering, ropes and ropes (hard data structures), navigating with the keyboard, computing which character interaction is closer to the I-beam when jumping up and down, also caching your previous movements to go back where you actually were. CRDT and atomic editing strategies... There are hundreds and thousands of articles and papers and stuff covering these things. It’s just something we take for granted with so much beauty in the background.
      - qsera 29d ago

self_awareness 29d ago

Text editing is a solved problem. It's not about the style of cursor, or if rope is used or not. We already have answers to that. It's about remote editing, LSP support.

boxed 29d ago
You can prompt yourself all the way to that. I don't have remote editing in my custom IDE because I never need that personally, but LSP/DSP, syntax highlighting, a built-in lazygit clone, git blame, soft wrap, find-in-files, etc all there: https://github.com/boxed/TurboKod https://github.com/boxed/TurboKod
- self_awareness 29d ago
  By "LSP support" I didn't mean "editor should call this API over HTTP and interpret whatever LSP server responds". It's a lot more than that, and LSP support in editors if often times broken. It's like saying that editor can have full AI support because it can send HTTP requests to an MCP server. But MCP server isn't the end of the problem, it's just a gateway to problems, just like LSP. For example, jdtls is often times broken, clangd sometimes works, sometimes doesn't. Language servers for ruby are a pain to set up. Some time ago LSP for Dart/Flutter worked under vscode, but not in Vim, because Vim had different assumptions how files should be reported to the LSP. Sometimes is the fault of the server itself, but sometimes the editor isn't fully compatible with some particular LSP server's quirks. It's a mess.
  - boxed 29d ago
    Hmm. I guess there needs to be some kind of general test suite editors and LSPs can validate against?
    - artyomsv 29d ago
      [dead]
rfgplk 29d ago

samus 29d ago

Every time someone has that idea they discover that text editing is hard! Kudos to the author that they considered accessibility as well.

nottorp 29d ago

There really is a fps counter on there. Is the experiment seriously rendering continuously in a loop?

deleted 29d ago
[deleted]

akersten 29d ago

Yes, who would have guessed that the <textarea> element, designed specifically for this use case and built into browsers for 3 decades, would be the most performant and behaviorally consistent way to implement editable text. I'm kind of sad the author stopped shedding unneeded complexity there though... we're not really building a text editor yet, we're building a website with a fancy input field. If we want to build a proper text editor we must eschew the bloat that is the web browser too.

notarobot123 29d ago
The browser-standards-or-bust moment has past, hasn't it? If you want your app to work the same way across platforms, using browser defaults is not the way to achieve that. If you want users to have a consistent experience within their browser across the web, I get it, but that's not how the Web has worked for a long long time.
snoopen 29d ago
So we take a web browser and trim it down to only ever show a single <textarea> element you say? That's what I'm taking away from this. All the hard work for accessibility is already done then right?
- cyrilng 29d ago
  [dead]
- akersten 28d ago
  > So we take a web browser and trim it down to only ever show a single <textarea> element you say? I was saying if the goal is "text editor," the web platform is the wrong foundation entirely

stillpointlab 29d ago

I literally just got Fable to write me a text editor. Well, I'll be honest, I got it to wrap the KDE KTextEditor library which is like 90% of a text editor. I had been using Kate which was what an LLM suggested was the closest to something like Sublime Text on Fedora. But even Kate, which was great, had too much going on. So I asked Fable to take the text editor part (KTextEditor) and wrap it using Rust with an LSP server. It took about 2 days but I have a tiny, super fast little editor. I use Sway to manage things like tabs, fuzzel stands in for fuzzy file search, broot stands in for an explorer view. I've already added Markdown preview support. I might get around to some basic git integration. Then I got it to turn that little editor into a note-taking interface that I have bound to a Mod-m key binding to keep notes in ~/Notes. We live in wild times. I hope everyone is taking advantage while they can.

inatreecrown2 29d ago
do you want to share your text editor?
- boxed 29d ago
  I also had Claude write me an IDE: https://github.com/boxed/TurboKod https://github.com/boxed/TurboKod It's obviously not for everyone, but if you fork that repo and prompt your favorite model to make it look and feel like you want, you can get something extremely useful very fast.
  - rfgplk 29d ago
    Actually looks really good
    - boxed 29d ago
      Heh thanks. It started as a joke idea, but now it's my daily driver. Especially the review mode is useful now that so much work goes through LLMs.
- stillpointlab 29d ago

globalnode 29d ago

The problem with writing an editor if you intend to use it for coding, is not the text editor itself, that's rather simple. The problem is code completion and syntax highlighting. Then whatever system you try to implement becomes just as bloated as the bloatware you're trying to replace.

bigstrat2003 29d ago
You don't actually need either of those things for coding. Many, many programmers did just fine without them.
alansaber 29d ago
This is just not true at all.
- globalnode 29d ago
  Which part is untrue? That theyre simple applications or that syntax highlighting and code completion are difficult?

erichocean 29d ago

If you want to do this in Clojure, Clobber[0] is a great base to start from. It can be used in headless-mode, I've hooked it up to the latest JavaFX text editing component it works very nicely. [0] https://github.com/phronmophobic/clobber https://github.com/phronmophobic/clobber

tzs 29d ago

Sometime around 1980-81 I had a part time job while an undergraduate in college doing system programming/admin for the Caltech High Energy Physics department. Rob Pike was the system programmer/admin before me when he was a grad student in high energy physics, but he left to go work at Bell Labs. One day another student, Karl Heuer, and I both were engaging in the common programmer pastime of complaining about the screen editors of the day and saying we could write something better. Somehow this turned into a competition, and we both spent all night racing against each other writing our editors. It was mostly silent except for the typing, interrupted by the occasional announcement of some feature that was now working to hopefully rattle the other. In the morning the other student system programmer/admin, Norman Wilson, got in and saw what Karl and I had been up to. Norman mentioned this in an email to Rob Pike. His response was something close to this: > Everyone writes a screen editor. It's easy to do and makes them feel important. Tell them to work on something useful. It was only a couple years or so later that Rob Pike wrote a screen editor. I wonder if it made him feel important? :-)

bigiain 29d ago
I was hoping for this to end with "I wrote emacs, and Karl wrote vi."
- LtWorf 29d ago
  If Rob Pike is in the story, it happened like yesterday.
- NooneAtAll3 29d ago
  [flagged]
- tzs 29d ago
  Hah. Those were some of the screen editors we complained about. Emacs was popularly said to stand for "(e)ight (m)egabytes (a)nd (c)constantly (s)wapping". (8 MB is small by today's standards, but back then it was big. I believe CITHEP's VAX 11/780 was either 4 MB or 8 MB). I don't remember what we didn't like about vi. At the time most of us were not using any screen editor. We were using the version of QED [1] that Tom Duff, Rob Pike, Hugh Redelmeier, and David Tilbrook had ported to Unix. If anyone is curious Karl's editor was named "ted", for "(t)ext (ed)itor". This was surprisingly bland because Karl was known for coming up with great names. For example when the undergraduate hackers who used Caltech's PDP-10 decided to agree on some standards for things like command switch conventions, Karl named the group working on that: the Organization to Define Definitive Hacks Against Catastrophic Kludges, AKA the odd hack committee. Mine was named "smegma", for something like "(s)ophisticated (m)odern (e)ditor with (g)lorious (m)acros (a)bilities". (I don't think I ever did actually get macros in).

qbane 29d ago

Hope the author finds CodeMirror 6 to be a solid foundation. It uses the same contenteditable-based approach but abstracts away all the browser-specific edge cases and quirks for you.

gushogg-blake 29d ago
It's an amazing project but I always found the docs lacking. Maybe you'd have to sit down with the code for a while or ask AI to explain it, but there were concepts, like "facets", that seemed crucial but were never really explained. I also found the way the docs sites were structured to be really frustrating and confusing - it always felt like there were pages missing and I was never sure if I was on the right page for the thing I was trying to read about (or even on the right site, as it's split into multiple projects).
- qbane 29d ago
  It takes a bit of time to get used to the abstractions, but I think it is worthwhile. To make a minimal working text editor you will only need a little surface of API (covered in the system guide [0]), but to do this by yourself you need to know a lot about browsers' internal working and their undocumented quirks, which is much more overwhelming. (you can glance over `@codemirror/view`'s commit history to see what I mean) [0]: https://codemirror.net/docs/guide/ https://codemirror.net/docs/guide/

vintermann 29d ago

I still miss NEdit. Around 2001 when I started getting into Linux seriously, I was also reading a lot about cults - Scientology had recently, infamously, forced Slashdot to take down a comment about their secret practices. One of the things I read was that a common cult trick was to demand that people re-learn basic skills so that they do them the "right" way, like reading (Scientology did that), eating (chew X times!), using the phone etc. So here's this system that demands I need to learn basic text editing all over? Nope, not joining that cult! We Amiga kids had had graphical editors for a long time! So I got the best modern text editor Linux had at the time, NEdit from fermilab. It was almost entirely CUA + the conventions we use today (which aren't entirely what we used in 2001). And the unusual features it had, such as square selection and X-style middle click copying, were quick to pick up. It was also tiny, both in binary size and memory footprint. Sadly it didn't really survive the switch to utf-8. I switched to Slava Pestov's Jedit for many years, and did some cool things with its huge library of extensions. But when VSCode started doing IDE stuff better than most IDEs, I defected to that. Yes yes, electron, Microsoft, I know... but it's just so damn convenient.

dwedge 29d ago
This is both the blessing and the curse of terminal based interfaces (I don't like to say TUI anymore since it makes me think of bubbletea style programs now). The curse being that there is way too much initial learning of how to use it (not that much, you can get by with half a dozen vim keys for years - I used vim for a decade before learning yank) but enough to be frustrating at first. The blessing is that once you master the basics they are very quick and very powerful. GUIs are more intuitive but the options have to be visual so they are always cluttered in my opinions. For most software it doesn't really matter but I want my text editor to let me type without latency or visual clutter and almost nothing else is anywhere near as important. I've tried GUIs many times (vscode, sublime, atom, zed, bbedit, intellij) but I always end up back in vim with CLI git to the point that I get asked in screen share sessions to just use a GUI. It's all personal preference
gtr 29d ago
I loved nedit back in the day. I wrote my entire PhD thesis in LaTeX using it. I think the only reason I picked it over emacs (which I was using for coding) was that the text line wrapping was sane out of the box.

jdw64 29d ago

There used to be a joke that said, 'A great programmer should try building a text editor.'

__patchbit__ 29d ago
Is Emacs the planaria species of text editors?
- jdw64 29d ago
  Probably. And that makes Vim the cockroach.

joefreeman 29d ago

> I’m good at building garbage! I've also been building my own editor - it's been fun. In my case it's a modal editor, so I ended up rendering with <div>s, but using a <textarea> to capture from the clipboard. https://github.com/joefreeman/aether https://github.com/joefreeman/aether

pizzabearman 29d ago

Vim bindings joke was great

dkersten 29d ago

Interestingly, for me on iOS, all of the examples worked except the textarea one, which didn’t allow me to interact at all.

Sweepline 29d ago

All I wanted was proper multi-cursor editing and Emacs keybindings. Gave up and just started a new `src` folder.

dvh 29d ago

I've been using my own text editor for over decade. Written in Lazarus using SynEdit component. It's trivial.

tom_wang007 29d ago

[flagged]

alwaysmrno 29d ago

Oh God Not another text editor. I swear that text editors are to computer engineers what trains are to mechanical engineers. Or Satisfactory to Systems Engineers

mr_mitm 29d ago
Let's see Paul Allen's text editor
Cthulhu_ 29d ago
Frameworks / forums / CMSes to PHP developers
__patchbit__ 29d ago
The Moon Landing Project text editors may not have survived

zahlman 29d ago

Oddly enough, I've recently started doing a text editor myself. (I'm using Tkinter, and I am implementing a Vim-like editing system with key commands and modes and such, but substantially different from actual Vim.)

lynx97 29d ago

So apparently every half-serious coder will write at least one chess engine and a text editor. Any other program type which gets implemented over-and-over again?

somat 29d ago
Static-site generators. Nothing wrong with that, I like to think there are some apps you should probably make yourself, like the blacksmith apprentice making their own tools.
- lynx97 29d ago
  I wasn't trying to imply there is anything wrong with these practice projects. I have written at least two chess engines maybe. And I am seriouly considering to write an editor, so, there you have it. I kind of got sidetracked by implementing my own rope...
krapp 29d ago
If you hang out here, you've probably tried to write a HN clone or client.

rfgplk 29d ago

The single most disappointing fact about (more or less) all text editors on the market today is how god awful their performance is. For most text editors, and when I say most I really do mean _most_, you can very easily start seeing noticeable lag and stuttering when making modifications, or even outright INPUT LAG when entering text. For very tiny buffers <1kB it's a rare occurrence (although bad editors lag there too), but once you start crossing the 10kB size it's dead obvious. For editing buffers >1MB, 99% of them are unusable due to a) writes taking SECONDS (how?) b) scrolling/using the buffer physically lagging out the editor itself. Which is really basic functionality that editors should be able to handle since it's rather trivial to come across a multiMB json/config file. Try a simple benchmark cd /tmp && dd if=/dev/random of=big_file bs=4096 count=10000 [editor of choice big_file] This should really be _trivial_ for any modern CPU.

gushogg-blake 29d ago
Having written a canvas-based editor with some non-trivial features like Tree-sitter based multi-language syntax highlighting, performance is actually what impresses me the most about VS Code. Maybe my standards are different but I don't think I've ever noticed it lag even on large files.
tmtvl 29d ago
Large files lagging editors is usually because the entire file needs to be parsed for the editor to know how the syntax highlighting and error reporting should work. Making that random big_file and opening it and editing it should be trivial under any editor (works perfectly fine under Emacs because it gets opened in fundamental mode, even opening it in hexl (hex editor) mode is fine), opening a 40M JSON file is a different can of worms (because it's a larger file Emacs will offer to open it in fundamental mode anyway, which means sacrificing QOL features for performance).
JaydenDomd 29d ago
[flagged]

Driftbench 29d ago

Been there, done that. It's a rabbit hole, but you learn so much about rendering and input. Good luck!

swiftcoder 29d ago

For some reason on all the canvas based demos, the text cursor is displayed on the line below where actual text insertion happens (at least on Safari). Canvas-based text editor is definitely hard-mode

neogodless 29d ago
Same in Firefox (on Windows).

Jean-Philipe 29d ago

OT but I really like the design of this website. It's fresh, it's fun, but still easy to read. Love the AI policy page as well.

syngrog66 29d ago

A mini-vi/vim I might be willing to reinvent for myself, if I ever felt it was needed or a net win. but would (obviously) prefer not. free time & energy are precious

pacMakaveli 29d ago

[flagged]

throwawayffffas 29d ago

Ooof you were not lying about the garbage. Hidden div for scrolling on canvas... Not really judging I make a lot garbage too. If you are going to do custom drawing why bother with the web platform, go native.

krzyzanowskim 29d ago

the Web is probably the most limited platform today to build custom text editor, in terms of text layout, interaction and all the small bits that may matter. It is still lacking proper API to interact with the OS input system outside the browser built-in text capabilities. That's why the <canvas> approach is so painful, and everything else is "limited" by the HMTL and Browser implementation details.

utopiah 29d ago
Could use a WASM environment to run tests or a companion app that run wrap in a (Podman) container, to be safe, e.g : const { exec } = require("child_process"); const express = require('express'); const app = express(); app.get('/', (req, res) => { exec("req", (error, stdout, stderr) => { res.json({error, stdout, stderr}) }) }); }); app.listen(3000); I'm not saying it's perfect but took me a minute.

EdZitron2 29d ago

He used AI but his site says “No AI”

serchinastico 29d ago
Where do you get he used AI?
- ycCantCode 29d ago
  The generated code and comments with emoji are very obvious
  - tredre3 29d ago
    Emojis have been over-used by javascript developers for decades. Long before LLMs, the README of any javascript project was filled with emojis. A non trivial amount of projects even add emojis to their git messages! As unpleasant as emojis are in this context, they aren't a reliable tell about AI.

holgerschurig 29d ago

Fine, I do this since several decades. I use an editor-construction kit named "Emacs" to build my own Editor, and IDE, and git porcelain, and organizer, and wiki. And many things more. IDE with e.g. LSP integration, rustix and many other programmer-related modes and enhancements like tree-sitter. Git porcelain with magit. Organizer with Org-Mode. Wiki with denote.

shuvrojit 29d ago
The only thing I miss in emacs is concurrency/multi-threading. Apart from that, it's a complete software for me. Anyone can build it to anyone's liking.
- tmtvl 28d ago
  Emacs has primitive concurrency (see Chapter 40, Threads in the Elisp manual), and because it's a Lisp, having nice concurrency is just a matter of programming.

philippta 29d ago

I recently learned that Odin has fully-featured text editing primitives in its core library. Coupled with the bundled raylib library, it should be fairly easy to build a GUI text editor from scratch. https://pkg.odin-lang.org/core/text/edit/ https://pkg.odin-lang.org/core/text/edit/

deleted 29d ago

[deleted]

rf15 29d ago

> Fine, I'll build my own text editor > “They don’t make ’em like Sublime Text anymore” resonated with a lot of folk. My first kneejerk reaction was, no, Sublime wasn't even that good or performant. We also really don't need another garbage baby's first text editor. But then > I’m good at building garbage! I appreciate the sentiment, and I guess that IS the right approach to the problem, don't take it too seriously. And the rest of the writeup describes some fun basic hoops you have to jump through to build something as simple as a text editor, so good job.

inopinatus 29d ago

I never stopped using Sublime Text so I suppose I am cool again.

jstummbillig 29d ago

> [...] is promising but I’ve noticed strange [...] In a nutshell, the perpetual experience of writing your own (web) text editor.

Isofarro 29d ago

The author travels the same path that ended up eventually with VS Code. Reminds me strongly of Marjin Haverbeke's talk at Full Frontal conf in 2011: https://ffconf.org/talks/respectable-code-editing-in-the-browser/ https://ffconf.org/talks/respectable-code-editing-in-the-bro... - Using Canvas, then contenteditable, and then DOM. Haverbeke went on to create CodeMirror and ProseMirror.

fg137 29d ago

When I saw the title, I thought this is about a native editor. A noble pursuit. As I read on I realized this is about a web based editor. Almost just as noble but I would not wish anyone go down this rabbit hole. You cannot build a good, performant and useful editor without sinking tons of work, as proved by many people. You could create something simple but will very quickly discover all sorts of problems and edge cases with it.

criddell 29d ago
The beauty of the word performant is that any thing is performant if your expectations are low enough.

kris-memoket 29d ago

You are truly a very dedicated developer! Thank you so much for your artifacts!

pmarreck 29d ago

The highlit line and cursor are 1 down from the line it thinks it is editing. I see off-by-one errors are still a common bug class, lol EDIT: It's only in the earlier examples. I'm glad you use pulsating cursors. I made this work in WezTerm but it is expensive CPU-wise!

lbriner 29d ago

A text editor is very personal to your use-case and experience, which is why not everyone likes any particular editor. Before I knew about multi-line cursors, I wouldn't have cared a less about whether an editor did that. Now that I know it and use it and love it, I would never choose to use an editor that doesn't have it. But since I not really spent much time identifying what should be quicker for me in a text editor, I am probably much happier still with simple/quick/responsive compared to some of the vi Gods who require at least 8000 macros to be productive and would never live with a mortal text editor (or emacs :-)

threethirtytwo 29d ago

I love this but, Text editors and IDEs are becoming obsolete. This is not a joke.

tech_army 29d ago
In what way ? Can you elaborate ? I use it all the time in Linux to edit config files.
- threethirtytwo 29d ago
  LLMs

eleventen 29d ago

https://overtype.dev/ https://overtype.dev/ exists to let you do exactly this (for markdown). There’s also https://codemirror.net/ https://codemirror.net/ which is like Monaco but more lightweight.

Schlagbohrer 29d ago

How is it possible that Notepad++ still has no Markdown support? Only a few imperfect plugins exist for it and those of us without admin rights on a corporate computer can't install those. Even though Markdown has become an extremely dominant filetype due to AI.

emursebrian 29d ago

In my mind, my computer is pretty beefy: 2.8 GHZ I7 with 16GB of ram. Yet, vendors like Adobe figure out ways to consume all available resources and make performance complete trash. Ironically, VS Code is one of the few programs that feels fast. Meanwhile, Visual Studio feels slow and janky. Between Notepad++ and VS Code, I don't notice much of a difference in performance for what I do. Browers are one of the few applications these days that are still highly optimized and performant. This is what allowed us to replace Adobe AfterEffects with a custom browser-based renderer. We've seen a 10x performance improvement in some cases: 2mins (Browser) vs 20mins (AfterEffects).

wmwragg 29d ago

For the very basic of basic browser based text editors just use this as the URL: data:text/html, <html contenteditable>

jsrcout 28d ago
Nice! That's a new one for me.

kqp 29d ago

Seems to me that in the short term everybody screams “DO NOT OPTIMIZE THAT CODE”, in the medium term everybody shrugs “buy a new computer”, and in the long term everybody gradually migrates to the solutions that optimized that code. I think the mainstream narrative around performance optimization is simply wrong. Inefficiency isn’t a constant, it’s a percentage. You look at software that’s 10x as fast and say yours will run that well in 20 years, and it does, but by then the other guy is 100x as fast, the gap is actually wider, everybody’s doing things that take advantage of all that speed, and you’re either 20 years in the past, still dog slow, balancing the two, or given up. Your software stays bad, and it happens again if you wait again, forever. The idea that optimization matters less over time is short-term thinking. It’s not the end-all, of course. Other things matter, context matters, it’s possible to over-invest, it doesn’t matter if your execs can just force people to use it, many of us are genuinely only planning two years out, etc.

argee 29d ago
> The idea that optimization matters less over time is short-term thinking. The more you think about things and the deeper you investigate, the closer you get to realizing that most aphorisms, advice, and even "facts" are a combination of best-effort philosophy and selection biases from the lowest common denominator. Add in the Barnum effect and you end up with an ocean of inconsequential platitudes being parroted by every Tom, Dick, and Harry. It's very difficult, requires active effort, and goes against human nature to act rationally. Most people don't even want to do it.
ChrisRR 28d ago
In the longer term we regress and start running an entire web browser to run a text editor in javascript
coffeeindex 28d ago
Casey Muratori has an interesting talk about how that narrative (“premature optimization is the root of all evil”) came to the mainstream narrative https://youtu.be/hpj6r6CjJf8 https://youtu.be/hpj6r6CjJf8

mikewarot 29d ago

I was a student at Rose-Hulman back in 1981-83. Back then they had a tweaked out 11/70 running RSTS and supporting 144 terminals, and the new spiffy VAX 11/780 running VMS. I found an old 11/40 that had a memory issue to work on, and started learning machine code, etc. Somewhere along the line, I was infected with a love of TECO, a relic of an editor that was said to be the basis for EMACS. I wrote my own version out of nostalgia in 1991. I put it on Github a few years ago.[1] It's only in the past few months that I learned that the first versions of TECO were actually full screen editors, which floored me, as I had always assumed TECO stood for Tape Editor, Character Oriented.... and started with teletype terminals and paper tape. [1] https://github.com/mikewarot/teco https://github.com/mikewarot/teco

owenbrown 29d ago

Check out Quick Memory. It’s a stripped-down, faster Obsidian. All rust, not html. https://qm.venka.com https://qm.venka.com It’s small (zip < 7MB) and fast (launches in 300 ms, opens Moby Dick in < 300 ms). Ping me if you use and something is missing. It’s my daily note-taking app.

marssaxman 29d ago

"Fine, I'll build my own text editor" is certainly a familiar sentence, one I've uttered several times, but it would never in a thousand years occur to me to take the next step in a web browser. Interesting to see such a different approach to the world: thank you for sharing.

demibabs 29d ago

I never understood why people have an issue with VS Code

iLemming 27d ago
> why people have an issue with VS Code Indeed. Why people had any beef with: - Borland Turbo Pascal, Turbo C, Turbo C++, Turbo Assembler, Borland JBuilder - Visual Basic IDE, Visual SourceSafe, FrontPage - Dreamweaver, Brackets, TextMate, JetBrains Fleet, etc. It's totally okay to spend years investing in some proprietary editor, IDE, tool, whatever. Just learn how to learn them quickly and learn how to dump that knowledge with no regrets. Never develop muscle memory, never learn keyboard shortcuts, never build extensions. Who cares if you're using it efficiently or as if you just woke up to it this morning? By the time you try to get comfortable in any tool, it may vanish into obscurity or become something else. Do not, I implore you, do not learn Emacs or Vim. They both predate every product on this list and will outlast everything on it. You may eventually get comfortable and even start liking your job. Surely, you don't want to start getting paid for having fun?

c-smile 29d ago

Just in case... In Sciter I have three editing behaviors (element controllers) associated with these elements by defualt: * <textarea> - plain text editor working with single text node. * <htmlarea> - WYSIWYG editor working with a DOM tree. * <plaintext> - editor working with a list of <text> elements. Each <text> element is allowed to have only inline and inline-block subelements and text nodes [1]. <plaintext> is optimized to work as a source code editor. Local editing in one <text> element invalidates text layout of that only element but not the whole content as in case of <textarea>. All editors support ::highlight - to style fragments of text without the need to change underlying DOM. <plaintext> provides streaming API allowing to access content of the element as pure plain text but with methods to ::highlight ranges in it to minimize problems with encodings and mappings of text positions to corresponding node trees and making syntax highlighting simpler: See screenshot: https://sciter.com/wp-content/uploads/2026/09/plaintext-colorizer.jpg https://sciter.com/wp-content/uploads/2026/09/plaintext-colo... <htmlarea> and <plaintext> also support transactional updates allowing to make non-trivial DOM tree mutations undoable as a single operation. [1] behavior:plaintext - https://docs.sciter.com/docs/behaviors/behavior-plaintext https://docs.sciter.com/docs/behaviors/behavior-plaintext

othmanosx 29d ago

I was waiting for the punch line

NikhilChowdaryG 29d ago

[flagged]

xacky 27d ago

It's always yet another yext editor instead of helping get people off Adobe's subscription trap.