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.
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
éĺ
ăăăăă
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