25 posts tagged with "frontend"

Staying updated in tech is like keeping pace with the seasons. Ignore it for a while and suddenly you look like the one person still writing jQuery in 2025. Among the handful of reliable sources that consistently deliver high-quality, expert insights, the Thoughtworks Technology Radar stands tall. Volume 33, in particular, has a rich collection of signals that map perfectly to modern frontend engineering. Here are the trends that caught my eye—my unofficial "Adopt" list for any intermediate or above frontend engineer.

AI-Enhanced Prototyping and Design​

Designers today have superpowers. Tools like UX Pilot and AI Design Reviewer act like always-available collaborators, helping generate everything from wireframes to pixel-perfect mockups. These tools also offer automated design audits, giving early warnings before a design becomes a future engineering migraine.

On the developer side, tools like V0 and Bolt allow text-based prototyping. Instead of waiting for finalized Figma files, developers can spin out interactive, throwaway prototypes in minutes. This fuels a new workflow where teams iterate rapidly on UI concepts before committing to the real build. Think of it as whiteboarding with a compiler.

Spec-Driven Development Comes of Age​

Spec-driven development is moving from “cool experiment” to “serious workflow.” The idea is simple: treat requirements as a versioned artifact, similar to code. Tools such as GitHub Spec Kit enforce this by introducing a structured flow—requirements, design, and task breakdown—each backed by richer orchestration and prompts. It also introduces a “constitution,” a set of rules the AI helpers must always obey. When specs become first-class citizens, onboarding and collaboration get smoother, and ambiguity drops dramatically.

Agents Need Documentation Too: Enter Agents.md​

Software engineers long accepted README files as the source of truth. Agents are now getting the same treatment. An Agents.md file acts like a behavioural guidebook for AI agents, explaining their capabilities, constraints, assumptions, and intended usage. It’s a simple idea but powerful for reducing unpredictability. It also improves collaboration when multiple teams depend on the same agent logic.

Shared Instructions with Slash Commands and Chat Modes​

Teams are increasingly using shared shortcuts inside their AI workflows. Slash commands like /refactor, /review, or /prototype help create predictable collaboration patterns. Paired with custom chat modes, teams end up with a common vocabulary for interacting with AI tools. This reduces the “AI did something weird” factor and introduces repeatable, deterministic workflows.

Testing: Faster Loops and Smarter Bots​

The Test && Commit || Revert workflow is resurfacing as a productive pattern. The idea is brutal and effective: write code, run tests, commit only if everything passes, and automatically revert if something breaks. Tools like Nx make this workflow practical by running only relevant tests instead of the entire suite. Without that, you’re staring at the screen waiting for tests longer than waiting for a Bangalore–Hosur bus on a rainy day.

AI-powered UI testing is also evolving. Playwright and Selenium now integrate with MCP-based agents that automatically author test cases, heal flaky selectors, and update broken assertions. UI tests finally feel less fragile and more self-repairing—a welcome relief for any frontend engineer who has fought with a stubborn CSS selector at 2 AM.

Real-Time Human–Agent Collaboration: AG-UI Protocol​

The AG-UI Protocol is an open standard aimed at structuring communication between frontends and agents. It defines how UI components and backend agents exchange state, collaborate in real time, and suggest actions to users. As agent-driven apps become mainstream, standards like this will keep architectures from devolving into random RPC chaos.

Keeping LLMs on the Same Version: Context7​

LLMs often hallucinate outdated API calls because their training data is stale. Context7 solves this by feeding models fresh, version-specific code directly from your source. This dramatically reduces the “React stopped supporting this in 2023” type of errors. For fast-moving ecosystems like Next.js or Angular, this is a significant advantage.

Feature Flags and Productivity Tools​

Feature flags are a necessary evil, but managing them across multiple runtimes is messy. OpenFeature brings a standard to how flags are defined and consumed across languages, frameworks, and platforms. It simplifies rollout strategies and makes flag management consistent.

On the tooling front, pnpm continues to prove it’s the package manager npm wishes it had become. Disk usage drops, install times improve, and monorepo workflows become smoother.

Tools Worth Paying Attention To​

The Radar also spotlights a number of tools that feel highly relevant for frontend engineers:

• Fastify brings high-performance Node servers with a pleasant TypeScript story.
• LangGraph pushes agent orchestration forward with graph-based logic flows.
• Nuxt continues to mature as Vue’s equivalent to Next.js, now also backed by Vercel.
• Tauri lets you build desktop apps using web technologies without the Electron weight class.
• ADK (Agent Development Kit) standardizes how agents are built and deployed.
• Assistant UI simplifies building apps around AI assistants.
• Drizzle and Prisma keep evolving as the most ergonomic TypeScript ORMs.
• OpenInference adds observability standards for AI pipelines.
• Valibot provides lightweight schema validation with tight type inference.
• Vercel AI SDK is becoming the go-to for building AI-driven frontend apps.

Closing Thoughts​

Thoughtworks Radar Vol. 33 makes one thing clear: the frontend world is shifting toward AI-augmented workflows, spec-driven development, and structured protocols for human–agent interaction. Frontends are no longer static presentation layers—they’re turning into dynamic negotiation tables where users and agents collaborate in real time.

Ignoring these trends will leave teams struggling to catch up later. Embracing them early gives developers the advantage of speed, clarity, and leverage. The next wave of frontend innovation is already forming around standards like AG-UI and tools like Context7, and the exciting part is that we’re still at the beginning of this transformation.

More experiments soon, especially hands-on explorations with agent-driven UIs and AI-aligned development workflows.

React Nexus 2025: React Harder​

Second time at React Nexus. Bigger venue, bigger sponsors, same old dev jokes. Held at Tata Auditorium, IISC – beautiful place if you like trees and long walks to the nearest metro.

What Went Down (Other Than My Battery)​

• Logistics: One sticker. One tee. One meal per day. That’s the deal. Cab-friendly, metro-unfriendly.

• Sponsors: Took the stage like Bollywood villains. Some reruns from 2024. Gemini & Copilot aced the quizzes more than the attendees did.

  

• ImageKit.io: Indie builder CEO handing out stickers = 🫶 Who knew images + GenAI + AWS could be a profitable cocktail?

• GoDaddy: Still selling domains like flash sales. Bought one. Page still says “Hello World.” Now with GenAI, they add the hello page for you. Still pushing Outlook 365 like it’s going out of stock.

• Vonage: Zoom-ish APIs. Most colorful booth. Least understood by crowd. They were hiring.

• WSO2 Asgardeo: Auth-as-a-service. Repeat speaker, repeat stickers. Still no buy-in from bosses.

• Zoho Catalyst: “Run everything with us (on free tier).” Indie energy, real. Good for side projects, enterprise signup after sales men raids. Might convert prompt to SaaS if you squint hard enough.

• Code of Conduct Slide: The usual “don’t harass women” clause. But honestly, dev conferences now look like HR onboarding. 50/50 gender ratio. Welcome change.

• React 19 + NextJS: Headliners. React Actions API opened the show. Time to un-dust the docs.

• Audience Engagement: Peak Bangalore moment: guy hacked, built, and launched a product on New Year’s Eve. 🙌

• React Compiler: Still a mystery box. Used in 3D video gen demo—hit and miss.

• Best Speaker? Wadad Parker. Tackled React Context with stand-up energy. Put Toastmasters to shame.

• GoDaddy Talk on Microfrontends: Enlightening. But no tools, just “vibes.”

• Tech Company vs Software Company vs Vibe-Coded Startup:

  • Tech company = builds tech
  • Software company = builds from packages
  • Vibe-coded = builds vibes, nothing else

• Zoho Catalyst (again): Their domain setup is easier than your weekend plans.

• Lighthouse Talk (again): Same speaker. Same slides. Different year. Look at web.dev if you need filler content, apparently.

• Monitoring & Observability: Not the same. One alerts, one explains. Both are friends now.

• Frontend QA: Smoke tests > Nothing. Playwright > Hope. Monitoring > Late-night debugging.

• Telemetry 101: Metrics, logs, traces... add them to your design system if you want to sound senior.

• AI Tools: Cursor’s @web, @docs, @diff = DevGPT mode unlocked.

• MCP (Magic Component Platform): Figma → Code without tears. Everyone's happy. Until you self-host it online and leak your keys.

• React Dev Joke Moment: “Lazy loading is like buying 10 chips, eating one at a time.” Me: “Bro that’s throttling. Lazy loading = frequent runs to the shop.”

• React Native: Few talks. Fewer fans. Still exists.

• Browser-LLMs: Local LLMs in your browser soon. Because why not.

Conclusion: React is evolving, audiences are engaging, and conferences are quietly becoming better. React Nexus 2025 felt more like a community summit than a sponsor expo—despite the sponsor overload. Chennai devs showed up in droves. Peaceful vibes. Good chai. No one shipped to production from the venue, which is a win.

P.S. I still haven’t deployed that domain I bought.

Why this post? As frontend engineers, we often focus narrowly on frameworks and tooling—primarily JavaScript, React, and UI libraries. But many of us hit a career plateau because we lack exposure to core software engineering principles.

This post is part of a growing genre I call “Bridge Posts”—connecting frontend development to foundational software architecture concepts. The goal is to help frontend engineers think like system designers, not just component builders.

Today, we explore the CAP Theorem, a classic principle in distributed systems, and map it to familiar frontend scenarios—such as Git workflows, real-time collaborative UIs, and offline-friendly apps.

Understanding the CAP Theorem​

In distributed systems, the CAP Theorem states that during a network partition (i.e., some parts of the system can’t communicate), you can only guarantee two of the following three:

• Consistency (C): All nodes see the same data at the same time.
• Availability (A): Every request receives a response—regardless of the freshness of the data.
• Partition Tolerance (P): The system continues to operate even when parts of it can’t communicate.

In practice, partition tolerance is non-negotiable in any distributed system. Therefore, systems must choose between consistency and availability when partitions occur.

Git Analogy: You Already Use CAP​

Let’s start with Git—a tool every developer knows.

• When you commit locally on a plane, you’re in a partitioned state.
• You can continue working (Availability), even though your code may diverge from your teammate’s (Consistency is compromised).
• Once reconnected, you merge changes to restore consistency.

Git is an AP (Available + Partition-Tolerant) system. It tolerates partitions and lets you work offline but eventually requires reconciliation.

React Use Case: Real-Time Collaborative Forms​

Now imagine you’re building a collaborative form in React. Multiple users edit the same form in real-time. Updates are synchronized via WebSockets or polling.

How does CAP play out here?

1. CP – Consistent & Partition-Tolerant​

• If a user loses network connectivity, editing is disabled.
• This ensures everyone always sees the latest state.
• However, the application becomes unavailable for offline or disconnected users.

Use cases: Healthcare apps, finance platforms—where data integrity is paramount.

2. AP – Available & Partition-Tolerant​

• Users can continue editing offline.
• Changes are stored locally and synced later.
• This may lead to conflicting edits, requiring merge strategies.

Use cases: Note-taking apps, chat applications—where user flow matters more than perfect sync.

3. CA – Consistent & Available (No Partition Tolerance)​

• Works as expected under perfect network conditions.
• Any partition causes the system to fail or block.
• While theoretically ideal, this model is impractical in real-world distributed systems.

🌐 Designing for Partition Tolerance​

A network partition occurs when different components of a distributed system—clients, services, or databases—cannot communicate due to a temporary network failure. Each component may still be operational, but they're isolated like islands without bridges.

In frontend development, this is surprisingly common:

• A user loses internet connectivity mid-session.
• A mobile app hits a dead spot with no signal.
• The frontend can reach a CDN or cache but not the main API server.

Designing for Partition Tolerance means your app should continue functioning as gracefully as possible, even during such disconnects.

As a React developer, this involves:​

• Storing user actions locally (memory, localStorage, IndexedDB).
• Queuing mutations and syncing later (e.g., Service Workers, Apollo cache, Redux middleware).
• Providing clear UI cues: “You’re offline, changes will sync later.”
• Implementing conflict resolution logic, if needed.

Real-world examples:

• Figma continues rendering and recording user edits during disconnects.
• Notion lets you type offline and syncs the block tree later.
• Gmail stores draft emails offline and sends them once reconnected.

These applications opt for Partition Tolerance, ensuring the app remains usable—even if consistency is delayed or temporarily broken.

Designing for Partition Tolerance doesn’t mean ignoring consistency—it means accepting that consistency might be eventual, not immediate.

In distributed systems, network failures are not rare edge cases—they're expected events. As frontend engineers, acknowledging and designing for them elevates your thinking from component trees to system-level resilience.

Mapping CAP to Frontend Patterns​

What This Means for Frontend Developers​

You don’t have to be building a distributed database to care about CAP. If your application:

• Caches remote data
• Lets users work offline
• Supports multi-user collaboration
• Relies on eventual consistency

…then you’re actively navigating CAP trade-offs.

Ask yourself:

• Can users work with stale data? → Choose Availability.
• Must every write be accurate and conflict-free? → Prioritize Consistency.
• Should the app always respond—even during outages? → Design for Partition Tolerance.

Closing Thoughts: Frontend as a Distributed System​

“CAP isn’t just a backend concern—it manifests in every interactive, networked UI you build.”

Whether you’re building a rich client with React Query, crafting optimistic updates, or designing for offline-first usage, you’re constantly making trade-offs. Understanding CAP helps you make them consciously.

This post was part of a broader mission to elevate frontend engineers into system thinkers—developers who don’t just build buttons, but design resilient user experiences.

Let’s not be cookie-cutter React developers. Let’s bridge the gap.

Would you like me to help you turn this into a blog-ready Markdown + SEO-friendly format?

As a dedicated frontend engineer, complacency is not an option. Staying at the forefront of technology is vital to navigate the ever-evolving landscape and provide innovative solutions to your clients. In this article, we'll explore four unconventional approaches to keeping up with frontend tech that don't involve traditional blogs or podcasts.

1. Follow the Titans​

One effective way to stay informed is by closely monitoring the thought leaders in the industry. These experts not only share their extensive knowledge but also disseminate the latest developments in frontend technology. For instance, Addy Osmani, a prominent figure in this field, is renowned for publishing cutting-edge research and providing real-time updates via Twitter or follow their talks or conferences. Here are some more influential figures to follow:

• Ben Frain
• Jake Archibald
• Lea Verou
• Addy Osmani
• David Walsh
• John Resig
• Paul Irish
• Alex Russell
• Chris Coyier
• Chris Lilley
• Dan Abramov
• David Khourshid
• Harry Roberts
• Kent C. Dodds
• Lin Clark
• Nicole Sullivan
• Sara Soueidan
• Wes Bos

2. Embrace Conferences and Meetups​

Frontend conferences and meetups are a treasure trove of insights. While it might not be feasible to watch every presentation on YouTube, you can gain valuable information by skimming through the talk titles. If a particular topic repeatedly surfaces, it's a clear indication of its significance. Here are some noteworthy conferences and meetups to keep an eye on:

Conferences:

• Smashing Conference (San Francisco, CA, USA)
• React Advanced (London, UK)
• VueConf (Multiple locations)
• Svelte Summit (Multiple locations)
• CSSConf (Multiple locations)
• Front-end Developers Conference (Multiple locations)
• Full-Stack Web Dev Conference (Multiple locations)
• JavaScript Conference (Multiple locations)

Meetups:

• Front-End Developers Meetup
• React Meetup
• Vue Meetup
• Svelte Meetup
• CSS Meetup
• Full-Stack Web Dev Meetup
• JavaScript Meetup
• Web Performance Meetup
• Accessibility Meetup

3. Dive into the Specs​

Frontend development thrives on open standards, and there are no secrets in this domain. A true professional must dive into the technical specifications. Keep a vigilant eye on the following organizations and their corresponding standards:

• For JavaScript, stay updated with TC39.
• For HTML and CSS, rely on W3C.
• Accessibility standards are set by WCAG.
• TypeScript enthusiasts should monitor TypeScript proposals.

Becoming adept at deciphering these proposals can qualify you as a tech speaker and provide instant insights for your fellow developers.

4. Explore Case Studies, Job boards and Journals​

Periodically, top-tier tech companies, such as Slack and Airbnb, release quality blogs that provide invaluable insights. Studying such content, which is tried and tested at scale on millions of users, can lead to innovative breakthroughs in your work. Notable publications, like Thoughtworks' Radar, delve into a wide array of frontend topics discussed at a CTO level, making them a must-read resource for any serious developer.

Conclusion​

Staying updated in frontend tech is no cakewalk. The methods outlined above may not be the easiest or most convenient, but they are highly effective. There is no easy way, the above said methods are not the easiest like skimming a newsletter or tech blog but I believe you can ascend to the ranks of an expert frontend developer with the above 4 strategies.

What are the Date methods?​

I have worked with a bunch of web apps and all of them have date-related code in common. The Date utils are written in plain Javascript using the Date constructor.

var date = new Date()

// Sample date methods
date.getMonth()
date.getFullYear()
date.getDate()

I have also worked on issues where the test suite would pass correctly on the day the tests were authored but they would fail on the other day or in the server. This is because the dates are getting dynamically generated in the test but the matcher value is static.

Why is testing Dates tricky?​

You cannot assert a dynamically generated date. For instance, if your date until returns a new date by applying some logic. You cannot put a test that looks like this.

// WRONG code, don't use without mocking date.getDate

expect(add2DaysToCurrentDate()).toBe("Some hard coded date")

If you want to use a hardcoded date, you should be able to control the output of the add2DaysToCurrentDate method.

How to make dynamic date logic predictable?​

The short answer is JEST mocks. Whenever we want to add 2 days to the current date, we need to ensure the date.getDate() method returns the same value, then we can write a test to assert the returned value.

it("should return new Date which is two days ahead of today", function() {
  jest.spyOn(Date, "getDate").mockImplementation(() => 14) // Mocks the getDate method until this test block
  expect(add2DaysToCurrentDate()).toBe("Some hard coded date")
})

Downsides to this approach​

As I mentioned in the comment, till the end of the test block, we cannot use date.getDate() as if it's a real function. The mock will replace the actual function call in the test block. This might hinder your assertion logic. We need to plan accordingly.

References​

https://stackoverflow.com/questions/29719631/how-do-i-set-a-mock-date-in-jest

From the title it sounds like a lot of cool technologies working side by side isn't it. Let me list them once again

• Turborepo - managing monorepo
• NPM - package manager
• NPM workspaces - also provided by npm, assists in monorepo
• vite - frontend tooling, rollup wrapper
• vite react - template for vite

Use case scenario​

I have a cool monorepo on github which holds all my sample projects, experimental works and code sample which I play around with.

The monorepo is build with npm workspaces & turborepo. I must admit that I hardly use any turbo repo features yet. Its mostly npm workspaces and npm commands at scale.

I encountered vite for frontend tooling and wanted to give it a try. Without a second thought, I created a directory called tooling and started working with vite.

Glitches and resolutions​

1. The first glitch was the node version requirement of vite. I opened a new terminal and used nvm to set the node version to latest. Thats expected bug while working with latest nodeJS tools.

2. The vite module was installed locally within the workspace. However the same vite module was referenced in vite.config.js. npm would try to resolve vite by checking in the global node_modules but it would not be there.

To understand why npm installed vite locally instead of global node_modules was easy. vite was used in npm scripts and if vite were to be installed globally then the npm scripts would fail mercilessly.

"scripts": {
    "dev": "vite",
    "build": "vite build",
    "preview": "vite preview"
  },

But the same module being used in JS modules was not expected by npm, so we need to instruct npm to install vite in both local and global node_modules.

Resolution​

At this step I found 2 ways to solve the problem.

1. The first way is something hinted by turborepo scaffold itself. I had to add vite as dev dependency at the root of the monorepo. This would ensure that vite is installed into the global node_modules.

2. The second way is to use an alias for vite within the workspace. You can do this with the below command

npm i my-vite@npm:vite -P

This command would ensure that the package vite is alias as my-vite. While checking the global node_modules folder, I noticed a folder with the name my-vite.

The flipside is that, I need to reference the vite package as my-vite within the code.

import { defineConfig } from "my-vite";

Hundreds of React tutorials and videos directly start with a custom hook. Here is my experience, where I had to write a custom react hook for the first time. Sharing the rationale and logic behind the first custom react hook.

The best thing about React props is the ability to send different data structures from parent to child without any code configuration like @input etc. But why do we need an extra construct React.forwardRef for passing ref? let us find out.