Huge announcement for my single favorite piece of open source software Anki. It's the flash card app that I used extensively while learning Japanese. The original developer, Damien, is changing the business model and partnering with AnkiHub which sells 3rd party Anki plugins and flash cards.
Right now the only monitization of the entire Anki project is the iOS app priced at $25, Apple taking $7. I was suprised to see that Anki is #3 currently on the entire iPhone for Paid Apps. It's easy to make fun of the state of mobile paid apps, but certaintly it's remarkably successful there. The website and Qt python cross platform desktop app are free. Not to mention server costs, free flash card hosting for any users (with images my database is over 5 gigs), etc. According to the post, it sounds like the biggest driver for this is to de-esclate the pressure of running everything from Damien (otsukare!), and expanding contributions to Anki. They also specifically called out UI improvements as a goal with more resources.
Anki's Browse Tab, showing my Japanese flashcards.
Sure, I wouldn't call this screen exactly following modern best UI design practices. As a tenured Anki user though I have hundreds of hours of muscle memory in this screen, so on first read I was very nervous about design changes. I knew AnkiHub as the med school Anki people, where am I in the language learning community. I'm worried if our more hacker DIY vibes in language learning are going to be left behind. At the same time, I'm starting to come around to welcoming change.
Last month, I walked a friend of mine learning English on how to use Anki, and it took me over an hour to go through all of the different tools and addons that I use to set the whole system up. She seemed really happy with it in the end, but I left that experience reminded my first time with Anki and how many different guides I had to comb through to settle into learning. Maybe there's some way to better integrate the wealth of 3rd part addons into a more seamless experience. As a developer, I wrote HTML to style my flash cards, scripts to automate new flash cards, and created PRs to improve the addons I was use. It was dare I say perfect for me, but I also want regular users have that feeling of freedom too. Anki is so great because you have so much power to control your own learning.
AnkiHub:
No enshittification. We’ve seen what happens when VC-backed companies acquire beloved tools. That’s not what this is. There are no investors involved, and we’re not here to extract value from something the community built together. Building in the right safeguards and processes to handle pressure without stifling necessary improvements is something we’re actively considering.
This research came out right as I’ve been thinking about how to improve my engineering skills. Pre-LLM I’ve relied primarly on personal projects to randomly give me usefull skills as I work through making my projects a reality. It's been quite successfull.
In 2025 however, I noticed my learning mindset slowly disappearing as AI tools can skip thinking straight to a final result. It's been easy to feel like I'm falling behind or getting rusty. Considering that all of my side projects last year extensively used agenticdevelopment, there may be some painful truth to that.
Anthropic tested junior coders with a example python project on a unknown to them library. Here’s what really caught my eye in the research:
On average, participants in the AI group finished about two minutes faster, although the difference was not statistically significant. There was, however, a significant difference in test scores: the AI group averaged 50% on the quiz, compared to 67% in the hand-coding group
Low-scoring interaction patterns:
AI delegation (n=4): Participants in this group wholly relied on AI to write code and complete the task. They completed the task the fastest and encountered few or no errors in the process.
High-scoring interaction patterns:
Generation-then-comprehension(n=2): Participants in this group first generated code and then manually copied or pasted the code into their work. After their code was generated, they asked the AI assistant follow-up questions to improve understanding. These participants were not particularly fast when using AI, but showed a higher level of understanding on the quiz. Interestingly, this approach looked nearly the same as that of the AI delegation group, except for the fact that they used AI to check their own understanding.
They talk about several different types of patterns then just these two, but these stuck out to me.
Takeaways for my own learning:
My biggest weakness that I've identified is “system design”. Therefore, I should not be letting AI decide my project architecture for me like I've been doing lately.
When code is generated that I don’t understand, make an effort to understand it right there or ask follow up questions. Not understanding = Not learning.
Outside of my core compenticies, it's likely just as fast to take more mental ownership over my work then floundering with prompt tweaking until X feature works.
Putting these into practice is easier said then done!
I was investigating an auth library today when I stumbled upon this syntax:
import { auth } from "@/lib/auth";
Which confused me, because I couldn't tell if it was a project path or a node module. Turns out this is a feature of TypeScript, which you can set up in your tsconfig.json like so:
This solution can help with cleaning up really long relative paths like I frequenctly see in Angular or React projects. It should also help when moving files around, that would otherwise break the relative imports.
// this:
import { SharedWidget } from '../../../../shared/widget';
// can become this:
import { SharedWidget } from '@/shared/widget';
Hey, an issue I've actually worked on before encountered in my real life! After a quick view source, sure enough, this website is using Google's Material Icons font. This is a web font that functionally works as an icon pack, similar to Microsoft Wingdings. The way it works is if you want to render the home icon, you write the word home and the font itself will render that sequence of characters as a home icon.
<span class="material-icons-outlined">home</span>
That's great and all, but what is the browser supposed to do if the font hasn't loaded yet? This is where the layout issue from the screenshot comes from. Before the material icons font is loaded, home is rendered with the browser's default font. You can see that in the screenshot with notifications_off and search.
This problem has a name: Flash of Unstyled Text (FOUT).
At my job we made extensive usage of Material Icons in our web apps so I've looked at many different proposed solutions to this problem before but everything comes up short.
When faced with a web font that has not yet loaded, the browser is faced with a dilemma: should it hold off on rendering text until the web font has arrived? Or should it render the text in a fallback font until the web font arrives?
...
font-display informs the browser how it should proceed with text rendering when the associated web font has not loaded. It's defined per font-face.
There are five possible values for font-display:
Value
Block period
Swap period
Auto
Varies by browser
Varies by browser
Block
2-3 seconds
Infinite
Swap
0ms
Infinite
Fallback
100ms
3 seconds
Optional
100ms
None
That screenshotted website is already using the font-display: block for the Material Icon font, but as demonstrated by my slow network conditions, 3 seconds wasn't enough here and I still saw the FOUT. There just isn't any way to force the browser to wait indefinitely until a font is downloaded before rendering. Browser authors could've done that, but it's intentionally limited to help users with slow connections see content.
Once the font is cached though, on subsequent page loads you don't see the behavior since the font is already loaded. So the FOUT on fonts is limited to first page loads typically.
Faster Downloads
Another optimization is to attack it from the file size end and shrink your payload by only sending the icons that are actually used in your app. Like the following:
From there you could download the font file it generates and add it to your app to self host your font. (Also generally a good idea so you won't be sending Google any extra referral data...)
While this does vastly cut down on the font's file size, thereby decreasing average load times, there's always a slower connection that could still see the flash.
What about code points?
If you don't like the layout-breaking long flash of a word like home, you can flash a instead. On the Material Icons page there's a unicode code point for each icon. Render that specific character with &#x****; and the chosen icon will render.
This mitigates the content flow issue since an entire word won't be rendered, which is good I guess, but you get this wierd box character instead. At best this idea is a sidegrade.
JavaScript Font Loading Detection
If you can use JavaScript to detect when a font is loaded, then you would be able to programmatically add CSS rules or classes based on the state of loading.
The FontFace API can load fonts and give a callback when the font is finished loading.
I'm positive this works, but it's a lot of complexity to add plus you have to juggle styling for icon loading before and after. For anyone looking for a permanent solution to FOUT, I'd spend my time here.
Don't give yourself this problem
For our apps, we didn't have font-display: block enabled yet, so that was an easy win that took the flash from happening essentially every non-cached page load to only for slow connections. Unfortunetly, since we had a system where we could swap icons at runtime, I was unable to implement the static font optimizations.
What I wanted to do though was not use a web font at all. Google has SVG icons available for download of every material icon, and you can simply download add them to your app from there. It's annoying to manage a lot of images, sure, but so is the issues that come from font icons. I think many people are still choosing the Material Icon font without giving a lot of thought to SVGs because Google has a lot of documentation about the fonts out there already, but I hope this post will convince some people to not worry about this and use SVGs instead.
Documenting this tool I found to convert SVGs to data URI data:image/svg+xml;base64,*** called svgviewer.dev. I actualy almost went to vibe coding first, but then sure enough a great tool was already out there.
And another cool thing I learned from this website is data URIs aren't limiting to base64 encoding. You can just paste the raw SVG directly into a data URI in a pinch.
