DEV Community: 𝗝𝗼𝗵𝗻

Stop Over-Optimizing Performance: The Modern Full-Stack Toolkit in 2026

𝗝𝗼𝗵𝗻 — Wed, 01 Jul 2026 12:35:00 +0000

Let’s face it: if your current frontend optimization strategy still involves manually auditing codebases for missing useMemo hooks, micro-managing dependency arrays, or aggressively fighting layout shifts with complex client-side state management, you are wasting your engineering leverage.

As we cross the midpoint of 2026, web framework architecture has quietly undergone a massive shift. We have firmly moved out of the era of manual performance tweaking and entered the era of automated, compile-time optimization.

The goal of modern development is no longer just shipping fewer kilobytes to human users—it's also about optimizing data chunk delivery for AI web crawlers that evaluate your site in real-time.

Here is how the modern full-stack ecosystem redefined performance this year, and what you should focus on instead.

1. The Death of Manual Memoization (Thanks, React Compiler)

For years, React developers bore the cognitive load of rendering performance. One misplaced reference and your entire component tree re-rendered down to the root.

With the absolute maturity and default adoption of the React Compiler across production frameworks, that paradigm is officially legacy code. The compiler handles component memoization automatically at the build step by analyzing javascript structures directly.

// ❌ THE OLD WAY (Pre-2026 Manual Overhead)
const ExpensiveComponent = memo(({ data }) => {
  const processedData = useMemo(() => computeHeavyMetrics(data), [data]);
  const handleAction = useCallback(() => { ... }, []);
  return <DataGrid items="{processedData}" onAction="{handleAction}"/>;
});

//   THE MODERN WAY (Zero Performance Boilerplate)
export function ModernComponent({ data }) {
  const processedData = computeHeavyMetrics(data);
  const handleAction = () => { ... };
  return <DataGrid items="{processedData}" onAction="{handleAction}"/>;
}

Because the compiler injects optimization markers directly into the output code, human engineers can stop arguing about code architecture aesthetics and write clean, plain, idiomatically correct JavaScript.

2. Streaming SSR is the New Baseline for AEO

Server-Side Rendering (SSR) used to be an all-or-nothing game. The server fetched all data, rendered the full HTML string, sent it to the browser, and then hydrated the entire view.

Today, production setups rely heavily on Streaming SSR mixed with hybrid data fetching architectures (like Next.js Server Components and SvelteKit Runes). Instead of blocking the page load for slow API responses, pages are delivered in independent streaming chunks.

This has become vital not just for your Core Web Vitals, but for AEO (Answer Engine Optimization).

🔍 Why this matters right now: Modern search indexes and AI aggregators scrape live data using real-time LLM agents. If your main page content is trapped behind a client-side loading spinner, an AI crawler won't wait for the hydration cycle. It reads the initial streamed server chunk and leaves. High performance means instant discoverability.

3. Radical Architectural Minimalism

Look at the trending boilerplate setups making waves in production this season. The visual noise is disappearing, and that translates directly to better performance strategy:

Fewer DOM Nodes: Complex layout hacks are being replaced by native CSS features (like Container Queries and dynamic anchor positioning), cutting out deep wrappers that bloat the virtual DOM.
Build-Time Shift: Frameworks like SvelteKit and Astro have proved that running heavy logic during compilation rather than execution yields smaller bundle sizes, ensuring great UX even on low-powered mobile devices.
Serverless Edge Runtimes: Computing is moving away from centralized data centers closer to the end user via Edge functions, keeping time-to-first-byte (TTFB) low globally.

4. Where You Should Actually Spend Your Time

If the toolchains and compilers handle runtime rendering optimizations, where do you look for engineering impact?

Strict Type Contracts: Spend time establishing rock-solid TypeScript definitions between your client and backend APIs. Predictable data types prevent downstream hydration mismatches.
Robust Test Coverage: Write end-to-end tests that validate data persistence and edge-case rendering boundaries. If the compiler optimizes your code, your tests must ensure the business logic remains intact.
Data Hydration Architecture: Focus on optimizing when and where data is fetched. Organize your databases, design efficient indexes, and ensure your APIs return predictable payloads.

Let's connect and discuss!

What performance optimizations have you safely delegated to your compiler this year? Are you embracing the shift to server-driven architecture or keeping your logic client-side? Let me know in the comments!

Connect with Me

If you found this guide helpful, let's connect and discuss modern development workflows!

💻 GitHub: johnnylemonny
✍️ DEV.to: johnnylemonny

This article was created with the help of AI

Stop Paying for GitHub Copilot: Build a Free, 100% Private AI Assistant Locally

𝗝𝗼𝗵𝗻 — Tue, 23 Jun 2026 12:15:00 +0000

The landscape of AI coding assistants has completely shifted. While cloud-based subscriptions like GitHub Copilot or Claude Pro are excellent, they come with two major pain points: recurring monthly costs and privacy concerns regarding your proprietary code.

Thanks to the incredible advancements in efficiency, you can now run state-of-the-art coding LLMs directly on your local machine with zero latency, absolute privacy, and absolutely no cost.

In this guide, we will set up a blazing-fast, context-aware local AI coding assistant using Ollama and Continue.dev in VS Code.

Why Go Local?

💰 Cost-Efficient: $0/month forever.
🔒 100% Private: Your code never leaves your local machine. Perfect for NDA-protected or enterprise projects.
✈️ Offline Capability: Code with full AI assistance on a plane, a train, or anywhere without internet.
🚀 Customization: Swap models instantly depending on whether you need quick autocomplete or deep architectural reasoning.

Prerequisites

To get a smooth experience, you ideally need:

A modern machine (Apple Silicon M-series chips or a Windows/Linux PC with a dedicated Nvidia RTX GPU).
16GB of RAM/VRAM minimum (8GB can work with highly compressed models, but 16GB+ is the sweet spot).

Step 1: Install Ollama and the Coding Model

Ollama is the easiest way to manage and run LLMs locally.

Download and install Ollama for your OS.
Open your terminal and run the following command to download Qwen2.5-Coder (7B) or DeepSeek-Coder. For most modern setups, the 7B (7-billion parameter) model offers the ultimate balance between speed and ChatGPT-4 level coding intelligence.

ollama run qwen2.5-coder:7b

Note: If your machine has lower specs, try ollama run qwen2.5-coder:1.5b for lightning-fast autocompletion.

Once the download is complete, you can test it in the terminal, then minimize it. Ollama will run quietly in the background as a local API.

Step 2: Set Up Continue.dev in Your IDE

Continue is an open-source AI code assistant extension that seamlessly replaces the Copilot UI in VS Code or JetBrains IDEs.

Open VS Code.
Go to the Extensions marketplace (Ctrl+Shift+X or Cmd+Shift+X).
Search for Continue and click Install.

Step 3: Configure Continue to Use Your Local Model

Once installed, a new icon will appear in your sidebar. Click it, then click the gear icon (⚙️) at the bottom right of the Continue panel to open your config.json file.

Replace the contents of the file with the following configuration to link it to your local Ollama instance:

{
  "models": [
    {
      "title": "Qwen2.5-Coder 7B",
      "provider": "ollama",
      "model": "qwen2.5-coder:7b"
    }
  ],
  "tabAutocompleteModel": {
    "title": "Qwen2.5-Coder 1.5b",
    "provider": "ollama",
    "model": "qwen2.5-coder:1.5b"
    },
  "customCommands": [
    {
      "name": "test",
      "prompt": "{{{ input }}}\n\nWrite a comprehensive unit test suite for the code above using Jest/Vitest.",
      "description": "Write unit tests"
    }
  ],
  "contextProviders": [
    { "name": "codebase", "params": {} },
    { "name": "openFiles", "params": {} }
  ]
}

What this configuration does:

Chat Model: Uses the robust 7b model for complex tasks, refactoring, and general chat conversations in the sidebar (Cmd+L or Ctrl+L).
Tab Autocomplete: Uses the ultra-lightweight 1.5b model to instantly suggest inline code as you type, ensuring zero lag.
Context Awareness: Allows you to type @codebase in the chat to let the local AI read your entire project repository securely.

How to Maximize Your Local AI Workflow

Now that you are fully set up, here are three essential shortcuts to replace your paid workflow:

1. The Inline Edit (`Cmd+I` / `Ctrl+I`)

Highlight a block of code, press Cmd+I, and ask the local model to modify it directly. For example: "Refactor this fetch request to use async/await and add error handling."

2. Full Project Context (`@codebase`)

If you are debugging a tricky bug that spans multiple files, open the chat and type:

@codebase why is my authentication state resetting on page refresh?

The extension will index your local files locally, feed relevant snippets to Ollama, and give you an exact answer without a single byte uploaded to the cloud.

3. Automatic Doc Generation

Highlight a function, hit your chat shortcut, and ask: "Add JSDoc comments to this function explaining the parameters."

Final Thoughts

The era of paying $10-$20 a month per developer for basic AI autocompletion is coming to an end. By leveraging open-weights models and local orchestration tools, you gain total control over your development environment, secure your data, and save money.

Give it a spin and see how it handles your toughest codebases!

Connect with Me

If you found this guide helpful, let's connect and discuss modern development workflows!

💻 GitHub: johnnylemonny
✍️ DEV.to: johnnylemonny

Beyond Code Autocomplete: How to Build a Modern Agentic Workflow in 2026

𝗝𝗼𝗵𝗻 — Tue, 16 Jun 2026 13:07:00 +0000

Let’s be honest: the era of copy-pasting code snippets from a chat UI or blindly accepting basic ghost-text autocomplete is officially over.

As we move through 2026, the developer landscape has fundamentally shifted. We’ve leapfrogged from AI augmentation to AI delegation. With over 70% of engineers using advanced AI tools daily, the competitive advantage isn't knowing how to prompt AI to write a quick utility function. It's knowing how to orchestrate Autonomous AI Agents to manage entire feature lifecycles.

If you want to stay ahead of the curve, save your cognitive load, and prevent your codebase from turning into an AI-generated spaghetti monster, you need to upgrade your setup.

Here is what a modern, high-leverage developer workflow looks like today.

1. The Shift to Bounded Agentic Workflows

We’ve moved past simple extensions. Modern tools like Claude Code, Cursor’s Agent Mode, and next-gen Copilot don’t just sit in your sidebar waiting for a prompt. They have repository intelligence.

They can:

Read your entire file structure and understand architectural intent.
Independently formulate multi-step execution plans.
Write code across multiple files, run tests in your terminal, read the error output, and self-correct before you even look at the PR.

💡 The 2026 Mindset: You are no longer a "line mechanic" writing every block of boilerplate by hand. You are a System Architect and a Code Reviewer. Your job is to define constraints, review intent, and validate outputs.

2. Enter MCP: The "USB-C Port" for AI Context

One of the quietest yet biggest revolutions happening right now is the widespread adoption of the Model Context Protocol (MCP).

Originally introduced as an open standard to connect AI models to secure data sources, MCP has become the integration layer of choice. Instead of you copying and pasting logs, database schemas, or API docs into an LLM, your development environment uses MCP servers to securely stream that context directly to the agent.


┌──────────────┐          MCP          ┌─────────────────────────┐
│              │◄─────────────────────►│ Your local filesystem   │
│   AI Agent   │          MCP          ├─────────────────────────┤
│ (Cursor/IDE) │◄─────────────────────►│ Production logs (Sentry)│
│              │          MCP          ├─────────────────────────┤
│              │◄─────────────────────►│ DB Schemas / App APIs   │
└──────────────┘                       └─────────────────────────┘

When your AI agent can safely inspect a distributed trace in Sentry, cross-reference it with your database schema, and apply a patch directly to your repository, debugging friction drops to near zero.

3. Why "Boring" Codebase Qualities are Your Superpower

There’s a common misconception that because AI can write code, humans can stop worrying about code quality. The exact opposite is true.

AI agents are highly sensitive to context. If your codebase is a chaotic mess of unstructured files and implicit types, the AI’s hallucination rate skyrockets. In 2026, building "agent-friendly" codebases is a core engineering skill.

To get the most out of modern AI workflows, prioritize these "boring" but strategic qualities:

Strict Type Safety: TypeScript has become the absolute baseline. Strong types and explicit data contracts act as guardrails for AI agents, preventing them from generating breaking changes.
Predictable Architecture: Stick to clean, conventional folder structures (like those enforced by modern meta-frameworks like Next.js or Nuxt).
Comprehensive Test Suites: If an agent can't run a test suite to verify its work, you cannot trust its autonomy.
Explicit Documentation: Write clear README.md files and code comments explaining why something was built a certain way, not just how. AI reads your docs to understand your business logic constraints.

4. Let the Tooling Handle the Micro-Optimizations

Another reason to shift your focus to high-level architecture is that modern frameworks have become incredibly smart.

With the maturity of tools like the React Compiler, manual performance optimization patterns (like aggressively littering your code with useMemo and useCallback) are largely things of the past. The compiler handles the optimization at build time, freeing you up to think about data flow, edge computing deployment strategies, and user experience.

5. Your 30-Day Action Plan to Upgrade Your Workflow

If you want to compound your engineering leverage this month, stop doing things manually and try this:

Adopt an Agent-First Tool: If you're still on a legacy editor, spend a week working inside Cursor's Agent Mode or experiment with Claude Code via your CLI. Force yourself to delegate full tasks (e.g., "Refactor this component to use Tailwind v4 and add unit tests").
Explore MCP: Set up an MCP server to connect your development environment to your tool stack (like your issue tracker or database client). See how much faster bugs get resolved when the AI has direct context.
Audit for Autonomy: Look at your current repository. If an automated agent tried to implement a feature right now, where would it fail? Fix your missing types, update your outdated setup scripts, and make your codebase machine-readable.

What are your thoughts?

Are you embracing "Vibe Coding" and agentic workflows, or are you keeping a tight manual grip on your codebase? Let's discuss in the comments below!

AI Can Build Your UI — But Can It Maintain It?

𝗝𝗼𝗵𝗻 — Thu, 04 Jun 2026 13:00:00 +0000

Modern Web Development in 2026

A practical series about building faster, cleaner, more maintainable web applications without chasing every shiny thing.

AI can build a surprisingly convincing UI in a few minutes.

That is useful. It is also dangerous in the same way a good mockup is dangerous: it can look finished before the engineering decisions are finished.

The question is no longer whether AI can generate components.

The better question is:

Can your team maintain what AI generated six months from now?

Generated UI has a smell

AI-generated frontend often looks impressive at first glance and strange on review.

Common signs:

duplicated components,
inconsistent spacing,
random animation choices,
inaccessible markup,
weak loading and error states,
hard-coded colors,
unclear state ownership,
no component contract,
tests that only prove rendering happened.

None of this means the tool is bad. It means the output needs engineering.

Give AI constraints, not vibes

Bad prompt:

Build a beautiful dashboard.

Better prompt:

Build a dashboard page using our existing Card, Button, Badge, and Table components.
Use semantic HTML. Include loading, empty, and error states.
Do not introduce new colors outside the design tokens.
Keep state local unless it is shared by more than one component.
Add keyboard-accessible interactions.
Return the component and a short review checklist.

AI is much more useful when you give it boundaries.

Ask for states, not just screens

A screen is not a component.

A component has states:

loading
empty
success
error
permission denied
partial data
saving
saved
validation failed

If the generated UI only includes the happy path, it is not ready for production.

Require component contracts

Before accepting generated UI, define the contract:

type InvoiceTableProps = {
  invoices: InvoiceSummary[];
  status: "loading" | "empty" | "ready" | "error";
  onRetry?: () => void;
  onOpenInvoice: (invoiceId: InvoiceId) => void;
};

This forces the component to have a clear boundary.

Without a contract, generated UI tends to reach outward: global state, random fetches, hidden assumptions, and props that grow without discipline.

Keep design tokens non-negotiable

AI loves inventing colors.

Do not let it.

:root {
  --color-bg: #0b1020;
  --color-surface: #121a2f;
  --color-text: #f8fafc;
  --color-muted: #94a3b8;
  --color-accent: #22c55e;
}

Tell the tool:

Use only existing design tokens. Do not invent new hex colors, spacing values, shadows, or font sizes unless explicitly requested.

Consistency is not decoration. It is maintainability.

Make accessibility part of the prompt

Do not ask for accessibility after the component is generated.

Include it at the start:

Use semantic HTML.
All interactive elements must be keyboard accessible.
Use visible focus states.
Do not use divs as buttons.
Connect form labels and error messages properly.
Avoid ARIA unless native HTML is not enough.

This will not guarantee perfect accessibility, but it raises the floor.

Review generated UI like a pull request

Use this checklist:

## AI-generated UI review

- Does it use existing components and tokens?
- Are loading, empty, error, and permission states handled?
- Is the markup semantic?
- Is keyboard interaction supported?
- Are props explicit and typed?
- Is state owned by the right component?
- Are side effects isolated?
- Are tests meaningful?
- Is there duplicated logic?
- Could another developer safely change this later?

The last question is the point.

Good uses of AI in frontend

AI is genuinely helpful for:

first drafts,
test scaffolding,
refactoring repetitive markup,
converting rough UI ideas into components,
writing stories for component states,
finding accessibility issues,
generating edge-case checklists,
explaining unfamiliar code.

It is less reliable for:

architecture boundaries,
product intent,
design consistency,
long-term ownership,
subtle accessibility behavior,
performance tradeoffs.

Use it where speed helps. Slow down where judgment matters.

Final thought

AI can generate UI. That is no longer the impressive part.

The impressive part is building a frontend system where generated code has to pass through the same standards as human-written code.

A fast draft is useful. A maintainable product is better.

Sources

Syncfusion, “Frontend Development Trends 2026,” published April 28, 2026: https://www.syncfusion.com/blogs/post/frontend-development-trends
2025 JavaScript Rising Stars, published 2026: https://risingstars.js.org/2025/en
Stack Overflow Blog, “Domain expertise still wanted: the latest trends in AI-assisted knowledge for developers,” published March 16, 2026: https://stackoverflow.blog/2026/03/16/domain-expertise-still-wanted-the-latest-trends-in-ai/

Thanks for reading.

You can find me here:

GitHub: https://github.com/johnnylemonny
DEV: https://dev.to/johnnylemonny

Accessibility Is Not a Lighthouse Checkbox

𝗝𝗼𝗵𝗻 — Tue, 02 Jun 2026 13:00:00 +0000

Modern Web Development in 2026

A practical series about building faster, cleaner, more maintainable web applications without chasing every shiny thing.

Automated accessibility checks are useful.

They catch missing labels, obvious contrast failures, invalid ARIA, and a lot of mistakes that should never reach production.

But accessibility is not finished when a tool gives you a green score.

A green score can still hide a page that is confusing, exhausting, or impossible to use with a keyboard.

Start with semantic HTML

The most underrated accessibility tool is still HTML.

Use the element that matches the job:

<button type="button">Save changes</button>
<a href="/settings">Account settings</a>
<nav aria-label="Main navigation">...</nav>
<main>...</main>
<form>...</form>

Do not turn everything into a div and then rebuild the platform with ARIA.

ARIA is powerful. It is also easy to misuse. Native semantics are usually safer.

Keyboard test every important flow

Put the mouse away.

Can you complete the flow with only:

Tab
Shift + Tab
Enter
Space
Arrow keys
Escape

Test:

opening menus,
closing dialogs,
submitting forms,
moving through filters,
skipping repeated navigation,
reaching error messages,
recovering from mistakes.

If your product cannot be used from a keyboard, it is broken for more people than you think.

Focus is part of the interface

Removing focus styles is not polish. It is damage.

Good focus indicators are:

visible,
consistent,
high contrast,
not hidden behind shadows,
not dependent on color alone.

:focus-visible {
  outline: 3px solid var(--focus-ring);
  outline-offset: 3px;
}

The goal is not to make focus pretty enough for a screenshot. The goal is to make the current location obvious.

Forms need more care than we give them

A good form explains itself before, during, and after input.

<label for="email">Email address</label>
<input id="email" name="email" type="email" autocomplete="email" aria-describedby="email-hint" />
<p id="email-hint">Use the address where you want to receive account updates.</p>

For errors:

place the message near the field,
describe how to fix it,
connect it programmatically,
summarize errors for long forms,
move focus intentionally after failed submission.

“Invalid input” is not a helpful error. It is a shrug.

Dialogs are traps unless designed carefully

A modal dialog should:

move focus into the dialog when opened,
trap focus while open,
close with Escape when appropriate,
return focus to the triggering element,
have a clear accessible name,
avoid background interaction.

If that sounds like a lot, use a well-tested primitive. Dialogs are one of the places where “simple custom code” often becomes inaccessible custom code.

Do not use color alone

Color is useful. It should not be the only signal.

Bad:

Required fields are red.

Better:

Required fields have text, an icon, and programmatic state.

For charts, statuses, validation, and alerts, combine:

text,
shape,
position,
iconography,
semantic markup.

Automated tests are a floor

Add accessibility checks to CI:

import { test, expect } from "@playwright/test";
import AxeBuilder from "@axe-core/playwright";

test("page has no obvious accessibility violations", async ({ page }) => {
  await page.goto("/settings");
  const results = await new AxeBuilder({ page }).analyze();
  expect(results.violations).toEqual([]);
});

This is good. It is not enough.

Automated tools cannot fully judge whether the flow makes sense, whether focus movement feels logical, or whether the content is understandable.

The human checklist

Before release, test:

[ ] Can the full flow be completed with keyboard only?
[ ] Is focus always visible?
[ ] Are headings meaningful and ordered?
[ ] Are form labels explicit?
[ ] Are errors helpful and connected to fields?
[ ] Are dialogs focus-managed?
[ ] Is color supported by another signal?
[ ] Does the page make sense with CSS disabled?
[ ] Does the page make sense with images unavailable?

Final thought

Accessibility is not a separate layer you add after the “normal” product is done.

It is part of the product being usable.

A green automated score is a good start. A real user completing a real task without barriers is the goal.

Sources

CSS-Tricks, “HTTP Archive 2025 Web Almanac,” published January 16, 2026: https://css-tricks.com/http-archive-2025-web-almanac/
Syncfusion, “Frontend Development Trends 2026,” published April 28, 2026: https://www.syncfusion.com/blogs/post/frontend-development-trends
MDN Web Docs, “Baseline compatibility”: https://developer.mozilla.org/en-US/docs/Glossary/Baseline/Compatibility

Thanks for reading.

You can find me here:

GitHub: https://github.com/johnnylemonny
DEV: https://dev.to/johnnylemonny

CSS Got Good While You Were Installing More Libraries

𝗝𝗼𝗵𝗻 — Thu, 28 May 2026 13:00:00 +0000

Modern Web Development in 2026

A practical series about building faster, cleaner, more maintainable web applications without chasing every shiny thing.

A lot of frontend habits were formed when CSS was weaker.

We reached for libraries because layout was painful, responsive components were awkward, browser support was uncertain, and the cascade felt like a haunted basement.

That history is real.

But modern CSS is not the same tool many developers learned five or ten years ago.

CSS got good. Quietly. While everyone was arguing about JavaScript frameworks.

The new default: check the platform first

Before installing a styling library, ask:

Can the platform solve this now?

Often, the answer is yes.

Modern CSS gives us better primitives for:

responsive components,
layout composition,
cascade control,
design tokens,
theme switching,
typography,
state-based styling,
fluid spacing.

Libraries can still be useful. They should not be reflexes.

Container queries change component design

Viewport media queries answer this:

How wide is the screen?

Container queries answer the more useful question:

How much space does this component have?

.card-grid {
  container-type: inline-size;
}

@container (min-width: 42rem) {
  .article-card {
    display: grid;
    grid-template-columns: 14rem 1fr;
  }
}

This makes components more portable. A card can adapt inside a sidebar, dashboard, modal, or full-width layout without pretending the viewport is the only context.

`:has()` makes parent-aware styling practical

For years, developers wanted a parent selector. Now we have a powerful version of it.

.field:has(input:invalid) {
  border-color: var(--color-danger);
}

.card:has(.card__media) {
  grid-template-rows: auto 1fr;
}

Used carefully, :has() can remove JavaScript that only exists to toggle classes.

Cascade layers make CSS less fragile

The cascade is not bad. Unmanaged cascade is bad.

@layer reset, tokens, base, components, utilities;

@layer tokens {
  :root {
    --space-4: 1rem;
    --radius-lg: 1rem;
  }
}

@layer components {
  .button {
    border-radius: var(--radius-lg);
    padding: var(--space-4);
  }
}

Layers let you define priority intentionally instead of relying on selector combat.

Subgrid fixes a real layout problem

Nested layouts often need to align with parent tracks.

.article-list {
  display: grid;
  grid-template-columns: 1fr minmax(0, 42rem) 1fr;
}

.article-card {
  display: grid;
  grid-template-columns: subgrid;
  grid-column: 1 / -1;
}

This helps create layouts that feel designed, not merely stacked.

Fluid type without a framework

You can create responsive typography with plain CSS:

:root {
  --step-0: clamp(1rem, 0.96rem + 0.2vw, 1.125rem);
  --step-3: clamp(1.75rem, 1.25rem + 2vw, 3rem);
}

h1 {
  font-size: var(--step-3);
  line-height: 1.05;
}

p {
  font-size: var(--step-0);
  line-height: 1.7;
}

No runtime. No package. No hydration. Just CSS.

Use Baseline thinking

The modern question is not “Can I use this feature on my machine?”

It is:

Is this feature supported well enough for my audience and fallback strategy?

Baseline helps make that decision more systematic, but it does not replace testing. You still need to check accessibility, usability, performance, and your actual user base.

The library decision checklist

Before adding a styling dependency, ask:

[ ] Is the problem solved by modern CSS?
[ ] Does the library add runtime JavaScript?
[ ] Does it make accessibility easier or harder?
[ ] Can the team debug the generated output?
[ ] Does it work with our design tokens?
[ ] Can we remove it later?
[ ] Is the dependency worth the long-term surface area?

Final thought

CSS is not just the thing you write after the “real” engineering is done.

It is a powerful layout and interaction language that now solves problems we used to outsource by default.

Install libraries when they help. But give the platform a chance first.

Sources

web.dev, “Baseline”: https://web.dev/baseline/
MDN Web Docs, “Baseline compatibility”: https://developer.mozilla.org/en-US/docs/Glossary/Baseline/Compatibility
CSS-Tricks, “HTTP Archive 2025 Web Almanac,” published January 16, 2026: https://css-tricks.com/http-archive-2025-web-almanac/

Thanks for reading.

You can find me here:

GitHub: https://github.com/johnnylemonny
DEV: https://dev.to/johnnylemonny

TypeScript Won — Now Stop Using It Like Fancy JavaScript

𝗝𝗼𝗵𝗻 — Tue, 26 May 2026 13:00:00 +0000

Modern Web Development in 2026

A practical series about building faster, cleaner, more maintainable web applications without chasing every shiny thing.

TypeScript won the argument.

Most serious JavaScript codebases either use it already or are planning around it. The more interesting question is what we do after adoption.

Because a lot of TypeScript code is still just JavaScript wearing a blazer.

function createUser(data: any): any {
  return api.post("/users", data);
}

Technically TypeScript. Spiritually not.

Types should protect boundaries

The best places to spend type effort are boundaries:

API input,
API output,
database records,
form state,
configuration,
feature flags,
permissions,
domain events.

Internal implementation types are useful. Boundary types are where bugs go to die.

Replace vague shapes with domain language

This is common:

type User = {
  id: string;
  role: string;
  status: string;
};

It is better than nothing, but it leaves too much room.

type UserRole = "admin" | "editor" | "viewer";
type UserStatus = "invited" | "active" | "suspended";

type User = {
  id: UserId;
  role: UserRole;
  status: UserStatus;
};

Now invalid states have fewer places to hide.

Use branded types for dangerous strings

Not every string is the same kind of string.

type Brand<T, Name extends string> = T & { readonly __brand: Name };

type UserId = Brand<string, "UserId">;
type OrgId = Brand<string, "OrgId">;

Now this mistake becomes harder:

function getUser(orgId: OrgId, userId: UserId) {}

A plain string can come from anywhere. A branded string says, “This value passed through a specific gate.”

Prefer discriminated unions over boolean soup

Boolean-heavy state is where UI bugs breed.

type RequestState = {
  loading: boolean;
  error?: string;
  data?: User;
};

This allows nonsense:

{ loading: true, error: "Failed", data: user }

Use a union:

type RequestState =
  | { status: "idle" }
  | { status: "loading" }
  | { status: "success"; data: User }
  | { status: "error"; message: string };

Now the impossible states are actually impossible.

Validate runtime data

TypeScript does not validate JSON at runtime.

This is one of the most expensive misunderstandings in web development.

const user = (await response.json()) as User;

That line does not make the response a User. It makes the compiler quiet.

Use runtime validation at external boundaries:

const UserSchema = z.object({
  id: z.string(),
  role: z.enum(["admin", "editor", "viewer"]),
  status: z.enum(["invited", "active", "suspended"])
});

const user = UserSchema.parse(await response.json());

Now TypeScript and runtime reality are connected.

Use `satisfies` for configuration

Configuration should be checked without losing literal types.

const routes = {
  home: "/",
  dashboard: "/dashboard",
  settings: "/settings"
} satisfies Record<string, `/${string}`>;

This catches invalid values while preserving useful inference.

Avoid type theater

Some types add noise but not safety.

type StringOrNumber = string | number;
type Callback = (...args: any[]) => any;
type ObjectMap = Record<string, any>;

These can be valid in rare cases, but often they are placeholders for decisions nobody made.

Good TypeScript is not more TypeScript. Good TypeScript is better constraints.

The practical checklist

Use this before merging TypeScript-heavy changes:

[ ] Are external inputs validated at runtime?
[ ] Are domain concepts named explicitly?
[ ] Are impossible UI states impossible?
[ ] Are IDs and tokens distinguishable?
[ ] Are any and unsafe assertions isolated?
[ ] Can a new developer understand the model from the types?
[ ] Do the types reduce tests you would otherwise need?

Final thought

TypeScript is not valuable because it makes JavaScript look professional.

It is valuable because it lets you encode decisions before those decisions become bugs.

If your types do not protect boundaries, model the domain, or remove impossible states, you are leaving most of the value on the table.

Sources

InfoQ, “State of JavaScript 2025: Survey Reveals a Maturing Ecosystem with TypeScript Cementing Dominance,” published March 20, 2026: https://www.infoq.com/news/2026/03/state-of-js-survey-2025/
Syncfusion, “Frontend Development Trends 2026,” published April 28, 2026: https://www.syncfusion.com/blogs/post/frontend-development-trends

Thanks for reading.

You can find me here:

GitHub: https://github.com/johnnylemonny
DEV: https://dev.to/johnnylemonny

Cabal for Android: My First Native Kotlin P2P Chat App Reaches Its First Early Version

𝗝𝗼𝗵𝗻 — Tue, 26 May 2026 06:30:00 +0000

A few weeks ago, I wrote about working on Cabal v3, a modern peer-to-peer chat app for Android, and how I started by exploring a React Native direction.

Later, I also wrote about how I started learning Kotlin by building a real Android app instead of only reading tutorials.

This post is the continuation of that series.

Today, I’m happy to share that the first early version of Cabal for Android is now available.

GitHub repository:

👉 https://github.com/johnnylemonny/cabal-android

An early version is also available to download from the repository.

What is Cabal for Android?

Cabal for Android is my attempt to build a modern Android client for Cabal as a native Kotlin application.

The idea is simple:

a peer-to-peer chat app for Android, built with modern native Android development in mind.

This project started as an experiment, but it quickly became something more serious for me. It became a way to learn Kotlin, understand Android development better, and explore how decentralized communication can feel on mobile.

From React Native exploration to native Kotlin

In the first post of this series, I wrote about reviving a P2P mobile chat app idea and experimenting with Cabal on Android.

At that point, I was thinking about the project from a React Native perspective.

That was useful because it helped me understand the shape of the app:

what the UI could look like,
how the chat flow should feel,
what kind of mobile experience I wanted,
and how much work would be involved in bringing a P2P chat app back to life on Android.

But after spending more time with the project, I decided to move deeper into native Android development.

That decision led me to Kotlin.

Why Kotlin?

Kotlin had been on my list for a long time.

I had read about it before. I had seen examples. I understood the basic syntax. But I never really learned it properly because I was missing one important thing:

a real project.

Cabal became that project.

Instead of learning Kotlin in isolation, I learned it by building something that had real screens, real state, real problems, and real trade-offs.

That changed everything.

Kotlin stopped being just a list of language features and became a tool I used every day to move the app forward.

What is included in this first version?

This is still an early version, but it is an important milestone.

The app is now at the point where it feels like a real native Android project instead of just an idea or experiment.

The first version focuses on the foundation:

native Android structure,
Kotlin-based implementation,
a modern mobile app direction,
Cabal-related chat experience,
early downloadable build,
and a codebase that can now evolve further.

It is not perfect yet.

It is not “finished” in the final-product sense.

But it is finished in the most important early-stage sense:

the project exists, runs, can be tested, and has a real direction.

That feels like a big step.

What I learned while building it

Building this first version taught me much more than I expected.

1. Real apps teach faster than tutorials

Tutorials are useful, but they usually have clean examples and predictable problems.

Real apps are different.

When building Cabal for Android, I had to make decisions about structure, state, screens, naming, data flow, and how to keep the app understandable as it grew.

That kind of learning is harder, but also much more valuable.

2. Kotlin makes Android development feel focused

One thing I started to appreciate is how Kotlin encourages more intentional code.

Null safety, data classes, immutability, and concise syntax all helped me think more clearly about the app.

At first, some parts slowed me down. But over time, those same features made the project feel safer and easier to reason about.

3. Native Android development has its own rhythm

Coming from other environments, native Android development requires a different mindset.

You are not only learning Kotlin.

You are also learning:

Android project structure,
lifecycle concepts,
UI patterns,
state handling,
Gradle,
app packaging,
and how all of these pieces fit together.

That was challenging, but also one of the best parts of the process.

4. Small milestones matter

This version is early, but shipping it matters.

It is easy to keep waiting until everything is perfect.

But open-source projects grow better when they are visible early.

Putting this first version out there gives the project a real starting point.

Why this project matters to me

Cabal for Android sits at the intersection of a few things I care about:

mobile development,
Kotlin,
Android,
open source,
peer-to-peer communication,
and learning by building.

I like projects that are practical but also a little experimental.

A P2P chat app is exactly that kind of project.

It is not just another CRUD app. It forces you to think about networking, identity, local-first experiences, mobile constraints, and how users communicate without depending entirely on centralized infrastructure.

That makes it a fun and meaningful project to work on.

Repository and download

The project is available here:

👉 https://github.com/johnnylemonny/cabal-android

There is also an early downloadable version available from the repository.

If you are interested in Kotlin, Android, peer-to-peer apps, or open-source mobile development, feel free to check it out.

Feedback, ideas, and contributions are welcome.

What comes next?

This first version is only the beginning.

Next, I want to continue improving the app step by step:

polish the UI,
improve the chat experience,
clean up the architecture,
test more edge cases,
improve stability,
and continue learning Kotlin through real development.

I also want to keep writing about the process because documenting the journey helps me understand what I’m learning.

And maybe it helps someone else too.

Final thoughts

This project started as an experiment.

Then it became a Kotlin learning project.

Now it is becoming a real native Android app.

That progression has been very motivating.

The biggest lesson so far is simple:

If you want to learn a technology deeply, build something real with it.

Cabal for Android gave me a reason to learn Kotlin properly.

And now the first early version is here.

Thanks for reading — and if you try the app or look through the code, I’d love to hear what you think.

Next.js Caching Is Hard Because You’re Thinking About It Too Late

𝗝𝗼𝗵𝗻 — Thu, 21 May 2026 13:00:00 +0000

Modern Web Development in 2026

A practical series about building faster, cleaner, more maintainable web applications without chasing every shiny thing.

Next.js caching is not hard because caching is mysterious.

It is hard because teams often decide what the user should see, build the feature, ship the route, and only then ask:

Wait, should this be cached?

By that point, caching feels like a trap. Static or dynamic? Revalidate or no-store? Tag invalidation? Server Actions? Partial rendering? Why did this page update locally but not in production?

The problem started earlier.

Caching is not a setting. It is a product decision.

Start with freshness

Before writing code, classify the data.

Always fresh        account balance, auth state, checkout price
Fresh enough        inventory count, dashboard cards, notifications
Rarely changes      marketing copy, docs navigation, pricing page layout
Versioned           blog posts, changelog entries, release notes
User-triggered      form result, optimistic mutation, saved settings

Each category deserves a different strategy.

If you do not define freshness, the framework cannot guess your intent.

The user does not care about your cache

Users care about expectations:

“I changed my profile; I should see it now.”
“I published a post; the public page should update soon.”
“I added an item to cart; the total should be correct.”
“I opened docs; they should load instantly.”

Those expectations map directly to caching behavior.

Cache by boundary, not by hope

A page usually contains mixed data.

Example product page:

product title: rarely changes,
price: may change,
inventory: fresh enough,
recommendations: personalized,
reviews: revalidated periodically,
cart state: user-specific.

If you cache the entire page as one unit, one dynamic section can make the whole route harder to reason about.

Instead, design boundaries:

export default async function ProductPage({ params }) {
  return (
    <main>
      <ProductShell productId={params.id} />
      <LivePurchaseBox productId={params.id} />
      <Recommendations productId={params.id} />
    </main>
  );
}

Then each section can have its own freshness model.

Make invalidation boring

Invalidation should be obvious from the mutation.

Bad mutation:

await updateProduct(productId, input);

Better mutation:

await updateProduct(productId, input);
await invalidateProduct(productId);
await invalidateProductList();

Even better: centralize the policy so developers do not remember tags by hand.

export async function invalidateProduct(productId: string) {
  revalidateTag(`product:${productId}`);
  revalidateTag("products:list");
}

A cache strategy nobody can remember is not a strategy.

Avoid accidental personalization leaks

Caching becomes dangerous when user-specific data slips into shared output.

Watch for:

user names in cached navigation,
role-specific actions in shared HTML,
personalized recommendations in static shells,
auth-only pricing mixed with public product data.

A simple rule helps:

Public data can be shared. User data needs a user boundary.

If a component depends on cookies, headers, session, or permissions, treat it differently.

Use loading states intentionally

Partial rendering and streaming are powerful because they let you show stable UI while dynamic sections load.

But a loading skeleton is not a substitute for product thinking.

Good skeleton:

preserves layout,
communicates progress,
appears only where delay is expected,
does not cause content to jump.

Bad skeleton:

flashes for 80ms,
shifts the layout,
appears everywhere,
hides the fact that the data model is too slow.

Debugging questions

When a Next.js route behaves strangely, I use this checklist:

## Caching debug checklist

- Is this route expected to be static, dynamic, or mixed?
- Which data must be fresh for every request?
- Which data can be cached safely?
- Is any user-specific data crossing a shared cache boundary?
- What event invalidates this data?
- Does the mutation revalidate the exact thing the user expects?
- Is the loading state masking an architecture problem?
- Can the behavior be explained in one paragraph?

That last question matters. If nobody on the team can explain the caching behavior simply, production will explain it for you.

The mental model

Think of caching as a conversation between three things:

Data truth — where the correct data lives.
User expectation — when the user expects to see changes.
Rendering boundary — where the UI can safely reuse work.

When those three agree, caching feels boring.

When they disagree, caching feels haunted.

Final thought

Next.js caching is not something to sprinkle on a finished route.

It belongs in the first design conversation.

Decide freshness early. Draw boundaries early. Name invalidation early.

Your future self will spend less time asking why the page is stale and more time building things users actually notice.

Sources

Next.js, “Next.js 16,” published October 21, 2025: https://nextjs.org/blog/next-16
InfoWorld, “Next.js 16 features explicit caching, AI-powered debugging,” published October 24, 2025: https://www.infoworld.com/article/4078213/next-js-16-features-explicit-caching-ai-powered-debugging.html

Thanks for reading.

You can find me here:

GitHub: https://github.com/johnnylemonny
DEV: https://dev.to/johnnylemonny

React Is Not the Problem — Your Client-Side Mental Model Is

𝗝𝗼𝗵𝗻 — Tue, 19 May 2026 13:00:00 +0000

Modern Web Development in 2026

A practical series about building faster, cleaner, more maintainable web applications without chasing every shiny thing.

React gets blamed for a lot of slow websites.

Sometimes that is fair. A careless React app can ship too much JavaScript, hydrate too much UI, and re-render too often.

But React is rarely the whole problem. The deeper problem is a mental model that says:

If something appears on the screen, it must be a client-side component.

That assumption made sense for many single-page apps. It makes less sense for much of the web we are building now.

A better default

Try this default instead:

Render as much as possible before the browser receives the page. Hydrate only what must be interactive.

This does not mean every product should be static. It means interactivity should be intentional.

The three kinds of UI

Most screens contain three different kinds of UI.

1. Content UI

This is information the user reads:

product names,
documentation,
blog content,
pricing details,
profile summaries,
search results.

This usually does not need client-side state.

2. Navigation UI

This helps the user move:

menus,
tabs,
breadcrumbs,
pagination,
links.

Some of it needs JavaScript. Much of it does not.

3. Interaction UI

This changes based on user action:

forms,
filters,
carts,
editors,
dashboards,
command palettes.

This is where client-side React shines.

The mistake is treating all three categories the same.

The client component tax

A client component costs more than its source file.

It can pull in:

dependencies,
state management,
event handlers,
hydration work,
serialization boundaries,
re-render behavior,
test complexity.

So do not ask, “Can this be a client component?”

Ask:

What user interaction requires this to be a client component?

If you cannot name the interaction, the component is probably in the wrong place.

Keep islands small

A common pattern is to make the whole layout interactive because one child needs state.

Avoid this:

"use client";

export function ProductPage({ product }) {
  const [quantity, setQuantity] = useState(1);

  return (
    <main>
      <ProductHero product={product} />
      <ProductDescription product={product} />
      <QuantityPicker value={quantity} onChange={setQuantity} />
    </main>
  );
}

Prefer this:

export function ProductPage({ product }) {
  return (
    <main>
      <ProductHero product={product} />
      <ProductDescription product={product} />
      <QuantityPicker productId={product.id} />
    </main>
  );
}

Now the interactive island is the picker, not the page.

Stop fetching twice

Another slow pattern is server rendering a page and then immediately fetching the same data again in the browser.

That creates:

extra network requests,
loading flicker,
duplicated caching logic,
inconsistent error states.

If the server already has the data required for first render, use it. Fetch in the browser when the user’s interaction creates new information needs.

Memoization is not architecture

React developers sometimes reach for useMemo, useCallback, and memoized components when the real issue is that too much state lives too high in the tree.

Before memoizing, ask:

Can this state move closer to the component that uses it?
Can this work happen on the server?
Can this derived value be computed once before render?
Can this component stop receiving unstable props?

Memoization can help. It cannot fix a confused ownership model.

The decision checklist

For every component, ask:

## Component placement review

- Does it need browser-only APIs?
- Does it respond to user input before navigation?
- Does it manage local interactive state?
- Does it need real-time updates?
- Does it depend on viewport measurements?
- Could it render on the server and pass data to a smaller client child?

If most answers are “no,” keep it server-rendered.

React is still useful

The point is not to write less React because React is bad.

The point is to use React where it creates value:

rich forms,
optimistic updates,
complex stateful widgets,
collaborative UI,
dashboards,
editors,
design systems.

But rendering a heading, a paragraph, and a price card does not require a client-side mental model.

Final thought

React did not make your app slow by itself.

Your architecture made the browser responsible for work the browser did not need to do.

Once you start treating client-side JavaScript as a budget instead of a default, React becomes easier to use well.

Sources

InfoQ, “State of JavaScript 2025: Survey Reveals a Maturing Ecosystem with TypeScript Cementing Dominance,” published March 20, 2026: https://www.infoq.com/news/2026/03/state-of-js-survey-2025/
Next.js, “Next.js 16,” published October 21, 2025: https://nextjs.org/blog/next-16

Thanks for reading.

You can find me here:

GitHub: https://github.com/johnnylemonny
DEV: https://dev.to/johnnylemonny

Stop Shipping 700KB of JavaScript for a Button

𝗝𝗼𝗵𝗻 — Thu, 14 May 2026 13:00:00 +0000

Modern Web Development in 2026

A practical series about building faster, cleaner, more maintainable web applications without chasing every shiny thing.

There is a strange kind of web performance problem that does not look like a bug.

The page loads. The button appears. The design looks fine. The framework did its job. Lighthouse is not screaming loudly enough to block the release.

Then a real user taps the button on a mid-range phone while the main thread is busy doing work that should never have been shipped to the browser in the first place.

That is when the interface stops feeling like software and starts feeling like a negotiation.

This article is not an anti-JavaScript rant. JavaScript is one of the reasons the web is as capable as it is. The problem is simpler: we keep shipping client-side work that does not need to be client-side work.

The uncomfortable question

Before optimizing a component, ask this:

Does the browser need this code to make the first interaction useful?

If the answer is no, you have three options:

move it to the server,
delay it,
delete it.

Most performance wins come from that boring list.

The common failure mode

A button starts as a button.

Then it becomes:

a component library import,
a theme provider dependency,
an analytics wrapper,
an icon package import,
a tooltip,
an animation primitive,
a client component boundary,
a hydration root,
and a tiny state machine nobody asked for.

The user sees one button. The browser receives a small town.

Budget the page before you polish it

A performance budget is not a punishment. It is a design constraint.

Use a simple budget before arguing about micro-optimizations:

Initial JavaScript:      under 170 KB compressed
Route-level JS:          under 80 KB compressed
Third-party scripts:     justified one by one
Critical CSS:            small enough to inline when useful
Images above the fold:   explicit dimensions and optimized format
Hydration islands:       only where interaction is required

Your exact numbers can differ. The important part is that the budget exists before the page is already slow.

Start with the bundle, not the vibes

Run a bundle analyzer and look for the boring surprises:

npm run build
npx source-map-explorer "dist/**/*.js"

Or use the analyzer that fits your stack:

# Next.js example
ANALYZE=true npm run build

Then ask:

Why is this package in the initial route?
Is this library used for one function?
Did an icon import pull in more than one icon?
Is a date library doing work that Intl can do?
Is a chart library needed before the user scrolls to the chart?

Bundle analysis is humbling because it replaces opinions with weight.

Be suspicious of client boundaries

In server-first frameworks, the most expensive line in a file may be this one:

"use client";

That line is not bad. It is a contract.

It says:

This component and the code it pulls in must be available to the browser.

So keep client components narrow:

// Good boundary: only the interactive part is client-side.
export function ProductPage({ product }) {
  return (
    <main>
      <ProductSummary product={product} />
      <AddToCartButton productId={product.id} />
      <ProductDetails product={product} />
    </main>
  );
}

The button can be interactive. The whole page does not need to hydrate because one button exists.

Delay what is not needed yet

Some code is useful, just not immediately.

Good candidates for lazy loading:

charts below the fold,
markdown editors,
maps,
video players,
complex filters,
admin-only panels,
onboarding tours,
non-critical animations.

const HeavyChart = dynamic(() => import("./HeavyChart"), {
  loading: () => <ChartSkeleton />,
  ssr: false
});

Use this carefully. Lazy loading is not a magic spell. It moves cost. That is useful only when the moved cost no longer blocks the first useful interaction.

Third-party scripts are product decisions

Performance often dies by a thousand approved vendors.

Create a small script review:

### Third-party script review

- What user or business outcome does this script support?
- Does it run on every route?
- Can it load after interaction or consent?
- Who owns it?
- How do we remove it?
- What is the fallback if it fails?

If nobody owns a third-party script, the browser owns the consequences.

Optimize for interaction, not screenshots

A page that appears quickly but cannot respond is not fast.

Look for long tasks:

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.log("Long task:", entry.duration);
  }
}).observe({ type: "longtask", buffered: true });

Then trace what blocks the main thread:

hydration,
large JSON parsing,
expensive rendering,
synchronous storage access,
client-side sorting/filtering of large lists,
heavy analytics startup.

The browser is not a server. Stop treating it like one.

The practical checklist

Before shipping a new route, check:

[ ] Is the initial JavaScript budget visible in CI?
[ ] Are client components as small as possible?
[ ] Is non-critical UI lazy loaded?
[ ] Are third-party scripts justified?
[ ] Are images sized and optimized?
[ ] Is the main thread free before the first important interaction?
[ ] Did you test on a slower device or throttled profile?
[ ] Can the page still be useful if enhancements arrive late?

The boring truth

Most users do not care which framework you used.

They care that the page loads, responds, and gets out of their way.

The fastest JavaScript is the JavaScript you never send. The second fastest is the JavaScript you send later. The third fastest is the JavaScript you actually needed.

Sources

HTTP Archive, “Performance | 2025 Web Almanac,” published January 15, 2026: https://almanac.httparchive.org/en/2025/performance
CSS-Tricks, “HTTP Archive 2025 Web Almanac,” published January 16, 2026: https://css-tricks.com/http-archive-2025-web-almanac/

Thanks for reading.

You can find me here:

GitHub: https://github.com/johnnylemonny
DEV: https://dev.to/johnnylemonny

React devs: rethink useEffect! Treat it as sync with external systems, not lifecycle replacement. Avoid hidden state-machine traps & keep your code clean. #webdev #react

𝗝𝗼𝗵𝗻 — Fri, 08 May 2026 17:06:29 +0000

DEV Community: 𝗝𝗼𝗵𝗻

Stop Over-Optimizing Performance: The Modern Full-Stack Toolkit in 2026

1. The Death of Manual Memoization (Thanks, React Compiler)

2. Streaming SSR is the New Baseline for AEO

3. Radical Architectural Minimalism

4. Where You Should Actually Spend Your Time

Let's connect and discuss!

Connect with Me

Stop Paying for GitHub Copilot: Build a Free, 100% Private AI Assistant Locally

Why Go Local?

Prerequisites

Step 1: Install Ollama and the Coding Model

Step 2: Set Up Continue.dev in Your IDE

Step 3: Configure Continue to Use Your Local Model

What this configuration does:

How to Maximize Your Local AI Workflow

1. The Inline Edit (Cmd+I / Ctrl+I)

2. Full Project Context (@codebase)

3. Automatic Doc Generation

Final Thoughts

Connect with Me

Beyond Code Autocomplete: How to Build a Modern Agentic Workflow in 2026

1. The Shift to Bounded Agentic Workflows

2. Enter MCP: The "USB-C Port" for AI Context

3. Why "Boring" Codebase Qualities are Your Superpower

4. Let the Tooling Handle the Micro-Optimizations

5. Your 30-Day Action Plan to Upgrade Your Workflow

What are your thoughts?

AI Can Build Your UI — But Can It Maintain It?

Generated UI has a smell

Give AI constraints, not vibes

Ask for states, not just screens

Require component contracts

Keep design tokens non-negotiable

Make accessibility part of the prompt

Review generated UI like a pull request

Good uses of AI in frontend

Final thought

Sources

Accessibility Is Not a Lighthouse Checkbox

Start with semantic HTML

Keyboard test every important flow

Focus is part of the interface

Forms need more care than we give them

Dialogs are traps unless designed carefully

Do not use color alone

Automated tests are a floor

The human checklist

Final thought

Sources

CSS Got Good While You Were Installing More Libraries

The new default: check the platform first

Container queries change component design

:has() makes parent-aware styling practical

Cascade layers make CSS less fragile

Subgrid fixes a real layout problem

Fluid type without a framework

Use Baseline thinking

The library decision checklist

Final thought

Sources

TypeScript Won — Now Stop Using It Like Fancy JavaScript

Types should protect boundaries

Replace vague shapes with domain language

Use branded types for dangerous strings

Prefer discriminated unions over boolean soup

Validate runtime data

Use satisfies for configuration

Avoid type theater

The practical checklist

Final thought

Sources

Cabal for Android: My First Native Kotlin P2P Chat App Reaches Its First Early Version

What is Cabal for Android?

From React Native exploration to native Kotlin

Why Kotlin?

What is included in this first version?

What I learned while building it

1. Real apps teach faster than tutorials

2. Kotlin makes Android development feel focused

1. The Inline Edit (`Cmd+I` / `Ctrl+I`)

2. Full Project Context (`@codebase`)

`:has()` makes parent-aware styling practical

Use `satisfies` for configuration