DEV Community: m.rezanahi

Learning Backend the Old-School Way: A Review of Ethan Brown’s Book

m.rezanahi — Fri, 05 Dec 2025 12:07:54 +0000

Intro :

I wanted to go back to the days when I was building Plants vs. Zombies clones , so I decided to start a new side project for myself.
But as a front-end developer, taking on the backend side as well can be challenging. Still, I made my decision and not by copy–pasting from chatbots, but by actually learning backend concepts.

I chose Express. The main reason was simple: I’ve already worked a lot with JavaScript, so I didn’t need to learn a completely different language for the backend, like Python or C#.
But then the question was: How do I learn backend concepts? Isn’t Express difficult?

I decided to learn through a book, maybe an unusual choice in the age of AI, but to be honest, I don’t regret it at all.

Learning Express with a Book :

In my opinion, learning through reading is the best way to learn (at least for me). I’ve been learning for several years now, from front-end topics like CSS, JavaScript, and React to optimization, testing, and more. And based on my experience, every time I try to learn something by reading, I’m able to understand it much more deeply. I’ve never been able to get the same result from video courses.
Now, whether that reading comes from documentation, articles, or books doesn’t really matter.
I think we could write and talk about the benefits of reading until tomorrow.

To learn Express and be able to build the backend of my project by myself, I chose the
Web Development with Node and Express, 2nd Edition
written by Ethan Brown.
It’s been a few days since I finished reading the book and made good progress on my project, and I think this is a good time to review the book, maybe my experience will be useful for others too.

Inside the Book :

This book is over 300 pages long and has 22 chapters.
A very important point is that this book is not only about Node.js or Express, but it also includes important backend concepts such as security, debugging principles, and more.
Throughout the book, you build a website, and in each chapter you learn new concepts and add them to your site. (This is a positive feature of the book because it teaches concepts in a practical way. However, I didn’t follow its sample code, I studied the concepts and then went to my own project and implemented them based on my own needs.)

Chapters 1 to 3 are introductory and talk about the history and basic concepts of Node.js and Express. Studying these chapters was interesting for me since I had no backend background. Maybe for someone who is already familiar with these basics, it would be better to quickly review them or move on to the later chapters.

Chapter 4 talks about principles and best practices, and in my opinion, it’s for people who have never had programming experience before. It covers topics like the importance of using version control, which are obvious for anyone who has prior programming experience.

Chapter 5 is about QA and discusses testing and its types. Studying these concepts was very interesting for me as a front-end developer, and I think everyone should at least know the basics of writing tests and the different types of tests.

Chapter 6 is practically the beginning of the most important topics and talks about the request and response objects in Express. I can pretty much say that everything you do in backend with Express is receiving a request from the user (request object), analyzing it to understand what the user exactly wants, and then deciding what you want to return to the user (response object).
The concepts in this chapter are explained very, very simply and are easy to understand.

Chapter 7 is about template engines.
I skimmed this chapter very quickly because in my own project I’m using React for the frontend, and I didn’t need a template engine.
If you want your backend to directly display HTML to the user instead of sending data to a frontend, you need to use a template engine, and this chapter teaches you that.

Chapter 8 is about handling forms, one of the main ways to collect data from users. In this chapter, you learn how to send real data from an HTML form to the backend and process it.

Chapter 9 explains cookies and sessions, which you must know even for implementing a simple authentication system. The way cookies and sessions work and how they are stored and used in Express is fully explained in this chapter.

Express is very lightweight, and for most tasks you need to install and use middleware. Chapter 10 explains middleware completely, introduces them, and teaches you how to create your own middleware and use it.

Middleware is executed in what’s known as a pipeline. You can imagine a physical pipe, carrying water. The water gets pumped in at one end, and then there are gauges and valves before the water gets where it’s going.

Chapter 11 talks about how to send emails to users, which was very important for my project since users need to be able to reset their passwords :)
This chapter explains different methods of sending emails and the pros and cons of each.

Chapter 12 contains important content about Production Concerns and is somewhat advanced. It’s more suitable for people who have more backend experience, but I think reading it is useful for everyone because it helps you understand the differences between running an app in different environments.

Chapter 13 is where the database comes in. The book uses MongoDB, while my project uses Postgres, but in any case, this chapter talks about different ways to store content for persistence, which is really useful.

Chapter 14 is about routing in Express and covers almost everything you need to know, from URL architecture to organizing routes in Express.

Chapter 15 talks about REST APIs and discusses principles like error handling in APIs and more.

Chapter 16 is about serving static content in Express and teaches very useful tips about caching.

Chapter 17 talks about the MVC architecture in Express and explains how to implement it.

Chapter 18 , which is a relatively long chapter, talks about security. Useful topics are discussed here, but I skimmed through it quickly because security is not my current priority. Still, studying this section can give anyone a good overview.

Chapter 19 is about using third-party APIs that you can integrate into your projects. I also just skimmed this chapter because I don’t plan to connect to these APIs right now.

Chapter 20 is about debugging principles and presents interesting points:

“The first and most important principle of debugging is the process of elimination.”

This topic isn’t limited to backend developers, even as a front-end developer, I’ve used it a lot.

Chapters 21 and 22 talk about the app’s launch day and what comes after that, meaning the principles of maintaining code and the project. They help you maintain your code in a way that prevents it from turning into a complex and terrible system that no developer would dare touch later on :)

Is This Book Worth It?:

This book was very useful for me and taught me many backend concepts, but I think if someone is already familiar with the basic backend concepts, they might get bored while reading this book. I think this book is more suitable for beginners.
The book uses good examples and explains concepts really simply, but in some parts it could make the explanations a bit shorter. In my opinion, some chapters were stretched too much, and it made me think to myself, “Ugh, why doesn’t this chapter end?”

Right now, for implementing more advanced topics, I use the official Express documentation, and honestly, now that I’m familiar with the basics of Express, using the official docs has become very easy for me.
If someone already has backend experience and wants to start with Express, I think they can go directly to the documentation and they don’t need to read the book.

I hope the explanations I’ve provided help people make a decision about whether to read this book. I’m really excited for my project to be ready and to share it with you.

When React’s Philosophy Isn’t Enough and Data Attributes Save the Day

m.rezanahi — Mon, 17 Nov 2025 06:24:25 +0000

The Data-Attr Dilemma :

Data attributes can be incredibly useful, but in React they often feel like they go against the framework’s core patterns and philosophy. Still, I eventually ran into real problems where I had no choice but to use them.

So today, I want to talk about this little tension between data attributes and React, and explore when they actually do make sense.

A Quick Look at Data Attributes :

Let’s first do a quick refresher on data attributes in plain HTML , then we’ll dig into the real question: how (and why) React sometimes clashes with them.
In HTML, we can apply different attributes to any tag, and one of these is the data attribute. Any attribute that begins with data- is considered a data attribute. The part that comes after "-" is treated as the attribute’s key, and we can assign any custom value to it. For example:

<div data-id="50" data-something="something"></div>

The main purpose of data attributes is to store custom data directly on elements. In this example, the div element holds two pieces of information: an id and a something value. In other words, data attributes allow us to store non-visual, non-structural information inside an element.

There are two primary ways to access these values in JavaScript:

1.Using the getAttribute method:
In this case, we pass the full attribute name as a string to the method, and it returns the value of that attribute:

div.getAttribute('data-id'); // 50
div.getAttribute('data-something'); // something

2.Using the dataset object:
Every element has a dataset property, which contains a key–value list of all the data attributes defined on that element. For example:

div.dataset; // { id: '50', something: 'something' }

The important point here is that the keys inside dataset are exactly the parts that come after data- in the HTML. Accessing the values is also straightforward:

div.dataset.id;
div.dataset.something;

This is a quick overview of how data attributes work. They seem useful and pretty interesting, right?
However, when we step into the world of React, this simple concept doesn’t fit as cleanly into its philosophy.

React Already Has Your Data :

In React, data attributes are generally unpopular, and for good reason. Using them often feels like you don’t fully understand how React works.

React is all about generating the UI directly from your data. Anyone who has even a little experience with React knows that most of the time, you’re mapping over an array of data, rendering a component for each item, and passing the data down as props. Throughout this process, your UI is always a direct reflection of your data.

So where does that leave data attributes?
The short answer: we usually don’t need them at all. The data is already available because the UI itself is generated from it. Consider the example below:

A while ago, I read an article that showcased an interactive chart built using data attributes. I decided to try building a similar chart in React, but without using a single data attribute. And it worked perfectly.

Here’s the basic idea. I have an array of data like this:

const Data = [
  { id: "1", name: "Typescript", color: "#0046FF", percentage: 45 },
  { id: "2", name: "Javascript", color: "#FFC50F", percentage: 20 },
  { id: "3", name: "CSS", color: "#62109F", percentage: 25 },
  { id: "4", name: "HTML", color: "#FF8040", percentage: 10 },
];

I then used this array to generate two sets of components:

Chart components showing the usage percentage and color of each language:

{Data.map((lang) => (
  <div
    onMouseLeave={() => setActiveLangId("")}
    onMouseOver={() => setActiveLangId(lang.id)}
    style={{
      width: `${lang.percentage}%`,
      backgroundColor: `${lang.color}`,
    }}
    className="langPercentage"
  ></div>
))}

List components below the chart showing the name, color, and numeric percentage:

{Data.map((lang) => (
  <Language
    {...lang}
    isActive={lang.id === activeLangId}
  />
))}

As you can see, the UI is generated directly from the data.

Now, suppose you want to do something when a user interacts with a component, for example, enlarging a list item when its corresponding chart bar is hovered. You already have full access to the data when defining the event handler:

onMouseOver={() => setActiveLangId(lang.id)}

No data attributes are necessary. The id of the language is available because the UI is created from the data itself.

The takeaway? In React, the DOM is just a rendered output. There isn't a reason to store extra data on the element itself, your components and state already hold everything you need.

The Scenario That Changed My Mind :

I used to believe that there was almost never a reason to use data attributes in React. But a while ago, while working on a frontend task, I discovered a situation where I had no real alternative.

The Scenario :

I had a scrollable container filled with cards, each displaying a substantial amount of data. My goal was: whenever a card reached the top of the container (and remained there until the next card arrived), the card’s title, and some additional minor information ,should appear in the container’s header.

The reasoning was simple: the user shouldn’t have to scroll back to the top of the card to see its title. Instead, when the card scrolls past the top, the header would display the title and some info until the next card takes its place.

The Challenge:

To implement this, I used the JavaScript Intersection Observer API . It worked perfectly to tell me when a card reaches the top of the container and when it fully exits. However, there was a problem:

The Intersection Observer gives you the target element (IntersectionObserverEntry.target) ,but it doesn’t give you the data that originally generated that element. Unlike normal event handlers, where you have access to the data when you define the handler, here you’re observing the DOM after the components have already been rendered, so the data isn’t directly accessible.

I initially thought I could query the DOM to find a p tag holding the title, but this felt brittle: any future change in the card’s internal structure would break the code.

The Solution: Data Attributes

Finally, I decided to store the card’s title directly in a data attribute on the card’s root element:

<div data-title="Card Title"> ... </div>

Now, when the Intersection Observer gave me the target element, I could easily access the title via dataset:

const title = entry.target.dataset.title;
setHeaderTitle(title);

This approach was simple, reliable, and future-proof.

Takeaways:

Most of the time in React, you don’t need data attributes, because the UI is generated directly from your data.
But in some cases, like Intersection Observer, Drag & Drop, or working with third-party DOM libraries, you only have access to the element itself. In these situations, data attributes are extremely useful.
If the dataset is large, you can store just an id in the data attribute, then look up the full data in your array.

Additionally, data attributes are commonly used for testing frameworks, such as data-testid, which is considered a normal and acceptable practice.

That’s my take on this tricky scenario with Intersection Observer in React. I’m curious, am I missing something? Is there a cleaner way to implement features like this without using data attributes, or is this truly one of those rare cases where they make sense? I’d love to hear your thoughts and experiences.

I Thought Becoming a Front-End Developer Was My Dream — Until I Realized I No Longer Enjoyed Coding

m.rezanahi — Thu, 30 Oct 2025 19:09:22 +0000

In the VS Code terminal:
npm run dev
I’ve rewritten the page for the tenth time after design changes, and everything works fine.
It’s 11 a.m., but I feel utterly exhausted.
The marketing team’s voices are loud, as if they have nothing to do, and I wish I could make them quiet.
I have very little patience today.
I start wondering, was this the job I had been chasing for so long? A front-end developer at a startup?
This made me pause and reflect: why did I even choose programming in the first place?

The Origin

Nine years ago, my school decided to hold several extracurricular classes on different topics, and one of them was game development. I signed up for it purely out of curiosity. The class met once a week.

The teacher taught us with great enthusiasm. None of us knew programming, but that wasn’t necessary we were using GameMaker Studio. We could implement game logic simply by dragging and dropping events, and we created our characters with the mouse in GameMaker’s environment, something like Windows Paint.

By the end of the first session, I was completely absorbed in making a game and barely noticed what the teacher was saying. In my game, we had two characters, each controlled by a few keyboard keys. One could shoot dynamite with the spacebar, the other with shift, and whoever hit the opponent first won.

The class ended, but I was still trying to figure out how to keep the characters from leaving the arena, adding blocks around the edges. I don’t know how long I spent on it, but the bell eventually brought me back. During recess, I realized the teacher was standing behind me, watching my work. I could tell he was amazed.

I told him I had made a game but couldn’t stop the characters from leaving the arena. He spent about 30 minutes explaining it to me, and afterward, I had a really cool game we could play together.

Everything started from there
exactly there
from the joy of creating. from the joy of learning.

The class ended after eight sessions, but on Thursdays, another advanced class was organized for me and four other interested students. In this class, the teacher taught us game development at a deeper level.

The image below shows the "Plants vs. Zombies" style game I created in GameMaker Studio.

A little later, we participated in a game development competition with about 20 schools competing. We ended up in second place.

It was there that my path was truly set.
Programming…
Ah, those were such good days.
So why don’t I feel that same excitement and joy from programming anymore?
Where is the problem?

What Took That Joy Away from Me?

The sound of something like an inflated bag popping brings me back to reality.
I hear laughter from the marketing team and realize it’s probably their mischief again.
It’s still 11 a.m.

The problem isn’t programming.
The problem isn’t me.
The real problem is the work I’m doing here.

Don’t get me wrong , I’m working on some really interesting projects in this startup. But as I said before:

Real satisfaction doesn’t always come from building impressive features, but from truly understanding what you’re working on and continuously learning.

When you build something amazing but don’t really understand how it works (just following instructions from ChatGPT or similar tools), it’s not truly rewarding.
This fatigue comes from straying from the right process.
I’ve become like a robot just implementing things. What’s the point of implementing without understanding its purpose?

The real joy comes when you create something extraordinary and know exactly how it works. I’ve experienced this feeling over and over, it’s what drew me to programming in the first place.

I need to change this situation because honestly, I don’t think I can continue programming like this.

In Search of Lost Joy

Honestly, I have some plans.
First, I think one reason I’ve been feeling this way is that I don’t have any personal projects. I work on many projects at the startup, but I don’t make the key decisions for them. Even though these projects are important to me and I try my best to implement and deliver them well, a personal project is something else entirely.

It’s like having a meaningful goal, a beautiful horizon that you run toward, like a point of light in a dark tunnel.

So, I need to have a personal project again and dedicate time to it.
Honestly, I already have some ideas.

But there’s another important issue that has been occupying my mind lately…

Robots Without Expertise

It’s been a few months now since our team started looking for a senior front-end developer.
Many people have come in for interviews, but they were all rejected, we still haven’t found the right person.

Some days, I stood near the interview room, listening to the conversations. I wanted to understand what kind of questions were being asked that made everyone fail.
Honestly, the questions weren’t that hard. But when I heard the answers, I was genuinely surprised. It was clear that most candidates lacked any deep understanding of React or front-end concepts. They didn’t know why one approach was right and another was wrong. They just learned something once and kept repeating it.

One of the candidates couldn’t even explain why we need a state management library like Redux.
That reminded me of myself years ago.
I once built a fairly large application with React without knowing what Redux Toolkit was. I did everything using the Context API.
By the end of the project, I was on the verge of tears. My app’s states were tangled like a spider web, and debugging had become painfully difficult. I had too many Contexts, and managing them was chaos.

When I finally discovered Redux Toolkit, I truly understood the problems it was designed to solve.

Watching these interviews taught me something very important:
You can have years of experience and still remain a junior.

I want to make sure that never happens to me.
If I ever decide to leave this startup, I want to be as skilled and knowledgeable as I can.
In fact, I want to become more of an expert every single day.

Starting Again

I want to combine these two goals:

Finding a deep understanding of front-end concepts and beyond.
Working on a personal project.

I plan to work on a personal project where I’ll learn a lot and become more specialized in many areas.
Honestly, I don’t want to share the details of this project, but to build it, I need to learn backend topics — things like Node.js, Express, and how to create APIs.

On the front-end side, I want to go deeper into everything I deal with every day.
For example, I’ve been wanting to learn Canvas for a long time.
Or maybe I could try to build my own router for React instead of using React Router.
And there are many other things I’d like to try.

Honestly, even now, as I’m writing these lines, it feels really exciting.
I think this might be the only way to escape this swamp.

This project has other advantages too.
For example, it could become a great portfolio piece that I can use later,
or maybe I could even make money from it.
Isn’t that awesome?

But years of dreaming have taught me one important thing:
you must start small, otherwise nothing gets done. Step by step.

The sound of the marketing team is still annoying.
The clock’s hand doesn’t seem to want to move.
Everything feels the same.
Except now, I have some interesting ideas to implement and I’m going to experience that lost joy again and again...

How can you build great things and still feel UNSATISFIED? - my first startup experience

m.rezanahi — Thu, 09 Oct 2025 22:33:15 +0000

It’s been about four months since I joined a startup as a frontend developer. This is my very first real job, and getting here wasn’t easy ,I had to go through a tough, multi-stage competition that lasted almost four months. After winning, I joined the team with a few other developers.
Honestly, this opportunity is amazing… but there’s one thing that’s been bugging me. I just don’t feel satisfied!

Building Amazing Stuff, Yet Feeling Empty!

In these four months, I’ve built some really cool stuff, things I honestly never thought I could pull off. I joined the startup at a time when there were tons of exciting projects going on (and yeah, a fair amount of work pressure too, but that’s fine).
Still, even though I’ve done a lot of things I can be proud of, there are days when I leave the office feeling like I did nothing at all. Like… nothing really meaningful.

Doing vs. Really Understanding

Maybe the main issue is my perfectionism!
So far, I’ve seen two types of developers around me:

1-The fast implementers

These developers can quickly build a feature even if it requires a new library or framework. They’ll skim the docs, search a bit, and get it done. Job complete.

2-The deep learners

These developers need to fully understand the library or framework before implementing it. It takes more time, but afterwards, they have a solid grasp of how everything works.

I’m, unfortunately (or maybe fortunately), in the second group. Sure, I could implement things like the first group, just quickly, using docs or AI, but if you asked me afterward if I really know that library, my answer would be no. I managed to deliver a decent project, but I haven’t truly internalized it yet, I just implemented it.

I don’t know if this is a strength or a problem I should fix (people have told me it’s a problem stemming from perfectionism). Either way, I learn a bit slower because I dive deep into concepts.
This becomes trickier when I’m working alongside fast implementers.

Like in my startup, I can’t slow down the team just because I need more time to understand. There are plenty of developers moving quickly, and I can’t hold up the flow. The result? I’ve been building cool features for months… yet I still don’t feel satisfied. It feels like I’m just laying bricks without understanding the bigger picture.

But then, there are days when I leave the office happy and energized, ready to come back the next day!
…These are the days when I finally get the chance to deeply learn something. sometimes something small that others might consider trivial, like console object methods in JavaScript, such as console.count or console.group (but not console.log).

I remember the day I learned a tiny detail about folder structures in React projects from a senior developer, and I even read a bit more about it afterward. After fully understanding it, I felt ten times more energized, I didn’t want to go home and just wanted to keep going!

So, what role does AI play here?

I’m not trying to have a cliché debate about AI, but here’s what I see: AI and chatbots have multiplied the speed of the “fast implementers.” They barely even touch documentation anymore—they just get everything they need with a single prompt.

Of course, I use AI too, especially when I don’t feel like digging through docs. And most of the time, when I want to dive deeper into a topic, AI is really helpful and gives me some good suggestions.

But in my scenario, AI has become a good friend who… unfortunately doesn’t realize it’s also kind of holding their buddy back.

My current fixes for feeling unsatisfied

Honestly, I haven’t found a perfect solution yet (hopefully you have some ideas for me!), but for now, there are a few small things that help improve how I feel.

1-Setting a daily learning task

Most workdays are packed with tasks, but I always pick one learning task the night before that I want to focus on the next day. If the topic is bigger than expected, I split it across a few days.
Examples of tasks I’ve chosen:

The most important SVG tags
Best practices for creating a custom hook in React
How to optimize state management in Redux
CSS Grid tricks for responsive layouts Completing these tasks helps me step away from that feeling of emptiness.

2-Choosing tasks aligned with my current interests and studies

As I said, there are lots of tasks to do every day. I try to pick ones that match my current interests or topics I’m studying (even if I don’t have time to dive into them fully yet).
If the task isn’t aligned, I end up doing it half-heartedly, leaning on a chatbot, and just implementing things like a “robot” without really understanding. But when the task matches my interests, I can both implement it and actually dive deep into the topic.

At the end of the day, I’ve realized that real satisfaction doesn’t always come from building impressive features, but from truly understanding what you’re working on and continuously learning.
I’m still figuring it out, and I’d love to hear from you: how do you stay motivated and actually feel fulfilled in your work?