# TypeScript citeproc released **URL:** \ **Category:** CSL Development\ **Created:** [July 17, 2026, 2:02pm UTC](https://discourse.citationstyles.org/t/typescript-citeproc-released/2047 "2026-07-17T14:02:29Z")\ **Posts on this page:** 4\ **Page:** 1

**Author:** ![johanneswilm](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.citationstyles.org/johanneswilm/32/205_2.png) [@johanneswilm](https://discourse.citationstyles.org/u/johanneswilm)\ **Post date:** [July 17, 2026, 2:02pm UTC](https://discourse.citationstyles.org/t/typescript-citeproc-released/2047/1 "2026-07-17T14:02:29Z")

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](https://github.com/fiduswriter/citeproc-plus) [2] [fiduswriter/citeproc-ts: A TypeScript fork of citeproc-js - Codeberg.org](https://codeberg.org/fiduswriter/citeproc-ts) ---

**Author:** ![Bruce\_D\_Arcus1](https://avatars.discourse-cdn.com/v4/letter/b/4bbf92/32.png) [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)\ **Post date:** [July 20, 2026, 9:06pm UTC](https://discourse.citationstyles.org/t/typescript-citeproc-released/2047/2 "2026-07-20T21:06:20Z")

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](https://citum.org/) ([repo](https://github.com/citum/citum-core)) processor/system includes a WASM+TS binding. > **[@citum/engine - JSR](https://jsr.io/@citum/engine)** > > @citum/engine on JSR: Citum WASM and TypeScript bindings for citation processing. 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: ```sh ❯ 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 ``` ---

**Author:** ![johanneswilm](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.citationstyles.org/johanneswilm/32/205_2.png) [@johanneswilm](https://discourse.citationstyles.org/u/johanneswilm)\ **Post date:** [July 24, 2026, 12:51pm UTC](https://discourse.citationstyles.org/t/typescript-citeproc-released/2047/3 "2026-07-24T12:51:38Z")

> [@Bruce\_D\_Arcus1](#): > > As for your question, the project isn’t CSL, but my new Rust-based [citum](https://citum.org/) ([repo](https://github.com/citum/citum-core)) processor/system includes a WASM+TS binding. Very interesting! This seems to do a lot of the same as what we initially built[BiblioJSON](https://www.npmjs.com/package/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. ---

**Author:** ![Bruce\_D\_Arcus1](https://avatars.discourse-cdn.com/v4/letter/b/4bbf92/32.png) [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)\ **Post date:** [July 24, 2026, 1:51pm UTC](https://discourse.citationstyles.org/t/typescript-citeproc-released/2047/4 "2026-07-24T13:51:18Z")

> [@johanneswilm](#): > > 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? 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. > [@](#): > > 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. 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.