DEV Community: Playful Programming

Moving to European Digital Services, One Decision at a Time

Emanuele Bartolesi — Thu, 24 Sep 2026 16:13:19 +0000

My move to European digital services includes Proton, Qwant, and DeepL. When it came to Notion, I went further and replaced it with Brainy, the product I built for my own notes, projects, and tasks.

That sounds like a migration, but the word creates the wrong expectation. I did not spend a weekend exporting every account, cancelling every subscription, and declaring myself independent from American technology on Monday morning.

I am changing one decision at a time.

I do not want a US provider to be the automatic answer for every digital need simply because it is the most visible option. Europe has credible products. Some are good enough to compete directly, and some fit my needs better. That does not mean I will replace a working service because a company has the wrong flag beside its logo.

Proton made the change visible

Proton is where the migration became a system rather than a few unrelated experiments.

Proton Mail replaced my previous email setup. Proton VPN replaced NordVPN. Proton Pass replaced NordPass. I also use Lumo for selected private AI conversations rather than treating every chat as suitable for any general-purpose assistant.

The immediate benefit was consolidation. One privacy-focused Swiss ecosystem replaced several separate accounts and subscriptions. I did not need to find a different European company for email, another for passwords, and another for the VPN before making progress.

There is an obvious trade-off: consolidation reduces vendor sprawl while increasing dependence on Proton. Moving three services into one company is not diversification. I still prefer the current setup, but it would be dishonest to describe concentration as independence.

Lumo has a similar boundary. Proton says stored conversations use zero-access encryption, which is why it has a place in my private workflow. I do not pretend that it replaces every AI service or every model. The choice depends on the conversation and the job I need to complete.
For the moment I am using Lumo only for questions related my health and other sensitive information.

The corporate map is more complicated than the logos

Once I started checking where services were based, the simple Europe-versus-USA story stopped working.

NordVPN is not an American service. NordVPN says it is based in and operates under Panama's jurisdiction, while its parent company, Nord Security, is based in the Netherlands. Moving to Proton VPN is a Panama-to-Switzerland change at the service-jurisdiction level, with a European parent company also involved in the old setup.

WeTransfer is European too. WeTransfer B.V. is based in Amsterdam, so my switch to SwissTransfer was not about escaping an American company. It was about the product.

For my file-sharing needs, SwissTransfer has a privacy model I prefer and a much more useful free allowance for large files. Infomaniak says SwissTransfer accepts transfers up to 50 GB, stores the files in Switzerland, supports password protection, and deletes the files after the transfer period. WeTransfer's current free-account documentation describes an allowance of up to ten transfers or 3 GB in total over a rolling 30-day period.

That is a concrete difference. I am not using SwissTransfer because the landing page has a Swiss flag. I am using it because privacy and larger transfers matter in this workflow.

This distinction changed how I evaluate alternatives. I now look separately at the service jurisdiction, parent company, data location, underlying infrastructure, business model, portability, and actual product quality. Those facts do not always point to the same country.

Some changes need almost no migration

Qwant and DeepL were easier decisions.

I use Qwant for search. Qwant is a French company, and its current privacy policy says it does not use targeted advertising or retain search history by default. Search is also easy to test: use it, compare the results, and keep another engine available when it does not find what you need.

I use DeepL for translation. It was founded in Cologne, Germany, and it is a good example of why the word "alternative" can be misleading. I do not need to treat a European translation service as a political compromise. I can use it because it does the work.

Neither choice required a dramatic data migration. There was no archive to restructure and no DNS record that could break a production system. They simply became part of the workflow.

New domains are another low-risk entry point. I now use Infomaniak Domains instead of GoDaddy for new registrations. I am not forcing every existing domain through an immediate transfer. When I need a new domain, the new default is a Swiss, ICANN-accredited registrar. That is progress without creating unnecessary operational risk.

DNS is an even quieter change. I use Quad9 as my resolver. Quad9 is a Swiss nonprofit, and its documentation says the recommended 9.9.9.9 service blocks lookups for malicious domains without logging end-user IP addresses. It also supports encrypted DNS protocols. This is closer to changing an infrastructure setting than migrating an account, but it moves a foundational part of normal browsing away from whichever resolver happened to be the default.

Replacing Notion meant building the alternative

Notion was different because a knowledge system accumulates structure as well as data. Notes connect to projects, tasks carry context, and the way information is captured affects whether it becomes useful work or remains another page in an archive.

I replaced Notion with Brainy, my own product.

Brainy is a practical second brain organized around the PARA method. It captures notes and ideas, connects them to projects and tasks, and focuses on turning stored knowledge into action. The goal was not to reproduce every Notion feature. It was to build a workflow that matches how I move from an idea to a project, from a project to the next task, and from planning to today's work.

Owning the product gives me control over that workflow, the data model, portability, and the roadmap, but it also gives me the maintenance work. I own the deployments, bugs, database changes, security decisions, and migration logic.

This is the clearest reason the entire transition cannot happen in two hours. Replacing a service can mean changing a setting or moving years of habits and information. In this case, it also meant building and operating a product.

For the moment, Brainy is free and you can create your own account here: www.brainy-me.com.

Sometimes the correct migration is no migration

I still use Spotify.

The reason is simple: Spotify is already European and it works for me. Its consumer terms identify Spotify AB in Stockholm, Sweden. Replacing it with another service only to increase the number of changed logos would add work without moving me closer to the actual goal.

A useful migration should leave some rows unchanged. Otherwise the process is driven by ideology rather than requirements.

Here is the current map:

Workflow	Current choice	Decision
Email	Proton Mail	Moved into the Proton ecosystem
VPN	Proton VPN	Replaced NordVPN
Passwords	Proton Pass	Replaced NordPass
Private AI chats	Lumo	Used selectively for private conversations
Large file transfers	SwissTransfer	Chosen for privacy and transfers up to 50 GB
New domain registrations	Infomaniak	Replaced GoDaddy as the default for new domains
DNS	Quad9	Uses a Swiss nonprofit resolver focused on privacy and security
Search	Qwant	In active use
Translation	DeepL	In active use
Knowledge and planning	Brainy	Replaced Notion with my own product
Music	Spotify	Kept because the European service already fits

The process I use before changing a service

The European Alternatives directory is useful for discovery, but inclusion in a directory is the beginning of the evaluation, not the conclusion.

Before changing a service, I work through a small set of questions:

What job does the current product perform?
Which features are genuinely non-negotiable, and which ones are habits?
Where is the service legally based, where is the data processed, and which external platforms does it still depend on?
Can I export the data in a useful format and move again later?
Can I run the old and new services in parallel before cancelling anything?
Is the alternative better, equivalent, or merely acceptable for this specific job?

That last question matters. I am willing to accept a small difference when privacy, control, or supporting a European provider makes the trade worthwhile. I am not willing to ignore a product that fails the workflow simply because it is European.

The safest changes happen at natural decision points. Register the next domain with a different registrar. Test another search engine without removing the old one. Import a copy of a password vault before cancelling the existing subscription. Send the next large file with a service that supports the size you need.

Moving all of them at once would turn a preference into an outage plan.

Change the next decision

I still use services from American companies, and I expect that to continue. Work, collaboration, audience, and network effects do not disappear because a European alternative exists.

The difference is that I no longer want the American option to win by default. When a subscription renews, a new need appears, or a current product creates friction, I check what exists in Europe before repeating the old decision.

The outcomes vary. A European product may be good enough, SwissTransfer may be better for large files, or Spotify may already be the European answer. Brainy sits at the other end of the range because I had to build the alternative around the workflow I wanted.

This process does not need a dramatic finish. The next decision is enough.

Thanks for reading this post, I hope you found it interesting!

Feel free to follow me to get notified when new articles are out 🙂

Emanuele BartolesiFollow

🏆 Microsoft MVP (12x) & GitHub Star (4x) ⭐ 👨‍🎓 LinkedIn Technical Instructor 🎓

INP and Partytown: give the main thread back to your users

Nicolas Frizzarin — Wed, 23 Sep 2026 08:18:37 +0000

Introduction

You click on a button. Nothing happens.
You click again. Still nothing.
Then the menu opens... and closes right away.

We have all lived this. It's a responsiveness problem. And since March 12, 2024, Google measures it with a Core Web Vital: INP.

Very often, the problem is not your code. It's the code you didn't write: analytics, tag managers, pixels, A/B testing tools...

This article explains:

What INP really measures
Why third-party scripts hurt it so much
How Partytown works
How to use it in React and Angular, with real examples
When you should not use it

INP in a few words

INP means Interaction to Next Paint.

It measures the time between a user interaction and the next frame painted by the browser. In other words: how long does the user wait before seeing that something happened?

Only three types of interaction count:

a click with a mouse
a tap on a touchscreen
a key press

Scroll, hover and zoom are not measured.

INP looks at all the interactions during the visit, and reports the worst one. If there are a lot of interactions, the browser ignores the highest one for every 50 interactions. That way, one random hiccup does not ruin your score.

The thresholds, at the 75th percentile of your real users:

INP	Result
≤ 200 ms	🟢 Good
200 ms to 500 ms	🟠 Needs improvement
> 500 ms	🔴 Poor

Just a reminder: INP replaced FID (First Input Delay). FID only measured the waiting time of the first interaction. INP measures every interaction, from start to paint. Much stricter.

What's inside an interaction?

An interaction has three phases:

 user clicks                                              next frame
     │                                                        │
     ▼                                                        ▼
     ├────────────────┬──────────────────────┬────────────────┤
     │  Input delay   │ Processing duration  │ Presentation   │
     │                │                      │ delay          │
     └────────────────┴──────────────────────┴────────────────┘
     │◄───────────────── interaction latency ───────────────►│

Input delay: the time before your event handlers start. The browser is busy with something else.
Processing duration: the time to run all your event handlers.
Presentation delay: the time to compute style, layout and paint the next frame.

Keep the first one in mind. This is where third-party scripts hurt the most.

The main thread: a one lane road

The browser has one main thread. It does everything:

runs JavaScript
handles events
computes style and layout
paints

And it does one thing at a time.

A task longer than 50 ms is a long task. During a long task, the browser can't respond to the user.

Now imagine your page with Google Tag Manager, a marketing pixel and an analytics script. The user clicks at the wrong moment:

Main thread, without Partytown

──[ your app ]──[ tag manager 180ms ]──[ pixel 120ms ]──[ click handler ]──[ paint ]──
                      ▲
                user clicks here
                      │◄──────── input delay ────────►│

Your click handler is fast. Your code is clean. And your INP is still bad.

This is the key point: you can write perfect code and still fail INP, because you share the road with scripts you don't control.

Partytown: move the party somewhere else

Partytown is a small library, lazy-loaded, maintained by the QwikDev team. Its goal is simple: move third-party scripts from the main thread into a web worker.

The philosophy: the main thread is for your code. Everything that is not in the critical path can go elsewhere.

flowchart LR
  subgraph Before["Without Partytown"]
    MT1["Main thread<br/>your app + GTM + pixel + analytics"]
  end
  subgraph After["With Partytown"]
    MT2["Main thread<br/>your app"]
    WW["Web worker<br/>GTM + pixel + analytics"]
    WW -. "DOM calls through a proxy" .-> MT2
  end

And the same timeline as before:

Main thread, with Partytown

──[ your app ]──[ click handler ]──[ paint ]──
                ▲
          user clicks here: almost no input delay

Web worker

──[ tag manager 180ms ]──[ pixel 120ms ]──   ← nobody waits for this

The long tasks still exist. They just don't block the user anymore.

⚠️ Partytown is still in beta. It's not guaranteed to work for every script. Test before you ship.

How does it work?

Here comes the tricky part.

A web worker has no DOM. No document, no real window. But third-party scripts expect them. They call document.cookie, getBoundingClientRect(), addEventListener...

On top of that, communication between a worker and the main thread is asynchronous. Third-party scripts are written in a synchronous way. No await, no callback.

So Partytown does two things:

In the worker, it creates JavaScript Proxies that look like window and document.
Each call to these proxies is sent to the main thread through a synchronous channel, and the worker waits for the answer.

From the script's point of view, nothing changed. This code works as is inside the worker:

const rect = element.getBoundingClientRect(); // blocking call, like on the main thread
console.log(rect.x, rect.y);

There are two ways to get this synchronous channel.

Option 1: Service Worker (the fallback)

The worker sends a synchronous XHR. A service worker intercepts it, asks the main thread, and answers.

sequenceDiagram
  participant W as Web worker (3rd-party script)
  participant SW as Service worker
  participant M as Main thread (DOM)
  W->>SW: sync XHR "getBoundingClientRect()"
  SW->>M: postMessage
  M-->>SW: result
  SW-->>W: response { x, y }
  Note over W: for the script, it was a normal blocking call

That's why you'll see a lot of proxytown requests in the network tab. They are not real HTTP requests. They're handled locally. You can hide them with the -url:proxytown filter in Chrome DevTools.

Option 2: Atomics (the fast one)

With Atomics and SharedArrayBuffer, the worker writes the request, calls Atomics.wait(), and reads the result when the main thread answers. No service worker needed.

It's about 10x faster to transfer data between threads.

But there's a condition: the page must be cross-origin isolated. You need these response headers on your document:

Cross-Origin-Embedder-Policy: credentialless
Cross-Origin-Opener-Policy: same-origin

Two things to know:

Safari doesn't support credentialless. So Safari falls back to the service worker.
You can use require-corp instead, which works in Safari. But it blocks every cross-origin image, script or video that doesn't have a crossorigin attribute. Be careful with your CDN.

If the headers are not there, no problem: Partytown falls back to the service worker automatically.

The two rules to remember

Before the code, two rules. They are the same for every framework.

Rule 1: type="text/partytown"

The browser doesn't know this type, so it doesn't run the script. Partytown finds it with a selector and runs it in the worker.

- <script src="https://third-party.com/script.js"></script>
+ <script type="text/partytown" src="https://third-party.com/script.js"></script>

Partytown is opt-in. Only the scripts with this type move. All the others stay where they are. You choose.

Rule 2: forward

Your own code still calls dataLayer.push(...) on the main thread. For example, when a user adds a product to the cart.

But GTM now lives in the worker. So Partytown needs to know which window functions to patch and send to the worker. That's the role of forward. It even queues the calls made before Partytown is ready.

flowchart LR
  A["Your code<br/>dataLayer.push(...)"] -->|"patched by forward"| B["Partytown<br/>(main thread side)"]
  B -->|"serialized message"| C["GTM<br/>in the web worker"]
  C -->|"network"| D["Google servers"]

By default, a forwarded call only runs in the worker. If you need the original function to also run on the main thread, use preserveBehavior:

partytown = {
  forward: [
    ['dataLayer.push', { preserveBehavior: true }], // runs on both sides
    'fbq'                                           // worker only (default)
  ]
};

Now let's have some code.

Angular

Our goal: run Google Tag Manager in the worker, and track page views and a click from our Angular app.

Step 1: install

npm install @qwik.dev/partytown

Step 2: serve the Partytown files

The worker and the service worker are real files. They must be served by your app. In angular.json, add them to the assets:

"build": {
  "options": {
    "assets": [
      {
        "glob": "**/*",
        "input": "node_modules/@qwik.dev/partytown/lib",
        "output": "/~partytown"
      }
    ]
  }
}

After a build, you should see a ~partytown/ folder in your output, with partytown.js, partytown-sw.js, partytown-atomics.js...

Step 3: `index.html`

Third-party scripts must be there early, before Angular starts. So we put everything in src/index.html:

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>My Shop</title>
  <base href="/">

  <!-- 1. Partytown configuration: BEFORE partytown.js -->
  <script>
    partytown = {
      forward: ['dataLayer.push']
    };
  </script>

  <!-- 2. Partytown itself: no async, no defer -->
  <script src="/~partytown/partytown.js"></script>

  <!-- 3. Google Tag Manager, moved to the worker -->
  <script type="text/partytown">
    (function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
    new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
    j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
    'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
    })(window,document,'script','dataLayer','GTM-XXXXXXX');
  </script>
</head>
<body>
  <app-root></app-root>
</body>
</html>

💡 While you set things up, use /~partytown/debug/partytown.js and add debug: true to the config. You get logs in the console. Don't ship the debug build to production.

Step 4: an analytics service

Now, our Angular code must talk to GTM. We only push to dataLayer. Thanks to forward, Partytown sends it to the worker.

// analytics.service.ts
import { DOCUMENT, Injectable, inject } from '@angular/core';
import { NavigationEnd, Router } from '@angular/router';
import { takeUntilDestroyed } from '@angular/core/rxjs-interop';
import { filter } from 'rxjs';

declare global {
  interface Window {
    dataLayer: unknown[];
  }
}

@Injectable({ providedIn: 'root' })
export class AnalyticsService {
  private readonly router = inject(Router);
  private readonly window = inject(DOCUMENT).defaultView; // null on the server (SSR)

  constructor() {
    // An SPA has no real page load after the first one.
    // So we send a page view on each navigation.
    this.router.events
      .pipe(
        filter((event): event is NavigationEnd => event instanceof NavigationEnd),
        takeUntilDestroyed()
      )
      .subscribe((event) => this.track('page_view', { page_path: event.urlAfterRedirects }));
  }

  track(event: string, params: Record<string, unknown> = {}): void {
    if (!this.window) return; // nothing to do on the server

    this.window.dataLayer = this.window.dataLayer || [];
    // This call is patched by Partytown: it's serialized and sent to the worker.
    // GTM does its heavy work there, not on the main thread.
    this.window.dataLayer.push({ event, ...params });
  }
}

Start it with the application:

// app.config.ts
import { ApplicationConfig, inject, provideAppInitializer } from '@angular/core';
import { provideRouter } from '@angular/router';
import { routes } from './app.routes';
import { AnalyticsService } from './analytics.service';

export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(routes),
    provideAppInitializer(() => {
      inject(AnalyticsService); // create the service, so it listens to the router
    }),
  ],
};

Step 5: track a click

// product-card.ts
import { Component, inject, input } from '@angular/core';
import { AnalyticsService } from './analytics.service';
import { CartStore } from './cart.store';

interface Product {
  id: string;
  name: string;
  price: number;
}

@Component({
  selector: 'app-product-card',
  template: `
    <h3>{{ product().name }}</h3>
    <button (click)="addToCart()">Add to cart</button>
  `,
})
export class ProductCard {
  private readonly analytics = inject(AnalyticsService);
  private readonly cart = inject(CartStore);

  readonly product = input.required<Product>();

  addToCart(): void {
    // 1. What the user wants to see: update the UI first
    this.cart.add(this.product());

    // 2. Tracking: cheap on the main thread, GTM works in the worker
    this.analytics.track('add_to_cart', {
      item_id: this.product().id,
      value: this.product().price,
    });
  }
}

Look at the click handler. Without Partytown, dataLayer.push wakes up GTM on the main thread, in the same frame as your click. With Partytown, the push is sent to the worker, and GTM runs its tags there. Your handler stays small. Your processing duration stays small.

React

Same goal, same app: GTM in the worker, page views and a click.

There are two ways to do it in React:

Option A: index.html, for a client-side app (Vite, Create React App...). The simplest.
Option B: the <Partytown /> component, for apps rendered on the server (React Router framework mode, Remix, Gatsby...).

Step 1: install and copy the files

npm install @qwik.dev/partytown

Partytown comes with a small CLI to copy its files into your public folder. Run it before dev and build:

"scripts": {
  "partytown": "partytown copylib public/~partytown",
  "dev": "npm run partytown && vite",
  "build": "npm run partytown && vite build"
}

Add public/~partytown to your .gitignore. It's generated.

Option A: client-side app (Vite)

Everything goes in index.html, like in Angular:

<!doctype html>
<html lang="en">
<head>
  <meta charset="UTF-8" />
  <title>My Shop</title>

  <script>
    partytown = {
      forward: ['dataLayer.push']
    };
  </script>
  <script src="/~partytown/partytown.js"></script>

  <script type="text/partytown">
    (function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
    new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
    j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
    'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
    })(window,document,'script','dataLayer','GTM-XXXXXXX');
  </script>
</head>
<body>
  <div id="root"></div>
  <script type="module" src="/src/main.tsx"></script>
</body>
</html>

Why not in a component? Because a client-side app renders late. The third-party scripts would wait for React to boot. In index.html, they're found as soon as Partytown starts.

Option B: server-rendered app (the `<Partytown />` component)

The package ships a React component: @qwik.dev/partytown/react. It's a thin wrapper around the Partytown snippet. The config becomes JSX props. And the snippet is inlined in the HTML, so there's no extra request for partytown.js.

Example with a root layout (React Router framework mode / Remix style):

// app/root.tsx
import { Partytown } from '@qwik.dev/partytown/react';
import { Links, Meta, Outlet, Scripts } from 'react-router';

const GTM_ID = 'GTM-XXXXXXX';

const gtmSnippet = `
(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer','${GTM_ID}');
`;

export default function App() {
  return (
    <html lang="en">
      <head>
        <Meta />
        <Links />

        {/* 1. Partytown: config as props */}
        <Partytown forward={['dataLayer.push']} />

        {/* 2. GTM in the worker */}
        <script
          type="text/partytown"
          dangerouslySetInnerHTML={{ __html: gtmSnippet }}
        />
      </head>
      <body>
        <Outlet />
        <Scripts />
      </body>
    </html>
  );
}

💡 Add debug={true} on <Partytown /> while you set things up.

Scripts added later

If a text/partytown script is added to the page after Partytown started (lazy loading, route change...), recent versions of Partytown (0.14.3 and later) find it automatically. On older versions, you have to tell Partytown:

const script = document.createElement('script');
script.type = 'text/partytown'; // set the type BEFORE adding it to the DOM
script.src = 'https://third-party.com/widget.js';
document.head.appendChild(script);

window.dispatchEvent(new CustomEvent('ptupdate')); // only needed before 0.14.3

Track page views and clicks

A small module, no library needed:

// analytics.ts
declare global {
  interface Window {
    dataLayer: unknown[];
  }
}

export function track(event: string, params: Record<string, unknown> = {}): void {
  if (typeof window === 'undefined') return; // nothing to do on the server

  window.dataLayer = window.dataLayer || [];
  // Patched by Partytown: serialized and sent to the worker
  window.dataLayer.push({ event, ...params });
}

A hook for page views:

// usePageView.ts
import { useEffect } from 'react';
import { useLocation } from 'react-router';
import { track } from './analytics';

export function usePageView(): void {
  const location = useLocation();

  useEffect(() => {
    track('page_view', { page_path: location.pathname + location.search });
  }, [location.pathname, location.search]);
}

Call it once, in your layout:

// Layout.tsx
import { Outlet } from 'react-router';
import { usePageView } from './usePageView';

export function Layout() {
  usePageView();
  return <Outlet />;
}

And the click:

// ProductCard.tsx
import { track } from './analytics';
import { useCart } from './useCart';

interface Product {
  id: string;
  name: string;
  price: number;
}

export function ProductCard({ product }: { product: Product }) {
  const { add } = useCart();

  function handleAddToCart() {
    // 1. UI first: this is what the user is waiting for
    add(product);

    // 2. Tracking: GTM does the heavy work in the worker
    track('add_to_cart', { item_id: product.id, value: product.price });
  }

  return (
    <article>
      <h3>{product.name}</h3>
      <button onClick={handleAddToCart}>Add to cart</button>
    </article>
  );
}

Using Next.js? Partytown has its own Next.js integration page. Check it, the setup is a bit different.

Check that it works

Don't trust, verify. Three quick checks in Chrome DevTools:

Console: with the debug build, Partytown logs what runs in the worker.
Sources panel: look at the threads. GTM should run in the Partytown web worker, not in the main one.
Performance panel: record a page load and a few clicks. The long tasks from googletagmanager.com should be gone from the main thread track.

Then check in GTM Preview mode that your page_view and add_to_cart events arrive. If nothing arrives, check your forward config first. It's the most common mistake.

Where INP really wins

Let's go back to our three phases.

               Input delay     Processing      Presentation
               ───────────     ──────────      ────────────
Partytown:     big impact      some impact     small impact

Input delay: the big win. Third-party long tasks no longer block the main thread, so the click is handled right away.
Processing duration: the work done by third-party scripts when you push an event (like in addToCart) happens in the worker, not in your handler's frame.
Presentation delay: Partytown batches DOM reads and writes into group updates. Less layout thrashing from third-party code.

Trade-offs: no magic here

Partytown is a great tool. It's not a silver bullet. Here is what you need to know before using it.

preventDefault() has no effect. When the worker receives the event, it's already too late. A script that needs to block a link or a form submit won't work.
DOM operations are throttled. Each call crosses threads. That's fine for analytics, not for scripts that build UI.
UI-heavy scripts are a bad fit. A chat widget, a cookie banner with a dialog, anything that injects a lot of DOM nodes: keep them on the main thread.
CORS. Some third-party scripts don't send the right CORS headers. You'll need to proxy them.
Cross-origin iframes created from a Partytown script can't persist cookies or storage.
Bad scripts stay bad. A script that reads the whole document every X milliseconds with setInterval will overload Partytown.

A quick rule:

Good fit ✅	Bad fit ❌
Google Tag Manager	Chat widgets
Google Analytics 4	Cookie consent dialogs
Facebook Pixel	Scripts that call `preventDefault()`
Mixpanel, Segment, Amplitude	Scripts that inject a lot of DOM

Measure, don't guess

Never move a script "because it should be better". Measure before, measure after.

INP is a field metric. Your real users on real devices are the source of truth. Use the web-vitals library with the attribution build to see which phase is slow. It works the same in React and Angular:

import { onINP } from 'web-vitals/attribution';

onINP(({ value, attribution }) => {
  console.log('INP:', value);
  console.log('Element:', attribution.interactionTarget);
  console.log('Input delay:', attribution.inputDelay);
  console.log('Processing:', attribution.processingDuration);
  console.log('Presentation:', attribution.presentationDelay);
  // send it to your analytics
});

Put it in main.ts (Angular) or main.tsx (React).

Here's how to read the result:

High input delay? Look at what runs before the click. Third-party scripts are the usual suspects. This is where Partytown shines.
High processing duration? It's probably your handler. Partytown won't help.
High presentation delay? Look at your DOM size and your layout.

In the lab, INP depends on what you click. Two tips:

Interact with the page while it loads. That's when the main thread is the busiest.
Use Total Blocking Time (TBT) as a proxy. It's not INP, but it tells you if the main thread is crowded.

Partytown won't fix your own code

If your click handler takes 400 ms, moving GTM to a worker changes nothing.

For your own code, the classic tools still apply:

Break long tasks into smaller ones.
Yield to the main thread (setTimeout, or scheduler.yield() where it's supported).
Show visual feedback first, do the heavy work after.
Move heavy computation to your own web worker.

Partytown handles the code you don't own. You handle the code you own.

Conclusion

INP measures what users feel: "I clicked, did something happen?"

Third-party scripts are often the hidden reason for a bad INP. They take the main thread, and your users wait.

Partytown moves them into a web worker, and keeps them working thanks to a clever synchronous bridge (Atomics or a service worker).

In Angular and React, the setup is small:

serve the Partytown files
add the config and type="text/partytown"
forward the functions your code calls
keep your tracking code as simple as a dataLayer.push

It's not magic. It's in beta, it has trade-offs, and it's not made for UI scripts. But for analytics, tag managers and pixels, it can give the main thread back to the only code that should be there: yours.

Measure first. Move the right scripts. Measure again. 🎉

The Grand Unifying Architecture of Frontend

Ryan Carniato — Tue, 22 Sep 2026 16:43:06 +0000

I used to joke that the history of frontend development could be retraced by following the argument of who owned the state. And the truth is both sides have gone back and forth on this over the years. We started on the document web where state was on the server. Then we added JavaScript and Applets where we could have stateful things in the client. But developers at the time didn't like either much and tried to wire state across both sides in their server languages and we got ASP.NET and the like.

I sit here over 30 years later and it is still going on. Going to replace your React app with HTMX? Maybe. Maybe it isn't that simple. Although this seems like an endless spiral, I don't think this is unsolvable. Even though it has been going on so long, I actually think the answer is in front of us.

The unified model comes down to understanding responsibilities. And they are as old as the web itself. Every time we misalign complexity soars. Every time we ignore part of the puzzle it goes on to bite us. Every solution straddles part of this solution space but we've struggled to cover the whole range.

Core Responsibilities

My observation is that all frontend architectures come down to layering of three responsibilities. Some are more present than others but they all exist in some form.

1. Navigation (client)

The URL is the basis of the web experience and it belongs to the browser. Orchestration is a client responsibility and every solution from SPA to HTML partial agrees with this. JavaScript in the browser is the root of our application.

2. Content (server)

Conversely, content belongs to the server whether it is markup or JSON. The server is the authoritative source. It hangs off of our navigation.

3. Affordances (client)

Affordances find us back in the browser. Local UI state, in progress work, optimistic updates. We need to provide our user feedback faster than a round-trip to the server.

Following the Shape

All web application architectures follow this client -> server -> client layering. A user navigates or performs an action, content comes back from the server, and the client settles it. That's the Single Page Application(SPA) architecture after load, but it's also HTMX. And also LiveView, if the server -> client protocol is powerful enough.

It feels like I'm stating the obvious here. But the web generally maps writes to navigation, and the server only pushes reads. Mutations travel through layer 1 with forms, actions, invalidation, and requests for the content. Layer 2, content, never writes and only publishes.

This asymmetry is what makes it composable. Breaking that leads to two stateful systems fighting against themselves. Which is why affordances like optimism(layer 3) fit cleanly on top if viewed as an overlay. The client never writes server content directly as it doesn't own it.

Revisiting the Spectrum

I've tried many times to map the solution space to a 4 quadrant grid but I never found the right axis. But I'm now seeing how all solutions can sit in the same diagram.

Obviously this is a rough placement, solutions fit spaces not points, and something like React can be used as a frontend in a sync engine like Zero. Here React represents classic SPAs + JSON API. But most frameworks fix both transport and affordance weight so they don't move much.

But if you put it under our lens of responsibility:

HTMX: Minimal layer 1, HTML carries the majority of the work under layer 2, and layer 3 is almost nothing.
LiveView: Layer 2 expands its capability, while layer 3 remains nearly non-existent. Same dance with the read window stretched to the length of the session.
DataStar: More machinery in layer 2 with the addition of server populated Signals allowing for some closer interaction with the client.
Astro(+ View Transitions): navigation(view transition) -> server(markup) -> client(islands). All 3 parts laid out explicitly.
Server Components(Next.js): Like Astro except shared client state is preserved.
SPA + JSON(React): Layer 3 grows until it merges with layer 1. And layer 2 is delegated to JSON APIs.
Sync Engine(Zero): Layer 2 becomes a persistent read of a replicated store, and layer 3 grows to hold a full local copy of it. Optimism over the whole dataset.

Every solution, with a bit of coaxing, is capable of expressing all of these. They differ in transport, window length, and how much affordance code you ship. So it comes down to efficiency and authoring. Which means one framework could cover it all, if each responsibility is adjustable.

A Modern Take

Nothing I've laid out is any different than how the base platform has always worked, but can we mirror this in a way that encompasses the full spectrum of the past 30 years?

I'm going to paint a picture using our 3 responsibilities with Solid 2.0.

Navigation: Delegation and progressive enhancement

Solid's router owns nothing in the render tree. There is no <Link>(or <A>) component. Instead our JSX compiler registers a claim on every a[href] and form[action] element it creates, and server-streamed content gets the same claims swept over any subtree the runtime renders.

// lib/users.ts
export const renameUser = action(
  async (id: string, formData: FormData) => {
    "use server";
    updateUser(id, { name: String(formData.get("name")) });
  }
);

// routes/users/[id].tsx — plain HTML. The compiler claims the
// anchor and the form. The router intercepts both. Works before 
// hydration and after.
<a href={`/users/${id}`}>{user().name}</a>
<form action={renameUser.with(id)} method="post">
  <input name="name" value={user().name} />
  <button>Rename</button>
</form>

Note: There are no components in this markup.

A SolidJS router consumes those claims to manage aria-current, active classes, and interception. This means server-rendered markup with zero client components participates fully in client-side navigation. So it works not only with "No JS" but with JavaScript with no interactive components.

Forms and buttons delegate to server function actions the same way. You hoist your preloads and invalidation correctly and single-flight mutations mean one round trip settles every piece of UI the mutation invalidated whether that UI is JSON-fed client components or server-owned markup.

Content: Reactive reads over the wire

Solid's powerful protocol for layer 2 stands on our "use server" functions. Solid serializes across the boundary with Seroval, which handles not just plain data but async structures, like Promises and async iterators. The communication between server and client is about the data, including data that hasn't settled yet.

export async function report(id: string) {
  "use server";
  return {
    title: await getTitle(id),
    // AsyncIterable<string> — crosses the wire as-is
    progress: watchProgress(id), 
  };
}

// client: the iterable's latest yield is just a reactive read
const r = createMemo(() => report(props.id));
const progress = createMemo(() => r().progress);
<h1>{r().title}</h1>
<p>{progress()}</p>

More than that, the reactive graph propagates over the wire. On the server, every expression feeding the client is an open binding for the life of the response. When a promise settles or iterator yields the server re-runs the expression and sends the new value to the client to be replaced or morphed.

So far I've showcased this in examples around the original response, ie what happens during hydration. Even if the content chunks stream in as they initially are ready, we can continue to update the stream in place as long as the request stays open.

But the same can be true of server function requests after the fact. We can send back would-be static markup, "Server Components", and have their reactive graph never ship to the client while still doing these streamed pinpoint updates. We will be announcing the preview for our Server Component feature soon (but if you look you can already see fully working examples in our repo).

export async function countdown(n: number) {
  "use server";
  const ticks = tick(n); // AsyncIterable<number>, one per second

  // returning a function returns a Server Component
  return () => {
    const count = createMemo(() => ticks);
    return <p>Counted to {count()} of {n}</p>;
  };
}

// client — zero component code ships for this
const Counter = dynamic(() => countdown(10));
<Counter />

Because the communication is one-way with a single authoring model, the transport is pluggable. Today we use Request/Response, so it lives as long as the request is open and you reconnect as needed. Swap in something persistent like SSE or a socket and the same server component becomes a non-terminating live component.

// request/response — left side of the grid
export const getAuction = GET(async () => {
  "use server";
  return read();
});

// persistent — right side of the grid
export const liveAuction = live(async function* () {
  "use server";
  while (true) { yield read(); await changed(); }
});

// the consumer doesn't care which one it got
const [auction] = createOptimisticStore(() => liveAuction(), {});

What makes this safe is what LiveView's failure mode teaches us: The server's live graph must be a re-derivable projection of durable state. It is never the source of truth. Reconnection doesn't depend on sessions, event replay, or anything that dies with a process.

Affordances: An async-aware graph that hydrates once

This is an area SolidJS has excelled in. But in 2.0, async became native to the graph. A value arriving from the server content channel and a value computed locally are indistinguishable to the consumer.

Optimism is a first-class primitive. It isn't just something bundled with the server functions or query caching library. Optimism represents any uncommitted state predicted over async, whatever the async source. It's a general concept. It doesn't just represent what some might consider "lying to the user", it doesn't have to masquerade as an invisible success. It represents any predictive ephemeral affordance. It either settles eventually as truth or it is reverted, but it never outlives its transaction. It prevents getting out of sync.

const [auction, setAuction] = createOptimisticStore(() => liveAuction(), {});

const placeBid = action(function* (amount: number) {
  // overlay — reverts on settle
  setAuction(a => { a.highBid = amount });
  // mutation - the write goes up
  yield bid(amount);
  // hold until truth comes back down             
  yield until(() => auction.highBid >= amount);
});

This all works because we never hydrate more than once. After startup, the server should never render a client component as client state has diverged from anything the server could know. This is a critical naive breaking point in HTML Partial and Islands solutions that share client state. Hydrating after state has updated is a recipe for hydration mismatches. While we can safeguard during the initial streaming progression, that isn't a realistic proposition over the life of an application.

A rule like that only holds if the system enforces it. Every piece of server content is keyed by the call that produced it, the function and its arguments, the same key a query cache would use. Content arriving on any transport only ever writes to that address's store, and mounted UI pulls from the address it's bound to. There is no direct connection from the network to the DOM. So a hover preload can't clobber the page you're looking at, a refetch morphs in place while the client-owned ranges inside it survive, and a stale response doesn't pass a version check.

Under this unified model, initial load gets the same treatment without paying serialization twice. Client components claim their server-rendered nodes and boot makes zero requests. The only serialized records are values the client requires. Server-only content ships as HTML or as data, never both. The page markup is the payload. For server components, that means always one copy. View-source and search for any piece of content and you'll find it exactly once.

I once positioned this as "Facing Frontend's Existential Crisis", but now it is a solved problem.

Traversing the Spectrum

What makes this exciting is with the pieces above you are completely free to move the whole solution space and every point in between.

If you start in the lower left corner, that would be like a SolidJS app with no client components that just swaps server component chunks on server "use server" actions bound to <form action>. Server markup streams and morphs, and navigation is handled without any client components.

The top left-hand side is when we extend layer 3 until it dominates and you have the SPA and there are no server components or server rendering at all. Just JSON APIs.

And we can continue to traverse over the top to the right-hand side by the way of persistent "use server" functions and our granular optimistic layer. Solid's live and until operators help close the gap when the client state is streamed in as available. I'd still use a dedicated sync engine, but the base primitives alone do a good impression.

Finally, the lower right corner, is closer to where we started. Except this time our server components have reactive bindings and their connection is persistent. No client components, just our same "use server" action protocol to write back, while our reads stream fine-grained markup partials over the wire. In this world, even the server components could be optimistic depending on how you write your actions, and until again gives us a mechanism for completion acknowledgements.

The incredible part is that this required nothing that users of Solid 2.0 aren't already familiar with. Async Signals and use server. With that, all these experiences are authorable using basically the same patterns, in the same framework, even in the same application.

Conclusion

It goes back to where we started. A few pieces that have been sitting in front of us this whole time.

The browser owns navigation and affordances. The server owns content. Communication is a loop with writes travelling as navigation and content travelling as one-way reads. And the transport and the response window should be configurable without changing the shape of authoring.

Everything from HTMX to LiveView to islands to the SPA is a coordinate on this grid. The differences between them are efficiency and ergonomics rather than expressiveness.

What makes this more than an exercise in categorization is that all the hard pieces are built. We serialize and hydrate once. The reactive graph serializes its own updates. Content is stored by address, so stale hydration can't be represented.

It comes as little surprise to me that Signals can act as that common representation on all sides. Sync and async. Server and client. Stateful and stateless.

This is stupidly ambitious. RSCs only aimed to provide the left half of the grid and many felt they still fell short. The HTML-over-the-wire camp has aimed to provide the bottom half, but ignoring the client is ignoring an entire responsibility.

And yet, this is a future that I want to live in. One where choosing a framework doesn't require you to choose a religion. And one, from my perspective, that is already here.

SpellBook of Skill: The Twin Project Nobody Asked For, But I Built Anyway 🧙🏻‍♂️

Domenico Tenace — Mon, 21 Sep 2026 07:00:00 +0000

Overview

Hey everyone 👋

A while back I launched Spellbook of Prompt, my curated collection of prompts organized by use case. It's been out there growing steadily, and at some point while adding new entries I kept thinking: prompts are only half the story. Knowing how to build something matters just as much as knowing what to ask an AI to do.

So I built the twin project. Meet Spellbook of Skill, a curated collection of development skills, tutorials, and guides to help you level up your craft from fundamentals to advanced techniques.

Let's dive in! 🤙

What It Actually Is 🤔

Where Spellbook of Prompt gives you the incantation, Spellbook of Skill teaches you the magic behind it. It's structured, practical guides organized by category and difficulty, each one built to save time and actually get you somewhere, not just another wall of theory.

Every guide follows the same shape: a clear learning objective, a working code example, prerequisites listed upfront, and a troubleshooting section for when things inevitably don't work on the first try. The concepts are language and framework agnostic where possible, so what you learn actually transfers instead of being locked to one stack.

The whole thing runs on Astro with Starlight, same setup as Spellbook of Prompt, so browsing is fast and the docs feel consistent across both projects. It's a genuine sibling project, same philosophy, different content.

Built Entirely with OpenCode + OpenRouter + DeepSeek V4 Pro 🛠️

Here's the part that ties back to everything I've been writing about lately. I built Spellbook of Skill end to end using OpenCode wired through OpenRouter, running on DeepSeek V4 Pro 0813.

No manual scaffolding, no switching to a pricier model halfway through. The project structure, the Astro and Starlight configuration, the content schema, the initial category setup, all of it came out of that same combo I've been using as my daily driver. If you've read my previous pieces on DeepSeek's cost-to-quality ratio or on wiring OpenRouter into OpenCode, this is that setup doing real, shippable work again.

It's honestly become my proof of concept for "can a budget model stack actually ship a complete open source project." So far the answer keeps being yes.

What's In There Right Now 📚

The structure is organized by category, starting with:

Content Creation, structured prompts and guides for writing clear technical articles, the same kind of workflow I use for these posts.

More categories are marked as coming soon: coding and development workflows, DevOps and deployment, system design and architecture, design and creative development, career and professional growth.

It's early. I'd rather be upfront about that than oversell it. The foundation, the docs site, the contribution flow, the conventions, is all solid and ready. The content library is what needs to grow now, and that's exactly where the community comes in.

This Is Where You Come In 🤝

Spellbook of Skill is MIT licensed and genuinely open to contributions. Whether you want to add a new guide, improve an existing one, or just fix something that's broken, there's a clear path to do it.

The process is simple: search existing guides first to avoid duplicates, add or update a guide in the right category folder, include a clear title, description, and at least one complete working example, then open a pull request with a short summary. Guides should stay concise and actionable, list prerequisites and learning objectives, include a troubleshooting section, and obviously never contain real secrets or sensitive data.

Full details are in the CONTRIBUTING.md file if you want the complete picture before jumping in.

If you've got a skill you wish someone had written down clearly when you were learning it, that's exactly the kind of guide this project needs. Beginner content is just as valuable as advanced content here.

Try It Out 🚀

The live docs are up at spellbook-of-skill.netlify.app, or clone it and run it locally:

git clone https://github.com/Domenico-Tenace-Open-Labs/spellbook-of-skill.git
cd spellbook-of-skill
pnpm install
pnpm dev

Then open localhost:4321 and start browsing.

Final Thoughts 🌟

Spellbook of Prompt and Spellbook of Skill now sit side by side under Domenico Tenace Open Labs, one teaching you what to ask, the other teaching you how to actually do it. Together they cover more ground than either could alone.

If you're curious about the project, go star it, and if you've got something worth teaching, open a PR. This is exactly the kind of thing that gets better the more people show up.

The spellbook grows. 🔥

Happy coding! ✨

Hi 👋🏻
My name is Domenico, software developer passionate of Open Source, I write article about it for share my knowledge and experience.
Don't forget to visit my social links to discover my links, check out Domenico Tenace Open Labs for my open source projects and subscribe to my newsletter! 🫰🏻

🌲 Links: https://links.domenicotenace.dev/
🐙 Domenico Tenace Open Labs: https://github.com/Domenico-Tenace-Open-Labs
📰 Newsletter: https://domenicotenace.substack.com/subscribe

If you like my content or want to support my work, you can support me with a small donation. I would be grateful 🥹

☕ Buy me a Coffee: https://buymeacoffee.com/domenicotenace

OpenCode + DeepSeek V4: The Budget Combo That Doesn't Feel Like a Budget Combo 🐋

Domenico Tenace — Tue, 01 Sep 2026 07:00:00 +0000

Overview

Hey everyone 👋

I've spent the last few weeks running most of my daily coding work through OpenCode wired to DeepSeek V4, both Pro and Flash. Not as an experiment, as my actual default setup. And the thing that keeps surprising me is how rarely I miss Claude or GPT for everyday tasks, while paying a fraction of the price.

I also used DeepSeek exclusively to generate an entire Astro template from scratch, Studio Pulse, which turned out to be a genuinely good test of what these models can actually do unattended.

Let me walk you through what I found. Let's dive in! 🤙

Quick Context on DeepSeek V4 🤔

DeepSeek V4 is an open weight, MIT licensed model family that went GA in two waves this year, V4-Flash on July 31 and V4-Pro on August 13. Both are mixture of experts models with a 1M token context window.

V4-Pro runs 1.6T total parameters with 49B active per token. V4-Flash is leaner, 284B total with 13B active. Both support tool use, function calling, and a thinking mode that effectively replaces the old R1 reasoning line.

The current API pricing sits at $0.435/$0.87 per million input/output tokens for Pro, and $0.14/$0.28 for Flash. Cache hit input drops even further, down to $0.0036 for Pro and $0.0028 for Flash. For context, Claude Opus output alone costs $25 per million tokens. A dollar buys you roughly 500K off-peak output tokens from V4-Pro, versus 40K from Opus.

That's not a small gap. That's an order of magnitude.

Setting It Up with OpenCode 🔧

Since OpenCode is model agnostic, plugging in DeepSeek is just a matter of pointing it at DeepSeek's API endpoint (or routing through OpenRouter, which I also do for some workflows). No special configuration, no compatibility layer, it speaks both OpenAI ChatCompletions and Anthropic API formats natively.

I keep both models available and switch depending on the task:

DeepSeek V4 Flash for quick iterations, small fixes, boilerplate, and anything where speed matters more than depth.

DeepSeek V4 Pro for anything that needs real reasoning, architecture decisions, or larger refactors.

Switching between them mid-session in OpenCode takes one command. No restart, no reconfiguration.

What Actually Impressed Me 👍

The cost is almost absurd. Running a full day of development work, dozens of file edits, multiple refactoring sessions, test generation, through V4-Pro costs me less than a coffee. Through V4-Flash it's closer to pocket change. I stopped thinking about token budgets entirely, which changes how you work. You stop being conservative with your prompts.

Coding quality holds up. On Artificial Analysis benchmarks, V4-Flash scores 69.1 on the coding index, ranking 29th out of nearly 200 models tracked. That's genuinely competitive, not "good for the price," just good. For everyday tasks, boilerplate, CRUD logic, component generation, API routes, I couldn't tell the difference from more expensive models in blind use.

The 1M token context window is a real advantage. Both models default to a million tokens of context. For large codebases or long refactoring sessions where you want the model to see everything at once, this matters more than raw intelligence scores.

Tool use and function calling are solid. Agentic workflows in OpenCode, file edits, shell commands, multi-step tasks, worked reliably. I didn't run into the kind of tool-call confusion I've seen with smaller open models in the past.

Cache hit pricing rewards good habits. If you structure your prompts with static content first and variable content last, DeepSeek's caching drops input costs by roughly 88%. That's a meaningful incentive to write better prompts, and OpenCode's session handling makes this easy to leverage naturally.

Where It Falls Short 👎

Agentic capability trails coding capability. DeepSeek themselves and independent reviews are honest about this: the model handles individual coding tasks well, but complex autonomous multi-step processes need tighter task boundaries and more validation than you'd need with Claude Opus or GPT-5.5. Long, loosely defined agent runs are where it's more likely to drift.

No image or video input. V4 is text and code only. If your workflow involves reviewing screenshots or mockups, you're switching models anyway.

Pricing isn't fully stable. DeepSeek has already signaled a broader price increase without publishing new rates yet, and peak/off-peak tiers were introduced in mid-August. The eye-popping pricing I quoted above could shift. Budget for it, but don't assume it's permanent.

Less polished on ambiguous instructions. When a prompt is vague, DeepSeek tends to make more assumptions than Claude does. Being explicit about what you want pays off more here than with pricier models that are better at inferring intent.

Reasoning depth on genuinely hard problems. For architecture decisions with lots of competing trade-offs, V4-Pro is good but not at the level of the very top tier models. I still occasionally reach for something stronger when the stakes are high enough to justify the cost difference.

The Real Test: Studio Pulse 🚀

To really push this setup, I built Studio Pulse entirely through DeepSeek, no manual coding, no assist from another model.

It's a template for a full-service communication agency marketing site: multi-page structure with home, about, blog, and contact, dark and light mode with OS preference detection and persistence, SPA-style page transitions via Astro's ClientRouter, a blog powered by content collections with typed frontmatter, and accessibility handled properly, skip links, semantic landmarks, focus-visible outlines, reduced-motion support.

Stack is Astro 7 with Bulma 1.0.4, statically generated, dependency-light, pnpm as the package manager. Clean project structure, typed content schema, CSS custom properties for theming.

What stood out building it: DeepSeek handled the Astro-specific patterns (content collections, the loaders API, client router transitions) correctly on the first or second pass most of the time. The accessibility details weren't an afterthought either, I asked for them once early in the process and the model kept applying them consistently across new pages without being reminded.

It's live at studio-pulse-demo.netlify.app, MIT licensed, and available as a GitHub template if you want to spin up something similar.

Who Should Try This Combo 🎯

If you're cost-conscious and building things where "good enough" coding quality is genuinely enough, which is most day-to-day development, this setup is hard to beat. Side projects, templates, internal tools, prototypes, all of it fits well within DeepSeek's strengths.

If you're running agent pipelines at scale where token costs actually matter to your bottom line, the math here is compelling enough to at least test against your current model.

Where I'd still reach for something else: safety-critical code, deeply ambiguous architecture decisions, or long autonomous agent runs with minimal supervision. That's where the extra cost of a stronger model still earns its keep.

Final Thoughts 🌟

I didn't expect to make DeepSeek V4 my daily driver, but that's what's happened. Between OpenCode's flexibility and DeepSeek's pricing, the barrier to just trying things dropped to nearly zero, and that changed how much I experiment.

Studio Pulse is proof that a fully model-generated project doesn't have to feel like a rough draft. It's not a toy, it's an actual usable template with real attention to detail.

Is DeepSeek the best model on the market right now? No. Is it the best model per dollar? By a wide margin, yes. And for most of what I build day to day, that's the metric that actually matters.

Happy coding! ✨

🌲 Links: https://links.domenicotenace.dev/
🐙 Domenico Tenace Open Labs: https://github.com/Domenico-Tenace-Open-Labs
📰 Newsletter: https://domenicotenace.substack.com/subscribe

If you like my content or want to support my work, you can support me with a small donation. I would be grateful 🥹

☕ Buy me a Coffee: https://buymeacoffee.com/domenicotenace

Nobody Argued For Your Stack

Ryan Carniato — Thu, 27 Aug 2026 18:34:44 +0000

Last week, it came to light Cursor had mostly finished migrating from SolidJS to React. This migration happened about seven months ago. But it became a central focus of discussion following the Solid 2.0 RC release. Then yesterday, a week later, it came to my attention that the Anthropic docs example command for their large-scale migration feature is:

I admit that my gut reaction was not great. Out of all the examples they could have chosen... Years of my work became a canonical example of the thing you migrate away from — in the same week we shipped the biggest release in the project's history — stung in a way I won't pretend it didn't. My second reaction was to assume that, like the other trickle-down posts I'd seen this week, this rode the same week-old news cycle.

Then I checked the Internet Archive and realized this has been there since at least April 2026. Four months before the Cursor story broke. At this point, the whole public footprint was a mention of an experiment sandwiched between bigger updates in a Cursor blog post posted in January. The kind of thing that no one outside the industry would even really pick up on. No reasoning, no benchmarks, no argument.

Stop to think about what that means. I should be careful here because I can't prove anyone at Anthropic ever read that Cursor post. Nobody can. Maybe a docs writer saw the experiment. Maybe Claude drafted its own example. But think it through. Either it traveled from a buried line in one company's release notes into another company's official docs, or it needed no origin at all. It was already assumed before any public migration existed.

Our industry has quietly started broadcasting conclusions where it used to transmit arguments. We couldn't have picked a worse time, because — as I'll get to — arguments are the only source that still matters.

Why This Matters More Than It Used To

It would be fair to ask, hasn't it always been like this? Teams cargo cult large players. Netflix or Facebook uses this predates AI by decades. Optics and politics have always beaten pure technical merit. The weight of Facebook definitely helped React's early propagation.

But a narrative used to come with friction. It was always in the race, but it couldn't outrun the argument. This has changed for two reasons:

First, execution cost has collapsed. Bun's rewrite from Zig to Rust — about a million lines — was executed almost entirely by Claude agents in days, not months. And before you start thinking "lock-in", going the opposite way, while not as easy, has never been easier. Migrating from Rust to Zig or React to Solid has never been easier.

That sounds like good news. And it is. When migrations took years of human effort, cost put a damper on fashion. Now execution is a lot cheaper in all directions. The only thing left is the reason. Which suggests, on the surface, these decisions should be rooted in technical merit. But when narrative is what sets the direction, you start to see how a line buried in documentation is worth an essay.

Second, verdict production has been industrialized. Cognition just migrated its marketing site from Astro to Next.js. A content site. Astro's home turf, by near-universal consensus, including from people with no stake in the fight. The migration was performed by Devin itself and published as a case study: the agent made the changes, tested them, recorded its own verification runs. No repository, no before-and-after numbers, no benchmark. The output wasn't the site. It was the story.

And believe me, there is no shortage of these stories. Migrations are now the demo genre of the agent industry. Theo Browne was trying to tell me this a couple weeks back with some very good advice. But it hits a lot harder when you feel it firsthand. Migrations that demo flawlessly are, by definition, the ones moving toward what the agent writes best today. Marketing departments are generating "X → dominant library" verdicts at a rate organic engineering decisions never would.

So you see the tension. Stacks have never been more sensitive to circulating verdicts, and verdicts have never been produced faster or with less reasoning attached.

What an Argument Looks Like

These aren't unheard of. They are just becoming rarer.

When Bun moved from Zig to Rust, Jarred Sumner made the case in public, with receipts. He talked about bug classes and memory management issues. You can disagree with the argument. People have, point by point, in public. That's the value. An argument can be engaged, checked, narrowed, refuted, or strengthened. A verdict can only be repeated.

Or look at TanStack's journey with React Server Components on tanstack.com. They spent the year almost arguing with themselves. When tanstack.com adopted React Server Components, they wrote it up and measured it. When they stopped using them, they did the same: What changed, what replaced it, why the tradeoff flipped for their specific case — while TanStack Start went right on supporting RSC as an opt-in primitive for everyone else. The reversal post calling the decision "uneventful" is a tell. A public reversal on React's flagship architecture, and it generated insight instead of heat. Because they delivered analysis instead of verdict.

That's what evaluation entering the public record looks like. jQuery didn't lose to React because a training set said so. It lost an argument, in public, on merit over several years. Every library you respect got where it is by winning that kind of fight. The flow of events I described earlier doesn't hold fights. It holds direction, and compounds on it.

The Argument Nobody Published

In all fairness, Cursor never issued a verdict. An experiment that "still needs careful review", then a congratulatory post on the Solid 2.0 RC release. But that post still characterized signals as "perf footguns" and "accidental fan out" — no numbers, nothing to engage — and reached straight for the React Compiler as the cure. No bad faith required. The diagnosis and the cure just came from the same place.

When I tried to reconstruct the case Cursor could have made, it turned out to be interesting. Far more interesting than "perf footguns."

The post obviously highlighted agents were "quite bad at writing good Solid code," everything "ended up being accidentally tracked." While my "Solid-brain" struggles a bit to imagine what they were doing to get there, I don't doubt it for a second. An agent that has internalized React's mental model will write Solid like React, and Solid written like React is bad Solid. I've also seen the reverse. The difference is when the agent fumbles React, the training data catches it. When it fumbles Solid, the training data shrugs. This is a pure numbers game.

But the same post contains a decision in the opposite direction. They're also moving from Tailwind to StyleX. This is a migration against volume. What StyleX offers instead is that agent mistakes get caught. Styles are typed with deterministic merge order, so a hallucinated class is a build error.

Put side by side, one conclusion can be made: make agents' mistakes cheap. Two ways to achieve that. Volume and verification. React (with its compiler) wins on volume and arguably on verification. StyleX loses on volume and wins decisively on verification. I won't pretend under this lens with Solid 1.0 this is a particularly comfortable place for signal-based reactivity. But it's also, not coincidentally, where Solid 2.0's design attention has gone.

That analysis, volume and verification as two axes, is concrete, checkable, and useful. It implies testable claims and gives every framework author a design target. It might also be wrong. I reconstructed it from a benchmark-free post and my own inferences. Cursor's actual reasoning may be entirely different.

The StyleX decision is even more interesting. Agent-driven development can move against volume when verification wins. There is a second angle that small technologies can embrace. To me, this isn't a new revelation, but one where practice confirms theory.

What Happens If Nothing Changes

If you follow this thinking to its logical conclusion, outside of a few exceptions, each layer collapses on its most popular solution today. Frontend converges on React. Systems converges on Rust. Scripting converges on Python. Even the sites that are just pages converge on Next, fit be damned. That's a monoculture, arrived at not by anyone deciding libraries on their merits, but by a system that can no longer distinguish "abundant in the training data" from "better."

If you are a React fan, you should still be concerned. React was good because it had competition. Hooks arrived in a world where composition patterns were being explored. The React Compiler exists, in part, as an answer to the question signals-based frameworks spent years forcing: Why should the developer pay for re-rendering the world? React's greatest strength has always been its ability to metabolize pressure from outside. A monoculture doesn't just kill the alternatives. It kills the pressure. An ecosystem without pressure doesn't stay good. It stays stuck.

There is a path back. Teams publish analysis, not verdict. Model vendors evaluate what they ship in public. Libraries learn from StyleX's example and bank on verification. And the rest of us learn to distinguish output from argument before we amplify it. The last one we've been struggling with since the dawn of social media.

In the meantime, we can keep generating our rules files, llms.txt, docs over MCP, curated examples. We do all of it for Solid 2.0, and it helps a lot. But context is borrowed, not owned. It has to be injected into every session, by every tool, forever, while the inertia works against you for free.

Where Does the Next Idea Come From?

I want to leave you with a more probing thought. The question this all comes down to isn't whether Solid survives. We're fine. We are shipping the biggest release in our history, with a community that chose this framework on purpose and, more importantly, knows why.

The question is where the next idea comes from.

Every paradigm that has mattered started as something the establishment couldn't write. React was mocked for almost a year over JSX. Markup in JavaScript? Are you insane? What about separation of concerns? If today's machinery had existed in 2013, models trained on a web that was all jQuery and Backbone, docs canonizing migrations everyone was already making, verdicts circulating months ahead of their arguments, do you think it could have gotten past that stage?

It didn't win because the defaults favored it. It won because people made a verifiable case in public. And I don't think the mechanisms are gone. Migrations have never been cheaper, in every direction. The door out of any monoculture has never been more open. We just need to keep analysis as part of the conversation even as we distance ourselves from the implementation. That's being informed. That's taking responsibility.

My AI Content Journey

Ryan Carniato — Wed, 19 Aug 2026 16:47:10 +0000

I apologize ahead of time, what follows has no tooling applied to it. No grammar checks, no AI, and no edit passes for flow. It might be a bit rough, but that's important.

For those who know me, I've written hundreds of articles over the last 8 years. I realized very early into my journey of creating SolidJS that education was going to be a fundamental barrier. React's rhetoric had consumed the frontend space in such way that the discussion of different ideas was not welcomed warmly. It may have started with the ideas, but the complexity of the move to modern tooling had left many feeling overwhelmed. The term "JavaScript Fatigue" was being thrown around, and those who didn't sneak in before 2016 were subject to it.

My early writing was rough. I mean really rough. I'd try to articulate my ideas, but they were hard to translate. It wasn't that I didn't have decent command of the English language. I always had done well in school. But the ideas I wanted to articulate extended past code examples. They borrowed from years of observations and cross discipline learning. It would take the span of a whole article for me to get my point across and it was really easy to get lost in the details.

It didn't help that I wrote like I talked. Which is rather disjointed. When I used to type messages on ICQ and MSN back in the day I'd keep thumbing the "." as a way to convey to the recipient the pacing. The more "..." the longer the pause. I had needed to communicate at work, obviously and had gotten used to rewriting my emails on average three times so that I could cut out things that were unnecessary.

So I published my earlier articles on Medium in 2018 and fortunately for me, the early Solid community on Gitter and Spectrum started providing me edits. This pattern of reviewing my articles with the community never went away. Most of my articles today still appear in the Solid Discord days before publishing.

Stepping up my Game

At some point, a community member suggested I pick up Grammarly. Honestly, it was such a huge help. I always skipped words and commas in certain places. Given I had the free tier it would also hint when I phrased something a lot oddly so I could at least give a shot at rewriting it.

This was better but honestly it fixed less than you would think. I wasn't falling into the simple traps. But the writing wasn't really anymore clear. The big break through there was when I started getting my work published through online publications. Specifically, "Angular in Depth" in 2019 time period. They were really supportive of my content but they saw that it was missing the audience.

I remember at one point @layzee sat down with me and picked through an article with me showing me how to break my writing up into more paragraphs. I was accustomed to having a paragraph express what I considered a complete idea. That meant 6-8 run-on sentences. He was like no more than 3. Give them a break to sit with what you just told them. Add spacing and images to your articles for the same reason.

I didn't like this much at first because it made my articles longer. Too long as far as I thought. But it also forced me to really focus on what I wanted to say. I'd need to do one editing pass to break things up and another to eliminate the cruft.

At this point, Solid was picking up steam, and there were others in the community that were interested in seeing us succeed. Some of you may not know but Theo Browne (T3.gg) reviewed many of my articles during the 2020-2022 time period. He had a lot less tolerance for sentences that didn't flow and he would go through and gut all my unnecessary phrasing. All the "And ...", "In fact", "But Honestly", "Actually..", "Simply put,". He emphasized it didn't add anything. By doing that I was able to save those for when I wanted to make a real impact.

So that gives you some insight into where my writing process was through the end of 2025. I'd write something rough, do multiple passes myself, run it through Grammarly, feed it to the Solid community. Have feedback, then pass it to a few specific reviewers (although some like Theo were getting too busy to look at my work regularly). And half a dozen people and twice as many hours later we had an article.

Enter LLMs

Now I never prompted an LLM intentionally before the end of 2025. As I have noted in previous articles, I was an AI laggard. Sure Gemini results would show up on a Google search. And I had dabbled with some image generation for Articles/Streams. But I did not use Chat LLMs directly at all. Funny enough, since late 2023 I had noticed two phenomena.

First, absolute garbage articles quoting my work in like "Best JavaScript Frameworks to use in 2023". At first I thought these were just low effort marketing articles. Some of them probably were. But after a while I came to recognize these as AI generated.

Second, people coming on to my articles and accusing them as being AI generated. My response would be, "Did you read the article?" There is no way AI makes that argument. But the general feedback was that the articles were vague because they tried to pack too much into a small space. And the move between macro and micro details was disorienting. Ironically my trademark writing style because it was born out of necessity.

I mostly pushed both of these aside. What had always mattered was the content. Those two couldn't be more obviously different. Even if I did my own yearly JavaScript summaries, any one with half a brain could tell the difference. My articles had takes that existed nowhere else and provided a deep insight.

Trying LLMs for Myself

I was working on Solid 2.0. High-level design stuff late 2025 and I decided to give LLMs a try. Not for coding just to talk through the problem and see if they had an insight. I believe GPT 5.3 was out but I was just using CoPilot for free which was on 5.1. I found the process very frustrating because it kept losing details. I realized pretty quickly I needed to have it write things down.

As I got more excited about formalizing these designs I got AI to write short explainers about what we had talked about so that I could share them in Discord. This was very helpful since my HackMDs I had been writing were cryptic and people could immediately understand what I was talking about this way. Maybe not deeply but the gist of it.

Summaries of really high level stuff. The thing I was particularly bad at writing. It was very common in the Solid community for people to post AI written summaries on my writing since no one seemed to get what I was saying and I didn't have time to clarify while working on cutting edge things.

But every time I tried to get AI to really capture the real point behind my stuff it missed. Even after moving to Cursor and frontier models. AI could write something coherent but it was never the position or argument the way I'd make it. As before it didn't have my original positioning/takes. Occasionally it would come up with something interesting like: The Architecture of Temporal Determinism. But that was a rare occurence.

AI Assisted Writing

So at some point, tired of the Yellow squigglies I was getting from Grammarly--the ones that you need to pay for that refer to structural issues--I was like why don't I feed my article to the LLM instead? And I was amazed.

It took what I wrote and it sounded coherent. No initial 3 passes, no Grammarly, no community pass, no special editors. Yes I still ended up doing all of those but it was like it skipped to the finish line. There was very little feedback down the line.

The part that really loved was it simultaneously made my writing shorter while bringing back that pacing I heard in my head. The old pauses. The way it used semi-colons and -- was exactly what I intended. No broken sentences. No confusion on flow. It just read perfectly.

I was so impressed. There were a couple things I thought odd. It really liked sumarizing at the end of each section. I had a habit of connecting sections with a probing sentence for sure, but AI liked to try to tie things in a bow. And those additions were the place that I immediately cut out. Easy to see. But for the most part it was like what I had always been looking for. I'd struggled being terse and clear and it just gave it to me, in mostly my own words.

I released my first article like this:

Ryan Carniato for Playful Programming

Mar 13

Two React Design Choices Developers Don’t Like—But Can’t Avoid

#javascript #webdev #solidjs #react

9 min read

and I was pretty excited. This was an important article. It was where I was going to do the unexpected: express to the world that React, a long time competitor philosophically, was actually completely right about a few things. It was controversial. It was honest. And it needed to be clear more than anything I'd done before.

In hindsight, the response should have been obvious. People couldn't get over the AI phrasings in places. That's the thing. It only takes a couple of places for the radar to go off. I had the before and after AI for this article I actually showed it on stream. I wrote every bit of the source. The things that people were accusing being AI were as much me. I thought that by taking accountability, owning it would be enough.

But this kicked up a rage. And I admit I felt a bit resentful. This is critical work. From my perspective earthshaking and all people could seem to talk about was that I used AI to make the message clearer. I had been dismissed in the past for being vague or hard to follow. Now I was being dismissed for the opposite.

I had also received similar feedback on using AI-generated covers. Previously, I was picking up random free images online. It took some cleverness to choose the image but it wasn't some work that I put in. AI had actually given me images suitable to my content. Again it seemed so much better to me. I'm not an artist. But somehow it wasn't acceptable. It seemed irrational to me. I put more effort in, to come up with a better result. I was clearly missing something.

Another Attempt

Last week, I took that lesson and tried something a little different when we dropped the Solid 2.0 RC release announcement. I had written release articles before but they were always tough. Short attention spans and a need to get to the point. And Solid 2.0 was proving difficult. It just had too much stuff in it. A point form list undersold it but there was no way I was going to be able to get into all the details.

I had written an article showed it to AI and it had done some edits. And this time I was more careful to cleanup language. Not because I thought it was bad but because I knew it would trigger people. However, no matter what I did the article was way too long. At some point the agent suggested the obvious. Make a follow-up article series. It would summarize the some of the pieces we would be removing. And we would be set.

I looked at the work and I was impressed it had kept my opening and sentimental parts and filled in the gap with the type of clear, to-the-point way that I'd expect in a release article. It was way shorter than what I had written and after a quick pass, everyone who reviewed agreed it was much more approachable. The language here was not nearly as AI-sounding because I didn't get it to really rewrite what I had written where it mattered. But obviously, even after human edits on the more marketing side there were still some traits.

Again, and I imagine it was because people didn't get to the end. The response was half about the use of AI in those point form lists. The general sentiment was that it was subtle but still enough to notice. It was genuinely a better article for it, it fit the purpose of the writing. But they couldn't see past it. Most of the article had the human soul, but a few point form lists ruined it.

Today

I had an odd week. It started with seeing an AI Gist comparing Solid 2.0 to Octane. I saw that Dominic had responded with some agent-assisted prose, and I knew there was no way I was going to keep up with that discussion while pushing forward all the post-release things I needed to do without doing the same. We literally had the Agents arguing our points. You can tell they are our points. Our fundamental positioning, but it isn't our voice.

But the most warmly genuine thing happens at the end. We both remove the Agent and have a real discussion. I think we both realized how ridiculous it had become.

Now, the problem is that it isn't too far from how we are working today. When I have an agent review and issue or PR even if I'm driving it, reviewing the changes, and setting the response, it no longer sounds like me. It's easy to justify the reasoning.

Look at how many open issues/PRs are on SolidJS right now. There is no way we could be as responsive without it. We've almost closed out every issue. That is between issue submitters using agent-guided PRs and from our own agent work. But a certain human aspect is gone. I used to go on every PR and write a thank you note personally and I know I haven't done that as much the last couple months. I can justify it, but there is a human cost.

I'm also about to release another article. I'm trying yet another approach to this. Where I write it, feed it to AI, but never let AI edit the actual article. When it identifies something that it rewrites, I take that as a sign my writing isn't the best there and read what the AI wrote, then minimize the window and write back the structure myself using my own voice. We'll see if this lands better.

It's tricky because I can already hear LLMism in my own writing. According to critics, I was already pretty close years ago. And if I already think it sounds better than what I write I have a bias. But it's the most honest thing I can do to produce good content. And I mean good content. Not whatever this is. So I'm going to try again. I'm still figuring this out.

That's all we can keep doing.

Functional languages are heavily imperative.

Mike Pearson — Mon, 17 Aug 2026 07:39:18 +0000

This article will seem full of contradictions.

Even writing it feels like a contradiction: Why am I digging through academic Haskell papers from the '90s right in the middle of my AI psychosis moment? Literally, as I write this, I am running my first experiment with an agent delegating tasks to another agent. So why am I spending time on esoteric academic nonsense instead of giving in to the vibes and building my loopy graphy software factory?

I am writing this because AI is a nuclear amplifier on the patterns we establish in our codebases, and we literally do not have the right terminology to establish scalable patterns. Nobody has the answers we need because nobody even has the right terminology to talk about it.

Two Dimensions, Not One

Industry dogma says that functional and declarative are synonyms—that code is either side-effectful and imperative, or pure and declarative:

But functional and declarative are independent dimensions:

Code that is both functional and imperative debunks this, and so does code that is both side-effectful and declarative.

Both exist!

"Imperative Functional Programming"

Simon L Peyton Jones and Philip Wadler helped create Haskell, which is a beautiful, pure functional programming language.

In 1993 they wrote a paper called "Imperative Functional Programming." The title may sound like an oxymoron, but it isn't.

The functional programming community had been struggling with how to manage side-effects like I/O, and these co-creators of Haskell proposed a way to decouple the expression of I/O commands from their execution.

But they noticed something:

It will not have escaped the reader’s notice that programs written in the monadic style look rather similar to imperative programs. For example, the echo program in C:

echo() {
loop: a = getchar(a);
    if (a == eof)
        return;
    else { putchar (a);
        goto loop; }
}

In Haskell:

echo :: IO ()
    echo = getcIO 'bindI0' \a ->
    if (a == eof) then
        doneIO
    else putcI0 a 'seqI0'

Does the monadic style force one, in effect, to write a functional facsimile of an imperative program, thereby losing any advantages of writing in x functional language?

Nope! Jones and Wadler list two advantages that remain:

List operations (like mapand append) can still operate on monadic commands
Effects can be expressed without immediately executing them. "It's a bit like being able to define your own control structures in an imperative language."

Recognizing the imperative structure of the Haskell monadic pattern does not mean we have to abandon the advantages that are inherent in pure functional programming.

But it is still imperative structure.

"Lazy Imperative Programming"

John Launchbury, another creator of Haskell, wrote a paper the following year called Lazy Imperative Programming.

In it he says,

Imperative features were introduced to Glasgow Haskell for expressing input and output.

Could this be plainer? Haskell has imperative features.

And the Haskell code that uses them is imperative. Also from his paper, an "Imperative Scan Left":

writeVar is an imperative statement, which is why this is an example of imperative code—written entirely with pure functions!!!

The paper has many other references to imperative stuff, including this:

In a strict imperative framework such as the IO monad (and most imperative languages), no value could be returned until the whole of the list was traversed. Using lazy sequences, however, this is not the case. If only the head of the list is required then very little of the computation is performed: the variable is allocated and initialised, it is read, and the list returned with that value in the head. If even less is required, merely whether the final list is empty for example, then the variable is not even allocated as only xs needs to be examined in order to give the structure of ys.

🤯
This is insanely cool.

Again, not everything in Haskell has to be declarative for it to still allow for incredible execution properties!

The "Imperative Feel" of Concurrent Haskell

Paul Hudak (another creator of Haskell) and Conal Elliot wrote a paper in 1997 where they weren't happy with the "strongly imperative feel" of Concurrent Haskell—even though it was 100% purely functional.

(Side note: I owe my passion for programming to this paper. More on that later.)

Here's an example of what that pure functional approach with an "strongly imperative feel" looked like:

box <- newEmptyMVar

forkIO $ do
  threadDelay 1000000
  putMVar box 42

result <- takeMVar box

puTMVar box 42 expresses a command to set box's value to 42.

In the authors' own words,

While this system is purely functional in the technical sense, its semantics has a strongly imperative feel. That is, expressions are evaluated without side-effects to yield concurrent, imperative computations, which are executed to perform the implied side effects. In contrast, modeling entire behaviors as implicitly concurrent functions of continuous time yields what we consider a more declarative feel.

It is not a coincidence that the definition of "imperative" in English is "expresses a command" and that a line of code that literally "expresses a command" had an "strongly imperative feel"—even in Haskell.

But the authors were dissatisfied with that "imperative feel"—so they invented functional reactive programming (FRP):

box t0 =
  0 `untilB`
    predicate (time >=* t0 + 1) t0
      -=> 42

Just a single declaration. Nothing here expresses a command at all. putMVar is 100% imperative, while this is 100% declarative and 0% imperative.

Note on "more declarative" and monoparadigmatic dogma

Since the industry dogma in the 1990s was "functional = declarative", they had to call FRP more declarative. Concurrent Haskell was already declarative, supposedly, by virtue of being in Haskell—so this had to be extra declarative 🤷

And I say that with great admiration for these authors, because I owe my passion for programming to this paper. This was the origin of both RxJS and signals, which I love... very much. Too much for many people.

The "Lazy Imperative Programming" paper was more contradictory. The author often contrasted Haskell with "imperative languages," while dozens of times referring to features within Haskell as imperative.

On the one hand, functional languages are commonly more expressive and easier to reason about than imperative languages,

After reading 20 or so papers from the 1990s talking about programming paradigms, you will understand that the terminology was extremely entrenched. Academics classified programming languages into rigid categories to help explain the programming patterns of the time.

Functional programmers were especially guilty of reinforcing this reductionism, since they were a minority of programmers and had to fight against the grain with every rhetorical tool they could. Branding functional programming languages as automatically 100% declarative was an enticing selling point—even though we have many Haskell creators very plainly referring to features within Haskell as imperative.

Also, in the 1990s very few "imperative languages" had added much functional features, having not had to deal with much concurrent processing yet, which meant languages really did mostly fall into neat categories; multi-paradigmatic languages were not the norm like they are now. The concept of entire languages as "imperative" or "declarative" somewhat applied back then, but today is a nothing but a leftover from decades of synchronous code that all matched the same 2-3 structural patterns.

We have to make a mental note of this history, but if we do not push to correct the terminology, it will continue to confuse developers and AI. Many developers think that stuffing imperative features between < > characters magically makes them declarative because it's part of HTML, a "declarative language." Some are attempting this and creating masses of spaghetti code that only cosmetically looks different from the imperative JavaScript spaghetti they were writing last year.

There are no "declarative languages" and "imperative languages", as much as it would simplify selling them. There are commands expressed in code, which are imperative by the purest definition; and there are features and behaviors declared without scattered commands controlling them from elsewhere.

Conclusion (Imperative Functional Programming)

The literal precise English definition of "imperative" is something that expresses a command. That is what these pure functions are doing in Haskell and other functional languages. This should already rest the argument.

But even the less precise definitions of imperative programming focus on structural descriptions written in code rather than execution details:

"Imperative programming involves writing programs as sequences of explicit commands that are executed in order from top to bottom." https://builtin.com/articles/imperative-programming
"logic encoded as a sequence of ordered operations" https://en.wikipedia.org/wiki/Programming_language
"Imperative programming focuses on describing how a program operates step by step, rather than on high-level descriptions of its expected results" https://en.wikipedia.org/w/index.php?title=Imperative_programming
"With an imperative approach, a developer writes code that specifies the steps that the computer must take to accomplish the goal." https://learn.microsoft.com/en-us/dotnet/standard/linq/functional-vs-imperative-programming
"Imperative programming languages are composed of step-by-step instructions (how)... By contrast, in declarative programming, the desired result (what) is described directly." https://www.ionos.com/digitalguide/websites/web-development/imperative-programming/
Imperative programming is a paradigm where you explicitly state how the program should achieve the desired result. https://octopus.com/devops/infrastructure-as-code/declarative-vs-imperative-programming/

It's very clear that Haskell and functional programming languages are extremely cool with the flexibility they afford for all kinds of things, including the execution of side effects.

But Haskell has features that enable writing literal imperative commands even with pure functions. This results in code that is structured imperatively: Explicit commands incrementally adding to behavior described elsewhere. The instant a single command appears, it completely takes away the declarative quality of describing the final result of something up-front. The imperative features of Haskell are not just less declarative; they are completely anti-declarative.

Functional programming can be imperative.

Declarative Side-Effects

RxJS

RxJS enables fully declarative code, despite latent side-effects.

RxJS actually came from that Fran paper we looked at earlier, which proposed a way to turn this kind of Concurrent Haskell:

box <- newEmptyMVar

forkIO $ do
  threadDelay 1000000
  putMVar box 42

result <- takeMVar box

into this:

box t0 =
  0 `untilB`
    predicate (time >=* t0 + 1) t0
      -=> 42

Neither of these trigger side-effects, but the declarative version structures the code as a single description of a complete, final logical result (a behavior over time). The thing that made the first imperative and the second declarative is the structure of the code, not the side-effect execution model.

The same structural move can be made in side-effectful code:

const box = Promise.withResolvers();

setTimeout(() => {
  box.resolve(42);
}, 1000);

const result = await box.promise;

const box = await lastValueFrom(
  timer(1000).pipe(map(() => 42)),
);

Both of these trigger side-effects when executed, but the declarative version structures the code as a single description of a complete, final logical result. The thing that made the first imperative and the second declarative is the structure of the code, not the side-effect execution model.

These four code snippets alone are enough to complete our four quadrants:

But let's look at some more common declarative side-effects.

HTML

"HTML is declarative" is often said. And it's mostly true (see above callout "Note on "more declarative" and monoparadigmatic dogma").

Yet the entire point of HTML is a side-effect: You being able to look at beautiful interfaces like this:

It's not just the DOM that's a side effect though. The HTML rendered in the page can itself trigger other kinds of side effects, like network calls:

<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.0/dist/css/bootstrap.min.css" />
<script src="https://cdn.jsdelivr.net/npm/axios/dist/axios.min.js"></script>
<!-- ... -->
<img src="https://storage.googleapis.com/blog-images-backup/1*tY3o3UFtBaMQ103en48qxA.png" />
<iframe src="https://www.youtube.com/embed/dQw4w9WgXcQ" />

Nondeterministic Declarations

`Math.random`

Math.random() technically produces a side effect because it relies on and mutates a hidden global internal state (the seed or PRNG algorithm pointer) inside the runtime environment to generate its next value.

But this is still totally declarative:

const x = Math.random();

`Date.now()`, `crypto.randomUUID()`, `process.memoryUsage()`, etc...

const now = Date.now();
const date = new Date();
const perfNow = performance.now();
const randomBytes = crypto.getRandomValues(new Uint32Array(1));
const uuid = crypto.randomUUID();
const hrtime = process.hrtime();
const uptime = process.uptime();
const memoryUsage = process.memoryUsage();
const freeMemory = os.freemem();
const battery = await navigator.getBattery();
const windowWidth = window.innerWidth;
const visibility = document.visibilityState;
const online = navigator.onLine;

All of these are completely declarative. They are declarations of final results, and no subsequent step-by-step (or any) imperative code is involved.

But they are not pure functions. They don't have side effects, but they have side causes, so they still are not functional. So while they aren't examples of declarative code that causes side effects, they are examples of declarative code that break rules of functional programming, showing that these are independent dimensions.

Declarative "Pure" Functions with Side-Effects

CPU

const fib = (n: number) => n < 2 ? n : fib(n - 1) + fib(n - 2);
const result = fib(50);

Everything here looks pure as the driven snow, and it's definitely declarative.

No side effects at all, right?

In fact, it triggers 40,730,022,147 calls, which means that its side effects are so severe that I really don't recommend pasting that into dev tools and running it. You think jQuery has interesting side effects by reaching into the DOM and changing the behavior of random things, but this will change the behavior of everything on the page. Namely, it eliminates it because it locks up the CPU.

Memory

new Array(2 ** 30).fill(0);

No side effects here, right? It's declarative, at least.

However, this might get compiled into assembly code that looks like this:

mov     rdi, 8589934592
call    malloc

mov     rcx, 1073741824
mov     rdi, rax
xor     eax, eax
rep stosq

There is a huge side-effect in this code: call malloc requests 8589934592 = (2 ** 30) × 8 bytes = 1,073,741,824 × 8 bytes ≈ 8 GiB of memory.

There may be guardrails against creating arrays this big. I didn't feel like testing it. But there is a variation that may not be prevented:

Array.from({ length: 1000 }, () => new Array(1_000_000).fill(0));

This time each inner array has only 1 million elements, but there are 1000 of them, so 1,000,000,000 total elements.

Here are some possible side-effects:

The page or Node.js process becomes unresponsive while the runtime tries to allocate and initialize the array
In a severe case, the browser tab crashes because it exceeds its memory limit.

And yet, it's still declarative.

Conclusion (Declarative Side-Effects)

Declarative and functional are not synonyms. Declarative code is about how a computation is structured: describing a result rather than spelling out a sequence of commands to get there.

Functional purity is about what that computation depends on and affects. A declaration can trigger network requests, consume CPU and memory, observe clocks and runtime state, or depend on hidden mutable state without becoming imperative.

These are separate dimensions.

Conclusion

The point of separating these dimensions is not to win a pointless terminology argument. It is to make better engineering decisions while AI is applying incredible pressure on our architectural patterns.

If we collapse functional into declarative, we lose the ability to talk precisely about what code is doing. Pure code can still be structured imperatively. Declarative code can still observe mutable state, trigger I/O, allocate absurd amounts of memory, or otherwise affect the world.

Structure and purity are independent properties of code that sometimes align, but DO NOT HAVE TO!

If the problem is hidden state, surprising effects, or difficulty reasoning about dependencies, functional programming can help with its explicit inputs, immutable values, pure transformations, effect isolation. And although I love functional programming, in my experience, most apps genuinely will never see significant consequences for not being purely functional.

However, most apps I have seen have suffered severely from being imperative: It always scatters control, with commands reaching across a system (spaghetti code), or behavior that can only be understood by mentally executing twenty steps across multiple contexts. Declarative code fixes this. Functional programming does not.

I am sick of saying I like declarative code and being told to juST UsE ELm or HASkElL.

People can't even understand the problem because they don't have the words to discuss it properly.

Now throw AI into this cross-talking mix of contradictions, and this is what we can expect:

This looks delicious, but can we please try to avoid it anyway?

Let's fix our vocabulary so we can learn real things about imperative code and steer humans and AI away from it.

OpenRouter: One API Key to Rule Them All 🔑

Domenico Tenace — Wed, 12 Aug 2026 07:20:51 +0000

Overview

Hey everyone 👋

Managing AI models in 2026 has gotten ridiculous. Anthropic key here, OpenAI key there, a separate billing account for Google, another for Mistral, and if you want to try DeepSeek you're adding yet another dashboard to the pile. It's chaos.

OpenRouter fixes this. One API key, one credit balance, 300+ models. I've been using it as the backbone of my AI setup for a while now, and recently I wired it directly into OpenCode, which made the whole workflow click into place.

Let me explain how it all works. Let's dive in! 🤙

What Is OpenRouter? 🤔

OpenRouter is a unified API gateway that sits between your application and the underlying LLM providers. You send a request to OpenRouter, it forwards it to the model you specified, and returns the response in a normalized OpenAI-compatible format.

The catalog currently covers 300+ models from every major provider: Anthropic, OpenAI, Google, Meta, Mistral, xAI, DeepSeek, Qwen, NVIDIA, and dozens of smaller ones. You switch models by changing a single parameter in your request. No code changes, no new integrations, no new billing accounts.

It's also OpenAI SDK-compatible, which means if you're already using the OpenAI client in your code, you change the base URL and the API key, and everything else works unchanged.

How It Works 🔧

The setup is three steps:

Create a free account at openrouter.ai
Add credits via credit card or crypto (no minimum purchase, no expiration)
Generate an API key and use it across all your tools

From that point on, switching models is just changing a string. If you were calling Claude Sonnet directly through Anthropic and want to test Gemini Flash or DeepSeek for the same task, you change one line. That's it.

Provider Routing and Fallbacks

One of OpenRouter's strongest practical features is automatic provider fallback. Many popular models are served by multiple infrastructure providers. If one returns an error or hits capacity, OpenRouter silently routes to an alternative and your request succeeds. You don't write retry logic for this, it just works.

There's also an auto-router mode: set the model to openrouter/free and OpenRouter selects the best available free model for your request based on what it needs, structured output, tool calling, image understanding, and so on.

The Free Tier

OpenRouter offers around 29 free models at any given time, including Llama 3, Gemma 4, DeepSeek Flash, Qwen3, and others. Free accounts get 50 requests per day without adding credits, and 1,000 per day after a first top-up.

The free model lineup shifts as providers change their policies, so treat it as a useful resource for prototyping, not a guaranteed production tier.

Pricing: What You Actually Pay 💰

This changed significantly in 2025. OpenRouter used to add per-token markups on top of provider pricing. That model is gone.

The current structure is straightforward: a flat 5.5% fee on credit purchases, and provider token prices passed through at cost. So if Claude Sonnet 4.6 is $3/$15 per million tokens at Anthropic, you pay $3/$15 on OpenRouter. The only overhead is the 5.5% you paid when you loaded credits.

The one additional charge: if you bring your own provider API keys (BYOK) and exceed 1 million requests per month, there's a 5% fee on usage beyond that threshold. Below 1M requests it's free to route through your own keys.

To put it concretely: loading $100 in credits costs $105.50. Everything you buy with those credits is at direct provider rates.

For hobbyists and developers running multiple models, this is genuinely competitive. For enterprises burning millions of tokens per day, negotiated direct rates might beat it, but you'd have to be at serious scale.

OpenRouter + OpenCode 🔗

This is the combination I've been running, and it's become my default setup.

OpenCode supports any OpenAI-compatible endpoint, which OpenRouter is. You point OpenCode at OpenRouter, set your API key, and from that moment you can use any model in OpenCode's model selector without managing separate credentials for each provider.

The practical benefit is flexibility without friction. When I want to try Qwen3 Coder for a refactoring task, I switch the model in OpenCode. When I need Claude Opus for something that requires stronger reasoning, I switch back. One balance covers everything.

It also means I'm not locked into any single provider's availability. If Anthropic has downtime, I route through Gemini or DeepSeek without touching my workflow. OpenRouter's provider fallback does the heavy lifting.

The Pros 👍

One API key and one billing account replace every separate provider integration you'd otherwise manage. For teams or individual developers using more than two models regularly, that alone justifies the overhead.

The OpenAI-compatible API means zero migration cost if you're already using the OpenAI SDK. Change the base URL, change the key, done.

Provider fallback is genuinely useful in production. You stop worrying about individual provider outages because OpenRouter handles the retry layer for you.

The free model catalog gives you a real prototyping environment at zero cost. Qwen3 Coder Free and DeepSeek Flash Free are capable enough for a lot of development tasks.

Transparent pricing with no hidden per-token markups. The 5.5% credit fee is upfront and easy to account for.

The Cons 👎

The 5.5% credit fee is real money at scale. If you're running high-volume production workloads, that overhead adds up. Direct provider APIs will be cheaper once you're large enough to negotiate rates.

Credits don't expire, but they also aren't refundable. You're committing capital upfront even if your usage patterns shift.

Free model availability is unstable. Providers can remove free-tier access at any time and OpenRouter has no control over it. Don't build a production workflow that depends on a specific free model being there next month.

Enterprise teams needing RBAC, per-team budgets, audit logs, and VPC-native routing will hit a ceiling. OpenRouter is primarily a routing and billing layer, not a governance platform. For stricter compliance needs, something like LiteLLM self-hosted or Portkey might be more appropriate.

The auto-router mode (openrouter/free) is convenient, but the model selection varies between requests. If you need consistent output style across sessions, pin a specific model ID instead.

Who Should Use OpenRouter? 🎯

OpenRouter is the obvious choice if you're using more than one or two AI models regularly and don't want to manage the overhead of multiple accounts and billing setups. For individual developers, it removes a real operational annoyance.

It's also the right call for tools like OpenCode that support BYOK or custom endpoints but don't manage multi-provider routing themselves. OpenRouter becomes the infrastructure layer your tool sits on top of.

Where it makes less sense: pure Anthropic shops that only need Claude, or enterprises with compliance requirements that need on-premise routing and audit trails. For those cases, the flexibility isn't worth the trade-offs.

Final Thoughts 🌟

OpenRouter started as a scrappy model aggregator with 30 models. In 2026 it's become the most important middleware layer in the independent developer's AI stack, and the pricing reform that eliminated per-token markups made it significantly more honest to use.

The combination with OpenCode is what made it click for me. Instead of managing Anthropic and Google credentials separately, I load credits into OpenRouter once and switch models from OpenCode's interface as needed. It's the kind of setup that removes decisions you don't want to be making mid-task.

One key, one balance, hundreds of models. For how messy the provider landscape has gotten, that's a genuinely useful simplification.

Happy coding! ✨

Hi 👋🏻

My name is Domenico, software developer passionate of Open Source, I write article about it for share my knowledge and experience.

Don't forget to visit my social links to discover my links and to check out Domenico Tenace Open Labs for my open-source projects! 🫰🏻

🌲 Links: https://links.domenicotenace.dev/

🐙 Domenico Tenace Open Labs: https://github.com/Domenico-Tenace-Open-Labs

If you like my content or want to support my work, you can support me with a small donation. I would be grateful 🥹

☕ Buy me a Coffee: https://buymeacoffee.com/domenicotenace

Originally published on ZyVOP

💡 For more articles like this, subscribe to the ZyVOP newsletter!

OpenCode: The Open Source Coding Agent That Doesn't Lock You In 🔓

Domenico Tenace — Wed, 05 Aug 2026 08:00:00 +0000

Overview

Hey everyone 👋

If you've ever hit your Claude Code token limits mid-task, wondered what's happening under the hood of a closed-source agent, or just wanted to plug in a different model without switching tools entirely, OpenCode might be exactly what you were looking for.

It's the open source alternative that took the terminal agent concept and made it model-agnostic, and by mid-2026 it had already surpassed Claude Code on GitHub stars. That's not a coincidence.

Let me break it down. Let's dive in! 🤙

What Is OpenCode? 🤔

OpenCode is an open source AI coding agent built in Go that runs in the terminal, desktop, and IDE. Its thesis is simple: you bring the model, OpenCode brings the agent. It supports 75+ LLM providers, from Claude and GPT to local models via Ollama, doesn't store your code, doesn't charge a subscription, and over 7.5 million developers use it monthly.

It was built by the SST team, the same people behind the popular serverless framework. The design is a client/server architecture, not a single CLI binary, so one backend drives a terminal TUI, a desktop app, and IDE extensions for VS Code and Cursor.

OpenCode surpassed Claude Code on GitHub stars (160K+ vs 122K+) and is now the most starred open source coding agent. It does what Claude Code does, but lets you plug in any model from 75+ providers, including local models at zero API cost.

How It Works 🔧

Installing OpenCode takes about 30 seconds:

curl -fsSL https://opencode.ai/install | bash

You land in a polished TUI with two modes, Build and Plan. Build mode executes tasks directly. Plan mode is read-only, it lets the agent analyze your codebase and propose an approach before touching a single file. This is the separation of intent and execution that Claude Code doesn't make as explicit.

The design choice that matters most is the one in the name. OpenCode separates the agent harness from the model. Claude Code is tuned end to end around Anthropic's models and talks to them and only them. OpenCode connects to 75+ providers through Models.dev, including Anthropic, OpenAI, Google, Moonshot, Z.ai, local runtimes through Ollama, and any OpenAI-compatible endpoint you hand it.

You can switch models mid-session without restarting. That alone is a feature Claude Code doesn't have.

The Pricing Reality 💰

This is where OpenCode makes its strongest argument. There's no subscription for the software itself, you pay for model access directly.

The options as of mid-2026:

Bring your own key: pay the provider directly at their posted rates. Full flexibility, full cost visibility.

OpenCode Zen: a pay-as-you-go hosted gateway with access to many models.

OpenCode Go: $5 for the first month, then $10/month. Includes access to capable open models like GLM, Kimi K2, Qwen, DeepSeek, and MiniMax with generous per-session request limits.

Compare that to Claude Code's $20/month Pro, $100/month Max 5x, or $200/month Max 20x plans. For individual developers or small teams watching their AI spend, the math is clear.

The caveat: cost visibility helps when you are counting. Once you settle onto a flat Max plan, the math changes. If you're a power user who hits their limits constantly, Claude Code's flat rate might actually be cheaper per task.

The Anthropic Block: What Happened and Where It Stands 🚧

This is the part of the story that redefined what OpenCode actually is.

On January 9, 2026, Anthropic changed its OAuth policy to block third-party applications from authenticating users through Claude.ai accounts. OpenCode was the primary casualty: users who relied on their Claude Pro login lost access overnight. The official reason was "security and ToS compliance."

The January block made that choice less about saving money and more about philosophy. You are no longer choosing a cheaper way to run Claude. You are choosing whether you want a managed product or an open one.

Where it stands today: you can still use Claude models in OpenCode, but only through an Anthropic API key, not your Claude.ai subscription credentials. The more lasting impact was reputational: it accelerated many users migrating to Gemini as their default backend.

OpenCode vs Claude Code: The Real Differences 🥊

Terminal experience

OpenCode tends to win here, and it wins on feel. The TUI is the repeated favorite in nearly every comparison thread. The terminal does not flicker on each update, sections scroll independently, and planning prompts are easy to answer. OpenCode also ships a standalone Tauri desktop app for macOS, Windows, and Linux, something Claude Code doesn't have.

Autonomy features

Claude Code has a wider toolset: Agent View for fleet management, /goal for fire-and-forget autonomous runs, instant rewind via double-Esc, and background monitoring. OpenCode has background subagents and sessions that survive a terminal close, but lacks the orchestration depth.

Output quality

A controlled benchmark found Claude Code faster and OpenCode more thorough using the same model. The summary: "Claude Code is built for speed. OpenCode is built for thoroughness."

One practical issue to know about: multiple testers reported that OpenCode, across all tested models, reformats existing code without authorization. On mature codebases with established style guides, this is a trust issue. There's an open GitHub issue tracking this, and it's the most common complaint in real-world use.

The Pros 👍

True model freedom. No other terminal agent lets you swap between Claude, Gemini, DeepSeek, Qwen, or a local Ollama model mid-session. This is OpenCode's defining advantage.

Open source and inspectable. You can read the codebase, fork it, self-host it, and know exactly what the agent is doing with your code. Claude Code is closed source.

Better terminal UX. The TUI is genuinely nicer. Non-flickering updates, scrollable sections, a dedicated desktop app.

Cost control. Bring your own key, use local models at zero cost, or pay $10/month for the Go tier. The ceiling is much lower than Claude Code's $200/month Max plan.

Data compliance. Teams with strict data requirements can point OpenCode at a local or self-hosted model so code never leaves their network.

The Cons 👎

The code reformatting issue. OpenCode has a known tendency to reformat existing code without being asked. On mature codebases this creates noisy diffs and erodes trust in the agent's edits. Not a dealbreaker, but worth knowing.

Thinner plugin ecosystem. Claude Code has a more mature skills, hooks, and plugin marketplace. OpenCode's extension catalog is catching up, but it's not there yet.

No subscription path for Claude. If you're paying for Claude Pro or Max, you can't use that credit in OpenCode. You need a separate API key, which means paying again.

Fewer autonomous orchestration features. /goal mode, Agent View, instant rewind, and worktree isolation are Claude Code exclusives. For complex multi-agent workflows, Claude Code is still ahead.

Broad permissions by default. Several developers flag that OpenCode's agent permissions are broad by default. Check opencode.json before you point it at anything sensitive.

Who Should Use OpenCode? 🎯

OpenCode is the right choice if:

You want model flexibility and don't want to be locked into Anthropic's roadmap
Budget control matters and you want to use cheaper or local models
You prefer an open source tool you can inspect, fork, and trust
Your team has compliance requirements that require on-premise model inference
You find Claude Code's terminal UX annoying and want something nicer

Stay with Claude Code if:

You need the strongest possible instruction-following on hard tasks
You use Agent View, /goal, or other orchestration features heavily
You want a managed product that "just works" without configuration
You're already paying for Max and want to get full value from it

And honestly, plenty of people run both. OpenCode for day-to-day work with flexible models, Claude Code for the heavy debugging sessions where Opus is worth it.

My Honest Take 💭

OpenCode is a serious tool, not a hobby alternative. 178,000 GitHub stars and 7.5 million monthly users don't lie. The model-agnostic design is genuinely useful, and the terminal UX is objectively better than Claude Code's.

But the January block revealed something important: the moment you depend on Claude's quality and want to pay less, you're in Anthropic's crosshairs. OpenCode solved the tooling problem, not the model dependency problem. If you're using it with Claude via API key, you're still paying Anthropic rates.

The real freedom comes when you combine OpenCode's harness with open or local models. That's the combination that makes the cost argument actually land, and that's where the project's future clearly points.

Managed product or open tool? The answer depends on who you want to be as a developer.

Happy coding! ✨

Hi 👋🏻
My name is Domenico, software developer passionate of Open Source, I write article about it for share my knowledge and experience.
Don't forget to visit my Linktree to discover my links and to check out Domenico Tenace Open Labs for my open-source projects! 🫰🏻

🌲 Linktree: https://linktr.ee/domenicotenace
🐙 Domenico Tenace Open Labs: https://github.com/Domenico-Tenace-Open-Labs

Follow me on dev.to for more articles 👇

Domenico TenaceFollow

Passionate about the IT world and everything related to it ✌🏻 Open Source enthusiastic 🦠

If you like my content or want to support my work, you can support me with a small donation. I would be grateful 🥹

Introducing Argus: The Code Security Colleague Your Team Doesn't Have

Davide Imola — Thu, 30 Jul 2026 08:56:00 +0000

Most development teams don't have a security engineer. Not because they don't want one. Security expertise is genuinely hard to find, expensive to keep, and most of us would rather ship features than spend an afternoon reading about deserialization gadget chains. So security becomes the thing you'll get to later, and later never comes.

I've believed for a while that AI is going to change security, and not as a slogan. The reason is structural: there aren't enough people. The industry is short something like 4.8 million security professionals worldwide,¹ which is the gap from that first paragraph counted globally, and no hiring spree closes a hole that size. AI won't close it either, and I want to be honest about that. What it can do is make the gap hurt less: take the routine load off the few people who are there, and keep a small team, or a team of one, from being buried. Same as it did for my coding, where it didn't make me smarter, it just stopped the grunt work from being the bottleneck.

A good model has read more security than most of us ever will: the best practices, the attack patterns, the bugs that hide in plain sight. Point it at code written by someone who isn't a security expert, which is most of us, and it genuinely lifts what they can ship safely. This isn't a spectator take for me either, it's what I spend my days on, building products that live right at that intersection. And the other side already gets it: attackers are using AI right now, so insisting defenders shouldn't is not caution, it's a handicap.

Concretely, I already use AI for security review, enough that I'm building a talk around how to do it well: lean on the skills that already exist, write your own, and point them at the real tools you already have. Give a capable model the right context and it quietly does a lot of the work a tired reviewer skips under a deadline. What it doesn't do is stick around. Every session starts from zero, knows nothing about your last review, forgets what you told it yesterday.

Then I started using OpenClaw, and it reframed the problem for me. OpenClaw is an always-running agent with a SOUL, a memory, and enough context about you that talking to it feels less like prompting a chatbot and more like messaging a colleague. It remembers. It knows your setup. I used it for useful things and for completely useless ones, and I had a lot of fun. We've mostly stopped since, if I'm honest, but it worked, and somewhere in there the idea landed: what if that colleague did security?

That's Argus: an open-source application security agent, written in Go, that I've been building with a few colleagues at RedCarbon. It's the project that quietly took the place of Worky, the tool I built and then never used, except this one has a mission I actually care about, so I'm not going anywhere.

Fair warning before you get excited: Argus is v0.2.0, and it's as much an idea as a tool. It's the thing I kept wishing existed, so I built a first version with people who actually do security for a living. I'm not sure I've got the shape right, but the shape is the part worth arguing about, and I'd rather do that in the open than sit on it.

Why security review needs a different shape

I want to be clear here, because this is easy to misread. I'm not saying AI security review is a bad idea. It's a great idea. What I don't believe in is doing it with AI alone. Models hallucinate, and a confident, wrong answer about a vulnerability is worse than no answer at all. Lean the whole thing on a model and you get a tool that sounds authoritative while quietly missing the one finding that mattered.

So the bet behind Argus isn't "point a model at your code". It's the union of three things that each cover for the others' blind spots: deterministic security tools that have been proven for years, a human kept firmly in the loop, and a model to tie it together and reason across the whole picture. Take any one of the three away and it falls over. Especially the human.

Recognizing a security problem is not something you wing. Get a code suggestion wrong and it's annoying; get a security call wrong and it's a breach. So an agent you'd actually trust with this has to earn that trust in ways a coding assistant never has to. Its answers need to trace back to something real instead of a confident guess. Its memory, from the moment it has one, becomes a thing attackers will try to lie to, so who gets to shape it suddenly matters. And it has to understand your world in particular, not security in the abstract, because a good share of the problems that actually bite only make sense once you know how your systems fit together.

None of these choices are settled. They're the ones I'd make today, pulled from the years I've spent around cybersecurity and filed down to the few details I think actually matter. I'm genuinely happy to have every one of them argued with. Here's the reasoning, a piece at a time.

Structured tools, not a shell

The default way to build a code agent in 2026 is to hand a model a shell and let it run. It works shockingly well for writing code. For security, I didn't want it.

When an agent has a shell, two things are true at once: it can do anything, and you can't be sure what it did. In a security context that's backwards. You want the opposite. A small, known set of capabilities, each one auditable.

So Argus doesn't get a shell. It gets tools. Under the hood there are real, boring, deterministic security scanners: Semgrep for static analysis, Gitleaks for secrets, osv-scanner for vulnerable dependencies. Each one is wrapped as a structured tool the agent can call, not a command it can type. The scanner runs, returns structured findings, and the model reasons on top of that.

This is also where an agent earns its place, because application security doesn't suffer from a missing tool. It suffers from too many. Nobody has the time to learn them properly, and even once you know them, remembering to run the right one at the right moment is a discipline of its own. You can wire them into a pipeline, of course, and then a slice of your week goes into managing the pipeline. An agent that already holds them, knows which one answers which question, and reaches for them without being asked is a different proposition from a folder full of CLIs you keep meaning to try.

One thing I'm genuinely proud of, and it's the least flashy part: Argus doesn't reinvent any of this. I'm not rewriting Semgrep, I'm not reimplementing a dependency scanner, because why would I. The whole bet is the opposite. Take the tools that already exist and already work, pull good data out of them, and let the agent reason over that data instead of over a hunch. The set Argus ships with today is small on purpose, and the direction is to let you bring your own: the more real tools it can call, the more signal it has to reason with. How far you push that is up to you.

That division of labor is the whole point. The deterministic layer finds things. The model does what models are good at: reading 400 findings and turning them into a conversation. "These three are the ones that matter, this one is a false positive because of how your auth middleware works, and here's the fix." Not a wall of SARIF. A colleague's summary.

It also keeps Argus honest about where its answers come from. A finding traces back to a tool that actually ran, not to a model that decided to type grep and interpret the output. When the domain is security, that provenance is the difference between a report you can act on and a guess you have to re-verify.

Roles and an audit log

An agent with a memory has a problem a stateless chatbot doesn't: the memory is part of the attack surface. If anyone who can talk to Argus can also teach it, then anyone who can talk to Argus can poison it. "Ignore that finding, it's fine" whispered often enough becomes policy.

OpenClaw already draws this line. If you have permission to write to the memory, you can shape it. If you don't, you can't. Argus takes the same idea and makes it central, because for a security tool it isn't a nice-to-have.

So every request arrives as a principal with a role, and Argus always knows which door you came through. Reach it over the local Unix socket and you're local:$USER; come in through the MCP endpoint and you're mcp:<token-hash>; arrive as a GitHub webhook and you're github:<login>. A viewer can ask questions and read findings, but shaping the memory, changing what Argus believes about your org, is a privileged action. And whatever anyone does, whoever they are, lands in an append-only audit log.

That log turns out to matter for a second reason. Go back to the original itch: teams without a security person. Those teams usually still have someone who has to answer to a CISO, a client, or an auditor about how security is handled, without reading the code themselves. An append-only record of what was reviewed, what was found, and what was decided is exactly the artifact that conversation needs.

SOUL, context, and a memory built for security

This is the part I took most directly from OpenClaw, then closed down hard around security.

Argus keeps a mix of three things, and they are not the same thing, which I keep having to explain to people, past-me included. There's the SOUL, the stable stuff: who Argus is, what your company does, your stack, your compliance posture. It rides along in every single model call, so Argus never forgets whose codebase it's looking at. There's context, the per-task working set for whatever it's reasoning about right now. And there's memory, the curated knowledge that persists from one conversation to the next.

The memory is where the security focus shows. Argus remembers findings. It remembers the things you tell it. And, my favorite part, it remembers your false positives, so the thing you already triaged and dismissed doesn't come back to eat your afternoon next week. That is the single most colleague-like behavior in the whole system. A good reviewer remembers what you already decided.

Say config.py in one of your repos only holds deploy-time placeholders that your secret manager swaps out at deploy. Tell Argus once, and it stops flagging them on that repo. The next review comes back clean, with a note explaining why, instead of the same false alarm you waved off last sprint.

The SOUL is what makes the reasoning fit your world instead of the abstract world of security-in-general. And the cross-session, cross-project knowledge is where I think this goes somewhere a single-repo tool can't follow. A coding agent pointed at one repository is blind to how that repository talks to the other twelve. Plenty of the security problems that actually hurt live in exactly that gap: the service that trusts input another service should have sanitized. Feed Argus enough of your world and it can start to reason across that boundary. It's early, but that's the direction.

OpenClaw is a general assistant, open-ended by design. Argus is the opposite. It knows it's a security tool, and everything (the tools, the skills, the memory, the persona) is shaped for that one job. Narrower, but deeper.

What Argus does today (v0.2)

Enough philosophy. Here is what actually runs.

One thing to set straight first, because the word "security" invites the wrong expectation. Argus doesn't watch your infrastructure, it doesn't sit in front of your traffic, and it is not a SOC. It reads code. That's the job it's built for, and the rest is somebody else's product.

Argus is a daemon, argusd, one shared instance per organization. Every way you talk to it (a terminal UI, the MCP endpoint, GitHub webhooks, and Slack soon) is a different door into the same process, sharing one memory, one tool registry, one audit log.

The most visible thing it does is review pull requests. Connect it as a GitHub App and it turns up on the thread like any other reviewer, except this one only cares about security. When it flags something you can push back right there, "Argus, is this finding real?", and it answers in context instead of making you go and dig. That back-and-forth isn't a nicety, it's the design: Argus is meant to be argued with, not obeyed.

Because it's also an MCP server, the AI tools you already use can consult it as a colleague rather than a black box. This is the part I reach for most: I point at something I just wrote and ask whether it's safe. And I want to be fair about the alternative, because the tools you already have are good at this. Claude and friends ship security skills, people write their own, and they work. What none of them has is your company: the other twelve repos, how your services talk to each other, which of your systems actually holds the data worth stealing. Ask Argus whether a pattern is a problem and it answers for your world instead of for security in the abstract, because the SOUL and the memory are right there. And it runs skills, which is how security methodology gets baked in. It ships with a handful: pr-quick-check for a fast pass over a diff, authz-audit for hunting authorization flaws, secret-rotation-plan for finding committed secrets and deciding what to rotate first, and threat-modeling for a STRIDE pass. You write your own the same way the built-ins are written, as a Markdown SKILL.md.

Getting started is ./argus init to pick a provider and write your SOUL, ./argus doctor to check the scanners are wired up, ./argus codehost setup to connect GitHub, and plain ./argus to just chat with it. There's a container image on ghcr.io with the scanners pre-bundled if you'd rather not install Semgrep and friends by hand.

A word on which model runs all this, because it's a design choice and not an afterthought. Argus is built to run on the AI you already have and already trust, rather than the one a vendor picks for you. The provider layer sits behind an interface, and argus init is where you choose. Today that choice is still narrow, with one provider implemented, and I won't dress that up as a feature. Support for any OpenAI-compatible endpoint is what I'm building right now, so depending on when you read this it may already be in. That's also the change that opens the door to local models, since most local runners speak the same API, and it matters for the teams I most want to reach: the ones who can't send their code to somebody else's API and don't have the budget to.

Where it's going

The idea list is longer than the changelog, which is the correct ratio for a v0.

The near stuff: Slack as a first-class channel, so Argus really is the colleague you message. Local models. More skills.

The stuff I'm actually excited about: service and code discovery, so Argus builds its own map of your systems instead of waiting to be told, and a view of how your projects connect, because that cross-project graph is where the non-obvious problems hide.

But I want to be careful, because I've made this mistake before. With Worky I built a showcase site and full docs for a tool with zero users, then watched it drift because there was no real usage telling me what to build next. A roadmap without users is fiction. So I'm not going to pretend I know exactly what Argus needs. The roadmap comes from whoever picks it up.

The difference from Worky, the reason I'm not worried this one ends up on the same shelf, is that I use Argus. It has a mission I care about. This is the tool I want to keep alive, and I get a vote in what it becomes precisely because I'm one of its users.

Come build in AI and security

There's a bigger thing behind Argus, and it's the reason I'm writing this instead of just pushing a repo.

AI and cybersecurity are converging fast, and most people are only watching one side of it. Back in June we ran a hackathon at RedCarbon: one day, tiny teams, AI pointed at security problems. I wrote about being on the jury in the Worky retrospective, but the part I keep coming back to is the range. One team went after phishing aimed at non-technical family members. Another built for the SOC. Another attacked the security of AI models themselves. Same prompt, completely different directions, all of them real.

Argus is just my direction, and it comes from something I actually live. I'm lucky here: I have security colleagues at RedCarbon who helped me shape it, pick the tools, and read what those tools are really saying. But they spend their days pointing our own AI agents at SOC problems, and none of them has time to sit behind our code's security posture every single day. So the developers have to, and Argus automates the exact work those colleagues would otherwise do by hand. And that job, it turns out, is increasingly buildable: models are getting good enough at security reasoning that the bottleneck is no longer the model, but whether someone shapes it into something trustworthy and useful.

A while back I wrote that AI will not secure your codebase, that it won't do the job for you but it can surface risk earlier, act as an early-warning system. Argus is me trying to make that concrete. Not a magic box that makes you secure, but a colleague who has read your whole codebase, remembers what you decided, and is awake at 2am when the PR lands.

It's on GitHub, Apache 2.0, v0.2 and honest about it. If you do security, or you just want the security colleague you don't currently have, clone it, break it, write a skill, and tell me how you use it. Real usage is the one thing that turns a fun experiment into a tool that matters, and I learned that the expensive way.

Worky has two stars and I made my peace with that. Argus I'd actually like you to star, because this is the one I'm keeping. And if you've been sitting on your own idea at the intersection of AI and security, stop sitting on it. The water's warm.

The 4.8 million figure is ISC2's estimate of the global cybersecurity workforce gap: the distance between the security professionals organizations say they need and the ones actually available to hire. Source: ISC2 2024 Cybersecurity Workforce Study. ↩

Gemini 3.6 Flash: Google's Fastest Bet in a Crowded Race 🚀

Domenico Tenace — Wed, 29 Jul 2026 08:33:15 +0000

Overview

Hey everyone 👋

Google dropped Gemini 3.6 Flash on July 21, 2026, and it's worth talking about. Not because it's a revolution, but because it quietly improves on almost everything from 3.5 Flash while getting cheaper and faster at the same time. That's a combination you don't see often.

Let me break down what actually changed, how it stacks up against the competition, and whether you should care.

Let's dive in! 🤙

What Is Gemini 3.6 Flash? 🤔

Gemini 3.6 Flash is Google's workhorse model for developers, the go-to for agentic workflows, coding tasks, long-document reasoning, and multimodal work. It's not Google's most capable model (that's still the upcoming 3.5 Pro and eventually Gemini 4), but it's the one most developers will actually use day to day.

It was released alongside two companion models: Gemini 3.5 Flash-Lite, designed for high-throughput and low-latency tasks like agentic search and document processing, and the limited-pilot Gemini 3.5 Flash Cyber for governments and trusted partners.

The model is available in Google AI Studio, the Gemini API (model ID gemini-3.6-flash), the Gemini app, Antigravity, Android Studio, and Vertex AI.

The Numbers: What Actually Changed 📊

Benchmarks

Gemini 3.6 Flash improves on Gemini 3.5 Flash across the board: coding went from 55.1% to 58.7% on SWE-Bench Pro, long-context retrieval went from roughly 27% to 54.0%, and computer use went from 78.4% to 83% on OSWorld Verified.

Average task time fell from 2.7 minutes to 1.3 minutes, while estimated task cost declined about 18 percent. That's not a minor tweak. That's a meaningfully faster agent in practice.

Speed

It runs at about 280 tokens per second, which makes it one of the faster models in its class for interactive use. For agentic workflows where you're chaining multiple LLM calls, this compounds fast.

Pricing

Gemini 3.6 Flash costs $1.50 per million input tokens and $7.50 per million output tokens. Input pricing is unchanged from Gemini 3.5 Flash, but output dropped from $9.00 to $7.50 per million tokens.

Context Window and Knowledge Cutoff

The model runs a 1 million-token context window with a 64,000-token output cap, and its knowledge cutoff is March 2026, up from January 2025 on Gemini 3.5 Flash. That's a 14-month jump, which matters more than it sounds. A model that knows about recent framework releases, pricing changes, and API updates needs less web retrieval to stay useful.

Token Efficiency

The model takes fewer reasoning steps and tool calls to complete multi-step workflows, which is a large part of why it uses roughly 17 percent fewer output tokens than its predecessor. You're paying for less and getting more done. That's the ideal direction.

How It Compares to the Competition 🥊

vs. Claude Sonnet 5

Claude Sonnet 5 outperforms on 3 benchmarks including SWE-Bench Pro and GDPval-AA, while Gemini 3.6 Flash wins on OSWorld-Verified and CharXiv-R. Claude Sonnet 5 has a slight edge in raw benchmark performance.

But the cost story is different. Gemini 3.6 Flash is 25% cheaper on both input and output compared to Claude Sonnet 5. At 100,000 tasks per month with 5,000 input and 10,000 output tokens each, that's $2,750/month in savings. For cost-sensitive workloads, Gemini is the clear winner.

Gemini 3.6 Flash also runs at 304 tokens per second compared to roughly 180 for Claude Sonnet 5. For agent workflows where latency matters, the speed difference is noticeable.

My take: if code quality at any cost is the priority, Claude Sonnet 5 still wins on most coding benchmarks. If you're building high-volume agent pipelines or cost is a real constraint, Gemini 3.6 Flash makes a strong argument.

vs. GPT-5.6 Luna

GPT-5.6 Luna remains cheaper than Gemini 3.6 Flash at public API rates, but Artificial Analysis measured Gemini at 304 output tokens per second compared to 190 for Luna. This creates a practical trade-off: Luna offers lower token rates, while Gemini produces output faster.

Independent testers report Gemini 3.6 Flash loses most coding benchmarks and GDPVal to Grok 4.5 and GPT-5.6 Luna. So if pure coding benchmark numbers are what you're optimizing for, Google isn't at the top of that list right now.

vs. Gemini 3.5 Flash

Both Gemini 3.6 Flash and Gemini 3.5 Flash currently score 50 on the Artificial Analysis Intelligence Index. Existing Gemini 3.5 Flash users have the clearest migration case, especially when latency and output volume drive costs.

In other words: same intelligence, faster, cheaper, fresher knowledge cutoff. The upgrade is a no-brainer if you're already on 3.5 Flash.

What's Missing: The Elephant in the Room 🐘

The most notable absence in this announcement is Gemini 3.5 Pro. Google originally said at I/O in May that 3.5 Pro would launch the following month. That deadline passed without a public release. Bloomberg reported on July 16 that the model was running months behind schedule, with Google spending extra time on its coding capabilities.

Google did not release Gemini 3.5 Pro in this announcement. The company said the Pro model fell short of internal expectations on coding and complex reasoning, so its broader release was delayed.

This is the real story. A delayed Pro model means that right now, Google's top available offering in the Flash tier competes on price and speed but not on raw reasoning against Claude Opus or GPT-5.6. Google also confirmed that pre-training has begun on Gemini 4, which the team described as its most ambitious pre-training run yet. So the roadmap is clearly ambitious, but the present gap is real.

The Pros 👍

Cost efficiency is excellent. Roughly half the output price of Claude Sonnet 5 at production scale is meaningful money. For startups or anyone watching API bills closely, this matters.

Speed is genuinely impressive. At 304 tokens per second, it's 1.7x faster than Claude Sonnet 5 for agent workflows where latency matters.

Multimodal support is broad. Gemini 3.6 Flash supports voice, video processing, images, PDFs, and audio as input. Claude Sonnet 5 doesn't support voice or video. For multimodal applications, Gemini is the stronger choice.

The knowledge cutoff jump is significant. Going from January 2025 to March 2026 in one model generation means you're working with a model that actually knows about tools and frameworks released in the past year and a half.

Token efficiency means lower costs in practice. Fewer output tokens for the same quality work, combined with a lower output price, compounds into real savings at volume.

The Cons 👎

The Pro model is still missing. For developers who need the strongest possible reasoning and coding quality today, Google's delays leave a gap that Claude Opus and GPT-5.6 are filling.

Raw coding benchmark scores lag behind top competitors. On the benchmarks that matter most to developers, Grok 4.5, GPT-5.6 Luna, and Claude Opus 4.8 still outperform Gemini 3.6 Flash. Speed and cost don't compensate for quality when you're debugging something complex.

Intelligence Index hasn't moved. Gemini 3.6 Flash and Gemini 3.5 Flash both score 50 on the Artificial Analysis Intelligence Index. Faster and cheaper is great, but it's not smarter. If you were hoping for a reasoning leap, this isn't it.

Gemini 4 uncertainty. Google teasing their next major model while 3.5 Pro is still delayed creates uncertainty for teams planning their model strategy. Do you build on 3.6 Flash now, or wait?

Who Should Use Gemini 3.6 Flash? 🎯

Existing Gemini 3.5 Flash users. The migration is a pure upgrade: same intelligence, faster, cheaper, better knowledge cutoff. No reason not to switch.

Cost-sensitive teams building agents. If you're running thousands or millions of API calls, the pricing advantage compounds fast. At scale, Gemini 3.6 Flash is the most efficient option in its class.

Multimodal applications. Voice, video, images, audio all in one model with a 1M token context window. If your use case touches multiple modalities, this is the most capable option at this price point.

Developers already in the Google ecosystem. Antigravity, AI Studio, Vertex AI, Android Studio. If you're already in these tools, the integration is seamless.

Who should look elsewhere: if you need the strongest possible code generation today and budget is secondary, Claude Opus 4.8 or GPT-5.6 Luna are stronger choices on raw coding benchmarks.

My Take 💭

Gemini 3.6 Flash is a solid, honest upgrade. Google didn't promise a revolution and didn't deliver one. What they delivered is a faster, cheaper, more efficient model with a dramatically improved knowledge cutoff. For most agentic workloads, that's exactly what you need.

The absence of 3.5 Pro is frustrating, and the coding benchmark gap against the top tier is real. But if you're building cost-sensitive pipelines, working with multimodal content, or already deep in Google's ecosystem, 3.6 Flash makes a compelling case.

The question isn't "is this the best model?" It's "is this the best model for what I'm building?" For a lot of teams, the answer is yes.

Happy coding! ✨

🌲 Linktree: https://linktr.ee/domenicotenace
🐙 Domenico Tenace Open Labs: https://github.com/Domenico-Tenace-Open-Labs

Follow me on dev.to for more articles 👇

Domenico TenaceFollow

Passionate about the IT world and everything related to it ✌🏻 Open Source enthusiastic 🦠

If you like my content or want to support my work, you can support me with a small donation. I would be grateful 🥹

DEV Community: Playful Programming

Moving to European Digital Services, One Decision at a Time

Proton made the change visible

The corporate map is more complicated than the logos

Some changes need almost no migration

Replacing Notion meant building the alternative

Sometimes the correct migration is no migration

The process I use before changing a service

Change the next decision

Emanuele BartolesiFollow

INP and Partytown: give the main thread back to your users

Introduction

INP in a few words

What's inside an interaction?

The main thread: a one lane road

Partytown: move the party somewhere else

How does it work?

Option 1: Service Worker (the fallback)

Option 2: Atomics (the fast one)

The two rules to remember

Angular

Step 1: install

Step 2: serve the Partytown files

Step 3: index.html

Step 4: an analytics service

Step 5: track a click

React

Step 1: install and copy the files

Option A: client-side app (Vite)

Option B: server-rendered app (the <Partytown /> component)

Scripts added later

Track page views and clicks

Check that it works

Where INP really wins

Trade-offs: no magic here

Measure, don't guess

Partytown won't fix your own code

Conclusion

The Grand Unifying Architecture of Frontend

Core Responsibilities

1. Navigation (client)

2. Content (server)

3. Affordances (client)

Following the Shape

Revisiting the Spectrum

A Modern Take

Navigation: Delegation and progressive enhancement

Content: Reactive reads over the wire

Affordances: An async-aware graph that hydrates once

Traversing the Spectrum

Conclusion

SpellBook of Skill: The Twin Project Nobody Asked For, But I Built Anyway 🧙🏻‍♂️

Overview

What It Actually Is 🤔

Built Entirely with OpenCode + OpenRouter + DeepSeek V4 Pro 🛠️

What's In There Right Now 📚

This Is Where You Come In 🤝

Try It Out 🚀

Final Thoughts 🌟

OpenCode + DeepSeek V4: The Budget Combo That Doesn't Feel Like a Budget Combo 🐋

Overview

Quick Context on DeepSeek V4 🤔

Setting It Up with OpenCode 🔧

What Actually Impressed Me 👍

Where It Falls Short 👎

The Real Test: Studio Pulse 🚀

Who Should Try This Combo 🎯

Final Thoughts 🌟

Nobody Argued For Your Stack

Why This Matters More Than It Used To

What an Argument Looks Like

The Argument Nobody Published

What Happens If Nothing Changes

Where Does the Next Idea Come From?

My AI Content Journey

Stepping up my Game

Enter LLMs

Trying LLMs for Myself

AI Assisted Writing

Two React Design Choices Developers Don’t Like—But Can’t Avoid

Step 3: `index.html`

Option B: server-rendered app (the `<Partytown />` component)

`Math.random`

`Date.now()`, `crypto.randomUUID()`, `process.memoryUsage()`, etc...