DEV Community: 𝗝𝗼𝗵𝗻

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

157

Comments 80

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?

NatureNode: An AI-Powered Biodiversity Research Tool for Earth Day

𝗝𝗼𝗵𝗻 — Sat, 18 Apr 2026 09:30:00 +0000

This is a submission for Weekend Challenge: Earth Day Edition

What I Built

NatureNode is a professional biodiversity research tool and Progressive Web App that transforms a smartphone photo into a comprehensive ecological dossier — instantly, in the field, with no backend and full offline capability.

Most identification apps give you a name and a pretty photo. NatureNode gives you what a field researcher actually needs:

🔬 Full scientific taxonomy — family, genus, species
🌍 Conservation status (IUCN scale) and native range
♻️ Ecological role — what this organism contributes to its ecosystem
🛡️ Protection guidelines — actionable tips to conserve what you found
📓 Specimen Journal — a persistent local database of all your discoveries
🗺️ Location tagging + one-tap Google Maps navigation

The design philosophy matched the ambition: dark botanical aesthetics, high information density, and interactions that feel deliberate — like a research dashboard, not a social app.

Demo

🌿 Live PWA: https://johnnylemonny.github.io/naturenode/

To try it: Get a free Gemini API key at Google AI Studio, paste it into the app, and upload any photo of a plant, insect, animal, or mushroom. Your key is stored securely in your browser — never on any server.

Code

johnnylemonny / naturenode

🌿 NatureNode: A premium Progressive Web App (PWA) for advanced biodiversity identification. Powered by Google Gemini AI, featuring professional field research tools, specimen journaling, and ecological conservation insights. Built as part of the DEV Weekend Challenge.

🌿 NatureNode

NatureNode is a professional biodiversity research and identification tool. Designed for field researchers and nature enthusiasts, it leverages state-of-the-art AI to transform simple photos into comprehensive ecological dossiers.

🌟 Key Features

Botanical Precision UI: A high-density, research-oriented design system using Tailwind CSS v4 and the OKLCH color model for superior visual clarity.
AI-Driven Identification: Powered by Google Gemini 3 Flash for instant, high-accuracy recognition of plants, animals, insects, and fungi.
Specimen Journal: A persistent, local history of all your discoveries, allowing you to build your own personal biodiversity database.
📱 PWA & Offline Support: Fully installable as a Progressive Web App. Designed to work in the field with robust offline capabilities.
🗺️ Manual Location Mapping: Easily log observation points by town or area name.
📍 Google Maps Integration: One-click navigation and mapping of find locations directly in Google Maps.
Ecological Insights…

View on GitHub

How I Built It

Architecture: Zero-Backend, Privacy-First PWA

The core constraint was: no backend, no running costs, no privacy compromise. Everything that isn't AI inference runs locally in the browser. The Gemini API call goes directly from the user's browser to Google's servers using their own key — a "Bring Your Own Key" model that is the most honest approach to privacy-first AI tooling possible.

User Browser
├── React 19 + TypeScript          # UI & state management
├── Vite 8 (Rolldown engine)       # Lightning-fast builds
├── Tailwind CSS v4 (OKLCH model)  # Design system with perceptual color
├── Vite PWA Plugin + Workbox      # Offline support & installability
└── @google/generative-ai SDK      # Direct browser → Gemini calls

Gemini Integration: Typed JSON Schema

The intelligence layer is engineered around Gemini's responseSchema API — instead of parsing or validating free-form AI text, the model is constrained to return exactly the data shape that TypeScript expects. Zero parsing errors, deterministic structure:

const responseSchema = {
  type: SchemaType.OBJECT,
  properties: {
    commonName:         { type: SchemaType.STRING },
    scientificName:     { type: SchemaType.STRING },
    conservationStatus: { type: SchemaType.STRING },
    ecologicalRole:     { type: SchemaType.STRING },
    protectionTips: {
      type:  SchemaType.ARRAY,
      items: { type: SchemaType.STRING }
    }
    // ...
  }
};

const model = genAI.getGenerativeModel({
  model: "gemini-3-flash-preview",
  generationConfig: {
    responseMimeType: "application/json",
    responseSchema,           // ← model is constrained to this shape
  },
});

This approach is more reliable than prompt-engineering your way to JSON and faster than asking the model to explain its reasoning. The result: sub-3-second identifications with zero unparseable responses.

Secure API Key Storage

GitHub's CodeQL scanner flagged clear-text storage of the user's key in localStorage. The fix: Base64 obfuscation with a generic storage key name. Not encryption — but it prevents the key from sitting as a plain string visible in browser dev tools, and satisfies static analysis:

const obfuscate   = (s: string) => window.btoa(unescape(encodeURIComponent(s)));
const deobfuscate = (s: string) => decodeURIComponent(escape(window.atob(s)));

// Save
localStorage.setItem("nn_secure_session", obfuscate(apiKey));

// Load
const raw = localStorage.getItem("nn_secure_session");
return raw ? deobfuscate(raw) : "";

PWA & Offline

Workbox precaches all static assets at build time — the shell, fonts, and full UI load instantly even with no connection. Only the Gemini API call requires internet, and the app communicates this clearly. The manifest enables full "Add to Home Screen" installability on both Android and iOS.

CI/CD Pipeline

Three GitHub Actions workflows run on every push:

Workflow	Tool	Purpose
`deploy.yml`	`actions/deploy-pages@v4`	Build → GitHub Pages (no branch needed)
`linter.yml`	Super-Linter slim v7	JS / TS / HTML / JSON quality gates
`codeql.yml`	CodeQL	Security vulnerability scanning

Prize Categories

🥇 Best Use of Google Gemini — Gemini 3 Flash Preview is the entire intelligence layer, used with typed JSON schema enforcement for production-grade, zero-parse AI responses delivered directly from browser to API.

5 Developer Trends That Actually Matter in 2026 (Not Just the Hype)

𝗝𝗼𝗵𝗻 — Thu, 16 Apr 2026 12:45:32 +0000

Every year, developers get flooded with trend lists.

Most of them are either too broad to be useful or too early to matter in real projects.

So instead of listing every shiny new thing, I want to focus on the shifts that are already changing how modern apps are built, shipped, and maintained right now.

Because 2026 does feel different.

GitHub’s latest Octoverse data says more than 1.1 million public repositories now use an LLM SDK, with 693,867 of those created in the last 12 months alone. It also reports that TypeScript became the most-used language on GitHub in August 2025, overtaking both Python and JavaScript. 1

That is not just noise. That is a signal.

Here are the five trends I think actually matter in 2026 — and what developers should do about them.

1. AI coding agents are moving beyond autocomplete

For a while, AI coding tools were mostly “fancy autocomplete.”

That is no longer the right mental model.

Anthropic’s 2026 Agentic Coding Trends Report argues that in 2025, coding agents moved from experimental tools to systems that can handle real implementation workflows, including writing tests, debugging, generating docs, and navigating large codebases. At the same time, the report notes an important nuance: developers may use AI in roughly 60% of their work, but they still report being able to fully delegate only 0–20% of tasks. 2

That means the real shift is not “AI replaces developers.”

The real shift is:

developers are becoming managers of execution loops.

Instead of asking:

“Can the tool write this function?”

we now ask:

“Can the agent plan this task?”
“Can it inspect the codebase safely?”
“Can it run tests and recover from failure?”
“Can it return something reviewable?”

What this means in practice

The best teams will stop treating AI as a tab in the IDE and start treating it as an async collaborator.

That changes what matters in your codebase:

clean file structure,
consistent naming,
reliable tests,
good docs,
and explicit constraints.

Messy code used to slow down humans.

Now it also slows down agents.

2. MCP is becoming the integration layer developers should pay attention to

One of the biggest shifts happening quietly is the rise of MCP — the Model Context Protocol.

Cloudflare describes MCP as an open standard that connects AI systems to external applications, comparing it to a “USB-C port for AI applications.” Vercel describes it similarly as a standard interface that lets LLMs communicate with external tools and data sources. 3 5

Why does that matter?

Because once agents become useful, the next bottleneck is tool access:

databases,
issue trackers,
deployment platforms,
logs,
docs,
cloud resources,
and internal APIs.

MCP is interesting because it reduces custom glue code and pushes the ecosystem toward a common contract.

And this is no longer theoretical.

Cloudflare explicitly supports building and deploying MCP servers. Vercel has its own official MCP server and documents support for clients including Claude, ChatGPT, Cursor, VS Code with Copilot, Codex CLI, Windsurf, and more. 3 4

What this means in practice

If you build developer tools, internal platforms, APIs, or anything that might be used by agents, you should already be asking:

Should this expose an MCP interface?
What tools would actually be safe and useful for an agent?
What permissions should be scoped tightly?
What tasks should remain human-only?

In 2026, “AI-ready” increasingly means “toolable by standards.”

3. Type safety and boring developer experience are becoming competitive advantages

One of the most underrated trends right now is that typed and predictable systems are becoming more valuable, not less.

GitHub’s Octoverse says TypeScript overtook both Python and JavaScript in August 2025 to become the most-used language on GitHub, calling it the most significant language shift in more than a decade. GitHub also ties that rise to agent-assisted coding, arguing that typed languages make production work more reliable. 1

This matches what many teams are noticing already:

When humans and agents work together, ambiguity becomes expensive.

That is why “boring” qualities are suddenly strategic:

strong types,
explicit contracts,
stable interfaces,
predictable scripts,
clear schemas,
readable errors.

If your stack is easy to reason about, it is easier to automate, test, review, and evolve.

What this means in practice

The question is not:

“What is the trendiest stack?”

The better question is:

“What stack minimizes ambiguity for both humans and machines?”

That is one reason TypeScript-heavy workflows feel stronger right now:

they reduce guessing,
improve refactors,
and make AI-assisted changes less fragile.

In 2026, good DX is no longer just a human experience.

It is also an agent experience.

4. Passkeys are moving from “nice idea” to default modern authentication

Authentication is also going through a real shift.

Passkeys are no longer just something security people talk about at conferences.

The FIDO Alliance describes passkeys as phishing-resistant credentials based on FIDO standards that let users sign in with the same process they use to unlock their device. FIDO also says passkeys lead to 20% more successful sign-ins over passwords, and reports that 53% of people have enabled passkeys on at least one account, while 22% enable them everywhere they can. 6

On the implementation side, Microsoft now documents passkeys in ASP.NET Core Identity, and MDN describes WebAuthn as a widely available browser capability that enables strong authentication with public key cryptography. 7 8

That makes passkeys relevant far beyond enterprise identity teams.

They now matter to:

SaaS builders,
indie hackers,
frontend engineers,
full-stack teams,
and anyone trying to improve signup/login conversion without weakening security.

What this means in practice

If you are building a modern app in 2026, authentication should probably be designed around:

passkeys,
OAuth/OIDC where appropriate,
and fewer custom password flows.

The old “email + password + reset flow + 2FA patchwork” setup is no longer the most compelling default.

The modern question is:

“How do I reduce friction and improve security at the same time?”

Passkeys are one of the few trends that genuinely do both.

5. Open source maintainership is changing because AI lowers contribution friction

One more trend that deserves attention: AI is increasing contribution volume, but not always contribution quality.

GitHub’s Octoverse reports record growth in repositories, pull requests, and commits, with more than 36 million new developers joining GitHub in the past year, more than 230 new repositories created every minute, and 43.2 million pull requests merged on average each month. 1

That growth is exciting — but it also creates pressure.

InfoQ, summarizing GitHub’s open source trend analysis, highlights a growing maintainer burden from low-quality AI-generated issues and pull requests, and argues that projects without clear written governance, contribution guidelines, and review expectations will struggle to scale sustainably. 9

What this means in practice

In 2026, if you maintain a public repository, your project needs more than code.

It needs:

contribution rules,
issue templates,
review expectations,
a clear roadmap,
and documentation that helps people help you.

Open source is becoming more accessible.

That is good.

But it also means maintainers need better systems, not just better instincts.

So what should developers actually do now?

If I had to turn these trends into a practical 30-day plan, it would look like this:

1. Upgrade how you use AI

Stop using AI only for snippets.

Start testing it on:

scoped feature implementation,
test generation,
documentation updates,
and repetitive refactors.

2. Audit your codebase for agent-friendliness

Ask:

Is the structure obvious?
Are scripts predictable?
Are errors readable?
Are tests reliable?

3. Learn the MCP mental model

Even if you do not build an MCP server this month, understand:

hosts,
clients,
servers,
permissions,
and where this fits in your stack.

4. Revisit authentication

If your product still treats passwords as the default forever-plan, it is time to reassess.

Passkeys are no longer “future tech.”

5. Treat repositories like products

If you maintain public code, improve:

README,
contribution docs,
labels,
issue templates,
and release notes.

Because in 2026, the quality of your repo operations matters almost as much as the quality of your code.

Final thought

A lot of trend posts focus on what is new.

The more useful question is:

what is already reshaping real developer workflows?

Right now, the answer looks something like this:

AI agents are becoming real collaborators,
MCP is becoming the connector layer,
typed systems are gaining strategic value,
passkeys are becoming practical default auth,
and maintainership is becoming more operational.

That is not just hype.

That is a workflow shift.

The developers who adapt fastest will not be the ones who try every new tool.

They will be the ones who build systems that are:

clearer,
safer,
more automatable,
and easier for both humans and machines to work with.

What trend are you actually seeing in your day-to-day work right now?

Is it AI agents, passkeys, TypeScript everywhere, better repo hygiene, or something else?

How to Build a Public Open-Source Project People Actually Want to Clone, Use, and Contribute To

𝗝𝗼𝗵𝗻 — Mon, 13 Apr 2026 12:42:18 +0000

Most public repositories do not fail because the code is bad.

They fail because:

nobody understands why the project exists,
it is hard to run locally,
the repository looks like an abandoned side experiment,
and there is no clear reason for anyone to come back a second time.

If you want to build public open-source projects that attract attention on GitHub, earn stars, and gain real users, you have to think about your repository as more than a folder of code.

You have to treat it like a public product.

In this article, I’ll show you how to build modern open-source projects so they:

look credible from the first visit,
are easy to run,
invite contributions,
and have a much better chance of growing organically.

1. Start with a problem, not with a stack

A very common mistake looks like this:

“I’m going to build a new project in Next.js / FastAPI / Rust / Bun to practice.”

That may be a fine learning project, but it rarely turns into a strong public project.

Repositories that have the best chance of getting traction usually solve one clear problem:

they save time,
simplify something,
automate something repetitive,
or show a modern, opinionated way to build something useful.

Better ideas than “another starter”:

a starter with a real-world use case,
a boilerplate for a specific product type,
a tool that solves a small but frequent developer pain point,
a team-ready repository template,
a dashboard, generator, CLI, integration, or mini-SaaS released as open source.

A good rule of thumb:

If you can’t describe the project in one sentence without naming technologies, the idea is probably still too vague.

Instead of:

“This is a project built with React, Node, Prisma, and Docker.”

Say:

“This is an open-source starter for building admin panels with authentication, roles, billing, and deployment already set up.”

People click on problems.

Not on stacks.

2. Build a small but complete vertical slice

A public project does not need to be huge.

It needs to feel complete.

That is a big difference.

It is far better to show:

working authentication,
one clean core workflow,
solid UI,
sensible folder structure,
documentation,
and a simple deployment path,

than to show 27 half-finished features.

The most shareable open-source projects are often the ones that create this feeling quickly:

“Okay, this works. I can see how I would use this.”

That’s why modern public apps should include:

clear onboarding,
a demo or screenshots,
fast local setup,
sample data,
a useful .env.example,
and one obvious way to run the project.

If someone needs 40 minutes just to reach the first useful screen, you lose most potential users.

3. Treat your README like a landing page

In practice, your README is your project’s homepage.

That is where visitors decide, often within seconds:

whether to stay or leave,
whether to star the repo,
whether to clone it,
or whether to close the tab.

A good README does not begin with:

“Project X is a modern application that aims to…”

It begins with a clear value proposition.

What your README should include near the top

1. A one-line pitch

Make it obvious:

what it is,
who it is for,
and why it matters.

Example:

An open-source SaaS starter for building modern web apps with auth, billing, roles, and deployment built in.

2. A screenshot, GIF, or live demo

People understand software much faster when they can see it.

If it’s an application, show:

the dashboard,
onboarding,
settings,
or the core workflow.

3. A “why this exists” section

Briefly explain:

what problem you are solving,
how the project is different,
when someone should use it.

4. A fast start section

Keep it short and practical:

clone,
install,
env,
run.

5. Key features

Not every feature.

Only the ones that actually communicate the value.

6. A roadmap

People are more likely to follow a project when they can see where it is going.

7. A contributor section

Even a short one helps.

It should be obvious how someone can get involved.

A README does not need to be long.

It needs to be clear, concrete, and easy to scan.

4. A public repository has to inspire trust

A lot of repositories look promising at first glance.

Then you open them and discover:

no license,
no idea whether the code can be used,
no contribution rules,
no issue templates,
no signal that the project is actively maintained.

If you want people to take your project seriously, you need the trust layer of open source.

At minimum, have:

README.md
LICENSE
CONTRIBUTING.md
CODE_OF_CONDUCT.md
SECURITY.md
issue and pull request templates
a meaningful repository description

These are the details that separate:

“I uploaded some code” from
“I’m building a project people can join.”

5. Optimize the first five minutes

The most important moment is not when someone stars your repo.

The most important moment is when someone tries to run it locally.

If they hit:

missing environment variables,
outdated setup instructions,
confusing scripts,
broken migrations,
or secrets hidden in config files,

they are usually gone.

That’s why you should test your project as if you were a stranger discovering it for the first time.

My simple pre-release checklist

Before making a repo public, I ask:

Can a new person run this without asking me questions?
Does the README answer the most obvious setup questions?
Is the configuration predictable?
Are the error messages understandable?
Do sample data or seed scripts help show value quickly?
Are the script names obvious?
Can this project run on a clean machine without guesswork?

This usually matters more than one more feature.

6. Package the repository like a product

Strong public projects are not only well-built.

They are also well-packaged.

If you want more visibility:

choose a clear repository name,
write a sharp description,
use relevant tags/topics,
add a social preview image,
publish real releases,
show progress through changelogs and updates.

This is especially important for:

modern web apps,
starters,
boilerplates,
developer tools,
templates,
and infrastructure projects.

People often judge project quality from the repository page itself:

is the name clear,
is the description useful,
is the value obvious,
does the project look active?

Your code can be excellent and still get ignored if the repository looks neglected.

7. Build community around the problem, not just the code

A lot of people think open source is only about pull requests.

That is too narrow.

People can add value in many ways:

reporting bugs,
suggesting features,
improving documentation,
testing edge cases,
sharing feedback,
explaining how they use the project.

That is why you should create a space not only for code changes, but for discussion and learning.

Helpful tools include:

issue templates,
labels like good first issue,
help wanted,
a public roadmap,
a list of contribution ideas,
an FAQ,
discussion threads,
or a feedback board.

The less friction people feel, the more likely they are to participate.

8. Publish early, but do not publish chaos

“Ship early” is good advice.

But “make it public early” does not mean:

“Throw everything online before it makes sense.”

Before you promote a project, make sure it is at least:

understandable,
runnable,
documented,
and safe to share publicly.

This matters even more if you are building in public on:

X,
LinkedIn,
DEV,
Reddit,
Hacker News,
newsletters,
or YouTube.

One of the most common mistakes in open source is promoting a project too early:

before the README is useful,
before setup works,
before the value proposition is clear.

The result?

Traffic arrives, but it does not turn into:

stars,
watchers,
issues,
contributors,
or real users.

It is better to publish a week later and make a strong first impression.

9. Think repo-first for modern apps

If you are building a modern app in public, your repository is part of the product.

It does not just store code. It:

sells the idea,
documents decisions,
builds trust,
shows quality,
and invites people in.

A modern repository should answer these questions immediately:

What does this do?
Why does it exist?
How do I run it?
How do I use it?
How do I report a problem?
How do I contribute?
What direction is the project going?

If those answers are visible from the beginning, your repository starts working for you even when you are offline.

10. A simple checklist before publishing on GitHub

Use this as a lightweight definition of done for any public project.

Product

[ ] The project solves a specific problem
[ ] There is a clear use case to show
[ ] The value can be explained in one or two sentences

Repository

[ ] The README is clear and concrete
[ ] There is a screenshot, GIF, or demo
[ ] There is a LICENSE
[ ] There is a CONTRIBUTING.md
[ ] There is a CODE_OF_CONDUCT.md
[ ] There is a SECURITY.md
[ ] Issue and PR templates are ready

Developer Experience

[ ] There is an .env.example
[ ] Setup works from zero
[ ] Commands are simple and predictable
[ ] There is seed or sample data
[ ] The project runs without guesswork

Visibility

[ ] The repo has a good description
[ ] The repository name is easy to understand
[ ] Relevant tags/topics are added
[ ] A first release is prepared
[ ] The next steps are visible

Final thought

Open source does not win on code quality alone.

It wins through a combination of:

usefulness,
clarity,
trust,
easy onboarding,
and consistent visible progress.

If you want to build public projects that actually grow, do not just ask:

“How do I write better code?”

Also ask:

“Will a random developer on the internet understand this project, run it, and want to come back?”

Because that is where real public open source begins.

If you are building public repositories yourself, I’d love to know:

What kills open-source projects fastest in your experience — scope creep, weak onboarding, poor README, inconsistent updates, or something else?

Working on Cabal v3: reviving a P2P mobile chat app with React Native

𝗝𝗼𝗵𝗻 — Mon, 13 Apr 2026 08:33:42 +0000

Right now I’m working on Cabal v3 — a modern peer-to-peer chat app for Android built on top of the Cable protocol.

This project is both a modernization and a revival of the older cabal-mobile effort:
https://github.com/cabal-club/cabal-mobile

The original project was created to let people chat with the P2P swarm on mobile devices, and its last tagged release (1.0) goes back to June 17, 2018. Later, the project README pointed development toward a v2 branch, so the idea of evolving the mobile client has already been part of its history. 1 2 3

What makes this especially interesting to me is the protocol underneath it.

Cable is a lightweight protocol for peer-to-peer private group chats, where peers communicate directly instead of depending on a centralized server. The protocol is designed around encrypted communication between equal peers and the exchange of cryptographically signed chat data. 4 5

For me, this is not just an interesting open-source revival.

It’s also a really good opportunity to learn more about building a mobile frontend with React Native while working on something rooted in decentralized communication.

So this project sits at a really interesting intersection for me:

mobile development
React Native
Android
open source
and peer-to-peer systems

Still early, but I’m excited to keep pushing it forward.

From NASA Exoplanet Query to ExoVault: Building a Better Data Exploration Experience

𝗝𝗼𝗵𝗻 — Sat, 11 Apr 2026 13:25:13 +0000

Other project idea I recently decided to build in public was inspired by the NASA Exoplanet Query prompt from the App Ideas repository.

That project eventually became ExoVault:
https://github.com/johnnylemonny/ExoVault

What started as a structured data query idea turned into something much more interesting for me:
a more polished, cinematic interface for exploring NASA exoplanet archive data.

The original prompt

The NASA Exoplanet Query idea is already a really good challenge.

It’s built around:

working with NASA archive data,
loading CSV efficiently,
minimizing delays at startup,
and building a query interface that lets users filter exoplanet data by fields like discovery year, method, host name, and facility.

That made it appealing right away.

It wasn’t just about rendering data.
It was about thinking carefully about:

ingestion,
structure,
search,
and presentation.

What pulled me into this idea

What interested me most wasn’t only the dataset.

It was the possibility of taking something that could have been “just a query tool” and pushing it toward a better exploration experience.

I kept thinking:

What if this felt less like a utility screen and more like a discovery product?

That question shaped the direction of the whole project.

Instead of building only the minimum query UI, I wanted to create something that felt more deliberate, more visually refined, and more enjoyable to explore.

That’s where ExoVault came from.

How ExoVault evolved

In my version, the project became a more premium archive explorer built around:

a custom CSV-to-JSON data pipeline,
a high-performance frontend,
compare mode for exoplanetary systems,
glassmorphic visuals,
and a more cinematic browsing experience.

I built ExoVault with:

Astro
React
Tailwind CSS
TypeScript

and used a custom data pipeline to process NASA’s raw CSV into optimized JSON payloads.

That part was especially satisfying because it made the project feel more complete end-to-end:
not just UI, not just data handling, but both working together.

What I wanted the project to feel like

One of my goals with ExoVault was to make exploration feel intentional.

Not just:

filter,
search,
render rows,
done.

I wanted the archive to feel like something people would actually want to browse.

That meant paying attention to things like:

visual hierarchy,
transitions,
compare flow,
and how the interface frames the data.

I think there’s a big difference between “showing information” and “creating a discovery experience.”

This project made me think a lot about that difference.

What I learned while building it

A few things stood out while working on ExoVault:

1. Data projects become more interesting when presentation is treated seriously

A structured dataset can feel dry or compelling depending on how the experience is shaped.

2. Prompt-based ideas are often stronger than they first appear

The original App Ideas brief gave me a very solid technical core.
The interesting part came from deciding how to evolve it.

3. Frontend polish matters even in data-heavy apps

If the interface feels flat, the whole experience feels flatter too.
Good data presentation is also a UX problem.

4. Public repos push me toward stronger execution

Knowing the project would live openly on GitHub made me care more about the quality of the pipeline, repo structure, documentation, and overall presentation.

Why I like using structured prompts as a starting point

I think structured prompt repositories are one of the best ways to build momentum — especially if you don’t treat them as the finish line.

That’s how I’m trying to use them.

Not as instructions to copy,
but as a framework to build from.

The prompt gives me:

direction,
constraints,
and technical focus.

Then the real project begins when I start asking:

how should this feel?
what should be improved?
what makes this worth sharing publicly?
how can this become more than the base brief?

ExoVault is probably one of my clearest examples of that so far.