标签：#devchallenge

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art . 🍩 Inspiration I write about WordPress plugins and PHP standards for a living, so when DEV dropped a "Comfort Food" theme for their Frontend Challenge, I didn't need to think twice about what to build. Not ramen, not pancakes — a donut. Specifically, the kind of donut that shows up on your desk right when a deploy breaks and somehow fixes everything. The twist I gave myself: don't just draw a static donut. Let people build one — pick a glaze, pile on toppings, then serve it — and do almost all of it in CSS, with JavaScript kept firmly in the back seat where the challenge rules ask for it to stay. That's how Donut Panic was born. 🎬 Demo Pick a glaze, load it up with sprinkles, drizzle, or powdered sugar, then hit Serve and watch it animate off the plate. 🛠️ Journey No JavaScript is driving the donut — :has() is Here's the part I'm most excited to talk about: every visual change in Donut Panic — the glaze swap, the toppings appearing, the donut lifting off the prep station and landing on the plate — is driven by plain checkbox/radio inputs and the :has() selector. Something like .kitchen:has(#serve:checked) .donut lets a parent element react to the checked state of an input buried somewhere inside it, which means the "Serve" button, the topping toggles, and the glaze picker are all just styled <label> s wired to hidden inputs. No click handlers, no state management — the checkbox is the state. JavaScript only shows up once, and it's not touching the art at all: it smooth-scrolls the stage into view on mobile after you hit Serve, because on a stacked mobile layout the donut can animate off-screen. That's the "sprinkle" of JS the challenge rules allow, used exactly the way it's meant to be — a UX nicety, not a rendering engine. Building the donut from the inside out The donut itself is layered rings, not a single flat shape: A base dough circle with a radial gradient doing double duty as both c

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry. Introduction: The...

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art . Inspiration In an Indian tech office, no product release, critical bug fix, or late-night deployment is complete without a 5-minute pantry chai break. A steaming clay Kulhad of Ginger Adrak Chai paired with crisp Garma-Garam Samosas is the ultimate comfort food that powers developers through endless coding sprints. This authentic workplace culture and rich street-food nostalgia inspired me to build a pure-CSS interactive art and corporate pantry scene. Demo Live Interactive Demo : Corporate Chai & Samosa Experience CodePen Embed : codepen.io GitHub Repository : Sayista-Yazdani/corporate-chai What I Built Adrak Chai & Samosa is an interactive web experience featuring: Pure CSS Hero Artwork : Handcrafted clay-textured Kulhad Chai cup with a shimmering tea surface, malai rim, and layered rising steam animations. Golden-brown samosas with crisp crimped edges, served on a traditional plate alongside mint and tamarind chutneys. Interactive Corporate Pantry Corner : Fully detailed tea kitchen equipped with a glowing gas stove, boiling tea saucepan with foam, spice jars ( Adrak , Elaichi , Chai Patti ), and stacked clay cups. 4 Distinct Characters : Rohan (Frontend Dev), Amit (Tech Lead), Priya (Product Manager), and Kaka (Pantry Specialist). Web Speech API & Audio Narration : Real voice speech synthesis with gender-matched voice profiles for each character. Character Gaze & Mouth Choreography : Characters automatically look toward whoever is currently speaking with dynamic gaze shifting, listening poses, and animated mouth movements. Journey & Tech Stack Technical Implementation CSS Artwork : Built entirely with CSS gradient meshes, polygon shapes, keyframe animations, and layered pseudo-elements ( ::before / ::after ). Audio Engine : Powered by native window.speechSynthesis with dynamic voice selection and text cleaning. State Management : Reactive data-speaker HTML attributes driving multi-char

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry . There's a shape of bug I've learned to distrust: the one where the safety net is bolted to the thing it's supposed to catch. I was reading Element Web's reporting code looking for something worth fixing when I hit a function that builds the whole Sentry payload as a single object literal — with two await calls sitting inside it. One of them asks the crypto layer for diagnostics. Optional diagnostics. Nice-to-have detail on a report that is already complete without them. I stopped there, because I could already see how that sentence ends. If the optional thing rejects, the object never exists. If the object never exists, there is no capture call. And the same pattern was waiting one directory over, in the rageshake path. The subsystem being diagnosed could prevent the diagnostic report from leaving the browser. Somebody decides to tell you what broke, and the broken part gets a veto. One deliberate press of a button, both explicit channels gone: the rageshake bundle and the manual Sentry event. I measured it at the boundary that actually counts — a real Sentry Browser SDK with a local, network-free transport. Under the same synthetic failure: zero serialized events before the fix, exactly one after. Same synthetic crypto rejection Before After collectBugReport(): rejected report completed with available diagnostics Sentry envelopes: 0 Sentry events: 1 unrelated context families: retained auxiliary error message or stack: absent Project Overview Element Web is the web client behind Element, a Matrix-based communication app. Its bug-report dialog can send two independent things: a rageshake bundle — logs and diagnostics packed into multipart form data and posted to a configured endpoint — and, when Sentry is configured, a single manually captured Sentry event. Both are explicit. Nothing leaves the browser unless a person opens that dialog and submits it. That framing shaped every deci

A scroll-driven cinematic page about vada pav. No framework, no build step. Just HTML, CSS, and a story worth telling. Dev.to Frontend Challenge submission.

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry . Project overview Nocturne Vania is a small pixel-art Metroidvania built with Godot 4. The game has interconnected rooms, enemy AI, save data, unlockable movement abilities, and a growing automated test suite. I hit this bug after adding a bell tower area. The new rooms, enemies, effects, and map markers used GDScript's class_name keyword so they could be referenced as global types. The new area worked in a freshly imported project and in CI. It did not always work in an existing local checkout. Bug fix or performance improvement Godot stores imported project data under .godot . An editor session that predated the bell tower scripts could still have an old global_script_class_cache.cfg . In that state, starting the game caused a parse error because scripts such as game.gd referred directly to global types that were missing from the stale cache. One room script, for example, inherited from a new global class by name: extends TowerRoom The test code also used the new classes for casts and enum access: var sentinel : = await _test_spawn_enemy ( "res://src/enemies/clockwork_sentinel.tscn" , Vector2 ( 320 , 300 ) ) as ClockworkSentinel if sentinel . _state == ClockworkSentinel . State . CHARGE : charged = true Those references were valid after Godot refreshed its global class registry. Before that refresh, the parser could not resolve them. CI missed the problem because the test workflow imported the project before running the suite. The import regenerated the cache, so CI always tested the healthy state. Local startup followed a different order and exposed the bug. Refreshing or deleting .godot could repair one checkout, but it left the startup dependency in the code. I wanted the game to parse even before the editor rebuilt the cache. Code I merged the complete fix as PR #95 in the project's private repository. Since the repository is not publicly accessible, the relevant before-and-af

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry. Prefer...

<!DOCTYPE html> Steam & Soul — A Bowl Written in CSS * { box-sizing: border-box; margin: 0; padding: 0; } :root { --wood1: #3b1710; --wood2: #71351f; --wood3: #a9572d; --red1: #43050c; --red2: #86101a; --red3: #d72b28; --broth1: #721006; --broth2: #c9330d; --broth3: #ff9228; --noodle1: #fff2ad; --noodle2: #ffd35c; --noodle3: #a95e1d; --gold: #ffbe42; } body { min-height: 100vh; overflow: hidden; display: grid; place-items: center; background: radial-gradient( circle at 50% 32%, #fffdf4 0%, #ffe9c7 28%, #e9a269 65%, #864029 100% ); font-family: Inter, Arial, sans-serif; } /* ===================================================== SCENE ===================================================== */ .scene { position: relative; width: 800px; height: 800px; perspective: 1100px; cursor: pointer; animation: floatingScene 7s ease-in-out infinite; } @keyframes floatingScene { 0%,100% { transform: translateY(0); } 50% { transform: translateY(-5px); } } /* ===================================================== TITLE ===================================================== */ .title { position: absolute; top: 30px; left: 0; width: 100%; text-align: center; color: #641f12; font-size: 36px; font-weight: 950; letter-spacing: 10px; text-shadow: 2px 2px 0 #ffd99e, 0 8px 20px rgba(70,20,0,.15); z-index: 200; } .subtitle { position: absolute; top: 82px; width: 100%; text-align: center; color: #8b4a2d; font-size: 11px; font-weight: 700; letter-spacing: 5px; z-index: 200; } /* ===================================================== LIGHT ===================================================== */ .light { position: absolute; left: 50%; top: 170px; width: 550px; height: 420px; transform: translateX(-50%); background: radial-gradient( ellipse, rgba(255,220,150,.4), transparent 68% ); filter: blur(20px); animation: lightPulse 5s ease-in-out infinite; z-index: 0; } @keyframes lightPulse { 0%,100% { opacity: .55; } 50% { opacity: .9; } } /* ===================================================== TABLE =======

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry . The Challenge: Flying Blind in Production Pull Request - https://github.com/NishikantaRay/InsightTrack/commit/a70ca0a00c8cd169a93b300cfcb450b5ecbde7f8 Before this summer, our analytics platform, InsightTrack , had a fundamental flaw in how it handled observability. We were tracking standard JavaScript errors via a basic window.onerror handler, but it was just noise. We had no stack traces, no grouped fingerprints, and absolutely no release context. If a customer integrated 10 different sites into our platform, we couldn't accurately tell them if a specific spike in errors was a brand-new issue or a resurrected bug from three deployments ago. We were flying blind, and our users were feeling the pain of delayed bug resolutions. The ultimate "bug" wasn't a single line of broken code; it was our entire error observability pipeline. The Solution: A Deep-Dive Sentry Integration We decided to smash this architectural bug by building a native, robust integration with Sentry . We didn't just want to add a widget; we wanted to bring Sentry's rich context (fingerprinted grouping, permalinks, regression status, and user-impact counts) directly into the InsightTrack dashboard so traffic and bugs could be watched side-by-side. How We Built It To make this work seamlessly at scale (where one customer might poll 10 independent Sentry projects simultaneously), we built a dual-path ingestion system: The Polling Backstop: We set up a bounded worker pool (to prevent slow projects from stalling the fleet) that polls the Sentry API every 5 minutes. To respect rate limits, we built an adaptive cadence —active projects poll frequently, while quiet or erroring projects exponentially back off. The Near-Real-Time Webhook: For instant visibility, we allowed users to point a Sentry Internal Integration webhook at our API. Using HMAC signatures verified in constant time against a stored secret, new or regressed is

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art . Inspiration Egusi soup with pounded yam. Jollof gets the headlines, but egusi is the quiet one that actually holds Nigerian homes together. Melon seeds, ugu, palm oil, and a dome of pounded yam you eat with your hands. I already sent this challenge a love letter to jollof for the Perfect Landing prompt. This is the companion piece, and it targets a different audience: not a flat poster, but a photograph with real depth. The entire table sits in a single CSS perspective plane, so the bowl is genuinely a bowl. You look down into it. Demo A morsel of pounded yam is resting on top of the dome. Press "Dip the yam" and watch it lift off, cross the table, drop into the soup and come back stained. No JavaScript anywhere near it. Journey The rule I set myself: zero JavaScript. The one interactive moment runs on a checkbox and a sibling selector. The checkbox stays keyboard focusable, the label carries a visible focus ring, and if you've asked your system for reduced motion, the morsel skips the flight and just shows up stained. The whole scene is sized in container query units, so it scales as one object from a phone to a desktop without a single media query for layout. Some of the tricks I'm proud of: The table is one plane with transform-style: preserve-3d and a rotateX , so everything standing on it uses translateZ to mean "up off the table" The bowl is six rings flaring up the Z axis. The top two are masked hollow, otherwise, they paint straight over the soup, and the whole thing reads as a solid disc. That bug is what taught me the technique The soup sits below the rim on the Z axis, so you see the inner wall and the shadow it throws across the curds The pounded yam is six contours stacked into a dome, each one a little brighter as it climbs toward the light The egusi curds are eleven stacked radial gradients, the palm oil pools at the rim through an inset shadow, and the oil sheen is a blurre

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art. ...

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art . Inspiration I chose to build a classic Dum Biryani — the ultimate comfort food! 🍛 There is nothing quite like opening a steaming handi of biryani and seeing the rich, saffron-colored rice dotted with fried onions, mint, and spices. It's a dish that brings people together and feels like a warm hug, making it the perfect inspiration for the Comfort Food challenge. Demo Here is my CSS Art representation of a traditional Biryani Handi! I built this primarily using vanilla CSS to create the realistic clay texture of the pot, the individual grains of rice, the steam animations, and the garnishes. I added a tiny bit of JavaScript just for a subtle mouse-parallax tilt effect and a saffron sparkle when you click the pot. https://github.com/pandeynitish23/dev_css_chalange/ https://dev-css-chalange.nitishkumar-nk-np.workers.dev/ Journey Building this was a really fun exercise in CSS gradients and positioning! What I'm most proud of: The Clay Handi: I used layered radial and linear gradients along with inset box shadows to give the pot a realistic, 3D clay texture with lighting highlights. The Rice & Garnishes: Creating individual rice grains, mint leaves, and onion crisps using CSS border-radius and positioning was tedious but incredibly rewarding when it all came together. The Atmosphere: Adding animated steam and floating background spice particles helped bring the scene to life and make it feel hot and fresh. It was a great challenge keeping the JavaScript minimal and relying on pure CSS for the heavy lifting of the art itself!

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing Mexico is our heritage. Yet, we have no family there to visit. That sounds sadder than it is. What it actually meant, for the years before my wife and I were married and most of our time off since, is that we had to go find it ourselves. No family kitchen waiting. No grandmother's recipe with an address attached. Just the two of us and a country that is ours and that we did not know. So we did what every hungry person in a new city does...we ate. Six cities, six completely different cuisines, and somewhere in there it stopped feeling like traveling. A tlayuda from a stand outside Santo Domingo in Oaxaca. An hour in line at El Yaqui with a michelada in Rosarito. Different food every time. Same feeling every time, and there is no English word for that feeling. There is a Spanish one. What I Built Sobremesa is the time you stay at the table after the food is gone, still talking. Not the meal. The part after the meal. That is the whole site. Six meals across six Mexican cities, and the thing it measures is not how good the food was. It is how long we stayed. Tijuana, one hour. Rosarito, two. Ensenada, one. Guadalajara, ninety minutes. Mexico City, two hours. Oaxaca, two. The page adds them up at the end. Nine hours and thirty minutes at six tables. Comfort food usually means a kitchen you can go back to. We do not have one over there. So the six tables became it. The stand at Plaza Santo Domingo is the family table. The hour in line at Tacos El Yaqui is the Sunday afternoon table. Each entry has the dish, where we ate it, one verified fact about the food, and one line that is just ours, from our experience. There is a form at the bottom where you add your own table and download a card of it, generated in your browser. Nothing gets sent anywhere. One static HTML file. No framework, no build step, no tracking, no cookies, no storage. Two fonts off Google Fonts and nothing else. Designed an

What I Built Gnoke Books works like an actual printed magazine on a table — you grab the...

Hey all, as part of our expanding challenge program we want to update and clarify some challenge...

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry. This happened a...

This is my official entry for the Frontend Challenge - Comfort Food Edition under the CSS Art category. Inspiration 🍚🐟 When thinking about "comfort food," I didn’t want to pick a generic burger or pizza. I wanted to build something tied directly to home and my culture: Ilish Polao (Hilsha fish cooked with fragrant rice). Hilsha is the national fish of Bangladesh, and Ilish Polao—paired with a side of spicy-sweet tomato chutney—is the ultimate comfort meal in our house. Translating a dish loaded with personal memory into raw CSS felt like the perfect way to combine culture with code. Demo mahbubasultanaety.github.io GitHub Repository: MahbubaSultanaEty / hilsha-polao How I Built It Instead of relying on SVGs or background images, every visual element in this piece is built from scratch with HTML elements and pure CSS styling. Here is a quick breakdown of what went into the scene: Fish-Shaped Platter: Built using layered border-radius curves and subtle box-shadows to mimic ceramic depth. The Polao Mound: Formed using rounded CSS containers with layered gradient textures. Scattered Rice Grains: Instead of hardcoding dozens of tags in HTML, I used a tiny JS script to generate and randomly position rice grains over the mound so the texture feels natural rather than grid-like. The Hilsha Piece: Crafted with CSS clip-paths and custom border geometries to get the signature cut and inner texture right. Animated Steam: CSS keyframe animations controlling opacity and vertical translate transforms to give the food a hot, fresh feel. Garnishes & Sides: Added cinnamon sticks, bay leaves, green chilies, and a small side bowl of tomato chutney to complete the plate. The Sprinkle of Javascript: Rice Generation Hardcoding hundreds of rice grains in static HTML felt redundant. So I used the minimal for loop JS approach to scatter them: This tiny bit of scripting saved me time and made the plate look organic every single render. Takeaways Building CSS art always forces you to think dif

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry. Did anyone ask for...

Deliberately best-effort — a settings tweak failing shouldn’t fail a deployment that already succeeded. It surfaces as public: false in the response and a visible warning in the UI, rather than silently handing someone a broken link. Live Stripe checkout failed on day one. Test mode worked perfectly. Live mode returned: Invalid line_items[0]: the product tax code is missing… Product tax code is required for Managed Payments, which is enabled by default on your account. A whole class of bug that only exists in production. I reproduced it directly against Stripe’s API before touching code, then opted the session out of Managed Payments — rather than inventing a tax classification, since whether to collect sales tax is a business decision, not a code one. The meta-lesson Every one of these five bugs was invisible to the test suite. The unit tests were green the entire time — because they tested my parsing logic, and every bug was in the query I sent or the transport I sent it over. Four of them were only findable by hitting the live endpoint and reading actual output. The 1996–2006 bug in particular looked like a total success from every angle except one: 566 results, HTTP 200, tests passing, correct shape. You had to actually look at the dates. Best Use of Sentry Not submitting to this category — DAREALTYTE doesn’t currently use Sentry. Worth being straight about it, since this project is a decent argument for adding it. Bugs 4 and 5 both returned HTTP 200 with well-formed payloads. Error monitoring wouldn’t have flagged either one; nothing threw. What would have caught them is exactly what I ended up doing by hand — inspecting real production responses and noticing the values were wrong even though the shape was right. The one place Sentry would have paid off immediately is Bug 3. The Safari Load failed was reported to me as a screenshot from a phone, with no stack trace and no way to reproduce it in my own environment. A Session Replay or a captured client-side exce

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry . Every developer has experienced that moment when a project works perfectly but doesn't feel perfect. That was exactly what happened while I was building my Gem Price Estimator , a web application designed to estimate gemstone values based on multiple characteristics and pricing rules. The calculations were accurate. The interface looked good. But something bothered me. It wasn't as responsive as I wanted it to be. That small delay was enough to make the application feel slower than it should, and I knew there had to be a better way. This wasn't about fixing a crash or a broken feature. It was about finding the hidden performance bottleneck. The Project The Gem Price Estimator analyses several gemstone properties and combines them to generate an estimated market value. The estimation process considers multiple factors, including: Carat weight Color Clarity Cut Other pricing adjustments Every user interaction triggered a complete recalculation of the estimated value. Initially, this approach worked well while the project was small. As the pricing logic became more sophisticated, however, the application started doing significantly more work than necessary. The First Sign Something Was Wrong Nothing was technically broken. There were no JavaScript errors. No failed requests. No database issues. The application simply felt slower every time users adjusted the estimator. Those tiny delays might seem insignificant individually, but together they reduced the smoothness of the overall experience. I wanted every adjustment to feel nearly instant. That became my goal. Investigating the Problem My first assumption was that the issue was caused by database operations. So I started checking: Database queries Network activity Browser Developer Tools Console logs Individual calculation steps Surprisingly... None of those were the real problem. The application wasn't waiting on the database. It wasn'