Featured Issues

Crafting the Web: Tips, Tools, and Trends for Developers Advertise with Us|Sign Up to the Newsletter @media only screen and (max-width: 100%;} #pad-desktop {display: none !important;} } @media only screen and (max-width: 100%;} #pad-desktop {display: none !important;} } WebDevPro #130 Rethinking State Management in Modern React Crafting the Web: Tips, Tools, and Trends for Developers Most Spring Boot projects stop at REST APIs Real systems require service discovery, API gateways, centralized configuration, and built-in resilience. In this live, hands-on workshop, you’ll build a working microservices system end-to-end, define service boundaries, wire up discovery, configure a gateway, and handle failures properly. 🎟 Register now and get 40% off with code SAVE40 📢 Important: WebDevPro is Moving to Substack We’ll be moving WebDevPro to Substack soon.Once the transition is complete, all future issues will come from packtwebdevpro@substack.com. To make sure the newsletter continues reaching your inbox, please add this address to your contacts or whitelist it in your mail client. No other action is needed. You’ll keep receiving WebDevPro on the same weekly schedule. Substack will also give you more control over your subscription preferences if you decide to adjust them later. Welcome to this week’s issue of WebDevPro! If you’ve worked with React for a while, you’ve probably run into the same recurring question: how should we manage state in this application? State management is one of those topics that almost every React team ends up debating sooner or later. Should everything live in context? Do we need a global store? Would something like Zustand make things simpler? Those conversations usually focus on tools. But in many cases the real problem shows up earlier than that. In practice, React applications rarely become difficult to maintain because the wrong library was chosen. They become difficult to maintain because different kinds of state get handled in the same way. A form input, an API response, a UI filter, and a shared user object often end up managed with identical patterns. That is where complexity starts to creep in. In this article, we will look at the main categories of state that appear in React applications and how each category is best managed. By the end, you will have a clearer way to decide where state belongs in a React app, whether that means local component state, shared state, server data tools, or even the URL itself. Not all state belongs in the same place State in React applications usually falls into a few clear categories. Local state lives inside a single component. A dropdown menu, a modal visibility toggle, or a small UI interaction typically belongs here. Hooks such as useState or useReducer work well because the logic remains isolated. Server state represents data fetched from APIs or databases. This includes user profiles, product listings, or analytics data. The key difference is that the source of truth lives outside the application. Form state includes field values, validation errors, and submission status. Forms have their own lifecycle and benefit from specialized tools such as React Hook Form or React’s form hooks. URL state stores small pieces of UI state in route or search parameters. Tabs, filters, pagination, and search queries often belong here. Shared state exists when multiple components need access to the same data. Authentication details, application settings, or user preferences are common examples. Understanding these categories clarifies an important point. React state is not a single problem. It is a set of related problems that require different solutions. The easiest state to manage is the state you never store One of the most common sources of complexity in React applications comes from duplicated state. Consider a list of items where the interface displays only active entries. A common pattern stores both the original list and a filtered version of it. const [items, setItems] = useState([...]) const [filteredItems, setFilteredItems] = useState([]) useEffect(() => { setFilteredItems(items.filter(item => item.active)) }, [items]) This introduces synchronization logic that React must maintain. A simpler approach derives the filtered list directly from the original state. const [items, setItems] = useState([...]) const filteredItems = items.filter(item => item.active) The application now maintains a single source of truth. React calculates the derived value when needed. Derived state reduces bugs and simplifies reasoning about data flow. Many React components become easier to maintain once unnecessary state variables disappear. Shared state is where React applications become complicated Local state remains predictable because it stays within a component. Shared state changes that dynamic because multiple components read and update the same values. Developers often encounter this situation when user data, permissions, or global settings must appear across different sections of the interface. The simplest approach begins with prop drilling. A parent component holds the state and passes it through props to child components. This technique often receives criticism, yet it works well for a small number of adjacent components. It also keeps data flow explicit and easy to trace. Problems appear when the component tree becomes deeper. Intermediate components may receive props they do not use, simply to pass them further down the hierarchy. At this stage, many teams introduce React context. Context allows components to access shared values without passing them through each level of the tree. A provider component stores the shared state and exposes it to any descendant component. This pattern simplifies access but introduces a different trade-off. When context values change, every consumer beneath the provider may re-render. For small applications this rarely matters. In larger interfaces the rendering behavior becomes harder to control. Libraries such as Zustand approach shared state from a different angle. Zustand creates a centralized store and allows components to subscribe only to the pieces of state they require. const userName = useUserStore(state => state.userName) Components update only when the subscribed value changes. This selective subscription reduces unnecessary renders and keeps the shared state logic compact. Context and Zustand both solve shared state challenges, but they operate at different scales. Context works well for moderate application state. Zustand becomes attractive once shared state spreads across larger parts of the interface. Server state follows a different lifecycle Data fetched from external services introduces a different category of state entirely. Server data involves caching, background refetching, loading indicators, and stale data management. Handling these concerns with useState and useEffect often leads to repetitive code and fragile synchronization. Libraries such as TanStack Query address this layer directly. They treat server data as cached resources rather than ordinary component state. Components request data using a shared query key. const { data } = useQuery({ queryKey: ['user', userId], queryFn: fetchUser }) TanStack Query stores the response in a client cache. Other components requesting the same query receive the cached result rather than triggering another network request. This model separates server data concerns from UI logic. React components remain focused on rendering rather than managing asynchronous data lifecycles. Some state belongs in the URL Another overlooked location for state is the browser address bar. Interfaces often contain UI state that describes how a page is being viewed. Active tabs, filter selections, search queries, and pagination indexes all fall into this category. Storing this information in URL search parameters creates several benefits. The state becomes shareable through links. Refreshing the page preserves the interface configuration. Browser navigation also restores previous UI states naturally. Framework hooks such as useSearchParams and routing utilities make this pattern straightforward. const params = useSearchParams() const activeTab = params.get('tab') Many teams duplicate this information inside React state and attempt to synchronize it with the URL. Removing that duplication simplifies the architecture. The address bar can act as a reliable source of truth for small pieces of UI state. Choosing the right home for state Modern React offers many tools for managing state, but the real skill lies in recognizing where each type of state belongs. Local UI interactions usually remain simplest when handled with component state. Values that can be computed from existing data should be derived instead of stored. Data fetched from APIs benefits from tools designed for server state, such as TanStack Query, which handle caching and refetching automatically. UI state that affects navigation, such as active tabs or filters, often works best when stored in URL parameters. Shared client state can start with straightforward prop passing and evolve into solutions such as context or Zustand when multiple components need coordinated access. The key takeaway is not which library to choose. It is learning to recognize the nature of the state problem in front of you. Once you can distinguish between local, shared, server, form, and URL state, the architecture decisions become much clearer. Instead of forcing every problem into the same pattern, each piece of state can live in the place where it is easiest to manage. That shift in thinking leads to React applications that are easier to reason about, easier to scale, and far less prone to the state management issues that often slow teams down. Build real skills in LLMs and agentic AI with this 20+ course Packt bundle, featuring titles like Learn Python Programming, 4E and The LLM Engineer’s Handbook. Learn how to design and deploy intelligent systems while supporting World Central Kitchen. 👉 Grab the LLM & Agentic AI Career Accelerator bundle This Week in the News 🧠 TypeScript 6.0 RC prepares the ecosystem for the Go-powered compiler:TypeScript 6.0 RC has landed and it marks an important transition for the language. This release functions largely as a stepping stone toward TypeScript 7.0, which will introduce a new native compiler written in Go. The RC itself contains only a few small changes compared to the beta, but the bigger shift lies in the groundwork being laid for the next generation of the toolchain. Required updates to tsconfig.json help projects align with upcoming architecture changes, giving teams time to prepare before the performance gains of the Go-powered compiler arrive later this year. ⚛️ SolidJS 2.0 beta introduces first-class async and a redesigned reactive core: SolidJS has entered the 2.0 beta phase after several years of experimental work on its next-generation reactive system. The release introduces major architectural changes including a rewritten signals implementation, deterministic batching, and first-class async support built directly into the framework’s primitives. New patterns such as action and optimistic state helpers aim to make server mutations and UI updates easier to manage, while updates to control flow and rendering bring several breaking changes developers will notice quickly. The beta sets the stage for broader ecosystem updates ahead of the stable 2.0 release. ☁️ Astro 6 introduces a Rust compiler and deeper Cloudflare alignment:Astro 6 arrives as the framework’s first major release since its acquisition by Cloudflare in January, and the platform direction is already becoming clearer. The update introduces an experimental Rust compiler that will eventually replace the original Go-based .astro compiler, promising faster builds and a modernized compilation pipeline. Development workflows also improve through Vite’s new Environment API, which allows developers to run the exact production runtime during development. Astro also introduces a new Fonts API that simplifies custom font handling across projects. 🌊 Cloudflare pushes for a simpler modern JavaScript Streams API:Cloudflare engineers are questioning the design of the Web Streams API, arguing that it reflects an earlier era of JavaScript before patterns like async iteration became common. The result is an abstraction that often feels overly complex, with specialized readers, locking mechanics, and extra boilerplate. Cloudflare proposes a simpler model built on modern JavaScript primitives that could improve both ergonomics and performance. Early benchmarks suggest potential speedups of up to 120× across runtimes such as Node.js, Deno, and Workers. In a related talk, James Snell explains how an async-iterator-driven approach could make streaming code easier to reason about for developers working with edge platforms and large data pipelines. 🎥 Watch the talk: https://www.youtube.com/watch?v=abbeIUOCzmw Beyond the Headlines 🤖 Literate programming may finally make sense in the AI agent era: Donald Knuth’s idea of literate programming asked developers to write code as a narrative meant for humans, with the compiler following along. For decades the concept remained mostly academic. This piece revisits the idea through the lens of AI-assisted development, where agents read, analyze, and generate code alongside developers. Clear explanations, structured reasoning, and intent-rich programs suddenly become far more valuable. The argument is simple but compelling: the rise of coding agents may finally make literate programming practical. 🐘 Just use Postgres and delay the infrastructure sprawl:Many modern stacks quickly grow into a collection of specialized tools: queues, search services, analytics systems, and caches. This article argues that much of that complexity arrives too early. PostgreSQL already includes powerful capabilities such as JSON support, full-text search, background jobs, and extensions that cover a surprising range of workloads. For many products, a single Postgres database can carry far more responsibility than teams assume. The takeaway is pragmatic: lean on Postgres longer and introduce new infrastructure only when the workload genuinely demands it. ⚡Building a real-time collaborative to-do app with Jazz and Vue: Real-time collaboration often brings complex backend logic, synchronization challenges, and WebSocket plumbing. This tutorial shows a simpler path by building a collaborative to-do app using Jazz and Vue. The stack manages shared state and synchronization automatically, allowing the interface to update instantly as multiple users interact with the same data. The walkthrough focuses on how collaborative state flows through the application and how the UI reflects updates in real time. It offers a practical introduction to modern tooling for building collaborative applications. ⚛️ Why React needed Fiber and what problem it actually solved:React Fiber is one of the biggest architectural changes in React’s history, yet its purpose is often misunderstood. This deep dive explains why the original reconciliation algorithm struggled with large or complex updates. Fiber introduced a scheduling model that allows React to pause, resume, and prioritize rendering work instead of processing everything in one blocking pass. That change laid the foundation for features such as concurrent rendering and smoother user experiences under heavy workloads. Tool of the Week 🛠️ VMPrint deterministic PDF generation without headless browsers Print-to-PDF pipelines often rely on headless Chrome, bringing along browser quirks and inconsistent rendering. VMPrint takes a different approach with a pure TypeScript typesetting engine that bypasses the DOM entirely and computes layout through typographic math. The result is deterministic output across browsers, Node.js, and edge runtimes like Cloudflare Workers. Given identical input, VMPrint guarantees identical layout down to the sub-point position of every glyph. For teams building document generation pipelines or publishing systems, it offers a precise and reproducible alternative to browser-based rendering. That’s all for this week. Have any ideas you want to see in the next article? Hit Reply! Cheers! Editor-in-chief, Kinnari Chohan SUBSCRIBE FOR MORE AND SHARE IT WITH A FRIEND! *{box-sizing:border-box}body{margin:0;padding:0}a[x-apple-data-detectors]{color:inherit!important;text-decoration:inherit!important}#MessageViewBody a{color:inherit;text-decoration:none}p{line-height:inherit}.desktop_hide,.desktop_hide table{mso-hide:all;display:none;max-height:0;overflow:hidden}.image_block img+div{display:none}sub,sup{font-size:75%;line-height:0}#converted-body .list_block ol,#converted-body .list_block ul,.body [class~=x_list_block] ol,.body [class~=x_list_block] ul,u+.body .list_block ol,u+.body .list_block ul{padding-left:20px} @media (max-width: 100%;display:block}.mobile_hide{min-height:0;max-height:0;max-width: 100%;overflow:hidden;font-size:0}.desktop_hide,.desktop_hide table{display:table!important;max-height:none!important}} @media only screen and (max-width: 100%;} #pad-desktop {display: none !important;} } @media only screen and (max-width: 100%;} #pad-desktop {display: none !important;} }

Editor’s Note Hello lovely people, how are y’all doing? We’re stepping into a new week with a scoop of Game Dev Assembly! 🚀 In this issue, Meer Balaj takes us behind the curtain of a deceptively tricky design problem. It’s the moment when a perfectly logical system suddenly feels broken during playtesting. Through a real development story and lessons from his puzzle shooter project, he explores how great games balance chaos with control. You’re about to find out that the best randomness in games often isn’t truly random at all! 🤫Let’s dive in and also find out what March has in store for you across the game dev world.🎮 I’ll never forget a particular playtest during the early development of a puzzle game I was working on. The mechanics were simple: match colored blocks to clear them. To keep things fresh, I used a standard random number generator to shuffle the upcoming pieces. It was “fair” in the mathematical sense because every color had an equal chance of appearing.Then it happened.One playtester sat staring at the screen for three minutes, unable to make a single move. Why? Because the “fair” RNG had decided to spawn ten blue blocks in a row when they desperately needed a single red one to clear the bottom row. The game was mathematically perfect, but to the player, it felt broken. It felt unfair.That moment taught me a lesson that every game developer eventually learns, and that is that true randomness is often the enemy of good design.True randomness is often the enemy of good design.The Illusion of Fairness Humans are notoriously bad at perceiving true randomness. If you ask someone to write down a random sequence of heads and tails, they will rarely write “heads” four times in a row, even though that’s perfectly common in a real coin toss. We expect variety. We expect balance.When a game gives us true, raw randomness, we see patterns where there are none, or we perceive bad luck as a personal vendetta from the game engine.In game design, we have to distinguish between mathematical randomness and psychological randomness.Mathematical randomness is pure. It’s Random.Range(0, 5). It doesn’t care what happened five seconds ago, and it doesn’t care if the player is about to lose.Psychological randomness, however, is what the player expects to happen. If I haven’t seen a “critical hit” in ten swings, I expect one to be coming soon. If I’ve been stuck on a difficult level for twenty minutes, I expect a “power-up” to drop.When the gap between these two types of randomness becomes too large, player frustration sets in. This is where calculated design steps in to bridge the divide.Beyond the Dice Roll: Calculated Design Calculated design is about curating it randomness, and not removing it. It’s the weighted die, the pity timer, and the shuffle logic that ensures the experience stays within the bounds of what feels fair.Think of it like a music playlist. If you set a 1,000-song library to true randomness, you might hear the same artist five times in a row, which is mathematically possible, but it’s going to be frustrating for the listener.A smart shuffle ensures the system cycles through different artists and genres before repeating. It’s still unpredictable, but it’s curated to feel like a better experience. This shift, which is from pure chaos to intentional flow, is the first step toward a more calculated and satisfying game.Solving the Deadlock in ThisIsBlast In my latest project, a shooter-based puzzle game called ThisIsBlast, I faced a classic randomness dilemma. The player controls a shooter that fires colored blocks at a grid. To clear a path and win the level, the player must shoot blocks that match colors currently at the bottom of the grid.Initially, I used a simple shuffle for the upcoming shooter queue. It seemed fair as every color the player needed was in the pool. But playtesting revealed a frustrating deadlock scenario.If the player was looking at a bottom row of Red and Green blocks, but the random queue gave them five Yellow blocks in a row, they were stuck. They didn’t have enough “slots” to hold the Yellow blocks, and the game would end simply because the dice rolled poorly. Figure 1: A Deadlocked board scenario — how pure mathematical randomness can feel broken to a playerThe Solution: Weighted Spawning Instead of just shuffling the colors, I wrote a system that scans the current state of the grid before every spawn. It asks three critical questions:Which colors are currently at the bottom of the grid?Which of those colors does the player need now to make progress?How many of those colors are already in the player’s queue?By weighting the spawn probability toward the colors at the bottom of the grid, I ensured that the player almost always has a path forward.We still shuffle the colors, but we shuffle within tiers. Tier 1 contains the Priority Colors, which are the ones that will actually clear blocks. Tier 2 contains the Future Colors, which are the ones that will be needed soon but aren’t urgent.The result? The game feels more skill-based even though there’s still significant randomness involved. The player doesn’t see the complex math behind the scenes; they just feel like the game is tough but fair. Figure 2: Calculated Design in action — ensuring a solvable pathThe Secret Sauce: Variety via Mystery Of course, if you make a game too predictable, it becomes boring. To counter the high predictability of weighted spawning, I introduced a mystery mechanic. Some items in the queue are hidden until they reach the front line.This creates tension. The player knows the game is helping them by giving them what they need, but the mystery elements hide the exact order, forcing adaptation on the fly. It’s the perfect marriage of control and chaos.Balancing the Scales If you’re looking to implement more calculated design in your own projects, consider the following principles:Analyze, then randomize. Make your RNG aware of the player state.Implement a pity counter to prevent extended failure streaks.Use deck systems instead of pure percentage rolls.Visualize your distributions over thousands of simulations.And finally, add salt to taste. Too little calculation feels frustrating, too much feels rigged.In the end, game development isn’t about being a mathematician; it’s about being a magician. We use randomness to create excitement and variety, but we use calculated design to ensure the trick never fails.By understanding player psychology, we can build worlds that feel infinitely deep, yet always within reach. Meer Balaj is a game developer from Pakistan with over three years of experience building games across mobile, WebGL, AR, VR, and PC platforms. His journey into the industry began at Pakistan’s largest game jam, Mindstorm Studios’ Game Jam, where he won the Best Mechanics award and was later selected among a small group of participants nationwide for an internship opportunity.Since then, he has shipped multiple titles in the casual, hypercasual, and educational spaces, working with international clients and teams. As a developer, his goal is to create games that go beyond pure entertainment and leave a lasting impact on players and communities, which is why many of his projects integrate elements of learning within the gameplay experience. You can find out about his latest projects here: https://meerbalaj.site/ Top Dev Headlines (March 2026) Microsoft teases next-gen Xbox “Project Helix”: Microsoft has confirmed early details of its next console, codenamed Project Helix, aimed at blurring the line between Xbox and PC. The company says the platform will deliver stronger performance for next-gen games while deepening integration between the two ecosystems, which is another step toward a unified development and play experience.Skillz launches Pro SDK for competitive mobile games: Skillz unveiled a new Pro SDK at GDC 2026 designed to give developers deeper control over competitive multiplayer and monetization. The toolkit streamlines real-money tournaments, matchmaking, and scalable competition systems for mobile games.GDC 2026 spotlights indie discoverability crisis: With thousands of games launching on storefronts every month, indie developers are struggling to stand out. At GDC 2026, sessions are focusing on new strategies, from community-driven marketing to alternative storefronts, to help smaller teams cut through the noise.Embark to break down ARC Raiders reboot at GDC: Embark Studios will showcase how it rebooted its upcoming shooter ARC Raiders, offering a behind-the-scenes look at resetting a AAA project mid-development. The studio will also discuss its evolving production pipeline, including new AI-assisted workflows.AAA veterans form new indie studio: Veteran developers from Radical Entertainment and Hothead Games have launched a new independent studio, continuing the industry trend of experienced talent leaving major publishers for smaller, creator-driven teams.Upcoming Game Events Future Games Show Spring Showcase (Online) – Mar 12: A global digital showcase featuring world premieres, trailers, and developer interviews for upcoming titles. The show is known for revealing new gameplay and giving studios a platform to spotlight their latest projects to millions of viewers worldwide.Game On Expo 2026 (Phoenix, AZ, USA) – Mar 13-15: A major gaming convention blending retro and modern gaming culture with tournaments, cosplay, live music, and indie developer showcases. The event attracts thousands of gamers and creators looking to celebrate gaming history while exploring new titles.CT Gamer & Anime Con (Uncasville, CT, USA) – Mar 14-15: A community-driven convention bringing together gamers, voice actors, developers, and content creators. Panels, esports tournaments, and industry discussions make it a lively meeting point for both fans and aspiring game developers.PAX East 2026 (Boston, MA, USA) – Mar 26-29: One of the largest gaming festivals in North America, featuring major publisher showcases, indie game demos, panels with industry leaders, and esports competitions. It’s a key event for developers looking to showcase upcoming games and connect with the wider gaming community.DreamHack Birmingham 2026 (Birmingham, England) – Mar 27-29: A massive gaming and esports festival combining competitive tournaments, creator meetups, LAN parties, and live entertainment. The event also hosts qualifiers for major esports competitions and attracts thousands of fans across the UK and Europe.Tool of the Week: RenderDoc When something looks wrong on screen, the problem usually isn’t obvious. A shader behaves strangely, lighting flickers, or a texture just refuses to cooperate, and suddenly you’re staring at your screen wondering where in the GPU pipeline things went sideways. That’s where RenderDoc shines. It’s a powerful graphics debugger that lets you capture a single frame of your game and inspect exactly what the GPU was doing at that moment—every draw call, shader, texture, and buffer frozen in time. Instead of guessing, you can step through the rendering pipeline, inspect shader inputs, visualize render targets, and replay draw calls one by one to pinpoint the exact moment something breaks. Graphics bugs are notoriously painful to track down, but RenderDoc turns the GPU from a black box into something you can actually interrogate, and once you start using it, you’ll wonder how you ever debugged rendering issues without it. 🎮⚙️Quick Dev Tips Log Your RNG During Playtests: When players say the game feels “unfair,” don’t guess. Log it. Record spawn rolls, drops, and probabilities during playtests so you can analyze what actually happened. Many RNG problems only become obvious when you review real gameplay data.Simulate Thousands of Runs: Before shipping any system that relies on randomness, run large simulations. Thousands of automated runs can reveal edge cases, unwinnable states, or distribution problems that would take weeks of manual testing to uncover.Design for Recovery, Not Just Success: Even well-balanced systems will occasionally produce bad luck streaks. Good design includes subtle recovery paths such as alternate strategies, secondary mechanics, or small assists that help players regain momentum without making the system feel rigged.Game Dev Jobs Board Unity Developer – Hitapps: A full-time remote role focused on implementing gameplay mechanics, integrating assets, and building systems in Unity. This position is ideal for developers comfortable with C# and looking to contribute to live game production in a distributed team.Unity Developer (Junior / Middle) – Octo Games Studio: A remote Unity position working on casual and puzzle-style games. Great for developers looking to gain experience building gameplay systems while collaborating with designers and artists on production features.Senior Unity XR Developer – Arc.dev Network: A fully remote senior role focused on building XR and VR experiences in Unity. The position emphasizes performance optimization and immersive gameplay systems for next-generation interactive environments.Unity SDK Technical Lead – Hypercell Games: A senior remote leadership role responsible for shaping Unity SDK architecture and internal tooling. This is ideal for experienced engineers who want to influence platform infrastructure and developer workflows.Unity Software Engineer – Easy Games: A remote engineering role working on gameplay systems and large-scale game architecture. The position suits developers who enjoy building robust game systems and collaborating closely with cross-disciplinary teams.