DEV Community: Shwetha

A Tamil filter-coffee stall board

Shwetha — Wed, 12 Aug 2026 11:50:27 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing

Comfort food isn’t only taste. It’s the stall board you already know how to read, the pour you watch without thinking, the quiet veena music if you want it. This is also partly a shoutout to my parents for numerous filter coffee mornings.

What I Built

For the DEV Frontend Challenge: Comfort Food Edition — Perfect Landing — I built Filter Coffee: a Tamil filter-coffee stall board. Pick a line, walk the ritual, watch the stretch pour. Optional veena if you want music.

Live Demo: https://filter-coffee.netlify.app
Code: https://github.com/TheVoraciousReader/filter-coffee

Filter Coffee stall board

The board, not a dashboard

First viewport is one composition: a painted shop menu. Shrikhand, Catamaran, and Noto Sans Tamil sit on board paint and brass. Weighted steel/brass art waits on the counter.

On mobile, the board and cups appear first, then the ritual begins so that the context stays in the first viewport.

Flow is simple:

Pick a line on the board
Step through the ritual (filter → decoction → milk → pour → sip)
On step 4, the stretch pour plays
Optionally, tap “Hear music”

CSS does the atmosphere: custom properties for paint, brass, focus, and type; a two-column shop layout from ~900px that stacks on small screens; menu rows as a dotted-line grid; SVG pour / froth / steam keyed with CSS animations.

Accessibility (the bit I cared about most)

Comfort food should feel welcoming. So should the page.

Keyboard & focus

Skip link jumps straight to the board
Real buttons for the menu and ritual — not clickable divs
Visible focus rings (brass, not browser default)
Tour mode disables other lines, so you don’t wander mid-ritual

Screen readers

aria-live announces step changes as you move through the ritual
Detail panel updates politely when you pick a line
Illustration is role="img" with a label that changes for the pour
Decorative bits stay aria-hidden

Bilingual, on purpose

Tamil sits next to English with lang="ta" so pronunciation isn’t guessed wrong
The sound toggle uses aria-pressed — on/off is clear without staring at the label

Motion & sound

prefers-reduced-motion calms the pour. Music is opt-in only. You’re in control.

Semantics over chrome

One <main>, a labeled menu list, an aside for the counter. Progress text for the tour (“2 / 5”) isn’t just visual fluff.

No perfect scorecard — just the stuff that makes a stall board usable if you’re not mousing around with perfect vision and speakers blasting.

Tech Stack

Vite as the build tool
TypeScript for type safety
React for interactivity
pnpm for package management

Run it for yourself

To poke at it locally:

pnpm install
pnpm dev

Veena clip: Veena_Recording by iskweldog (CC0).

Closing

I wanted the landing to feel like standing at the stall — paint, brass, Tamil and English side by side — and still hold up if you only have a keyboard, a screen reader, or reduced motion settings enabled.

If you try it, I’d love feedback on the ritual flow and anything that still trips assistive tech.

Built for the Comfort Food Edition · Perfect Landing.

Fixing your site's metadata: a practical checklist

Shwetha — Thu, 06 Aug 2026 18:32:23 +0000

You've done it. You're finally done building the website or application you've been working on for quite a while. Proud and elated, you go to share this on your socials or to your buddies — uh oh, what's this now? The preview in WhatsApp shows no headline, your avatar is cropped and dimensions seem wrong. I've been there too. The site looked fine in the browser.

The problem was everything outside the browser: link previews, search snippets, and tab icons all use a separate metadata layer most of us skip until something breaks.

So, how do you fix this? Use this as a pre-launch checklist — or run it on a site that's already live but sharing badly.

What I ran into on my own portfolio

When I ran this audit on shwethaadiraj.com, the site rendered fine — but sharing it told a different story. I had pointed both the favicon and Open Graph image at my profile avatar. At tab size the illustration was unreadable; in link previews it got cropped awkwardly.

An OG validator then flagged two things I hadn't considered: the image was 512×512 (most platforms expect 1200×630), and there was no headline or CTA on the image itself — so Slack and LinkedIn showed a plain square with none of the context from my meta title. I replaced the favicon with a simplified monogram, regenerated the OG image at the correct aspect ratio with my name, tagline, and site URL on it, and re-ran the debuggers. Even then, previews didn't update until I hit Scrape Again — platforms cache OG data aggressively, so fixes on your end won't show up until you bust that cache.

None of this required rethinking the app. It was a metadata pass — the kind of work that's easy to defer and annoying to discover at the share button.

Before we get into the specifics, here's a primer on what metadata can actually impact:

What is metadata for?

Metadata, simply put, is data about data. Search engines, crawlers and social sites all parse different metadata from your app.

Search & Discovery: The title and description in your app's <meta> tags tell search engines, crawlers, and AI chatbots how relevant your content is to a user's query.
Social Platforms: Open Graph (OG) and Twitter/X cards give you more control over how your app is presented when shared on social platforms.
Browser: Adding favicons and apple touch icons helps consolidate your brand identity across browser tabs, notifications and bookmarks.

The metadata audit checklist

A page can render properly and function well but it can still fail when it comes to browser, socials or search engine checks. Run this audit on every public-facing page on your app.

1. Favicon and touch icons

Does the browser tab show a clear icon at 16×16 and 32×32?
Is there a dedicated Apple touch icon (typically 180×180) for “Add to Home Screen”?
Is the favicon a simplified mark, not a full photo or illustration?
Are favicon URLs absolute (or resolvable via a consistent base URL)?

Why it matters: Large images or detailed illustrations lose detail at tab size. Users with many tabs rely on favicons to find your site. A blurry or generic icon makes the site look unfinished even when the page itself is polished.

How to verify

Open the site in a browser and inspect the tab icon.
Visit the favicon URL directly (e.g. /icon or /favicon.ico).
On mobile, add the site to the home screen and check the icon.
Use a favicon checker or DevTools → Application → Manifest / Icons if you ship a PWA manifest.

2. Page title and description

Does every route have a unique <title>?
What is the length of the titles? Are they concise and readable?
Does every page have a description summarizing content of that specific page?

Why it matters: Title and description are what show up in Google results and often in link previews when OG tags are missing. Duplicate or empty metadata makes pages compete with each other and look spammy in search.

How to verify

View page source and search for <title> and name="description".
Paste the URL into a search preview tool and confirm the title/description match what you expect.

3. Canonical URL

Does every page declare one canonical URL via <link rel="canonical">?
For your app or any routes in it, is it app.com/blog/ or app.com/blog?

Why it matters: Search engines treat duplicate URLs (http/https, www/bare, trailing slash variants) as separate pages. Canonical URL tells them which version to index and pass ranking signals to.

How to verify

View source on each page type and find link rel="canonical".
Confirm the href matches the URL you'd share publicly.
Try alternate forms (with/without www, with trailing slash) and check redirects or canonical tags.

4. Open Graph and social link previews

Does your page have og:title, og:description, and og:url, and do they match the page content?
Are the image dimensions in og:image 1200×630 (1.91:1)?
Does the image include readable headline and/or CTA text — many validators flag “no conversion text” because platforms often show the image without your meta title overlay.
Are twitter:title, twitter:description, and twitter:image defined and aligned with Open Graph tags?
Does twitter:card match your image: summary_large_image for wide OG art, summary only for small square cards?

Why it matters: These tags control how your link appears on Slack, LinkedIn, iMessage, and X. Wrong aspect ratio gets cropped; missing image means no preview. X can fall back to OG tags, but explicit Twitter tags and the right card type avoid inconsistent layouts.

How to verify

opengraph.xyz — paste URL, inspect warnings.
Facebook Sharing Debugger — use “Scrape Again” after fixes.
LinkedIn Post Inspector
Twitter Card Validator
Open your og:image URL directly in the browser — confirm it loads and reads at thumbnail size.
Compare previews across at least two platforms for the same URL.

5. Robots and indexing

Does your robots.txt allow crawling of public pages and block only private or paywalled content?
Is the sitemap URL declared in robots.txt?

Why it matters: Accidentally blocking / or omitting the sitemap slows discovery. Blocking too little exposes internal paths to crawlers.

How to verify

Visit /robots.txt on production.
View source for <meta name="robots"> on key pages.
Google Search Console → Pages / Sitemaps (if you use it).

6. Sitemap

Does /sitemap.xml exist and return valid XML?
Do new routes get added when you ship pages?
Is the URL in your sitemap matching canonical URL structure?

Why it matters: Sitemaps help search engines find pages that aren't heavily linked.

How to verify

Open /sitemap.xml in the browser.
Count URLs vs what you expect to be public.
Resubmit in Search Console after major additions.

Going further: agentic browsing

Once the basics above are solid, there's a second audience worth optimizing for: AI agents browsing on behalf of users. That means accessibility tree completeness, llms.txt, layout stability, and eventually APIs like WebMCP. I wrote a separate post on this — Your Website's New Audience: AI Agents — but the order matters: get favicons, Open Graph, and canonical URLs right first, then layer agent-ready improvements on top.

Closing thoughts

When building any new application, people focus on the app itself — metadata gets deferred until you share a link and it looks unpolished. You don't need every advanced technique on day one — get titles and descriptions, canonical URLs, favicons, and Open Graph images right first; robots.txt and sitemap next. That covers the failures people actually notice.

I've been experimenting with a Cursor agent skill that runs this checklist against a real codebase — try it on your project and let me know how it works.

How to use feature flags effectively

Shwetha — Tue, 21 Jul 2026 17:45:37 +0000

Shipping code is stressful. You have a full test suite of end-to-end tests, linting and manual verification only for something to crash in production.

Here is where feature flags enter the picture. It enables developers to safely deploy ideas in production, roll out features to a particular subset of users and disable it in case anything goes wrong without a redeployment. Let's explore some ways on how to use them effectively:

1. Don't clutter your code by mixing up feature flag logic

//🚫 DON'T: complicated if/elses
function Dashboard({ user }) {
  if (flags.enableAnalytics) {
    if (user.isAdmin) {
      return <AdminAnalytics />;
    } else {
      return <UserAnalytics />;
    }
  } else {
    if (user.isAdmin) {
      return <AdminOverview />;
    } else {
      return <UserOverview />;
    }
  }
}

//✅ DO: isolated flag logic
// flagEvaluator.js
export function getDashboardComponent(flags, user) {
  const BaseComponent = flags.enableAnalytics ? Analytics : Overview;
  return user.isAdmin ? AdminWrapper(BaseComponent) : UserWrapper(BaseComponent);
}

// Dashboard.jsx
import { getDashboardComponent } from "./flagEvaluator";

function Dashboard({ user }) {
  const DashboardComponent = getDashboardComponent(flags, user);
  return <DashboardComponent />;
}

2. Make ownership clear

Assuming a codebase worked on by a team of multiple people, all feature flags must always have a code owner. This helps massively as they now effectively manage the feature. Having an ambiguous boundary here wastes manpower and resources on who to contact if something goes wrong or for any cleanup.

3. Always test "ON" and "OFF" mode

Generally, when introducing any feature flags, there is more care given to the code paths newly introduced. Always test your "OFF" mode as thoroughly as well - there's always a chance you might need to turn it off due to some issues.

4. Clean up old or redundant flags

All flags, whether shipped or redundant need to be cleaned up - it reduces tech debt and overhead. Ideally, have a system that alerts codeowners of old flags (example criteria - flags not used in say 30 days) and have them take an action against it.

5. Follow naming conventions

A feature flag name does not need to be too descriptive, but it should be able to give any reviewer broader context on what the change does. For example, enable_new_checkout_flow_mobile would be preferred over new_checkout_flow. You can even include a tag descriptive of whether it is an experiment vs permissive flag.

6. Page performance should not be hampered by feature flags

// home-page.js
function HomePage() {
  // Multiple async calls for each flag
  const showDiscountBanner = fetchFlag("show_discount_banner");
  const enableSupportChat = fetchFlag("enable_support_chat");

  return (
    <>
      {showBanner && <Banner />}
      {enableChat && <ChatWidget />}
    </>
  );
}

Notice how in this example, nothing shows up on the home page until at least one of the feature flags are evaluated. My go to solution would be to aggressively cache your flags per user and resolving the flags on the server. Plus, always batch your feature flag calls.

Share your experience

I’d love to hear how feature flags have played out in your projects. Drop a comment with:

Bug stories: Ever had a flag cause chaos in production? How did you fix it?

Your Website’s New Audience: AI Agents

Shwetha — Mon, 20 Jul 2026 05:08:35 +0000

Web performance has traditionally always been about human user experience. In recent time, that has evolved to include AI agents as well. AI agents can be thought of as anonymous and agentic systems that browse, consume and interact the web on behalf of users. As more and more people continue to use AI agents or search engines pushing AI mode, it is recommended to optimize for agentic browsing as well.

Google has recently included an agentic browsing category for both lighthouse and pagespeed insights, although they are currently experimental.

How do we do that? Broadly speaking, there are a few basic steps that can be covered here:

1. Accessibility Tree:

When agents browse your page, they do not typically "see" the page as a human would. They parse the DOM structure to analyze element roles, names and relationships. If any part of the tree is incomplete, it may lead to broken data and checkout flows. Google Lighthouse today measures this by the following methods:

Every interactive element (button, input, link) needs to have a text node or aria-label assigned to it so they are "visible" to agents.
Parent - child relationships or sibling relations must be clear in the tree. For example, a label must be clearly tied to an input and so on. This is for better context of the general page structure and executing workflows.
Interactive elements should NOT be hidden - A clickable Submit button hidden via CSS or aria-label confuses agents.

2. Proper Metadata:

A llms.txt present at the root of your domain summarizes key pages and sections for the agent to browse for any given task without having to hit every page unnecessarily. There are more advanced techniques here like schema.org and llms-full.txt for a more enhanced summary.

3. Cumulative Layout Shift (CLS):

Cumulative Layout Shift is already a part of traditional web performance metrics but for agents, it is even more crucial as layout stability ensures that the agent does not misclick or misfire anything in a given workflow or task.

4. WebMCP Adoption:

With WebMCP, agents are provided with APIs that enable them to directly take any action based on the user prompt. There are currently two ways to implement this - a declarative API, defined directly with HTML forms or imperative API, with JavaScript. This is currently available under an origin trial - meaning you can actually try this out today in production with real users. This has practical use cases - like ecommerce, travel and general automation of day-to-day tasks.

Checking if your website is agent ready

One really good resource I've found for checking this is https://isitagentready.com/ - it gives you actionable insights and a prompt by checking against these aforementioned standards.

Closing thoughts

I'm not sure the future of the web will be fully autonomous (or if we would have evolved to some new interface) but for the moment, the best strategy is: build your page for humans and optimize the basics first - accessibility, structure, metadata, stability of the page. Then if and when the need arises, WebMCP and other technologies could be gradually introduced.

From Hooks To Actions: What's New In React 19

Shwetha — Tue, 25 Nov 2025 17:01:28 +0000

With the release of React 19.2, let's explore in brief how you can leverage the latest React features in your applications. Just a heads up, this blog post is more theory heavy. In case you want to see some working examples, I've linked a video in the references as well as the official documentation so that you can experiment with these features on your own time as well.

1. React Compiler

This is the one that's most exciting and anticipated by people in my opinion. React compiler is a build tool that automatically optimizes your app.

Before: review component logic and separate out states or apply memoization manually

After: configure in your bundler and see the magic

There are some caveats here however. Your app needs to follow Rules of React or the compiler will err on the safe side and choose to not apply any memoization automatically in such cases. Also, there may be unintended consequences to optimizing - there may be some bugs due to memoization that weren't there before.

So, how can you safely roll this out?

The React team recommends incremental adoption and has various configurations to support the same.

Feature flag

Dynamically control if the compiler is enabled or not; maybe you can roll it out to some user groups or segments and measure performance

//in your bundler config
gating: {
  source: 'ReactCompilerFeatureFlags', //file name
  importSpecifierName: 'isCompilerEnabled', //function name
},

// ReactCompilerFeatureFlags.js
export function isCompilerEnabled() {
  // Use your feature flag system
  return getFeatureFlag('react-compiler-enabled');
}

Opt in approach

By setting compilationMode: 'annotation', you can then opt in to compiler behaviour for necessary components with the "use memo" directive.

Opt out approach

By default, with just React Compiler enabled, you would have an opt out approach where you can specify components which are not to be processed by the compiler using "use no memo" directive

2. React performance tracks

With React 19.2, a custom set of performance tracks have been added for profiling, debugging and general monitoring in the performance tab of devtools.

Scheduler view : What is React working on?
Blocking (user interactions) / Transitions / Suspense / Idle

Components view : What components are being rendered by react in how much time?

3. Activity API

Activity API lets you break your app into activities. It can be helpful for cases where you might want to conditionally render components or preload parts of your app.

It has two modes : hidden, visible.

Hidden mode:

"saves" internal state for later
when you toggle to visible mode again, previous state is restored

Visible mode:

component loads with restored state

Why is it different from adding display none on elements?

React does do this for visually hiding the components but there is an added benefit here - hidden mode elements rerender at a lower priority, i.e, updates are deferred until thread is idle.

Some common use cases can be:

Preload some slow parts of your app on lower priority
Prerender some content that you know will appear next in a series of steps
Restore hidden components state as you don't unmount the component

4. View transitions API

Fair warning here, this is currently an experimental feature, available in React Canary & Experimental channels.

View transition lets you animate elements inside a transition. So, if you have a startTransition on any action already, you can wrap the relevant component in a ViewTransition and smooth out the user experience.

5. Use API

use is a React API that can consume context or Promise values. The added advantage with use is that it can be called within loops or conditionals. If used with a Promise, it pairs along with <Suspense> and <ErrorBoundary> components to provide an optimal user journey.

6. useEffectEvent

useEffectEvent is a new React Hook that lets you extract non-reactive logic from your Effects into a reusable function. This is super helpful for cases where you might want latest props and state values but not for the effect to run again on changes of those values.

References / Further Reading

React Compiler Documentation - https://react.dev/learn/react-compiler
React 19 blog - https://react.dev/blog/2024/12/05/react-19
React Conf 2025 - https://www.youtube.com/watch?v=zyVRg2QR6LA
Jack Herrington's React 19.2 explainer with working code - https://www.youtube.com/watch?v=KI4gjUrOfOs

In the comments, do let me know which feature you found most exciting or what you've tried out so far!

My VSCode Config

Shwetha — Sun, 18 Feb 2024 19:20:23 +0000

Hi fellow devs,

For my first post, I'm just documenting my VSCode configurations here for posterity's sake or just for my reference later. Keep in mind that this list is going to be language agnostic and more so utility/aesthetic suggestions (though these are inevitably tied to what languages I work with, so take that as you will). Please feel free to suggest any good extensions that I've missed out on or your absolute must-haves!

Extensions

Duplicate selection or line - keyboard shortcut for duplication (cmd/ctrl+d)
GitLens - essential when working with teams
Error Lens - inlines errors for better dev experience
Import Cost - tells you the size of imported package, pretty useful for performance improvements
Kill Process - kill a process from vscode menu
Project Dashboard - quick overview of all your projects for easy navigation
Decompiler - decompiles stuff, useful for debugging
Toggle Zen Mode - adds a button for enabling zen mode so you don't have to remember the shortcut
Bracket Select - quickly select code in between brackets
Auto Rename Tag - rename pair of tags automatically
vscode-icons - icons for most file extensions you can think of
Dracula Official - my preferred VSCode theme

Now, on to aliases. This isn't part of VSCode; it's git. But I've included it here anyway as the two do complement each other. Here's the alias section of my .gitconfig file.

[alias]
    ac = !git add -A && git commit -m
    cd = !git checkout develop
    cm = !git checkout master
    pd = !git pull origin develop
    pm = !git pull origin master
    cn = !git checkout -b

Additional Resources

https://www.smashingmagazine.com/2018/01/visual-studio-code/

That's all for my first post folks. Thanks for reading and have a nice day! ✨