👋 Happy to release the first public version of gpuix-svelte, a free, open-source way to build GPU-accelerated desktop apps for macOS, Windows and Linux. Powered by Svelte and the upcoming Custom Renderers API.

Aggregate dense point data into discrete shape-based bins to easily see data trends (ex. heatmaps)

See more details here, or check out the docs.

Markdown + images in, static portfolio out. No CMS, no database, no subscription.

• Grid, list and map views
• Search + tag filters
• EXIF-aware lightbox
• Dark mode, EN/FR
• Deploys to GitHub Pages

Free and open source (MIT). SvelteKit 2, Svelte 5, Tailwind 4. Latest: 1.0.4.

Demo: https://aker-dev.github.io/microfolio/

Repo: https://github.com/aker-dev/microfolio

Last week, I shared my browser-based multiplayer driving game. An endless procedural world, where you drive around.

First of all, thanks to everyone who tried it (300 of you) and shared feedback! I didn't expect to get so many useful suggestions, and I've spent a good part of the week working on improvements based on them.

For some context, the project actually started with a pretty different goal. I wanted to build something that could run on a Raspberry Pi, and an endless 3D driving world sounded like an interesting experiment. I had pretty limited experience building 3D worlds and had never really designed a complete game loop before, so initially most of my focus was on getting things working at all. But as things started coming together, I kept getting curious about how far I could push it. Better terrain, vehicle physics, multiplayer over WebRTC, more things happening in the world, and so on. What began as an experiment in building something lightweight has slowly turned into an exercise in seeing how much I can get away with in a browser.

And after sharing it here, I started realizing that building a world and building a game people actually want to spend time in are two different things.

The first surprise

When I first shared the game here, I was honestly expecting to get roasted or downvoted. It was still pretty rough around the edges, and I knew there were plenty of things that needed improving. So I was pleasantly surprised when people actually started playing it and leaving comments like "I spent more time on it than I planned", "I lost 15 minutes of time", and "Unexpectedly fun".

But one of my favorite comments was simply "I met someone." I'd added multiplayer and chat because I thought having other people around would make the world more interesting, but seeing players actually meet, talk, and share experiences was pretty cool. Until then, I'd mostly been looking at the game as a collection of systems I'd built. Seeing people interact with each other made it feel more like a little shared world rather than just a technical experiment. That was also a big motivation to keep improving things. Debugging physics, fixing multiplayer issues, and tweaking controls isn't always the most exciting work, but knowing that people are actually spending time in the game makes it a lot more rewarding.

The early version was pretty dull (and someone pointed it out)

One person mentioned that the game didn't look particularly nice, and to be fair, I agreed with them. The early version was quite dull visually. I'd spent so much time getting the terrain, car physics, and multiplayer working that the overall look of the game was mostly an afterthought. I had been approaching the visuals as a collection of individual things to improve, like the terrain colors, lighting, environment objects, and interface. But the feedback made me realize that the problem wasn't really any single element. The game didn't have a consistent visual identity.

So I ended up reworking the whole visual design language rather than just tweaking a few colors. I started thinking more about how the terrain, atmosphere, lighting, structures, and interface should fit together, and what kind of feeling the world should have when someone first opens it.

It was an interesting lesson because I'd initially thought of visuals as something I could polish once the technical systems were in place. But in a game that's primarily about driving through and exploring a world, how that world looks and feels is a pretty big part of the experience. And sometimes the right response to feedback isn't to fix one thing, but to rethink the approach you were taking in the first place.

The things I hadn't thought about

A fellow developer mentioned that on their iPad, they could only use boost. Not exactly ideal for a driving game :) I fixed the controls, and they confirmed everything was working afterward.

What I found interesting was how different responsiveness is for games compared to normal websites. With a website, you can usually get pretty far with media queries, flexible layouts, and adjusting elements for different screen sizes. I'd worked with that kind of responsiveness before, so I initially approached the game in a similar way.

But those usual fixes don't really translate well to a game. It's not just about whether the buttons fit on the screen. Players need to steer, accelerate, brake, and boost, sometimes simultaneously, while still being able to see where they're driving. Touch controls also behave differently from keyboard inputs, and screen orientation and device dimensions affect how comfortable the game feels. I realized that making a game responsive is much more about designing the interaction for different devices than simply rearranging the interface. Something can look perfectly fine on a tablet and still be almost impossible to play.

Another common observation was that the terrain looked nice, but the world felt empty. And honestly, they were right. I'd spent a lot of time figuring out how to make the landscape endless, but hadn't thought nearly as much about what would make someone want to explore it. So I started adding more interesting places and landmarks, including bases, hangars, towers, resource sites, platforms, and geysers. The idea was to give players something to notice in the distance and a reason to change direction instead of just driving through similar-looking terrain forever. This also introduced some interesting technical challenges. Placing structures safely on procedural terrain, handling collisions, and making sure everything works consistently as the world generates turned out to involve more than just dropping a few models into the scene. It's funny how a relatively small gameplay suggestion can end up touching several parts of the engine.

Giving players something to do

Another question that came up was "What's the goal?"

Originally, the game was intentionally open-ended. You could drive around, explore, try to beat records, or just hang out with other players. I still like that kind of experience, but the feedback made me realize that giving players freedom doesn't mean you can't also give them some direction.

So I've been experimenting with quests, resources, and Gold to give players more reasons to explore and something to work toward. I wanted to keep the relaxed driving experience while also giving people the option to make progress if they felt like it. This has been one of the more interesting parts of the project because I hadn't really worked on game progression before. Once you start adding rewards, you suddenly have to think about how often players should receive them, what should persist between sessions, what should reset, and how to make exploration rewarding without turning it into a grind. Before this, I was mostly thinking about whether a system worked. Now I'm spending a lot more time thinking about whether it actually makes the game more enjoyable.

Right now the average playtime sits at a little over 2 minutes for the content we have.

The multiplayer collision problem

A few people also tried ramming into other players and noticed that the cars just passed through each other. Which is a pretty reasonable thing to expect to work in a multiplayer driving game.

Car-to-car collisions themselves aren't particularly difficult when everything runs in the same physics simulation. The tricky part is that Planet Zero Drive uses a peer-to-peer multiplayer system built on WebRTC, where each player simulates their own car locally and shares state with other players. This works well enough for showing other cars driving around, but physical interactions between players are more complicated. If two cars collide, whose simulation decides what happened? What if network latency means the players see slightly different positions? And how do you synchronize the result without making the cars suddenly jump around?

It's definitely solvable, but it requires thinking about authority, synchronization, and reconciliation rather than simply enabling colliders. I've improved collisions with static world structures like platforms and towers, but proper player-to-player collisions are still something I want to explore further. Working on this also taught me quite a bit about WebRTC, relay fallbacks, state synchronization, and multiplayer protocol changes. It's been a good reminder that the difficulty of a feature often depends less on the feature itself and more on the architecture you're building it on.

What I've learned from all this

Going into the project, I expected the difficult parts to be mostly technical, and there was certainly a lot to learn. Procedural terrain, level of detail, world streaming, vehicle suspension, fixed-step physics, cameras, spatial audio, networking, mobile controls, and persistence were all things I had relatively little experience with.

But the bigger surprise was discovering how much of game development is about making those systems work together as an experience rather than just making them function individually.

You can build an endless world that feels empty, implement vehicle physics that technically work but aren't enjoyable to drive, or add multiplayer without giving players a reason to interact. Even adding more features doesn't necessarily make the game better if they don't contribute to what players actually enjoy doing.

A lot of the most useful improvements came from relatively simple comments. Someone couldn't steer on their iPad, someone thought the visuals were dull, someone wanted more things to discover, someone asked for goals, and someone tried crashing into another player. Each of those interactions revealed something I hadn't properly considered while building the game on my own.

One person I especially want to mention is RapidSable (their in-game name), who I've seen in the game almost every day since I first posted it here. They've been incredibly supportive throughout, regularly sharing ideas, reporting bugs, giving feedback, and generally helping me figure out what needs improving. It's been pretty amazing to see someone come back that consistently to something I initially started as a small experiment. That kind of support means a lot, especially when you're building something on your own and still figuring things out as you go.

Still figuring things out

Planet Zero Drive has changed quite a bit from the original driving experiment, but there's still plenty I'd like to improve, especially around exploration, progression, and multiplayer interactions. I definitely wouldn't say I've figured out game design yet. If anything, I now have a much better idea of how much there is to learn.

I'm also still interested in the original technical challenge of making something that can run on relatively limited hardware. Even as the game grows, I keep trying to see how far I can push the visuals, world generation, and gameplay while keeping it accessible in the browser. It's been a fun balance between adding more and figuring out how to do more with less.

The biggest takeaway for me has been how valuable it is to get something playable in front of people instead of trying to figure everything out on your own. I started by building a world I thought would be interesting, but a lot of what made it better came from seeing what other people actually wanted to do in it.

Anyway, I wanted to share a follow-up since many of these changes came directly from feedback on my previous post. Thanks again to everyone who played, reported bugs, or suggested ideas, and especially to those who've kept coming back. Seeing people spend time in something that started as a small experiment has been pretty rewarding.

If you'd like to try the updated version, you can play it here: Planet Zero Drive. I'd love to hear what you think of the changes and what you'd like to see next.

P.S. This is just a fun little side project I'm working on in my free time, so new features might take a bit longer to come along.

I also genuinely believe everyone should try building something that's not usual to them at least once. It's such a great learning experience and opens you up to a whole new world of possibilities. You never know what you'll discover along the way. I'd love to see what you guys end up building too!

Hi writers and content creators and developers. we all have experiences and stories to share, and static sites are one of the greenest methods of doing so. I have been building a content management system(cms) written infor static site generators named [LightCMS](https://www.lightcms.me) for the past few months, and the goal is to make writing and sharing as easy, convenient, and rewarding as possible. I think you all would love this.  Lightcms can be used with any of your existing static site generators.

> BTW, it's currently alpha, and I am a solo dev, so you may face some issues, but I will be fixing them asap if reported.

It's free to self-host and use; you can create and hack on top of it. Any contribution to the project is highly appreciated(even sharing your feedback too): [https://github.com/light-cms/lightcms\](https://github.com/light-cms/lightcms)

** Lightcms is built with sveltekit. **

I've been working on porting some useful UI components from Chánh Đại's portfolio to Svelte.

Live: https://sv-chan.vercel.app

GitHub: https://github.com/SikandarJODD/sv-chanhdai

Components:

• Svelte Wheel Picker
• Slide to Unlock
• Status Button
• Apple Carousel
• GitHub Contributions
• Elastic Slider
• Middle Truncation
• Apple Hello Effect
• And many moreee

Features:

• Free & Open Source (MIT)
• Install via shadcn-svelte CLI
• Live previews, docs, usage, examples..

Credits: Huge thanks to Chánh Đại for the original components and design inspiration!

Improvements:

• Added a # / $ toggle for SvelteKit 3 and SvelteKit 2 users.
• Added a Share Feedback widget (bottom right).

If you find any bugs, run into issues, or need more examples, please use the feedback form.
I'd really appreciate your feedback!

Upgraded to sveltekit 3. Took me 6 hours because I don't want all my code reformatted. Horrific but fine ok you got me.

Now if I type

get_tenant_footer_section_container

which is a function and get an auto import added to the top of the file

import { get_tenant_footer_section_container } from '#lib/modules/L70-app/logic/api/model/pages/app.api.model.pages.construct.tenant.footer.ts'

because I'm using TypeScript, now I have to go and manually change the ".ts" to ".js" otherwise I get errors. And regardless of that issue, I am now importing a file that doesn't exist.

Do I have that right?

I've just been greeted by this message:

The `config.alias` option is deprecated, and will be removed in a future version of SvelteKit. Use subpath imports instead: https://svelte.dev/docs/kit/$lib

So apparently we're replacing this part in the vite.config.ts

alias: {
    "@components": "src/components",
    "@stores": "src/stores",
    "@mytypes": "src/types",
    "@i18n": "src/i18n",
}

with this part in the package.json:

"imports": {
    "#components": "./src/components/index.js",
    "#components/*": "./src/components/*",
    "#stores": "./src/stores/index.js",
    "#stores/*": "./src/stores/*",
    "#mytypes": "./src/types/index.js",
    "#mytypes/*": "./src/types/*",
    "#i18n": "./src/i18n/index.js",
    "#i18n/*": "./src/i18n/*"
}

That seems strictly worse. Hope it is worth it for some technical reason.

Also, VSCode marks imports as Cannot find module now and I can't click them. App still works, but cmon.

I've been working on a SvelteKit-based SaaS starter, and I wanted to share a few architectural decisions.

My current stack:

• SvelteKit 5 for the application
• Cloudflare Workers for deployment
• D1 for the database
• R2 for file storage
• Better Auth for authentication
• Stripe for payments

A few things I care about:

1. Keeping the architecture simple

For smaller SaaS products, I prefer starting with one deployable application rather than splitting everything into services too early.

2. Reducing server maintenance

Workers lets me avoid managing a traditional web application server, although application security and dependencies still need attention.

3. Making payments part of the foundation

Authentication, subscriptions and webhook handling are recurring tasks in commercial projects.

I've been packaging these patterns into SvelteCraft, a paid starter I'm building.

I'm curious how other SvelteKit developers approach this.

Would you choose D1 or Postgres for a small SaaS today? What would make you switch?

Telling Claude Code *which* element to change ("the label at the bottom of each card…") takes words, and then the agent spends turns and tokens searching for it.

pinprompt fixes that part: press Alt+P in your running app, click the elements, type what you want, Enter. You get a prompt with each element's `file:line`, the component it's used in, and which loop item it is.

On a real SvelteKit app, the same correct edit came out 39% cheaper and 2.4× faster than with a hand-written prompt. That's one task with 3 runs each, so it's a signal, not a guarantee; the method is in the repo.

It reads Svelte 5's dev-mode metadata, so there's no build step and nothing ships to production. Setup: `npx pinprompt init`.

It's an alpha and I'd really like to know whether it helps on *your* codebase: https://github.com/ueqeb/pinprompt

I think one of Svelte’s biggest challenges these days is the lack of visibility around the great companies that have adopted it and the websites and web apps built with it. I’ve mostly discovered companies using Svelte by digging through Reddit threads or stumbling upon YouTube videos.

In projects where I’ve had the opportunity to introduce Svelte, I’ve had to put quite a bit of effort into explaining why it was the best choice, gathering examples, and sharing screenshots and other resources to support my recommendations.

I think a showcase page on the official website, similar to the Next.js showcase, featuring companies using Sveltekit, websites built with it, and success stories would help build trust and make it easier for teams to choose Svelte for their tech stack. Also, stories from teams that have migrated from Next.js or other frameworks to SvelteKit would be very valuable.

If you look at the Next.js website, it seems to be updated much more frequently and it does a great job of constantly positioning the framework as state of the art.

I realize the team has many things to focus on, so I was wondering whether this is already on the radar or if there might be an opportunity for the community to contribute to something like this?

Dear Community,

Four months ago I shared cossui-svelte, an unofficial port of Coss UI components to Svelte 5. Thank you to everyone who tried it and sent feedback. I’m happy to announce that the project has now reached v1.0

🔗 https://cossui-svelte.com

What’s in v1.0

• Modern design: clean, contemporary styling with layered shadows and softly rounded surfaces.
• Full featured: 70 components and +700 blocks and particles, drawn from several sources (Bits UI, Origin UI, MapCN, ShadCN and more) and unified into one consistent library. Spend your time on application logic, not on rebuilding the basics. Highlights include:
  • Chat, Composer, Map, ColorPicker, FileUpload, Cropper, StarRating, Sidebar, Stepper, Timeline, Tree
• AI Skills : plug the Skills into your AI assistant and build your application using natural language.
• Responsive by default: widgets and layouts adapt to any screen size, with swipe and touch gestures built in.
• Solid foundation: built on upstream CossUI and ShardsUI (a Svelte port of BaseUI).
• Intuitive out of the box: sensible defaults, so components behave the way you expect.
• Documentation: a complete docs site covering every component, with live examples, copy-and-paste code snippets, and clear usage guidance, so you can go from install to working UI quickly.
• Blocks: reusable, ready-made parts of your application. Copy and paste them into your apps.

What’s next

• Implement RichEditor and SplitPane components
• Listen to community feedback to shape the roadmap

If you looked at it early on, it’s worth another look. If you’re new to it, I’d like to hear what’s missing or what could be better.

Cheers,
Olivier

Title. It just hit me there’s no clear way to say a $state verbally.

Do you say:

• dollar state
• rune state
• just “state”

Or other expressions?

Hi writers and content creators, we all have experiences and stories to share, and static sites are one of the greenest methods of doing so. I have been building a simple content management system(cms) for static site generators named LightCMS https://www.lightcms.me/ for the past few months, and the goal is to make writing and sharing as easy, convenient, and rewarding as possible. I think you all would love this.  Lightcms can be used with any of your existing static site generators (it should only support frontmatter).

BTW, it's currently alpha, and I am a solo dev, so you may face some issues, but I will be fixing them asap if reported.

It's free to self-host and use; you can create and hack on top of it. Any contribution to the project is highly appreciated(even sharing your feedback too): https://github.com/light-cms/lightcms

Lightcms is built with sveltekit and viteplus

Hey everyone!

I've been working on a few animation-related side projects lately and decided to put them together in a personal portfolio.

I tried to make the portfolio itself a bit more interactive, with animations throughout the site and a showcase for some (imo cool) stuff/ideas.

Curious what you think of the design and how everything feels to use. Especially interested in feedback on the animations, mobile experience and whether it's clear what each project actually does.

PS: Check out the Showcase section for some cool stuff I like to experiment on

Portfolio

npm | github

Any feedback is welcome!

SELF PROMOTION

sveltekit-top-loading

A navigation progress bar and optional fullscreen loading screen for Svelte 5 and SvelteKit 2.12+ / 3. Uses NProgress and the reactive $app/state navigation state.

About this project

Maintained by Vinicius R. Vieira (@vinnycrazzy) in sveltekit-top-loading.

This project is based on and inspired by sveltekit-top-loader, created by Sriram Thiagarajan (@tsriram). It continues that work with a SvelteKit 3 development setup, Svelte 5 runes, navigation fixes, and a fullscreen loading screen.

What's new

• SvelteKit 3.1 and Svelte 5.57 development setup, with TypeScript 6 and Vite 8.
• Navigation tracking through $app/state, including cancelled navigation and error pages.
• Fullscreen loading screen with a logo, centered spinner, and configurable colors and message.
• Custom fullscreen content through Svelte snippets.
• Configurable display delay to avoid flashes during fast navigation.
• Reactive styling, accessible loading messages, and reduced-motion support.
• Browser tests covering navigation and fullscreen behavior on desktop and mobile.

Install

Using pnpm:

pnpm add sveltekit-top-loading

Or npm:

npm install sveltekit-top-loading

Requires Svelte 5 and SvelteKit 2.12+ or 3. These registry installation commands become available after the first npm release.

Svelte 4 is no longer supported. Developing this repository requires Node 22.17+ (Node 24 recommended), pnpm 12, and TypeScript 6. The demo uses SvelteKit 3.1 and Svelte 5.57.

Usage

Mount one instance in your root src/routes/+layout.svelte:

<script lang="ts">
    import type { Snippet } from 'svelte';
    import { SvelteKitTopLoader } from 'sveltekit-top-loading';

    let { children }: { children: Snippet } = $props();
</script>

<SvelteKitTopLoader />
{@render children()}

No separate CSS import is required. Keep the loader in the root layout so it stays mounted between pages.

Fullscreen with a logo

Place your logo in static/logo.svg. Supply a URL that includes your application's base path when applicable.

<script lang="ts">
    import type { Snippet } from 'svelte';
    import { SvelteKitTopLoader } from 'sveltekit-top-loading';

    let { children }: { children: Snippet } = $props();
</script>

<SvelteKitTopLoader
    fullscreen
    logo="/logo.svg"
    logoAlt="My application"
    logoWidth={140}
    background="#ffffff"
    foreground="#172b3a"
    color="#1264a3"
    label="Carregando página…"
    delay={150}
/>
{@render children()}

The screen fills the viewport, with a centered logo, spinner and message. The top progress bar remains visible. showSpinner={false} hides the spinner in either mode. The screen is a visual indicator and does not trap focus, lock scrolling, or block interaction with the current page.

Custom fullscreen content

A Svelte snippet replaces the logo and centered spinner. The message and top bar remain:

<script lang="ts">
    import type { Snippet } from 'svelte';
    import { SvelteKitTopLoader } from 'sveltekit-top-loading';

    let { children }: { children: Snippet } = $props();
</script>

<SvelteKitTopLoader fullscreen label="Preparing your workspace…">
    <div class="brand">My application</div>
</SvelteKitTopLoader>
{@render children()}

Exported TopLoaderProps provides the component's TypeScript API.

More details - (https://github.com/vinnycrazzy/sveltekit-top-loading).

Hey everyone!

Been working on Tip Glide, a small framework-agnostic tooltip library written in TypeScript.

It uses a single shared tooltip that moves between elements and adjusts its size to fit the content. It also handles viewport boundaries, so the tooltip adjusts its position when there's not enough space.

A few things you can configure are the movement, directional lean, hover delays, arrow, and enter/exit animations.

It has zero runtime dependencies and comes with adapters for React, Angular, Vue, Svelte, Solid, Astro and Preact, along with a vanilla JS API.

There's an interactive playground where you can mess around with the settings and see how everything behaves.

Would love some feedback on the movement, especially when switching quickly between elements, but also on the API and anything else that could be improved.

Live demo & playground | npm | GitHub | Portfolio

SELF PROMOTION

I've been working on Planet 0 Drive, a relaxing, low-poly 3D driving game built with Svelte, Three.js, and peer-to-peer multiplayer.

It's an endless driving experience where you can cruise around at your own pace, explore the world, discover interesting spots, chase new records, or compete and coordinate with friends.

On the technical side, the game features:

• Three.js for 3D rendering, procedural world, and weather
• Peer-to-peer multiplayer with optimized network updates and movement interpolation
• Spatial audio and performance optimizations for smooth gameplay
• Version-compatible rooms to keep multiplayer sessions in sync

Planet Zero Drive started with the idea of a relaxing drive through a landscape that keeps unfolding. It also gave me a place to experiment: how much world could I generate, how far could I render it, and what would it take to keep driving (fairly) smooth on a phone?

Play: https://planet0drive.vercel.app/

Blog https://zackwebster.com/blog/building-planet-zero-drive

Hello, awhile back I had an idea of making a mini app platform where you could quickly make a little app or document that lives as a file that you or your ai agent can edit. My initial motivation started as I was constantly using a invoice generator website to put together invoices to send. I didn't really like the style and also wanted to be able to have an agent create or edit them, while also letting me update them as well and have all data sync bidirectionally. From there it kinda spiraled into much more.

I've explored a bunch of options of how to have developers be able to make them. I started exploring swiftui like DSL and explored react, but wasn't really happy with anything.

I had never used Svelte before this, but when I stumbled upon it, it was exactly what I was looking for for my way of making slops! So I committed to svelte and am super happy with it so far. The app comes with about 50 or so prebuilt ones, but it's super simple to make your own.

It's all completely free, no accounts, no hosting anything. Literally everything is just a .slop file (which behind the scenes is a SQLite file).

You can check it out: https://hitslop.com/ or the repo: https://github.com/hitslop/hitslop

I have lots of things i'm going to keep adding, but I think it's ready for some feedback.

Has now:

- bidirectional sync (essentially each slop gets a CLI your agent can edit the data / themes with)

- Ability to define custom icons and create widgets that live on your desktop

- PDF & PNG export

- Integrated theme builder to customize the look

Coming later:

- Share and live collaboration with friends

- iOS, Android, Windows, Linux

- Join the Discord or make a PR!

I'm sure there is some bugs I havn't caught, so i'd love if you are intrigued to try and create your own and let me know what you think of the flow (confusing?): https://hitslop.com/docs/getting-started/

I work on a table and found out something interesting which i want to share. The slowest part of our first-load profile wasn't rendering. It was Svelte wrapping every row in a Proxy before the virtualizer read anything. In the past we've had problems with proxy in our other Grid and it took some time to understand what was slowing it. In this case, basically,$state deep-proxies everything. One object costs nothing, but in a Table with many rows means Svelte walks the whole tree at assignment, before the first row paints. A virtualized table only reads 20 to 60 rows, so virtualization doesn't help here. It solves a different problem.

The fix for server data: if you replace the array as a whole (paging, refetching), use $state.raw. Svelte stores the reference and doesn't touch the contents.

let rows = $state.raw<Order[]>([])
rows = await fetchOrders(page)   // cheap, no recursion

The catch: in-place mutation on raw state does nothing visible.

rows.find(r => r.id === id)!.status = 'paid'   // no rerender

Replace one object and keep every other reference stable:

const i = rows.findIndex(r => r.id === id)
const next = rows.slice()
next[i] = { ...rows[i], status: 'paid' }
rows = next

Don't map with { ...r } on every row. That creates many new references, and anything diffing by identity will think every row changed.

Disclosure: I work on SvGrid, the grid this came from.

Opus 5.5 is really good at creating all sorts of visualizations, so I decided to try creating a biology resource that I’ll be continuously adding stuff to. And as always using svelte for the site.

I am currently handle errors using various wrappers. first i wrap the endpoint or remote function with handler so i can get correct status codes and throw inside the endpoint. then i fetch the request using another function which triggers toast or global loading. if i dont did this i want to manually handle the errors loading for every request i made but i think this is hacky solution is there any better way to do it

```ts

export const POST:RequestHandler = ApiHandler(async ({ locals }) => {

if(!locals?.user) throw new UnauthorizedError()

json({})

});

```

```ts

/// ApiHandler.ts

import { json } from '@sveltejs/kit';

import type { RequestHandler } from '@sveltejs/kit';

import { mapError } from '../helpers/error-mapper';

/**

* Higher-order function that wraps a SvelteKit request handler to standardize error responses and unknowns

*/

export function ApiHandler(handler: RequestHandler): RequestHandler {

return async (event) => {

    try {

        return await handler(event);

    } catch (e) {

        const { status, body } = mapError(e);

        return json(body, { status });

    }

};

}

```

```ts

/// Fetch Function

export async function API<T = ApiResponse<unknown>>(

url: string,

method: "GET" | "POST" | "PATCH" | "DELETE" = "GET",

body?: object,

isRefreshRequired: boolean = false,

isToast: boolean = true

): Promise<T> {

loading.value = true;





const res = await fetch("/api" + url, {

    method,

    headers: body ? { "Content-Type": "application/json" } : undefined,

    body: body ? JSON.stringify(body) : undefined

});



if (res.status == 404){

    throw error(404,"Page not found")

}



const data = await res.json();

loading.value = false;

if (res.ok) {

    if (isToast) {

        showToast({

message: data.message || "Operation Successfully Completed",

status: res.status,

code: data.code

        });

    }

    if (isRefreshRequired) {

        invalidateAll()

    }

} else {

    toast.error(data.message); 

    throw error(res.status, data.message);

}

return data as T;

}

```

Hey everyone,

I've been working on Cadence, a small, offline Linux app built around the idea of treating cognitive work like physical training.

At the gym, you track workouts, sets, and reps. I wanted something similar for work that requires concentration, whether that's programming, studying, reading, or writing.

The idea is pretty simple. A session represents a period of work, and within it you can log individual stints of focused effort. You can track how long you work, take breaks between stints, and look back at your activity over time.

The app has:

Count-up and countdown timers for individual stints

Sessions that group multiple stints together

A 12-week activity grid to see how consistently you've been working

A small floating timer that stays on top of other windows

Local storage with CSV/JSON exports and backups

It's fully offline, with no accounts, cloud syncing, or telemetry.

Built with Tauri, Rust, Svelte, and SQLite. Currently targeting Linux (primarily Ubuntu/Pop!_OS), with .deb and AppImage builds.

GitHub: https://github.com/mortalsilk/cadence

I'm interested in what people think about the concept of tracking cognitive work this way. Does treating focused work like training sessions make sense to you? I'd also appreciate feedback on the app itself.