DEV Community: 𝗝𝗼𝗵𝗻

7 New JavaScript Features in ECMAScript 2026 That Replace Everyday Workarounds

𝗝𝗼𝗵𝗻 — Tue, 14 Jul 2026 12:20:00 +0000

JavaScript receives a new specification every year, but not every release changes the way we write everyday application code.

ECMAScript 2026 is different.

The 17th edition of the ECMAScript specification was approved by Ecma International on June 30, 2026. It introduces several small but highly practical APIs that replace patterns many of us have been writing manually for years.

No new framework is required. No architectural rewrite is necessary. These are language-level improvements for frontend applications, Node.js services, libraries, APIs, data pipelines, and developer tools.

In this article, we will explore seven additions:

Array.fromAsync()
Map.prototype.getOrInsert()
Iterator.concat()
Error.isError()
Math.sumPrecise()
Native Base64 and hex support for Uint8Array
JSON source text access and raw JSON

Let us look at the problems they solve and where they can be useful in real projects.

Before using a new API in production, check support in your target browsers and JavaScript runtimes. Feature detection, progressive enhancement, or a compatible fallback may still be appropriate.

1. Convert async data into an array with `Array.fromAsync()`

JavaScript has supported Array.from() for synchronous iterables for years.

const values = Array.from(new Set([1, 2, 2, 3]));

console.log(values);
// [1, 2, 3]

However, Array.from() cannot consume an asynchronous iterable.

Until now, collecting values from an async generator usually required a manual loop:

async function* loadPages() {
  yield await fetchPage(1);
  yield await fetchPage(2);
  yield await fetchPage(3);
}

const pages = [];

for await (const page of loadPages()) {
  pages.push(page);
}

With ECMAScript 2026, we can express the same intention more directly:

const pages = await Array.fromAsync(loadPages());

Array.fromAsync() can also apply a mapping function while collecting the values:

const titles = await Array.fromAsync(
  loadPages(),
  page => page.title
);

A simplified full-stack example could collect results from a paginated API:

async function* fetchAllUsers() {
  let page = 1;

  while (true) {
    const response = await fetch(`/api/users?page=${page}`);
    const result = await response.json();

    for (const user of result.users) {
      yield user;
    }

    if (!result.nextPage) {
      return;
    }

    page = result.nextPage;
  }
}

const activeUsers = await Array.fromAsync(
  fetchAllUsers(),
  user => ({
    id: user.id,
    name: user.name,
    active: user.lastSeenAt !== null
  })
);

Why it matters

This is useful when working with:

paginated API responses,
database cursors,
asynchronous generators,
streamed records,
file-processing pipelines,
values that resolve asynchronously.

The main benefit is readability. The code clearly says: consume this asynchronous source and return an array.

One important consideration

An array keeps every collected item in memory. If the source can produce a very large or unlimited number of values, process items incrementally with for await...of instead.

2. Initialize Map values with `getOrInsert()`

A common Map pattern is to check whether a value exists, create it if necessary, and then retrieve it.

For example, grouping products by category often looks like this:

const productsByCategory = new Map();

for (const product of products) {
  if (!productsByCategory.has(product.category)) {
    productsByCategory.set(product.category, []);
  }

  productsByCategory.get(product.category).push(product);
}

ECMAScript 2026 adds Map.prototype.getOrInsert():

const productsByCategory = new Map();

for (const product of products) {
  productsByCategory
    .getOrInsert(product.category, [])
    .push(product);
}

If the key exists, the method returns the current value. If it does not exist, the provided default is inserted and returned.

There is also getOrInsertComputed(), which calculates the value only when a key is missing:

const userCache = new Map();

function getUserProfile(userId) {
  return userCache.getOrInsertComputed(
    userId,
    () => createUserProfile(userId)
  );
}

This is especially useful when creating the default value is expensive.

const reportCache = new Map();

function getReport(projectId) {
  return reportCache.getOrInsertComputed(projectId, () => ({
    projectId,
    createdAt: new Date(),
    rows: buildInitialReportRows(projectId)
  }));
}

Equivalent methods are also available for WeakMap.

Why it matters

These methods make several common patterns more concise:

grouping API results,
memoization,
per-request caches,
dependency containers,
graph construction,
counters and indexes,
metadata associated with objects.

They also communicate intent better than separate has(), set(), and get() calls.

3. Combine lazy sequences with `Iterator.concat()`

Suppose an application receives items from multiple sources:

function* localArticles() {
  yield { id: 1, source: "local" };
  yield { id: 2, source: "local" };
}

function* partnerArticles() {
  yield { id: 3, source: "partner" };
  yield { id: 4, source: "partner" };
}

Previously, we might have created an array:

const articles = [
  ...localArticles(),
  ...partnerArticles()
];

This immediately consumes both iterators and stores all their values in memory.

ECMAScript 2026 provides Iterator.concat():

const articles = Iterator.concat(
  localArticles(),
  partnerArticles()
);

for (const article of articles) {
  console.log(article);
}

The combined iterator remains lazy. Values are requested only when the consumer needs them.

It can also combine arrays and other synchronous iterables:

const navigationItems = Iterator.concat(
  ["Home", "Articles"],
  getProjectLinks(),
  ["Settings"]
);

Why laziness is useful

Lazy iteration can help when:

inputs are large,
producing an item requires computation,
the consumer may stop early,
allocating an intermediate array is unnecessary.

For example:

const allCandidates = Iterator.concat(
  getPrimaryCandidates(),
  getFallbackCandidates(),
  getArchivedCandidates()
);

for (const candidate of allCandidates) {
  if (candidate.matches(query)) {
    console.log("Found:", candidate);
    break;
  }
}

The later sources may never be evaluated if an earlier match is found.

4. Detect genuine Error objects with `Error.isError()`

Most JavaScript developers use instanceof to determine whether a caught value is an error:

try {
  await saveDocument();
} catch (value) {
  if (value instanceof Error) {
    console.error(value.message);
  }
}

This works in many applications, but it can be unreliable when the error comes from a different JavaScript realm, such as:

an iframe,
another browser window,
certain VM environments,
isolated execution contexts.

Each realm can have a different Error constructor. An error created elsewhere may therefore fail the local instanceof Error check.

ECMAScript 2026 introduces Error.isError():

try {
  await saveDocument();
} catch (value) {
  if (Error.isError(value)) {
    console.error(value.message);
  } else {
    console.error("A non-Error value was thrown:", value);
  }
}

A reusable normalization helper becomes straightforward:

function normalizeError(value) {
  if (Error.isError(value)) {
    return value;
  }

  if (typeof value === "string") {
    return new Error(value);
  }

  return new Error("An unknown error occurred", {
    cause: value
  });
}

Why it matters

This API is particularly useful for:

component libraries,
iframe-based applications,
plugin systems,
test runners,
browser automation,
sandboxed code,
error-monitoring SDKs.

It gives the language a direct and explicit way to answer a surprisingly difficult question: is this value actually an Error object?

5. Sum floating-point values more accurately with `Math.sumPrecise()`

Floating-point arithmetic can lose precision, especially when values with very different magnitudes are added sequentially.

Consider this calculation:

const values = [1e16, 1, -1e16];

const total = values.reduce(
  (sum, value) => sum + value,
  0
);

console.log(total);
// Commonly 0, although the mathematical result is 1

The small 1 can disappear during intermediate floating-point operations.

ECMAScript 2026 adds Math.sumPrecise():

const total = Math.sumPrecise([
  1e16,
  1,
  -1e16
]);

console.log(total);
// 1

It accepts an iterable, so it can also work with data transformations:

const completedOrderValues = orders
  .filter(order => order.status === "completed")
  .map(order => order.total);

const revenue = Math.sumPrecise(completedOrderValues);

Or with a generator:

function* validMeasurements(rows) {
  for (const row of rows) {
    if (Number.isFinite(row.measurement)) {
      yield row.measurement;
    }
  }
}

const total = Math.sumPrecise(
  validMeasurements(dataset)
);

Important: this is not decimal arithmetic

Math.sumPrecise() reduces floating-point accumulation error, but JavaScript numbers are still IEEE 754 floating-point values.

For money, the safest approach is usually to store minor units as integers:

const pricesInCents = [1999, 2500, 349];

const totalInCents = pricesInCents.reduce(
  (sum, value) => sum + value,
  0
);

Use Math.sumPrecise() when you intentionally work with floating-point measurements, statistics, coordinates, scientific data, or mixed-magnitude values.

6. Encode and decode binary data without custom Base64 helpers

Web applications frequently need to convert binary data to Base64 or hexadecimal strings.

Common use cases include:

API payloads,
cryptographic data,
file chunks,
content hashes,
authentication challenges,
browser storage.

Historically, developers often combined btoa(), atob(), loops, buffers, or third-party helpers. Those approaches could be awkward, environment-specific, or unsafe for arbitrary binary data.

ECMAScript 2026 adds dedicated methods to Uint8Array.

Base64

const bytes = new Uint8Array([
  72, 101, 108, 108, 111
]);

const encoded = bytes.toBase64();

console.log(encoded);
// SGVsbG8=

Decode it again:

const decoded = Uint8Array.fromBase64(
  "SGVsbG8="
);

console.log(decoded);
// Uint8Array(5) [72, 101, 108, 108, 111]

Hexadecimal

const token = new Uint8Array([
  15, 160, 255
]);

console.log(token.toHex());
// 0fa0ff

And in the opposite direction:

const bytes = Uint8Array.fromHex(
  "0fa0ff"
);

A digest helper can now be written cleanly:

async function createSha256Hex(input) {
  const source = new TextEncoder().encode(input);

  const digest = await crypto.subtle.digest(
    "SHA-256",
    source
  );

  return new Uint8Array(digest).toHex();
}

Why it matters

These methods create a clearer, standardized path for binary conversion across JavaScript environments.

The code is easier to review because developers no longer need to recognize a custom chain of character conversions as “binary data to Base64.”

7. Preserve important JSON source information

JSON numbers are parsed into JavaScript Number values. This can cause information loss when the source contains an integer larger than JavaScript can represent safely.

const payload =
  '{"transactionId":123456789012345678901234567890}';

const result = JSON.parse(payload);

console.log(result.transactionId);
// The original integer may already have lost precision

ECMAScript 2026 extends the JSON.parse() reviver with access to the original source text.

const payload =
  '{"transactionId":123456789012345678901234567890}';

const result = JSON.parse(
  payload,
  (key, value, context) => {
    if (key === "transactionId") {
      return BigInt(context.source);
    }

    return value;
  }
);

console.log(result.transactionId);
// 123456789012345678901234567890n

The key detail is context.source. It shows the matched JSON source before the already-parsed Number value becomes the only available representation.

This is useful for:

database identifiers,
blockchain values,
high-precision API data,
large counters,
scientific datasets,
interoperability with systems using 64-bit integers.

ECMAScript 2026 also includes JSON.rawJSON(), which lets code provide validated raw JSON for primitive values during serialization.

const exactId = JSON.rawJSON(
  "123456789012345678901234567890"
);

const payload = JSON.stringify({
  transactionId: exactId
});

console.log(payload);
// {"transactionId":123456789012345678901234567890}

This offers more control over output that cannot be represented exactly as a regular JavaScript Number.

Use it carefully

Raw JSON is a precision and interoperability tool, not a general string-concatenation shortcut.

Only use validated values and keep the expected schema explicit.

A quick migration checklist

You do not need to refactor an entire codebase to benefit from ES2026.

Look for these existing patterns:

Manual async collection

const results = [];

for await (const item of source) {
  results.push(item);
}

Consider:

const results = await Array.fromAsync(source);

Repeated Map initialization

if (!map.has(key)) {
  map.set(key, createValue());
}

const value = map.get(key);

Consider:

const value = map.getOrInsertComputed(
  key,
  createValue
);

Array spreads used only to join iterables

const combined = [
  ...sourceA,
  ...sourceB
];

Consider a lazy sequence:

const combined = Iterator.concat(
  sourceA,
  sourceB
);

Cross-context error checks

value instanceof Error

Consider:

Error.isError(value)

Custom binary conversion helpers

customBytesToHex(bytes)

Consider:

bytes.toHex()

Large integers parsed from JSON

If an API returns integer values outside the safe Number range, consider parsing the original source into BigInt or a decimal representation.

How to use these features safely today

A feature being part of the ECMAScript standard does not guarantee that every browser, embedded webview, server runtime, or build target already supports it.

A simple feature check can help:

const supportsFromAsync =
  typeof Array.fromAsync === "function";

const supportsPreciseSum =
  typeof Math.sumPrecise === "function";

const supportsErrorCheck =
  typeof Error.isError === "function";

const supportsHex =
  typeof Uint8Array.prototype.toHex === "function";

For a production project:

Check your browser and runtime support matrix.
Test using the same versions as your deployment environment.
Add a fallback or polyfill where appropriate.
Avoid assuming that transpilation automatically provides new runtime APIs.
Upgrade dependencies and CI images deliberately.

Transpilers can transform syntax, but methods such as Math.sumPrecise() and Array.fromAsync() require runtime support or an implementation supplied by your application.

Final thoughts

ECMAScript 2026 is a good example of language evolution focused on practical improvements rather than dramatic syntax changes.

Its additions address familiar problems:

collecting asynchronous data,
initializing cached values,
combining lazy sequences,
identifying errors reliably,
reducing summation error,
converting binary data,
preserving JSON precision.

None of these features will replace your framework or redesign your architecture. That is exactly why they are valuable: they make ordinary JavaScript code shorter, clearer, and more expressive.

My first candidates for immediate adoption are:

Map.prototype.getOrInsertComputed() for caches and grouping,
Array.fromAsync() for finite asynchronous sources,
the new Uint8Array encoding methods for API and crypto work.

Which ECMAScript 2026 feature are you most likely to use first?

Sources and further reading

Connect with Me

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

💻 GitHub: johnnylemonny
✍️ DEV.to: johnnylemonny

This article was created with the help of AI

Passionaut: Turn Any Passion into an AI-Generated 3D Knowledge Atlas

𝗝𝗼𝗵𝗻 — Sat, 11 Jul 2026 13:15:00 +0000

This is a submission for Weekend Challenge: Passion Edition

What if learning about a passion felt less like reading a list of search results—and more like exploring a universe?

That question led me to build Passionaut, an AI-powered, interactive 3D knowledge atlas that transforms almost any passion or domain into an explorable constellation of concepts, sub-disciplines, projects, techniques, and connections.

Enter a topic such as Astrophysics, Mechanical Keyboards, or Procedural Generation, and Passionaut uses Google Gemini AI to generate a structured deep dive into that subject.

The generated knowledge is not presented as another wall of text.

Instead, it becomes a fully navigable 3D constellation.

🌌 Launch the live demo

What I Built

Passionaut is an interactive 3D knowledge graph designed to answer one question:

How deep does my passion go?

A user enters any passion, interest, or domain. Google Gemini then generates a structured map of the subject, including:

core concepts,
sub-disciplines,
important techniques,
practical projects,
useful tools,
and meaningful relationships between them.

Passionaut converts this information into an immersive 3D constellation rendered directly in the browser.

Every node represents part of the selected domain. Connections between nodes reveal how individual ideas belong to the larger knowledge landscape.

Users can navigate the constellation, inspect dynamically scaled 3D labels, select individual nodes, and open a deep-dive panel containing more information and an importance score.

The goal was not to create another linear learning checklist.

I wanted to make curiosity spatial.

Inspiration

People rarely discover a passion in a perfectly organized sequence.

One concept leads to another. A tool introduces a technique. A historical breakthrough reveals an entire discipline. A simple question opens a path toward ten more questions.

Passions behave less like lists and more like constellations: individual points become more meaningful when we can see the connections between them.

Search engines are excellent when we already know what to ask. But when entering an unfamiliar field, the more interesting question is often:

What exists inside this world, and where could I go next?

Passionaut was built to explore that question.

By combining generative AI with a spatial interface, the application turns an abstract and potentially overwhelming subject into a concrete environment that users can navigate.

Try it in four steps

Open the live application.
Enter your Google Gemini API key when prompted.
Search for a passion or domain.
Explore the generated 3D constellation.

Good topics to try include:

Astrophysics
Mechanical Keyboards
Procedural Generation
Game Development
Electronic Music
Robotics
Photography
Artificial Intelligence
Sustainable Architecture

Select a node to open its detail panel, then move through the graph to discover related ideas.

The application also remembers your five most recent successful searches, allowing you to return to a previously generated atlas.

Share an atlas

Passionaut supports shareable query links.

Click Copy Share Link after generating an atlas. The resulting URL contains the selected topic as a query parameter.

When another user opens the link, Passionaut automatically generates that specific atlas in real time.

For example, a shared link can point directly to an atlas for Astrophysics:

https://johnnylemonny.github.io/passionaut/?q=Astrophysics

About the API key

Passionaut follows a bring-your-own-key model.

Your Gemini API key is stored locally in your browser. The application is statically hosted and does not rely on a custom backend for storing API credentials.

A free Gemini API key can be created in https://aistudio.google.com/apikey.

Code

The complete source code is available on GitHub:

github.com/johnnylemonny/passionaut

Passionaut is open source and licensed under the MIT License.

If you find the project interesting, consider giving it a ⭐ on GitHub.

How I Built It

Passionaut is built around a pipeline that converts an unrestricted natural-language topic into structured data and then turns that data into an interactive environment.

1. Accepting an open-ended passion

The experience begins with a simple search input.

The user does not need to understand the structure of a field before exploring it. Discovering that structure is the purpose of the application.

The input can be broad, specific, technical, or creative.

2. Generating structured knowledge with Gemini

Passionaut uses Gemini 3.1 Flash-Lite through the @google/genai SDK.

Instead of asking Gemini for a conventional article, the application requests structured JSON describing the selected domain.

The generated data represents elements such as:

sub-disciplines,
concepts,
techniques,
projects,
descriptions,
importance values,
and relationships.

This distinction is essential.

A rendered knowledge graph cannot be built from an unstructured paragraph alone. It needs recognizable entities and connections that can be translated into nodes and links.

Gemini provides enough flexibility to generate these structures for completely different domains without requiring a manually curated database for every possible passion.

3. Converting the response into a graph

The structured Gemini response is transformed into graph data.

Individual concepts become nodes, while relationships between concepts become links.

Importance values can influence how prominently information appears in the visualization, helping users recognize the hierarchy inside a generated atlas.

This stage connects the AI layer with the visualization layer: Gemini defines the knowledge landscape, while the graph system determines how users experience it.

4. Rendering an interactive 3D constellation

The visualization is powered by:

Three.js
React Three Fiber
react-force-graph-3d
React Spring

Together, these technologies render the generated graph as a fully navigable 3D constellation.

Users can rotate the scene, change their viewing position, inspect connections, and select nodes.

Instead of presenting knowledge as a static hierarchy, the 3D layout communicates that every domain is a network of interconnected ideas.

5. Building dynamic 3D typography

A graph becomes difficult to use if its labels are too small, frequently overlap, or are cut off.

Passionaut uses dynamically sized 3D labels that float beside their corresponding nodes.

The label scale helps communicate importance while keeping concepts identifiable throughout the scene.

This was one of the most important usability considerations because the visualization needed to remain informative rather than becoming purely decorative.

6. Creating the deep-space interface

The interface was built with:

Next.js 16
React 19
Tailwind CSS v4
Lucide Icons
React Spring

I wanted the application to feel like a specialized instrument for navigating knowledge rather than a conventional dashboard.

The dark-space HUD, motion, suggestion chips, search history, and detailed node panel all support that direction.

The visual effects are designed to reinforce exploration without making the knowledge harder to read.

7. Synthesizing audio in the browser

Passionaut includes custom interaction sounds created with the native Web Audio API.

The application synthesizes effects such as:

ticks when hovering,
a D5 tone when selecting a node,
and sweeping sounds when starting a search.

These sounds are generated directly in the browser. No external audio asset library is required.

The audio layer makes the interface feel more responsive while preserving the application’s futuristic identity.

8. Managing state and recent searches

Application state is managed with Zustand.

Local storage persistence allows Passionaut to remember the five most recent successful atlases. This gives users a quick way to move between previously explored topics without maintaining a user account.

The Gemini API key is also kept locally in the user’s browser.

9. Generating shareable links

A generated atlas can be shared using a URL query parameter.

When a recipient opens a Passionaut link containing a query, the application reads the selected topic and generates the associated atlas.

This makes the subject itself shareable without requiring a backend database to permanently store every graph.

10. Deploying as a static application

Passionaut uses the Next.js static export workflow and is deployed on GitHub Pages.

The application does not require a dedicated application server. Users provide their own Gemini API key, and the browser communicates with the Gemini API to generate the requested knowledge structure.

This architecture keeps deployment simple and makes the project easy to host as a public demonstration.

Technical Stack

Here is the complete technical stack behind Passionaut:

Framework: Next.js 16 with App Router and static export
UI: React 19
Styling: Tailwind CSS v4
Icons: Lucide Icons
Animations: React Spring
3D rendering: Three.js and React Three Fiber
Graph visualization: react-force-graph-3d
State management: Zustand with local storage persistence
AI integration: Google Gemini through @google/genai
AI model: Gemini 3.1 Flash-Lite
Audio: Native Web Audio API
Deployment: GitHub Pages

Interesting Challenges

Making AI output visualization-ready

Natural-language output is flexible, but a graph requires predictable structure.

The generated information must be converted into entities and relationships that the visualization can reliably interpret.

This meant treating prompt design and structured output handling as parts of the application architecture—not as an isolated AI feature.

Supporting completely different passions

Astrophysics, mechanical keyboards, music, and game development have very different vocabularies and internal structures.

Passionaut needs to create a useful constellation for each domain without assuming that every subject can be represented in exactly the same way.

Gemini provides the flexibility to interpret each passion in context while still producing data for a common graph system.

Balancing complexity and readability

A dense 3D graph can look impressive while being practically impossible to use.

The challenge was to communicate the scale and interconnectedness of a passion without letting the visualization become meaningless visual noise.

Dynamic labels, node importance, navigation, and the detail panel all help preserve the graph’s utility.

Combining information with atmosphere

Passionaut is both a knowledge tool and an interactive audiovisual experience.

WebGL, animation, and Web Audio can make the application memorable, but they should never distract users from the generated concepts.

The guiding design principle was:

Every effect should make discovery feel better without getting in the way of discovery.

Running without a custom backend

Static deployment makes Passionaut easy to host, but it also requires a different approach to API access, state persistence, search history, and sharing.

The bring-your-own-key model and browser-based storage allow the application to remain fully static while still generating new atlases on demand.

Best Use of Google AI

I am submitting Passionaut for Best Use of Google AI.

Gemini is not an optional chatbot placed beside the main application. It is the knowledge engine that creates the environment the user explores.

Gemini 3.1 Flash-Lite transforms an unrestricted topic into structured JSON containing concepts, sub-disciplines, projects, techniques, importance values, and relationships.

That output directly determines:

which nodes appear,
how the nodes are connected,
which concepts receive greater visual importance,
what appears in the deep-dive detail panel,
and which paths of discovery are available.

Without Gemini, Passionaut would require a manually curated database for every supported domain.

With Gemini, the same visualization system can generate an atlas for subjects as different as astrophysics, mechanical keyboards, procedural generation, music, photography, and game development.

Gemini does not merely describe the universe.

Gemini helps create the universe that the user explores.

What I Learned

Building Passionaut reinforced an important idea:

AI becomes especially powerful when its output changes the interface itself.

A generated paragraph can be helpful, but generated structure can become a visualization, a simulation, a map, or an entire explorable environment.

In Passionaut, AI output is not the final presentation layer. It becomes material for the application.

I also learned that knowledge visualization is not only a rendering problem.

It requires decisions about:

information hierarchy,
relationships,
visual density,
label readability,
interaction feedback,
spatial navigation,
and where the user’s attention should go first.

The strongest results came from treating AI, 3D rendering, animation, sound, and interface design as parts of one connected system.

What’s Next

There are several directions I would like to explore next:

saving generated constellations permanently,
exporting knowledge maps,
comparing two related passions,
adding alternative non-3D navigation modes,
generating guided learning journeys,
improving keyboard navigation and accessibility,
expanding nodes into deeper sub-constellations,
adding collaborative exploration,
and allowing users to customize the depth and complexity of an atlas.

The direction I find most exciting is recursive exploration.

A user could select one concept inside a constellation and generate a completely new atlas around it. That would turn Passionaut into an almost endless journey through connected knowledge.

Final Thoughts

Passionaut began with a simple idea:

A passion is not a list. It is a universe of connected ideas.

Google Gemini provides the knowledge structure.

Three.js gives that structure a spatial form.

Web Audio adds a responsive layer of feedback.

Together, these technologies turn curiosity into something users can explore.

🌌 Try Passionaut

💻 Explore the source code

Next.js Finally Fixed Caching (And My Database Is Sighing in Relief)

𝗝𝗼𝗵𝗻 — Thu, 09 Jul 2026 13:02:00 +0000

I spent a miserable afternoon a while back debugging a production issue where a user's private financial dashboard was showing cached data from a completely different account. Why? Because Next.js 14 decided that a standard, innocent-looking fetch() call should be cached aggressively until the end of time unless you explicitly went out of your way to block it.

It was the ultimate frontend footgun.

Thankfully, the ecosystem listened. With the recent maturity and widespread production adoption of Next.js 15 and the latest 16.x patches, the Vercel team completely flipped the script. Caching is now opt-in by default.

If you haven't audited your full-stack data fetching patterns lately, the era of pulling your hair out over stale data is over—but it means you need to adjust how you write your data layer today.

The Nightmare of "Everything is Cached"

In previous versions, Next.js tried to be clever. It assumed that if you were making a GET request, you wanted it to be as fast as possible, so it statically cached the result at build time or on the first request.

While that worked great for basic blogs, it was a disaster for real-world dynamic apps. You had to constantly litter your code with things like:

// The old boilerplate dance just to keep data fresh
export const revalidate = 0; 
// or
fetch('[https://api.example.com/data](https://api.example.com/data)', { cache: 'no-store' });

If you forgot that single configuration object on an API route handler, your dynamic endpoint was suddenly serving stale data to your users, and your serverless functions were returning zombie responses.

The Modern Fix: Uncached by Default

In the current Next.js architecture, fetch requests and GET Route Handlers are uncached by default.

If you don't explicitly ask for caching, Next.js treats your request as dynamic. Your database gets queried when the user requests the page, just like traditional backend frameworks (like Node/Express, Rails, or Laravel) have done for decades.

// How we write data fetching now (Next.js 15/16 baseline)
// This hits the API live on every single request automatically.
const res = await fetch('[https://api.yourbackend.com/users/me](https://api.yourbackend.com/users/me)');
const user = await res.json();

If you actually want to cache a heavy public payload (like a product list or a public configuration), you now have to be intentional about it:

// Explicitly opting into performance optimization
const staticData = await fetch('[https://api.yourbackend.com/products](https://api.yourbackend.com/products)', { 
  cache: 'force-cache' 
});

This simple swap dramatically lowers the cognitive load of shipping full-stack apps. You optimize for correctness first, then opt into performance later.

Watch Out for the Asynchronous Request APIs

The caching overhaul also brought another massive structural change that catches developers off guard when upgrading: request-scoped metadata APIs are now completely asynchronous.

If you are reading cookies, headers, or route params inside a Server Component, you can no longer access them synchronously.

// ❌ This will throw an error in modern Next.js
const cookieStore = cookies();
const token = cookieStore.get('session');

//   The right way
const cookieStore = await cookies();
const token = cookieStore.get('session');

Why did they do this? To make Partial Prerendering (PPR) actually work. By making these APIs return a promise, the framework can instantly serve a static HTML shell of your page while waiting for the request-dependent dynamic parts (like user sessions or headers) to resolve and stream into the client.

Over to you

Did you get bitten by the old aggressive caching model, or did you actually prefer things being fast by default? Let's talk in the comments.

Connect with Me

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

💻 GitHub: johnnylemonny
✍️ DEV.to: johnnylemonny

This article was created with the help of AI

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

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

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

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

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

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

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

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

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

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

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

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

2. Streaming SSR is the New Baseline for AEO

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

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

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

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

3. Radical Architectural Minimalism

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

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

4. Where You Should Actually Spend Your Time

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

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

Let's connect and discuss!

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

Connect with Me

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

💻 GitHub: johnnylemonny
✍️ DEV.to: johnnylemonny

This article was created with the help of AI

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

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

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

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

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

Why Go Local?

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

Prerequisites

To get a smooth experience, you ideally need:

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

Step 1: Install Ollama and the Coding Model

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

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

ollama run qwen2.5-coder:7b

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

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

Step 2: Set Up Continue.dev in Your IDE

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

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

Step 3: Configure Continue to Use Your Local Model

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

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

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

What this configuration does:

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

How to Maximize Your Local AI Workflow

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

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

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

2. Full Project Context (`@codebase`)

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

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

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

3. Automatic Doc Generation

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

Final Thoughts

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

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

Connect with Me

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

💻 GitHub: johnnylemonny
✍️ DEV.to: johnnylemonny

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

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

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

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

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

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

1. The Shift to Bounded Agentic Workflows

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

They can:

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

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

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

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

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


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

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

3. Why "Boring" Codebase Qualities are Your Superpower

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

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

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

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

4. Let the Tooling Handle the Micro-Optimizations

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

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

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

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

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

What are your thoughts?

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

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

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

Modern Web Development in 2026

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

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

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

The question is no longer whether AI can generate components.

The better question is:

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

Generated UI has a smell

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

Common signs:

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

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

Give AI constraints, not vibes

Bad prompt:

Build a beautiful dashboard.

Better prompt:

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

AI is much more useful when you give it boundaries.

Ask for states, not just screens

A screen is not a component.

A component has states:

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

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

Require component contracts

Before accepting generated UI, define the contract:

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

This forces the component to have a clear boundary.

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

Keep design tokens non-negotiable

AI loves inventing colors.

Do not let it.

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

Tell the tool:

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

Consistency is not decoration. It is maintainability.

Make accessibility part of the prompt

Do not ask for accessibility after the component is generated.

Include it at the start:

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

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

Review generated UI like a pull request

Use this checklist:

## AI-generated UI review

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

The last question is the point.

Good uses of AI in frontend

AI is genuinely helpful for:

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

It is less reliable for:

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

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

Final thought

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

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

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

Sources

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

Thanks for reading.

You can find me here:

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

Accessibility Is Not a Lighthouse Checkbox

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

Modern Web Development in 2026

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

Automated accessibility checks are useful.

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

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

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

Start with semantic HTML

The most underrated accessibility tool is still HTML.

Use the element that matches the job:

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

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

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

Keyboard test every important flow

Put the mouse away.

Can you complete the flow with only:

Tab
Shift + Tab
Enter
Space
Arrow keys
Escape

Test:

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

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

Focus is part of the interface

Removing focus styles is not polish. It is damage.

Good focus indicators are:

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

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

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

Forms need more care than we give them

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

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

For errors:

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

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

Dialogs are traps unless designed carefully

A modal dialog should:

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

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

Do not use color alone

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

Bad:

Required fields are red.

Better:

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

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

text,
shape,
position,
iconography,
semantic markup.

Automated tests are a floor

Add accessibility checks to CI:

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

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

This is good. It is not enough.

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

The human checklist

Before release, test:

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

Final thought

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

It is part of the product being usable.

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

Sources

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

Thanks for reading.

You can find me here:

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

CSS Got Good While You Were Installing More Libraries

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

Modern Web Development in 2026

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

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

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

That history is real.

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

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

The new default: check the platform first

Before installing a styling library, ask:

Can the platform solve this now?

Often, the answer is yes.

Modern CSS gives us better primitives for:

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

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

Container queries change component design

Viewport media queries answer this:

How wide is the screen?

Container queries answer the more useful question:

How much space does this component have?

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

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

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

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

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

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

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

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

Cascade layers make CSS less fragile

The cascade is not bad. Unmanaged cascade is bad.

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

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

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

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

Subgrid fixes a real layout problem

Nested layouts often need to align with parent tracks.

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

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

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

Fluid type without a framework

You can create responsive typography with plain CSS:

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

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

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

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

Use Baseline thinking

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

It is:

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

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

The library decision checklist

Before adding a styling dependency, ask:

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

Final thought

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

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

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

Sources

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

Thanks for reading.

You can find me here:

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

TypeScript Won — Now Stop Using It Like Fancy JavaScript

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

Modern Web Development in 2026

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

TypeScript won the argument.

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

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

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

Technically TypeScript. Spiritually not.

Types should protect boundaries

The best places to spend type effort are boundaries:

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

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

Replace vague shapes with domain language

This is common:

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

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

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

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

Now invalid states have fewer places to hide.

Use branded types for dangerous strings

Not every string is the same kind of string.

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

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

Now this mistake becomes harder:

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

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

Prefer discriminated unions over boolean soup

Boolean-heavy state is where UI bugs breed.

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

This allows nonsense:

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

Use a union:

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

Now the impossible states are actually impossible.

Validate runtime data

TypeScript does not validate JSON at runtime.

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

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

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

Use runtime validation at external boundaries:

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

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

Now TypeScript and runtime reality are connected.

Use `satisfies` for configuration

Configuration should be checked without losing literal types.

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

This catches invalid values while preserving useful inference.

Avoid type theater

Some types add noise but not safety.

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

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

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

The practical checklist

Use this before merging TypeScript-heavy changes:

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

Final thought

TypeScript is not valuable because it makes JavaScript look professional.

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

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

Sources

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

Thanks for reading.

You can find me here:

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

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

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

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

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

This post is the continuation of that series.

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

GitHub repository:

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

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

What is Cabal for Android?

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

The idea is simple:

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

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

From React Native exploration to native Kotlin

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

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

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

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

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

That decision led me to Kotlin.

Why Kotlin?

Kotlin had been on my list for a long time.

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

a real project.

Cabal became that project.

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

That changed everything.

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

What is included in this first version?

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

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

The first version focuses on the foundation:

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

It is not perfect yet.

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

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

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

That feels like a big step.

What I learned while building it

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

1. Real apps teach faster than tutorials

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

Real apps are different.

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

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

2. Kotlin makes Android development feel focused

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

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

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

3. Native Android development has its own rhythm

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

You are not only learning Kotlin.

You are also learning:

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

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

4. Small milestones matter

This version is early, but shipping it matters.

It is easy to keep waiting until everything is perfect.

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

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

Why this project matters to me

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

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

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

A P2P chat app is exactly that kind of project.

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

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

Repository and download

The project is available here:

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

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

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

Feedback, ideas, and contributions are welcome.

What comes next?

This first version is only the beginning.

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

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

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

And maybe it helps someone else too.

Final thoughts

This project started as an experiment.

Then it became a Kotlin learning project.

Now it is becoming a real native Android app.

That progression has been very motivating.

The biggest lesson so far is simple:

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

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

And now the first early version is here.

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

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

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

Modern Web Development in 2026

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

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

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

Wait, should this be cached?

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

The problem started earlier.

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

Start with freshness

Before writing code, classify the data.

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

Each category deserves a different strategy.

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

The user does not care about your cache

Users care about expectations:

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

Those expectations map directly to caching behavior.

Cache by boundary, not by hope

A page usually contains mixed data.

Example product page:

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

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

Instead, design boundaries:

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

Then each section can have its own freshness model.

Make invalidation boring

Invalidation should be obvious from the mutation.

Bad mutation:

await updateProduct(productId, input);

Better mutation:

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

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

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

A cache strategy nobody can remember is not a strategy.

Avoid accidental personalization leaks

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

Watch for:

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

A simple rule helps:

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

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

Use loading states intentionally

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

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

Good skeleton:

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

Bad skeleton:

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

Debugging questions

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

## Caching debug checklist

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

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

The mental model

Think of caching as a conversation between three things:

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

When those three agree, caching feels boring.

When they disagree, caching feels haunted.

Final thought

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

It belongs in the first design conversation.

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

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

Sources

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

Thanks for reading.

You can find me here:

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

DEV Community: 𝗝𝗼𝗵𝗻

7 New JavaScript Features in ECMAScript 2026 That Replace Everyday Workarounds

1. Convert async data into an array with Array.fromAsync()

Why it matters

One important consideration

2. Initialize Map values with getOrInsert()

Why it matters

3. Combine lazy sequences with Iterator.concat()

Why laziness is useful

4. Detect genuine Error objects with Error.isError()

Why it matters

5. Sum floating-point values more accurately with Math.sumPrecise()

Important: this is not decimal arithmetic

6. Encode and decode binary data without custom Base64 helpers

Base64

Hexadecimal

Why it matters

7. Preserve important JSON source information

Use it carefully

A quick migration checklist

Manual async collection

Repeated Map initialization

Array spreads used only to join iterables

Cross-context error checks

Custom binary conversion helpers

Large integers parsed from JSON

How to use these features safely today

Final thoughts

Sources and further reading

Connect with Me

Passionaut: Turn Any Passion into an AI-Generated 3D Knowledge Atlas

What I Built

Inspiration

Try it in four steps

Share an atlas

About the API key

Code

How I Built It

1. Accepting an open-ended passion

2. Generating structured knowledge with Gemini

3. Converting the response into a graph

4. Rendering an interactive 3D constellation

5. Building dynamic 3D typography

6. Creating the deep-space interface

7. Synthesizing audio in the browser

8. Managing state and recent searches

9. Generating shareable links

10. Deploying as a static application

Technical Stack

Interesting Challenges

Making AI output visualization-ready

Supporting completely different passions

Balancing complexity and readability

Combining information with atmosphere

Running without a custom backend

Best Use of Google AI

What I Learned

What’s Next

Final Thoughts

Next.js Finally Fixed Caching (And My Database Is Sighing in Relief)

The Nightmare of "Everything is Cached"

The Modern Fix: Uncached by Default

Watch Out for the Asynchronous Request APIs

Over to you

Connect with Me

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

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

2. Streaming SSR is the New Baseline for AEO

3. Radical Architectural Minimalism

4. Where You Should Actually Spend Your Time

Let's connect and discuss!

Connect with Me

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

Why Go Local?

Prerequisites

Step 1: Install Ollama and the Coding Model

Step 2: Set Up Continue.dev in Your IDE

Step 3: Configure Continue to Use Your Local Model

What this configuration does:

How to Maximize Your Local AI Workflow

1. Convert async data into an array with `Array.fromAsync()`

2. Initialize Map values with `getOrInsert()`

3. Combine lazy sequences with `Iterator.concat()`

4. Detect genuine Error objects with `Error.isError()`

5. Sum floating-point values more accurately with `Math.sumPrecise()`

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

2. Full Project Context (`@codebase`)

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

Use `satisfies` for configuration