Anki's Svelte future

Is the future of Anki to have all of its UI in Svelte?

That means full cross-platform compatibility between Desktop, iOS and Android and possibly to remove all of the Python code.

3 Likes

I’d like to see more screens using Svelte and less using Python+constructing HTML using strings, but it’s going to be a gradual process, and migrating some of the important screens like the reviewer and browser is going to take a lot of work.

We’re still also going to need some platform-specific functionality for things that aren’t possible in HTML.

4 Likes

The best future of Anki would be to remove the existing Svelte screens and opt for Qt Widgets and/or Qt Quick exclusively because Svelte introduces unnecessary complexity and significantly impacts performance, slowing everything down. Additionally, many agree that it looks ridiculous when a technology meant to be used in a web browser in forced into a program for desktops.

I think it’s also would be nice to get rid of the HTML constructed using strings and replace that with Qt widgets.

1 Like

Would that also mean getting rid of designing our cards with HTML, JavaScript and CSS?
Because if so, I don’t agree with your position. We would lose a lot of freedom with this. And getting into python just to design your cards efficiently would be something completely different, than picking up a little bit of HTML and CSS.

I mean, yeah. I can see your point with “technology meant to be used in a web browser being forced into a program for desktops”. But isn’t this already common practice, even for really big companys? I remember Steam being a really good example for this. Basically a big part of it is a customized browser running with php, JavaScript and HTML. And Steam is being used by several million people.

These things are independent from the screens that dae mentioned. The main ones are the main screen, deck overview, card/note browser, deck options, statistics. Just a few years ago they weren’t made using Svelte so it’s possible to simply revert those changes.

If you still remember Anki 2.0 or the first versions of 2.1, you probably understand why it was so much better. If not, try running them just for fun.

1 Like

Yes, some popular applications are built with Electron (or something similar), but those programs are a nightmare to run because they eat a lot of memory and are very slow. So, even if it is a common practice, it’s not a good practice.

1 Like

達元さん。。。:person_kneeling:t4:

2 Likes

Tatsumoto has made the same arguments on GitHub before as well, and I disagree with his conclusions. Interested parties can read this issue, though I think there was probably at least one other issue/PR that I can’t currently find.

2 Likes

Anki as a cross-platform PWA would be really cool. But I’m not sure if Svelte is good for this purpose.

Doesn’t that break down more to a “perspective”-oriented discussion?
One could argue that memory and performance is the peak target for every application which is being developed.

On the other hand people could say, that memory perfomance in our current lifetime is not a huge problem anymore. I can’t imagine Anki taking 2GB of RAM and 70% CPU Power just to run, just because it’s using Svelte. What would it take? Maybe a few MB of RAM more than with a pure Qt UI?
RAM is getting cheaper and cheaper and our technology is advancing more and more. Also: The popular applications we are talking about are usually not “very slow” in my opinion.

You also have to differentiate between the meaning of “slow” to a developer and a consumer. The consumer won’t notice something being too “slow”, just because it maybe takes 0.5 seconds or 1 second delay to boot up.
I seriously cannot imagine Svelte making everything super slow and taking up to 20-30 seconds to load. (Even if there would be such things appearing while in close development, I am sure the core developers of Anki will somehow make something happen, so it will work more efficiently).
The use case of Anki is learning, not some 3D-Rendering of super complex geometry.

In the end, just because it isn’t good practice in your opinion (and maybe other developers), doesn’t mean, it can’t be still effective. If it fits the use case, then why shouldn’t we adopt Svelte?

I am gonna take a (mere) 2 second delay for a boot up and maybe even a 0.05 second delay for the switch from one card to another card. It’s still gonna successfully fulfill the use case and I am not gonna be mad about it (I won’t notice this anyway).

It’s up to Dae to decide if incorporating more Svelte is a wise decision. I just think it’s not the optimal tool for the job. Developing a desktop app with Svelte feels like commuting to work in a hovercraft instead of a regular car. It may function on a road, but the overall experience is poor. There are better technologies available for creating GUI applications on the desktop, primarily GTK and Qt. I’ve mentioned this previously on GitHub a couple times.

The primary argument for the current approach is the ability to share code between the desktop and mobile versions. However, this often results in bad user experience across all platforms, where it would be better to refine at least one platform.

Every Qt and gtk program I’ve installed launches instantly. Surprisingly, even Firefox starts up quicker than Anki on my desktop. The most frustrating aspect for me is the noticeable delay when switching between the reviewer screen and the main screen (by pressing s s d).

Another thing is that every time there’s a significant change in the UI (like the one Matthias proposed but thankfully didn’t submit), it absolutely destroys existing add-ons, and I’d prefer to have all add-ons functioning properly.

2 Likes

You are saying there are better ways to do that?

@BrayanDSO As dae says the plan is to have more screens running with Svelte. So will we see even the card/note browser screen (that David is working on now) from Anki Desktop?

No idea, actually, I guess it’s between Svelte and React.

GTK was a mess on everything except for Linux. Not sure if it still is. Qt is the only dependency of Anki that falls under GPL, unless I am mistaken. Would be good if the whole project could fall back to a more permissive license. Plus I personally support dumping Qt out of spite; very annoying setup process.

There is this project which aims to combine Rust + JS (would work nicely with Svelte/SvelteKit) as an alternative to Electron which is known to be slow and heavy

A list of alternative to Qt, GTK, and Electron: awesome-electron-alternatives

1 Like

Good to hear that.

The reasoning of my question is mostly to know where to put efforts, specially in AnkiDroid since it has a fair amount of Android native code.

Making things as much cross-platform as possible is the best move to reduce maintenance cost, especially in the open source world where developers’ time is scarce.

Web add-ons are still immature, but they also should be able to be cross-platform thanks to the Web UI (How to make web pages extensible by add-ons? · Issue #3187 · ankitects/anki · GitHub).

From what I see about the current rhythm of Anki, migrating the whole UI to Svelte will take many years, so AnkiDroid’s current work isn’t a complete waste of time.


We’re still also going to need some platform-specific functionality for things that aren’t possible in HTML.

Yeah, some minimal platform-specific code will be necessary, but moving most things to Rust/Js should be possible

Something like Tauri seems the ideal way to reach that. And it’s going to be even more mature when Anki is finally able to try doing a migration.


About moving back to Qt, just downgrade or create your own project. This is open source after all.

1 Like

I think something that should be emphasized are the Svelte tests. Taking a quick look at them as they are right now, they seem to be awfully focused on implementation details.
Anki’s frontend revamp should be focused on creating better UI/UX. I think dropping Qt is a good step towards that.

1 Like

“dropping Qt” is a horrible idea because all existing add-ons use Qt widgets.

Before Svelte was put in Anki, the UI was a lot better, that’s for sure.

3 Likes

I mean, if a change like that was to happen, then a compatibility layer for addons would probably be maintained for a while until most are back on track.

1 Like

A dumb question:
Have we considered separating Anki to anki-core (which compiles on all platforms, providing (REST) APIs of all functions) and anki-ui-qt, anki-ui-android, anki-ui-ios, anki-ui-web, etc. (which can be Qt, or any platform native UI calling anki-core APIs)?

2 Likes