DEV Community: 𝗝𝗼𝗵𝗻

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

The AI Code Review Checklist I Use Before Merging Any TypeScript PR

𝗝𝗼𝗵𝗻 — Thu, 30 Apr 2026 10:40:00 +0000

AI can write code quickly.

That is no longer the interesting part.

The interesting part is what happens after the code is generated.

Because in real projects, the bottleneck is rarely “how do we get code faster?”
It is usually:

Is this correct?
Does it match the architecture?
Does it handle edge cases?
Is it safe to merge?
Can someone else maintain it next month?

That is why I stopped treating AI output like finished code.

Now I treat it like a draft that needs a reliable review system.

This is the checklist I use before I merge any AI-generated TypeScript PR.

Not a theoretical checklist.
A practical one.

1. Can I explain the change in one sentence?

Before I look at the code, I force myself to summarize the PR in one sentence.

For example:

“This change validates uploaded image metadata before saving records to the database.”

If I cannot describe the change clearly, one of two things is probably true:

the PR is doing too much
the code is hiding the real intent

AI often produces code that looks organized while actually mixing multiple concerns.

If the purpose is fuzzy, I stop there and split the change.

2. Does the code match the requested scope?

AI loves to be helpful.

Sometimes too helpful.

It will often:

rename unrelated variables
refactor nearby code
introduce “small improvements”
create utility functions nobody asked for
solve adjacent problems

That makes review harder.

So one of my first checks is simple:

Did the model change only what needed to change?

If a PR was supposed to fix one validation bug but now touches eight files, I get suspicious immediately.

A good AI-generated PR is usually narrower than you think.

3. Are the boundaries explicit?

For TypeScript projects, this is one of the biggest signals of quality.

I look for clear boundaries:

input types
output types
domain models
DTOs
API contracts
validation layers

AI-generated code is much easier to trust when the edges are visible.

Bad sign:

async function saveUser(data: any) {
  // ...
}

Better:

interface CreateUserInput {
  email: string;
  displayName: string;
}

interface CreateUserResult {
  id: string;
  email: string;
  displayName: string;
}

async function saveUser(data: CreateUserInput): Promise<CreateUserResult> {
  // ...
}

If the AI patch adds logic without tightening the contract, I usually improve the boundary before I approve the implementation.

4. Did the AI generate code, or did it generate a new abstraction?

This matters a lot.

Sometimes AI gives you useful implementation.
Sometimes it gives you a brand new architecture you did not ask for.

Watch for:

extra layers
generic helpers
“reusable” wrappers
configuration systems
class hierarchies for simple logic
abstraction before repetition actually exists

A useful question here is:

Would I still create this abstraction if a human teammate had not suggested it?

If the answer is no, I remove it.

AI-generated code often becomes bloated not because it is broken, but because it is too eager to generalize.

5. Is there a test for the thing that actually changed?

I do not just ask, “Are there tests?”

I ask:

Is there a test for the exact behavior this PR claims to fix or add?

That means:

one test for the happy path
one test for the expected failure mode
one test for the edge case that is easiest to miss

If the PR fixes a parsing bug, I want a parsing test.
If it changes authorization logic, I want an authorization test.
If it adds fallback behavior, I want a test that proves the fallback works.

AI often writes tests that mirror the implementation too closely.

So I look for tests that verify behavior, not just structure.

6. Does the code fail safely?

A surprising amount of AI-generated code handles success better than failure.

So I explicitly review:

missing values
invalid input
timeouts
third-party failures
null and undefined cases
partial success scenarios
retries
logging
user-facing error messages

I ask myself:

What happens if this dependency is down?
What happens if the payload shape changes?
What happens if this field is missing?
What happens if the operation succeeds halfway?

If the answer is “the app probably throws something weird,” the PR is not ready.

7. Are runtime checks present at the system edges?

TypeScript is great, but it does not validate runtime data by itself.

So any AI-generated code that touches:

request bodies
query parameters
local storage
database results
webhooks
environment variables
third-party APIs

should make me ask:

Where is the runtime validation?

Types help inside the codebase.
Validation protects the boundary.

For example:

import { z } from "zod";

const CreatePostSchema = z.object({
  title: z.string().min(1),
  body: z.string().min(1),
  tags: z.array(z.string()).default([]),
});

type CreatePostInput = z.infer<typeof CreatePostSchema>;

function parseCreatePostInput(input: unknown): CreatePostInput {
  return CreatePostSchema.parse(input);
}

If AI writes strongly typed code without validating incoming data, it creates a false sense of safety.

8. Are names better after the change — or worse?

AI can produce valid code with terrible naming.

And bad names are expensive because they survive code review surprisingly often.

So I check:

function names
variable names
type names
file names
booleans
enum values
error messages

I want names that reflect the domain, not the implementation trick.

Bad:

const dataProcessorManager = createHandler();

Better:

const invoiceRetryScheduler = createRetryScheduler();

When naming gets vague, maintainability drops fast.

9. Does the PR introduce duplicate logic?

AI often rewrites something that already exists somewhere else in the codebase.

That creates:

near-duplicate validators
inconsistent helpers
slightly different parsing functions
multiple ways to do the same thing

So I always scan for duplication before approving.

My rule is simple:

if the logic already exists, reuse it
if the existing abstraction is bad, improve it
do not allow AI to create parallel versions of the same idea

Duplicate code is especially dangerous when it looks clean.
It feels harmless at first and becomes expensive later.

10. Would I be comfortable debugging this at 2 AM?

This is one of my favorite review questions.

Because code can be technically correct and still be operationally terrible.

I look for:

meaningful logs
useful error messages
predictable branching
obvious control flow
easy-to-trace data transformations
no “magic” hidden in helpers

If production breaks, will this code help the next person understand what happened?

Or will it force them to reverse-engineer AI-generated cleverness under pressure?

If debugging would be painful, I simplify the code before merge.

11. Is the security model still intact?

Any AI-generated PR that touches:

auth
permissions
tokens
cookies
headers
uploads
database access
redirects
HTML rendering
shell commands

gets a slower review.

I specifically check:

authorization, not just authentication
input handling
secret leakage
unsafe defaults
overly broad permissions
accidental exposure of internal fields
client/server boundary mistakes

I do not trust “looks secure.”

I want the security assumptions to be obvious in the code.

12. Can I roll this back easily?

This final check is underrated.

Even a good change can fail in production.

So before merging I ask:

is the change isolated?
is it behind a flag?
can it be reverted cleanly?
does it change data shape or persistence behavior?
does it create migration risk?
does it depend on coordinated deployment?

AI makes it easy to create larger patches than necessary.
Rollback thinking forces the patch back into a safer shape.

My quick merge rubric

If I need a fast decision, I use this simple rubric.

I merge when:

the scope is narrow
the intent is obvious
the boundaries are typed
runtime input is validated
tests prove the claimed behavior
failure paths are handled
naming is clear
security assumptions are visible
rollback is simple

I request changes when:

the PR does more than requested
the code adds unnecessary abstractions
tests are shallow
boundary validation is missing
names are vague
duplicate logic appears
debugging would be painful
the operational or security story is unclear

Final thought

AI can absolutely make teams faster.

But speed only matters if the output is reviewable, understandable, and safe to ship.

That is why I do not ask:

“Did AI write this?”

I ask:

“Would I still approve this if I had to own it in production?”

That single question has improved my reviews more than any tool setting.

If you are using AI heavily in your TypeScript workflow, build a checklist like this one.

It does not have to be identical.

It just has to be consistent.

Because the real productivity gain is not generated code.

It is generated code that survives review without creating future pain.

I recommend this!

𝗝𝗼𝗵𝗻 — Tue, 28 Apr 2026 16:37:34 +0000

Ready-to-use markdown template

Giorgi Kobaidze

Apr 26

15 Essential Sections Every README Needs: Give Your Project What It Deserves

#documentation #opensource #tutorial #development

161

11 min read

How I Started Learning Kotlin by Building a Real Android App

𝗝𝗼𝗵𝗻 — Wed, 22 Apr 2026 09:20:00 +0000

For a long time, Kotlin was one of those technologies I kept meaning to learn “properly.”

You probably know the feeling.

You read a few examples.

You understand the syntax.

You save a few tutorials.

You tell yourself you’ll build something with it “soon.”

And then nothing happens.

That was me for a while.

The problem wasn’t that Kotlin looked hard.

The problem was that learning it in isolation felt abstract.

I could read about:

null safety,
data classes,
coroutines,
when,
extension functions,

but none of it really stuck until I had a reason to use it inside a real Android app.

That’s when things changed.

Instead of trying to “finish a Kotlin course,” I decided to learn Kotlin by building something real — small enough to complete, but real enough to force me to understand how Android development actually works.

This post is about what that approach taught me, what slowed me down, and what I’d focus on first if I started learning Kotlin again today.

Why I chose to learn Kotlin by building instead of studying longer

At some point I realized I was consuming too much “learning material” and not enough actual friction.

And friction is where real learning starts.

It is easy to feel productive when you are:

reading docs,
watching tutorials,
highlighting syntax,
copying code examples.

But you don’t really understand a language until you hit questions like:

How should I structure this screen?
Where should this logic live?
Why is this nullable?
Why does this state not update the way I expected?
What is the most Kotlin-like way to write this instead of just translating Java or JavaScript habits?

Building an app forces those questions to happen naturally.

It also gives you a much better feedback loop:

write code,
break something,
fix it,
understand one concept more deeply,
repeat.

That loop taught me more than another week of passive learning would have.

The kind of app I built

I did not start with a big idea.

I didn’t try to build:

a full social app,
an e-commerce platform,
a chat system,
or a feature-packed productivity tool.

That would have been a mistake.

Instead, I picked something small and realistic:
a simple Android app with a few clear screens, local state, user input, and enough structure to feel like a real product.

That mattered a lot.

A good beginner project should be:

small enough to finish,
useful enough to stay motivating,
and complex enough to teach real patterns.

The goal is not to impress people with scope.

The goal is to create a project that forces you to use:

Kotlin syntax in real conditions,
Android UI structure,
state handling,
user interactions,
navigation,
and a bit of architecture.

That’s where the language starts making sense.

What helped me most when learning Kotlin

A few things made a huge difference early on.

1. Writing Kotlin every day, even in small amounts

I learned very quickly that consistency mattered more than long study sessions.

A focused 30–45 minutes of building something real helped me much more than occasionally spending 4 hours jumping between tutorials.

Kotlin started to feel natural only after repeated exposure:

writing functions,
handling nullable values,
creating data models,
wiring UI interactions,
refactoring small pieces of code.

At first, even simple things felt slower than they should.

But that’s normal.

The important part was not speed.

It was repetition.

2. Accepting that Kotlin is not just “better Java”

This was one of the biggest mental shifts.

If you come from another language, especially something like Java, JavaScript, or TypeScript, it is tempting to treat Kotlin as “the same thing with nicer syntax.”

That mindset slows you down.

Kotlin becomes much more enjoyable when you stop translating your old habits directly and start asking:

What is the idiomatic Kotlin way to do this?
Why does this language encourage immutability here?
Why is null handling so explicit?
Why do data classes feel so natural in app development?

The more I leaned into Kotlin as its own language, the easier it became to write cleaner code.

3. Building features instead of collecting concepts

At the beginning, I thought I needed to “learn coroutines,” “learn data classes,” or “learn sealed classes” one by one.

That was not the best approach for me.

What worked better was learning those things inside real features.

For example:

user input taught me about state,
screen transitions taught me about navigation,
modeling items taught me about data classes,
error handling taught me about nullability,
asynchronous work pushed me toward coroutines.

That approach made the concepts feel useful immediately.

And useful concepts are easier to remember than isolated definitions.

What confused me the most at first

Learning Kotlin through a real Android project was helpful — but not frictionless.

A few things definitely slowed me down.

1. Null safety felt great… until I had to actually design around it

At first, null safety looked like one of Kotlin’s cleanest features.

And it is.

But it also forced me to become more deliberate.

Instead of casually passing values around and “handling it later,” I had to think earlier about:

what can actually be null,
what should be required,
what should have a default value,
and where I was making assumptions.

That was frustrating at first because it exposed weak decisions immediately.

But looking back, that was a good thing.

Kotlin was not making development harder.

It was making sloppy assumptions harder.

2. Android structure is part of the learning curve, not just Kotlin

This is important.

When you learn Kotlin for Android, you are not learning just one thing.

You are learning at least three layers at once:

Kotlin itself,
Android concepts,
and your chosen UI / architecture approach.

That means confusion is not always caused by the language.

Sometimes the real question is:

Is this a Kotlin issue?
an Android lifecycle issue?
a UI state issue?
a project structure issue?

Once I understood that, I stopped blaming Kotlin for every confusing moment.

A lot of beginner frustration actually comes from trying to learn the whole Android stack at once.

3. There is a difference between “it works” and “this is clean”

One of the biggest lessons was realizing how easy it is to build something that works… and how much harder it is to build something that still feels clean after the third or fourth feature.

Early in the project, I often wrote code like this:

directly inside the screen,
with too much logic in one place,
and without thinking much about separation of concerns.

That got me moving quickly, which was good.

But after a while, I could feel the cost:

harder refactors,
messier UI code,
less confidence when adding features.

That was actually one of the most valuable parts of the project.

It taught me that learning Kotlin is not just about syntax.

It is also about learning where code should live.

The Kotlin features that clicked fastest for me

Some Kotlin features made sense almost immediately once I used them in a real app.

Data classes

These were one of the quickest wins.

As soon as I started modeling app data, data classes felt obvious and useful.

They reduce boilerplate and make data easier to reason about.

`when`

This felt much cleaner than long conditional chains.

It became especially useful for handling UI states and branching logic in a more readable way.

Null safety

Even though it was frustrating at first, it made my code more intentional.

Once I stopped fighting it, I started trusting my code more.

Immutability by default

This changed how I thought about state.

When building UI, predictable state matters a lot.

Kotlin nudged me toward better habits there.

Extension functions

These made code feel more expressive once I understood where they were actually useful.

Not “clever” useful — but genuinely cleaner in small repeated patterns.

What I would focus on first if I started again

If I had to restart from zero today, I would not try to learn everything.

I would focus on this order:

1. Core Kotlin basics

variables
functions
classes
nullability
collections
control flow

2. Kotlin features that matter quickly in apps

data classes
when
immutable patterns
simple extension functions

3. Basic Android app flow

screens
user input
state
navigation
local data

4. Code organization

separating UI from logic
keeping files readable
avoiding giant screens or giant classes

5. Then only later: deeper architecture and advanced patterns

I would avoid over-optimizing too early.

The first milestone should not be:

“Build the perfect architecture.”

It should be:

“Build something working, understandable, and easy enough to improve.”

That makes everything else easier.

My biggest takeaway

The biggest thing I learned is this:

Kotlin became much easier once I stopped trying to “master Kotlin” and started trying to build something with it.

That shift changed everything.

A real app gave every concept a reason to exist.

Without a project, Kotlin was just a list of language features.

Inside a project, it became:

a way to model data,
a way to structure UI logic,
a way to write safer code,
and a way to think more clearly about app development.

That’s when learning started to feel real.

Final thoughts

If you are trying to learn Kotlin right now, my honest advice is:

Don’t wait until you feel “ready.”

Don’t try to complete every tutorial first.

Build something small.

Make it real.

Let the project expose the gaps in your understanding.

That is where the best learning happens.

Not when everything is clear.

But when the code forces you to ask better questions.

If you’re learning Kotlin too, I’d love to know:

What has been harder for you so far — the language itself, Android concepts, or figuring out how to structure a real app?

DEV Community: 𝗝𝗼𝗵𝗻

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

3. Native Android development has its own rhythm

4. Small milestones matter

Why this project matters to me

Repository and download

What comes next?

Final thoughts

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

Start with freshness

The user does not care about your cache

Cache by boundary, not by hope

Make invalidation boring

Avoid accidental personalization leaks

Use loading states intentionally

Debugging questions

The mental model

Final thought

Sources

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

A better default

The three kinds of UI

1. Content UI

2. Navigation UI

3. Interaction UI

The client component tax

Keep islands small

Stop fetching twice

Memoization is not architecture

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

Use `satisfies` for configuration

`when`