DEV Community: Hamed Farazi

Burger Atelier — The Burger, Reimagined 🍔

Hamed Farazi — Tue, 11 Aug 2026 12:21:21 +0000

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

What I Built

For this challenge, I wanted to take a familiar comfort food and give it a more refined digital experience.

I built Burger Atelier, a modern landing page centered around the idea of burgers as more than just fast food — they can be crafted, customized, and presented like an experience.

The goal was to create a landing page that feels polished while keeping the experience simple and intuitive.

Highlights
🍔 A bold food-focused visual design
📱 Responsive layout across screen sizes
✨ Interactive UI elements and micro-interactions
🎯 Clear calls-to-action and visual hierarchy
♿ Accessibility-conscious structure and interactions
⚡ Modern React-based frontend
🧩 Reusable components and clean project structure
Demo

🌐 Live Demo:

frontend-challenge-comfort-food-edi-alpha.vercel.app

💻 Source Code:

HamedFarazi / Frontend-Challenge---Comfort-Food-Edition-Perfect-Landing

Perfect Landing: Comfort Food

Burger Atelier

Premium interactive burger studio for the DEV Community Frontend Challenge — Comfort Food Edition.

Run

npm install
npm run dev
npm run build

Stack

React · TypeScript · Vite · Tailwind CSS v4 · CSS burger craft

View on GitHub

Journey

I approached the project by first thinking about how a food brand could communicate its personality through its landing page.

Instead of treating the page as a collection of sections, I focused on creating a visual flow that guides the user from the hero section toward the menu and the main call-to-action.

One of the things I enjoyed most was balancing the visual side of the design with practical frontend considerations. A food landing page can easily become visually heavy, so I tried to keep the interactions clear and the content easy to scan.

Building the project with React also gave me the opportunity to structure the UI into reusable pieces rather than treating the page as one large component.

What I learned

This challenge was a good reminder that a polished landing page isn't only about making things look good.

The small details matter:

How quickly users understand what the product is
Whether the primary action is obvious
How the layout behaves on smaller screens
Whether interactive elements feel intentional
How accessible the experience remains beneath the visual layer

I'm particularly happy with how the final design combines a playful food theme with a more premium visual direction.

What's Next?

I'd like to continue experimenting with the concept by adding more interactive ordering flows, richer menu interactions, and potentially turning Burger Atelier into a small multi-page restaurant experience.

Thanks to the Frontend Challenge team for putting together this challenge! 🙌

Built with React and modern frontend tools.

🍔 The Perfect Burger — CSS Art

Hamed Farazi — Tue, 11 Aug 2026 11:25:10 +0000

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

🍔 The Perfect Burger

Inspiration

For this challenge, I wanted to create something familiar, fun, and comforting: a classic burger.

Instead of using images or pre-made assets, I decided to build the entire burger from scratch using HTML and CSS.

Every ingredient is created with CSS, including the buns, lettuce, tomato, onion, melted cheese, and grilled beef patty.

The goal was to make something that looks like a burger at first glance, but becomes more interesting when you discover that the entire artwork is built with HTML and CSS.

Demo

🚀 Live Demo: https://frontend-challenge-comfort-food-edi.vercel.app/

💻 Source Code: https://github.com/HamedFarazi/Frontend-Challenge---Comfort-Food-Edition

You can also interact with the burger to reveal and separate its individual ingredients.

✨ Features

🍞 CSS-crafted toasted buns
🥩 Grilled beef patty with CSS texture
🧀 Melted cheese with organic drips
🥬 Layered lettuce
🍅 CSS tomato slices
🧅 CSS onion rings
✨ CSS gradients and shadows
🎬 Interactive ingredient reveal mode
🖱️ Hover and 3D interactions
♿ Keyboard accessible interactions
📱 Responsive design
🌓 prefers-reduced-motion support

🛠️ Built With

HTML5
CSS3
Vanilla JavaScript

🎨 CSS Techniques

Gradients
Pseudo-elements
Clip-path
CSS transforms
CSS animations
Box shadows
CSS variables
3D perspective

Journey

I started this project with a simple idea: create a burger using only HTML and CSS.

The first version was intentionally simple, but as I worked on it, I focused on making the ingredients feel more organic, dimensional, and visually appetizing.

The most challenging parts were creating the melted cheese, the grilled texture of the beef patty, and making all of the ingredients feel like they were physically stacked together.

I used CSS gradients, pseudo-elements, clip-path, transforms, shadows, and animations to create the different ingredients and their textures.

One of my favorite parts is the interactive reveal mode. Instead of keeping the burger as a static illustration, users can separate the ingredients and see each layer individually.

This also became a way to demonstrate that the burger is actually built from individual HTML/CSS elements.

What's Next?

I'd like to continue experimenting with CSS-based food illustrations and push the interaction and visual details even further.

Thanks for checking out my submission! 🍔

Why (and When) You Should Actually Use useMemo and useCallback

Hamed Farazi — Tue, 11 Aug 2026 08:29:43 +0000

If you've spent any time in a React codebase, you've probably seen useMemo and useCallback sprinkled everywhere — sometimes on every single function and computed value, "just in case." The irony is that this habit often makes an app slower, not faster, while also making the code harder to read.

This article is about building an honest mental model for these two hooks: what they actually do under the hood, when they genuinely help, and when they're just noise.

What these hooks actually do

useMemo and useCallback don't make anything "faster" by default. They cache a value between renders and only recompute it when its dependencies change.

const value = useMemo(() => computeExpensiveValue(a, b), [a, b]);
const fn = useCallback(() => doSomething(a, b), [a, b]);

useCallback(fn, deps) is really just useMemo(() => fn, deps). Same mechanism, different return type (a function reference instead of a value).

Two things matter here:

The caching itself has a cost. React has to store the previous dependency array, compare it on every render, and hold onto the cached value in memory.
You only benefit if something downstream actually cares about referential stability or expensive recomputation.

If neither of those is true, you're paying the comparison cost for zero benefit.

The case where it's obviously worth it: expensive computations

This one is uncontroversial. If you have a genuinely heavy calculation — sorting a large array, filtering thousands of rows, running some numeric computation — recomputing it on every render (including renders triggered by unrelated state) is wasteful.

function ProductList({ products, filters }) {
  const filtered = useMemo(
    () => products.filter(p => matchesFilters(p, filters)),
    [products, filters]
  );

  return <List items={filtered} />;
}

Without useMemo, every re-render of ProductList — even one triggered by, say, a tooltip's hover state — would re-run the filter over the whole array. With it, the filter only reruns when products or filters actually change.

The key word is expensive. Filtering 20 items is not expensive. Filtering 20,000 items, or running a computation with real algorithmic weight, is. Don't reach for useMemo reflexively — profile first, or at least reason about the actual cost.

The case that trips people up: referential stability

This is where most of the confusion lives. useCallback and useMemo matter for referential stability in two situations:

1. When a value or function is a dependency of another hook.

function SearchBox({ onSearch }) {
  const debouncedSearch = useMemo(
    () => debounce(onSearch, 300),
    [onSearch] // if onSearch changes identity every render, this debounce is recreated every time
  );
  // ...
}

If onSearch isn't stable, useEffect, useMemo, or a custom hook relying on it as a dependency will re-run constantly, potentially defeating the entire purpose of the debounce, subscription, or cache it's feeding into.

2. When a value is passed to a memoized child component.

const ExpensiveChild = React.memo(function ExpensiveChild({ onClick }) {
  // heavy render logic
});

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

  // Without useCallback, this is a NEW function every render,
  // which defeats React.memo on ExpensiveChild entirely.
  const handleClick = useCallback(() => {
    console.log('clicked');
  }, []);

  return (
    <>
      <button onClick={() => setCount(c => c + 1)}>{count}</button>
      <ExpensiveChild onClick={handleClick} />
    </>
  );
}

Here, React.memo on ExpensiveChild only pays off if the props it receives are stable. If handleClick is a new reference on every render, React.memo does nothing — the child re-renders anyway, and you've added the overhead of React.memo's comparison for no benefit.

This is the important part: useCallback without React.memo (or a dependency array somewhere downstream) usually does nothing useful. The two are a pair. If nothing consumes the stable reference, you're just adding bookkeeping.

When it's not worth it

Simple values or inline functions passed to plain DOM elements. <button onClick={() => setOpen(true)}> does not need useCallback. DOM elements aren't memoized components; a new function reference every render costs essentially nothing.
Cheap computations. const total = a + b doesn't need useMemo. The comparison overhead of the hook can genuinely exceed the cost of just recalculating.
"Just in case" usage without a memoized consumer. If nothing downstream is React.memo-wrapped and nothing uses the value as a dependency, the memoization has no one to benefit from it.
Values that change on every render anyway. If a dependency changes every render, useMemo will recompute every time too — you get the comparison cost and the recomputation.

A practical mental checklist

Before adding useMemo or useCallback, ask:

Is this computation actually expensive, or does it just look intimidating? (Measure if unsure.)
Does something downstream depend on referential equality — a React.memo child, a useEffect dependency, a custom hook's cache key?
Do the dependencies change rarely relative to how often the component re-renders? If they change every time anyway, memoization buys nothing.

If the answer to #1 or #2 is no, you probably don't need the hook.

A note on the React Compiler

It's worth mentioning: the React team has been building an automatic compiler (React Compiler, formerly "React Forget") specifically to memoize things like this automatically, precisely because manual useMemo/useCallback placement is easy to get wrong and tedious to maintain. That's a strong signal about how the React team itself views manual memoization — as a mechanism you should reach for deliberately, not a reflex.

Takeaway

useMemo and useCallback are not performance switches you flip on by default. They're targeted tools for two specific problems: avoiding expensive recomputation, and preserving referential stability for something that actually checks for it. Used with intent, they meaningfully help. Used everywhere, they add cognitive overhead and runtime cost while often fixing nothing at all.

Where to get cover images for a post like this: for genuinely free-to-use, no-attribution-needed photos, Unsplash and Pexels are the standard choices for dev.to-style covers — search something like "code" or "abstract programming." For a more on-topic illustration (e.g. a diagram-style cover), you can also generate a simple custom SVG/graphic yourself — dev.to covers are just images, so anything royalty-free works.

How I Used BFS to Find the Shortest Route in Tehran Metro with React

Hamed Farazi — Mon, 10 Aug 2026 22:48:07 +0000

When I started building Metrino, a Tehran Metro route planner, I had a simple question:

«How can I find the shortest route between two metro stations?»

The UI was only one part of the problem. Underneath the map and station selectors, I needed a way to represent the Tehran Metro network and calculate a route between two stations.

The solution was to model the metro network as a graph and use Breadth-First Search (BFS) to find the shortest path.

🚇 Turning the Metro Into a Graph

Instead of thinking about the metro as a visual map, I represented it as a graph.

Each station is a node.

Each connection between two stations is an edge.

For example:

Station A
│
▼
Station B ─── Station C
│
▼
Station D

In my data model, each station contains a list of connected stations.

This means I can ask:

«"Which stations can I reach directly from this station?"»

The application builds a bidirectional adjacency map when the metro data is initialized:

const adj = new Map>();

this._stations.forEach((s) => {
if (!adj.has(s.id)) adj.set(s.id, new Set());

s.connectedStationIds.forEach((nid) => {
adj.get(s.id)!.add(nid);

// Add reverse direction
if (!adj.has(nid)) adj.set(nid, new Set());
adj.get(nid)!.add(s.id);

});
});

This gives the route finder a structure that is easy to traverse.

🧭 Why BFS?

For the first version of the route planner, I wanted to minimize the number of station-to-station hops.

That's where BFS works well.

Breadth-First Search explores a graph level by level:

Start
│
├── A
├── B
└── C
│
├── D
├── E
└── F

It first explores the stations closest to the starting station, then moves to the next level.

Because every connection has the same cost in this version of the problem, the first route BFS finds to the destination is the route with the fewest hops.

💻 The Actual BFS Implementation

Here is the actual "findPath" implementation from Metrino:

findPath(fromId: string, toId: string): string[] | null {
if (fromId === toId) return [fromId];

const visited = new Set();

const queue: Array<{ id: string; path: string[] }> = [
{ id: fromId, path: [fromId] },
];

visited.add(fromId);

while (queue.length > 0) {
const { id, path } = queue.shift()!;

const neighbors = this._adjacency.get(id) ?? [];

for (const neighbor of neighbors) {
  if (neighbor === toId) {
    return [...path, neighbor];
  }

  if (!visited.has(neighbor)) {
    visited.add(neighbor);

    queue.push({
      id: neighbor,
      path: [...path, neighbor],
    });
  }
}

}

return null;
}

Let's break it down.

Handle the same station

if (fromId === toId) return [fromId];

If the origin and destination are the same station, there is nothing to calculate.

Keep track of visited stations

const visited = new Set();

Without this, the algorithm could keep visiting the same stations again and again.

I immediately mark the starting station as visited:

visited.add(fromId);

Create the queue

const queue: Array<{ id: string; path: string[] }> = [
{ id: fromId, path: [fromId] },
];

The queue contains the station we're currently exploring and the path that led to it.

For example:

{
id: "station-b",
path: ["station-a", "station-b"]
}

This makes it easy to return the complete route once we reach the destination.

Explore the graph

while (queue.length > 0) {

As long as there are stations waiting to be explored, BFS continues.

We remove the first item from the queue:

const { id, path } = queue.shift()!;

Then get all directly connected stations:

const neighbors = this._adjacency.get(id) ?? [];

Check the destination

if (neighbor === toId) {
return [...path, neighbor];
}

As soon as BFS reaches the destination, we return the complete station sequence.

For example:

Station A
↓
Station B
↓
Station C
↓
Station D

The returned result would look like:

[
"station-a",
"station-b",
"station-c",
"station-d"
]

Add unvisited stations to the queue

if (!visited.has(neighbor)) {
visited.add(neighbor);

queue.push({
id: neighbor,
path: [...path, neighbor],
});
}

This is what allows BFS to move through the network level by level.

🔄 What About Line Transfers?

Finding the shortest path is only part of the problem.

Tehran Metro has multiple lines, so after finding the station path, I also need to determine where passengers change lines.

The route service looks at consecutive stations and finds their shared line:

private _getCommonLine(a: Station, b: Station): number | null {
for (const line of a.lines) {
if (b.lines.includes(line)) return line;
}

return null;
}

Then the route builder can detect when the route changes from one line to another.

For example:

Line 1
│
│
▼
Station A
│
▼
Transfer Station
│
│
▼
Line 4
│
▼
Station B

The transfer is recorded separately from the BFS path.

⏱️ Estimating Travel Time

BFS gives me the route, but it doesn't tell me how long the journey will take.

So after finding the path, Metrino calculates an estimated travel time using:

approximate distance between stations
an average train speed
station dwell time
transfer time

The current implementation uses:

const TRANSFER_PENALTY_MIN = 3;
const STATION_DWELL_SEC = 30;
const AVG_SPEED_KMH = 40;

The total estimate is then built from these values.

These are estimates, not official Tehran Metro schedules.

🧩 Separating the Algorithm From the UI

One thing I wanted to avoid was putting route calculation directly inside React components.

Instead, I separated the responsibilities:

React UI
↓
MetroRouteService
↓
MetroDataService
↓
Metro Graph / Metro Data

"MetroDataService" handles the station, line, connection, and adjacency data.

"MetroRouteService" takes the resulting path and turns it into a complete route containing:

origin
destination
station sequence
segments
transfers
distance
estimated time

This separation makes the UI much easier to work with.

📈 What's Next?

BFS was a good starting point because the first version of Metrino only needed to minimize the number of station hops.

But the real-world "best route" isn't always the route with the fewest stations.

For example, a slightly longer route might be better if it has fewer transfers or takes less time.

That's why one of the next improvements I'd like to explore is weighted pathfinding, using algorithms such as Dijkstra's algorithm or A*.

The goal would be to consider things like:

Station count

Travel time
Transfer penalties

instead of only counting station hops.

🚀 What I Learned

The biggest lesson from building this feature was that many problems that look like UI problems are actually data structure and algorithm problems.

The metro map is a UI.

But underneath that UI, it's a graph.

Once I represented the metro network as a graph, route calculation became much easier to reason about.

BFS gave me a simple and reliable starting point, and it was enough to power the first version of the route planner.

🚇 Try Metrino

I built Metrino as a Persian-first Tehran Metro web application with React, TypeScript and Vite.

Live Demo: https://metrino.vercel.app/

GitHub: https://github.com/HamedFarazi/metroapp

The project is open source, and I'm continuing to improve the routing, maps, PWA experience, and accessibility.

Thanks for reading 💫