DEV Community: Michael Scott Hertzberg

Series: Frontend Architecture in a Nutshell: Optimize

Michael Scott Hertzberg — Wed, 11 Jun 2025 16:50:38 +0000

Operate & Optimize

Last updated: 2025-07-29

Series: Frontend Architecture in a Nutshell: Build & Deliver

Michael Scott Hertzberg — Wed, 11 Jun 2025 16:46:26 +0000

Build & Deliver

Last updated: 2025-07-29

Series: Frontend Architecture in a Nutshell: Test

Michael Scott Hertzberg — Wed, 11 Jun 2025 16:42:43 +0000

Test

Last updated: 2025-07-29

Series: Frontend Architecture in a Nutshell: Develop

Michael Scott Hertzberg — Wed, 11 Jun 2025 16:39:44 +0000

Develop

Last updated: 2025-07-29

Series: Frontend Architecture in a Nutshell: User Interface

Michael Scott Hertzberg — Wed, 11 Jun 2025 16:14:16 +0000

User Interface

Last updated: 2025-07-29

Series: Frontend Architecture in a Nutshell: Interface

Michael Scott Hertzberg — Wed, 11 Jun 2025 16:08:47 +0000

Interface

Last updated: 2025-07-29

Series: Frontend Architecture in a Nutshell: Data

Michael Scott Hertzberg — Wed, 11 Jun 2025 16:06:10 +0000

Data

Last updated: 2025-07-29

Series: Frontend Architecture in a Nutshell: Architecture

Michael Scott Hertzberg — Wed, 11 Jun 2025 16:01:30 +0000

Architecture

Last updated: 2025-06-11

Series: Frontend Architecture in a Nutshell: Requirements

Michael Scott Hertzberg — Wed, 11 Jun 2025 15:48:24 +0000

Requirements

Last updated: 2025-07-29

Series: Frontend Architecture in a Nutshell

Michael Scott Hertzberg — Wed, 11 Jun 2025 15:46:28 +0000

This series explores Frontend Architecture from 0-100. It can be used for both personal and professional enrichment, or as a study guide for SWE interviews.

This was created by myself and not using AI. Consider this to be a living document, as the diagrams are subject to evolve! Please note that on each part of the series, a latest update date will be present.

The first part in the series will cover Requirements. Be sure to give me a follow to stay updated as this series progresses!

If you've interviewed before and have been asked to design something from the ground up, how do you start? Well, you start with the requirements!

Diagrams were made using XMind.
View the full series here!

I've written a lot of tech specs & now I have this new interview fear -- looking AI-made. I try not to use LLMs (maybe coming up with test cases; autocomplete). I popped a few docs of mine into a few. docs written Pre-LLM. It claims all was AI made. WWYD?

Michael Scott Hertzberg — Tue, 18 Mar 2025 22:26:39 +0000

To a React naysayer

Michael Scott Hertzberg — Wed, 26 Feb 2025 15:59:31 +0000

"Friends don't let friends use React" were the first words in this post.

🚨 Friends don’t let friends use React. 🚨

We all know that every line of code you add today is just a future liability waiting to haunt you. Technical debt is real, and once you’re in deep, there’s no easy way out.

Now, imagine your friend maxing out their credit cards on overpriced junk, living that "buy now, cry later" lifestyle. Would you just stand by and let it happen? Of course not! You’d step in, shake them by the shoulders, and say, “Think about your future!”

So why is it any different when you see a fellow developer swiping their React credit card, installing package after package, drinking the hook-flavored Kool-Aid, and convincing themselves that yet another state management library is the answer to all their problems?

It starts small, just a little JSX here, a sprinkle of useEffect there. Then, before they know it, they’re lost in dependency hell, buried under 4,187 npm packages that all mysteriously break after a minor version update.

Will you step in? Will you be the friend who saves them from themselves? Or will you let them spiral into an endless cycle of over-engineered component hierarchies?

React may be seductive, but it’s a one-way ticket to regret. Intervention starts with you.

⚛️ React. Not even once.

It didn't catch me off-guard, given this was yet another blanket statement toward a library (in this case, React).

I don't involve myself in heated conversations, yet I was compelled to reply to the post with:

A better argument here would be, "use a framework, not a library" -- it never has anything to do with React and everything to do with not having opinion. When there is only opinion, is there no one right way to do something.

To my surprise, my reply had a follow-up from another naysayer:

Michael Hertzberg: Such horse sh*t! All subjective opinions are validated by objective reality in the end. They don’t exist in isolation. Reality tells us which opinions yielded the most productivity and the simplest code. Definitely not React. At every React codebase I joined over the years, it was absolutely horrendous compared to other technology codebases. Opinions CAN BE wrong when they miss the target of doing client work with the most productivity and maintainability and at the lowest cost and time to deliver. I currently use a technology that can implement React Frontend work in half the time, easily, with the code being much more readable by everyone. It’s not even close. React sucks. All smart software engineers know that already.

Without any quick judgment on my part given their emotional response, I was eager to give an emotional response; however, I took a moment to address everything, instead of throwing a bunch of unproductive streams of consciousness. Here was my response:

[Redacted], that's a strong take. but, you're presenting your own subjective experience as "objective reality," which is exactly what you're criticizing.

React is just a UI library. It doesn't enforce architecture or patterns, which is why you see such wildly different React codebases; my point about opinions vs. frameworks.

The "horrendous" codebases you encountered weren't predetermined by React itself - they were the result of architectural choices, team dynamics, and project constraints. Maybe you worked on "horrendous" teams.

You mention using a technology that's 2x more productive for you -- that's awesome! Different tools work better for different people and projects. But declaring "all smart engineers know React sucks" doesn't reflect reality, it just dismisses the valid experiences of countless skilled devs who find value in it.

My original comment wasn't defending React, it was pointing out that libraries without opinions naturally lead to more diverse (and sometimes messy) implementations. That's a tradeoff, not a failure.

React is fine for smart people if they want to.

What do you think?