DEV Community: Hugo Naili

Building search for a smart TV streaming platform

Hugo Naili — Mon, 03 Aug 2026 21:26:08 +0000

Search on a streaming platform looks simple from the couch. You type a few letters, results appear, you press OK. The interaction most people compare it to is Netflix or YouTube, and the comparison is fair — that is the bar.

What sits behind it is a fan-out. A single keyword goes to several content APIs at once, each returning a different kind of thing, and the interface has to resolve those responses into one ordered list that makes sense to someone holding a remote. That resolution is where the work is.

I built the search experience for a streaming platform on smart TVs using LightningJS.

One query, many sources

A streaming catalog is not one index. Movies, series, live channels, networks, and people each live behind their own endpoint, with their own response shape, their own latency profile, and their own idea of what a relevance score means.

So a keyword becomes N concurrent requests. That immediately raises questions the DOM and a single search endpoint would have answered for you.

When do you render? Waiting for all responses means the slowest endpoint sets your perceived latency. Rendering as each arrives means the list reorders under the user while they are looking at it — and on a TV, where the user tracks a focus highlight rather than a cursor, a list that reorders mid-look is disorienting in a way it isn't on a phone.

How do you order across sources? Each endpoint returns its own ranking, and those rankings are not comparable. An exact title match from the movies endpoint and a fuzzy match from the people endpoint both come back as "the top result." Merging them requires a ranking policy that lives in the client, because no single backend has the whole picture.

What happens when one fails? Partial failure is the normal case, not the exception. If the live-channels endpoint times out, the user should still get movies — but they should not silently get a result set that is missing a category they were looking for.

Why ordering is worse on a TV

On the web, a reordering result list is mildly annoying. On a TV it breaks the interaction.

The user is not pointing at anything. They are moving a highlight with a D-pad, and their model of the screen is positional — the thing they want is two to the right. If a slow endpoint returns and inserts three results ahead of the highlighted item, the highlight is now on something else, and the user has to re-read the row to work out where they are. Do that twice and they stop trusting the screen.

Every mitigation costs something. Lock ordering after first paint and you lose relevance when a better result arrives late. Append late results to the end regardless of score and you get stability at the price of correctness. Hold the highlight on its item as the list reflows and you preserve the user's position but shift the layout under a stationary cursor.

The input constraint shapes everything upstream

The user is typing with a directional pad on an on-screen keyboard. Each character is a cursor traversal plus an OK press. Nobody types a full title.

So the fan-out fires on two- and three-character prefixes, which means every endpoint is being asked its least selective question, which means result sets are large and the ranking problem is at its hardest exactly when you have the least information to solve it. Longer queries would be easier in every respect and you will almost never get one.

Request volume follows from this. A naive implementation fires N requests per keystroke, and a user pecking out six characters generates 6N, most superseded before they return. Debouncing is not optional, and the usual approach does not transfer cleanly: D-pad input is slow and irregular, with long pauses while the cursor travels between distant keys and then bursts on adjacent ones. A fixed timeout tuned for typing behaves badly in both directions — too eager during the pauses, too sluggish during the bursts.

Out-of-order responses are a related problem worth calling out separately. Slow irregular input plus multiple endpoints plus living-room network conditions means a response for "do" can land after a response for "doc." Each of the N streams needs its own staleness check, not just a global one.

LightningJS and what it takes away

LightningJS renders to a WebGL canvas rather than the DOM. On TV hardware that is the difference between a smooth app and a stuttering one — DOM-based TV apps degrade badly on the older devices that make up much of the installed base, and stutter is unmissable on a ten-foot screen.

The cost is that the browser stops helping. No reflow, no CSS layout, no native text input, no focus management. Every element is a texture at a coordinate you set.

Focus becomes an explicit system: a tree you maintain, key handlers you write for every direction, and no default behavior when you miss a case. Search is harder than most screens in this respect because it has several focusable regions the user moves between constantly — on-screen keyboard, query field, results grid, category filters — and every transition between them is code you write. The failure mode is a press that does nothing, which reads to a user as the app being broken rather than as a missing handler.

Texture memory

Every result tile carries a poster, and every poster is a WebGL texture resident in GPU memory. A grid of thirty tiles is thirty textures; scrolling adds more.

Lightning provides texture management primitives but the retention policy is yours. Too aggressive and users see pop-in as posters reload on scroll-back. Too lax and you crash on the low end of the device matrix — and the low end of a TV device matrix is genuinely low.

Fan-out sharpens this. Multiple content types means multiple poster aspect ratios and sizes arriving together, so the memory cost of a result set varies with what the query happened to match.

The hard part: a ranking policy the backends couldn't give me

The endpoints could each tell me what was most relevant within their own catalog. None of them could tell me whether a movie beat a person, because none of them could see the other's results. That judgment had to live in the client, and it had to be made on two or three characters of input.

What I settled on was deliberately simple. Exact title match first, regardless of source. Then movies and series. People always last.

The reasoning behind the first rule is that on a short prefix, an exact match is the only high-confidence signal available. If someone types "up" and there is a film called Up, the probability that they meant something else is low enough to ignore. Everything after that is inference; an exact match is not, so it goes above the inference.

The second rule follows from intent. On a streaming app the user is looking for something to watch. Movies and series are the destination; everything else is a route to them. Ordering by content type rather than by score is technically a worse use of the relevance information available, and it is the right call anyway, because the relevance information is weakest precisely when the ordering matters most.

The third rule is the one I deliberately got wrong. People are demoted even when the match is exact — someone typing an actor's name in full still sees that actor's films before the actor. That is incorrect for the user who specifically wanted the person page, and they pay for it by traveling further with the D-pad. I accepted that cost because the failure is recoverable in a few presses, whereas the alternative failure is not: if a person card can take position one, then a user searching for something to watch lands on a card that plays nothing, and the fix is to back out and start over. Asymmetric costs justify an asymmetric policy.

Render timing worked the same way — pick a cheap failure over an expensive one. Results paint progressively as each endpoint returns, so first paint is fast and the screen never sits empty waiting on the slowest source. But ordering locks at 400ms. After that, late arrivals append in place rather than sorting into position.

Four hundred milliseconds is roughly where a screen change stops reading as "still loading" and starts reading as "the thing moved." Before that threshold the user is still absorbing the screen and reordering is invisible. After it, they have oriented, and moving their highlight is a betrayal of a model they have already built.

The cost is real and I knew it going in: an endpoint returning at 600ms with a genuinely better match gets appended below results that deserve it less. I would rather serve a slightly worse ordering that stays still than a better one that moves. On a device where the only pointer is a highlight the user is steering blind, stability is a correctness property, not a polish item.

Structured data in Next.js: Person and BlogPosting schema

Hugo Naili — Mon, 03 Aug 2026 21:25:32 +0000

Most Next.js sites ship with good metadata and no structured data. Title tags, Open Graph, canonical URLs — all correct. And then nothing that tells a search engine what kind of thing the page is or who made it.

That gap matters more than it used to. Structured data is how a search engine moves from "this page contains the string Hugo Naili" to "this page is authored by an entity named Hugo Naili who also has these profiles and works here." The second is a fact about the world. The first is a substring match.

This is a practical walkthrough: what to add, where it goes in the App Router, and the mistakes that make it silently useless.

What JSON-LD actually is

A block of JSON in a <script type="application/ld+json"> tag describing the page in Schema.org vocabulary. It is not rendered, does not affect layout, and adds a negligible amount to your bundle.

Three properties carry most of the weight:

@type — what kind of thing this is. Person, BlogPosting, Organization, WebSite.
@id — a stable, unique URI for the entity. Underused and important; more below.
sameAs — an array of URLs where the same entity appears elsewhere.

sameAs is the one people skip and shouldn't. It is how you assert that the GitHub account, the dev.to profile, and the personal site are the same person rather than three coincidences. Entity consolidation is the whole game for personal sites.

Person schema, in the root layout

This belongs on every page, so it goes in app/layout.tsx:

export default function RootLayout({
  children,
}: {
  children: React.ReactNode
}) {
  const personSchema = {
    '@context': 'https://schema.org',
    '@type': 'Person',
    '@id': 'https://hugonaili.com/#person',
    name: 'Hugo Naili',
    url: 'https://hugonaili.com',
    jobTitle: 'Senior Demo Engineer',
    worksFor: {
      '@type': 'Organization',
      name: 'Contentful',
      url: 'https://www.contentful.com',
    },
    description:
      'Senior software engineer with over ten years of experience building React and Next.js systems, design systems, and technical demo environments.',
    knowsAbout: [
      'React',
      'Next.js',
      'TypeScript',
      'Frontend architecture',
      'Design systems',
      'GraphQL',
    ],
    sameAs: [
      'https://github.com/hugonaili',
      'https://dev.to/hugonaili',
      'https://gitlab.com/hugonaili',
      'https://medium.com/@HugoNaili',
    ],
  }

  return (
    <html lang="en">
      <body>
        <script
          type="application/ld+json"
          dangerouslySetInnerHTML={{ __html: JSON.stringify(personSchema) }}
        />
        {children}
      </body>
    </html>
  )
}

Two notes on this.

The @id is doing real work. https://hugonaili.com/#person is a stable identifier for you as an entity. Every article you publish can reference that exact string as its author, and a parser resolves all of them to one entity rather than treating each article's author as a separate unnamed person. Without it, you have N disconnected author objects that happen to share a name.

knowsAbout is not decorative. It is a topical association between an entity and subject areas, and it costs nothing.

BlogPosting schema, per article

Make it a component so every post gets consistent output:

// components/BlogPostSchema.tsx

interface BlogPostSchemaProps {
  title: string
  description: string
  slug: string
  publishedAt: string   // ISO 8601: '2026-08-03'
  updatedAt?: string
  imageUrl: string
  tags?: string[]
}

export default function BlogPostSchema({
  title,
  description,
  slug,
  publishedAt,
  updatedAt,
  imageUrl,
  tags = [],
}: BlogPostSchemaProps) {
  const url = `https://hugonaili.com/blog/${slug}`

  const schema = {
    '@context': 'https://schema.org',
    '@type': 'BlogPosting',
    '@id': url,
    headline: title,
    description,
    url,
    image: imageUrl,
    datePublished: publishedAt,
    dateModified: updatedAt ?? publishedAt,
    keywords: tags.join(', '),
    author: { '@id': 'https://hugonaili.com/#person' },
    publisher: { '@id': 'https://hugonaili.com/#person' },
    mainEntityOfPage: { '@type': 'WebPage', '@id': url },
    inLanguage: 'en-US',
  }

  return (
    <script
      type="application/ld+json"
      dangerouslySetInnerHTML={{ __html: JSON.stringify(schema) }}
    />
  )
}

Note author and publisher are references — { '@id': ... } — not inline objects. This is the payoff from defining @id in the layout. The parser follows the reference to the full Person definition. One canonical description, referenced everywhere.

Usage:

// app/blog/[slug]/page.tsx
import BlogPostSchema from '@/components/BlogPostSchema'

export default async function BlogPost({
  params,
}: {
  params: Promise<{ slug: string }>
}) {
  const { slug } = await params
  const post = await getPost(slug)

  return (
    <>
      <BlogPostSchema
        title={post.title}
        description={post.excerpt}
        slug={slug}
        publishedAt={post.publishedAt}
        updatedAt={post.updatedAt}
        imageUrl={`https://hugonaili.com/images/blog/${post.image}`}
        tags={post.tags}
      />
      <article>{/* ... */}</article>
    </>
  )
}

Breadcrumbs, which are cheap and visible

BreadcrumbList changes what your URL looks like in results — hugonaili.com › blog › article-title instead of a raw path. Small change, measurable click-through effect.

const breadcrumbSchema = {
  '@context': 'https://schema.org',
  '@type': 'BreadcrumbList',
  itemListElement: [
    { '@type': 'ListItem', position: 1, name: 'Home', item: 'https://hugonaili.com' },
    { '@type': 'ListItem', position: 2, name: 'Blog', item: 'https://hugonaili.com/blog' },
    { '@type': 'ListItem', position: 3, name: title, item: url },
  ],
}

Emit it alongside the BlogPosting. Multiple JSON-LD blocks on one page are fine and normal.

Mistakes that make this silently useless

Canonical says one thing, page content says another. If your canonical points to your own domain but the article footer links to another copy labeled "read the original here," you have contradicted yourself. Schema is a claim about authority; anything on the page that undercuts the claim undercuts the schema. This applies doubly to cross-posted content.

Assets hosted on the platform you cross-posted to. Your schema asserts you published the article. Every image loads from another platform's CDN. That's a signal in the opposite direction, and it's free to fix — download the images, serve them yourself.

Dates that aren't ISO 8601. 'August 3, 2026' is not a date to a parser. '2026-08-03' is. This fails silently; nothing warns you.

dateModified earlier than datePublished. Usually a bug where one field is hardcoded. It invalidates the whole block.

Describing content that isn't on the page. The schema must describe what a user actually sees. Headline mismatches, or an author who appears nowhere in the visible page, read as manipulation.

Missing a visible byline. If the schema names an author but the rendered page shows no author name, photo, or bio, you have a mismatch between what you're claiming and what the page demonstrates. Add the visible byline. It's a better page anyway.

Verifying it

Google's Rich Results Test at search.google.com/test/rich-results parses a live URL and shows you exactly what it extracted. Schema.org's validator is stricter about vocabulary correctness and worth running once per schema type.

Both catch syntax errors. Neither catches the semantic problems above — a page can validate perfectly while contradicting itself in the body copy. Read the rendered page and ask whether a person would agree with what the JSON claims.

What to expect

Structured data is not a ranking factor in the direct sense. It doesn't move you up the page.

What it does is make your pages legible — parseable as entities with relationships rather than documents with keywords. That legibility is what enables enhanced snippets, breadcrumb display, and eventually entity recognition. It also increasingly determines whether AI-driven search surfaces describe you accurately, since those systems lean heavily on structured signals.

The work is a couple of hours. The main cost of skipping it is that everything downstream that depends on a machine understanding who you are has to infer it from prose instead.

Extracting design tokens from a site you don't control

Hugo Naili — Mon, 03 Aug 2026 21:24:57 +0000

The problem: given a URL, produce a design token set — colors, type scale, spacing rhythm, border radii, logo — good enough that a generic app re-skinned with those tokens reads as belonging to that brand.

This sounds like a scraping problem. It is mostly not. Scraping gets you a pile of CSS values in about an hour. Turning that pile into a usable token set is where the actual work is, and it took me several iterations to get right. Here is the approach that ended up working.

Why the naive version fails

The obvious first attempt: load the page, walk the DOM, collect every computed style, count frequencies, take the top values.

I built this. It produces garbage, for a reason that is obvious in retrospect. Frequency counting is dominated by whatever element type is most numerous on the page, which is almost always body text and its containers. You get seven shades of near-black, #ffffff, one grey, and a 16px font size. Technically accurate. Completely useless for making something look like the brand, because a brand's identity lives in its accents — the button color, the display heading, the one saturated hue used sparingly — and accents are by definition rare.

The fix is to weight by visual prominence rather than count.

Weighting by prominence

Every element gets a prominence score before its styles are counted. The score I converged on:

prominence = area_ratio × viewport_weight × role_weight

area_ratio is the element's rendered area over the viewport area. A hero section outweighs a footer link.

viewport_weight decays with distance below the fold. Something at scroll position zero counts fully; something 4000px down counts for very little. Brands front-load identity.

role_weight is a lookup by tag and semantic role. Buttons, links, headings, and elements with role="button" get multiplied up substantially. This single term did more for output quality than anything else I tried, because it surfaces exactly the accent colors that frequency counting buries.

With prominence weighting, a color used on three buttons above the fold outranks a grey used on four hundred spans, which is the correct answer.

Color: cluster, then assign roles

Raw color extraction returns hundreds of near-identical values — anti-aliasing, opacity compositing, and hover states generate a smear around every intended color.

Convert to a perceptually uniform space first. Clustering in sRGB gives you results that look wrong to a human eye because sRGB distance doesn't match perceived difference. OKLCH fixed this for me; LAB works too. Cluster with a distance threshold rather than a fixed k — you don't know in advance whether a brand has three colors or eleven.

Then the harder part: assigning roles. A cluster set is not a token set. You need to know which one is primary, which is background, which is text.

Heuristics that held up:

Background is the highest-area cluster, near-always. Very high confidence.
Text is the cluster with maximum contrast ratio against background, weighted toward clusters that appear on <p> and <li> elements.
Primary is the highest-chroma cluster that appears on an interactive element. Chroma is doing the heavy lifting — brands reserve saturation for the thing they want clicked.
Surface is a cluster within a small perceptual distance of background but not identical. Cards, panels, elevated regions.

Anything left over goes into an unassigned pool. I do not try to force-assign; a wrong role assignment is worse than a missing one, because downstream code can fall back gracefully on a missing token but will render confidently wrong output on a mislabeled one.

Type scale: fit a ratio, don't collect sizes

Collecting font sizes gives you a list like [14, 16, 16, 18, 24, 32, 48]. You can use it directly, but the output is brittle — any size you need that isn't in the list has no principled value.

Better: fit a modular scale. Take the prominence-weighted mode as the base (almost always the body size), then regress the remaining sizes against candidate ratios — 1.125, 1.2, 1.25, 1.333, 1.5, 1.618 — and pick the best fit by residual.

Now instead of seven fixed numbers you have base and ratio, and every step is derivable. When the demo needs a size the source site never used, you generate one that is consistent with the brand's rhythm rather than guessing.

The same treatment works for spacing, though the fit is noisier because spacing is more often ad hoc. I extract a base unit — usually 4px or 8px, found as the GCD of common margin and padding values after discarding outliers — and express everything as multiples.

Border radius is a personality variable

Underrated signal. Collect radii from cards, buttons, and inputs, weighted by prominence, and reduce to a small set.

What matters is not the exact pixel value but where the brand sits on the sharp-to-round axis, because that position implies other decisions. Fully-rounded pill buttons want more horizontal padding than square ones to look balanced. Sharp-cornered cards tolerate tighter gaps than heavily-rounded ones. I derive a roundness scalar from the extracted radii and feed it into padding and gap calculations rather than treating radius as an isolated token.

This is the difference between a re-skin that looks like the brand and one that looks like the brand's colors applied to someone else's layout.

Logos: prefer declared, verify rendered

Order of attempts:

<link rel="icon"> and its variants, preferring SVG, then largest PNG.
Open Graph and Twitter card images — often a logo lockup, sometimes a product shot, so this needs verification.
An <img> or inline <svg> inside <header> or <nav>, positioned in the first third horizontally. This is where a wordmark lives on the overwhelming majority of sites.
Anything with logo in a class, id, alt, or filename.

Each candidate gets checked: reasonable aspect ratio (reject anything near-square and tiny, which is usually an icon rather than a wordmark), reasonable dimensions, and not a photograph. A quick edge-density check separates vector-ish marks from photos well enough.

I extract the aspect ratio explicitly and store it as a token, because header height depends on it and a 6:1 wordmark and a 1:1 mark produce meaningfully different headers.

Screenshots are for verification, never extraction

The most useful architectural decision I made.

It is tempting to pull colors out of a screenshot — it works, it's simple, and it handles canvas and image-heavy sites where the DOM tells you nothing. But screenshot pixels have been through compositing, anti-aliasing, and JPEG artifacts. The color you sample is near the brand color, never equal to it. Downstream, near-correct tokens produce output that looks subtly wrong in a way that is very hard to debug.

The DOM has ground truth. Use it.

Screenshots earn their place at the end: render the themed output, screenshot it, diff it against the source screenshot, and use the mismatch as a quality signal. Sub-5% pixel mismatch means the token extraction did its job. A large mismatch localized to one region tells you which token is wrong — a header-region mismatch points at logo sizing, a body-wide one points at type scale.

Verification, not source. That distinction is the whole thing.

Failure modes worth knowing about

Heavy canvas or WebGL sites. The DOM is nearly empty. There is no good answer; these get flagged for manual handling rather than producing confident garbage.

Aggressive bot protection. Some fraction of sites will not load headless. Budget for a fallback fetching path and accept that a percentage will need a human.

Sites mid-rebrand. New homepage, old interior pages. Extracting from more than one URL and detecting disagreement catches this, but resolving it requires knowing which one is current, which requires a human.

Dark mode defaults. If the extraction runs with a dark color-scheme preference and the brand's primary identity is light, every token is inverted. Pin the preference explicitly.

The general lesson

The scraping is the easy part and it is not where the quality comes from. The quality comes from the interpretation layer — prominence weighting, role assignment, ratio fitting, deriving tokens from other tokens rather than collecting them independently.

Which is a fairly ordinary engineering lesson dressed in an unusual problem: the value is in the model you impose on the data, not in the collection of it.

What building 40+ product demos taught me about software

Hugo Naili — Mon, 03 Aug 2026 21:24:20 +0000

I've spent the better part of a year building demo environments for a living. Not prototypes, not MVPs, not production apps. Demos: software whose entire purpose is to be watched for eleven minutes by someone deciding whether to spend money.

It is a strange discipline. Most of what I learned as a frontend engineer over the previous decade applies, but the priorities invert in ways that took me months to internalize. Here is what actually transferred, what didn't, and what I got wrong.

The demo is a narrative, and the code serves it

The first demo I built was technically excellent and completely useless.

I had built a content modeling walkthrough with proper error boundaries, optimistic updates, a loading skeleton for every async boundary, and a genuinely nice type-safe API layer. During the run-through, the account executive stopped me forty seconds in and asked why we were looking at a spinner.

The answer was that I had built for a real network. But nobody in a demo cares about a real network. They care about the moment where the thing they were promised happens on screen. Every millisecond before that moment is a millisecond where attention leaks.

The reframe that helped: a demo is a story with a claim, and every screen either advances the claim or dilutes it. Loading states dilute. Empty states dilute. Error handling — which I still believe is the most underrated skill in frontend engineering — dilutes, because the error never comes.

This does not mean building carelessly. It means the quality bar moves from robustness under adverse conditions to legibility under observation. Those are different targets and they require different code.

Seed data is the product

I underestimated this for an embarrassingly long time.

In production apps, seed data is a development convenience. You write a script, it fills the database with user_1@example.com and Lorem Ipsum, and you get on with the real work. The data is scaffolding.

In a demo, the data is the demo. When a prospect in commercial real estate looks at a content dashboard, the difference between "Article Title 1" and "Q3 Leasing Trends: Suburban Office Absorption" is the difference between watching a tool and seeing their own job.

I now spend more time on seed data than on components. A realistic dataset needs:

Plausible volume. Three records looks like a toy. Three thousand looks like a database dump. Somewhere between forty and two hundred, depending on the entity, feels like a real workspace that a real team has been using for a real year.

Temporal spread. Everything created on the same day is a tell. Real data has a long tail — things from last week, things from eight months ago, one thing from 2019 nobody has touched.

Deliberate imperfection. A workspace where every field is filled and every image is present looks synthetic. One draft with no cover image, one entry with a slightly-too-long title that wraps, one archived item. These read as authenticity precisely because a designer would have removed them.

Names that sound like the industry. This is the highest-leverage detail and the cheapest to get right. Ten minutes reading a prospect's actual site gives you the vocabulary their team uses internally.

Fast beats correct, until it doesn't

The tension I still haven't fully resolved.

Demos have brutal timelines. A prospect meeting gets scheduled Thursday for the following Tuesday, the environment needs to reflect their brand and their content model, and there is no version of that where you architect carefully.

So you take on debt aggressively. Hardcode the thing. Skip the abstraction. Put the mock response in a JSON file next to the component. This is correct and I would do it again.

The failure mode is that demo environments do not die. They get forked. Someone on another team sees the commercial real estate demo, changes six strings, and now there are two. Then eight. Then the original has a bug and the bug is in all of them.

What I settled on: debt is fine inside a demo, but never in the substrate. The theming layer, the seed data generator, the deployment pipeline — those get real engineering, because every future demo inherits them. The narrative-specific code on top can be as disposable as it needs to be.

The line is not "how important is this code" but "how many future demos will touch this code."

Theming is where the actual engineering lives

The most interesting technical problem in this job is making one codebase convincingly wear another company's identity.

Naively this is a color swap. In practice, brands differ along dimensions that break layouts in ways color never does. Type scale — a brand with a 72px display heading and a brand with a 32px one need different vertical rhythm, not a different font size. Border radius — a fully-rounded brand and a sharp-cornered brand imply different densities, different button padding, different card spacing. Logo aspect ratio, which quietly dictates header height and therefore every above-the-fold decision on the page.

Once I stopped treating theming as a palette problem and started treating it as a constraint-propagation problem, the whole thing got tractable. Design tokens with derived values rather than fixed ones. Spacing that scales from a type ratio. Component padding expressed as a function of border radius rather than a magic number.

This is the part of demo engineering that is genuinely just good frontend architecture, and it's the part I'd point to if someone asked whether this role keeps you sharp.

What transferred and what didn't

Transferred: component architecture, TypeScript discipline, understanding of the render cycle, CSS layout fundamentals, deployment tooling. All of it, more than I expected. A demo that stutters during a scroll is a demo that loses the room, and knowing why it stutters is a frontend skill.

Did not transfer: my instincts about what to build first. In product work you build the risky thing first to de-risk the project. In demo work you build the visible thing first, because the visible thing is the entire deliverable and the risky thing may never be seen.

Actively harmful: the completionist reflex. The urge to handle the edge case, fill in the empty state, wire up the setting that nobody will click. In product work that reflex is professionalism. Here it is scope creep against a fixed deadline, and I have burned real hours on screens that were never opened.

The uncomfortable part

There is a version of this job that is dishonest, and the line is thinner than I'd like.

A demo shows software working. It does not show software working under the conditions the prospect will actually encounter. Every demo engineer knows this. The good ones hold a line about which shortcuts are presentational and which are load-bearing.

My rule: I will fake the data, never the capability. Seed data can be invented. Response times can be optimistic. But if the demo shows a feature, the feature exists, and if the demo implies an integration works, the integration works. The moment you demo something that cannot be built is the moment you have written a check the implementation team has to cash.

That rule has cost me a few impressive-looking screens. It has also meant I have never had a post-sale conversation where someone felt misled, which I consider the actual measure of doing this job well.

How to type third-party API responses in TypeScript (without lying to your compiler)

Hugo Naili — Sat, 13 Jun 2026 19:52:16 +0000

You add TypeScript to a project, turn on strict, fix every red squiggle, and feel safe. Then a third-party API quietly changes a field from a number to a string, your app explodes in production, and TypeScript never said a word.

That gap surprises people, so it's worth saying plainly: TypeScript checks your code, not the data your code receives at runtime. The moment a value crosses the network boundary, your types are a promise nobody is enforcing. This article walks through how to type API responses honestly — from the quick approaches that only look safe, to the ones that actually hold up when the data misbehaves.

The starting point: `fetch` gives you nothing

Here's the shape of the problem. The built-in fetch returns a response whose .json() resolves to any:

const response = await fetch("https://api.example.com/users/1");
const user = await response.json(); // user: any
console.log(user.naem.toUpperCase()); // typo, no error, crashes at runtime

any switches type checking off. Every property access is allowed, including the typo. So the first instinct is usually to reach for a type assertion.

The trap: `as` assertions

This compiles, and it's tempting:

interface User {
  id: number;
  name: string;
  email: string;
}

const user = (await response.json()) as User;
console.log(user.name.toUpperCase());

Now your editor autocompletes user.name and the typo is caught. It feels solved. It isn't.

as is you telling the compiler "trust me, this is a User." The compiler stops arguing and assumes you're right. But nothing checks the actual JSON. If the API returns { "id": "1", "name": null }, TypeScript still believes name is a string, and user.name.toUpperCase() throws Cannot read properties of null in production — exactly the failure types were supposed to prevent.

A type assertion doesn't verify anything. It silences the one part of your stack that was being honest about not knowing.

Step one: generics for a reusable typed wrapper

Before we fix the runtime problem, let's at least stop repeating ourselves. A small generic wrapper lets each call site say what it expects:

async function getJson<T>(url: string): Promise<T> {
  const response = await fetch(url);
  if (!response.ok) {
    throw new Error(`Request failed: ${response.status}`);
  }
  return response.json() as Promise<T>;
}

interface User {
  id: number;
  name: string;
  email: string;
}

const user = await getJson<User>("https://api.example.com/users/1");
console.log(user.name.toUpperCase()); // user is typed as User

This is genuinely useful: the <T> flows through, so every caller gets a typed result without scattering assertions everywhere. The error handling lives in one place.

But be honest about what it does and doesn't do. That as Promise<T> inside the wrapper is the same assertion as before, just hidden one level down. The ergonomics improved; the runtime safety did not. The data is still unverified.

Step two: validate at the boundary with a schema

The real fix is to check the data once, at the edge where it enters your app, and only hand the rest of your code values that have actually been verified. A schema validation library like Zod makes this the path of least resistance.

The key idea: you write the schema as the single source of truth, and derive the TypeScript type from it — instead of writing an interface and a separate validator that drift apart over time.

import { z } from "zod";

const UserSchema = z.object({
  id: z.number(),
  name: z.string(),
  email: z.string().email(),
});

// Derive the type from the schema — one source of truth.
type User = z.infer<typeof UserSchema>;

async function getUser(url: string): Promise<User> {
  const response = await fetch(url);
  const json: unknown = await response.json(); // start from unknown, not any
  return UserSchema.parse(json); // throws if the payload doesn't match
}

Two things changed that matter:

json starts as unknown, not any. unknown forces you to prove what the value is before you can use it — the compiler won't let you skip the check.
UserSchema.parse(json) actually inspects the data at runtime. If the API returns { "id": "1", ... } with a stringy id, it throws a ZodError immediately, at the boundary, with a clear message — instead of three components deep when you try to do math on it.

If you'd rather handle bad data as a value than a thrown exception, use safeParse:

const result = UserSchema.safeParse(json);
if (!result.success) {
  // result.error.issues is an array of every problem found
  console.error(result.error.issues);
  return;
}
// result.data is fully typed AND verified here
console.log(result.data.name.toUpperCase());

I tested both paths against a deliberately malformed payload (id as a string, invalid email): parse throws a ZodError, and safeParse returns success: false with two issues — one per bad field. That's the difference between "TypeScript thinks this is fine" and "this data is provably correct."

Step three: codegen, when the API already has a schema

Hand-writing schemas is the right call for APIs you don't control or that have no machine-readable contract. But if the API publishes one, generate your types from it instead of transcribing them by hand:

REST with an OpenAPI/Swagger spec → openapi-typescript turns the spec into types.
GraphQL → GraphQL Code Generator produces types from your schema and even your individual queries.

Codegen's advantage is that the types are mechanically tied to the contract: when the API's spec changes and you regenerate, the new or removed fields show up as type errors across your codebase, pointing you straight at what broke. The tradeoff is that most codegen describes the shape at build time; it doesn't, by itself, validate the actual response at runtime. For untrusted or flaky sources, people often pair generated types with a runtime check at the boundary.

Which approach should you reach for?

There's no single winner — it depends on how much you trust the source and what the API gives you:

Internal API you control, low risk, want speed: a generic getJson<T> wrapper with hand-written interfaces is fine. Just know the runtime is unchecked.
Third-party or user-facing data, correctness matters: validate at the boundary with a schema (Zod or similar) and derive your types from it. This is the default I'd recommend for anything important.
API ships an OpenAPI or GraphQL schema: generate types from the contract, and add a runtime check at the edge if the data is untrusted.

Notice the through-line: the safest options all push verification to the boundary and keep a single source of truth for the type. Everything inside your app then works with data that's already been proven to match its type — which is the actual promise TypeScript was supposed to give you.

Takeaway

TypeScript types describe what your data should be. They don't make it so. For data you generate inside your own code, that's enough. For data arriving over the network, you need something that checks reality:

Reach for generics to stop repeating type assertions, but don't mistake nicer ergonomics for safety.
Avoid as on API responses — it silences the compiler instead of verifying the data.
Validate at the boundary with a schema and infer your types from it, so the type and the check can never drift apart.
Generate types from an OpenAPI or GraphQL contract when one exists, and validate at runtime when the source is untrusted.

Do that, and the next time an API quietly changes a field, you find out at the boundary with a clear error — not from a user, in production, three layers deep.

TypeScript vs. JavaScript: Explaining the differences

Hugo Naili — Thu, 07 May 2026 00:16:21 +0000

TypeScript provides developers many advantages over JavaScript: you can identify and enforce data types, better communicate the purpose of code, and streamline your development process with enhanced developer tools.

This article explains the difference between TypeScript and JavaScript, how to take advantage of the new features, and how to migrate your projects.

What is JavaScript?

JavaScript is a high-level interpreted programming language that's been around since 1995 and is widely used in web development.

It was originally developed for adding interactivity and functionality to HTML web pages. It can manipulate the Document Object Model (DOM), making it possible to create dynamic and responsive user interfaces that run in the web browser.

Although JavaScript is best known for being a client-side language, developers' widespread familiarity with it led to it being used server-side using Node.js, and to develop mobile and desktop apps using frameworks like Ionic and Electron.

What is TypeScript?

TypeScript is a programming language that's a superset of JavaScript — building on top of it to add static typing so you can catch errors during development instead of at runtime.

It was developed by Microsoft to address the difficulties of maintaining large applications written in JavaScript, and has been expanded to add a number of modern developer-friendly features.

In addition to static typing, TypeScript also adds features like interfaces, generics, type inference, access modifiers, and other constructs not present in standard JavaScript.

TypeScript compiles to plain JavaScript, so anything that works in JavaScript works in TypeScript, including third-party JavaScript libraries and any code you've already written in JavaScript.

What's the difference between TypeScript and JavaScript?

Both TypeScript and JavaScript are widely used for web development. As they are so closely related, they're often confused, but the key differences between TypeScript and JavaScript are as follows:

What is static typing?

Static typing is a programming language feature that lets you explicitly specify the data types of variables, function parameters, and return values in advance, so they are known at compile time. For TypeScript, this means the code is checked for type-related errors when it's compiled to JavaScript, so type-related errors are caught before they reach users.

By contrast, JavaScript has dynamic typing. This is where data types are determined and checked at runtime, meaning that if there is a type-related error (like trying to multiply a string by an integer), it won't be encountered until someone finds the bug by running the code — which could be one of your users in production.

Static typing in TypeScript ensures that variables are used in ways consistent with their defined types, preventing certain types of errors that can occur due to incorrect type usage.

Example of static typing in TypeScript

An example of a type error is shown in the below JavaScript snippet. This code assigns a string to the age variable, even though it was originally supposed to be a number. This leads to a runtime error when the code later tries to use age in a numeric context.

let age = 25;
age = "twenty six";
console.log(age * 2); // runtime error: "NaN"

The above JavaScript causes a NaN error in the browser.

Using a string in a numerical context results in NaN (Not a Number), a special value that indicates an operation has failed due to a number conversion.

With TypeScript, adding a static number type to the age variable causes the compiler to immediately raise the issue:

let age: number = 25;
age = "twenty six"; // compiler error: "Type 'string' is not assignable to type 'number'."

The above TypeScript causes an error earlier — before runtime.

Benefits of static typing

Early error detection — Type-related errors are caught at compile time, helping developers identify and fix issues before the code is executed. Many modern code editors (e.g., Visual Studio Code) support the TypeScript compiler running automatically in the background, meaning errors are caught as you write code.
Improved code quality — Type annotations make your code self-documenting and easier to understand.
Enhanced tooling — IDEs and code editors can provide better auto-completion, code navigation, and refactoring suggestions based on type information.
Readability and maintainability — Explicit types make code more readable and understandable, especially in larger projects.

TypeScript vs. JavaScript: use cases

When to use JavaScript

When learning to code for the first time — Beginner developers may prefer to experiment with JavaScript's flexible code without being overwhelmed with extra information.
For ad-hoc scripts or automation tasks — When you're automating tasks or writing quick, throwaway scripts, JavaScript is quicker to set up and get started with.
When working on legacy codebases — If you're working on a very old codebase already written in JavaScript, it may not be worth converting it all to TypeScript, which could require significant rewrites or break existing functionality.

When to use TypeScript (hint: whenever you can!)

You should use TypeScript whenever you can. The advantages it provides are numerous, and in any application of any scale, it gives you a better developer experience that results in more reliable code. This is particularly important for complex projects that involve collaboration between teams.

Is TypeScript better than JavaScript?

TypeScript vs. JavaScript has a clear winner for large collaborative projects. Here's why TypeScript can be a game-changer:

Reduced errors — Static typing helps catch type-related errors at compile time, preventing many common mistakes from reaching runtime.
Improved tooling and IDE support — TypeScript provides robust tooling, including code completion, navigation, and refactoring suggestions.
Enhanced collaboration — Type annotations provide clear interfaces for functions and modules, making it easier for team members to understand how different parts of the codebase interact.
Safer refactoring — TypeScript's type system makes refactoring safer by alerting developers to potential issues when they change code.
Code quality and consistency — TypeScript encourages a higher level of code quality and consistency by enforcing type standards.
Code maintainability — Static typing makes it easier to understand the data types of variables, function parameters, and return values, resulting in more self-documenting code.

You don't need to take an all-or-nothing approach. You can adopt TypeScript incrementally — start by adding types to new code or the most error-prone parts of your codebase.

How to migrate your existing JavaScript project to TypeScript

Ensure you have the latest versions of Node.js and npm installed, then follow these steps:

1. Install TypeScript

npm install typescript --save-dev

2. Create tsconfig.json

npx tsc --init

This creates a basic TypeScript configuration.

3. Enable JavaScript support

To allow TypeScript to compile .js files during migration, add "allowJs": true to the compilerOptions object in tsconfig.json:

{
  "compilerOptions": {
    "allowJs": true
  }
}

4. Convert your JavaScript files to TypeScript

Rename *.js files to *.ts (or *.jsx to *.tsx). Then run the compiler:

npx tsc path/to/your/file.ts

You can also convert all files at once and run npx tsc to compile them all.

Avoid renaming auto-generated files (e.g., those in .next/) or files from external libraries in node_modules/.

5. Add type annotations gradually

Start small by adding types for function parameters and return values:

function add(a: number, b: number): number {
  return a + b;
}

Then progressively add interfaces, type aliases, and more advanced TypeScript features.

For third-party libraries, you can find type definitions in the DefinitelyTyped repository.

6. Run tests

After migrating your files, run your test suites to check that everything still works and catch any breaking changes introduced during the migration.

What is the global object in JavaScript? A practical guide for developers

Hugo Naili — Wed, 29 Apr 2026 01:27:05 +0000

The JavaScript global object and scope are a key part of building apps with JavaScript. Unfortunately, they are easy to misunderstand and misuse, leading to negative impacts on your application's functionality, performance, and security.

This guide covers what the global object is, how JavaScript scopes work, and how to safely create and access global variables and functions across different environments.

What is the global object in JavaScript?

The global object in JavaScript is available to all parts of your code. Any variables or functions inside it are in the global scope, meaning they can be used in functions, nested callbacks, and modules — wherever they are.

The global object has a different name depending on your environment:

Environment	Global object
Browser	`window`
Node.js	`global`
Web Worker	`self` (or `this`)

Because of this inconsistency, globalThis was introduced to provide a single, standardized way to access the global object in any environment. More on that later.

The JavaScript global scope

JavaScript scopes (also called contexts) determine where a declared variable or function is accessible. Each scope has access to variables and functions declared in its parent scopes.

When JavaScript resolves a variable name, it starts at the current scope and works upward toward the global scope. The first match it finds wins.

Scope	Description
Global scope	Variables and functions declared outside any module, function, or block
Module scope	Variables and functions inside a module — isolated, not accessible from other modules
Function scope	Variables and functions declared inside a function — only accessible within that function
Block scope	Variables declared with `let` or `const` inside `{}` — only accessible within that block

Note on local scope: "Local scope" is an informal term that refers to either function scope or module scope, depending on context. A variable declared inside a function is local to that function; a variable declared inside a module is local to that module.

When you should (and shouldn't) use the global object

Each JavaScript environment comes with its own built-in globals:

Browser — window exposes the DOM, alert popups, console, localStorage, geometry info, base64 utilities, and more.
Node.js — global exposes module imports, process.env for environment variables, timers, and more.
Workers — additional globals for shared scope access between the window and other workers.

These built-in globals are safe and intended to be used. Where you need to be careful is when adding your own variables to the global scope. Avoid:

Naming a variable the same as an existing built-in global
Storing sensitive data (like user credentials or API tokens) in globals where they could be unintentionally exposed
Reusing variable names across scopes, which can cause a function to silently read a global instead of a local value

Over-relying on globals also has long-term costs:

Harder to debug — globals can be modified from anywhere, making it difficult to trace unexpected values
Memory overhead — globals persist for the lifetime of the page or process
Namespace pollution — too many globals increases the risk of naming conflicts

The best practice is to use globals as strategically and sparingly as possible.

How to create and access global variables in JavaScript

Scope Set a global variable from this scope Access a global variable from this scope

Scope	Set a global variable from this scope	Access a global variable from this scope
Global Declared variables and functions are automatically global	Browser: `var myVariable = 'foo';` Node.js: `var myVariable = 'foo';` Worker: `var myVariable = 'foo';`	Browser: `console.log(myVariable)` Node.js: `console.log(myVariable)` Worker: `console.log(myVariable)`
Function/local/block Global variables/functions must be declared in the global object	Browser: `window.myVariable = 'foo';` Node.js: `global.myVariable = 'foo';` Worker: `this.myVariable = 'foo';`	Browser: `console.log(window.myVariable)` Node.js: `console.log(global.myVariable)` Worker: `console.log(this.myVariable)`
Module Each module has its own global scope, so global variables declared in one module will not be present in another	Within modules, global, function, and block scopes behave the same way as in other environments. Functions inside modules have their own function scope and must access the module's global scope through `window`, `global`, or `this`.

Global

Declared variables and functions are automatically global

Browser: var myVariable = 'foo';

Node.js: var myVariable = 'foo';

Worker: var myVariable = 'foo';

Browser:

console.log(myVariable)

Node.js:

console.log(myVariable)

Worker:

console.log(myVariable)

Function/local/block

Global variables/functions must be declared in the global object

Browser: window.myVariable = 'foo';

Node.js: global.myVariable = 'foo';

Worker: this.myVariable = 'foo';

Browser:

console.log(window.myVariable)

Node.js:

console.log(global.myVariable)

Worker:

console.log(this.myVariable)

Module

Each module has its own global scope, so global variables declared in one module will not be present in another

Within modules, global, function, and block scopes behave the same way as in other environments. Functions inside modules have their own function scope and must access the module's global scope through window, global, or this.

How to create and access global functions in JavaScript

The process for global functions mirrors global variables. Declare a function at the top level and it is automatically global:

// Declared at the top level — automatically in the global scope
function greet(name) {
  return `Hello, ${name}!`;
}

console.log(greet('world')); // Hello, world!

If you are inside a function or block scope, you must explicitly attach the function to the global object:

// Browser
function setup() {
  window.greet = function(name) {
    return `Hello, ${name}!`;
  };
}

setup();
console.log(greet('world')); // Hello, world!

// Node.js
function setup() {
  global.greet = function(name) {
    return `Hello, ${name}!`;
  };
}

setup();
console.log(greet('world')); // Hello, world!

Watch out: Variable names and function names share the same namespace in the global scope. A var myFunction = ... will silently overwrite a function myFunction() {} if they share the same name.

How to use `globalThis` to access the global object from anywhere

With multiple JavaScript environments in play — browser windows, Node.js, web workers — accessing the global object the old way required environment-sniffing code:

// The old way — fragile and verbose
const globalObj =
  typeof window !== 'undefined' ? window :
  typeof global !== 'undefined' ? global :
  this;

globalThis solves this by always returning the global object, regardless of where you call it from. It is now supported in all modern browsers and recent versions of Node.js.

Setting a global variable with globalThis:

// Works in browser, Node.js, and workers
globalThis.myVariable = 'foo';

Accessing a global variable with globalThis:

console.log(globalThis.myVariable); // 'foo'

Setting a global function with globalThis:

globalThis.greet = function(name) {
  return `Hello, ${name}!`;
};

Accessing a global function with globalThis:

console.log(globalThis.greet('world')); // Hello, world!

globalThis works by calling this from the global scope, which always returns the global object — even when you're inside a function, a module, or a worker.

Key takeaways

The global object (window, global, self) holds all globally scoped variables and functions and is accessible throughout your entire codebase.
JavaScript resolves variable names by walking up the scope chain — the first match wins.
Use built-in environment globals freely, but be strategic when adding your own.
Over-relying on globals leads to debugging difficulties, memory overhead, and naming conflicts.
Use globalThis as the universal, environment-agnostic way to read and write globals.
When possible, prefer modules for sharing code rather than adding to the global scope.

Vue vs. React: Which JavaScript UI framework is best?

Hugo Naili — Tue, 28 Apr 2026 23:20:16 +0000

Choosing the right UI framework can make a big difference to your project's success. Vue and React are two of the most popular frameworks for UI development, and both offer huge improvements in development speed and useful functionality over vanilla JavaScript. Both are lightweight and modular with a component-based architecture and rely on a virtual DOM to improve performance. But which is best?

The truth is that there isn't one clear winner for all possible use cases, but it's likely that one will be better than another for your specific project. So, to understand which framework will work best for you, you'll need to consider which is the best fit for the developers in your team, and for the type and size of your particular application.

This post provides detailed, practical comparisons between React and Vue that will help you make an informed decision about leveraging either for your project's specific needs.

What is Vue?

Vue.js is a front-end framework for building UIs, developed by Evan You (a former Google engineer) in 2014, and is particularly well suited for building single-page applications (SPAs). It's a progressive framework, which means you can adopt it incrementally, starting by plugging just one part of it into an existing application. This incremental approach makes it easy to integrate into existing projects as well as new ones.

Vue is known for having a gentle learning curve. One reason behind this is its HTML-based template syntax, which is easier to get started with than learning a new syntax from scratch. Another reason is its use of single file components — files with a .vue suffix that contain HTML, CSS, and JavaScript all together. An example of the template syntax within a single file component is shown below.

<template>
  <div>
    <h1>{{ message }}</h1>
    <button v-on:click="changeMessage">Click me</button>
  </div>
</template>

<script>
export default {
  data() {
    return {
        message: 'Hello, World!'
    };
  },
  methods: {
    changeMessage() {
        this.message = 'You clicked the button!';
    }
  }
}
</script>
<style scoped>
  h1 { color: blue; }
</style>

In the example above, you'll notice the use of one of Vue's directives.

Directives tell Vue to do something to a DOM element, and are prefixed with a v-. In the above example, the v-on:click directive handles the button being clicked. There are a wide variety of directives for different use cases, ranging from v-bind (which allows you to dynamically bind a variable to an HTML element) to v-for (which allows you to iterate over a list).

As well as the standard HTML-based components like <div> and <img>, Vue has its own built-in components, such as for managing animation effects like fading a component in or out.

The project structure of a Vue app looks like this:

The public directory is for static assets that are not processed by Webpack (like index.html — the main HTML template), whereas assets processed by Webpack (such as images and fonts) live in the assets directory.

The main.js file is the entry point for your application and App.vue is the root Vue component. All child components go in the components directory except page components, which go in views. The router directory is for your Vue router configuration and store is for state management. Finally, vue.config.js is an optional configuration file for the Vue CLI.

What is React?

React is a JavaScript library, originally developed by Facebook in 2013. Like Vue, it's also used for building UIs and SPAs, as well as more complex web applications.

Although React is technically considered to be more of a library than a full-fledged framework, this distinction doesn't mean that it's less comprehensive than Vue, as the extra features that make Vue a framework (such as routing and state management) are still available to be used with React; they’re just not part of the core library. Instead, you could use Redux for state management and React Router for routing.

Like Vue, React has a component-based architecture and uses a virtual DOM to improve performance. It also uses declarative syntax, however, instead of templating it uses JSX, a syntax extension of JavaScript allowing you to describe UI elements in React.

The code example from Vue above would look like this in React:

import React, { useState } from 'react';
import './MyComponent.css'; // Import the CSS file for styling

const MyComponent = () => {
  const [message, setMessage] = useState('Hello, World!');

  const changeMessage = () => {
    setMessage('You clicked the button!');
  };

  return (
    <div>
    <h1>{message}</h1>
    <button onClick={changeMessage}>Click me</button>
    </div>
  );
};

export default MyComponent;

/* MyComponent.css */
h1 {
  color: blue;
}

As we can see above, the HTML tags are included as part of JSX, but the CSS is separate. (There are alternative approaches to this, such as styled-components, a library that allows you to add CSS as part of your React code, but this isn’t part of the core React library.)

You can also create custom components in React:

//Greeting.jsx
import React from 'react';

Greeting = ({ name }) => {
return <h1>Hello, {name}!</h1>;
};

export default Greeting;

And then refer to them in another JSX file:

<Greeting name={name} /> React projects typically have this structure:

The public directory is for static assets (like index.html or the favicon). The index.js file is the entry point for your application, and App.js is the root React component. All child components go in the components directory and pages go in pages. Finally, the services directory is for service logic such as API calls and the store directory is for state management (e.g. Redux).

How do Vue and React differ?

Vue.js	React
More opinionated Vue offers a single integrated solution with libraries that work together seamlessly. It has its own built-in tools for things like state management and routing.	More customizable It's a library, not a framework — with a massive ecosystem of third-party libraries to choose from. React uses these third-party libraries to handle state management and routing.
HTML templates React uses HTML templating syntax with directives (by default). It's possible to configure Vue to use JSX but this is less common.	JSX This is essentially just JavaScript, so you have the full power of JavaScript in your application. Dynamic rendering is easier in JSX.
Less commonly used In terms of market share, Vue is used by 1.1% of all JavaScript websites.	More commonly used React is used by 5.1% of all JavaScript websites. While it might not sound like a lot, this is 5x the usage of Vue.
Less community support and backing Vue has a decent amount of community support but not as much as React. It doesn't have a huge corporate backer like Meta in React's case, but does have sponsorship from some medium-sized companies. Notable users: Alibaba, GitLab, Upwork, Wizz Air	More community support and backing React is supported by a massive community and has corporate backing from Meta. Notable users: Instagram, Reddit, Airbnb, Netflix
A combination of one-way and two-way data binding v-model, a directive for form input fields, does two-way data binding, which simplifies the handling of form inputs. The v-bind directive does one-way data binding.	One-way data binding Data flows in one direction — from parent to child via props. You can still implement things that require bi-directional data flows, such as with forms, but such functionality requires managing state, which adds some complexity to your application.

Vue.js

React

More opinionated

Vue offers a single integrated solution with libraries that work together seamlessly.

It has its own built-in tools for things like state management and routing.

More customizable

It's a library, not a framework — with a massive ecosystem of third-party libraries to choose from.

React uses these third-party libraries to handle state management and routing.

HTML templates

React uses HTML templating syntax with directives (by default).

It's possible to configure Vue to use JSX but this is less common.

JSX

This is essentially just JavaScript, so you have the full power of JavaScript in your application.

Dynamic rendering is easier in JSX.

Less commonly used

In terms of market share, Vue is used by 1.1% of all JavaScript websites.

More commonly used

React is used by 5.1% of all JavaScript websites. While it might not sound like a lot, this is 5x the usage of Vue.

Less community support and backing

Vue has a decent amount of community support but not as much as React. It doesn't have a huge corporate backer like Meta in React's case, but does have sponsorship from some medium-sized companies.

Notable users: Alibaba, GitLab, Upwork, Wizz Air

More community support and backing

React is supported by a massive community and has corporate backing from Meta.

Notable users: Instagram, Reddit, Airbnb, Netflix

A combination of one-way and two-way data binding

v-model, a directive for form input fields, does two-way data binding, which simplifies the handling of form inputs.

The v-bind directive does one-way data binding.

One-way data binding

Data flows in one direction — from parent to child via props.

You can still implement things that require bi-directional data flows, such as with forms, but such functionality requires managing state, which adds some complexity to your application.

How to choose: React vs. Vue for your project

You need to make informed framework selection decisions to avoid wasting time and resources and introducing technical debt. Thorough understanding of your needs (as much as that’s possible up front) and planning for them makes app development more straightforward and predictable.

For new projects

React is best for large complex projects: Complex and large projects usually benefit from flexible tooling, so that, over time, development teams can adapt the tooling to fit their needs and their scale exactly. React is a good fit for such projects because it has a smaller amount of built-in functionality in its core library. Teams can pick and choose additional tooling to suit their own needs. React also has an extensive ecosystem, making it more flexible, which is often required with larger or more complex projects.

Vue is easier to learn: For smaller projects that don't require the flexibility of React, Vue is the better choice as it's simpler and easier to learn. If you're not familiar with either framework you'll probably find Vue easier.

For existing projects

Vue is easier to integrate: As Vue is a progressive framework, you can just add one small part to your application at a time, making it easy to start integrating into your existing JavaScript projects. It's fairly easy to add a single file component to an existing project.

Compare this to React, where you have to create many more files and import a root component into your code. It's often simpler to start from scratch and create a whole new React project, migrating all the old code from your old project into the new one.

For rapid prototyping

Vue is easier to learn: If you already have experience with either React or Vue, stick with the one you know, but otherwise use Vue as it has the simplest learning curve.

For server-side rendering (SSR)

It's a tie: Both have adequate solutions for SSR. You can either use React with Next.js or Vue with Nuxt.js. So, it really comes down to other considerations that you might care about — such as whether you're looking for a more opinionated or a more flexible framework.

For long-term reliability

React has more support and backing: Most importantly, it has corporate backing from one of the big tech giants (Meta), but it's also used more, by some of the biggest companies in the world, and has a bigger community of support.

How to create a Vue project

You can use the Vue CLI to create a new Vue project:

Install Node and NPM.
Install the Vue CLI: npm install -g @vue/cli
Use the Vue CLI to create your new project: vue create my-vue-app
Enter your new project directory: cd my-vue-app
Start the Vue development server: npm run serve
Navigate to http://localhost:8080/ in your browser.

How to create a React project

The simplest way to create a React project is to use the Create React App.

Install Node and NPM.
Use Create React App to create your new project: npx create-react-app my-react-app
Enter your new project directory: cd my-react-app
Start the React development server: npm start

Navigate to http://localhost:3000/ in your browser.

Best practices for Vue and React development and maintenance

TypeScript: Whether you're using React or Vue, there are some best practices that are relevant for both. For example, we recommend using TypeScript instead of JavaScript for all React and Vue projects as its static typing will help catch many errors early (at compile time) and will also give you features like improved automatic code completion that will speed up your development.

GraphQL: A potentially helpful practice for both types of projects is to use GraphQL. GraphQL enables you to fetch all the data you need from a single endpoint, which is much more efficient than having to use multiple REST queries to get the same data. Using GraphQL for fetching data can massively increase your performance, although there is a learning curve.

Vue best practices

Use the key attribute with lists: When it comes to using listing items, Vue uses the v-for directive, and as this isn't plain JavaScript, it can be harder to understand exactly what it's doing, which can lead to unintended side effects. For example, items in a list can lose their state when they're updated, as their order isn't necessarily preserved. To avoid this, add a key attribute to your list. React also has a similar key property for dealing with lists.

<template>
  <!--Don't do this-->
  <div v-for="item in items">{{ item }}</div>

  <!--Do this-->
  <div v-for="item in items" :key="item.id">{{ item }}</div>
</template>

Don't use `v-if` with `v-for`:

If you want to filter a list or array, don't use the v-if directive with v-for, as this is very inefficient. Vue gives priority to v-for over v-if, meaning that every single element will be looped over before the v-if conditional is checked.

<!--Don't do this-->
<div
   v-for='item in items'
   v-if='item.available'
>

Instead, extract this logic to your JavaScript code and use a filter within there.

<!--Do this-->
<template>
  <div v-for="item in availableItems">{{ item }}</div>
</template>

<script>
export default {
  computed: {
    availableItems() {
      return this.items.filter(item => item.available);
    },
  },
}
</script>

React best practices

React hooks: Using hooks allows you to simplify your code by managing state, side effects, and context all from within functional components. Without this, you'd have to use class components, which contain a lot more boilerplate code and are less performant.

The most common React hooks are useState and useEffect, but you can also create your own custom hooks. useState is responsible for managing state, and it returns the current state value along with a function to update it.

import React, { useState } from 'react';

function Counter() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={() => setCount(count + 1)}>Click me</button>
    </div>
  );
}

useEffect focuses on separating side effects from your main code logic, which makes your code more modular, readable, and maintainable. The code below runs useEffect after every render, and the side effect is that it updates the title of the web page.

import React, { useState, useEffect } from 'react';

function Counter() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    document.title = `You clicked ${count} times`;

    // Optional cleanup function
    return () => {
      console.log('Cleanup on unmount or before next effect');
    };
  }, [count]); 

  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={() => setCount(count + 1)}>Click me</button>
    </div>
  );
}

React Suspense: This allows you to display a fallback component when waiting for your main components to load. Suspense is particularly useful when your components rely on data that you're fetching from an API that may not have loaded yet.

StrictMode: Wrapping a component (or your entire application) in StrictMode will add extra checks and warnings to that component and its descendents, allowing you to identify potential problems and catch them early on.

<React.StrictMode>
    <App />
</React.StrictMode>

React vs. React Native: The difference, and which is best for you

Hugo Naili — Tue, 28 Apr 2026 21:45:12 +0000

Choosing between React vs. React Native for your project can be confusing. Both JavaScript user interface (UI) libraries serve similar purposes and use the same syntax, but their differences are important. React is designed for building user interfaces for web front ends, while React Native helps you build native mobile apps for Android and iOS.

This article explains what React and React Native are and their differences, and provides context and information so that you can decide which to use for a particular project.

React and React Native are not the same thing

React and React Native are two distinct JavaScript libraries for developing user interfaces. While React serves as the foundation for React Native, they are not the same thing, and serve different purposes when developing user interfaces:

React is intended for building user interfaces for web applications that run in the browser. It lets you create reusable UI components using your own designs implemented using CSS, or using a pre-built user interface library.
React Native lets you use React to build mobile applications that look and behave like native applications. Rather than defining your own look and feel, it adopts the appearance of the native UI elements of the operating system (like buttons, lists, and inputs), while still letting you develop your own broader design using familiar React concepts and syntax.

Both libraries use the same core React syntax and component-based architecture.

Before deciding which JavaScript UI library to adopt for a project, it's worth understanding each in detail. As React Native is built on React, the programming knowledge is transferable, so it's less a matter of deciding which you will invest your time learning, and more about learning React and then identifying when it would be better to use React Native on a per-project basis.

What is React?

React is an open-source frontend JavaScript library that is developed specifically for building user interfaces for applications that run in a web browser. It lets you create reusable UI components (known as a component-based architecture), reducing the code you need to write and providing a consistent and efficient codebase.

React uses JSX, an extension to JavaScript that lets you include the HTML for your reusable UI components alongside their JavaScript in the same file, which some developers prefer as it makes your codebase easier to understand and navigate.

Another major feature of React is the virtual DOM: a representation of the HTML document displayed in the browser that you can manipulate programmatically, and that React then automatically syncs to the real DOM as shown to the user. This feature lets you use React to make dynamic pages that don't have to reload to change their contents, with much less code than would be required if working from scratch.

Due to React’s lightweight nature, you can use it to provide as little or as much interactivity in a web page as needed, and you can add it to existing projects. Alternatives to React for web development include Vue.js and Angular. React is used by websites like Facebook, Instagram, and Netflix to power their user interfaces.

Below is an example of an HTML list rendered in React using JSX syntax:

// Import the React module
import React from 'react';

// Create the React component 
const App = () => {
    const items = ['Apple', 'Banana', 'Cherry']; // List data

    return (
        <div>
            <h1>Fruit List</h1>
            <ul> 
                {items.map((item) => (
                <li key={item}>{item}</li> /* Item names in the example array are unique strings, so they can be used as the key */
                ))}
            </ul>
        </div>
    );
};

export default App;

What is React Native?

React Native was developed so that React developers could create mobile apps with their existing React skill sets. It allows for efficient app development, as you can share much of your code between all of your web and native applications (Windows, iOS/iPadOS, and Android).

In addition to letting you leverage existing React skills, tools, and techniques to cover cross-platform native app development, React Native lets you build applications that look and feel like they were designed for each platform from the ground up.

Rather than building your own UI elements and interacting with a virtual DOM, you use React Native's buttons, lists, panels, and other included components to create applications that look like, animate like, and conform to the host’s design system. Apps built with React Native include Discord, Uber, and Skype.

Below is an example of the same list as above, but implemented using React Native user interface elements:

// Import the React module as well as the React Native UI element modules for View, Text, and FlatList
import React from 'react';
import { View, Text, FlatList } from 'react-native';

// Create the React Component
const App = () => {
    const items = ['Apple', 'Banana', 'Cherry']; // Sample list data

    return (
        <View> 
        <Text style={{ fontSize: 24 }}>Fruit List</Text> 
        <FlatList 
            data={items}
            keyExtractor={(item, index) => item} // Item names in the example array are unique strings, so they can be used as the key
            renderItem={({ item }) => (
            <Text style={{ fontSize: 18 }}>{item}</Text> 
            )}
        />
        </View>
    );
};

export default App;

You'll notice that while React and JSX syntax is used in both the React and React Native examples, the React example uses HTML elements like

and

The behavior of each example is the same, but the UI provided by React will require CSS to style it, whereas the React Native UI elements will automatically adopt the appearance of the mobile platform they are run on (it's worth noting that you can alter the appearance of React Native components).

What is React Native for Web?

Web browsers don't include native UI components for React Native to display. React Native for Web makes it possible to deploy React Native apps for delivery to web browsers by providing a set of web-compatible HTML UI components to use in place of the missing native components.

This allows you to use React Native to build both mobile and web applications, and while React Native for Web isn't a core part of React Native, it is widely supported and used by the React community, and is actively maintained.

React Native for macOS and Windows

It’s also possible to use it to develop desktop applications using React Native for Windows and React Native for macOS.

When should you use React?

You should use React to build user interfaces for your web development projects when you:

Want to benefit from the component-based architecture and interactivity React provides.

Are building web applications that will run in a web browser.

Need to design bespoke interfaces with unique visual elements that differ from the visual style of the host operating system.

When should you use React Native?

You should use React Native when you:

Want to take your React skills and use them to build native mobile or desktop apps.
Require a consistent user interface that adopts the appearance of the host operating system.
Are building native apps that you will publish to the Apple App Store, Google Play, and Microsoft Store.
Are developing an application that doesn't rely on HTML — React Native has no DOM, so everything must be constructed with React Native UI components.

Choosing the best tools for your project

React is a powerful user interface development tool, greatly streamlining the frontend development process. React Native builds on this by letting you use React to build native mobile apps as well as web apps, for full platform coverage using the same language and tools.

However, that doesn't mean React (or React Native) is necessarily right for your project: there are a number of other user interface libraries and technologies, each with their own use cases and advantages. In some cases, a full application framework may accelerate your development process by providing a code foundation and boilerplate functionality for your apps.

Designing Demos That Don’t Lie: A Demo Engineer’s Guide

Hugo Naili — Tue, 28 Apr 2026 21:19:33 +0000

There’s a special kind of dread that comes from watching a demo you know will never survive first contact with a real codebase.

On the surface, it looks slick: perfect sample data, pixel‑polished UI, a happy path that always works. Under the hood, it’s a one‑off build, stitched together just well enough to impress for 30 minutes and impossible to evolve into anything useful afterward.

As a software engineer, my job is to avoid that trap.

In this post, I’ll share how I think about building “honest demos” or demos that are realistic, technically sound, and close enough to production patterns that developers can actually build on them later, no matter which CMS, framework, or hosting platform they prefer.

What makes a demo “honest”?

To me, an honest demo has three properties:

The architecture resembles what a real team would build. Same patterns: API‑first, composable services, framework choices that match the audience.
The content model is production‑minded. References, localization, slugs, images, authors, not just a single “blob of text” field.
The handoff doesn’t feel like starting from scratch. The code, content model, and workflows are structured enough that a dev team could fork it and ship something real.

You don’t need a specific vendor to do this. Any modern stack that combines:

a headless CMS or content API,
a frontend framework (React, Vue, Svelte, etc.), and
a CI/CD + hosting setup

can support honest demos if you design with production in mind from the start.

1. Start from a real architecture, not a slide

Before I open a CMS or write a line of code, I write down three things:

Target audience: Frontend devs? Full‑stack? Marketers with some dev support?
Primary job to be done: “Spin up a blog,” “launch a campaign page,” “localize product content,” etc.
Likely stack: React + Next.js, Vue + Nuxt, a static site generator, or something else.

Then I map the architecture they’d recognize:

Content layer: a headless CMS or content API that stores structured content and media.
Frontend layer: the framework handling routing, data fetching (SSR/SSG/ISR), and UI components.
Delivery layer: hosting/CDN where builds run and pages are served.
Optional integrations: search, analytics, commerce, personalization, and so on.

The key is that nothing in the diagram feels like “demo‑only magic.” If a developer can’t imagine deploying a variant of what you’ve drawn, it’s the wrong architecture for the demo.

2. Model content like a real product, not a JSON blob

The fastest way to make a demo feel fake is to dump everything into a single “body” field.

Instead, aim for the smallest content model that still feels like production.

For a blog‑style experience, that might be:

Post
- title (short text)
- slug (short text, used in the URL)
- excerpt (long text)
- body (Rich Text or Markdown)
- coverImage (media)
- author (reference to Author)
- tags (short text or references)
- publishedDate (date/time)
Author
- name
- bio
- avatar

If localization matters to the audience, enable locales on key fields and actually show what it looks like to manage multiple languages from a single content model.

This does two things in a demo:

It builds trust with developers, because they recognize patterns they already use.
It gives you natural opportunities to show the strengths of a structured content approach: references, localization, content reuse, and preview.

3. Stand on the shoulders of starters and the community

You don’t get extra points for hand‑rolling everything.

Most ecosystems now offer:

Official starters and templates for frameworks like Next.js, Gatsby, Nuxt, Remix, etc.
Open‑source example apps on GitHub that wire a frontend to a headless CMS or content API.
Starter kits from hosting providers that cover routing, deployment, and environment variables.

As a demo engineer, treat these as scaffolding:

Use a starter to bootstrap content types, basic pages, and wiring to your content API.
Swap in your own components, design system, and story.
Prune anything that doesn’t support the narrative you’re trying to tell.

The win: you spend less time on boilerplate and more time on the aspects that make your demo unique to the prospect such as their vertical, their channels, their workflows.

4. Seed content that tells a believable story

Even with a strong content model, your demo will fall flat if the content itself feels like lorem ipsum in disguise.

Think in tiny narratives:

For each page type, what’s the story? A launch announcement, a seasonal campaign, an educational series, etc.
For each persona in the room (developer, marketer, product manager), what do they care about seeing?

Then seed content that reflects that:

Posts that look like something a real company in that industry would write.
Images and assets that match the brand and channel (hero images, thumbnails, icons).
A few intentional edge cases: long titles, missing images, quirky tags — so you can show validation or fallback behavior.

AI tools can help generate this seed content quickly, as long as you:

Review it for accuracy and tone.
Avoid inserting any real customer, personal, or internal data into prompts.
Treat it as a draft that you refine, not as a source of truth.

5. Design the demo as a workflow, not a tour

The most compelling demos are guided workflows, not feature checklists.

Instead of “here’s the content model, here’s the API, here’s the app,” frame the demo around a task that matches the audience:

“Let’s launch a new campaign page globally in under 10 minutes.”
“Let’s create a new blog post and send it to production without touching code.”
“Let’s add a new content component and expose it safely to authors.”

Then walk through:

Content modeling Add or tweak a field, explain why it’s structured that way, and how it avoids future rework.
Authoring & preview Create/edit content in the CMS, show live preview in the frontend, highlight validation and governance.
Developer experience Jump into the codebase, show how content is fetched via the content API, and how components map cleanly to content types.
Deployment or publishing Either trigger a deploy or a publish flow, depending on the story you’re telling.

By the end, the audience hasn’t just watched features, they’ve followed a realistic workflow from idea to live experience.

6. Leave behind something developers can actually use

A good demo answers “Can this work?”

A great demo also answers “What happens after we sign?”

Whenever possible, make sure the demo assets can become a starter kit:

A repo with:
- A clear README (how to run locally, how to connect to a CMS, how to deploy).
- A minimal but realistic folder structure (pages/routes, components, a small library for API access, etc.).
A content setup that:
- Uses content types you’d be comfortable extending in production.
- Avoids one‑off hacks that only exist to make the demo look good.

If the demo is just a lightly customized version of an existing starter or template, the path from proof‑of‑concept to MVP is much shorter for the prospect’s team.

7. Guardrails: what not to show

Finally, a few things to consciously avoid in demos, especially when they’re recorded or public:

No confidential customer data. Use synthetic or anonymized data that can’t be traced back to real people, companies, or contracts.
No internal‑only metrics, roadmaps, or legal details. If it’s not already public, it doesn’t belong in a public demo.
No “black box” shortcuts. If you can’t explain how something works in terms a developer would accept, it’s better to simplify than to hand‑wave.

These constraints are good discipline. They force you to rely on documented capabilities and well‑understood patterns which happens to be exactly what your audience wants to see.

Wrapping up

As demo engineers, we live in the space between aspiration and implementation. Our job isn’t to build the final product, it’s to prove that a real product could exist, on a realistic timeline, using tools the audience trusts.

You don’t need a specific vendor or stack for that. You need:

A realistic architecture your audience recognizes.
A thoughtful content model and believable data.
A workflow‑driven narrative that starts with a problem and ends with a live experience.
A handoff that feels like a starting point, not a magic trick.

If you treat your next demo as a small, honest product, instead of a disposable prototype, you’ll not only earn more trust in the room, you’ll also give the dev team something they can actually build on when the meeting ends.

What is React memo? How to improve React performance

Hugo Naili — Tue, 28 Apr 2026 04:35:57 +0000

React memo is a powerful feature that improves the performance of your React applications by letting you skip the re-rendering of components that haven't changed.

This article explains how React memo works and how to use it. It also includes use cases and code examples that you can adapt for use in your own React code to make sure that your applications are as fast and efficient as possible.

What is React memo?

Memoization is a programming technique that improves performance by caching the results of a function. Code that implements memoization checks the result of a function each time it is called to see if it can serve the cached result and avoid recomputation.

In the context of React, this means storing the results of rendering a component to avoid excessive re-renders. React memo is a component that allows you to wrap React components and memoize them based on their properties (props). This means that components wrapped in a memo will not be re-rendered if their properties have not changed.

How React memo works

Typically in React, when the state is updated in a parent component, this will trigger a re-render of that component along with any of its child components, even if only some of them rely on the updated state. This can lead to poor performance, especially if some of those components make API calls or perform complex calculations.

This is solved by using React memo: When you wrap one of your components with a memo component, it will shallowly compare its current props to its previous ones, and if there is no change in the props, React will skip re-rendering that component and continue to use the existing result (as it was in the previous virtual DOM).

For example, if you have a React parent component that displays the value of the U.S. dollar in different currencies (each currency conversion being in its own child component), each time the state of the parent component is updated with new currency data, every child component is re-drawn — even if the conversion rate hasn't changed. By wrapping each child component with memo, only those where the calculated value has actually changed will be redrawn, improving performance.

Shallow vs. deep comparison

Shallow comparison – If a prop is a primitive (string or number), React memo will check if the new value is different from the old one. If a prop is an object or an array, React memo will only compare the memory reference; even if the contents are the same but the reference has changed, it will consider them different and trigger a re-render.

Deep comparison – If a prop is complex, such as an array or object, comparison would require checking every nested value within to ensure all properties are equal to the old values. While this would provide an exact match, it’s computationally expensive and can be slower than the actual re-renders you are trying to prevent. Deep comparison should be avoided by using composition-based patterns to move the state closer to where it’s needed, minimizing the need for complex prop comparisons.

The benefits of using React memo to optimize your components include:

Preventing unnecessary re-renders and avoiding redundant updates.
Improving performance.
Optimizing expensive and complex components.
Enhancing the user experience.

As memo is simple to implement by wrapping your existing React components, it is an effective way to improve the efficiency of your apps without significantly reworking them.

How to use React memo (demo)

Now that you know what React memo is and how it works, let's take a look at some code and how you can use it in an application.

In your React project, create a parent component:

import React, { useState, useEffect } from "react";
import ChildComponent from './ChildComponent.jsx'

const ParentComponent = () => {
  const [cardData, setCardData] = useState();
  const [clicked, setClicked] = useState([]);

  useEffect(() => {
    const data = Array.from({ length: 5000 }, (_, index) => ({
      id: index + 1,
      name: `Card ${index + 1}`,
    }));

    setCardData(data);
  }, []);

  const pushItem = (id) => {
    setClicked(() => [{ id }]);
  };

  const renderWithoutMemo = () => {
    const renderedComponents = cardData?.map((card, index) => {
      return (
        <ChildComponent
          key={index}
          name={card.name}
          onClick={pushItem}
          id={card.id}
          handleClick={pushItem}
          isClicked={clicked.some((click) => click.id === card.id)}
        />
      );
    });

    return renderedComponents;
  };

  return (
    <div>
      <div
        style={{
          display: "flex",
          boxSizing: "border-box",
          flexWrap: "wrap",
        }}
      >
        {renderWithoutMemo()}
      </div>
    </div>
  );
};

export default ParentComponent;

Here the component is initialized by creating some mock data, which will render out a list of child components. With 5,000 components, other optimization techniques could be used here (pagination, for example), but this is just to demonstrate a clearly noticeable performance lag.

This component also includes some functionality that allows the user to click a child component from the list that will add its id to an array. This is checked later to decide if it has been clicked or not.

Next, create a child component:

import React, { useState, useEffect } from "react";

const ChildComponent = ({ name, handleClick, isClicked, id }) => {
  console.log("rendering - ", name);

  const calculatePrimes = (num) => {
    const primes = [];

    for (let i = 2; primes.length < num; i++) {
      let isPrime = true;
      for (let j = 2; j < i; j++) {
        if (i % j === 0) {
          isPrime = false;
          break;
        }
      }
      if (isPrime) {
        primes.push(i);
      }
    }
    return primes;
  };

  const primeNumbers = calculatePrimes(5);

  return (
    <div
      style={{
        backgroundColor: isClicked ? "green" : "#f9f9f9",
        border: "1px solid black",
        padding: "5px",
        margin: "5px",
        cursor: "pointer"
      }}
      onClick={() => handleClick(id)}
    >
      <h2 className="name">{name}</h2>
      <div>
        <ul>
          {primeNumbers.map((prime) => (
            <li style={{listStyle: "none"}} key={prime}>{prime}</li>
          ))}
        </ul>
      </div>
    </div>
  );
};

export default ChildComponent;

This is just a simple card component with some code to simulate some sort of expensive computation in each list item.

Now, if you run the application, you will be able to see a noticeable delay in performance when you click a card to change its color. If you open up the console window in your browser, you will also be able to see that each child component logs a message every time you click, showing that updating one component is triggering a re-render for all children.

Now let's add the fix with React memo. Add the below code in App.js above the ParentComponent.

const MemoizedChildComponent = React.memo(
  ChildComponent,
  (prevProps, nextProps) => {
    return prevProps.isClicked === nextProps.isClicked;
  },
);

Create a React memo component by wrapping the child in the React.memo component. By default, React.memo does a shallow comparison of props. This would normally be sufficient, but because the prop isClicked is generated dynamically (by using .some to generate a boolean), you have to pass a second argument to React.memo with an equality check function, allowing you to customize the way properties are checked. This function opens up the possibility to check objects deeply.

This is one of the common pitfalls with using React memo. The bottom line should be to either ensure that comparison props are simple values such as numbers or strings, or use a custom equality check for complex props.

Now add the following function above the renderWithoutMemo function:

const renderWithMemo = () => {
  const renderedComponents = cardData?.map((card, index) => (
    <MemoizedChildComponent
      key={index}
      name={card.name}
      onClick={pushItem}
      id={card.id}
      handleClick={pushItem}
      isClicked={clicked.some((click) => click.id === card.id)}
    />
  ));

  return renderedComponents;
};

In the return statement, remove the current renderwithoutMemo() and replace it with renderWithMemo(). Now, if you refresh the application, you should see a notable improvement in the load speed when you click on a card. Also, in the console, you will only see logs from the cards you click on, showing that the other child components have been memoized. The only components being re-rendered now are the components whose props have changed.

Here you can access a working demo of the application where you can switch between renderWithMemo() and renderWithoutMemo() to see the performance lag.

When to use React memo

It is considered best practice to use React memo in the following scenarios:

Frequent prop changes: If the props of a parent component change frequently but the output of a child component stays the same.
Expensive rendering: If you have some complex calculation going on inside a component.
Large list of components: If you have a large list of components, especially if the props are changing frequently in a parent component or you have expensive computation inside each child component.
Pure function components: Components that render often and rely solely on the input props to determine their rendering output and have no internal state or side effects.

If none of the above scenarios are true, React memo will have negligible benefits and may add unnecessary complexity to your application. To take one of the examples above, if you use React memo on a component that usually renders with different props, React will do two jobs; it will invoke the comparison function to determine whether the previous and next props are equal, and because the props comparison will always return false in this scenario, React will re-render the component anyway. So, you will get no performance benefits, and this will actually result in more overhead than benefit.

You should use the profiler tool provided by React to identify any performance issues. The Profiler tool allows you to measure how often a component renders and how long these renders take, helping you determine if memoization would provide actual performance improvements. By profiling first, you can make informed decisions about when React memo is truly beneficial, avoiding needless optimizations.

React provides a couple of other related performance optimization tools. While React memo focuses on optimizing whole component re-renders, these two are a little more granular as they require you to optimize specific parts of your components:

useMemo(): In React, useMemo is a hook that can wrap computationally heavy functions to memoize the result, so if the function is called again with the same arguments, the result doesn't need to be recalculated each time.

useCallback(): This hook can be used to wrap a function to memoize its reference. It takes a set of dependencies that determine whether the function should be redefined; if the dependencies remain the same, the memoized function can be reused. It's used to prevent unnecessary re-creation of functions that are passed down as props.

Performance matters in React applications
According to the Doherty threshold, applications that respond in 400 ms or under keep a user's attention and increase engagement, and anything over that causes frustration and may result in users leaving your application altogether.

As your React application scales and grows in complexity, you may find that it starts to slow down as you add more functionality and complex components. This is why it is advisable to employ optimization strategies such as memoization with React memo, pagination, or lazy loading from the beginning of your project, so that it always performs as well as possible.

DEV Community: Hugo Naili

Building search for a smart TV streaming platform

One query, many sources

Why ordering is worse on a TV

The input constraint shapes everything upstream

LightningJS and what it takes away

Texture memory

The hard part: a ranking policy the backends couldn't give me

Structured data in Next.js: Person and BlogPosting schema

What JSON-LD actually is

Person schema, in the root layout

BlogPosting schema, per article

Breadcrumbs, which are cheap and visible

Mistakes that make this silently useless

Verifying it

What to expect

Extracting design tokens from a site you don't control

Why the naive version fails

Weighting by prominence

Color: cluster, then assign roles

Type scale: fit a ratio, don't collect sizes

Border radius is a personality variable

Logos: prefer declared, verify rendered

Screenshots are for verification, never extraction

Failure modes worth knowing about

The general lesson

What building 40+ product demos taught me about software

The demo is a narrative, and the code serves it

Seed data is the product

Fast beats correct, until it doesn't

Theming is where the actual engineering lives

What transferred and what didn't

The uncomfortable part

How to type third-party API responses in TypeScript (without lying to your compiler)

The starting point: fetch gives you nothing

The trap: as assertions

Step one: generics for a reusable typed wrapper

Step two: validate at the boundary with a schema

Step three: codegen, when the API already has a schema

Which approach should you reach for?

Takeaway

TypeScript vs. JavaScript: Explaining the differences

What is JavaScript?

What is TypeScript?

What's the difference between TypeScript and JavaScript?

What is static typing?

Example of static typing in TypeScript

Benefits of static typing

TypeScript vs. JavaScript: use cases

When to use JavaScript

When to use TypeScript (hint: whenever you can!)

Is TypeScript better than JavaScript?

How to migrate your existing JavaScript project to TypeScript

1. Install TypeScript

2. Create tsconfig.json

3. Enable JavaScript support

4. Convert your JavaScript files to TypeScript

5. Add type annotations gradually

6. Run tests

What is the global object in JavaScript? A practical guide for developers

What is the global object in JavaScript?

The JavaScript global scope

When you should (and shouldn't) use the global object

How to create and access global variables in JavaScript

How to create and access global functions in JavaScript

How to use globalThis to access the global object from anywhere

Key takeaways

Vue vs. React: Which JavaScript UI framework is best?

What is Vue?

What is React?

How do Vue and React differ?

How to choose: React vs. Vue for your project

For new projects

For existing projects

For rapid prototyping

For server-side rendering (SSR)

For long-term reliability

How to create a Vue project

How to create a React project

Best practices for Vue and React development and maintenance

The starting point: `fetch` gives you nothing

The trap: `as` assertions

How to use `globalThis` to access the global object from anywhere

Don't use `v-if` with `v-for`: