标签：#webdev

30 React.js Interview Questions You Should Know Before Your Next Frontend Interview ⚛️ Whether you're preparing for a frontend interview or simply want to brush up on your React.js knowledge , this guide covers 30 real-world, scenario-based React interview questions that interviewers frequently ask. The goal isn't just to memorize definitions. These questions are designed to help you understand how and when to apply React concepts in real-world applications . 📌 Bookmark this article and come back to it during your next interview preparation session. 📚 What We'll Cover In this guide, we'll explore questions around: Conditional rendering API calls and side effects Form validation Performance optimization State management Component re-rendering Keys and lists Dark mode Dynamic components useEffect vs useLayoutEffect Large-list optimization And much more... 1. How do you handle conditional rendering in React? Conditional rendering allows you to render different UI based on application state or conditions. You can use standard JavaScript techniques such as: if...else Ternary operators Logical && Example { isLoggedIn ? < Dashboard /> : < Login />} 💡 Interview Tip For simple conditions, a ternary operator or && is usually sufficient. For more complex conditions, consider moving the logic outside the JSX to keep the component readable. 2. You need to fetch API data when a component mounts. What's the best way to do it? 💡 Key Concept The typical approach is to perform the API request inside a useEffect hook when the component needs to fetch data after rendering. A common pattern is: useEffect (() => { // Fetch API data }, []); The empty dependency array indicates that the effect is intended to run after the initial render. Note: In modern React applications, the best approach can also depend on the framework or data-fetching library you're using. 3. How would you handle form validation in React? A common approach is to use controlled inputs and perform validation during even

SpaceXAI recently introduced Grok Bot, an always-on AI-agent service designed to work more like an autonomous teammate. The agents have their own cloud computer environment and can log into applications, websites and tools to perform multi-step tasks. They can also operate in parallel and coordinate with other agents. The product is entering a market that already includes competing agentic workplace products from OpenAI, Anthropic and Microsoft. Traditional chatbot: User ↓ Question ↓ LLM ↓ Answer And Now Agent: Goal ↓ LLM ↓ Plan ↓ Tool ↓ Observe ↓ Reason ↓ Tool ↓ Validate ↓ Continue ↓ Result * But there's a major problem : * Giving an AI agent access to: Email Slack GitHub CRM Cloud Browser Databases Internal documents creates a huge identity and security problem. An agent with permission to send an email or modify production infrastructure effectively becomes another privileged identity. About the Author -> I am Ashutosh Maurya , a Senior Full-Stack Developer ** with 6+ years of experience in high-performance UI development and the MERN stack. I specialize in building scalable architectures like Schooliko and **AI-integrated platforms . My goal is to bridge the gap between complex backend logic and seamless frontend experiences.

Sometimes you have GPS coordinates like: 40.7128, -74.0060 But coordinates alone are not very useful to most users. They usually want to know something much simpler: What place is this? The process of converting latitude and longitude into a human-readable address is called reverse geocoding . In this article, we'll build a simple reverse geocoding example with JavaScript. What Is Reverse Geocoding? Normal geocoding converts an address into coordinates: New York, NY ↓ 40.7128, -74.0060 Reverse geocoding does the opposite: 40.7128, -74.0060 ↓ New York, NY, United States This is useful for location tools, GPS applications, travel websites, delivery systems, photo location tools, and map interfaces. Reverse Geocoding with JavaScript For a simple example, we can use the OpenStreetMap Nominatim reverse geocoding endpoint. async function reverseGeocode ( lat , lon ) { const url = `https://nominatim.openstreetmap.org/reverse` + `?lat= ${ lat } &lon= ${ lon } &format=jsonv2` ; const response = await fetch ( url ); if ( ! response . ok ) { throw new Error ( " Reverse geocoding failed " ); } const data = await response . json (); return data ; } reverseGeocode ( 40.7128 , - 74.0060 ) . then ( data => { console . log ( data . display_name ); }) . catch ( error => { console . error ( error ); }); The returned data usually contains a readable location name together with structured address information. Display the Address on a Page We can turn the example into a small browser tool. <input id= "lat" placeholder= "Latitude" > <input id= "lon" placeholder= "Longitude" > <button onclick= "findAddress()" > Find Address </button> <p id= "result" ></p> <script> async function findAddress () { const lat = document . getElementById ( " lat " ). value ; const lon = document . getElementById ( " lon " ). value ; const result = document . getElementById ( " result " ); try { const url = `https://nominatim.openstreetmap.org/reverse` + `?lat= ${ lat } &lon= ${ lon } &format=jsonv2` ; const res

AI agents can only use tools as reliably as those tools are described. That’s why I built ToolReady AI —a free tool that reviews MCP and AI-agent tool schemas, identifies reliability problems, and recommends specific fixes. A function might work perfectly when a developer calls it directly, yet still fail when an agent has to decide when to call it, which arguments to provide, and what values are safe. In many cases, the problem is not the underlying API. It is the tool schema placed between the API and the model. Here are seven issues worth checking before releasing an MCP or AI-agent tool. A description that is too vague Descriptions such as "Searches documents" do not give an agent enough routing context. The description should identify the supported content, expected result, important limits, and a clear use case. Better: «Search indexed support documents and return the most relevant text excerpts. Use this when answering questions about product setup or troubleshooting. Do not use it for account-specific or real-time billing information.» No boundary conditions A useful description should also explain when the tool should not be used. Exclusions help an agent distinguish similar tools and avoid calls that cannot succeed. Examples include: Do not use for personal account data. Do not use when the user requests current inventory. Do not use for destructive actions without confirmation. Undocumented inputs An input name such as "query", "id", or "limit" may seem obvious to its author, but the agent still has to guess the required meaning and format. Each property should explain: What the value represents The expected format A realistic example Any important constraints Missing required fields If the schema does not identify the minimum necessary inputs as required, an agent may send an empty or incomplete call that cannot produce a useful result. For example: { "type": "object", "properties": { "query": { "type": "string", "description": "Natural-language search q

Last quarter, we ran our production voice AI receptionist — Loquent — across four different TTS engines simultaneously, split-testing real patient calls at dental and healthcare clinics. The results surprised us: the most "natural sounding" engine in demos performed the worst with actual patients. Why We Ran This Test At Autor, we've been running Loquent in production for over a year now. It handles thousands of automated calls per month for healthcare and dental clinics across Canada — booking appointments, answering insurance questions, handling after-hours triage. The voice is the product. If patients don't trust the voice, they hang up, and the clinic loses a booking. When we first built Loquent, we picked our TTS engine the way most teams do: we generated a few sample clips, played them for ourselves, and went with the one that sounded best in a quiet office. That worked fine until we started digging into our call analytics and noticed something weird. Our completion rate — the percentage of calls where patients actually finished the full interaction instead of hanging up or asking for a human — was hovering around 74%. Good, but not great. We suspected the voice itself was part of the problem. So we designed a proper A/B test. Not a demo comparison. A production comparison on live calls. The Setup We tested four TTS engines across 12,247 calls over 8 weeks. Each engine handled roughly equal volume, randomly assigned at call start. All other variables stayed constant: same prompts, same Anthropic Claude backbone for conversation, same Twilio infrastructure, same clinics. The four engines: Engine A : ElevenLabs (Turbo v2.5) — our existing production engine Engine B : OpenAI TTS (tts-1-hd) — the model most teams default to Engine C : Deepgram Aura — optimized for real-time, low-latency use cases Engine D : A newer entrant we'd been evaluating (under NDA, so I can't name it) We measured five things: Completion rate — did the patient finish the full call flow? Time

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is...

🚀 SoloEngine v0.4.0 Release — Context Compaction, Browser/Terminal Panels, Token Statistics...

A practical guide to building reliable event-driven systems in Go using Apache Kafka. Learn how to implement tiered retry strategies with delayed reprocessing, route permanently failed messages to dead letter queues in Golang with Sarama. Prerequisites What do you need to follow along? Working knowledge of Golang. Go & Docker installed on your PC. What is an Event-Driven Architecture? An Event-Driven Architecture (EDA) is a design approach where services communicate by producing and responding to events. Each service operates independently, producing or reacting to events as they happen. What are Events? An event is a record of something that has happened in a system, typically representing a state change or a significant action. An event contains data (payload) describing what happened. An example of an event could be: A user signing up for a service. A user placing an order in your system. Components of an Event-Driven Architecture To understand how events flow through a system, we need to know three key players: Event Producers : They are the sources of events. They generate and publish events like signup events, order placed events, etc. Producers generate events and transmit them to the rest of the system. They do not know who is listening for or handling the events. Event Brokers : They sit between producers and consumers, decoupling them so neither needs a direct connection to the other. Brokers receive event messages, maintain their chronological order, make them available for consumption, and route them to the right consumers. Apache Kafka is an example of an event broker, and it's the one we'll use throughout this guide. Event Consumers : They handle the processing tasks. They listen on event channels and react when an event they are subscribed to is published, then they process the event, which can include making API calls, updating a database, triggering other events, or logging information. The Complete Flow With those three pieces in place, the flow of

The bug ticket said "carousel feels broken on trackpad." It took me forty minutes to find the actual...

O contrato do cliente tá numa URL que qualquer um adivinha A tarefa parecia simples: o cliente precisa baixar a nota fiscal dele. Você salvou em storage/app/public/notas/ , rodou php artisan storage:link , mandou o link e foi feliz. https://app.com/storage/notas/nota-1042.pdf . Semanas depois cai a ficha. Aquele arquivo está aberto na internet . Sem login, sem nada. E o nome é sequencial: quem baixou a nota-1042.pdf só precisa de curiosidade e cinco segundos pra tentar a 1041 . E a 1040 . Então você faz a coisa certa: tira do disco público e cria um sistema pra controlar acesso. Tabela download_tokens , model, geração de UUID, coluna expires_at , controller que valida, e um comando no scheduler pra limpar os vencidos. Sessenta linhas depois, funciona. E aí alguém comenta no PR: "por que você não usou uma URL assinada?" O sistema que você não precisava construir // ❌ migration + model + controller + command. tudo isso pra um PDF. Schema :: create ( 'download_tokens' , function ( Blueprint $table ) { $table -> id (); $table -> uuid ( 'token' ) -> unique (); $table -> string ( 'path' ); $table -> foreignId ( 'user_id' ); $table -> timestamp ( 'expires_at' ); $table -> timestamps (); }); public function gerarLink ( NotaFiscal $nota ): string { $token = DownloadToken :: create ([ 'token' => Str :: uuid (), 'path' => $nota -> arquivo_path , 'user_id' => auth () -> id (), 'expires_at' => now () -> addMinutes ( 10 ), ]); return route ( 'download' , $token -> token ); } Não tem nada de errado tecnicamente. O problema é o custo: mais uma tabela crescendo pra sempre, mais um comando no scheduler, mais um caminho pra testar. E você vai manter isso enquanto o projeto existir. O Laravel resolve o mesmo problema com uma assinatura criptográfica na própria URL. Sem estado, sem tabela, sem limpeza. Como uma URL assinada funciona A ideia é bonita de simples: o Laravel monta a URL com os parâmetros que você quer, calcula um hash disso tudo usando a APP_KEY e cola o hash no final. /not

"Deu erro ao salvar, umas duas da tarde" É a única informação que você tem. O cliente não lembra o que clicou, não tirou print e já fechou a aba. Você abre o laravel.log . Quarenta mil linhas no dia. Faz um grep por "erro". Aparecem 1.200 ocorrências, e a maioria é isso: [2026-08-14 14:03:11] production.INFO: entrou [2026-08-14 14:03:11] production.INFO: erro aqui [2026-08-14 14:03:12] production.INFO: passou [2026-08-14 14:03:12] production.ERROR: Erro ao salvar Erro ao salvar o quê ? De qual usuário? Qual pedido? Qual valor? Aquele entrou da linha de cima é do mesmo request ou de outro cliente que estava usando o sistema no mesmo segundo? Você tem log. Você não tem informação. São coisas diferentes. O problema não é a falta de log. É o excesso de log inútil. public function emitir ( Pedido $pedido ) { Log :: info ( 'entrou no emitir' ); try { $nota = $this -> sefaz -> emitir ( $pedido ); Log :: info ( 'emitiu' ); } catch ( Throwable $e ) { // parabéns, você registrou que algo deu errado em algum lugar 🎉 Log :: error ( 'Erro ao emitir nota' ); return back () -> withErrors ( 'Falha na emissão' ); } } Repara no que esse catch jogou no lixo: a mensagem da exceção, o stack trace, o ID do pedido, o CNPJ, o retorno da SEFAZ. Tudo estava ali, na mão, e foi substituído por uma frase genérica. E os Log::info('entrou') espalhados? Aquilo foi debug que virou permanente. Hoje eles só servem pra empurrar as linhas úteis pra fora da tela. Duas perguntas que todo log precisa responder Um log serve pra duas plateias: você, com sono, às 3h da manhã — e uma máquina , filtrando milhões de linhas. As duas querem a mesma coisa: O que aconteceu , numa mensagem que não muda nunca. Com quem aconteceu , em dados separados da mensagem. Essa separação é o pulo do gato. Repare na diferença: // ❌ mensagem única pra cada pedido. impossível agrupar ou contar. Log :: error ( "Falha ao emitir nota do pedido { $pedido -> id } do cliente { $cliente -> nome } " ); // ✅ mensagem estável + contexto est

The Quest Begins (The "Why") I still remember the first time I tried to add login to a side‑project. I’d read a tutorial that said “just store a token in localStorage and you’re good,” slapped together a few fetch calls, and called it a day. A week later I got an email from a user: “Hey, I can’t log out, and someone else seems to be using my account.” My heart sank. I realized I’d bolted a flashy lock onto a screen door — it looked secure, but anyone with a screwdriver could walk right in. That moment kicked off a deep dive. I wanted to understand the trade‑offs between sessions , JSON Web Tokens (JWT) , and OAuth so I could pick the right tool for each job, not just the shiniest one. What followed felt like assembling a superhero squad: each member has a unique power, and knowing when to call on them makes the difference between saving the day and causing collateral damage. The Revelation (The Insight) Sessions – The Trusty Sidekick Sessions are the classic, server‑side approach. When a user logs in, the server creates a random identifier (the session ID), stores it in a database or cache (Redis, Memcached, etc.), and sends it back to the browser as an HttpOnly cookie. On every request, the browser automatically includes that cookie, the server looks up the ID, and pulls the associated user data. Why I love it: The secret never leaves the server, so stealing a cookie only gives an attacker a session ID that’s useless without the server’s store. Revoking a session is trivial — just delete the row from the store. Works great for traditional web apps where you control both front‑ and back‑end. Where it stumbles: Horizontal scaling requires a shared session store; otherwise each instance forgets who the user is. Every request does a database/lookup, which can add latency if the store isn’t fast enough. JWT – The Lone Wolf with a Signed Badge A JWT is a compact, URL‑safe string that contains claims (like sub , exp , roles ) and is cryptographically signed (HMAC or RSA).

Like many developers, designers, and digital marketers, my Instagram "Saved" collection had turned into a digital graveyard with over 5,000 bookmarked posts, reels, and carousels. The native Instagram web app offers virtually zero productivity tools: ❌ No full-text search across captions or hashtags ❌ No way to extract individual slides from carousel photo dumps ❌ No offline preservation (if a creator archives a post, it disappears forever) ❌ Existing web downloaders ask for account passwords, inject trackers, or bombard you with ads. So I spent the last few months developing Unlockt — a 100% free, MIT open-source, local-first Chromium extension and Node.js Express dashboard. --- ## 🏗️ Architecture & Engineering Highlights Here is how Unlockt is designed under the hood: ┌─────────────────────────────────┐ │ Chromium Extension (MV3) │ ──► Reads Instagram GraphQL via active session └────────────────┬────────────────┘ │ Local REST Sync ▼ ┌─────────────────────────────────┐ │ Express Backend (Port 3000) │ ──► SSRF-Hardened Proxy & HTTP 206 Video Streamer └────────────────┬────────────────┘ │ ┌────────┴────────┐ ▼ ▼ ┌──────────────┐ ┌───────────────────────────┐ │ data/saved. │ │ /thumbnails /videos │ │ json (DB) │ │ (Local High-DPI Storage) │ └──────────────┘ └───────────────────────────┘ 1. Zero-Password Session Scraping Rather than asking users for their credentials or running headless browser instances that trigger Meta account checkpoints, Unlockt operates as a Manifest V3 Chromium extension. It uses the cookies and CSRF tokens already present in your authenticated browser tab with randomized jitter delays (800ms - 2200ms) to respect rate limits. 2. 1-Click HTML5 Canvas Collage Studio One of my favorite features is the Carousel Studio . When you open a 10-slide photo dump, Unlockt extracts every slide and can render them onto an off-screen HTML5 <canvas> element to produce high-resolution moodboards ( 2x1 , 2x2 , 3x2 , 3x3 , and 5x2 ) with crisp 4px white margin div

The Day I Realized I Wasn't Building Apps For years, I thought I was building apps. That's what I called them anyway. A scheduler. A job bot. A healthcare platform. An AI project. A content tool. A browser automation system. Looking at my GitHub, they seem completely unrelated. Honestly, that's something I've worried about before. I have over a hundred repositories. If someone spends thirty seconds scrolling through them, I can imagine them thinking: "Wow. This person is all over the place." The funny thing is that I eventually realized the opposite was true. My GitHub is here: https://github.com/ashb4 The Scheduler That Wasn't A Scheduler One of my projects started life as a simple scheduler. That was the goal. I hated posting content manually. Open platform. Paste content. Upload image. Repeat. Again. And again. And again. It felt repetitive. It felt annoying. Most of all, it felt like something a computer should be doing instead of me. So I built a scheduler. At least, that's what I thought I was building. Then Things Got Weird The scheduler worked. But now I needed content. Then I needed analytics. Then I needed to know what content was working. Then I needed a way to track winners. Then I needed a way to reuse content. Then I needed platform-specific strategies. At some point I looked up and realized I wasn't building a scheduler anymore. I was building a system. A system for discovering, creating, publishing, measuring, and improving content. The scheduler was just one piece. Then I Started Looking At Everything Else That's when I noticed the same thing happening in almost every project I'd ever built. My job application tools weren't really job application tools. They were systems designed to reduce repetitive effort. My automation projects weren't really automation projects. They were systems designed to reduce repetitive effort. Even my AI projects weren't really about AI. They were systems designed to reduce repetitive effort. Different technologies. Diffe

Updating old codebases usually means hours of re-configuring environments, fixing broken dependencies, and hunting for lost secrets. In this walkthrough, we use Cursor IDE and the new Auth0 plugin to automatically resurrect a 2-year-old Python Flask application. Watch how AI seamlessly sets up the Auth0 CLI, generates environment variables, and configures our authentication tenant from scratch. What You'll Learn How to install and navigate the Auth0 plugin within Cursor IDE. Using AI prompts to automate Auth0 tenant creation and Flask secret key generation. Navigating the Auth0 CLI device authorization code flow inside an AI environment. Troubleshooting AI prompt timeouts and natively restarting development servers via Cursor. Resources & Links 🐙 GitHub Repo 💻 Auth0 Plugin in Cursor Marketplace 🔐 Auth0 Python/Flask Docs 📖 Auth0 CLI

ASP.NET Core Output Caching: How to Make Web APIs Faster in .NET When an API receives the same request repeatedly, performing the same database query and rebuilding the same response every time can waste valuable resources. For example, imagine this endpoint: GET /api/products If thousands of users request the same product catalog, your application might repeatedly: HTTP Request ↓ Controller ↓ Database Query ↓ Business Logic ↓ JSON Response For data that doesn't change frequently, this can create unnecessary database load. ASP.NET Core provides Output Caching to help solve this problem. Instead of executing the complete request pipeline every time, the application can temporarily store the generated response and reuse it for subsequent requests. In this tutorial, we'll look at how Output Caching works, how to configure it, how to invalidate cached responses, and when you should avoid using it. What Is Output Caching? Output caching stores the generated response from an endpoint. For example: First request ↓ GET /api/products ↓ Execute controller ↓ Query database ↓ Generate response ↓ Store response in cache Later: Second request ↓ GET /api/products ↓ Cached response ↓ Return immediately The database doesn't need to be queried again while the cached response is valid. Output Caching vs Response Caching These two concepts are often confused. Response Caching Response caching mainly relies on HTTP caching semantics and headers. Output Caching Output caching is controlled by ASP.NET Core and allows your application to decide which responses should be cached and for how long. Output caching provides more control over server-side response caching. 1. Add Output Caching Start by registering the output-cache services. var builder = WebApplication.CreateBuilder(args); builder.Services.AddControllers(); builder.Services.AddOutputCache(); var app = builder.Build(); app.UseOutputCache(); app.MapControllers(); app.Run(); The important pieces are: AddOutputCache() ↓ Configure cac

One of the easiest security mistakes is assuming that a WordPress plugin is still trustworthy simply because it has been installed for a long time. The folder is familiar. The plugin name is familiar. WordPress still loads. But is the code on disk still the code you approved? That question became very real for me when MatrixSwarm reported an unexpected change inside a plugin directory on a production server. The alert did not claim that it had discovered malware. It said something more precise and defensible: This plugin no longer matches its trusted baseline. That integrity warning led to a manual investigation. Inside a forgotten WordPress test plugin, I found a PHP backdoor. The important part of this story is not that an automated agent magically understood the attacker’s intent. It did not. The important part is that it noticed a change that was easy for a person—and WordPress itself—to overlook. That incident shaped the design of MatrixSwarm’s WordPress Plugin Guard. The problem: familiarity is not integrity WordPress sites often accumulate history: plugins that are no longer actively maintained; test plugins that were never removed; emergency fixes applied directly on the server; auto-updates that legitimately replace files; abandoned folders that nobody remembers installing; writable PHP files inside a public web root. A traditional malware scanner looks for known suspicious patterns. That is valuable, but it answers a different question. Plugin Guard asks: Has anything inside this approved plugin changed since the operator trusted it? It does not need to recognize a specific web shell. It does not need a signature for a particular backdoor family. It detects the loss of integrity first, then gives the operator evidence and control. How the baseline works When an operator approves a plugin, Plugin Guard walks the plugin directory and computes a SHA-256 digest for every file. It stores those relative paths and hashes as the plugin’s trusted manifest. A simpli

I'm building EverQuill, an AI-powered tabletop RPG platform — a game where an AI acts as your dungeon master, narrating the story and reacting to what you do. Every turn of that story is a message to a language model, and every message costs money. That cost isn't a problem you get to solve later, once you're big. It's a set of choices you make before anyone shows up, because the defaults you pick decide whether a bad day costs you a few cents or a few hundred dollars. Here are three decisions I made before I opened the alpha, and why. 1. When the tier is unclear, I reach for the stronger model This is tier-based routing : which model serves a request depends on who's asking. Better models write better stories and cost more; cheaper ones are faster and rougher. So free players get Claude Haiku (cheaper, ~$0.80 per million input tokens) and paying players get Claude Sonnet (stronger, ~$3.00 per million) — plus, because the platform is designed to route across providers, the same decision could hand a turn to a local model running through Ollama instead of a hosted one. That part is straightforward. The interesting case is the ambiguous one. My routing hands over the cheaper model only when a request is clearly free-tier; everything else — paid, alpha testers, admin, anything the system can't cleanly place as free — gets the stronger model. The instinct most people have is the reverse: default to cheap, protect the margin, don't spend money you don't have to. The reasoning: a rough, disappointing experience for someone who should have gotten a good one is a real cost — it just doesn't show up on the bill. It shows up as someone deciding the product isn't worth paying for. Meanwhile the money risk is capped elsewhere (more on that below), so biasing toward quality can't run away from me. Given a bounded downside on money and an unbounded downside on reputation, I'd rather err toward quality than toward cheap. 2. I stopped paying full price for the part that never chang

A browser preview can look correct while the downloaded image is wrong. The usual failure is timing: CSS eventually applies the custom font to the preview, but Canvas draws once. If the font is not ready at that exact moment, fillText() can silently use a fallback face. The user sees one design and downloads another. I ran into this while building GraffForge, a browser-based graffiti text tool. The free editor compares the same user-entered word across multiple bundled styles, then exports the selected result as a transparent 2048 × 2048 PNG. That gave the export path a clear contract: preserve the exact text; use the selected font; keep spacing, outline, shadow, and skew; fit inside a safe area; preserve real transparency; never upload the user's text or image. Here is the approach that made the output deterministic. 1. Treat export as a separate rendering target Do not enlarge the preview DOM and take a screenshot. Create a fresh Canvas with explicit bitmap dimensions: const EXPORT_SIZE = 2048 ; const canvas = document . createElement ( ' canvas ' ); canvas . width = EXPORT_SIZE ; canvas . height = EXPORT_SIZE ; const context = canvas . getContext ( ' 2d ' ); if ( ! context ) { throw new Error ( ' Canvas rendering is unavailable. ' ); } The width and height attributes define the actual PNG pixel dimensions. CSS sizing and devicePixelRatio are useful for an on-screen preview, but neither should determine the export contract. A fixed bitmap size also makes automated verification straightforward. 2. Load the font before measuring anything Canvas does not redraw automatically when a font finishes loading. Load the exact family, weight, size, and text before calling measureText() : await document . fonts . load ( `400 160px " ${ fontFamily } "` , text ); Passing the actual text is useful because the browser can confirm that the required glyphs are available. After this point, set the Canvas font explicitly: context . font = `400 ${ fontSize } px " ${ fontFamily } "` ;

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing What I Built Warm Hearth — a landing page for a comfort food restaurant built around one idea: everything on the menu comes from the same wood-fired hearth in the back. Instead of treating "comfort food restaurant" as a generic brief, I anchored the whole page to that single hearth: An interactive hearth centerpiece. Right after the hero, there's a hand-drawn CSS/SVG fire pit you can click to "stoke." The flame flares, embers burst upward, and a small honest counter tracks how many times you've stoked it this visit — no fake global numbers, just a real, session-based response to your click. Four dishes, each with real cultural identity. Ramen, warm pies, a cheesy pasta bake, and gulab jamun — each with its own hand-drawn SVG illustration and a border motif pulled from its own cuisine (a jade-and-gold double line for the ramen, a scalloped pastry edge for the pies, an Italian tricolor accent for the pasta, gold paisley tones for the gulab jamun) rather than one generic card style stretched across all four. Living detail, not static photos. Steam rises off the ramen, pies, and pasta bake using the same wisp animation as the hero's hearth, so the whole page reads as one consistent "warmth" language. The gulab jamun gets a syrup shimmer and drip instead, since steam isn't the right detail for a syrup-soaked sweet. Price tags that hang like real kitchen tickets — pinned by a string, swaying gently, and giving a small "flicked" swing on hover instead of sitting flat on the card. Mira, an illustrated host in the corner who offers a rotating table tip when you click her — a small personal touch instead of a static "contact us" widget. Built for actual use, not just to look good in a screenshot: keyboard-focusable tab filters, a skip-to-content link, aria-live regions on the interactive parts, and full prefers-reduced-motion support that disables every animation without breaking the page. Dem