DEV Community: Playful Programming

Stop Prompting. Start Thinking.

Davide Imola — Fri, 17 Apr 2026 00:00:00 +0000

This post exists because of a problem I've always had: when I sit down to write something (an article, a post, anything), the words don't come out right. My reasoning compresses. I end up with something weaker than what I actually think.

I'm a talker. I do my best thinking out loud.

For a while I tried to fix this with AI: give it a topic, get back a draft, edit it into something mine. It worked okay. But the output felt generic, detached. It didn't sound like me.

Then I noticed something: the same problem was showing up in my development work. I'd hand a task to an AI tool, get back code that was technically correct but didn't feel right. Wrong abstractions, missing conventions, no real judgment. The AI was generating, not thinking.

The fix in both cases turned out to be the same thing: stop treating AI as a generator. Start treating it as a thinking partner.

This post is about how I made that shift and the workflow I built around it. It started as a method for development, but I've since applied it to writing, editorial work, branding. The underlying principle is the same everywhere.

(And yes, this post was written using that exact method. I spoke, the AI asked questions, pushed back, and helped shape what I was saying into something readable.)

Think first. Then open the AI.

The biggest mistake I see people make with AI is reaching for it too early.

Before I type a single message, I read the requirements myself. I think about what needs to be done, what the tricky parts are, what I'd need to clarify with the PM or with myself. I form my own mental model of the problem.

Only then do I bring in the AI.

This isn't a ritual. It's practical. If I don't understand the task, I can't explain it well. And if I can't explain it well, I can't respond usefully when the AI starts asking hard questions. The quality of the entire session depends on that first ten minutes of thinking alone.

There's also something else: when you understand the problem yourself first, you stay the senior in the room. AI tools are fast, confident, and occasionally wrong. If you haven't thought it through, you have no filter for the output.

Big picture first, then drill down

Once I start working with an AI, I never jump straight to implementation details.

I start broad: here's the task, here's the context, here's roughly what I think needs to happen. Then I use a skill called grill-me: a Socratic dialogue where the AI asks hard questions instead of immediately generating a plan. It pushes back, challenges assumptions, asks "why" a lot.

This phase is where most of the real work happens. Questions asked upfront eliminate entire categories of rework later. A wrong assumption caught during design costs nothing. The same assumption caught during implementation costs a lot.

The key insight is that going deeper on design isn't wasted time. It's the most leveraged time in the whole process. I used to feel like I was procrastinating by not writing code yet. Now I treat this phase as the actual work.

One recurring problem I've had: even with a solid PRD, individual user stories get lost during implementation. You start a session, the AI tackles the obvious parts, and by the end something that was clearly in the spec is just... missing. Tools like Ralph exist specifically for this: an autonomous agent loop that works through a PRD story by story, tracking progress across iterations so nothing falls through the cracks. I haven't fully integrated it yet, but the problem it solves is real and I've felt it.

Voice unlocks context you didn't know you had

During design discussions, and honestly throughout the whole process, I use voice input instead of typing.

Not because typing is slow. Because speaking makes me think differently.

When I'm reading a response and the answer isn't a simple yes or no, when there are tradeoffs, nuances, things that depend on context I haven't fully explained, I switch to voice. Speaking out loud forces me to reason in real time. I self-correct mid-sentence. I remember things I forgot to mention. I add context that would have stayed locked in my head if I'd just typed a terse reply.

Voice also makes longer, richer responses feel natural. Nobody wants to type three paragraphs. But talking for thirty seconds? Easy.

The result is better input, better follow-up questions, and output that's more grounded in what I actually want.

This applies to writing just as much as to development. I'm not a natural writer. The channel of "sit down and type an article" compresses my thinking instead of expanding it. Speaking to an AI as an editorial partner, having it ask me questions, challenge weak angles, surface the structure in what I'm saying: that's what made this post possible. The ideas were always there. I just needed a different way to get them out.

Skills and context files are guardrails, not magic

When I first started using AI for development, I'd give it a task and it would produce code that worked. Technically correct. But not written the way I'd write it. No tests, or tests that weren't meaningful. Styling that didn't match the system. Abstractions that solved the problem but ignored the conventions already in the codebase.

The fix wasn't better prompts. It was better context.

I now have a CLAUDE.md file in every project: a context document that explains the stack, the conventions, the design tokens, what not to do. It gets read at the start of every session and it changes everything. The output starts looking like code that belongs in the codebase.

Then I started using skills. A skill is a prompt template that encodes a specific process. Instead of explaining how I want something done every time, the skill carries that knowledge. tdd runs a test-first development loop. simplify does a post-implementation review for code quality. grill-me runs the Socratic design session.

I was skeptical of domain-specific skills at first. I thought they'd be overkill. Then I loaded a frontend design skill and the output stopped looking generic. I changed my mind.

BYOS: Build Your Own Skills

The most powerful thing you can do is write skills for your own workflows.

The skills I use most aren't the built-in ones, they're the ones I wrote myself. write-blog-post (the skill behind this post) doesn't write for me. It interviews me, pushes back on weak angles, helps me find the structure in what I'm saying. social-post takes a finished post and turns it into platform-specific content for LinkedIn and BlueSky. I have a skill for Worky (an open-source project I'm building) that helps define issues in a way that's specific to that project's conventions.

All of these are in my public repo if you want to look at them.

The pattern is: when you find yourself repeating the same setup instructions at the start of a session, that's a skill waiting to be written. Once you write it, it works exactly the same way every time, for you and for anyone else on the project.

The real unlock isn't any individual skill. It's the realization that you can codify your own processes.

A note on tools

I use Claude Code as my main AI tool, specifically in agentic mode with Claude as the driver on implementation tasks while I stay in the PM seat. But the principles in this post aren't Claude-specific. The mental model, the voice habit, the context files, the skill pattern: these transfer to any AI tool that lets you shape the interaction.

Agentic workflows (where the AI executes multi-step tasks autonomously) are where things are heading, and they make the guardrails even more important. The less you're in the loop on individual steps, the more your context files and skills need to encode your standards upfront.

The review loop

After implementation, I don't just run the tests and move on. I do two reviews in parallel: mine and the AI's.

I look at the code myself first. Then I ask Claude to review it too, specifically looking for things I might have missed: security issues, edge cases, patterns that work but don't belong. Then I compare. Some findings overlap. Some are mine only. Some are the AI's only. The merged list becomes the input for the next iteration.

This back-and-forth is where a lot of quiet improvements happen. It's also where I catch the things that are technically correct but feel wrong: an abstraction that solves the problem but adds cognitive overhead, a test that passes but doesn't actually verify the behavior I care about.

There are tools that try to automate this loop entirely. I'm curious and plan to experiment, but I'd want to keep my own review at the end regardless. Not every finding the AI surfaces is worth acting on, and not every real problem shows up in an automated scan. The loop is valuable. Removing the human from it entirely is a different bet.

You are still the senior developer

Everything above is in service of one principle: the AI gives feedback. You evaluate it.

Don't accept output because it looks confident. Don't accept a plan because it's detailed. When the AI produces something, read it. Think about whether it's what you actually wanted and whether it's written the way it should be. When you disagree, say so. Be specific about your reasoning: "I'd have done this differently, here's why, what do you think?" This usually produces a better answer than the original.

AI-assisted work works when the human is still driving. The moment you stop exercising judgment, you're not working with an AI partner. You're just running an autocomplete on your codebase.

This is my workflow as it stands today. It'll evolve. I'm still figuring out how to make the review loop tighter, and I'm experimenting with new skills as I find new patterns.

If you work differently, or if something here doesn't make sense for your context, I'd genuinely like to hear it. Leave a comment or find me on LinkedIn.

Resources

The video that originally inspired a lot of this workflow (and where I first came across most of these skills):

AI-Assisted Development workflow by Matt Pocock

The core skills I use, all open source:

My own custom skills (write-blog-post, social-post, and others) are in my public repo.

Stop Coding Through Remote Desktop. Use VS Code Remote Tunnels Instead

Emanuele Bartolesi — Wed, 15 Apr 2026 07:10:40 +0000

There is a pattern I keep seeing with customer environments.

You get access to a VM for development. The code stays there. The dependencies are already there. The network access is there too. On paper, it looks fine.

Then reality starts.

You are expected to work through Remote Desktop, as if software development were the same thing as clicking around a server. It is not. Remote Desktop is tolerable for admin work. For actual coding, it is a bad experience. The editor feels disconnected from your normal workflow. Shortcuts feel wrong. Terminals are awkward. Moving between tools is slower than it should be. You are technically “inside” the environment, but you are not really productive.

In my case, there was another constraint. I could not even sign into VS Code on the customer VM with my own account, which meant no normal setup, no synced configuration, and no easy way to work the way I usually do.

That is where VS Code Remote Tunnels becomes the right solution.

The real-world scenario

Instead of living inside a remote desktop session, you expose the development environment through a secure tunnel and connect to it from your local VS Code. The code stays on the customer VM. The execution stays on the customer VM. But the editor experience comes back to your own machine, where you can actually work properly.

Remote Tunnels is the answer I would pick for that every time.

What VS Code Remote Tunnels actually does

VS Code Remote Tunnels gives you a way to connect to a remote machine from VS Code without setting up SSH access. The official model is simple: you create a secure tunnel from the remote machine, and then connect to it from a VS Code client somewhere else. Microsoft’s documentation describes it as connecting to a remote machine, such as a desktop or VM, through a secure tunnel using Microsoft dev tunnels.

That matters because it changes where the work happens.

The code stays on the remote VM. The terminals run on the remote VM. Debugging happens against the remote VM. VS Code installs its server-side components on that machine, and your local VS Code becomes the client for that remote environment.

Another practical point is that SSH is not required. That is one of the biggest advantages in customer environments, because SSH is often blocked, restricted, or simply not part of the approved setup. Remote Tunnels gives you another path that still keeps the work inside the target machine.

You can then connect in two main ways. You can use local desktop VS Code with the Remote - Tunnels extension, or you can connect through VS Code for the Web in the browser. That browser path is useful when you need access from a locked-down device, although the desktop client is usually the better experience.

There is one important limitation worth stating clearly. The VS Code Server used behind this model is designed for a single user, not as a shared multi-user development service. Microsoft also states that hosting the VS Code Server as a service is not allowed. So this is a personal remote development setup, not a team-hosted IDE platform.

That is why Remote Tunnels fits this customer scenario so well. It gives you remote development, not remote desktop. That is the real difference.

Why it fits this customer use case

This is exactly the kind of setup where Remote Tunnels is the right answer.

The customer wants the work to stay inside their environment. That is reasonable. The code, dependencies, network access, and internal services are already on the VM. Moving everything to a local machine would create more friction, more approvals, and in some cases more risk.

At the same time, working through Remote Desktop is a bad trade.

How to set it up

The setup is surprisingly simple. That is part of why this works so well in customer environments.

First of all, you need to download VS Code Server.
You can download it directly from the official Download page of Visual Studio Code website (https://code.visualstudio.com/Download)

From this page, as you can see in the image above, you can select your OS and your CPU family.
You can also use VS Code with the UI, but it doesn't make sense if you want to install only the server part.

Then you start the tunnel with:

code tunnel

When you run that command, VS Code downloads and starts the VS Code Server on that machine, then creates the tunnel for remote access. The first time, you will also be asked to accept the server license terms, unless you pass the CLI flag to accept them up front.

After that, the CLI gives you a vscode.dev URL tied to that remote machine. When you open that URL the first time from a client, you will be asked to authenticate with GitHub. That authentication is how VS Code checks that both sides are tied to the same account and that you are allowed to access the remote machine.

There are two practical ways to connect.

The first is through the browser using that vscode.dev link. This is the fastest way to prove the setup works.

The second, and usually better option, is from your local desktop VS Code. For that, install the Remote - Tunnels extension, open the Command Palette, and run Remote Tunnels: Connect to Tunnel. You can also see available machines in the Remote Explorer.

So the basic flow looks like this:

On the customer VM, run code tunnel
Authenticate when prompted
Open the generated vscode.dev URL or connect from local VS Code
Start working on the remote codebase from your own editor

There are two practical details worth calling out.

First, the tunnel is only reachable while VS Code is running there, unless you explicitly set it up to keep running. Microsoft documents a service mode for this with code tunnel service install, and there is also a --no-sleep option to help prevent the remote machine from going to sleep.

Second, this does not require VS Code to open inbound listeners on the VM. Microsoft states that hosting and connecting use authenticated outbound connections to the Azure-hosted tunneling service, and that no firewall changes are generally necessary. That is one of the reasons this can fit locked-down environments better than people expect.

Trade-offs and limits

Remote Tunnels is a strong solution for this scenario, but it is not magic. It has constraints, and it is better to say them clearly.

The first limit is the trust model. To create and access a tunnel, you authenticate with GitHub or Microsoft, and the tunnel itself is brokered through Microsoft’s dev tunnel service. That is exactly why setup is easy, but it also means some customer environments may reject it on policy alone, even if the technical setup works.

The second limit is extension support, especially in the browser. The desktop VS Code client is usually the best experience. The browser option is useful, but not every extension behaves the same way there. VS Code’s remote documentation is explicit that extensions may run in different locations, local or remote, depending on the extension type and the client being used.

The third limit is that this is not a shared remote IDE platform. Microsoft states that the VS Code Server is intended for a single user and that hosting it as a service is not allowed. So this is a personal remote development workflow, not something you should pitch as a team-wide hosted development environment for many users.

The fourth limit is operational persistence. A tunnel is easy to start, but if the remote machine sleeps, shuts down, or the tunnel service is not kept running, your session is gone until it comes back. Microsoft documents service mode and sleep-related options for that reason.

👀 GitHub Copilot quota visibility in VS Code

If you use GitHub Copilot and ever wondered:

what plan you’re on
whether you have limits
how much premium quota is left
when it resets

I built a small VS Code extension called Copilot Insights.

It shows Copilot plan and quota status directly inside VS Code.

No usage analytics. No productivity scoring. Just clarity.

👉 VS Code Marketplace:
https://marketplace.visualstudio.com/items?itemName=emanuelebartolesi.vscode-copilot-insights

Using GitHub Copilot CLI with Azure AI Foundry (BYOK Models) – Part 2

Emanuele Bartolesi — Fri, 10 Apr 2026 09:54:00 +0000

In Part 1, you ran GitHub Copilot CLI against a local model using LM Studio.

That setup gives you control. No external calls. No data leaving your machine. But it comes with clear limits. Small models struggle, and output quality drops fast on anything non-trivial.

This is where Azure AI Foundry comes in.

Instead of running models locally, you connect Copilot CLI to a cloud-hosted model you control. You still use the same BYOK (Bring Your Own Model) approach, but now the model runs on Azure.

That changes the trade-offs:

You gain better models and stronger reasoning
You keep control over the endpoint and deployment
You accept cost and network dependency

This is not a replacement for the local setup. It is the next step if you want privacy but at the same time, more power.

Setting Up Azure AI Foundry

This is the only "Azure-heavy" part. Keep it minimal. You just need a working endpoint and a deployed model.

1. Create or Use an Existing Resource

Go to Azure AI Foundry in the Azure portal.

You need:

A resource already created
Access to it (permissions matter)

If you already use Azure OpenAI, you can reuse it.

2. Deploy a Model

This step is mandatory.

In Azure, you cannot call a model directly. You must deploy it first.

Steps:

Open your resource
Go to Model deployments
Select a model (for example GPT-4 class)
Assign a deployment name

Example:

copilot-gpt53codex

This name is what Copilot CLI will use later.

This is how the GPT 5.3 Codex looks like, but you can also deploy models directly from the HuggingFace catalog.

If your AI Foundry is good, you can deploy the models directly with the Deploy button in the model details page.

3. Get Endpoint and API Key

From the resource, retrieve:

Endpoint URL
API key

Typical endpoint:

https://<your-resource>.openai.azure.com/

You will combine this with the deployment in the next step.

4. Build the Final Endpoint

Copilot CLI expects a full path, not just the base URL.

Format:

https://<your-resource>.openai.azure.com/openai/deployments/<your-deployment>/v1

Example:

https://my-ai.openai.azure.com/openai/deployments/copilot-gpt53codex/v1

If this path is wrong, nothing will work.

5. Quick Validation

Before using Copilot CLI, validate:

The deployment exists
The API key is valid
The endpoint is reachable

If you skip this, debugging later becomes painful.

Connecting Copilot CLI to Azure

This is the same pattern as Part 1. Different endpoint. More constraints.

Set the Environment Variables

You must point Copilot CLI to your Azure deployment.

PowerShell example:

$env:COPILOT_PROVIDER_BASE_URL="https://<your-resource>.openai.azure.com/openai/deployments/<your-deployment>/v1"
$env:COPILOT_MODEL="<your-deployment>"
$env:AZURE_OPENAI_API_KEY="<your-api-key>"

What matters:

COPILOT_PROVIDER_BASE_URL → full Azure endpoint
COPILOT_MODEL → deployment name, not model name
AZURE_OPENAI_API_KEY → required for authentication

No COPILOT_OFFLINE here. Requests go to Azure.

Run a Simple Test

Open Copilot CLI with the following command in a project folder you want to test:

copilot --banner

Ask a simple tasks like: "Give me the list of all the files larger than 2MB".

If everything is configured correctly:

The response comes from your Azure AI Foundry Model
The answer is really fast, at least faster than the answers from the Part 1

Reality Check

This is not “Copilot with Azure magic”.

It is:

Copilot CLI acting as a thin client
Azure acting as the model provider

You gain better models, not better tooling.

👀 GitHub Copilot quota visibility in VS Code

If you use GitHub Copilot and ever wondered:

what plan you’re on
whether you have limits
how much premium quota is left
when it resets

I built a small VS Code extension called Copilot Insights.

It shows Copilot plan and quota status directly inside VS Code.

No usage analytics. No productivity scoring. Just clarity.

👉 VS Code Marketplace:
https://marketplace.visualstudio.com/items?itemName=emanuelebartolesi.vscode-copilot-insights

Using GitHub Copilot CLI with Local Models (LM Studio)

Emanuele Bartolesi — Thu, 09 Apr 2026 11:36:59 +0000

Local AI is getting attention for one simple reason: control.

Cloud models are strong and fast, but for many companies and developers, especially when experimenting or working with sensitive code, that is not ideal.

This is where local models come in.

Tools like LM Studio let you run LLMs directly on your machine. No external calls. No data leaving your environment or your network.

Instead of sending prompts to cloud models, you can point Copilot CLI to a local model running in LM Studio.

This setup is not perfect. It is not officially seamless. But it works well enough for learning, experimentation, and some real workflows.

What You Need

Before setting this up, make sure the basics are clear. This is not a plug-and-play setup. There are a few moving parts, and some assumptions.

GitHub Copilot CLI

You need GitHub Copilot CLI installed and working.

You can launch GitHub Copilot CLI with the following command:

copilot

or even better, if you want to see the banner in the terminal:

copilot --banner

By default, the CLI uses GitHub-managed models, but now you can override that.

Note: You must be authenticated with GitHub and have access to Copilot.

LM Studio

LM Studio is the simplest way to run local LLMs without dealing with raw model tooling.

What it gives you:

A UI to download and run models
A local server that exposes an OpenAI-compatible API
No need to manually manage inference engines

Once running, it exposes an endpoint like (OpenAI compatible):

http://localhost:1234/v1

This is the key piece. Copilot CLI will talk to this endpoint instead of the cloud.

A Local Model (Be Realistic)

Not all models are equal. And your hardware matters.

For this guide, a small model like:

qwen/qwen3-coder-30b

is enough to get started.

But be clear on the trade-offs:

Small models → fast, but weaker reasoning
Large models → better output, but slow or unusable on most laptops

If you are on a standard laptop:

1B–3B models → OK
7B+ models → borderline
13B+ → usually not practical without a GPU

On my laptop I am giving a chance to the NVidia model nemotron-3-nano-4b but on my gaming PC (that I use for developing and not gaming) I use bigger models la Qwen3 Code or similar.

Tip: Start small. The goal here is understanding the workflow, not benchmarking models.

Connecting Copilot CLI to LM Studio

This is the part most people get wrong.

Copilot CLI is not designed primarily for local models. You are using a BYOK (Bring Your Own Key/Model) path that is still evolving.

It works, but you need to be precise.

Reference: https://docs.github.com/en/copilot/how-tos/copilot-cli/customize-copilot/use-byok-models

1. Set the Environment Variables

You must override the default Copilot provider.

In PowerShell:

$env:COPILOT_PROVIDER_BASE_URL="http://localhost:1234/v1"
$env:COPILOT_MODEL="google/gemma-3-1b"
$env:COPILOT_OFFLINE="true"

What they do:

COPILOT_PROVIDER_BASE_URL → points to your local LM Studio server
COPILOT_MODEL → defines which model to use
COPILOT_OFFLINE → prevents fallback to cloud models

If COPILOT_OFFLINE is not set, Copilot may silently use cloud models.

2. Run a Simple Test

Open LM Studio, and open the *Developer * tab.
Click on the switch of the Status and the server will start in a second.

Then, click on Load Models and load the models you prefer that you downloaded previously on your machine.

Open Copilot CLI with the following command in a project folder you want to test:

copilot --banner

Ask a simple tasks like: "Give me the list of all the files larger than 2MB".

If everything is configured correctly:

The response comes from your local model
No external API calls are made

Don't expect a result in seconds like a normal cloud model, but it depends on your hardware; it can also take minutes sometimes.

Reality Check

This is not a first-class integration.

No guarantee of full compatibility
No optimization for local inference
No smart routing like in GitHub-hosted Copilot

But for simple CLI workflows, it is good enough.

When This Setup Makes Sense

Do not use this everywhere. Use it where it actually gives you an advantage.

1. Privacy-Sensitive Environments

If code cannot leave your machine, this setup is useful.

Examples:

Internal tools
Proprietary scripts
Regulated environments

You avoid sending prompts and contexts to external services.

This is the strongest reason to use local models.
Especially in some companies like insurances or military, it makes absolutely sense.

2. Offline Workflows

If you work without a stable connection or you don't have a connection at all (like during a flight).

It is slower, but always available.

3. Learning and Understanding AI

This setup forces you to see how LLMs actually behave.

You learn:

Prompt sensitivity
Model limitations
Output variability

This is valuable if you want to go beyond "just using Copilot".

When It Does NOT Make Sense

Avoid this setup if you need:

High accuracy
Large context handling
Production-grade reliability

In those cases, cloud models are still the better option.

👀 GitHub Copilot quota visibility in VS Code

If you use GitHub Copilot and ever wondered:

what plan you’re on
whether you have limits
how much premium quota is left
when it resets

I built a small VS Code extension called Copilot Insights.

It shows Copilot plan and quota status directly inside VS Code.

No usage analytics. No productivity scoring. Just clarity.

👉 VS Code Marketplace:
https://marketplace.visualstudio.com/items?itemName=emanuelebartolesi.vscode-copilot-insights

GitHub Copilot Is Too Nice. Fix It With a Tone of Voice File.

Emanuele Bartolesi — Wed, 01 Apr 2026 12:21:58 +0000

Most GitHub Copilot setups are too polite to be useful.

By default, Copilot tries to agree, avoid criticism, and keep answers "safe".
That sounds good, but in practice it leads to weak suggestions, missed problems, and bad decisions slipping through.

If you want better output, you need to change its behavior.

The simplest way is a tone of voice file.

Create a voice-instructions.md in your repo and force Copilot to be critical:

---
applyTo: '**'
---

Give direct, critical feedback.
Identify mistakes, weak assumptions, unnecessary complexity, unclear naming, hidden risks, and poor trade-offs without softening the message.

Do not add generic praise or filler. Do not agree by default.

When something is wrong, say exactly what is wrong, why it is a problem, and what should be done instead.

Prioritize correctness, clarity, simplicity, maintainability, and practical delivery.

Challenge vague requirements and surface missing constraints, edge cases, and operational risks.

Be blunt but professional. Never be insulting. Always aim to be useful.

You get:

Clear problems called out
Weak assumptions challenged
Simpler and more maintainable alternatives

The result is better code and faster decisions.

There is a trade-off.

It feels harsher.
It is not ideal for beginners.
It removes the "friendly assistant" vibe.

But if you are building real systems, that is the wrong goal anyway.

If you want better output, demand better behavior.

👀 GitHub Copilot quota visibility in VS Code

If you use GitHub Copilot and ever wondered:

what plan you’re on
whether you have limits
how much premium quota is left
when it resets

I built a small VS Code extension called Copilot Insights.

It shows Copilot plan and quota status directly inside VS Code.

No usage analytics. No productivity scoring. Just clarity.

👉 VS Code Marketplace:
https://marketplace.visualstudio.com/items?itemName=emanuelebartolesi.vscode-copilot-insights

I Rebuilt My Site Twice. Here's What the Second Time Taught Me.

Davide Imola — Fri, 27 Mar 2026 09:26:35 +0000

I rebuilt my personal site. Then I rebuilt it again.

The first time I thought the problem was the old site. The second time I realized the problem was how I was working.

Two versions, same problem

The original site was built in Astro. I chose Astro because I wanted to experiment with something new. I'd been doing mostly backend and infrastructure work at the time, and my frontend skills were, let's say, still developing. The result was functional and completely forgettable: white text on a black background, no real personality, nothing that said anything about who I was or what I did.

So I decided to rebuild it using AI. I had access to Cursor through work, so I started there. The workflow was straightforward: describe what you want, get a plan, let it generate most of the site at once.

It was better. Some things were genuinely nice: red underlines styled like brushstrokes, a layout that felt more composed. But it was also a mess. Too many color variations that didn't quite agree with each other. And at some point, because I'd mentioned that I love Japanese culture and aesthetics, the AI decided the obvious move was to add kanji characters to the design.

I don't speak Japanese. I removed the kanji.

The core issue wasn't the kanji. That was just the most visible symptom. The real problem was that I'd handed over a vague brief ("I like Japanese aesthetics") and gotten back a literal interpretation, with all the inconsistencies that come from generating a whole site in one go. The design system wasn't solid because I'd never defined one. Everything was a bit improvised.

Still not working. But now I knew why.

Starting over with a different question

I could have kept patching the Cursor version. Instead I started from scratch. Partly out of frustration, mostly out of curiosity. I'd been reading and watching more about AI-assisted development, and I wanted to try a fundamentally different approach.

The question wasn't "can AI build my site?" I already knew it could. The question was: what happens if I stop treating AI as a site generator and start treating it as a collaborator?

I switched to Claude Code and gave myself one constraint before touching a single component: I would define the design system first.

Design system first, everything else second

This sounds obvious in retrospect. It wasn't obvious to me at the time.

I'm not a designer. I can look at something and know whether it works, but I struggle to build the underlying system that makes it consistent. What I needed wasn't something to generate components. I needed something that would push back when my decisions were incoherent.

So I started with tokens: background colors, text hierarchy, border values, a single accent color (Akane red, #C91F37). I set strict rules. The AI started flagging things I wouldn't have caught on my own: too many color variations, inconsistent visual language, patterns that looked fine in isolation but clashed in context.

"Too many colors. Pick a few that work together and stick to them."

That kind of feedback is what a designer gives you. I was getting it from an AI, but only because I'd asked the right questions and constrained the scope. Working on one isolated part of the project at a time, not the whole thing, made the feedback loops tight and the outcomes predictable.

The result was a design system I actually understood. Building the site on top of it was a completely different experience.

The voice input accident

Somewhere in the middle of the second rebuild, I started using voice input.

I didn't plan to. I'd seen someone mention it in a video, tried it out of curiosity, and kept using it because it worked better than I expected.

The difference isn't speed. Typing is faster for precise, short instructions. The difference is how you think. When you speak, you reason out loud. You self-correct in real time. You catch yourself saying "actually, no, wait, what I really mean is..." and that process of rephrasing turns out to be genuinely useful.

I started with the voice input built into Claude, then experimented with other tools. The prompts I produced with voice were longer, more specific, and more honest. I said things I wouldn't have bothered typing.

I'm not claiming it's some revolutionary technique. It's just a different input method that, for me, unlocked a different way of communicating with the AI. Your mileage may vary.

The result: a terminal that works

The site is live at davideimola.dev.

The thing I'm most happy with is the terminal aesthetic: commands as navigation, monospace headings, a design language that feels like it was made by a developer, not by someone using a portfolio template. That direction came from the AI noticing what I kept gravitating toward and suggesting something more committed.

It has character now. The old site didn't.

The tech stack is Next.js, Tailwind v4, TypeScript. Everything I'd have chosen anyway, but this time built on a design system that makes the codebase coherent instead of a collection of decisions made in different moods.

What's next

The rebuild was the experiment. What I took away from it was a method: a way of working with AI that I've since applied to other projects.

I extracted that method into something replicable. That's the next post.

How I replaced Sentry and the rest for Good: The $0 Telegram Alerting Hack

Bima — Thu, 19 Mar 2026 18:37:54 +0000

Most production applications need some form of real-time alerting.
When something goes wrong — a payment fails, an API crashes, or a user submits a contact form — someone needs to know immediately.

Large teams often use tools like Sentry, Datadog, or PagerDuty for this. These platforms are powerful, but they can also be expensive and complex to configure, especially for small projects or solo developers.

So instead of integrating a full observability stack, I built a lightweight alerting system using something I already use every day: Telegram.

In this guide, I’ll show you how to set up a free Telegram-based notification system that can alert you about:

server errors
new leads and contact form submissions
important business events like payments or signups

Why Telegram Works So Well for Alerting

Telegram is surprisingly perfect as a developer alerting channel:

It’s free
Push notifications are instant
Bots are easy to create
Messages support Markdown, HTML, emojis, and buttons
You can add your entire team to a group and everyone gets notified at once

Instead of building dashboards or constantly checking logs, your application can send messages directly to a Telegram group.

What You Need Before Starting

You only need four things:

A Telegram account
A Telegram bot
A Telegram group
Your bot token and chat ID

That’s it. No servers, no SDKs, no third-party monitoring service.

Step 1: Create a Telegram Bot

Open Telegram and search for @botfather.
Run the command:

/newbot

Follow the prompts and Telegram will give you a bot token.
This token is basically the password your application will use to send messages.

If you’ve never done this before, you can simply ask any AI assistant:

“How do I create a Telegram bot and get the bot token?”

Or follow this tutorial.

Step 2: Create a Group and Add the Bot

Create a Telegram group for alerts, then:

Add your bot to the group
Add your teammates
Make sure notifications are enabled for the group

This allows your app to send one message and notify everyone at once.

Step 3: Get the Telegram Chat ID (Important Step)

Telegram bots don’t send messages using usernames or group names. They use a chat ID.

To get it:

Send any message in the group
Open your browser and visit:

https://api.telegram.org/bot<YOUR_TOKEN>/getUpdates

You’ll see a JSON response. Look for:

"chat": {
  "id": -1001234567890,
  "title": "My Alerts Group"
}

Copy the id. That is your chat ID.

Step 4: Send Your First Message Using the Telegram Bot API

Telegram provides a simple HTTP endpoint called sendMessage.

POST https://api.telegram.org/bot<TOKEN>/sendMessage

Example payload:

{
  "chat_id": "-1001234567890",
  "text": "Hello from my web app"
}

You can test this using:

curl
Postman
or directly from your backend code

Once this works, your alerting system is already functional.

Additionally, you can read more about the telegram api here.

Making Alerts Readable (Markdown, Emojis, and Structure)

Raw text alerts quickly become hard to read. Instead, format them so they are easy to scan on mobile.

Example:

🚨 *Server Error*
Endpoint: /api/payments
Status: 500

Telegram supports:

Markdown
HTML formatting
emojis
inline buttons

This means you can send alerts that look structured and professional instead of messy log dumps.

Real-World Things You Can Alert On

Once you have this set up, you can send notifications for almost anything.

Backend alerts

Unhandled exceptions
Failed background jobs
Payment confirmations

Frontend alerts

Contact form submissions
New user registrations
Demo bookings

DevOps alerts

Deployment completed
Server restarted
Environment variables missing

This turns Telegram into a lightweight observability and business monitoring tool.

Sending Alerts from a Backend (Node.js Example)

Here’s a minimal reusable function:

import axios from "axios";

const token = process.env.TELEGRAM_BOT_TOKEN;
const chatId = process.env.TELEGRAM_CHAT_ID;

export async function sendTelegramAlert(message: string) {
  const url = `https://api.telegram.org/bot${token}/sendMessage`;

  await axios.post(url, {
    chat_id: chatId,
    text: message,
    parse_mode: "Markdown"
  });
}

Now you can call this anywhere in your application:

await sendTelegramAlert("🚨 Database connection failed");

Using Telegram Alerts in Frontend Applications

You can also trigger alerts from the frontend when API calls fail.

try {
  await api.createOrder(data);
} catch (err) {
  await sendTelegramAlert("⚠️ Order creation failed");
}

This is especially useful for catching silent failures during production that users might not report.

Example: Alerting on Contact Form Submissions

Instead of relying only on email, you can push new leads directly to Telegram:

📩 New Contact Form Submission
Name: John Doe
Email: john@example.com
Message: I’m interested in your services.

This ensures you never miss an important message because it landed in spam.

Limitations of This Approach

Telegram alerts are simple and effective, but they are not a full replacement for tools like Sentry or Datadog.

You won’t get:

dashboards
error grouping
performance tracing

However, for:

side projects
startups
internal tools

this approach provides a huge improvement over having no alerting at all.

Final Thoughts

You don’t always need a complex observability stack to stay informed about what’s happening in your application. With just a Telegram bot and a few lines of code, you can build a real-time alerting system that notifies you and your team instantly.

It’s free, quick to set up, and flexible enough to integrate with both frontend and backend workflows.

Sometimes, simple tools are all you need.

Why I Switched to pnpm and Never Looked Back 🚀

Domenico Tenace — Thu, 19 Mar 2026 09:03:03 +0000

Overview

Hey everyone 👋

For years, I used npm without questioning it. It's the default, it comes with Node.js, everyone uses it, why change? But after switching to pnpm a few months ago, I genuinely can't imagine going back.

This isn't about being trendy or jumping on the latest bandwagon. pnpm solves real problems I didn't even realize I had with npm. Let me explain why making the switch was one of the best development decisions I've made this year.

Let's start! 🤙

What's the Actual Difference? 🤔

Before we get into why pnpm is better, let's understand what makes it fundamentally different from npm.

npm's Approach: Flat and Duplicated

When you run npm install, npm creates a flat node_modules structure. This means all your dependencies and their dependencies end up in the same folder, flattened out. While this solved some earlier problems with nested dependencies, it created new ones:

Phantom Dependencies:
You can import packages that aren't listed in your package.json because they happen to be installed as someone else's dependency. This works until that dependency changes, and suddenly your code breaks.

Disk Space Waste:
If you have 10 projects on your machine and they all use Express, npm downloads and stores Express 10 times. Same for React, Lodash, or any other common package.

Slow Installations:
Every project needs its own copy of everything, which means longer install times and more network usage.

pnpm's Approach: Smart and Efficient

pnpm takes a completely different approach using something called a content-addressable storage system. Here's how it works:

Single Global Store:
pnpm keeps one copy of each package version in a global store (usually ~/.pnpm-store). When you install a package, pnpm creates hard links from this store to your project's node_modules.

Strict Dependency Tree:
Instead of flattening everything, pnpm maintains a proper nested structure using symlinks. You can only import packages that are explicitly listed in your package.json or their dependencies.

Shared Across Projects:
If 10 projects use Express version 4.18.0, pnpm stores it once and creates 10 hard links. No duplication, massive disk space savings.

This isn't just a minor optimization, it's a fundamentally better architecture.

Why pnpm Wins: The Real Benefits 🏆

Let me share the concrete improvements I've experienced since switching.

Speed That Actually Matters

pnpm is noticeably faster than npm. We're not talking marginal gains, we're talking "wait, it's already done?" levels of speed.

Cold Installs:
When installing a package for the first time, pnpm downloads it once to the global store. Every subsequent project that uses it just creates a hard link, which is nearly instantaneous.

Warm Installs:
If you've already got the packages in your global store (which you probably do if you work on multiple projects), installations are blazingly fast. What took npm 2-3 minutes might take pnpm 10-20 seconds.

In Practice:
Running pnpm install on a fresh clone of a project feels almost magical. The speed difference is real and noticeable every single day.

Disk Space Savings Are Huge

This one surprised me the most. After switching my entire workspace to pnpm, I freed up over 15GB of disk space. That's not a typo, 15 gigabytes.

Here's why: with npm, if you have 20 projects and 15 of them use React, you have 15 copies of React sitting on your disk. With pnpm, you have one copy with 15 hard links pointing to it.

For common dependencies like:

React and React DOM
Lodash
TypeScript
ESLint and Prettier
Testing libraries

The savings add up fast. And this isn't just about disk space, it's about principle. Why should my machine store the same exact files hundreds of times?

Strict Dependencies Prevent Bugs

This is the feature I didn't know I needed until I had it.

With npm, you can accidentally import packages that aren't in your package.json because they're installed as transitive dependencies. This creates hidden coupling that breaks when those dependencies update.

pnpm's strict mode prevents this entirely. If it's not in your package.json, you can't import it. Period.

Real Example:
I had a project using a utility function from Lodash, but Lodash wasn't in my package.json. It worked because another package happened to depend on Lodash. When that package updated and removed Lodash, my build broke.

With pnpm, this would have failed immediately, forcing me to add Lodash explicitly. The error is caught early instead of in production.

Monorepo Support Is First-Class

If you work with monorepos (and increasingly, who doesn't?), pnpm's workspace support is excellent.

Built-in Workspaces:
Define your workspace structure in pnpm-workspace.yaml, and pnpm handles linking between packages automatically.

Efficient Sharing:
Shared dependencies across workspace packages are stored once and linked everywhere they're needed.

Better Than Alternatives:
I've used npm workspaces and Yarn workspaces. pnpm's implementation feels cleaner and more efficient in practice.

The Lock File Is Better

pnpm's pnpm-lock.yaml is more deterministic than npm's package-lock.json. It stores more information about dependency relationships and produces more consistent results across different environments.

I've had fewer "works on my machine" issues since switching to pnpm. The lock file format just seems more robust.

The Migration: Easier Than You Think 🔄

I was worried about migrating, but it turned out to be trivial.

How to Switch

For an existing project:

# Install pnpm globally
npm install -g pnpm

# Navigate to your project
cd my-project

# Import your package-lock.json
pnpm import

# Install dependencies
pnpm install

That's it. pnpm even converts your package-lock.json to pnpm-lock.yaml automatically.

Commands Are Nearly Identical

If you know npm, you already know pnpm:

# npm commands
npm install package-name
npm uninstall package-name
npm run build
npm test

# pnpm equivalents
pnpm add package-name
pnpm remove package-name
pnpm run build
pnpm test

The only real difference is add instead of install and remove instead of uninstall. Everything else is identical.

Create Aliases If Needed

If you want even less friction:

alias npm=pnpm

Though honestly, once you start using pnpm, you'll appreciate the distinct commands.

The Gotchas (Yes, There Are Some) 😬

Let's be honest, pnpm isn't perfect. Here are the issues I've encountered:

Some Packages Don't Play Nice

Occasionally, you'll find a package that assumes npm's flat structure and breaks with pnpm's strict linking. This is rare, but it happens.

The Fix:
pnpm has a .pnpmfile.cjs where you can configure workarounds. Or you can use the shamefully-hoist flag to flatten dependencies like npm does (though this defeats some of pnpm's benefits).

In practice, I've only hit this issue twice in several months, and both times the package maintainers fixed it quickly.

Smaller Community

While pnpm's adoption is growing rapidly (Vue, Vite, Astro, and other major projects use it), it's still smaller than npm's massive ecosystem.

This means:

Fewer Stack Overflow answers
Less extensive documentation for edge cases
Occasional confusion when following tutorials that assume npm

That said, the community is active and helpful, and most npm knowledge transfers directly.

Initial Learning Curve

Understanding hard links, symlinks, and the global store takes a minute. The first time you look at node_modules in a pnpm project, it looks weird.

But once you understand the model, it makes perfect sense and you appreciate the elegance.

When npm Still Makes Sense 🎯

To be fair, there are scenarios where sticking with npm is reasonable:

You're Brand New to JavaScript:
If you're just learning, start with npm. It's the default, and you'll find more beginner-friendly resources. Switch to pnpm once you're comfortable.

Company Policy:
Some organizations have standardized on npm, and switching requires buy-in. Don't fight that battle unless the benefits are worth it for your specific situation.

Compatibility Concerns:
If you're working on legacy projects with lots of old dependencies that have quirks, npm's more permissive structure might save headaches.

You Don't Care About Disk Space or Speed:
If you have unlimited disk space and don't mind waiting for installations, npm works fine. Some people genuinely don't care about these optimizations.

But for most modern development, pnpm is simply better.

Real-World Impact 💪

Let me share some concrete numbers from my own experience:

Before pnpm (npm):

npm install on a typical Next.js project: ~90 seconds
Disk space for 20 active projects: ~42GB in node_modules
Frequent phantom dependency issues
Occasional lock file conflicts between team members

After pnpm:

pnpm install on the same projects: ~15-20 seconds
Disk space for the same 20 projects: ~27GB total
Zero phantom dependency issues
More consistent installations across the team

The time savings alone add up. If you run install 20 times a day (between switching branches, pulling updates, etc.), pnpm saves you about 20-25 minutes daily. That's over 2 hours per week.

The Broader Ecosystem Is Adopting It 🌍

pnpm isn't just a niche tool anymore. Major projects have switched:

Projects Using pnpm:

Vue 3 and the entire Vue ecosystem
Vite (one of the fastest build tools)
Astro (my personal site's framework)

When tools and frameworks this significant adopt pnpm, it's a strong signal that it's production-ready and worth considering.

My Recommendation 💡

If you're still using npm and any of these apply to you:

You work on multiple projects
You care about build speed
Disk space is a concern
You work with monorepos
You want stricter dependency management

Switch to pnpm. The migration takes 5 minutes, and the benefits are immediate and ongoing.

Will you encounter the occasional quirk? Probably. Is it worth it? Absolutely.

The JavaScript ecosystem moves fast, and package managers are evolving. npm was great for its time, but pnpm represents a better approach to dependency management. It's faster, more efficient, and more correct.

Conclusion 🚀

Here's my challenge: pick one project and try pnpm for a week. Just one week.

npm install -g pnpm
cd your-project
pnpm import
pnpm install

Use it like you'd use npm. Notice the speed. Check your disk space savings. Experience the strict dependency resolution.

After a week, if you genuinely prefer npm, switch back. But I'd bet that like me, you won't want to.

Sometimes the best tools are the ones that just work better in ways you didn't realize you needed. For me, pnpm is one of those tools.

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 🥹

Git Mirroring During Migrations: `--all` vs `--mirror`

Emanuele Bartolesi — Mon, 16 Mar 2026 07:00:00 +0000

During a Git migration, the new platform is rarely switched on overnight.

In many real scenarios, two systems must coexist for a while. For example:

repositories move from GitLab to GitHub
CI pipelines still run in GitLab
developers start working in GitHub

In this transition phase, the repositories must stay synchronized between both platforms.

One common solution is repository mirroring, where changes from one repository are pushed to another remote so both systems stay aligned.

Two approaches are often used for this:

git push gitlab --force --all
git push gitlab --force --tags

git push gitlab --force --mirror

At first glance, these commands may look equivalent. They are not.

The Common Approach: Pushing Branches and Tags

A common way to keep two repositories in sync is pushing all branches and tags to the second remote.

git push gitlab --force --all
git push gitlab --force --tags

These two commands are often used together during migrations.

`git push --all`

git push gitlab --force --all

This command pushes all local branches to the remote.

Important details:

It pushes every branch under refs/heads/*
It does not push tags
It does not push other reference types

So after this command runs, the remote repository will contain the same branches as the local repository.

`git push --tags`

git push gitlab --force --tags

This command pushes all tags under refs/tags/*.

Tags are often used for:

releases
versioning
deployment markers

Since --all does not include tags, they must be pushed separately.

What This Approach Synchronizes

Using these two commands ensures that:

all branches are synchronized
all tags are synchronized

For many teams, this is already enough to keep two repositories aligned during a migration.

However, this approach does not synchronize the entire repository state. Some Git references are still missing.

This is where --mirror behaves differently.

The Full Mirror Option

Git also provides a command designed specifically for repository mirroring:

git push gitlab --force --mirror

This command behaves differently from pushing branches and tags separately.

Instead of pushing selected references, --mirror pushes every reference under refs/* from the local repository to the remote.

This includes:

branches (refs/heads/*)
tags (refs/tags/*)
remote-tracking branches
notes
any other custom references

Another important behavior is that --mirror synchronizes deletions.

If a reference exists on the remote but no longer exists locally, --mirror will remove it from the remote as well. The goal is to make the remote repository an exact replica of the source repository.

In other words:

--all + --tags copies branches and tags
--mirror copies the entire reference namespace

This makes --mirror the closest thing to a true Git repository mirror.

Quick Recommendation

Both approaches can work during a migration, but they serve slightly different goals.

Use `--all` + `--tags` when

git push gitlab --force --all
git push gitlab --force --tags

This approach is usually enough if you only need to synchronize:

branches
tags

It is also safer in environments where the target repository may contain additional references created by tooling, CI systems, or platform features.

Since it does not delete references on the remote, it reduces the risk of accidentally removing something important.

Use `--mirror` when

git push gitlab --force --mirror

This option is appropriate when you want the destination repository to be a complete mirror of the source.

Typical cases include:

temporary mirrors during platform migrations
backup repositories
strict synchronization between two Git servers

However, --mirror is more aggressive. It will overwrite and delete references on the remote to match the source exactly.

👀 GitHub Copilot quota visibility in VS Code

If you use GitHub Copilot and ever wondered:

what plan you’re on
whether you have limits
how much premium quota is left
when it resets

I built a small VS Code extension called Copilot Insights.

It shows Copilot plan and quota status directly inside VS Code.

No usage analytics. No productivity scoring. Just clarity.

👉 VS Code Marketplace:
https://marketplace.visualstudio.com/items?itemName=emanuelebartolesi.vscode-copilot-insights

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

Ryan Carniato — Fri, 13 Mar 2026 15:39:54 +0000

Developers have never been shy about disliking certain React APIs. They feel awkward, restrictive, or just plain counterintuitive. But the reality is that the two most complained‑about design choices in React weren’t arbitrary at all — they were early signs of deeper constraints that every UI model eventually runs into.

As many of you know, I’ve been working on Solid 2.0 for the last couple of years. It’s been a journey. I’d already been using Signals for over a decade, and I thought I understood the entire design space. But the deeper I went, the more I found myself in unexpected territory.

And somewhere along the way, I realized something uncomfortable. React was right about those design decisions that people absolutely cannot stand. Not React’s model — I’m not here to defend that. But React did correctly identify two invariants that the rest of the ecosystem, including Solid 1.x, glossed over.

I'm talking about deferred state commits:

const [state, setState] = useState(1);

// later
setState(2);
state === 1; //not committed yet

And dependency arrays on Effects:

useEffect(() => console.log(state), [state]);

These are the two things Signals were supposed to “fix.” And in a sense, they did. But not in the way people think. Today, we’re going to look at why that isn’t the full story.

Living in an Async World

Everything we do on the web is built on asynchronicity. The entire platform is defined by a client and server separated by a network boundary. Streaming, data fetching, distributed updates, transactional mutations, optimistic UI — all of it branches from that simple truth.

Async pushes us out of our imperative comfort zone. Imperative code is about writes: “set this, then read it back.” Async is about reads: “is this value available, stale, or still in flight?” It’s the question every UI must answer before it renders anything: can I show this, or will I expose something inconsistent?

To most frameworks, async looks like ephemeral state flitting in and out of a synchronous declarative world. It feels unpredictable because we only see the moments where async intersects with our computation. But async isn’t chaos — it’s just time. And if we want to reason about it, we need the language to represent it directly.

It starts with how we represent state. If a value isn’t available yet, there is no placeholder it can safely substitute. Returning null, undefined, or a wrapper breaks determinism. Continuing anyway produces a result that never corresponds to any actual moment in time. The only way to keep consistent is to stop.

It also takes respecting the declarative model. What makes reactive systems (including React) compelling is their ability to represent UI as state at a given moment in time. All architectural clarity and execution guarantees stem from this. Determinism is the goal: the same inputs produce the same outputs, timing doesn’t alter the shape, and the UI is always consistent.

When async leaks into user space — through conditional branches or alternate value shapes — we force the user to manually manage consistency, and the declarative model collapses.

// Derived computation forced to branch on async state
const firstInitial = user.loading ? "" : user.name[0];

UI affordances for async—loading indicators, skeletons, fallbacks—are not the problem. Those are presentation concerns. The problem is when async becomes part of the value flowing through the state graph. It forces every consumer to branch. UI can show whatever it wants, but the graph must only ever see real values.

1. Async Must Be Isolated from Commits

Unlike other reactive systems, React’s tight coupling of state and rendering forced it to confront this problem early. When every state change triggers a re-render, you can’t hide inconsistencies behind synchronous derivation. Signals avoid this because everything is always up to date by the time you read it—no re-renders, no orchestration, no wasted work.

But those characteristics only hide a fundamental truth. You cannot let async work interleave with synchronous commits. If a computation is still waiting on async, any writes it performs are speculative. You can’t show the user UI based on state you don’t have yet, because if they interact with it they expect to be interacting with what they see—not some intermediate state the framework is holding.

Consider:

let count = 0;
let doubleCount = count * 2;
function increment() {
  count++;
  console.log(`${count} * 2 = ${doubleCount}`);
}

<button onClick={increment}>{count} * 2 = {doubleCount}</div>

I've used this example many times in the past but it captures the nature of the problem. See:

Ryan Carniato for Playful Programming

Jul 12 '22

The Cost of Consistency in UI Frameworks

#react #vue #svelte #solidjs

369

Comments 41

7 min read

In plain JavaScript, count and doubleCount drift apart. Signals fix this by updating doubleCount on read. But that still leaves the question. When does this update reach the DOM? If you flush immediately (like Solid 1.x), consecutive updates can be expensive. If you don't you don't that acknowledges that some amount of scheduling is inherent to the system.

React was the only system that didn’t update count immediately, and people hated it. But the motivation was sound. React wanted event handlers to see consistent state, and it had no way to update derived values until the component re-ran.

Now imagine the handler is:

function onClick(event) {
  setBooks([]);
  // derived value
  if (booksLength) {
    books[booksLength - 1]
  }
}

If books updates but booksLength doesn’t, you’re reading out of bounds.

Signals keep state and derived state perfectly in sync, and that gives developers a strong sense of safety. You write the code once and it just works. But that confidence becomes a liability the moment a derived value turns async as there is no guarantee that it will keep in sync.

Return to count and doubleCount, but make doubleCount async. If you want the UI to stay consistent — to keep showing 1 * 2 = 2 until the async doubleCount resolves — then you must delay updating count as well. Otherwise you end up in a strange situation. The UI is still showing 1 * 2 = 2, but the console is already logging 2 * 2 = 2 because the underlying data has moved on to count = 2.

Once you see that mismatch — the UI waiting for consistency while the data has already advanced — the conclusion becomes unavoidable. The synchronous world made you feel safe because everything updated together, but that safety was an illusion built on the assumption that all derived values were immediately available. The moment one of them becomes async, that assumption collapses. If you want the UI to remain consistent, you have to delay the commit. And once you delay the commit in the UI, you have to delay it in the data as well, or the two drift apart in ways that violate the very guarantees you relied on. Async doesn’t just add latency; it forces a different execution model.

2. Dependencies of Effects must be known at Computation Time

React’s re‑render model forced it to confront another truth long before anyone else. Derivations and side effects obey different rules.

When components re-run on every change, recalculating everything every time would be wasteful. So when Hooks were introduced, dependency arrays came with them — a crude but effective form of memoization.

Compared to Signals, where dependencies are discovered dynamically and only the necessary computations re-run, this looks limited. But it had an important consequence. React knew all the dependencies of the tree before running any rendering or side effects.

That detail becomes vital the moment async enters the picture. If rendering can be interrupted at any time — paused, replayed, or aborted — then no side effects can have run yet. A side effect that fires before all dependencies are known risks running with partial or speculative state. React’s architecture exposed this immediately. Rendering was not guaranteed to complete, so effects could not be tied to rendering.

Signals, with their surgical precision, avoided this problem for years. Change propagation is synchronous and isolated, so derivations and side effects appear to run in a single, predictable flow. But that predictability evaporates the moment async enters the graph.

Because if async is only discovered during side effects, it’s already too late. And if async is interruptible — say by throwing a promise and re-executing on resolution — execution becomes completely unpredictable.

Consider:

const a = asyncSignal(fetchA());
const b = asyncSignal(fetchB());
const c = asyncSignal(fetchC());

effect(() => {
  console.log(a());
  console.log(b());
  console.log(c());
});

What does the effect log? How many times does it run? In a purely synchronous world, these questions barely matter — derivations are stable, and effects run once per commit. But with async, they become unanswerable. Each async source may resolve at a different time. Each resolution may re-trigger the effect. And if any of them suspends or retries, the entire execution order becomes nondeterministic.

And that’s just the initial load. If these async sources can update independently over time, the unpredictability compounds. You can’t reason about side effects if you can’t reason about when the effect runs or what values it sees.

The solution is simple and unavoidable. Effects must only run after all async sources they depend on have settled. And to do that, you must know all dependencies before executing any effect. You must seperate collecting the dependencies from executing the effect.

const a = asyncSignal(fetchA());
const b = asyncSignal(fetchB());
const c = asyncSignal(fetchC());

effect(
  () => [a(), b(), c()] // capture deps
  ([a, b, c]) => { // do side effects
    console.log(a);
    console.log(b);
    console.log(c);
  }
);

What This Means for Signal‑Based Solutions

At this point the architecture forces a choice. Either confront async head‑on or continue pretending synchronous guarantees hold in an async world. Async is real. It will appear somewhere in the graph. And once it does, the guarantees you relied on in the synchronous case no longer hold unless the system acknowledges it.

Can a Compiler Solve This?

No. A compiler can’t fix a semantic problem by rearranging syntax. Early commits aren’t a mechanical limitation — they’re a correctness limitation. The moment async enters the graph, the system must know when a value is real and when it is speculative. No amount of static analysis can change that.

Could a compiler extract dependencies from a single effect function? In a shallow sense, yes — React’s compiler does exactly that. But compiler‑based extraction only sees what’s in scope. It can’t see the whole graph. If your sources are functions that call signals rather than signals themselves, the compiler has no way to know whether those functions are pure or whether they hide side effects.

This is exactly why Svelte 5 moved to Runes (Signals). Compiler‑time dependency capture hit a hard limit. It couldn’t track sources that weren’t syntactically visible.

let count = 0;

function getDoubleCount() {
  return count * 2;
}

// never updates because count is not
// visible in this scope
$: doubled = getDoubleCount();

Once you hit these edges, you have to ask whether the added complexity, hidden rules, and incomplete coverage are worth it. Compiler inference can paper over the problem, but it can’t solve it. Async is a runtime phenomenon. The guarantees must be enforced at runtime.

Does This Mean We’re Doomed to Mimic React?

Not at all. This isn’t copying React. It’s acknowledging the same fundamental truth React ran into first. Async forces commit isolation. Async forces effect splitting. Vue has had this split in its watchers(effects) for years. These aren’t React‑isms. They’re invariants of any system that wants to preserve consistency in the presence of async.

Adopting these invariants doesn’t erase the advantages of Signals. Updates remain surgically fine-grained. Components never re-render. Dependencies are deeply discoverable and dynamic.

Only effects require separation. Pure computations do not. This marries the expressive power of Signals with the correctness discipline of functional programming. It acknowledges reality instead of fighting it. And it gives async the same determinism and clarity that Signals already give to synchronous computation.

Conclusion

Solid has always pushed the boundaries of frontend architecture, not by chasing novelty but by uncovering the underlying rules that make UI predictable, consistent, and fast. React encountered these rules first because its architecture forced it to. It didn’t choose these constraints — it ran into them. Calling them “design decisions” almost overstates the agency involved. They were discoveries.

Choosing to embrace those same invariants from a position of strength is something entirely different. We aren’t adopting these constraints because we’re boxed in — we’re adopting them because they are true. Async forces commit isolation. Async forces effect splitting. Async forces a consistent snapshot. These aren’t React‑isms; they’re the physics of UI.

Embracing this isn’t mimicry. It’s maturity. It’s choosing the inevitable path with eyes open, and building a system that treats async not as an edge case but as a first‑class part of the architecture. It’s the next step in making Solid not just fast, but fundamentally right.

Clarity doesn’t simplify the world, but it does make the direction unmistakable.

Rebuilding domenicotenace.dev: How Pure Astro and CSS Reminded Me That Simple Is Better 🌟

Domenico Tenace — Thu, 12 Mar 2026 16:52:57 +0000

Overview

Hey everyone 👋

I recently did something that felt almost rebellious in today's web development landscape: I completely refactored my personal website using only Astro and vanilla CSS. No React, no Vue, no Tailwind, no animation libraries, no component frameworks. Just HTML, CSS, and a bit of JavaScript where absolutely necessary.

And you know what? It was the most refreshing development experience I've had in years.

Let's start! 🤙

The Decision: Back to Basics ✨

The turning point came when I was helping a friend debug their website. They'd built it with pure HTML and CSS, no build step, no dependencies. When they made a change, they just refreshed the browser. No waiting for compilation, no hot module replacement issues, no dependency conflicts.

It was fast. Not just the website itself, but the entire development experience.

That's when I decided: my personal website doesn't need all this complexity. It's time to simplify.

Why Astro? 🚀

I chose Astro for one simple reason: it lets you write components and modern syntax while outputting pure static HTML. No JavaScript runtime, no virtual DOM, no hydration overhead. Just good old HTML, CSS, and minimal JS where needed.

Astro's philosophy aligned perfectly with what I wanted:

Zero JavaScript by default: Pages are pure HTML unless you explicitly opt-in
Component-based: I can still organize my code cleanly without shipping React
Fast builds: Seriously fast, we're talking seconds
No lock-in: If I want to switch frameworks later, I can easily migrate

The best part? Astro doesn't force you into any particular way of doing things. Want to use vanilla CSS? Great. Want to sprinkle in some JavaScript? Cool. Want to stay 100% static? Perfect.

The Refactoring Process 🔧

The migration was surprisingly straightforward. Here's what I did:

Step 1: Stripped Everything Down

First, I removed all the dependencies. Every single one. The package.json went from 40+ dependencies to just Astro itself. It felt liberating, like decluttering a messy room.

Step 2: Rebuilt the Structure

I created a simple Astro project structure:

src/
├── components/
│   ├── Header.astro
│   ├── Footer.astro
│   └── ProjectCard.astro
├── layouts/
│   └── BaseLayout.astro
└── pages/
    ├── index.astro
    ├── blog/
    └── projects/

Clean, minimal, easy to understand.

Step 3: Pure CSS, No Frameworks

This is where it got interesting. Instead of reaching for Tailwind, I wrote vanilla CSS. And honestly? It was fun.

I created a simple global.css file for handle all CSS.

No build tools, no purging, no configuration. Just CSS that works.

Step 4: Animations in Pure CSS

Here's where I had the most fun. Instead of importing animation libraries, I wrote CSS animations from scratch:

@keyframes fadeIn {
  from { opacity: 0; }
  to { opacity: 1;  }
}

.fade-in {
  animation: fadeIn 0.6s ease-out forwards;
}

Simple, performant, and I have complete control over every detail.

Step 5: JavaScript Only Where Needed

I added minimal JavaScript for interactive features:

Theme toggle (dark/light mode)
Mobile menu toggle
Smooth scroll behavior

Total JavaScript: less than 100 lines. No frameworks, no bundlers, just plain vanilla JS.

What I Rediscovered 💡

This process taught me (or reminded me) of several important lessons:

CSS Is Actually Powerful

Modern CSS is incredibly powerful. Grid, flexbox, custom properties, container queries, scroll-driven animations, we have everything we need to build beautiful, responsive websites without frameworks.

I'd forgotten that. Years of using Bulma, Tailwind, ecc made me think I needed utility classes for everything, but honestly? Writing semantic CSS felt more natural and resulted in cleaner markup.

Less Is Genuinely More

The final bundle size? Tiny. We're talking kilobytes, not megabytes. The Lighthouse score? 100 across the board. The build time? Under 3 seconds.

None of this would be possible with my previous stack. All that complexity was weighing the site down, literally and metaphorically.

Development Can Be Simple

There's something deeply satisfying about opening a file, changing some CSS, refreshing the browser, and seeing the change instantly. No build process, no hot module replacement quirks, no "hmm, why isn't this updating?"

The tight feedback loop made development enjoyable again.

You Don't Need a Framework for Everything

This is the big one. I'd internalized the idea that "professional" websites require modern frameworks. But that's not true. Frameworks solve specific problems, and if you don't have those problems, you don't need the framework.

My personal website doesn't need client-side routing, state management, or component reactivity. It's content, presented nicely. HTML and CSS do that perfectly well on their own.

The Results 📊

Let me share some concrete improvements:

Performance:

Initial load time: 0.3s (down from 1.8s)
Total bundle size: 45KB (down from 380KB)
Lighthouse score: 100 across all metrics
Time to Interactive: instant

Developer Experience:

Build time: 2.4s (down from 28s)
Hot reload: instant
Dependency updates: basically none
Mental overhead: significantly reduced

Maintenance:

Breaking changes: none (it's just HTML/CSS)
Security vulnerabilities: none (no dependencies to patch)
Complexity: minimal

What About the Trade-offs? 🤔

Let's be honest, there are some trade-offs:

No Component Reactivity:
Astro components are static by default. If I need interactivity, I have to add it manually. But for a content site, this is rarely an issue.

Less Tooling:
No automatic CSS optimization, no tree-shaking, no hot module replacement for styles. But honestly? I don't miss it. The simplicity makes up for the lack of bells and whistles.

Manual Responsive Design:
Without Tailwind's responsive utilities, I write media queries by hand. It takes slightly longer, but the CSS is more maintainable and semantic.

More CSS to Write:
No utility classes means writing more CSS. But the total amount of CSS is actually less than my Tailwind config generated, and it's more readable.

These trade-offs are worth it for me. Your mileage may vary.

Who Should Consider This Approach? 🎯

Pure Astro and CSS isn't for everyone, but it's perfect if:

You're building content sites:
Blogs, portfolios, documentation, marketing pages, anything that's primarily content benefits from this approach.

You value simplicity:
If you're tired of complex build processes and dependency management, going minimal is refreshing.

You want to learn the fundamentals:
Writing vanilla CSS makes you a better developer. You understand what your tools are doing under the hood.

Performance matters:
If you need the absolute fastest site possible, less code wins every time.

You don't need heavy interactivity:
If your site is mostly static content with occasional interactive elements, you don't need a full framework.

When You Still Need Frameworks 🔄

To be clear, I'm not saying frameworks are bad. They're excellent tools for the right jobs:

Complex web apps:
If you're building a dashboard, SaaS platform, or interactive application, React/Vue/etc. make total sense.

Teams with existing expertise:
If your team knows React and you're building something quickly, use React. Don't reinvent the wheel.

Lots of client-side state:
When you need to manage complex client-side state, frameworks provide the structure to do it well.

Rapid prototyping:
Component libraries and frameworks can speed up initial development significantly.

The key is choosing the right tool for the job, not defaulting to the most popular stack.

The Bigger Picture 🌍

This refactoring taught me something important about modern web development: we've collectively become a bit obsessed with complexity.

We reach for frameworks by default, even when they're overkill. We add dependencies without thinking. We over-engineer simple problems because that's what "professional" developers do.

But sometimes, the best solution is the simplest one.

HTML and CSS have been around for decades because they're good. They're stable, they're fast, they're simple. Modern CSS is powerful enough to build beautiful interfaces without frameworks.

Astro lets us use modern development practices (components, TypeScript, etc.) while outputting pure, simple code. It's the best of both worlds.

My Challenge to You 💪

If you're reading this and thinking "hmm, maybe I've over-engineered my site too," I challenge you:

Try building something with pure HTML and CSS. No frameworks, no libraries, just the fundamentals. See how it feels.

You might be surprised at how freeing it is.

And if you need a static site generator, give Astro a shot. It's genuinely excellent at letting you write simple code that performs beautifully.

Conclusion 🌟

Rebuilding domenicotenace.dev with pure Astro and CSS reminded me why I fell in love with web development in the first place: the joy of creating something that works, that's fast, that's simple.

We don't always need the latest framework or the trendiest library. Sometimes, the best code is the code we don't write.

If you take one thing from this article, let it be this: question your stack. Ask yourself if you really need all those dependencies. Challenge the assumption that complexity equals professionalism.

Often, the simplest solution is the best one.

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 🥹

Why JavaScript Engineers are Secretly C# Masters

Hayk Sargsyan — Mon, 09 Mar 2026 16:45:25 +0000

Photo by Denis N. on Unsplash

For a professional JavaScript developer, moving to TypeScript often feels like "cleaning up the room." But for those who look closer, TypeScript isn't just JavaScript with types; it is the spiritual successor to C# for the web. Understanding this connection is the shortcut to mastering backend architecture and high-scale systems.

The Hejlsberg Lineage

The most critical secret is that both languages share a father: Anders Hejlsberg.

Hejlsberg led the design of C# at Microsoft before creating TypeScript in 2012.
Because of this, the "feel" of the languages, how they handle generics, interfaces, and asynchronous patterns - is nearly identical.
Learning TypeScript is, in many ways, an onboarding process for modern C# and .NET.

Write Once, Understand Both

If you can read complex TypeScript, you can already read 80% of modern C#.

Async/Await: Both languages use the exact same keywords and mental model for non-blocking I/O.
Access Modifiers: Keywords like public, private, and protected function similarly in both environments to enforce encapsulation.
Arrow Functions vs. Lambdas: What you call an "arrow function" in JS, a C# dev calls a "lambda expression" using the same => token.
Generics: The syntax for reusable components - List in C# and Array in TS - is virtually interchangeable.

Photo by MJH SHIKDER on Unsplash

The "Erasure" vs. "Reified" Distinction

The realization for engineers is understanding where they diverge: The Runtime.

TypeScript uses Type Erasure. Types exist only at compile-time to help the developer, once it hits the browser/server, it’s just "naked" JavaScript.
C# uses Reified Types. Type metadata stays with the code at runtime, allowing for powerful features like Reflection (inspecting code at runtime) that TypeScript cannot do natively.

The Full-Stack Bridge

Engineers use this connection to bridge the gap between frontend and backend.

Frameworks like Nest.js (Node.js) are explicitly modeled after ASP.NET Core (C#). If you understand one’s Dependency Injection or Controller pattern, you understand the other.
The languages are actively borrowing from each other. C# recently added Pattern Matching, while JavaScript/TypeScript adopted Decorators, a staple of C# attributes for years.

The "lift" from TypeScript to C# is often smaller and more productive than moving to Go or Rust because the mental model remains consistent.

The "Awaitable" Pattern

Both languages implement asynchronous programming using a virtually identical mental and syntactic model:

A JavaScript Promise and a C# Task are ideologically equivalent, representing an ongoing operation that will complete in the future.
Both use the async and await keywords to flatten asynchronous callbacks into a synchronous-looking flow.

Photo by Michal Pokorný on Unsplash

Conclusion

The symmetry between C# and TypeScript represents a calculated evolution of industrial-scale engineering. By sharing a primary architect, both languages have aligned on a specific "developer ergonomics" that prioritizes predictability, maintainability, and architectural discipline.