Hey,
I have found it difficult to fix issues in citeproc-js due to the library’s internal structure. For citeproc-plus [1], I previously resorted to patching it externally to allow bundler tree-shaking to remove unnecessary components. However, using AI-assisted refactoring (Kimi K2.7 Code and DeepSeek V4 Pro/Flash), I have successfully restructured the project into citeproc-ts [2].
While I am aware that certain features may not yet work as expected and will require ongoing fixes (it is currently a 0.x.x release), it is now passing all tests. More importantly, the new structure allows me to handle most of these fixes myself.
I am also curious about what others are currently using for web-based implementations. Are people using citeproc-rs via WASM, or has the community moved toward something else entirely?
[1] GitHub - fiduswriter/citeproc-plus: Citeproc-js + citation styles bundled · GitHub
[2] fiduswriter/citeproc-ts: A TypeScript fork of citeproc-js - Codeberg.org
2 Likes
Very cool (though the demo seems awfully slow)! Does it also support the citeproc-js/CSL-M legal and multilingual extensions/styles?
As for your question, the project isn’t CSL, but my new Rust-based citum (repo) processor/system includes a WASM+TS binding.
This is on a pretty old laptop (in general, the engine is much faster on my much newer MBP from work), using the new stateful session API:
❯ bun scripts/benchmark-wasm-workflow.js --mode session
====================================================
Citum WASM: Word Processor Workflow Benchmark
====================================================
[Config] Style: styles/embedded/apa-7th.yaml
[Config] Source: local
[Config] Mode: session
[Config] References: 500
[Config] Citations: 100
[Config] Refresh: Every 20 citations
----------------------------------------------------
[Status] Style validated.
Simulating authoring workflow...
[Progress] Citation 1/100...
[Progress] Citation 10/100...
[Progress] Citation 20/100 | Bibliography read (0.56ms)
[Progress] Citation 30/100...
[Progress] Citation 40/100 | Bibliography read (0.20ms)
[Progress] Citation 50/100...
[Progress] Citation 60/100 | Bibliography read (0.32ms)
[Progress] Citation 70/100...
[Progress] Citation 80/100 | Bibliography read (0.30ms)
[Progress] Citation 90/100...
[Progress] Citation 100/100 | Bibliography read (0.97ms)
Simulation complete.
----------------------------------------------------
Performance Statistics (WASM)
----------------------------------------------------
insert_citation (incl. bibliography re-render): Avg: 11.73ms | P50: 11.44ms | P95: 17.25ms | P99: 28.72ms
get_bibliography (cached read): Avg: 0.47ms | P50: 0.32ms | P95: 0.97ms | P99: 0.97ms
Very interesting! This seems to do a lot of the same as what we initially built BiblioJSON for (support CSL and BibLaTeX, use EDTF for date strings, store data as JSON, etc.. previous name: biblatex-csl-converter). Now it contains a bunch more things relate dto converting citatons in docx files, prosemirror compatible JSON, etc. .
Had this been around around 2012, I’m sure we would have chosen it rather than citeproc-js. I can see from the repo that you intiially thought about making this CSL 2.0, but then decided against it. May I ask what is the reason for that is? It makes it a bit harder to switch to a new system if it’s not clear if it is to replace an older system or whether it is meant as an alternative.
A combination of a lack of apparent interest from the CSL community, and not wanting to be held back by compatibility requirements. E.g. I felt it would work better as a clean break, which I think is justified when you consider the basic design of CSL is now more than 20 years old.
Yes, there is strong inertia for CSL.
EDIT: the inertia cuts both ways though; it’s still unclear how to me how we evolve CSL, given the technical and organizational status quo.
1 Like