JS API for add-ons

[abdnh]

With the most important Anki screens being moved to Svelte (#4289 #4029), it's probably time to discuss add-on compatibility.

The Svelte port as it is will break almost all add-ons that touch these screens but there'll be a transition period where both the old and new screens will be available 1 (as was the case for the Stats and Deck Options screen).

Anki mostly dodged the question of add-on support for screens transitioned to the web for ~6 years now because they were relatively low impact.
Now though with the most frequently used screens being rewritten, the approach of having old screens available for a few years is no longer enough, because the time will soon come when it's no longer practical to maintain both versions. Add-ons will then be left with no path forward if no new approach is offered.

We can at least implement a JS hooks API similar to the Python one.
Not every hook and use case can be supported in the new API, but we can get a pretty good idea about what add-ons need by surveying hooks usage in AnkiWeb add-ons.

[abdnh]

Maybe a more ambitious solution that tries to minimize breakages with little involvement from add-on authors is to keep Python hooks working via a compatibility layer where hooks are triggered from the JS side. To give an example using the reviewer_will_answer_card hook:

const [proceed, newEase] = await runHook('reviewer_will_answer_card', {ease, card});

runHook would be a Protobuf RPC that calls the corresponding Python hook from gui_hooks after doing any necessary type conversions.

It remains to be seen whether this is practical overall, but it looks like a good solution for very common hooks such as card_will_show.

[BrayanDSO]

For reference, AnkiDroid already has a JS API in the study screen.

There's also a new version, written in TypeScript, with a working PR that integrates it into the new study screen, browser previewer, and template previewer.

It was designed to be platform agnostic, so it could be used here and even in AnkiMobile (it's licensed under Apache-2.0).

[h0tp-ftw]

Thanks for the post, and I strongly support the RPC Compatibility Layer proposed by @abdnh.

A lot of the addons ecosystem relies heavily on Python/Qt hooks.
If we force a hard switch to a pure JS API (as suggested by @BrayanDSO), while cleaner/modern, it creates a massive barrier to entry. Many add-on developers are Python-first and may struggle rewriting their entire frontend in TypeScript. Could work but it will be a massive change of landscape for current addons.

Without a robust Python-to-JS bridge (runHook RPC), a lot of addons especially from newer, smaller addon devs may become much tougher.

[tatsumoto-ren]

The Svelte port as it is will break almost all add-ons that touch these screens

You are essentially proposing changes that will break existing add-ons, which I cannot support. On Android, Svelte may be appropriate because it allows for touch-friendly UIs. However, on desktop, Svelte is a terrible technology, inferior to Qt widgets. It slows down the UI, makes it harder to use, introduces noticeable lags, complicates the codebase, etc.

I propose removing Svelte code from Anki before it’s too late. At the very least, there should be an option to permanently disable those new UIs. There should be a way to completely opt out of them. The fact that Android can benefit from these changes doesn't mean that the desktop app will also benefit from them.

the time will soon come when it's no longer practical to maintain both versions

How about we transition to Qt widgets instead? The new svelte screens can be exclusive to AnkiDroid. For add-on developers, creating Qt widgets from Python code is easy, but juggling Python with JavaScript, HTML, CSS, and whatever the latest hyped frameworks are is considerably more complicated.

Honestly, the idea of having a transition period doesn't sit well with me because it implies the eventual removal of the old code. The current UI functions perfectly fine.

I think there are more important priorities than changing menus and buttons. For instance, improving the scheduler would be a better focus.

#4289 #4029

Regarding these PRs: since these changes negatively impact the user experience on desktop, it would be better to implement them in add-ons instead. This way, the core Anki app won't be affected.

Dae also suggests implementing changes in an add-on to keep the Anki app stable.

Additionally, Dae points that changes should be small to avoid significant disruptions.

---

Some posts for reference:

• Implement the editor in pure Qt #4142 (comment)
• Shift editor control to TypeScript #4029 (comment)
• Pending UI improvements #2313 (comment)

[abdnh]

I propose removing Svelte code from Anki before it’s too late.

It's already too late. Svelte now consists 11% of the codebase. Rewriting the editor alone is a significant undertaking with no clear benefits.

I'm not going to reply to the other points, as this topic has already been discussed to death.

The priorities under the new leadership haven't been decided yet. When the time comes to look into this again, I'm sure we can make use of the increased resources to do better for add-ons in terms of compatibility, APIs, and documentation to make the transition as smooth as possible while still improving Anki across all clients.

[tatsumoto-ren]

Svelte now consists 11% of the codebase.

If that code is left untouched, allowing only bug fixes, that will be good enough. At the very least, it will remain stable and prevent further issues.