top | item 46947229

Show HN: JavaScript-first, open-source WYSIWYG DOCX editor

130 points| thisisjedr | 20 days ago |github.com

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.

44 comments

order

_the_inflator|19 days ago

Someone has to do it:

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.

illright|18 days ago

I disagree that this submission has no value at all or that it should be auto-banned — there is a difference between thoughtless vibe-coding and spec-driven coding, guarded by tests. It seems from the next thread that this project is hopelessly outmatched by the sheer complexity of taking on something as the Docx spec, but this project has value, and for someone, it may be all that they need.

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

efilife|19 days ago

Seconded. I could ask the LLM myself and see what it comes up with in 5 minutes, not to mention that all of this was done 1000 times already so I have no interest of doing so.

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)

ramon156|19 days ago

At this point I agree, this is brogramming and its getting boring.

lelanthran|19 days ago

The real tragedy is that I can only give a single upvote. This post needs to be added to the HN guidelines, I feel.

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.

mediumdeviation|19 days ago

Ah these poor fools. Having built this exact product (OOXML compatible editor in React) before, it took all of two minutes to find a bug. The issue is that the OOXML spec is not in fact definitive - Word is, and trying to implement it from the spec will produce something that works maybe 80% of the time then fall over completely when you hit one of hundreds of minor, undocumented edge cases. Assuming of course that CC did not just hallucinate something. And then there's the more fundamental problem that HTML/CSS has unresolvable incompatibilities with OOXML. This is why Google Docs for instance use canvas for rendering.

jimjimjim|19 days ago

I feel your pain. PDF applications have the same problem. The thousand page PDF spec isn't actually the spec, Acrobat is the spec.

Tade0|19 days ago

When I saw the title I couldn't help but ask myself: how?

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.

thisisjedr|19 days ago

Fair point, we know the editor isn't yet 1:1 with Word. When you built yours, was Word your source of truth (reverse-engineering sense), or did you stick to MS-OE376? And any recommended process for systematically uncovering those undocumented edge cases?

nayroclade|19 days ago

When you built this exact product, how long did it take you to reach 80% compatibility?

KellyCriterion|18 days ago

Arent there any commercial libraries available already?

Somehow this reminds me of PDF

bonesss|19 days ago

> As an experiment

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.

lelanthran|19 days ago

I agree with everything in this comment - FWIW, I was on the standards bodies in my country in 2008/2009 to establish a national standard for word processing documents.

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.

ryanackley|19 days ago

How far can Claude can take this beyond a cool demo.

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.

creata|19 days ago

Two very minor suggestions for the demo:

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.

chromehearts|19 days ago

There is HugeRTE, a fork of tinymce. I don't know how long they searched for a tinymce alternative

ofway|18 days ago

Is there any good open source that actually work with web docx editing ?

lewisjoe|19 days ago

Excellent work! To put out the importance of the project - as of today there is not many google docs/word online alternative that is completely open source.

I'm yet to dig the code on how pagination is implemented but if the page breaks mimick word's - this is huge!

pipeline_peak|19 days ago

So it’s like Google Docs? What am I looking at exactly?

thisisjedr|19 days ago

Yes, it's like Google Docs for .docx files. It's open-source, MIT-licensed, and runs fully in JS, so you can embed it in your app.

Every other JS DOCX editor I found was either abandoned or commercial. I couldn't find a solid MIT-licensed option.

arxari|19 days ago

More vibe coded slop on Show HN

wouterjanl|19 days ago

Thank you for sharing this and making it open source! I appreciate that when clicking the link you end up immediately in the tool. I saved it. This surely will be useful at some point.

tkel|19 days ago

ai slop

chenmx|19 days ago

[deleted]

girvo|19 days ago

> Curious how you handled the undocumented Word behaviors that deviate from the spec.

That’s the neat part: they didn’t!

aitchnyu|19 days ago

I would have liked to see the feedback loop and harness instead of the end product. 12 years back, I was opening the 12000 page ECMA OOXML format and also reverse engineering Word's output (half my time spent from undocumented crap) and having "unit tests" to generate Docs which I had to check by eye.