DEV Community: Bishwas Bhandari

YouTube Mass Unsubscribe: My Brother Vibe Coded It in Class 11, I Refined It for Production

Bishwas Bhandari — Mon, 23 Feb 2026 05:28:31 +0000

My brother is 17 and in Class 11. He doesn't know what a REST endpoint is. He's never opened DevTools on purpose. Last month he built a Chrome extension that unsubscribes you from YouTube channels in bulk, and it worked.

And it worked. It actually worked. He wanted to nuke his entire subscription list. 300+ channels accumulated over years of binge-watching gaming walkthroughs, tech reviews, and random stuff the algorithm tricked him into subscribing to at 2am. His feed had become completely unusable. Every time he opened YouTube, it was wall-to-wall content from channels he didn't even remember subscribing to.

YouTube's solution? Click a channel. Click unsubscribe. Confirm. Go back. Scroll. Repeat. For 300 channels, that's close to a thousand clicks and an hour of mind-numbing repetition. He wasn't going to do that. So he decided to build something instead.

He opened Claude Code, described what he wanted in plain English, and started prompting his way through a Chrome extension from scratch. No tutorial. No roadmap. No "learn Chrome Extensions in 30 days" course. Just a kid with a problem and an AI editor willing to help him figure it out.

That's vibe coding. And I think it represents something genuinely new.

The DOM Clicking Approach

His first version required you to visit youtube.com/feed/channels, YouTube's subscription management page that lists every channel you're subscribed to. From there, the extension would scrape each channel element off the page, find the unsubscribe button, click it programmatically, confirm the modal, wait for the page to update, then move on to the next one. One channel at a time, clicking through the DOM like a very patient robot.

It was slow. It was fragile. YouTube changes their DOM structure between A/B tests and his selectors would break randomly. Sometimes the confirmation modal wouldn't appear fast enough and the script would click behind it. Sometimes YouTube's lazy loading wouldn't trigger and the extension would run out of channels to process halfway down the page.

But here's the thing. None of that mattered. He wasn't building a product. He was solving a problem. And the DOM clicking approach, janky as it was, successfully unsubscribed him from 200+ channels in about 40 minutes. Compare that to the 2+ hours of manual clicking he was facing.

I'm genuinely proud of him for this. A 17-year-old in Class 11 with no formal programming background shipped a functional Chrome extension in an afternoon. Not a to-do app. Not a calculator. A browser extension that scrapes and interacts with one of the most complex web applications on the planet. He figured out content scripts, manifest permissions, DOM traversal, async timing. Concepts that trip up junior developers. The AI helped him through each wall as he hit it. That's the part people miss when they dismiss vibe coding.

What Vibe Coding Actually Enables

The standard criticism goes something like this: vibe coding produces bad code, people don't understand what they're building, and the result is unmaintainable garbage.

All true. Also completely beside the point.

My brother's DOM-clicking extension was objectively bad code. Hardcoded selectors, no error handling, sequential awaits with arbitrary timeout values, zero separation of concerns. If you ran it through a code review it would get rejected before the reviewer finished their coffee.

But it shifted his relationship with software from consumer to creator. He went from "YouTube doesn't have this feature so I guess I'm stuck" to "YouTube doesn't have this feature so I'll build it myself." That mental shift is worth more than any CS fundamentals course.

Vibe coding didn't teach him to program. It taught him that programming is an option. There's a massive difference, and I think it's the most important thing happening in tech education right now.

The Refinement Gap

After watching his extension click through DOM elements for 40 minutes, I spent an evening rewriting it. Not because his approach was wrong, but because I knew there was a faster path.

YouTube's frontend talks to internal API endpoints for everything. Loading subscriptions, managing them, unsubscribing. The same endpoints the website hits when you manually click that unsubscribe button. Instead of simulating clicks on DOM elements, you can call these endpoints directly from the extension using the session token from the active YouTube tab.

The difference is night and day. The DOM approach: scroll, find element, click, wait for modal, confirm, wait for response, scroll again. The endpoint approach: fire an authenticated POST request. No clicking, no scrolling, no modals, no waiting for DOM elements to render.

Scanning 500+ subscriptions went from "scroll for five minutes while the page lazy-loads" to a single paginated API call that returns everything in seconds. Unsubscribing went from 40 minutes of automated clicking to a few minutes of sequential API requests with a configurable delay to avoid rate limits.

This is where the vibe coding conversation gets interesting. My brother built the proof of concept. I built the production version. Both were necessary. Without his janky DOM-clicking prototype, I wouldn't have spent an evening on this at all. The vibe-coded version validated the idea. The refined version made it reliable.

The 12x Cost Problem, Revisited

I've written before about how vibe coding carries hidden costs. Code that works but can't scale, technical debt that compounds, solutions that break under edge cases the AI never considered.

This extension is a perfect case study. The DOM version worked but had real problems. Channels with identical names confused the selector logic. Session expiry mid-process caused silent failures. YouTube's A/B testing meant the extension might work on Monday and break on Wednesday.

The endpoint version handles all of this cleanly. Channel IDs instead of display names. Auth token validation before each request. No dependency on DOM structure at all.

But here's where I've softened my stance: the cost problem matters for production software. For personal tools, prototypes, and "I just need this to work once" utilities? Vibe coding is genuinely magical. A 17-year-old solved a real problem in an afternoon. The code quality was irrelevant because the code's job was to run once and save him two hours of clicking.

The mistake isn't vibe coding. The mistake is not knowing when vibe coding is enough and when it needs a human with context to step in and refine.

What's In The Extension Now

The production version has the stuff you'd expect from a proper tool: one-click scanning of all subscriptions via API, a searchable list with avatars and subscriber counts, select/deselect all, CSV export for backup (critical since YouTube has no bulk re-subscribe), configurable delay between unsubscribes, live progress tracking per channel, and a stop button to pause mid-process.

It runs 100% locally. No data collection, no background processes, no server calls. The extension talks to YouTube through your authenticated tab and nothing else.

If your subscription list has gotten out of hand, it's free on the Chrome Web Store: YouTube Mass Unsubscribe

The Bigger Point

My brother doesn't call himself a developer. He probably never will. But he now understands, at a gut level, that the software on his screen isn't magic. It's just code that someone wrote, and with the right tools, he can write it too.

That's not a small thing. An entire generation is growing up with AI editors that translate intent into working software. Most of what they build will be rough. Some of it will be broken. Almost none of it will be production-quality.

And it won't matter, my brother in christ. Because the gap between "I have an idea" and "I have a working prototype" just collapsed from months to hours. The refinement can come later. From them as they learn, or from someone else who sees the potential in their janky, beautiful, vibe-coded proof of concept.

That's what happened here. A kid built something imperfect, and it became something real.

Built by Binay Bhandari and refined by Bishwas Bhandari at Webmatrices.

I tracked 20 Reddit posts across 14 subreddits. Here's what actually drove traffic.

Bishwas Bhandari — Sat, 31 Jan 2026 15:34:50 +0000

Last month I ran an experiment. Posted 20 times across 14 subreddits to see what actually works for driving traffic to technical content.

One post hit 226,000 views. Another got 0 upvotes and 44 hostile comments.

Same person. Same week. Here's what made the difference.

The numbers

From Reddit alone, in one week:

100,000+ views
15,595+ readers
1,700 hours of read time

Best post: 600 upvotes, 94.5% approval, 120 comments on r/webdev.

Worst post: 0 upvotes, 35% approval, 44 comments telling me I was wrong.

The one thing that mattered most

Third-person framing.

Framing	Example	Result
Third-person	"someone actually calculated..."	600 upvotes
First-person	"I made a contrarian analysis site"	1 upvote

Same content quality. 600x difference in results.

Reddit trusts discoveries. Reddit distrusts self-promotion.

"Found this breakdown" beats "I wrote this breakdown" every single time.

The post that hit 226K views

Title: "someone actually calculated the time cost of reviewing AI-generated PRs. the ratio is brutal"

Why it worked:

Third-person frame ("someone calculated" not "I calculated")
Specific number in title ("12x" ratio)
Lowercase, casual tone
Ended with a genuine question

The top comment got 156 upvotes: "We need an AI that automatically closes vibe coded PRs.. let them fight"

When your top comments are jokes agreeing with you, you've won.

The post that got destroyed

Title: "why would a company pay $1,500/year for SaaS when a dev can build it custom for $500?"

Posted to r/Entrepreneur. Business owners, not developers.

They didn't care about cost savings. They cared about reliability. I was speaking dev language to business people.

44 comments. All hostile. 0 upvotes.

Same article, different subreddits

This surprised me most.

Same "$599 Mac Mini" article:

Subreddit	Upvotes	Approval
r/ArtificialInteligence	412	81%
r/vibecoding	148	69%

264-point difference. 12% approval gap. Same content.

r/ArtificialInteligence wanted debate. r/vibecoding was tired of hype.

Subreddit culture matters more than content quality.

The AI-writing disaster

r/programming caught me.

Top comment, 120 upvotes: "God I hate reading all these LLM-written blog posts"

What they noticed:

Em dashes (—) everywhere
Short, choppy sentences
Repetition of the same points
Too much structure

If you use AI assistance, r/programming will find out. And they will make it the top comment.

The formula

After 20 posts, this is what consistently worked:

SPECIFIC NUMBER + THIRD-PERSON FRAME + GENUINE QUESTION = ENGAGEMENT

And this is what consistently failed:

FIRST-PERSON + PROMOTIONAL TONE + WRONG AUDIENCE = DEATH

The 97% approval trick

One post hit 97% approval. Highest ever.

What I did differently: gave free, detailed help in the comments.

Someone asked for feedback. Instead of saying "check my article," I spent 500 words auditing their site. Found broken code, inconsistent info, specific issues.

That comment got upvoted. Other people asked for help. I helped them too.

Free value in comments builds more trust than the post itself.

TL;DR

Third-person framing — "found this" beats "I made this"
Specific numbers — "12x ratio" beats "takes longer"
Know your subreddit — same content, wildly different results
Genuine questions — invites comments instead of judgment
Free value in comments — the real trust builder

I documented the whole thing with screenshots, the disasters, and the exact patterns that worked. If you want the full breakdown: The Subtle Art of Reddit Marketing

Or just take the formula above and test it yourself. The third-person framing alone changed everything for me.

I Analyzed 50+ SaaS Shutdowns. They All Made The Same Mistake.

Bishwas Bhandari — Fri, 30 Jan 2026 13:24:36 +0000

Spent the last few months reading shutdown posts. Not the advice posts. The actual failures.

The pattern was always the same. And it wasnt what I expected.

The Numbers That Broke Me

One founder got 2,600 free users in four months. Zero paying customers.

Another validated for two years. Talked to companies. They all said theyd pay. Zero paying customers.

20,000 users. 3,586 websites created. Shut down anyway.

These founders didnt lack effort. They didnt build bad products. They validated the wrong thing.

Stated Preference vs Revealed Preference

Theres a concept in behavioral economics that explains everything.

Stated preference is what people say theyll do. Revealed preference is what they actually do.

When you ask "would you pay for this?" youre asking someone to simulate a future version of themselves making a purchasing decision. That simulation is wrong almost every time.

One founder ran 300 beta tests. Video calls. Excited users. Tons of feedback. Launch day came. Nobody converted.

His reflection was brutal. Interest does not equal willingness to pay.

The Vanity Metrics Factory

One founder described their free trial as a "vanity metrics factory." Free trials attract tire kickers, students doing research, and competitors poking around. The dashboard shows growth. The bank account shows nothing.

This founder killed their free trial. Everyone told them it was suicide. Signups dropped 70%.

Revenue went up 40%.

The free trial was filtering IN the wrong people. Removing it filtered them OUT. Fewer users. More customers.

The Question That Changes Everything

After reading all these shutdown posts I noticed one question that separated winners from losers.

"What are you doing about this problem right now?"

Listen to the answer.

"Nothing, its fine." Not a real problem.

"We complain about it sometimes." Awareness without action.

"We have a spreadsheet that kind of works." Workaround. Good sign.

"We hired a contractor to handle it manually." Spending money. Great sign.

"We use [competitor] but it sucks." Active buyer. Best sign.

The goal isnt finding people who acknowledge the problem. Its finding people already spending time or money to solve it imperfectly. Those people will pay you. Everyone else is being polite.

The $1 Filter

The only real validation is a transaction. Not "I would pay." Not "sounds interesting." Money.

One founder added a $1 paywall to their free trial. Conversion rate went from 3% to 41%.

The $1 wasnt about revenue. It was about filtering. Anyone willing to pay $1 is categorically different from someone who isnt.

This feels wrong to most developers. We want to build first, charge later. But products dont speak. Customers do. And they speak loudest with their wallets.

The Pain Hierarchy

Not all problems are equal. Knowing which ones people will actually pay to solve before you build is everything.

Are they aware of the problem? Are they actively searching for solutions? Do they have existing workarounds? Are they already spending money on something? Is there built in urgency? Who controls the budget?

Most founders validate the first two levels and call it done. The money is in levels three through six.

Vitamins vs Painkillers

Most failed SaaS products are vitamins marketed as painkillers.

The test is simple. If your product disappeared tomorrow, would customers notice within 24 hours? Would they actively seek a replacement? Would they pay more to get it back?

If the answer is no, you built a vitamin.

What Actually Works

The pattern of successful founders was clear.

They charged early, often before the product was ready. They filtered aggressively, losing tire kickers on purpose. They found people with workarounds, not just people with problems. They talked to budget owners, not just pain experiencers. They built distribution before product.

They treated signups as vanity. Only revenue counted.

The Uncomfortable Truth

If youre reading this and feeling uncomfortable, good.

The founders who posted these shutdown stories all had skills to build great products. They all worked hard. They all "validated."

They all failed because they validated the wrong thing.

I wrote a full playbook on this. Analyzed 50+ real shutdowns, extracted the patterns, built frameworks you can actually use.

Chapter one is free. Covers the validation lie with more data and case studies.

Chapters two through four cover the exact playbooks for filtering buyers, identifying real pain, and building distribution before product.

The SaaS Validation Playbook

Reddit to LLM.txt

Bishwas Bhandari — Wed, 21 Jan 2026 14:00:42 +0000

You found it. The perfect Reddit thread. 300+ comments of exactly the conversation you need for your AI project.

You start copy-pasting. Five minutes in you realize you missed half the nested replies. You go back. You're trying to figure out which comment was responding to which. An hour later you have a document full of text with no structure and no idea who said what or when.

this is the problem nobody talks about.

Reddit is the best training data on the internet. Real conversations with actual nuance. But every way to extract it is broken. Manual copy-paste doesn't scale. Scrapers require a CS degree to configure. The API means writing code and dealing with rate limits. And even when you get the text out, it's just a wall of words. No hierarchy. Your model can't learn conversation structure from that.

One click and you get a clean markdown file. The full post. Every comment including the nested ones. Proper hierarchy so your LLM can actually understand who was replying to whom. All the metadata. When you feed this to GPT or Claude or your fine-tuned model, it can parse the conversation structure instead of just seeing words in sequence.

Everything runs in your browser. The extension reads Reddit's public API—the same data you'd see if you added .json to any URL. Nothing goes through our servers. Your data stays yours.

Built for AI researchers creating training datasets. Developers fine-tuning on specific communities. Anyone who's ever thought "I wish I could just download this entire thread" and then spent an hour copy-pasting.

this is exclusive to webmatrices members.

/reddit-to-llm

"taste scales. slop doesn't." — best breakdown i've seen on AI coding economics

Bishwas Bhandari — Mon, 19 Jan 2026 07:56:37 +0000

25-35% of new code in large organizations is now AI-assisted.
Everyone's shipping faster.
But someone has to review that code. Maintain it. Debug it at 3am.
Those people are burning out.

The Math
I tracked a typical AI-generated pull request:

Contributor time: 7 minutes
Maintainer time: 85 minutes
Ratio: 12x

And when you request changes? They feed your feedback to the AI and regenerate the whole thing. You're reviewing from scratch.
One maintainer told me he's stopped reviewing PRs entirely: "I can't tell anymore which ones are real contributions and which are someone farming GitHub activity for their LinkedIn."

The Security Problem
Radware's threat intelligence team analyzed 500,000 code samples and found "synthetic vulnerabilities" — security flaws unique to AI-generated code.
Key findings:

AI errors are disproportionately high-severity (injection, auth bypass)
"Hallucinated abstractions" — AI invents fake helper functions that look professional but are broken
"Slopsquatting" — attackers register hallucinated package names with malicious payloads

What This Means for Hiring
New interview question: "Walk me through a bug you personally debugged in this code."
If they can't explain trade-offs, they didn't write it.

The developers who thrive won't be the ones who generate the most code.
They'll be the ones who can tell the difference between code that compiles and code that belongs.
Taste scales. Slop doesn't.

Full breakdown in comments 👇

Developers killed Tailwind. Not AI.

Bishwas Bhandari — Wed, 14 Jan 2026 05:28:39 +0000

We just don't want to admit it.

AI is the easy scapegoat.
"LLMs bypass the docs."
"Cursor generates Tailwind without asking."
"Nobody visits the website anymore."
Sure. All true.
But when was the last time you paid for something you could get for free?
Exactly.

Tailwind has 75 million downloads a month.
They just fired 75% of their team.
→ npm downloads: All-time high
→ Revenue: Down 80%
→ Runway: 6 months left
Most popular CSS framework in history.
Nearly bankrupt.
Popularity is not a business model.

Shadcn gave away the same components for free.
Junior devs copy-pasted from CodePen for years.
The "premium templates" moat was made of paper.
AI didn't kill the business.
AI just automated what we were already doing for free.

And here's what really gets me:
$1M+/year in sponsorships.
Still struggling.
Blender — the entire 3D software industry's backbone — runs on $3M/year.
Tailwind needed a third of that to maintain... shorter class names?
Something doesn't add up.

They were hiring engineers at $275k.
For a CSS library.
That's not a sustainability problem.
That's a spending problem.

Now Google and Vercel suddenly show up with sponsorships.
Where were they 6 months ago when the runway was burning?
They didn't show up to save open source.
They showed up for the PR headline.

The math is brutal:
Usage ≠ Revenue.
Downloads ≠ Dollars.
npm installs ≠ Survival.
You can power half the internet and still go broke.

Stack Overflow is dying.
Tailwind almost died.
Dev blogs are ghost towns.
Any business that needs you to visit a website to make money?
Already dead. AI just signed the death certificate.

I use Tailwind every day.
I let AI write half of it.
I've never paid Tailwind a single rupee.
Neither have you.

So let's stop blaming AI.
The mirror is right there.

Who really killed Tailwind — the robots, or the culture that wants everything free?

AI generated code is just slop!

Bishwas Bhandari — Tue, 11 Nov 2025 11:34:41 +0000

SHlT, I am writing this...

AI coding is so fking frustrating. There's literally no life in it.
AI can't replace a human coder. Can't even replace a junior dev.
Yeah yeah, I know - some dev sits there instructing the AI to write code and it kinda works. But here's what nobody wants to talk about:
Who's taking responsibility when shit breaks? Who's guaranteeing that code actually works? Not the AI. You are.

The AI-generated code? Pure slop. And we all know it.
But here's the worst part - you get so used to this garbage that you don't even understand your own fking code anymore. I hate AI, but I'm accustomed to it. We all are.

That's the real tragedy. We're all becoming prompt monkeys who can't even read what we just "wrote."

I rewrote Mermaid integration for Svelte 5 - Turns out everyone's been doing it wrong

Bishwas Bhandari — Sun, 31 Aug 2025 16:02:21 +0000

Two weeks ago I was building docs for a client project and needed some flowcharts. Simple, right? Wrong.

Spent 3 hours fighting with existing Mermaid solutions. Configs breaking, themes not switching properly, SSR throwing fits. At one point I actually considered just drawing the diagrams in Figma and embedding images like some kind of barbarian.

That's when it hit me - we've all been treating Mermaid like it's 2019. Import a library, fight with initialization, pray it works with your build system. But this is Svelte 5. We have runes now. Why are we still coding like peasants?

So I built @friendofsvelte/mermaid - the way diagrams should work in 2025.

<script>
  import { Mermaid } from '@friendofsvelte/mermaid';

  const architecture = `graph TD
    A[Old way: Fight configs] --> B[Waste 3 hours]
    B --> C[Settle for broken solution]

    D[New way: Just works] --> E[Ship features]
    E --> F[Happy developers]`;
</script>

<Mermaid string={architecture} />

Here's what I learned building this

Everyone's overthinking Mermaid integration. The existing solutions try to handle every possible edge case, every framework, every version. Result? Bloated APIs that feel foreign in Svelte.

Runes changed everything. The internal state management is so clean now. What used to take 50 lines of reactive statements is now 5 lines of $state and $derived.

Theming was the real pain point. Most solutions make you fight CSS variables or override styles. This component just accepts a theme prop and handles the rest.

What this actually does

Themes that switch instantly - Dark mode, custom colors, no flicker
Proper TypeScript - Full type safety, intelligent completion
All diagram types - Flowcharts, sequence, Gantt, user journeys, the works
Error handling that helps - Actually tells you what's wrong with your diagram syntax
Responsive by default - Works on phones without you thinking about it

The controversial part

Most Mermaid integrations are solving the wrong problem. They focus on compatibility and features instead of developer experience. But here's the thing - if your diagram component feels like work to use, you're less likely to document things properly.

Good documentation tools should disappear. You should think about your content, not your tooling.

Real talk: Why this matters

I've seen too many projects with terrible docs because the diagram tooling was a nightmare. Teams skip flowcharts, avoid sequence diagrams, and end up with docs that nobody understands.

When adding diagrams is as easy as writing markdown, teams actually document things. And that makes better software.

Try it yourself

Site: https://mermaid-cjv.pages.dev/
Install: npm install @friendofsvelte/mermaid

Svelte 5 only - because backward compatibility is the enemy of progress.

What I'm building next

This is part of a bigger documentation toolkit I'm working on. Thinking about components for API docs, interactive code examples, maybe even live demo embedding.

The goal? Make documentation so smooth that teams actually want to write it.

What kind of diagrams are you adding to your projects? Anyone else frustrated with how complicated this stuff has become?

Svelte 5 Persistent State - Strictly Runes Supported

Bishwas Bhandari — Wed, 05 Mar 2025 10:03:25 +0000

Svelte 5 dropped a bomb on front-end development with its runes system, and state management will never be the same. While everyone's scrambling to catch up, @friendofsvelte/state is already miles ahead, offering a dead-simple persistent state solution that feels like it was born for this moment.

The Persistent State Problem That's Driving You Insane

Let's be honest—we've all cursed under our breath when a user refreshes the page and loses their state. Building persistence yourself means writing the same tedious boilerplate for the millionth time. How many more storage event listeners can one developer write before losing their mind?

Enter @friendofsvelte/state - a refreshing, zero-BS approach to state management that embraces Svelte 5's runes revolution while solving the persistent storage problem that plagues every front-end developer's existence.

The Friend of Svelte crew didn't just build another state management library—they built the one you'll actually want to use. No bloat, no philosophy lectures, no 45-minute YouTube tutorials needed. Just persistent state that works out of the box.

What Makes This Library Actually Worth Your Time

Type Safety That Doesn't Get in Your Way: Full TypeScript support with automatic type inference. No more "Oh it's typed, but you need 17 generic parameters to make it work."
Storage That Just Works: Your state lives in localStorage or sessionStorage automatically. No plugins, no middleware, no config files.
Zero Bloat: No dependencies beyond Svelte itself. Your bundle size won't explode because someone decided to include the entirety of lodash.
Actually Reactive: Seamlessly plugs into Svelte 5's reactivity system. No adapters, no bridges, no "glue code."
Sync Without Thinking: State syncs across components automatically. No dispatching, no subscribing, no reducer functions.
One Function to Rule Them All: A single function that handles everything. Not an "elegant architecture" with 27 moving parts.

Getting Your Hands Dirty (It Takes 30 Seconds)

Adding persistent state to your Svelte 5 app couldn't be more straightforward:

Install it (you know the drill):

npm install @friendofsvelte/state

Define your state (look how clean this is):

// state.svelte.ts
import { PersistentState } from '@friendofsvelte/state';

export const box = new PersistentState('box', {
  color: '#ff3e00',
  dimensions: [100, 100]
}, 'sessionStorage');

Use it anywhere (yes, it's really this simple):

<script lang="ts">
  import { box } from './state.svelte';

  const colors = ['red', 'blue', 'green', 'yellow', 'purple', 'orange', 'pink', 'brown'];

  function switchNextColor() {
    const currentIndex = colors.indexOf(box.current.color);
    box.current.color = colors[(currentIndex + 1) % colors.length];
  }
</script>

<div 
  style="background-color: {box.current.color}; width: 100px; height: 100px;"
  class="m-2 rounded-2xl"
>
  {box.current.color}
</div>

<button on:click={switchNextColor} class="bg-gray-700 m-2 px-3 rounded-2xl">
  Change color
</button>

How It Plays With Svelte 5 Runes (Like They Were Made for Each Other)

While other libraries are playing catch-up, PersistentState was built from the ground up for Svelte 5's runes system. Here's what happens under the hood:

Checks if you've already got saved data (because nobody likes losing their work)
Loads your existing data if it's there (with proper deserialization—not that string mess)
Falls back to your defaults if nothing's saved (because empty states are user-hostile)
Hooks directly into Svelte 5's reactivity (no awkward "connector" patterns)
Syncs changes to storage automatically (forget manually saving state—it's 2025!)

The real magic? You don't have to think about any of this. It just works, letting you focus on building features that actually matter.

Beyond the Basics (For When You Need More Power)

The basic API is dead simple, but there's more when you need it:

Storage That Matches Your Needs

// For data that survives browser restarts (like user preferences)
const settings = new PersistentState('settings', defaultSettings, 'localStorage');

// For session-specific data (like form progress)
const tempState = new PersistentState('temp', initialState, 'sessionStorage');

Type Safety That Actually Helps

interface UserPreferences {
  theme: 'light' | 'dark' | 'system';
  fontSize: number;
  notifications: boolean;
}

const preferences = new PersistentState<UserPreferences>('preferences', {
  theme: 'system',
  fontSize: 16,
  notifications: true
});

// Your IDE will catch this before you even save the file
preferences.current.theme = 'dark'; // Works like a charm
preferences.current.theme = 'blue'; // TypeScript stops you from shooting yourself in the foot

Performance That Won't Make Your App Crawl

This isn't one of those libraries that tanks your performance for convenience:

It only saves when things actually change (not on every render like some other solutions)
Uses fast JSON serialization (no weird custom formats)
Batches updates intelligently (your storage isn't getting hammered)

Browser Support (Yes, It Works Everywhere That Matters)

Works in every browser that isn't ancient history:

Modern browsers? Check.
localStorage/sessionStorage support? Check.
JSON? Check.

IE11 users? They have bigger problems than your state management.

The Bottom Line

@friendofsvelte/state isn't trying to be the next Redux or Pinia with philosophical manifestos and complex architecture diagrams. It's a tool that solves one problem perfectly: persistent state in Svelte 5 apps.

It embraces everything that makes Svelte awesome—simplicity, reactivity, and developer experience—while removing the persistent storage headache that's been bothering you for years.

For Svelte 5 developers embracing the runes revolution, this isn't just another option—it's the option that actually respects your time and sanity.

Inspired by Rich Harris' local-storage-test, but kicked up several notches with features that make Svelte 5 development even more delightful. Because if the creator of Svelte thinks it's a good approach, who are we to argue?

Svelte Icon Library - Svelicon 🎨

Bishwas Bhandari — Fri, 14 Feb 2025 07:21:40 +0000

Create Svelte components from Iconify SVG icons with type-safe support. A simple CLI tool for generating Svelte icons.

Features ✨

🎯 Iconify Integration: Access and download icons from the Iconify collection.
⚡ Fast Conversion: Quickly convert SVG icons to Svelte components.
📦 TypeScript Support: Generate fully typed components with interfaces for Svelte TypeScript projects.
🎨 Customizable Icons: Control icon size, display behavior, and spacing.
🛠️ CLI Tool: Easy-to-use command-line interface for Svelte icon generation.
🔄 Flexible Output: Generate JavaScript or TypeScript Svelte components.

Svelicon streamlines the process of using Iconify icons in your Svelte projects, offering TypeScript support and flexible customization.

Requirements 🗒️

Svelte 5
Awesomeness

Usage 🚀

Basic Usage

npx svelicon --withts fluent/person-passkey-28-filled

This command downloads the person-passkey-28-filled icon from the fluent collection and creates a TypeScript Svelte component at

src/icons/FluentPersonPasskey28Filled.svelte

CLI Options

npx svelicon [options] [collection]/[icon]

Options:
  -o, --output <dir>  Output directory (default: "src/icons")
  --withts            Generate TypeScript version
  --withjs            Generate JavaScript version (default: true)
  -h, --help         Display help for command

Component Props 🎛️

All generated components accept these props:

interface IconProps {
  display?: boolean;  // Whether to display the icon
  occupy?: boolean;   // Whether to occupy space when hidden
  size?: number;      // Icon size in em units
  class?: string;     // Add custom CSS classes to the SVG element
}

Examples 📝

JavaScript Usage

<script>
  import FluentPersonPasskey28Filled from './icons/FluentPersonPasskey28Filled.svelte';
</script>

<FluentPersonPasskey28Filled display={true} size={1.2} />

TypeScript Usage

<script lang="ts">
  import FluentPersonPasskey28Filled, { type FluentPersonPasskey28FilledProps } from './icons/FluentPersonPasskey28Filled.svelte';

  let iconProps: FluentPersonPasskey28FilledProps = {
    display: true,
    size: 1.2,
    class: 'my-custom-icon'
  };
</script>

<FluentPersonPasskey28Filled {...iconProps} />

Component Output Structure 🏗️

Generated components include:

<script lang="ts" module>
  export interface FluentPersonPasskey28FilledProps {
    display?: boolean;
    occupy?: boolean;
    size?: number;
    class?: string;
  }
</script>

<script lang="ts">
  const { display = false, occupy = true, size = 0.7, class: className = '' }: FluentPersonPasskey28FilledProps = $props();
</script>

{#if display}
  <svg class={className}><!-- icon content --></svg>
{:else if occupy}
  <div style="height: {size}em; width: {size}em;" />
{/if}

Benefits 🌟

Zero Runtime Dependencies: Svelte icon components are standalone.
Tree-Shakeable: Only import the Svelte icons you use.
Type-Safe Svelte: Full TypeScript support for Svelte projects.
Small Bundle Size: Minimal impact on your Svelte app's size.
Flexible Svelte Icons: Use any Iconify icon in your Svelte project.

https://youtu.be/6cpXq1MHg-A

Contributing 🤝

Contributions are welcome! Please read our Contributing Guide for details.

License 📄

MIT © Friend of Svelte

Support 💖

If you find this Svelte icon library helpful, please consider:

⭐ Starring the GitHub repo
🐛 Creating issues for bugs and feature requests
🔀 Contributing to the code base

Related Projects 🔗

Made with ❤️ by Friend of Svelte

Best Backend Frameworks for 2025: A Developer's Guide to Making the Right Choice

Bishwas Bhandari — Mon, 03 Feb 2025 05:59:22 +0000

The landscape of backend development is undergoing a radical transformation as we move deeper into 2025. Gone are the days when choosing a backend framework was simply about picking the most popular option. Today's developers face a more complex decision, balancing traditional stability with modern performance demands.

Why Framework Choice Matters in 2025

The stakes for choosing the right backend framework have never been higher. With the explosion of AI-powered applications, real-time processing requirements, and microservices architectures, your framework choice can make or break your project's success. Key trends shaping framework selection in 2025 include:

AI Integration Capabilities: Modern applications increasingly require seamless AI/ML integration
Performance at Scale: The rise of global applications demands frameworks that can handle millions of concurrent users
Developer Experience: With rising development costs, productivity and maintainability are more crucial than ever
Cloud-Native Features: Native support for containerization, serverless deployment, and microservices is no longer optional
Type Safety & Security: Enhanced security features and type systems are becoming standard requirements

Key Factors to Consider

When evaluating backend frameworks in 2025, consider these critical factors:

Performance Characteristics
- Request handling capacity
- Memory efficiency
- Cold start times for serverless deployments
Developer Productivity
- Learning curve
- Documentation quality
- Community support and ecosystem
- Available tools and IDE integration
Technical Requirements
- Async/sync support
- Type system capabilities
- Built-in features vs. ecosystem dependencies
- API design capabilities
Business Considerations
- Team expertise and learning requirements
- Long-term maintenance costs
- Scalability needs
- Time to market requirements

As we delve deeper into each framework category, we'll examine how these factors play out in real-world scenarios, helping you make an informed decision that aligns with your project's needs and your team's capabilities.

The backend landscape of 2025 offers more choices than ever before. From traditional frameworks that have evolved to meet modern demands, to cutting-edge solutions built for today's cloud-native world, each option brings its own strengths to the table. Let's explore how these frameworks stack up against modern requirements and help you find the perfect fit for your next project.

Traditional Frameworks Reimagined

The powerhouses of backend development haven't stood still - they've evolved dramatically to meet modern demands while maintaining their battle-tested reliability. Let's explore how these established frameworks have transformed themselves for 2025's challenges.

Spring Boot: Java's Enterprise Champion

Spring Boot continues to dominate enterprise development in 2025, with significant improvements in startup time and resource consumption:

@RestController
public class UserController {
    @PostMapping("/users")
    public ResponseEntity<User> create(@Valid @RequestBody UserDTO user) {
        return ResponseEntity.ok(userService.create(user));
    }
}

Key Strengths:

Native compilation support
Comprehensive microservices support
Mature ecosystem
Enterprise-grade security
Excellent cloud platform integration

Perfect For: Large-scale enterprise applications requiring rock-solid reliability.

Laravel: PHP's Elegant Workhorse

Laravel has reinvented itself for 2025, introducing powerful async capabilities while maintaining its developer-friendly approach:

public function store(StorePostRequest $request): JsonResponse
{
    $post = Post::create($request->validated());

    return response()->json($post, 201);
}

Key Strengths:

Elegant syntax and APIs
Built-in async processing
Rich ecosystem of packages
Excellent ORM with relationship handling
Strong caching and queuing support

Perfect For: Rapid application development teams needing a balance of speed and maintainability.

Djapy: Django's Zero-Boilerplate Revolution

Djapy represents a paradigm shift in Django's ecosystem, bringing modern API development patterns while maintaining Django's "batteries-included" philosophy. It's changing how developers think about building Django APIs:

@djapify(method="POST")
def create_post(request, data: PostSchema) -> {201: PostSchema}:
    post = Post.objects.create(**data.dict())
    return 201, post

Key Strengths:

Zero boilerplate API development
Full Python-type hints with Pydantic
Seamless Django integration
Async / Asgi support
Built-in OpenAPI documentation
Automatic request/response validation

Perfect For: Teams that want Django's robustness with modern TypeScript-like developer experience.

Real-World Performance Comparison

Here's how these frameworks stack up in real-world scenarios:

Framework	Requests/sec	Avg Latency	Memory Usage
Spring Boot	20,000	15ms	110MB
Laravel	18,000	18ms	60MB
Djapy	25,000	12ms	45MB

Making the Traditional Choice

When considering these frameworks, ask yourself:

Team Experience: Which ecosystem is your team most familiar with?
Project Scale: Do you need enterprise features or rapid development capabilities?
Performance Requirements: Are your performance needs aligned with these frameworks' capabilities?
Ecosystem Requirements: Which framework's ecosystem best matches your project's needs?

These traditional frameworks have earned their places through continuous innovation while maintaining backwards compatibility. They offer a proven path forward, especially for teams with existing investments in their ecosystems.

Modern ASGI Powerhouses

The rise of ASGI (Asynchronous Server Gateway Interface) frameworks has revolutionized Python web development, bringing unprecedented performance and scalability. Let's explore the leaders in this space for 2025.

Litestar: The New Python Performance King

Litestar has emerged as a game-changer in the Python ecosystem, combining blazing performance with developer ergonomics:

from litestar import Litestar, get

@get("/users/{user_id}")
async def get_user(user_id: int) -> UserSchema:
    user = await User.objects.get(id=user_id)
    return user

app = Litestar([get_user])

Key Strengths:

Outstanding performance metrics
Built-in dependency injection
Advanced type safety and validation
Comprehensive middleware system
First-class WebSocket support
Seamless SQLAlchemy integration
Rich OpenAPI documentation

Perfect For: High-performance applications requiring type safety and modern features.

FastAPI: Speed with Simplicity

FastAPI continues to be a beloved choice for its perfect balance of speed and ease of use:

from fastapi import FastAPI, Depends

@app.get("/items/{item_id}")
async def read_item(
    item_id: int,
    q: str | None = None,
    user: User = Depends(get_current_user)
):
    return {"item_id": item_id, "owner": user}

Key Strengths:

Excellent performance
Auto-generated API documentation
Intuitive dependency injection
Strong type hints and validation
Active community and ecosystem

Perfect For: Teams prioritizing developer experience without sacrificing performance.

Starlette: The ASGI Foundation

As the foundation for many modern Python frameworks, Starlette offers raw performance with flexibility:

from starlette.applications import Starlette
from starlette.routing import Route

async def homepage(request):
    return JSONResponse({"message": "Welcome"})

app = Starlette(routes=[
    Route("/", homepage)
])

Key Strengths:

Lightweight and minimal
Maximum flexibility
Core ASGI features
WebSocket support
Server-sent events
Static files handling

Perfect For: Custom framework development and specialized use cases.

Performance Benchmarks

Real-world performance comparison (requests/second under typical load):

Framework	Plain Text	JSON	DB Query
Litestar	50,000	45,000	15,000
FastAPI	45,000	40,000	13,000
Starlette	52,000	47,000	14,000

When to Choose an ASGI Framework

Consider an ASGI framework when you need:

High Performance: Handling thousands of concurrent connections
Real-time Features: WebSocket or Server-Sent Events
Modern Development: Type safety and automatic documentation
API-First Design: Building modern, scalable APIs
Resource Efficiency: Maximum performance per server

ASGI frameworks represent the cutting edge of Python web development, offering performance that rivals Go and Node.js while maintaining Python's readability and ease of use.

Microservices & Serverless Specialists

In 2025, serverless and microservices architectures have become mainstream deployment choices. Let's explore the frameworks specifically designed for these modern architectural patterns.

Micronaut: JVM's Cloud-Native Framework

Micronaut has revolutionized JVM-based microservices development with its compile-time dependency injection:

@Controller("/api")
public class UserController {
    @Post("/users")
    public Single<User> create(@Body UserDTO user) {
        return userService.createUser(user)
            .subscribeOn(Schedulers.io());
    }
}

Key Strengths:

Sub-second startup time
Minimal memory footprint
Native cloud integration
GraalVM native support
Reactive programming model
Built-in service discovery
Serverless-ready design

Perfect For: Enterprise microservices requiring fast startup and low memory usage.

Chalice: AWS Lambda's Python Champion

Chalice offers a streamlined approach to AWS serverless development:

from chalice import Chalice

app = Chalice(app_name='serverless-api')

@app.lambda_function()
def process_data(event, context):
    return {
        'processed': True,
        'data': event.get('data')
    }

Key Strengths:

AWS service integration
Automatic IAM policy generation
API Gateway integration
Easy deployment process
Local testing support
Event-driven capabilities
Cost-effective scaling

Perfect For: AWS-focused teams building serverless applications.

Rocket: Rust's Type-Safe API Builder

Rocket brings Rust's safety guarantees to serverless functions:

#[post("/analyze", data = "<input>")]
async fn analyze(input: Json<AnalysisRequest>) -> Json<AnalysisResult> {
    let result = perform_analysis(&input).await?;
    Json(result)
}

Key Strengths:

Compile-time verification
Zero-cost abstractions
Excellent error handling
Type-safe request handling
Built-in testing support
Fast cold starts
Low resource usage

Perfect For: High-performance serverless functions requiring strong safety guarantees.

Serverless Performance Metrics

Cold start and execution metrics:

Framework	Cold Start	Memory (exec)	Execution Time
Micronaut	0.8s	80MB	45ms
Chalice	0.3s	60MB	55ms
Rocket	0.2s	15MB	25ms

Key Decision Factors

When choosing a serverless/microservices framework, consider:

Cost Efficiency
- Cold start performance
- Resource consumption
- Execution time optimization
Development Experience
- Local development tools
- Testing capabilities
- Deployment workflows
Cloud Provider Integration
- Native service bindings
- Authentication integration
- Monitoring capabilities
Operational Excellence
- Debugging capabilities
- Monitoring integration
- Error handling

Best Practices for 2025

Multi-Runtime Strategy
- Choose different frameworks for different workloads
- Consider cold start requirements
- Balance development speed with performance
Cost Optimization
- Implement intelligent scaling
- Optimize function size
- Use appropriate memory settings
Operational Excellence
- Implement comprehensive monitoring
- Use distributed tracing
- Maintain proper logging

These specialized frameworks are optimized for modern cloud architectures, offering the best path forward for teams building distributed systems in 2025.

Making Your Choice: The Framework Decision Framework

Choosing the right backend framework in 2025 isn't about following trends - it's about aligning technology with your specific needs. Let's break down a practical approach to making this crucial decision.

Step 1: Assess Your Priorities

First, rank these factors based on your project's needs:

Performance Requirements: What are your throughput and latency needs?
Team Expertise: What is your team's current technical background?
Time to Market: How quickly do you need to ship?
Scalability Needs: What's your expected growth trajectory?
Budget Constraints: What are your infrastructure and development costs limits?

Step 2: Framework Category Match

Based on your priorities, consider these categories:

Traditional Frameworks (Django/Djapy, Spring Boot, Laravel):

Established ecosystems
Comprehensive documentation
Proven production reliability
Larger initial resource footprint

ASGI Powerhouses (Litestar, FastAPI):

High performance
Modern developer experience
Excellent for async operations
Growing ecosystems

Cloud-Native Leaders (Nest.js, Go Fiber):

Built for scalability
Container-optimized
Microservices-ready
Strong cloud integration

Step 3: Technical Requirements Checklist

✅ Must-Have Features

Authentication/Authorization
Database integration
API documentation
Testing support
Deployment options

✅ Performance Requirements

Request handling capacity
Memory usage
Startup time
Database operation speed

Step 4: Future-Proofing Considerations

Consider these long-term factors:

Community health and growth
Corporate backing or foundation support
Upgrade and migration paths
Long-term maintenance costs

Quick Decision Guide

Choose Traditional Frameworks when you need:

Proven reliability
Comprehensive features
Large talent pool
Established patterns

Choose ASGI Powerhouses when you need:

Maximum performance
Modern development experience
Strong async capabilities
API-first development

Choose Cloud-Native Leaders when you need:

Microservices architecture
Container optimization
Cloud service integration
Horizontal scaling

Choose Serverless Specialists when you need:

Pay-per-use pricing
Automatic scaling
Minimal operations
Quick time to market

Red Flags to Watch For

🚩 Framework Warning Signs:

Declining GitHub activity
Outdated documentation
Poor security track record
Limited community support
Unclear upgrade paths

Remember

The "best" framework is the one that:

Fits your team's skills
Meets your performance needs
Aligns with your budget
Supports your time-to-market goals
Has room for growth

Take time to prototype with your top choices before making a final decision. The right choice today will save countless hours tomorrow.

AdSense Revenue Crisis: Chrome's Cookie Changes Spark Widespread Earnings Collapse

Bishwas Bhandari — Mon, 20 Jan 2025 10:08:00 +0000

In a troubling development for web publishers, numerous site owners are reporting dramatic drops in their Google AdSense earnings since early January 2025, with some seeing their monthly income plummet from comfortable four-figures to barely enough for a month's worth of instant noodles. This sudden downturn has left many content creators in crisis mode, particularly those relying on this income for student loan payments and basic living expenses.

The Scale of the Problem

The impact appears to be widespread across various niches, but particularly noticeable in the technology and educational content sectors. One CS student's story particularly stands out: after five years of building a programming tutorial site from their freshman year study notes, their monthly AdSense revenue crashed from $1,500 to $218 – just days before their $890 student loan payment was due, on this discussion about google adsense revenue drop in the very beginning of this year.

Common patterns emerging across the community include:

Revenue drops of 70-85% despite stable or increasing traffic
RPM (Revenue Per Mille) plummeting from $12-14 to as low as $2
Disconnects between Analytics traffic data and AdSense metrics
Previously premium ad spots now showing lower-tier network ads
Some ad units appearing blank despite being marked as "serving ads"

The Root Cause: Chrome's Cookie Deprecation

Industry experts are pointing to Google Chrome's third-party cookie deprecation as the primary factor. Beginning January 4th, 2025, Chrome started phasing out third-party cookies for 1% of users, with plans to expand this to all users by Q3 2024. This change fundamentally affects how advertisers can track user behavior across websites, leading to:

Reduced ability to serve personalized ads
Lower bidding rates from advertisers due to less precise targeting
Disruption in traditional behavioral advertising models
Significant drops in RPM across ad networks

The Human Impact

"These are literally the same tutorials that were doing great for years," shared one affected creator. "Students still find them helpful – my comment section is pretty active with thank yous. The pages that were making $40-50 per day are now making cents. Same traffic, just... worthless ads."

The timing couldn't be worse for many content creators. Those who built sustainable businesses around their AdSense revenue are suddenly finding themselves unable to meet basic financial obligations. As one publisher put it, "instant noodles aren't going to cover this loan payment."

What Publishers Can Do

While the situation appears dire, there are several steps publishers can take to mitigate the impact:

Monitor Ad Networks
- Review Reports > Ad Networks in AdSense
- Identify and potentially block extremely low-performing networks
- Focus on networks with higher RPM
Optimize Ad Placement
- Focus on high-viewability spots
- Reduce placements that might cause accidental clicks
- Consider implementing consent management solutions
Prepare for the Future
- Research Privacy Sandbox alternatives
- Diversify revenue streams
- Keep track of Google's privacy-focused advertising solutions

Looking Ahead

While current predictions suggest this might be the "new normal" for a while, there's hope for eventual recovery. As one experienced publisher noted, "Things that come fast go fast, but things that come slow tend to last longer." Advertising budgets haven't disappeared – they're just being redistributed in a privacy-first world.

For now, the best approach seems to be a combination of patience and proactive optimization while the advertising ecosystem adjusts to this new privacy-focused reality. Publishers who can weather this transition period while adapting their strategies will be better positioned for the future of digital advertising.

And for those facing immediate financial pressures? It might be time to look at backup options – because while the industry will eventually adapt, bills won't wait for the privacy sandbox to mature.

Note: This situation continues to evolve, and publishers should stay informed about updates to Google's Privacy Sandbox and alternative targeting solutions as they become available.