Passing languages list into CodeMirror plugin causes extreme lag

[MrDiamondDog]

Title. When I input the languages list from @codemirror/language-data, everything works as expected and the languages selector is filled out, but the markdown editor is slow. Typing anything takes a while before it shows up. I'm a bit confused as this is what the documentation says to do. I would be fine with removing the languages list, but I would like to use the languages selector. Has anyone else experienced this issue?

codeMirrorPlugin({
    codeBlockLanguages: languages,
})

[daveshenal]

Edit: this analysis was incorrect...

You're not doing anything wrong, and this is a known pattern, not just you. Here's what's almost certainly going on, and what to do about it.

Why it lags: the docs do show codeMirrorPlugin({ codeBlockLanguages: languages }) from @codemirror/language-data as a valid shortcut, but that array has ~200 full LanguageDescription entries (each with its own alias list, extensions, and dynamic import loader) - a very different workload from the simple { js: 'JavaScript', css: 'CSS' } object map most examples use. There's an existing discussion (#896) confirming @codemirror/language-data already causes excessive bundling/chunk overhead in this plugin even when unused, and a separate, currently unresolved issue (#839, related to a previously "closed - not planned" #685) about the editor getting noticeably slower while typing in general. Passing the entire language-data array is the kind of thing that would make whichever per-keystroke language resolution/auto-load logic is already strained, work significantly harder - which lines up exactly with what you're seeing.

Fix that keeps your language selector: don't pass the whole languages array - pass a curated subset using the same array format (it's explicitly supported and keeps aliases working):

import { javascript } from '@codemirror/lang-javascript'
import { python } from '@codemirror/lang-python'
// ...only the languages you actually need

codeMirrorPlugin({
  codeBlockLanguages: [
    { name: 'JavaScript', alias: ['js', 'javascript'] },
    { name: 'Python', alias: ['py', 'python'] },
    { name: 'CSS', alias: ['css'] },
    // etc - just the ones your users actually use
  ],
})

This still gives you a proper language-selector dropdown - just scoped to the handful of languages you actually support instead of all ~200 CodeMirror knows about. Most people don't need more than 10-20 in practice.

If you trim it down and the lag is still there even with a short list, that points to the broader, already tracked typing performance issue (#839) rather than this specific list - worth adding a comment there with your repro details either way, since the maintainers were specifically asking to understand the real world severity of it.

[MrDiamondDog]

This does not solve the problem. I want to use the whole array. If I were to use a subset it would still be pretty large and still cause lag. Please do not just plug my question into AI next time and actually answer the question.

[daveshenal]

I tried to reproduce this on editor v4.0.4 and 3.55.0 with the full languages array but couldn't get the typing lag to show up in either dev or prd, even with a large document containing many code blocks.

That said, I did confirm a related issue: the bundle output is identical whether you pass the full languages array or a minimal object like ts and js. The editor always generates 100+ language chunks regardless, which suggests the import is unconditional inside the plugin itself. This is tracked in #896.

@MrDiamondDog could you share your editor and language-data versions? Its possible the lag is version specific or depends on something else in your setup...

[MrDiamondDog]

Both versions are latest. I messed around with my setup some and the presence of an onChange handler on the editor seems to cause all of the lag. Even just setting it to a setter function from a useState causes the lag. There aren't any useEffects that are triggered in my code by this either. Are you able to recreate this?

[petyosi]

@MrDiamondDog from what you're saying, most likely you're refreshing the entire component setup on each keystroke. You can probably reproduce this in stackblitz/sandbox.

[daveshenal]

@petyosi exactly. @MrDiamondDog I was able to reproduce it with a minimal vite app.

onChange + small language object -> smooth
onChange + ~100 manually created languages -> lag
onChange + full codemirror/language-data languages -> lag
no onChange + full languages -> smooth

StackBlitz reproduction

[MrDiamondDog]

Thank you guys! I'll probably just switch to an auto-save interval in that case (which is what I should've done in the first place)

[petyosi]

To clarify: in general, the component is not meant to be used in a controlled way (this has a lot of performance implications). Re-passing value on each keystroke causes a lot of churn.

[MrDiamondDog]

That makes sense. I'd suggest adding that in the documentation in this section, as it can be a little misleading to new users as it is currently written. If you want, I'll open a PR for it.