Hi, I'm Mohamed Elshahawy
In a React emergency, read this first
The React Handbook is run by me, Mohamed Elshahawy. I care about practical frontend engineering: clean architecture, predictable performance, and teams shipping without chaos.
This page is the "why" behind the site, the mindset behind the recommendations, and a shortlist of resources that still shape how I build software.
Quick context
- I built this guide to help engineers make better React decisions faster
- I optimize for long-term maintainability over short-term novelty
- I treat performance as a product concern, not just a Lighthouse score
- I believe team alignment beats individual preferences every time
1) Why this handbook exists
React docs are excellent for APIs and fundamentals. What they intentionally do less of is prescribing full-stack ecosystem choices for every team context. That gap is where ReactField lives.
My goal is straightforward:
- reduce decision fatigue for React teams
- prioritize high-impact engineering decisions over trend-chasing
- give practical references you can use in real production codebases
- keep guidance opinionated but revisable as the ecosystem changes
If you want the full background story of React itself, watch this documentary.
2) How to use ReactField effectively
If you are new to React, start with Fundamentals.
If you are choosing tooling, go to Frameworks.
If your app is already in production, prioritize Performance Optimization and Project Standards.
The pattern I recommend:
- start from principles, not libraries
- pick one stack and apply it consistently
- measure before optimizing
- document decisions your future team members will question
3) How I stay current with React and JavaScript
I don't rely on one source. I combine docs, maintainers, issue threads, and community signals:
- Foundation:
- Community channels:
- People I pay attention to:
- Newsletters:
Paid resources that delivered real long-term value for me:
- Just JavaScript by Dan Abramov
- Epic React by Kent C. Dodds
- Advanced React by Nadia Makarevich
4) Technologies I reach for often
- React / React Native
- TypeScript
- Tailwind
- Radix UI
- Flask (Python)
5) Arguments I care about
- KISS still wins: simple designs survive team growth
- Strong opinions, loosely held: adapt fast when data changes
- Readability over cleverness: future maintainers matter
- TypeScript over JavaScript for production apps
- Avoid
anyunless you've exhausted better options - Not every product should be an SPA; choose architecture by constraints
- If your app is fully auth-gated, SPA can still be a very good fit
- Tooling consistency matters more than personal style preferences
6) Build principles I use in real projects
- Design APIs and component boundaries before scaling features
- Keep page architecture obvious: data flow, ownership, and dependencies
- Prefer boring, proven tools unless a new tool solves a real bottleneck
- Remove complexity aggressively; every abstraction has a maintenance cost
- Write docs for decisions, not just setup steps
7) Arguments I do not care about
- Tabs vs spaces (just pick one so everyone is consistent)
- camelCase vs snake_case (consistency beats personal preference)
- Sass vs Styled Components vs Post CSS (pick one approach and execute it well)
If ReactField helps you ship better software, consider contributing or opening an issue: