We needed a JS-first WYSIWYG DOCX editor and couldn't find a solid OSS option, most were either commercial or abandoned. As an experiment, we gave Claude Code the OOXML spec, a concrete editor architecture, and a Playwright-based test suite. The agent iterated in a (Ralph) loop over a few nights and produced a working editor from scratch. Core text editing works today. Tables and images are functional but still incomplete. MIT licensed. |
Please auto-ban any "We gave Claude/Gemini/Grok/OpenAO/Qwen/Mistral/WhateverLLMAI the spec and..."
"and..." resolves to:
- "and now we have this impressive result you won't believe!"
100% of the time this is attention seeking, live debugging - no value at all.
Don't waste people's time. Any sound and reasonable story about results without misusing the public's eye is welcome, for example:
- One year after - 10 hard problems we found - extensive pro/contra comparison with other solutions - maintaining such a AI app for one year
Otherwise: please auto-ban.
However, I do agree with your point about live debugging. In light of that, I prefer to treat this submission as a curiosity about current model capabilities, and let the authors keep improving this project if they find it worth their time.
Let's be more respectful to the differing goals of people
Also, it's effortless. Not interesting at all if you can't share any insight about the project, because you don't know how it works under the hood and how many architectural problems were solved (or not)
Is it back? I remember 2011 it had a high time in an ad agency I was working back then :-D
We are being overwhelmed with slop. Not even original slop, but carefully specced slop that poorly replicates some existing functionality, but as a SaaS.
This is the 90s equivalent of "Doing $FOO, but on the internet", only it's "Copying $FOO, but with added costs as a SaaS".
That it is AI is just another black mark against it.
The spec is over 5000 pages long - no way in hell a human could parse this in a reasonable timeframe and no agent today has nearly the necessary context.
EDIT: also, like you said: the spec is secondary to the implementation and was only published (and not even in complete form originally!) because Microsoft was asked by the EU to do that.
FWIW the bug I found is that your comment parser assumes the w:date attribute represents a useful timestamp of when comments are made. It does not - a bug in Word causes it to save it as ISO8601 local time but _without timezone_, rendering it useless if more than one user across different timezone edits the document. Instead, you need to cross reference the comment with a newer comment part and find a dateUtc attribute. The above is, of course, completely undocumented.
Honest question: when the formal spec isn't really a spec how do you even measure "80% compatibility"?
For now, we mostly rely on testing with our own and customer docs. In practice, we were seeing solid results after a couple of days of keeping Claude working in the loop and giving lots of feedback: .docx files along with screenshots annotated to highlight what didn’t work.
Somehow this reminds me of PDF
The threshold for caring about experiments is exponentially higher in 2026 thanks to half baked vibe slop.
Non-functioning software and demoware comes fast and cheap, regardless of author.
> we gave Claude Code the OOXML spec
Having used the former a lot and read the latter in detail, uhhh…
Trim down the claims here, clarify the editor subset you plan to be supporting, and map the “last 90%”’s to honestly reflect the product you are pushing.
If “tables” and “images” aren’t there I’m quite skeptical about content controls and other key OOXML constructs being addressed meaningfully. The full OOXML footprint chokes OpenOffice out of procurements, rich OOXML documents choke half-way-there implementations (which was the whole point of the format).
As is pointed out elsewhere in the thread - there are fundamental constraints that have kept Google, Apple, and others from pursuing this route. Relatively simple docs are one thing, but OOXML is full of dragons and parity with Word has eluded more than a few tech giants.
We debated the OOXML spec in as much detail as time allowed, but we still didn't get through the entire behemoth of a thing.
ISTR that Microsoft representatives were also on the same subcommittee, and, but the MS rep was pushing very hard indeed to standardise on OOXML.
Too bad the OOXML format, itself, has MS-proprietary binary blobs built into the specification as part of the format.
ISTR we submitted a recommendation of standardising on ODF.
Does it become exponentially harder to add the missing features or can you add everything else you need in another two days? I'm guessing the former but would be interested to see what happens.
Are you going to continue trying? I ask because it's only been two days and you're already on Show HN. It seems like if you waited for it to be more complete, it would have been more impressive.
1. I don't know what the "Docxtemplater" button does, but it eats my document without warning and that's annoying.
2. It would be nice if the page came with some example .docx files we could see it work on.
I'm yet to dig the code on how pagination is implemented but if the page breaks mimick word's - this is huge!
Every other JS DOCX editor I found was either abandoned or commercial. I couldn't find a solid MIT-licensed option.
Also
>p.p.s don't miss out on free lifetime access
>Join thousands getting premium insights delivered weekly.
There’s stuff like diagrams.net, but that’s not compatible.