thomasnowhere

same here, it reads exactly the same whether the number is real or completely made up, so the confidence stops meaning anything.

This, pretty much exactly what I've been noticing too. Feel for the juniors though, its rough trying to learn when the tool in front of you can just spit the whole answer out. I still think they're worth it, but tbh I just don't have a good answer yet for how to actually use them well, maybe just takes time to figure that out.

The cost of writing code dropped but the cost of maintaining it didn't. If anything that makes saying no more important, not less.

One area where AI is reliably faster with no quality tradeoff is writing E2E tests. You can cover a ton of edge cases in an afternoon that you would normally skip, and if something breaks you see it immediately.

The never-resolving promise trick is clever but what caught me off guard is how clean the GC behavior is. Always assumed hanging promises would leak in long-lived apps but apparently not as long as you drop the references.

This looks nice. I work on a rich text editor and have a large Playwright test suite. The hardest bugs to catch are always the ones where a speciffic sequence of user actions leaves the editor in a broken state, things like formatting inside a merged table cell or pasting content mid-selection. You would never think to write a test for those combos manually.

Curious how well the action generators work with contenteditable elements though. Rich text editors have a lot of browser-level behavior that isn't just clicks and keypresses, things like IME input, drag and drop, clipboard events. Can you write custom action generators for that kind of stuff?

That makes sense, the hidden input approach is clever. Google Docs definitely proved it's viable at scale. The RTL support is a nice touch, that's notoriously tricky to get right.

Great work pulling this off in 10 months. Good luck with the project!

Impressive that you built the rendering layer from scratch on Canvas. Curious about one thing though, how do you handle accessibility? With contenteditable you get a lot of browser accessibility features for free (screen readers, selection, input methods). With Canvas rendering you'd need to reimplement most of that manually.

I've been working on a ProseMirror-based editor and the biggest lesson was how much the browser gives you for free with contenteditable, even though it's painful to work with. IME input handling alone took weeks to get right, and that's with the browser doing most of the heavy lifting. Starting from Canvas seems like an order of magnitude harder.

How's the IME/CJK input working? And does it play nice with browser spellcheck?