Svelte on ThunderBlaze's Blog

Zafkiel - An Anilist Client

Sun, 24 Aug 2025 00:17:05 +0530

Zafkiel - Building a Native Anilist Client with Svelte, Tauri, and Rust

Over the past few months, I’ve been working on a project very close to my heart: Zafkiel, a desktop anilist client built with Svelte, Tauri, and Rust. The goal has always been simple yet ambitious - to create a fast, lightweight, and customizable app for browsing and tracking anime, one that feels native, modern, and open to the community.

Zafkiel is at a stage where I can reflect on why I started it, the choices I made, and the direction it’s heading.

Why Zafkiel?

Existing anime tracking platforms and apps are powerful, but I often found them lacking in either performance, design flexibility, or openness. Many desktop clients are simply Electron wrappers, which work but can feel heavy and slow.

I was also inspired by the creative minds behind the creation of Dantotsu, an Android application for watching anime, reading manga and light novels with multi-sourcing, extensions for more features, etc. Sadly it was taken down recently by DMCA but many of its forks are still there. And I also came across a cross-platform Dantotsu (Dartotsu) but it was still in much development and it used flutter so the app was really slow and bad in performance.

That is why I decided to create my own client with the following features in mind:

Lightweight - fast startup and minimal resource usage.
Beautiful - a modern design with multiple themes, fully customizable.
Community Friendly - easy to modify, extend, and contribute to.
Cross-platform - consistent performance on Linux, Windows, and macOS.
Multi-Sourced - should have multiple sources and switching between them (I’ll expand on this further later).
Extensible - should provide features like extensions which can be installed or uninstalled.

That vision became Zafkiel - named after Kurumi Tokisaki’s angel in Date A Live (My favorite character btw from this Series), symbolizing control over time. It felt like the right metaphor for an app meant to give users control over their anime experience.

Choosing the Stack

Frontend: Svelte + Shadcn & Tweakcn

I chose Svelte for the frontend because of its speed, simplicity, reactivity, and developer experience. Unlike heavier frameworks, Svelte compiles away much of the overhead, leaving a lean and efficient app. This makes UI development faster and more intuitive, letting me focus on design and user experience.

To bring flexibility to the design, I integrated Shadcn & Tweakcn (Shadcn Themes), using which I enabled multi-theme functionality and consistent design. With it, users can seamlessly switch between themes, creating a personalized experience without bloated complexity in the codebase.

Backend: Rust + Tauri

For the backend, I went with Rust. Rust not only ensures safety and performance, but it also makes Zafkiel highly modular. The backend is structured in a way that keeps each part of the logic isolated, easy to read, and easy to extend.

This modularity has another major advantage: contributing is accessible to others. Developers can dive into specific parts of the codebase without needing to understand everything at once. Whether it’s improving caching, adding API integrations, or refining error handling, contributions are straightforward.

With Tauri acting as the bridge between the frontend and backend, the result is a native cross-platform application that consumes only a fraction of the resources of an Electron-based app, while maintaining strong security guarantees.

Multi Sourced Feature

This is yet to be implemented, I am planning to implement this along with the extensions. Multi-Sourced refers to the ability to choose between the providers of Anime/Manga. You must’ve heard of websites for watching anime like hianime, aniwatch, etc and even torrents too. I want to provide the user the ability to choose which source to watch from because of various factors:

It is not necessary for the site I am using to be available in the user’s region.
Some sites have reduced quality but lower size while other offers higher sizes but high quality.
There’s also the thing called hard subtitles (embedded in video) and soft subtitles (embedded in the file like mkv but not in the video).

Extensions

This multi-sourcing feature is planned to be enabled using these so called extensions. I want to provide each site as optional extensions as in Dantotsu. But extensions won’t stop there, they can provide more features such as torrenting, downloading, cli integrations and much more. I’ll be keeping the repository separate though because of DMCA. More and more sites can be added and easily integrated as extensions as all of them will follow the same structure and responses.

Current State

At the moment, Zafkiel is still in basic development.
Some core features are working, but it’s far from stable or feature-complete.

Right now, I’m focusing on:

Building out the core UI with Svelte and Tailwind.
Structuring the Rust backend for modularity and clean APIs (need to rework on this).
Refining how I use TanStack Query for AniList API calls.

It’s not something I can use daily yet, but the foundation is being laid carefully.
My approach is slow but steady - making sure I get the architecture right before layering on more features.

Looking Ahead

The roadmap for Zafkiel includes:

Polished UI/UX with multiple themes and smooth transitions (Yes, it needs more work).
Cross-platform support to ensure consistency on Linux, Windows, and macOS (Even android support is coming soon).
Multi-source streaming and reading support using extensions and also torrenting support.
Extensibility so contributors can add new features or integrations easily.
More components for streaming anime, reading manga, reading light novels, etc.
Documentation site (Yes, this is very important for contributors and even for users)

I’m not rushing this project - the goal is to build it right, not just fast.

Conclusion

Zafkiel is still a work in progress and there is a long way to go before it goes into production, but it represents my vision of what an anilist client should be: lightweight, customizable, and faster.

With Svelte powering the UI, Tweakcn providing theming flexibility, TanStack Query handling data-fetching experiments, and a modular Rust backend ensuring performance and stability, Zafkiel is slowly but surely becoming the client I’ve always wanted.

It’s not production-ready yet, but the journey has only just begun - and I’m excited to see where it goes from here.

Getting Started with Svelte 5 (and Why You Might Not Need React)

Sun, 24 Aug 2025 00:16:00 +0530

Getting Started with Svelte 5: Why It Feels Different from React

For most developers, the path into modern frontend development goes something like this: you learn a little HTML and CSS, sprinkle in some JavaScript, then get told that “if you want to be taken seriously, you need React.”

React has become the default. Its component-based structure, hook system, and virtual DOM reconciliation process have shaped the way millions of developers think about web interfaces. But that dominance also means many developers assume React’s structure is simply how frontend frameworks work.

Svelte - especially in its latest version, Svelte 5 - politely disagrees. Its structure, reactivity model, and approach to state management are designed around a compiler-first philosophy rather than a runtime-first philosophy. To really appreciate why that matters, let’s unpack what these frameworks are actually made of.

The Structure of a React Application

In React, an application is a tree of components, each represented by a function (or class, historically). Components return a description of UI in JSX, which React turns into a virtual DOM tree. Whenever state changes, React re-renders the component, compares the new virtual DOM with the old one, and applies minimal updates to the real DOM.

This means React’s structure has three major layers:

Component Functions - the building blocks, each describing what the UI should look like.
Hooks and State Management - useState, useReducer, useContext, and a host of third-party libraries that hold and manage application state.
Runtime Reconciliation - the virtual DOM diffing algorithm that determines how to update the actual DOM based on state changes.

The advantage of this structure is familiarity and flexibility: every piece is declarative, and React handles the mechanics of change. The disadvantage is weight. Every app ships React itself plus the runtime that makes reconciliation work, even if you are only building a simple counter.

The Structure of a Svelte 5 Application

Svelte flips the model. Instead of carrying a runtime into the browser, Svelte compiles components into plain JavaScript at build time. This alters the structure of an application in a fundamental way:

Components are still the unit of composition, but instead of returning virtual DOM, they are compiled into direct DOM operations. When you declare <button>{count}</button>, the compiler generates the exact DOM update instructions needed to increment the text when count changes.
Runes replace hooks. A rune like $state(0) declares state. A rune like $derived(expr) computes a value from other state. $effect(() => { ... }) defines what React would call a “side effect” - code that runs in response to data changes but doesn’t itself produce data for the UI. Importantly, because runes are compile-time hints, the compiler wires dependencies automatically.
Reactivity is not a runtime guessing game. In React, you declare dependencies manually in useEffect or useMemo. Forgetting or mis-declaring them is a common source of bugs. In Svelte, reactivity is fine-grained and explicit: if count is used inside $derived or $effect, the compiler knows exactly when to update.

This structure means a Svelte 5 application has no virtual DOM, no reconciliation layer, and significantly less runtime code. What ships to the browser is essentially optimized vanilla JavaScript customized for your component tree.

What is Reactivity ?

The term “reactivity” describes how a framework updates the UI when data changes.

In React, reactivity is powered by state and re-renders. You call setState, React re-runs the component, then the Virtual DOM decides what needs updating. This works well, but every change re-executes the component function, even if only one value changed.

In Svelte, reactivity is built into the compiler. Assigning to a variable (count++) directly updates only the DOM nodes that depend on it. No Virtual DOM, no component re-runs - just precise updates.

The difference is subtle but important: React reactivity is runtime-driven, while Svelte reactivity is compile-time optimized.

What Side Effects Actually Mean

The phrase “side effect” gets thrown around casually in frontend development, but let’s pin it down. A side effect is any action your code performs that reaches outside of its own scope and alters something external. Examples include logging to the console, updating localStorage, starting an interval timer, or making a network request.

In React, side effects live in useEffect. You declare dependencies, React runs the effect when they change, and you may return a cleanup function. In practice, this can be error-prone: forgetting dependencies leads to stale values, while adding too many creates unnecessary re-runs.

In Svelte 5, side effects live inside $effect. The difference is subtle but important: the compiler analyzes your effect and automatically tracks which values it depends on. You do not manually declare dependencies, so there is less room for mistakes. Moreover, because $effect is reserved only for side effects, not computations, it reduces the temptation to use it as a catch-all. Computed values belong in $derived, keeping data transformations pure and effects truly external.

State and Data Across the App

Both frameworks need a way to manage state across components. In React, this typically means useContext or an external state library like Redux, Zustand, etc. In Svelte, the answer is stores.

A store is simply a reactive object with a subscribe method. Svelte provides a small set out of the box:

writable: holds a value that can be updated.
readable: holds a value but can only be updated internally (useful for derived or system state).
derived: computes a new store based on others.

The compiler adds sugar: prefixing a store variable with $ inside a component automatically subscribes and unsubscribes it. That’s why you can write {$count} inside a template and get the live value.

The line between runes and stores is clear: runes are for local component state, stores are for shared global or cross-component state.

The Role of Data Loading

One area where SvelteKit - the application framework around Svelte - diverges sharply from React’s ecosystem is data loading. In React, data loading conventions vary by framework. Next.js, for example, uses server components, route handlers, and getServerSideProps or getStaticProps (depending on the version you’re working with). It’s powerful but can feel fragmented.

SvelteKit simplifies this with a single concept: the load function. Every route or layout can export a load function, which fetches or computes data before rendering. Crucially, there are two flavors:

+page.ts / +layout.ts: runs on both client and server, perfect for public data or anything that must survive client-side navigation.
+page.server.ts / +layout.server.ts: runs only on the server, ideal for accessing databases, filesystems, or secret environment variables.

This clear separation removes guesswork. When you read a SvelteKit codebase, you know exactly what runs on the server and what may run in the browser.

A Practical Comparison

Let’s compare two mental models.

React’s Model

Structure: components return virtual DOM, React runtime diffs and updates real DOM.
State: hooks manage local state; external libraries manage global state.
Side effects: useEffect runs external code, with manually declared dependencies.
Data loading: depends on framework, with patterns that vary between Next.js, Remix, and others.

Svelte 5’s Model

Structure: components compile into direct DOM operations; no runtime reconciliation layer.
State: runes ($state, $derived, $effect) handle local reactive state and side effects.
Shared state: stores (writable, readable, derived) provide reactive values across components.
Data loading: SvelteKit’s load functions, explicit and scoped to routes.

This difference in structure is not just academic. It changes the weight of the code you ship, the likelihood of bugs from dependency mismatches, and the mental overhead required to understand what your app is doing at any given time.

Why This Matters

Choosing between React and Svelte is not about loyalty, it’s about trade-offs. React gives you the safety of an enormous ecosystem, countless libraries, and a familiar structure used by millions of developers. Svelte 5 offers a compiler-driven model that produces smaller bundles, faster updates, and code that directly mirrors your mental model of reactivity.

If you want predictability, React is the well-traveled highway. If you want efficiency, simplicity, and a more expressive syntax, Svelte is the smaller, faster road that feels almost suspiciously smooth.

The real takeaway is not that one will “kill” the other - React’s ecosystem is too large for that. The takeaway is that Svelte offers a different structure, one where reactivity is explicit, side effects are cleanly separated, and the compiler takes on more of the work so the browser can do less.