WebDevPro

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 #132 Async Code That Looks Fine but Fails in Production Crafting the Web: Tips, Tools, and Trends for Developers Most Spring Boot projects stop at REST APIs Most Spring Boot developers stop at REST APIs. That’s enough to build demos but not to build systems that survive production. The real work sits beyond that. Service discovery, resilience, observability, config management are what separate working code from systems that hold up under pressure. You don’t pick this up from tutorials. It comes from building systems, making trade-offs, and seeing them run. Tomorrow, you get exactly that. Live. From scratch. With Simon Martinelli and Josh Long. Only 6 spots left. 🎟 Use code SPRING40 for 40% OFF 📢 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! Have you ever written async code that looked perfectly fine, only for it to behave unpredictably later? It’s one of those things that feels obvious while coding, but starts to fall apart once real conditions come into play. Asynchronous programming is fundamental to Node.js. The event loop keeps everything moving, delegating work and picking it back up when results return. On paper, it feels straightforward. You write code in sequence, so it should run that way too. But that’s where things get tricky. Execution is shaped by timing, scheduling, and resource contention. These are not visible in the code itself. What looks sequential can run concurrently. What feels predictable can change under load. Many real-world issues don’t come from syntax errors, but from how async behavior interacts with shared resources and execution order. This week’s deep dive breaks down where these assumptions fail and what it takes to make async systems behave reliably. Before we get into it, here’s this week at a glance: 🟦 TypeScript is preparing for a compiler rewrite 📦 pnpm is redesigning how dependencies are stored 🤖 Next.js is pushing toward AI-first app development ⚡ Claude dropped SSR for speed gains 🧩 Storybook is becoming AI-readable infrastructure When Async Execution Breaks Assumptions A common source of failure is incorrect assumptions about execution order. Consider a case where two operationsattempttowrite tothe same file. The code may appear sequential, but without explicit coordination, the operations execute independently. In such scenarios, the following pattern is oftenobserved: async functionraceCondition() { const filename = ... await unlink(filename) writeFile(filename, 'Written from first promise\n',{ flag: 'a' }) writeFile(filename, 'Written from second promise\n',{ flag: 'a' }) } At first glance, this code appears correct because two write operations are triggered one after the other.However, the absence of awaiting these operations means they run concurrently. Both operationsattemptto access the same file at the same time. This leads to inconsistent results, where the order of writes varies across executions. This behavior is known as a race condition. The issue is not syntax, but incorrect assumptions about how asynchronous execution works. Concurrency Does Not Guarantee Order In asynchronous systems, starting operations sequentially does not guarantee sequential execution. Each asynchronous call creates its own execution path, and these paths are resolved independently based on system timing. When multiple operations target the same resource, they compete for access. Without explicit coordination, the runtime does not guarantee which operationcompletesfirst. The outcome becomes dependent on timing rather than intent. This variability may not appear during development but becomes more prominent under production load, where multiple operationsexecutesimultaneously. Coordinating Access: Controlling Async Behavior To prevent race conditions, access to shared resources must be controlled. One approach is to introduce a mechanism that ensures only one operation interacts with the resource at a time. The following structuredemonstratesthis approach: classFileWriter{ #isWriting = false static instance = null constructor() { if (!FileWriter.instance) { FileWriter.instance= this } return FileWriter.instance } asyncwriteFile(filename, data) { if (this.#isWriting) { awaitsetTimeout(250) returnthis.writeFile(filename, data) } this.#isWriting= true const result = awaitwriteFile(filename, data, { flag: 'a' }) this.#isWriting= false return result } } This implementation introduces a lock mechanism. If a write operation is already in progress,subsequentoperationswaitbefore retrying. This ensures thatwritesoccur sequentially rather than concurrently. With coordination in place, execution becomes predictable. Without it, asynchronous code may behave inconsistently under real conditions. Callback Hell: When Async Structure Breaks Readability Asynchronous issues are not limited to executionorder. They also affect howcodeis structured. Deeply nested callbacks create code that is difficult to read andmaintain. An example of this structure is shown below: stepOne((err,resultOne) => { stepTwo(resultOne, (err,resultTwo) => { stepThree(resultTwo, (err,resultThree) => { console.log(resultThree); }); }); }); Although the code executes correctly, the nested structure makes it harder to follow the flow of data and control. Error handling is repeated at each level, increasing complexity. As the number of steps increases, the difficulty ofmaintainingand debugging the code also increases. The Event Loop and Hidden Blocking Node.js relies on non-blocking operations tomaintainperformance. The event loop processes tasks and delegatesworkwhen possible, allowing other operations to continue executing. However, not all operationsare non-blocking. Some APIs perform blocking I/O, which pauses execution of the entire program until completion. This prevents the event loop from handling other tasks. For example, cryptographic operations can block the main thread when executed synchronously. An asynchronous alternative allows work to be delegated externally: generateKeyPair("rsa", {modulusLength:1024 }, () => {}) The asynchronous version allows other operations to continue, while the synchronous version blocks execution. Under production load, blocking operations can significantly reduce system responsiveness. Async Does Not Always Mean Non-Blocking A common misconception is that wrapping a function in asynchronous code makes it non-blocking. This is not always true. If the underlying operation is blocking, it will still block execution. In such cases, performance improvements come from reducing how often the operation runs rather than changing how it is invoked. For example, caching results avoids repeated expensive computations: letcachedSignature= null; if (!cachedSignature) { cachedSignature=signData(...) } This approach improves throughput by reducing execution frequency rather than altering execution style. Async Behavior Under Load Many asynchronous issues only become visible under load. In controlled development environments, operations often execute in predictable sequences, and resource contention is minimal. As a result, code that appears stable during testing can behave differently when multiple operations are triggered at the same time. Race conditions become moreapparentwhen concurrent requests attempt to access ormodifythe same resource. What may appear as an occasional inconsistency during development can become a frequent issue when the same code is executed repeatedly under higher traffic. The lack of coordination between asynchronous operations leads to unpredictable results, making these issues harder to reproduce and debug. Blocking operations also have a more pronounced impactunderload. When a synchronous task runs on the main thread, it prevents the event loop from processing other incoming requests. In low-traffic scenarios, this delay may not be noticeable. Under production conditions, where many requests arrive simultaneously, blocking behavior can cause cascading delays, reducing overall responsiveness. Repeated execution of expensive operations further amplifies the problem. When the same computation is performed for every request without caching or reuse, system resources are consumed unnecessarily. This reduces throughput and increases response times, especially when multiple requests trigger the same operation concurrently. Anotherimportant factoris timing variability. Asynchronous execution depends on system scheduling, resource availability, and workload distribution. Under load, these factors fluctuate more significantly, increasing the likelihood of inconsistent outcomes. Code that relies on implicit ordering or timing assumptions becomes less reliable as concurrency increases. These issues highlight that asynchronous behavior is not only about writing non-blocking code, but also about understanding how that code behaves when multiple operations interact simultaneously. Without coordination, control over execution order, and careful management of shared resources, asynchronous systems can produce inconsistent results under real-world conditions. Final words Asynchronous programming enables Node.js to handle multiple operations efficiently, but it also introduces complexity in execution order, resource access, and performance. Many failures are caused by incorrect assumptions about how asynchronous code behaves. These issues oftenremainhidden during development and only surface under production conditions. Understanding how asynchronous code interacts with the event loop, shared resources, and system constraints is essential for building reliable applications. This Week in the News 🟦TypeScript 6.0 is really about TypeScript 7.0: TypeScript 6.0 quietly sets the stage for a bigger shift. This release moves the ecosystem closer to a Go-powered native compiler planned for TypeScript 7.0, with clear signals that performance and build speed are about to take a serious leap. It focuses less on surface-level features and more on groundwork that could reshape how large codebases compile and scale. 📦 pnpm 11 Beta just changed how dependencies are stored: pnpm 11 Beta offers a glimpse into where package management is heading. The shift to a SQLite-powered store improves lookup speed and reliability, while a broader config overhaul simplifies how projects define and share settings. Stricter build security is now enabled by default, reflecting a growing focus on supply chain safety. This release feels less like an incremental update and more like a rethink of how dependencies are stored and secured. 🤖Next.js just made AI apps feel native: Next.js 16.2 leans deeper into AI-native development. The update reshapes how developers connect model output to real interfaces, tightening the loop between prompting and product. The direction is becoming clear. Next.js is evolving into a foundation for AI-powered applications, not just a frontend framework. ⚡Why Claude dropped SSR for a Vite-powered setup: Anthropic’steam shared how they made Claude and its desktop apps meaningfully faster by moving away from SSR to a static setup using Vite andTanStackRouter. The shift highlights a growing pattern where speed and responsiveness win over traditional rendering models, especially for AI-heavy interfaces that demand instant feedback. 🧩 Storybook MCP brings AI into your UI workflow:Storybook’s latest update introduces an MCP server that lets coding agents understand your components at a deeper level. Instead of guessing structure, AI can now access metadata, generate stories, write tests, and even help fix bugs with more context. It signals a shift where component libraries are no longer just for developers, but also for the tools assisting them. Beyond the Headlines 🧠Fix your Next.js errors without exposing your code: Debugging production errors in Next.js often means staring at unreadable stack traces. This guide walks through setting up source maps withSentryso errors point back to your actual code, not minified chunks. The key detail is balance. You get full visibility in Sentry while keeping source maps out of the browser, which protects your code and improves debugging at the same time. 📊 Most open source projects are already accepting AI code:Phil Eaton surveyed 112 major source-available projects to understand how they handle AI-assisted contributions. The results show a clear trend. Most projects already allow or have accepted AI-generated code, with only a handful enforcing outright bans. The takeaway is not just policy, but reality. AI is already part of how modern open source evolves, and governance is still catching up ⚛️The React quirks you hate are actually fundamental: Some ofReact’smost disliked patterns, like deferred state updates and dependency arrays, are not accidental complexity. This piecearguesthey reflect deeper constraints of asynchronous UI systems. Once you look past the friction, they reveal problems every framework eventuallyhas tosolve, even the ones trying to replace React. 🧩Small programming tricks shape how your code scales: Tiny habits compound. This piece explores how small implementation choices, often dismissed as style or preference, quietly influence readability, maintainability, and long-term velocity. It is a reminder that good engineering is rarely about big rewrites. It is built through consistent, low-level decisions that add up over time. Tool of the Week ✍️ Draw it once, animate it instantly Stroke turns rough sketches into production-ready animations. You draw directly in the browser, and it generates Motion-based code you can drop into a React or Next.js component. Under the hood, it converts your strokes into SVG paths and animates them without manual setup, making it ideal for signatures, logos, or playful UI details. 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 👋 Advertise with us Interested in sponsoring this newsletter and reaching a highly engaged audience of tech professionals? Simply reply to this email, and our team will get in touch with the next steps. 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;} }

Crafting the Web: Tips, Tools, and Trends for DevelopersAdvertise 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 #131Building Reliable Applications with Cursor: A Spec-Driven Workflow for Incremental DevelopmentCrafting the Web: Tips, Tools, and Trends for DevelopersMost Spring Boot projects stop at REST APIsReal 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 SubstackWe’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 been experimenting with tools like Cursor, you’ve probably had that moment where the output looks promising but not quite right. You tweak the prompt, try again, and end up chasing the result instead of building something stable.What tends to work far better is not bigger prompts or more detailed instructions, but a shift toward a spec-driven, incremental workflow. One that mirrors how experienced developers already build systems, but adapts it to work effectively with AI-assisted coding environments.In this article, we want to walk through a more reliable way to approach this. By the end, you’ll have a practical workflow for structuring your projects, breaking down features, and working with AI coding tools in a way that actually scales beyond small experiments.Why direct prompting breaks down in real projectsIt is tempting to treat Cursor as a high-powered code generator. Describe the app, mention the tech stack, and expect a complete implementation.That approach holds up for small, disposable prototypes. It starts to fracture as soon as the project has multiple features, shared state, or evolving requirements.There are a few reasons for this.First, ambiguity compounds quickly. Even a well-written prompt leaves room for interpretation. The model fills in those gaps based on patterns, not your intent.Second, outputs are inherently variable. The same prompt can produce slightly different structures, naming conventions, or flows. This makes it difficult to build predictably.Third, you give up control of the system’s shape. Instead of designing the architecture, you are reacting to whatever the model generates.The result is a loop of correction rather than a process of construction.A more reliable approach: constrain, decompose, iterateA more effective pattern is to treat the tool as a collaborator that works best within clearly defined boundaries.The workflow is straightforward:Define what the system should doBreak it into discrete units of workImplement those units incrementallyRefine through feedbackThis is familiar territory. The difference is that your artifacts, like specifications and task lists, are now also guiding the model.Start with a specification that removes guessworkBefore opening Cursor, it helps to define how the application should behave in concrete terms. Consider a simple example: a math practice application for children.At a glance, it sounds trivial. In practice, it involves a number of decisions:What kinds of operations are supportedHow questions are presentedHow users interact with answersHow incorrect attempts are trackedWhat metrics are surfaced in a statistics viewWriting this down in a structured format forces clarity. It also creates a shared reference point for every subsequent step.One useful approach is to draft the specification in Markdown using a general-purpose language model. The key is not the initial output, but the interaction that follows. Asking the model to clarify uncertainties before generating the spec often leads to better results.Once you have a draft, it is worth reviewing line by line. Fill in gaps, remove contradictions, and add constraints that matter to you. Visual expectations, state transitions, and edge cases are all worth capturing early.The specification becomes less of a document and more of a contract. It defines intent in a way that both you and the tool can consistently refer back to.Translate the specification into a phased TODO listWith a clear specification in place, the next step is to decompose it into manageable units of work.Instead of thinking in terms of “build the app,” the focus shifts to “implement the next smallest meaningful piece.” A structured TODO list works well for this. Features are grouped into phases, and each phase contains tasks that can be completed independently.For example: Phase 1: Project setupInitialize React applicationConfigure styling systemCreate base routing and placeholder pages Phase 2: Core interactionGenerate math questionsRender question cardsImplement answer selection logicThis breakdown serves two purposes: It reduces cognitive load. You are no longer juggling the entire system in your head. It also gives Cursor a much clearer target. Instead of interpreting a broad request, it can focus on a well-defined task.Build incrementally and keep the scope tightWith the TODO list in place, you can begin implementing features in Cursor. The important shift here is how you frame your prompts. Rather than asking for a full implementation, you anchor the request to specific artifacts and a limited scope:Use the specification and TODO list to complete Phase 1. Mark completed tasks.This keeps the model grounded. It knows where to look for context and what success looks like. In the case of the math practice app, the first phase might result in:A scaffolded React projectBasic routingPlaceholder pages such as Home, Practice, Stats, and SettingsAt this stage, the application is simple, but functional. That is intentional. Each phase establishes a stable base for the next.Iterate deliberately instead of restartingOnce the initial output is in place, the next step is refinement.It is common for the first version of the UI or structure to feel underdeveloped. The instinct might be to rewrite the prompt or regenerate the feature from scratch. A more effective approach is to iterate on top of what already exists.For example:Improve the homepage layout. Add clearer navigation and better spacing.This kind of prompt is focused and contextual. It builds on existing work rather than replacing it.Over time, this creates a steady progression:Initial structureIncremental improvementsTargeted fixesEach step is small, but collectively they move the system toward a more polished state.Designing for variability instead of fighting itOne characteristic of working with language models is that outputs are not perfectly consistent. Even with the same inputs, you may see variations in structure, naming, or implementation details. Rather than trying to eliminate this variability, it helps to account for it in your workflow.Specifications anchor intent.TODO lists constrain scope.Incremental development limits the blast radius of changes.Together, these reduce the impact of variation. You retain control over the system, even as the underlying outputs shift slightly.A closer look at a single featureTo make this more concrete, consider the first phase of the math practice application. The goal is to establish the basic application shell. You begin with two inputs:A specification that defines pages and navigationA TODO list that outlines setup tasksThe prompt is simple and scoped:Complete Phase 1 using the provided specification and TODO list.Cursor initializes the project, sets up dependencies, and creates the necessary files. You run the application locally and see a basic interface with navigation between pages. At this point, the system is functional but minimal. You then refine:Improve the visual structure of the homepage and navigation.The tool updates components, adjusts layout, and introduces better spacing. You review the changes, keep what works, and continue. This pattern repeats for each feature. The system grows in layers, each one built on a stable foundation.Patterns that hold up in larger projectsA few patterns consistently make this approach effective. Clear specifications reduce the need for corrective prompts later. They shift effort from fixing outputs to shaping intent early.Breaking work into smaller tasks improves reliability. Each unit is easier for the model to interpret and implement correctly.Iteration keeps progress steady. Instead of waiting for a perfect result, you move forward through a series of improvements.Documentation becomes an active part of the process. Specifications and TODO lists evolve alongside the code, keeping everything aligned.Most importantly, you remain in control of the system’s design. The tool accelerates execution, but the direction still comes from you. But this workflow is not automatic. It depends on a few habits.If the specification is vague, the outputs will reflect that.If tasks are too large, the results become inconsistent again.If changes are accepted without review, small issues compound over time.The tool amplifies the process you bring to it. Structure leads to leverage. Lack of structure leads to friction.Closing thoughtsWorking with Cursor is less about mastering prompts and more about shaping a reliable development process. Once you move away from one-shot generation and toward a spec-driven, incremental approach, the experience changes. The tool becomes more predictable. The codebase becomes easier to reason about. Progress feels steadier.In many ways, this is not a new way of building software. It is a return to fundamentals, adapted for a new interface. The difference is that when the structure is right, the speed at which you can move begins to compound.If you want to go deeper into this way of working, especially with hands-on examples and a full project walkthrough, this approach is explored in detail in Vibe Coding with Cursor. It’s a practical guide to building real applications using these patterns, and a useful next step if you’re looking to move beyond experimentation into something more structured.This Week in the News🤖 OpenAI to acquire Astral: OpenAI is acquiring Astral and its widely used open-source Python developer tools, including uv, Ruff, and ty. The move strengthens OpenAI’s push into developer tooling, bringing core workflows like dependency management, linting, and type checking closer to its ecosystem. The goal is to accelerate Codex beyond code generation, positioning it to operate across the full development lifecycle, where it can work directly within the tools developers already use.🗓️ Why JavaScript still struggles with dates: The JavaScript new Date(someString) constructor is notoriously over-eager, stemming from legacy C++ parsers in engines like V8 and SpiderMonkey that aggressively "guess" date components to maintain backwards compatibility. This leads to absurd "hallucinations" where the engine prioritizes finding a year at any cost. Beyond these quirks, the parser's inconsistency is a frequent source of production bugs; for instance, new Date("2024-03-25") is treated as UTC, while adding a time element like T00:00 shifts it to Local Time, often causing "off-by-one-day" errors for users in different time zones. To avoid silent data corruption, such as new Date(null) defaulting to the 1970 Unix Epoch, developers should abandon these loose string constructors in favor of strict ISO 8601 formatting or the modern, predictable Temporal API.▲ Next.js 16.2 updates:Next.js 16.2 introduces a set of refinements focused on improving performance, stability, and the overall developer experience. The release builds on recent changes to the app router and server components, with updates that make common workflows more predictable and easier to manage. The direction remains consistent, with Vercel continuing to smooth out rough edges while aligning Next.js more closely with modern React patterns and production needs.⚡Vite 8 and Void, the fill-stack pivot: The Vite ecosystem is expanding beyond build tooling. Alongside the release of Vite 8, which brings updates focused on faster builds and a more streamlined developer experience, the VoidZero team has introduced Void, a Vite-native deployment platform built on Cloudflare Workers. Void aims to turn Vite apps into full-stack applications by bundling capabilities like databases, KV storage, object storage, and AI inference directly into the workflow. Together, these updates signal a shift toward a more integrated Vite stack that spans both development and deployment.⚖️ No AI code in Node.js core? A new petition sparks debate:A long-running discussion around AI-assisted development in OpenJS Foundation projects has taken a new turn. A Node.js contributor has started a petition urging the TSC to restrict AI-generated code from being merged into Node’s core, following concerns raised alongside a large 19K LOC PR. The debate touches on deeper questions around code quality, maintainability, and ownership as AI becomes a common part of development workflows.🧩 How TanStack approaches modern developer tooling:TanStack shares a set of ecosystem updates alongside a detailed talk that breaks down the thinking behind its tooling approach. The focus stays on building framework-agnostic, composable primitives that can scale across different application architectures without locking developers into a specific stack. The talk offers a deeper look into how these decisions play out in practice, from managing server state to structuring UI logic, and why flexibility and interoperability remain central to TanStack’s design philosophy.Beyond the Headlines📉 The hidden cost of “comprehension debt”:Addy Osmani introduces the idea of comprehension debt: the growing gap between how quickly code can be produced and how easily it can be understood. As tools (especially AI) accelerate code generation, the burden shifts to developers who need to read, debug, and maintain that code. It’s a useful lens for thinking about long-term code quality. Fast output is valuable, but only if teams can still reason about what they’ve built.🧠 React to Svelte migration with AI agents: Strawberry shares how it rewrote 130K lines of React code to Svelte in just two weeks using coding agents, cutting UI complexity and doubling performance in the process. The write-up goes deeper into why the team moved away from React’s rendering model toward Svelte’s compiler-first approach, and how AI-assisted workflows made a full rewrite practical at a scale that would usually take months. It’s a strong signal of how framework decisions, performance constraints, and AI-driven development are starting to converge in real-world systems.🎥 Rethinking how we build modern web apps: This talk explores how modern web development is evolving, touching on architecture, tooling, and the trade-offs developers face as applications grow in complexity. It’s a useful watch if you’re thinking about how today’s patterns scale in real-world systems.🚄 Understanding how JIT affects runtime performance: This post explores how Just-In-Time (JIT) compilation behaves in practice, looking at how execution performance evolves over time. It offers a deeper look at runtime optimizations and how they impact real-world performance characteristics.Tool of the Week🔍 Understand code changes with structural diffsTraditional diffs compare text line by line, which can make complex changes hard to follow. Difftastic takes a different approach by comparing the syntax tree of your code, helping you see what actually changed at a structural level.It supports multiple languages and highlights meaningful differences, making it especially useful when reviewing refactors or large code updates.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👋 Advertise with usInterested in sponsoring this newsletter and reaching a highly engaged audience of tech professionals? Simply reply to this email, and our team will get in touch with the next steps.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;} }

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;} }

Crafting the Web: Tips, Tools, and Trends for DevelopersAdvertise 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 #129Why Single Page Applications Changed How We Build Web AppsCrafting the Web: Tips, Tools, and Trends for DevelopersMost Spring Boot projects stop at REST APIsReal 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 SAVE40Welcome to this week’s issue of WebDevPro!Take a moment to think about the web apps you use every day. A dashboard updates without refreshing the page. A chat window receives messages in real time. A project board moves tasks across columns instantly.Modern web applications behave very differently from traditional websites. Interfaces update instantly, dashboards refresh without reloading the page, and navigation feels closer to using installed software than browsing documents. This experience is powered by an architectural shift called the Single Page Application, or SPA.By the end of this article, you will understand three things that shape modern frontend systems. First, what actually defines a Single Page Application beyond the buzzword. Second, why the SPA model improves responsiveness and interactivity in web applications. And third, how React enables this architecture through its rendering model and state-driven design.This is not a tutorial about setting up React or writing components. Instead, the goal is to understand the architectural thinking behind SPAs and how React fits into that model.The architectural shift behind modern web appsEarly websites were built around a page-based model. Each interaction triggered a request to the server, which generated a new HTML document and returned it to the browser. This worked well when the web primarily delivered content.Modern web applications demand a different experience. Consider tools such as analytics dashboards, project management systems, or collaborative editors. Users interact continuously with the interface. Data updates frequently, UI elements move around the screen, and navigation happens rapidly.In a traditional page-driven architecture, each of those interactions would require a server request and a full page refresh. Even small updates would rebuild the entire interface.Single Page Applications address this limitation by shifting the responsibility for rendering the interface into the browser itself.Instead of repeatedly requesting new pages, the browser loads the application once and then updates the interface dynamically as data changes. This change might sound simple, but it transforms the browser from a document viewer into a runtime environment for applications.What actually defines a Single Page ApplicationThe term “Single Page Application” can be misleading. It does not mean an application literally has only one page in the user experience. Instead, it describes how the application is delivered and rendered.A SPA typically loads a single HTML document that acts as a container for the application. Once the application initializes, JavaScript takes responsibility for rendering and updating the interface.From that point onward, most user interactions modify the current interface rather than loading new documents.Several architectural patterns define this approach.Client-side renderingIn a traditional website, the server generates HTML for each page request. In a SPA, the browser renders most of the interface.The server still plays an important role. It provides data through APIs and delivers the initial application bundle. However, the frontend application determines how that data appears on the screen.This allows the interface to update instantly when new data arrives.Persistent application runtimeBecause the application remains loaded in the browser, its logic persists across user interactions.Instead of rebuilding the interface from scratch, the system modifies the existing UI based on changes in application state.This persistence allows applications to maintain context and update small pieces of the interface without resetting the entire page.Virtual navigationUsers still see URLs change when navigating through a SPA, but the navigation logic is handled inside the application rather than by the server.The application interprets the URL and determines which components to display. From the user's perspective, the experience feels like normal navigation. Internally, the browser remains on the same underlying document.Together, these characteristics create the foundation of SPA architecture.Why the SPA model improves responsivenessThe key advantage of SPAs is not simply that they avoid page reloads. The deeper benefit is that they reduce unnecessary work.In a page-based system, the browser discards the entire interface whenever a new page loads. The server reconstructs the page, sends it back, and the browser renders it again.In a SPA, the application updates only the parts of the interface that change.Once the application code is loaded, the browser already contains everything needed to update the UI. When data changes, the system redraws only the relevant components rather than rebuilding the entire page.This approach becomes particularly valuable in highly interactive environments.Imagine a data dashboard where metrics update continuously while users filter results, adjust settings, and move between views. Rebuilding the entire interface for each interaction would create unnecessary delays.SPAs allow these updates to happen immediately because the rendering logic runs locally in the browser.However, this architecture introduces new complexity. The browser must now manage application state, UI rendering, and navigation. Without structured tools, this quickly becomes difficult to maintain.This challenge is where frameworks such as React play an important role.How React enables SPA architectureReact does not directly implement the SPA model. Instead, it provides a system that makes managing dynamic interfaces significantly easier.At its core, React helps developers answer a difficult question: how should the interface update when application data changes?Instead of manipulating the browser DOM directly, React introduces a model where the UI is described as a function of application state.This approach rests on two key ideas: the Virtual DOM and state-driven rendering.The Virtual DOM and efficient UI updatesEvery webpage contains a structure known as the Document Object Model, or DOM. The DOM represents the hierarchy of elements that make up the interface.Updating the DOM directly can become expensive when applications contain large numbers of elements or frequent updates.React addresses this problem through the Virtual DOM.The Virtual DOM is an in-memory representation of the interface maintained by React. When application state changes, React creates a new representation of the interface and compares it with the previous version.This comparison process determines exactly what has changed between the two states.React then updates only those elements in the real DOM that need to change. This process is often referred to as reconciliation.By reducing the number of direct DOM operations, React helps maintain performance even when applications grow large and complex.State as the driver of the interfaceThe second important idea in React is that the interface should be driven by state.React applications are built from components, each representing a piece of the user interface. Components maintain state that describes the data they display.When that state changes, React automatically updates the component's output and reconciles the differences in the DOM.A simplified example illustrates the concept.import { useState } from "react";function Counter() { const [count, setCount] = useState(0); return ( <button onClick={() => setCount(count + 1)}> Count is {count} </button> );}In this example, the interface is directly derived from the value of count. When the state changes, React recalculates the component output and updates the interface accordingly.Developers do not manually manipulate DOM elements. Instead, they describe how the interface should look given a particular state.This declarative model simplifies reasoning about complex interfaces. It also aligns naturally with the needs of Single Page Applications, where the interface must update frequently in response to data changes.Why React became central to modern frontend developmentReact's design aligns well with the requirements of SPA architecture.Component-based design allows large interfaces to be broken into smaller, manageable pieces. Each component encapsulates its logic, state, and rendering behavior.The Virtual DOM helps maintain performance by minimizing unnecessary DOM updates. Meanwhile, React's state-driven model ensures that the interface stays synchronized with application data.Together, these ideas provide a structured approach to managing dynamic user interfaces.This combination of performance and developer ergonomics helped React become one of the most widely used frameworks for building modern web applications.Final wordsSingle Page Applications represent a shift in how the web is used. Instead of treating the browser as a document viewer, modern applications treat it as an execution environment for complex software.This architectural shift allows web applications to behave more like native software, delivering responsive interfaces and fluid user experiences.Understanding SPAs means understanding three core ideas. First, the browser now handles much of the interface rendering that used to happen on the server. Second, applications persist in the browser and update the interface dynamically rather than rebuilding pages. And third, frameworks such as React provide the abstractions needed to manage the resulting complexity.Once you view the web through this lens, many modern frontend patterns begin to make sense. Component-based architectures, state-driven rendering, and client-side routing all exist to support the same goal: building web applications that behave like real software rather than collections of pages.These concepts are explored further in Full-Stack React, TypeScript, and Node (2nd Edition), currently available in early access for PacktPub subscribers.Preorder now!This Week in the News📊 State of React Native results are out: The latest State of React Native survey is live, offering a snapshot of how developers are using the framework today. It covers adoption trends, satisfaction, tooling, and common pain points across the ecosystem. Worth a look if React Native is part of your stack or roadmap.🤖 Cloudflare rebuilds Next.js as AI reshapes the commercial open source model: Cloudflare surprised the developer community this week by claiming that a single developer rewrote Next.js in just one week using AI tools, spending about $1,100 in tokens. The experiment highlights how quickly large codebases can now be recreated with AI-assisted development, raising new questions about the speed and economics of building complex frameworks.📈 Next.js 16 upgrade triggers unexpected request spikes: Some developers upgrading from Next.js 15 to 16 report higher server request volume and increased response latency. The change appears to put more strain on backend infrastructure, which could mean higher compute usage and increased hosting costs in production. A useful read if you’ve ever been surprised by a framework behaving differently outside local dev.🔐 When a GitHub Issue Becomes a Supply Chain Attack: A security write-up explains a vulnerability chain called Clinejection that exploited an AI GitHub issue bot. The attack combined prompt injection with CI cache poisoning to publish a malicious package. It’s a good reminder that AI agents in developer workflows introduce a new kind of supply chain risk.💬 Vercel introduces the AI Chat SDK: Vercel has released a new Chat SDK aimed at simplifying how developers build conversational AI interfaces. The SDK provides primitives for streaming responses, handling message state, and integrating with multiple AI providers. If you’re building AI features into web apps, it removes a lot of the plumbing typically required for chat-style interactions.Beyond the Headlines🔄 Migrating from TypeScript 5.x to 6.0: This GitHub gist explores some extreme TypeScript type patterns that push the compiler surprisingly far. It’s a fascinating look at how conditional types, inference, and recursion turn TypeScript into something close to a compile-time programming language.🤖 AI Is Writing More Software, but Who Checks the Output?: Lean creator Leo de Moura explores what happens if AI systems eventually generate the majority of production code. The essay looks beyond productivity gains and asks deeper questions about verification, correctness, and how we maintain trust in software when humans are no longer writing most of it. A thoughtful perspective on where AI-assisted development could lead.🎞 Web Performance with Image Sprites: Sprite animations are an old web technique that still works surprisingly well today. Josh Comeau walks through how sprite sheets function, how to implement them with modern CSS, and when they’re preferable to other animation approaches. A great refresher for anyone building playful UI interactions or performance-friendly animations.🧠 Patterns for building agentic systems: Simon Willison breaks down emerging patterns in “agentic engineering” workflows. The article looks at how developers are structuring AI agents that can reason, call tools, and coordinate tasks across systems. If you’re experimenting with agent-style architectures, this piece highlights the design patterns that are starting to emerge.Tool of the Week🧩Build Custom Rich Text Editors with YooptaIf you're building apps that need rich text editing, finding a flexible editor can be tricky. Many solutions are either too rigid or difficult to extend.Yoopta Editor is a modern, open source rich text editor framework built for React. It uses a block-based architecture, making it easier to customize editing experiences, add plugins, and control how content is structured.For developers building CMS tools, collaborative editors, or AI-assisted writing interfaces, Yoopta offers a flexible foundation without forcing a fixed editing model.That’s all for this week. Have any ideas you want to see in the next article? Hit Reply!Cheers!Editor-in-chief,Kinnari ChohanSUBSCRIBE 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;} }

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 #128 TypeScript Under Pressure in Evolving Full Stack Systems 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 Welcome to this week’s issue of WebDevPro. This issue looks at a common transition in modern engineering: taking a fast proof of concept and turning it into something that can survive real change. Consider a small internal AI support chatbot. The architecture is simple. A React frontend collects messages and sends them to an Express POST /api/chat endpoint. The server returns a short reply. The goal here is speed, not durability. To move quickly, the frontend stores messages as any[]. The backend reads req.body.messages from untyped JSON and returns a response like: { "reply": "You said: hello" } There is no formal contract between frontend and backend. The agreement lives in shared understanding: reply is a string, and messages is an array of objects with role and content. When both sides are written close together, this feels stable. Then the requirements change. The reply must now include structured data: the assistant’s message, references, and follow-up questions. The backend evolves and begins returning an object under reply instead of a string. The frontend does not change. The build passes. The browser fails at runtime because React attempts to render an object as if it were a string. Nothing in the type system flagged the mismatch because nothing at the boundary defined what the response was supposed to be. This is where TypeScript either acts as a safety mechanism under change or becomes a thin layer of annotations. What follows is a practical look at how that same chatbot evolves into a production-safe system by making contracts explicit and boundaries deliberate. Phase One: Turning Assumptions into a Shared Contract The chatbot did not break because the change was complex. It broke because the change was invisible to the type system. On the frontend, state was typed as any[]. The API response was treated as whatever res.json() returned. On the backend, req.body was used without an explicit shape. From TypeScript’s perspective, there was nothing concrete to compare, so the change in response structure did not register as a problem. The fix was not adding defensive conditionals in the UI. It was introducing a shared domain contract and making both sides depend on it. Instead of allowing the frontend and backend to “just agree,” the system defines explicit types for: ChatMessage ChatRequest ChatReply ChatResponse These types live in a shared module that both the frontend and backend import. The frontend state becomes ChatMessage[]. The API call returns Promise<ChatResponse>. The backend handler constructs a value that must satisfy ChatResponse. At that point, the contract stops being an assumption and becomes code. If someone changes the shape of reply again, the compiler will force every dependent piece of code to reconcile with that change. The mismatch that previously appeared in the browser now appears during build. In practical terms, this shifts the feedback loop. Instead of discovering drift during manual testing or after deployment, the team discovers it the moment they try to compile. That difference seems small, but over time it fundamentally changes how safely a system can evolve. Phase Two: Making the Network Boundary Honest Introducing shared types stabilizes collaboration between frontend and backend. It does not solve everything. There is still one place where untyped data enters the system: the network boundary. On the backend, req.body arrives as raw JSON. On the frontend, res.json() returns data that TypeScript cannot inspect at runtime. Even with shared contracts, the system is still trusting external input. In the chatbot’s case, this matters more as the system grows. Deployments may not always be perfectly synchronized. A proxy or middleware layer might alter payloads. A partial rollout could temporarily mix versions of frontend and backend. Shared types alone cannot guard against that. The practical adjustment is simple but important: treat boundary data as unknown until it is validated. Instead of assuming that req.body matches ChatRequest, the backend checks that it actually does. Instead of assuming that res.json() returns a valid ChatResponse, the frontend verifies the shape before proceeding. These checks do not need to be elaborate. Lightweight type guards are enough to confirm that required properties exist and have the correct types. Once the data passes that validation step, the rest of the system can rely on strong typing with confidence. This introduces a clear separation of responsibilities: Outside the boundary, data is untrusted. Inside the boundary, data is guaranteed to match the domain contract. In day to day development, this prevents subtle corruption. Rather than allowing malformed data to move deeper into the UI or business logic, the system fails immediately at the edge. Errors become explicit and local instead of diffused and harder to trace. The chatbot remains small, but its architecture becomes more deliberate. The boundary is no longer a blind spot; it becomes a controlled entry point. Phase Three: Containing Vendor Volatility As the chatbot matures, another requirement arrives: support more than one LLM provider. This is a common inflection point. Early on, it is convenient to wire the backend directly to a single SDK. The response from the provider flows straight through the server and into the UI. It feels efficient. It also quietly couples your entire stack to a vendor’s response shape. If that vendor changes its format, or if you decide to introduce a second provider, the ripple effects can reach the frontend quickly. What began as a backend integration detail becomes a full-stack coordination problem. In the chatbot’s evolution, this risk is handled differently. Instead of exposing raw provider responses, the system defines a provider interface that returns a domain-level ChatReply. Each provider implementation adapts its own SDK response into that shared shape. The rest of the application does not know or care which provider generated the reply. It only understands the domain contract. This decision seems architectural, but it has very practical consequences. Switching providers or introducing a second one no longer forces a redesign of shared types. The volatility is contained. The surface area of change is smaller. TypeScript reinforces this separation. The compiler ensures that every provider implementation produces a valid ChatReply. The backend handler depends on the interface, not on vendor-specific JSON. In a growing system, this is what stability looks like. The parts that are likely to change are isolated behind clear contracts. The parts that need to remain steady, especially the frontend, are shielded from that churn. Phase Four: Making States Explicit as Features Expand Feature growth rarely stops at integration. The chatbot evolves again. Sometimes a response includes citations. Sometimes it does not. A quick solution would be to add optional fields. Over time, optional fields accumulate. The type becomes flexible, but also ambiguous. It becomes unclear which combinations are valid and which are accidental. Instead, the chatbot models these variations explicitly using a discriminated union. A response is either a plain answer or an answer with citations, and the kind field identifies which one it is. On the frontend, rendering logic switches on that kind. The exhaustive check ensures that every variant is handled. This design choice has a subtle but important effect. When a new response variant is introduced later, the compiler highlights every place that must adapt. Nothing slips through unnoticed. In everyday development, this reduces the risk of partial updates. The type system becomes a guide for refactoring, not just a static annotation layer. The chatbot still feels small. The difference is that its possible states are no longer implied. They are declared. Phase Five: Removing Quiet Type Erosion As the chatbot grows, new endpoints appear. Health checks. Admin actions. Maybe analytics or feedback capture. The API surface expands gradually. This is usually where small shortcuts start accumulating. A common one looks harmless: const data = (await res.json()) as ChatResponse; The cast makes the compiler quiet. It also shifts responsibility back to the developer. At the exact point where the system is most exposed to incorrect data, you are asserting that everything is fine. In a small codebase, this feels manageable. In a growing one, these assertions multiply. Over time, they erode the safety you thought TypeScript was providing. In the chatbot’s evolution, this problem is addressed structurally rather than procedurally. Instead of scattering casts, the system defines a mapping between route literals and their request and response types. The endpoint determines the shape. The generic client enforces it. Now the type of /api/chat is tied directly to ChatRequest and ChatResponse. You cannot accidentally call the wrong endpoint and pretend it returns something else. The compiler resolves the relationship based on the route itself. This removes a category of silent drift. It also makes the API surface self-documenting. When someone adds a new endpoint, they define its contract in one place, and the rest of the system aligns automatically. It is a small shift in structure, but it prevents gradual type erosion. What This Evolution Actually Achieved The chatbot still answers questions. The UI still renders messages. The architecture is not radically different from the initial proof of concept. What changed is where mistakes surface. At first, mismatches appeared in the browser. After shared contracts, they appeared during compilation. After boundary validation, they appeared at the edge of the system. After isolating providers, vendor changes stopped leaking across layers. After modeling variants explicitly, feature growth became safer. After tightening endpoint typing, unsafe assumptions stopped spreading quietly. None of these changes required advanced language features. They required clarity about boundaries and discipline about contracts. In a system that evolves under real-world pressure, assumptions are the most fragile dependency. TypeScript is most valuable when it turns those assumptions into enforceable structure. The chatbot did not become more sophisticated for its own sake. It became more predictable under change. For a deeper exploration, pre-order Clean Code with TypeScript. The book takes a detailed look at the evolving chatbot system and walks through the architectural decisions, trade-offs, and production considerations behind it. If you’re a PacktPub subscriber, you can access the Early Access version right away. This Week in the News ☁️ Cloudflare rebuilds Next.js on Vite: Cloudflare unveiled vinext, an experimental reimplementation of the Next.js API surface built on Vite, reportedly put together in a week using AI coding agents and the official Next.js test suite as a spec. Instead of adapting Next’s build output for non-Vercel platforms, Cloudflare rebuilt the framework layer itself to make deployment on its infrastructure more natural. vinext already supports routing, SSR, React Server Components, server actions, middleware, and both routing systems, passing about 94 percent of the Next 16 test suite. Cloudflare claims faster builds and smaller client bundles in early benchmarks, while calling the results directional. It is still early, but this is a bold signal in the ongoing platform versus framework conversation. 🅰️ Angular Skills for coding agents: Angular developers can now equip their coding agents with “Angular Skills,” a set of curated defaults and patterns designed to guide agents toward modern Angular best practices. The project packages conventions, structure, and tooling preferences so AI-assisted workflows generate code that feels aligned with today’s Angular ecosystem. Do agent skills materially improve output quality? That remains to be seen. At the very least, they formalize standards and make human intent more explicit, which may be half the battle in AI-assisted development. 🟢Node.js 24.14.0 LTS and 25.7.0 Current released: Node shipped both an LTS and a Current release this week, and this one is more than routine version churn. The LTS update tightens up async_hooks, improves fs.watch reliability, adds proxy configuration support, and begins exposing early ESM embedder API enhancements. If you’re running backend services, SSR stacks, or dev tooling that leans on Node internals, these changes are practical, not cosmetic. Meanwhile, 25.7.0 Current gives a preview of where the runtime is heading. Framework maintainers and teams with native modules should treat this as a signal to test early and avoid CI surprises later. 📈 OpenClaw briefly overtakes Python projects on GitHub: A retro game reimplementation project saw a spike in GitHub activity that temporarily outranked major Python repositories. While largely a trend metric, this serves as a reminder that GitHub stars and ranking spikes do not always reflect lasting ecosystem impact. For developers, this is a useful gut check. Popularity metrics can highlight energy, but they don’t always indicate production relevance or long-term impact. 🤖 Claude Code turns one as distillation dispute surfaces:Anthropic marked the first anniversary of Claude Code while raising concerns about competitors using Claude outputs to train rival models through large-scale distillation. The discussion moves beyond company rivalry and into deeper questions around model output ownership, competitive boundaries, and how AI tooling companies protect their work. For developers building AI-powered products, this matters. The ecosystem is still defining what is acceptable reuse, what is extraction, and where legal lines will be drawn. Tooling decisions today are increasingly shaped by these policy and governance shifts 🏛️ React moves to the Linux Foundation:React and React Native are now governed by a newly formed React Foundation under the Linux Foundation. This shifts stewardship from a single corporate sponsor to neutral, open governance. For teams betting their front end architecture on React, this reduces long-term platform risk. Governance stability may not feel urgent in daily development, but it quietly shapes the future of roadmaps, community trust, and ecosystem continuity. Beyond the Headlines 🦀 Ladybird adopts Rust for new components: The Ladybird browser project is moving new development to Rust, citing safety and maintainability. This isn’t just about language preference. It reflects the industry’s steady migration toward memory-safe systems programming in infrastructure-level code. The browser space has historically been C and C++. Rust’s continued expansion here signals that safety is becoming a baseline expectation, not a luxury. 🤖 The five stages of AI agents: A useful framework is emerging around how AI agents evolve: from basic task automation to more autonomous, goal-oriented systems. For developers experimenting with AI workflows, this gives structure to what can otherwise feel like hype. The takeaway is simple. Not every workflow needs autonomy. Understanding where your system sits on that spectrum prevents overengineering and keeps expectations grounded. 🧠 Mitchell Hashimoto on AI adoption: Mitchell Hashimoto, the co-founder of HashiCorp shared a candid look at integrating AI tools into his workflow. Not evangelism. Not backlash. Just a practical breakdown of where AI speeds things up and where it still falls short. That grounded middle space is where most developers are operating right now. AI is useful. It is not magic. And thoughtful integration beats blanket adoption. Refactoring production systems is risky, especially when API changes and hidden coupling are involved. In this Deep Engineering session, learn how to safely evolve real-world codebases using ast-grep and Claude Code, with practical guardrails you can apply immediately. Use code WDP40 to get 40% off your seat. Tool of the Week 🛡️ Zod Makes Runtime Validation Feel Native to TypeScript If you’ve ever trusted req.body a little too much or written as SomeType just to quiet the compiler, you already know the pain: TypeScript disappears at runtime. The type system keeps you safe inside your codebase, but JSON at the network boundary remains unchecked. Zod solves that gap cleanly. It’s a TypeScript-first schema validation library that lets you define runtime validation and static types in one place. You describe the shape once, validate incoming data against it, and automatically infer the TypeScript type. No duplication. No drift between interface and validator. The real value shows up under change. When your API evolves or a provider shifts its response format, Zod forces the mismatch to surface immediately at the boundary instead of leaking deeper into your system. It turns assumptions into enforced contracts. Good architecture is often about making edges explicit. Zod gives those edges structure. 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;} }

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 #127 Design Patterns as Decision Frameworks, Not Recipes Crafting the Web: Tips, Tools, and Trends for Developers Unblocked: The context layer your AI tools are missing Give your agents the understanding they need to generate reliable code, reviews, and answers. Unblocked builds context from your team’s code, PR history, conversations, documentation, planning tools, and runtime signals. It surfaces the insights that matter so AI outputs reflect how your system actually works. See how it works Welcome to this week’s issue of WebDevPro. If you’ve been building and maintaining systems for a while, you’ve probably felt the friction that doesn’t show up in code reviews. And here’s something that doesn’t get said often enough: most engineering pain isn’t caused by bad code. It’s caused by unexamined decisions. Nobody deliberately optimizes for rigidity. Nobody sets out to make performance worse or future changes harder. But when trade-offs aren’t made explicit, that’s exactly where teams end up. You notice it when: A small requirement change forces a wide refactor A performance issue appears under load and the root cause isn’t obvious “Best practice” debates stall because everyone is arguing from instinct, not intent We’re often handed rules like these: Use strict equality Avoid blocking I/O Prefer Map over Object Use Set for deduplication Be careful with parseInt These guidelines are useful, especially early on. They prevent common mistakes. But over time, following rules without understanding the trade-offs turns into habit, not judgment. This week’s issue looks at patterns differently. Not as templates to apply or badges of clean code, but as decision frameworks. By the end of this article, you’ll start seeing what a piece of code is really optimizing for, notice the hidden costs behind everyday implementation choices, think more deliberately about where change should happen, and reframe conversations from “Is this correct?” to “What are we trading off?” That shift from applying rules to making deliberate trade-offs is where engineering starts to feel intentional. And that’s what we’re unpacking today. Code Shape and the Cost of Change Most problematic code works. That’s why it survives. createUser(name, email, password, phoneNumber, role = 'guest') There’s nothing obviously wrong here. Until the domain changes. Add a required field. Deprecate one parameter. Split roles into multiple variants. Now you’re updating dozens of call sites and hoping argument order wasn’t misused somewhere. Switching to object parameters: createUser({ name, email, password, phoneNumber, role = 'guest' }) This changes what the API optimizes for. Specifically, order stops mattering, adding fields becomes safer, and call sites become self-documenting. This is design thinking at the function level. You’re choosing a shape that absorbs change instead of amplifying it. Hidden Transformations and Predictability Loose equality in JavaScript produces results that surprise people: false == 0 // true '' == false // true [] == false // true These aren’t bugs; they follow the language’s coercion rules. The issue is that the conversion happens implicitly. When a comparison behaves unexpectedly, it looks like a logic error, not a type conversion chain. Using === keeps comparisons explicit. It removes hidden work. Parsing has similar edges. parseInt(0.0000005) // 5 parseInt converts its input to a string, then parses from the start until it hits an invalid character. A number like 0.0000005 may be represented as "5e-7", so parsing stops at "e". This is documented behavior. The problem isn’t the function. It’s assuming there are no intermediate transformations. The broader lesson: implicit conversions reduce clarity. When behavior depends on hidden steps, bugs become harder to reason about. Runtime Reality: Blocking Work and Delegation Node.js executes JavaScript on a single main thread that drives the event loop. CPU-heavy synchronous code blocks that thread. While it runs, nothing else progresses. That’s why synchronous work in request handlers can reduce throughput and increase latency under load. Asynchronous APIs often help because some operations can be delegated to the system or to worker threads (for example, many crypto operations have asynchronous variants). The main thread remains free to coordinate. But async alone doesn’t solve architectural problems. Performance often improves more by reducing how often expensive work runs than by simply changing it to async. Caching, batching, and eliminating redundant computation frequently have a bigger impact than switching APIs. The real pattern isn’t “async good, sync bad.” It’s understanding where your runtime is serial and designing accordingly. Data Structures as Cost Models Choosing between Object, Map, Array, and Set is about workload and not preference. Objects fit well when: keys are known and stable you’re modeling record-like data JSON serialization matters Maps fit well when: keys are dynamic frequent insertions and deletions occur iteration order must be preserved non-string keys are required Arrays excel at ordered data and transformations. Sets excel at uniqueness and fast membership checks. No structure is universally better. Each implies a different cost model. When you align structure with usage patterns, the code becomes simpler and more predictable. Classic Patterns: Controlling Where Change Happens Design patterns get introduced as diagrams. Boxes, arrows, interfaces. In practice, nobody reaches for Strategy because they love abstractions. They reach for it because some piece of logic keeps changing and it’s starting to infect everything around it. Pricing rules change. Validation rules change. Feature flags change. If that logic is scattered across the system, every update becomes a small cleanup project. Strategy just gives that volatility a place to live. Observer shows up when components are getting too aware of each other. One module updates something and suddenly three others need to react. Hard-coded calls turn into a web of dependencies. Events or observers aren’t about elegance. They’re about reducing how much each part needs to know. Adapter is what you write when an external API doesn’t quite fit your model, and you don’t want your entire codebase shaped by someone else’s decisions. It’s a boundary. A buffer. None of these patterns are impressive on their own. What they’re really doing is controlling where change hurts. They add indirection, yes. That indirection costs something. But in return, you stop paying interest every time requirements shift. That’s the trade. Containment Over Cleverness There’s always a moment when modifying a prototype feels like a clever shortcut. You add a helper to Array.prototype so you don’t have to import a utility everywhere. You tweak Object.prototype to normalize something globally. It works. It even feels elegant. The catch is that you’ve quietly changed the rules for the entire runtime. Now every array in the system has that extra method. Every object inherits the behavior whether it asked for it or not. If something breaks, the failure won’t point back to your “nice little improvement.” It’ll surface somewhere unrelated, and debugging it will take longer than the shortcut saved. In small scripts, this might be fine. In shared codebases, libraries, or long-lived services, it’s a different story. The blast radius is bigger than it looks. Most engineers grow out of this not because someone tells them it’s wrong, but because they’ve spent a day tracing a bug back to a global modification they forgot existed. After that, containment starts to feel a lot more attractive than cleverness. Final words: Making Trade-offs Explicit The deepest anti-pattern isn’t picking the “wrong” API but rather building for neatness today in places that are guaranteed to change later. That’s why patterns matter. Not because they’re clever, but because they force the trade-offs into the open: CPU vs latency memory vs speed coupling vs flexibility simplicity now vs adaptability later Used like recipes, patterns turn rigid fast. Used like decision frameworks, they do something much more valuable: they make teams talk about consequences instead of preferences. You spend less time arguing about “best practices,” and more time agreeing on what kind of system you’re actually building. That’s the shift from following rules to developing engineering judgment. This Week in the News 🧩TypeScript 6.0 Beta Is Here and 7.0 Will Change More Than You Think: TypeScript 6.0 is now in beta and while it looks like a transitional release, it lays the groundwork for the Go-based TypeScript 7. Some changes may subtly affect existing projects, especially around deprecated behaviors and internal shifts. This is the release to test against early so you are not caught off guard when 7.0 lands with deeper architectural changes. 🌐 WebMCP and EPP Show Where Chrome Wants the Web to Go Next: With WebMCP and EPP, Chrome is exploring structured communication between web apps and external processes. This could reshape how developer tools, AI agents, and browser-based apps coordinate capabilities. If you care about automation-heavy workflows or AI-assisted development, this signals where the platform is heading. 🔗 npm Just Made Supply Chain Security Harder to Ignore: npm 11.10.0 rolls out bulk trusted publishing configuration and stronger lifecycle script protections. Teams managing multiple packages can now streamline trusted publishing, while script security improvements reduce risk from malicious or unexpected install-time behavior. Worth reading if you maintain libraries or ship production packages regularly. 🛠️ Interop 2026 Aims to Remove More Cross Browser Headaches: Interop is a yearly cross-browser effort where engine teams align on specific platform features and work together to close gaps in behavior and support. Interop 2026 is now announced, continuing the collaboration between WebKit, Chromium, and Gecko with a fresh set of focus areas. For developers, it is one of the most reliable signals of which web platform fixes are actually likely to land across all major browsers. Beyond the Headlines ⚡Node vs Deno vs Bun Benchmarks Show Where the Real Gaps Are: Fresh performance benchmarks compare Node.js, Deno, and Bun across real-world scenarios rather than synthetic micro tests. The results challenge a few common assumptions about which runtime is “fastest” and where that speed actually matters. Worth reading before you make runtime decisions based purely on hype or benchmark screenshots. 🧠 Performance Is Not a Technical Problem: This essay argues that most performance issues stem from priorities, incentives, and product decisions rather than raw engineering limits. It reframes optimization as a cultural and organizational question, not just a profiling exercise. A sharp perspective shift for anyone working on growing codebases where “we’ll fix it later” keeps winning. ♟️What Deep Blue Still Teaches Us About AI Hype: Simon Willison revisits IBM’s Deep Blue moment and connects it to today’s AI narratives. The piece explores how milestone victories shape public perception, funding, and expectations long after the headlines fade. A thoughtful read for developers navigating the current AI wave and trying to separate signal from spectacle. 🧵 HTTP in Node.js Gets Tricky Fast and This Guide Explains Why: Making an HTTP request in Node.js looks simple until you hit retries, timeouts, streaming, backpressure, and error handling in real production code. This deep dive breaks down the patterns that help you move beyond quick fixes and build request logic that stays reliable under load. It’s also a great preview of the thinking behind Node.js Design Patterns, one of the most practical books for developers building serious Node.js systems. Tool of the Week 🧮 Excelize Makes Spreadsheet Automation in Go Feel Like a Superpower If you’ve ever had to generate Excel reports, clean up spreadsheets, or build export pipelines, you already know the pain: most tooling is either fragile or wildly overcomplicated. Excelize, built by Ri Xuis an open-source Go library that makes working with real .xlsx files feel straightforward, from formatting and formulas to charts and large-file handling. The most interesting part is the story behind it. The write-up on how Excelize was builtshows what it takes to make “boring” infrastructure reliable: handling OpenXML edge cases, keeping the API Go-friendly, and evolving features without breaking existing users. It’s a strong example of how long-term OSS gets built, one painful spreadsheet at a time. Good developer tooling rarely starts as “let’s build a library.” It starts as “this keeps hurting, let’s fix it properly.” Excelize is the result of sticking with that fix long enough to turn it into real infrastructure. 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 Brought to you in cooperation with Unblocked: 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;} }

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 #126 Using AI in Development Without Losing Architectural Control Crafting the Web: Tips, Tools, and Trends for Developers Webinar: How to Build Faster with AI Agents Learn how full‑stack developers boost productivity by 50% with AI agents that automate layout, styling, and component generation through RAG and LLM pipelines. See how orchestration and spec‑driven workflows keep you in control of quality and consistency. Save your seat! Welcome to this week’s issue of WebDevPro. If you’ve written any meaningful amount of code recently, AI is already part of your workflow. It finishes your lines, scaffolds components, suggests refactors, and removes a lot of the friction from day-to-day implementation. At the same time, more teams are shipping AI-powered capabilities directly into their products. The productivity gains are real. Development moves faster. Experimentation becomes easier. But speed introduces a structural question that doesn’t get talked about enough. When implementation becomes this easy, AI can start shaping architecture by default. Not through dramatic failures, but through small decisions that slip in unnoticed. A suggestion becomes a pattern. A pattern becomes the norm. Over time, structure starts drifting, responsibilities blur, and the codebase becomes harder to reason about. This piece looks at how to prevent that. We’ll look at practical ways to keep architectural control while still using AI heavily: how to set guardrails before generating code, where AI logic should live once it becomes part of your product, and what to review so “correct” output doesn’t slowly weaken your design. AI should accelerate implementation, not quietly define structure or responsibility. When Implementation Speed Becomes the Default When AI integrates into the development environment, the nature of coding changes. Developers move from writing every line manually to reviewing and selecting generated suggestions. That shift is efficient, but it also changes what drives consistency in a codebase. Suggestions are generated from generalized patterns. They can be correct, but correctness is not the same as architectural alignment. A project’s structure depends on decisions that hold across features, not on what looks plausible inside a single file. Encode Guardrails Before You Generate One practical way to preserve architectural control is to define expectations before generation. In practice, this means writing down the constraints that matter in your codebase so the assistant consistently reinforces them. For example, a strong instruction set begins by defining the development role clearly: You are an expert in TypeScript, Angular, and scalable web application development. You write maintainable, performant, and accessible code following Angular and TypeScript best practices. From there, it becomes easier to add concrete constraints that prevent structural drift. Even a small rule can make a difference, such as discouraging weak typing: Avoid the any type; use unknown when type is uncertain This kind of guidance does not guarantee perfect output. It does something more important: it keeps the assistant working within a defined standard instead of inventing one through suggestion. When AI Becomes Part of the Application The architectural stakes rise when AI is not only assisting development but also powering feature behavior. At that point, the questions are no longer about scaffolding. They become questions of placement, responsibility, and cohesion. One useful pattern is to configure AI behavior deliberately through a system instruction and then route all interaction through a structured interface. Example model configuration and system instruction: const instructions = ` Welcome to citypass. You are a superstar agent for this car parking validator. You will assist users by submitting parking tickets. You can convert date phrases to ISO strings and act as a geocode service to convert a location or address to coordinates long/lat. `; const ai = getAI(firebaseApp); const model = getGenerativeModel(ai, { model: 'gemini-2.5-flash', systemInstruction: instructions, tools: [toolset] }); this.chat = model.startChat(); This approach makes two architectural decisions explicit. First, AI behavior is constrained by a clear instruction. Second, interaction happens through a controlled interface instead of being scattered across unrelated parts of the application. A Practical Boundary: UI for Input, Services for Processing When AI is exposed to users, architectural control often comes down to a simple boundary. The UI collects input and shows results. The AI processing stays encapsulated behind an interface that can be tested and evolved. A clean example is offering an “AI Creator” entry point near an existing workflow, opening a modal to capture a prompt: Ticket creation flow with an AI Creator entry point used to capture user input for AI-assisted ticket creation. AI Creator button and modal markup: <button nz-button nzType="link" type="button" (click)="isVisible.set(true)" >AI Creator </button> <nz-modal [(nzVisible)]="isVisible" nzTitle="AI Creator" (nzOnCancel)="isVisible.set(false)" (nzOnOk)="ok()"> <ng-container *nzModalContent> <textarea [(ngModel)]="prompt" rows="3" placeholder="Enter ticket details" nz-input> </textarea> </ng-container> </nz-modal> This interface design matters because responsibility stays clear. The component manages interaction and user input. The AI-driven work happens only when the user explicitly triggers it, and the application can decide where that processing belongs. The Drift Risk: Structure by Convenience AI rarely causes dramatic architectural failures. The more common risk is incremental drift. A generated approach is accepted, then repeated, and then becomes the default. Over time, similar features are built with slightly different patterns, responsibilities move across layers, and ownership becomes less obvious. This is why the guiding principle needs to be visible early in the workflow: AI should accelerate implementation, not make architectural decisions. Maintaining Architectural Control Architectural control in an AI-assisted workflow comes from a small set of repeatable practices: Define expectations before generation so the assistant reinforces standards Encapsulate AI-enabled behavior behind clear interfaces Review generated code for placement and responsibility, not only for correctness These practices keep speed from rewriting structure. Final words AI can absolutely increase velocity. It can also unlock product capabilities that would have been expensive or slow to build even a year ago. But long-term maintainability still comes down to structure. The difference is that AI changes how structure gets created. It can reinforce good decisions, or it can quietly introduce new patterns through convenience, repetition, and speed. That’s why boundaries matter. When they’re clear, AI becomes a multiplier for discipline. When they’re loose, drift becomes the default. AI should accelerate implementation, not quietly define structure or responsibility. Architectural control isn’t about resisting AI. It’s about staying deliberate while moving fast. Want to learn more? Get your copy of Angular Projects, 4th Edition now! This Week in the News 🧩TypeScript 6.0 beta and roadmap shift: TypeScript 6.0 beta introduces incremental improvements across type checking and configuration while laying groundwork for the long-discussed native rewrite in Go that promises serious performance gains. The team is clearly thinking beyond syntax tweaks and focusing on compiler architecture, which signals that large codebases and build speed are now central to the TypeScript story. For teams pushing monorepos or heavy CI pipelines, this roadmap matters more than any single feature flag. 📊 State of JavaScript 2025 survey results: The State of JavaScript 2025 survey provides a broad snapshot of how developers are working across the JS ecosystem. TypeScript continues to see strong adoption, reinforcing its position as a standard part of modern JavaScript development. In tooling, newer build systems and faster runtimes are gaining momentum, reflecting a clear preference for performance-focused developer experience. The survey also compares usage, satisfaction, and interest across frameworks, testing tools, browser APIs, and runtimes, highlighting which technologies feel stable and which are generating curiosity. Overall, the results show an ecosystem that is maturing around modern defaults while steadily evolving toward faster tooling and more streamlined workflows. ⚛️ State of React 2025: The State of React 2025 survey offers a data-backed look at how developers are building with React today. Core tooling remains strong: Next.js, React Router, and Redux continue to see widespread usage, while TanStack Query and Axios are common choices for data handling. On the build side, Vite has emerged as the dominant tool, reflecting the ecosystem’s shift toward faster development workflows. UI libraries like MUI and shadcn/ui show meaningful adoption, and modern state solutions such as Redux Toolkit are preferred when external state is needed. The results also highlight a practical trend: many teams still rely primarily on built-in React APIs for state management, reaching for external libraries only as complexity grows. Beyond the Headlines ⚡Running Next.js at Enterprise Scale:Next.js scales well, but enterprise usage needs more than default settings. This piece breaks down what changes when you’re running Next.js under real traffic: defining clear SLOs/SLAs, instrumenting performance monitoring, and understanding the framework’s request lifecycle so you can spot bottlenecks early. It also highlights practical architecture choices like using CDNs and caching effectively, picking the right rendering strategy (SSG vs SSR) per route, and planning for horizontal scaling with shared caches and load balancing. 🐢 Is Claude Code losing its engineering edge:This post critiques recent shifts in Claude Code’s behavior, arguing that guardrails and simplifications are reducing its usefulness for experienced developers who value precision and depth. It reflects a broader tension in AI tooling between safety, accessibility, and raw capability. For developers relying on AI as a serious engineering assistant, subtle model behavior changes can have an outsized impact on trust and workflow. 🧭 Debugging workflows that actually benefit from AI: An exploration of AI-assisted debugging workflows that break down how you can leverage models to trace issues, interpret stack traces, and accelerate root-cause analysis without feeling like you’re guessing at prompts. ⚛️ React Server Components performance insights: This piece examines how React Server Components behave in real world performance scenarios, moving past high level explanations to measure tradeoffs in rendering, hydration, and network boundaries. It challenges simplistic assumptions about automatic speed gains and highlights where architectural decisions still matter. For teams evaluating RSC adoption, the nuance here is critical before refactoring large parts of an app around the paradigm. Tool of the Week 🌀🛠️ OpenClaw — The AI Agent That Does Work for You OpenClaw is an open-source autonomous AI agent that goes beyond chat: it can execute real tasks like managing email, calendars, messaging apps, and other workflows by integrating with platforms such as WhatsApp, Telegram, and Slack. Developed by Austrian engineer Peter Steinberger, it grew from an experimental project into one of the fastest-adopted agent tools in the community because of its ability to act instead of just respond. Since its introduction in November, OpenClaw has seen a viral rise, surpassing 100,000 stars on GitHub and attracting 2 million visitors in a single week, signaling strong developer curiosity around agent-based systems. This week, OpenClaw made headlines when creator Peter Steinberger announced he’s joining OpenAI. Sam Altman highlighted Steinberger’s expertise in multi-agent systems as strategically important for building the next generation of personal AI assistants, and OpenClaw will continue as an open-source foundation supported by OpenAI. This move signals how quickly agent-centric tooling is becoming a central focus for major AI platforms. For anyone interested in trying OpenClaw yourself or seeing it in action, this tutorial walks through setup and use:📺 OpenClaw Full Tutorial for Beginners. 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;} }

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 #125 Where AI actually saves time in modern development workflows Crafting the Web: Tips, Tools, and Trends for Developers Hi , Welcome to this week’s issue of WebDevPro! Aditya Agarwal, Facebook’s 10th employee and former CTO of Dropbox, sparked a wider conversation in the developer community this week after sharing a personal reflection about coding with Claude, Anthropic’s AI assistant. After a weekend building with Claude, he wrote: “It was very clear that we will never ever write code by hand again.” Then he admitted something more surprising: He felt happy, but also disoriented. Now that isn’t a prediction for “someday.” It’s a workflow shift happening right now. The real challenge for most teams isn’t access to AI. It’s integration. How do you apply AI to scaffolding, debugging, refactoring, UI generation, and delivery pipelines without disrupting your stack or compromising quality? That’s why this upcoming Progress workshop stood out to us. It’s designed to help developers integrate AI into real workflows, without losing control over quality, security, or governance. Webinar: AI for Developers – How to Achieve a 50% Productivity Boost If interested, sign up here This session breaks down technical workflows, architectural considerations, and hands-on demos showing how AI can augment development tasks, without requiring framework changes or replatforming. We’ll cover topics you care about: AI‑Assisted Component Scaffolding How AI can generate baseline UI components, form logic, data-binding structures, and reduce initial setup time. Debugging & Refactoring Using AI Agents Techniques for leveraging AI to identify bottlenecks, suggest optimized patterns, and modernize legacy code. AI‑Enhanced UI Development with Kendo UI & Telerik Practical examples of generating boilerplate, bindings, CRUD screens, tests, and documentation directly from your existing tech stack. Integrating AI into Dev Workflows Where AI fits into CI/CD, code reviews, architectural planning, prototyping, and cross-team collaboration. How Teams Achieve Measurable Gains (up to 50%) Real scenarios showing reduced time spent on repetitive implementation tasks, improved code consistency, and faster iteration cycles. Security & Practical Limitations What to automate, what not to automate, and how to ensure AI‑generated code aligns with team standards. Who should attend: Senior devs building complex front‑end or full‑stack applications Dev leads and architects driving technical decision‑making Teams exploring AI adoption without changing their existing stack Register & Save Your Seat! 👉 Join the webinar and see how AI can be embedded into real engineering workflows. 📅 February 26, 2026 ⏰ 9:30 PM GMT+5:30 Secure your spot! 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;} }

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 #124 Why Modern JavaScript Feels Fragmented, Plus This Week’s Updates Crafting the Web: Tips, Tools, and Trends for Developers Webinar: How to Build Faster with AI Agents Learn how full‑stack developers boost productivity by 50% with AI agents that automate layout, styling, and component generation through RAG and LLM pipelines. See how orchestration and spec‑driven workflows keep you in control of quality and consistency. Save your seat! Welcome to this week’s issue of WebDevPro! Before we get into the updates and tools, let’s start with a familiar moment. Imagine this. You’re deep in a JavaScript codebase, following a clean map and filter chain, when you suddenly land in a class full of mutable state and lifecycle methods. Same language, different mental model. That shift is easy to miss, but over time, it adds real cognitive overhead. Modern JavaScript often feels more complicated than it needs to be, even when the syntax itself is familiar. JavaScript doesn’t neatly transition from one programming style to another as projects grow. Instead, it accumulates them. You might begin with step-by-step procedural code, adopt functional patterns along the way, and later introduce object-based structures to manage scale. In practice, most real-world codebases blend all three. In this issue, we'll start with a deep dive into JavaScript, looking at how that layering came to be, why it can make code harder to reason about, and how to approach those tradeoffs with more intention. Then we will move on to the key updates from the past week, and wrap up with a tool worth adding to your workflow. Procedural thinking as the foundation For many developers, procedural logic is the starting point. Programs are expressed as a sequence of steps executed in a clear and predictable order. Control flow is explicit, and it is easy to follow how data moves through the program. Loops and conditional statements play a central role in this style. They make execution order visible and help explain how decisions affect program behavior. for (let i = 0; i < items.length; i++) { if (items[i].active) { handle(items[i]) } } This approach emphasizes execution order and state changes. It works well when programs are small and logic is linear. Importantly, this style never disappears. Even as programs grow, procedural code remains a valid and familiar tool. Introducing functional patterns As programs become more complex, functional patterns begin to appear more frequently. Array methods and callbacks provide a more concise way to work with collections and reduce repetitive looping logic. Instead of describing how a loop executes, this style focuses on what transformation is applied to the data. items .filter(item => item.active) .forEach(handle) Here, intent is clearer, but control flow is less explicit. Readers must understand how each method behaves and how functions are applied. For some, this improves readability. For others, it introduces a new layer of abstraction that requires adjustment. Crucially, this style does not replace procedural logic. Both approaches coexist, and developers are expected to move between them as needed. Shifting toward composition As functional ideas are reinforced, composition becomes more prominent. Functions are treated as reusable building blocks that can be passed around and combined. This encourages thinking in terms of data flow rather than execution steps. Logic is expressed by chaining operations together, which can make intent clearer while obscuring the underlying sequence of events. At this stage, developers are often working with at least two distinct paradigms simultaneously: procedural control flow and functional composition. Object-based organization for larger programs As programs grow further, object-based organization emerges as a way to manage complexity. Classes and objects group related data and behavior, providing a structural model for larger systems. class ItemHandler { handle(item) { if (item.active) { // ... } } } This approach shifts the focus again. Instead of steps or transformations, code is organized around responsibilities and roles. Object-based organization can improve clarity in large programs, but it introduces a third way of thinking. Procedural, functional, and object-oriented styles now coexist within the same language and often within the same codebase. Accumulation instead of replacement A defining characteristic of JavaScript is that new paradigms are added without removing older ones. Procedural logic remains valid even as functional patterns appear. Functional composition continues to be useful when object-based structures are introduced. Nothing is deprecated at the architectural level. Every style remains available, and developers are free to choose the approach that fits the problem at hand. This cumulative nature explains why JavaScript codebases often contain a mixture of paradigms. The language supports each style equally and does not enforce a single architectural direction. Understanding the resulting tension As paradigms accumulate, readers and developers must constantly adjust how they interpret code. Different sections of a program may require different mental models depending on the style being used. This flexibility is powerful, but it increases cognitive load. Understanding a program requires not only knowledge of syntax, but also awareness of which paradigm is currently in play. Maintaining consistency becomes more challenging as programs grow. The same language constructs can support multiple architectural interpretations depending on context. Final words JavaScript is not broken. It is intentionally flexible. The challenge is not choosing the right paradigm, but navigating multiple paradigms at once. When procedural logic, functional composition, and object-based organization coexist, developers must be deliberate about how and when each style is used. Understanding how these paradigms accumulate rather than replace one another helps explain why modern JavaScript can feel complex even when the individual concepts are familiar. Want to go deeper? JavaScript from Beginner to Professional is a solid pick for developers transitioning into JavaScript. It uses more than 100 practical exercises and projects to develop real, working JavaScript skills. This Week in the News ⚙️ Node.js v25.5.0 Is Out:Node.js has shipped v25.5.0, continuing the steady pace of updates ahead of the next LTS release. This one focuses on runtime fixes and smaller improvements rather than headline features. If you like keeping an eye on where Node is heading next, this release is worth skimming through. 🧱 The Boring JavaScript Stack Reaches v1.0: The Boring JavaScript Stack has officially hit v1.0, and the name is very much intentional. It is an opinionated full-stack starter built with Sails, Inertia, Tailwind CSS, plus your choice of Vue, React, or Svelte. The goal here is fewer decisions, less setup churn, and getting to actual product code faster. 🧠 A Conversation with Anders Hejlsberg: Last week’s interview with Anders Hejlsberg offers a thoughtful look into the mindset of one of the most influential language designers behind C# and TypeScript. The discussion touches on language evolution, long-term trade-offs, and what it takes to design tools that scale with both developers and ecosystems. For an overview of the conversation, Aaron Winston summarizes Hejlsberg's lessons from C# and TypeScript on fast feedback loops, scaling software, open source visibility, and building tools that last. Beyond the Headlines 🐢 Fixing TypeScript Performance Problems:If your TypeScript project has started to feel slow, this article will feel very familiar. It walks through common causes of sluggish builds and editor lag in larger TS codebases. There are practical fixes here that teams can apply without rewriting everything from scratch. 🧭 JavaScript Frameworks Heading Into 2026: This is a community-driven look at how JavaScript frameworks are shaping up as we move toward 2026. It talks less about hype cycles and more about adoption, trade-offs, and long-term sustainability. A good read if you are thinking about whether to stick, switch, or wait with your current stack. 🅰️ Angular Community Stories and Signal Forms: The Angular team shares new community stories along with real-world code samples. There is also an update on Signal Forms, which builds on Angular’s signals model for handling reactive forms. If you work on form-heavy Angular apps, this is a useful glimpse into where things are going. 🤖 How Cursor Shipped Its Coding Agent: This post breaks down how Cursor built and shipped its AI coding agent. It goes into architectural decisions, trade-offs, and the realities of putting an AI-assisted dev tool into production. A solid behind-the-scenes read if you are curious about how modern developer tools are actually built. Tool of the Week ⚡Bun Gets Faster with v1.3.7 Bun shipped v1.3.7 last week with a JavaScriptCore update that brings noticeable performance gains, including faster async and await handling and ARM64 improvements. There’s also a new option to generate profiling data in Markdown for easier sharing, along with native support for JSON5 and JSONL. If you are curious why Bun keeps gaining traction, this article is still a good explainer on what’s driving its adoption. 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;} }

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 #123 Looking Back at 2025 and January in Focus Crafting the Web: Tips, Tools, and Trends for Developers Hi , Welcome back to the first WebDevPro issue of the year. We’re reopening with a tighter promise: a sharper take on what’s happening in web development, and what’s actually worth your attention. The web moved fast in 2025, but the real story was the direction the updates were pointed in. Everyday development got more structured, more AI-assisted, and more performance-aware, and the teams that adapted early are already moving differently. Last year we sent 42 issues to 40,000+ subscribers. This year, we want each edition to feel useful within the first minute: the ideas you can carry into your codebase, the shifts that change how you build, and the updates you should act on before they turn into surprises. This edition is a reset and a catch-up in one. We’re bringing back pieces from past issues that still hold up when you’re dealing with async complexity, messy failure modes, and production AI features. Then we compress 2025 into the shifts that mattered, followed by a short news corner to get you current. Let’s get started! Most popular articles from our past newsletters Taming Asynchronous Control Flow in Node.js: From Callback Hell to Elegant Patterns (Originally sent: August 06, 2025) Starting from the classic “callback hell” problem, this article showed how simple techniques like early returns and modular functions can clean up asynchronous code. It then introduced essential async control patterns, including sequential execution, concurrency, race condition prevention, and limited parallelism using queues, all grounded in practical Node.js examples. Even as async and await improve readability, the underlying coordination problems have not gone away. APIs are more distributed, users are more impatient, and systems are more parallel. Knowing how to control flow, limit concurrency, and avoid race conditions remains critical for building resilient applications. Rethinking Error Handling with Information Architecture (Originally sent: September 15, 2025) Errors are not all the same, and this article made a strong case for treating them differently. By classifying errors into user, system, and contextual types, it reframed error handling as an information architecture and UX problem rather than a purely technical one. The piece explored how clear messaging, thoughtful fallback navigation, and consistent structure help users recover when things go wrong, without losing trust or orientation. As products grow more complex and AI-driven systems introduce new failure modes, error states have become more visible and more consequential. Designing for breakdowns, empty states, and partial failures is now a core part of resilient UX. This article’s focus on graceful degradation, user-centered language, and recovery paths feels increasingly relevant in a world where systems fail in subtle, contextual ways rather than simply crashing. Building an AI Email Enhancer with React 19 and Vercel AI SDK (Originally sent: September 29, 2025) This article explored how modern React and AI tooling come together in a real-world feature. It walked through building a type-safe AI email enhancer using React 19 Server Functions, useActionState, Zod validation, and the Vercel AI SDK. Beyond the mechanics, it showed how server-first form handling and structured AI responses can turn raw input into polished communication with minimal friction. As AI features move from experimentation into core product workflows, reliability and developer experience have become non-negotiable. This piece focused on exactly that. By emphasizing type safety, server-side execution, and predictable form behavior, it anticipated a shift toward AI integrations that are trustworthy, maintainable, and production-ready. In 2026, this approach feels less like a demo and more like the baseline for serious AI-powered web apps. The shifts that defined 2025 TypeScript became GitHub’s #1 language: In August 2025, TypeScript crossed a symbolic threshold: it became the most used language on GitHub by contributor counts, overtaking both Python and JavaScript. TypeScript isn’t “just nicer types” anymore. It’s the default foundation for modern web app scale, and it fits the direction frameworks and AI-assisted coding are already pulling teams toward: more structure, fewer runtime surprises, and codebases that stay maintainable as they grow. AI became a baseline developer skill, not a differentiator:In August 2025, TypeScript crossed a symbolic threshold: it became the most used language on GitHub by contributor counts, overtaking both Python and JavaScript. TypeScript isn’t “just nicer types” anymore. It’s the default foundation for modern web app scale, and it fits the direction frameworks and AI-assisted coding are already pulling teams toward: more structure, fewer runtime surprises, and codebases that stay maintainable as they grow. WebAssembly 2.0 made the browser a serious performance platform: With Wasm 2.0 marked “official,” the story is less “new tech” and more “this is stable enough to bet on.” WebAssembly keeps showing up where JavaScript naturally struggles: graphics-heavy experiences, compute-intensive features, and workloads that want near-native performance without leaving the browser. As Wasm matures, it quietly expands what “web app” can mean, turning the browser into a practical runtime for edge-case performance rather than a hard constraint teams work around. Tech jobs in 2025 quietly stabilized, even as layoffs stayed part of the story: After the brutal reset in 2022 and 2023, 2025 looked less like a rebound and more like a steady return to normal. Open roles kept inching up across startups and public tech companies, while layoffs were far less sweeping than the 2023 peak and increasingly concentrated in specific companies. The story of 2025 wasn’t a hiring frenzy, it was selective job creation and early signs that technical hiring is rebuilding momentum. JavaScript turned 30:Last year, our favorite semicolon-optional, closure-loving, eventually-async language turned 30. It’s officially old enough to rent a car, and it’s still picking up new features every year. Thirty years of function-scope confusion, a brief era where jQuery felt mandatory, and endless hours untangling asynchronous code. Through all of it, JavaScript stepped out of the browser, powered the rise of Node.js, and now runs everywhere from edge runtimes and cloud platforms to tiny devices. This week’s news corner JavaScript Rising Stars 2025 points to a new center of gravity: workflows: n8n emerged as the clear breakout winner, jumping from fifth place last year to number one with a record setting surge in GitHub stars, reflecting growing demand for AI powered automation and low code workflows. React continues to anchor the frontend world, reclaiming the top framework spot, while projects like shadcn/ui and react-bits underline the momentum around composable, design forward UI systems. On the backend, newcomer Motia signals a potential shift toward unified full-stack frameworks that collapse APIs, workflows, and AI agents into a single abstraction, making this year’s rankings less about incremental wins and more about where modern JavaScript development is heading next. Node.js shipped coordinated security releases across active lines: Node.js pushed security updates for v20.x, v22.x, v24.x, and v25.x on January 13, 2026, addressing multiple vulnerabilities across the active release lines. If you’re running Node in production, this is the kind of patch cycle you treat like a sprint task, not a “later” item. The practical move: check your runtime versions, plan a fast upgrade window, and make sure your dependency chain (especially anything touching HTTP, permissions, or request parsing) gets the same level of scrutiny. Angular 21.1 is landing, and the RC is already hinting at the direction: Angular 21.1 is expected imminently, and the 21.1.0-rc.0 release is a useful preview of what the team is tightening up next. Even if you don’t jump on minors day one, RC notes are a strong early warning system: they show what’s being stabilized, what’s being nudged into “new default” territory, and what might create friction in apps that sit a little off the happy path. Claude Code added Tool Search, making “tool use” feel less manual:Tool Search is now showing up in the Claude ecosystem, and it changes the ergonomics of agentic coding. Instead of you hard-wiring a small set of tools into context, the system can discover and select from a broader tool universe without blowing up the prompt budget. The result is less ceremony around “which tool do I expose,” and more momentum when you’re moving between code, docs, and actions. What do you want more of in 2026? Hit reply and tell us! Aaand that’s a wrap! This issue is a reset around one idea: web dev is rewarding teams that build with clearer contracts and tighter guardrails. From async control and resilient error states to TypeScript’s rise, production-ready AI workflows, and WebAssembly getting practical, the direction is the same. Even this week’s updates fit the pattern: patch Node, track Angular’s next release, and watch how tool-first coding is evolving. Before you close this tab, pick one default you’ve been relying on and tighten it. If something surprises you, hit reply and tell us what you learned. Cheers! Editor-in-chief, Kinnari Chohan Have any ideas you want to see in the next article? Hit Reply! 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;} }

Real-world insights for sharper web dev decisionsAdvertise 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 #122Rise of LLM Powered agentsReal-world insights for sharper web dev decisionsHi ,As the year winds down, there was one idea we kept coming back to and wanted to leave you with before the break.This is a short bonus note to close out the year, touching on a shift many teams are starting to notice, even if they’re not naming it yet.The quieter shift around AI agentsMuch of the conversation around AI agents still focuses on how they help teams work faster. That part is useful, but it may also be the least interesting aspect of what’s changing.A quieter shift is happening in how products are observed and operated once they are live.Most products do not fail in obvious ways. Things change gradually. A metric softens, user behaviour shifts slightly, or performance drifts away from what once felt normal. These changes are rarely dramatic, but they are easy to miss when attention is split and teams are busy moving forward.What agents are beginning to do well is take on that background attention. They sit alongside live systems, watch behaviour continuously, and surface changes that genuinely matter. This is not about adding more dashboards or alerts. It is about maintaining a steady sense of awareness without relying on someone remembering to check at the right time.From chatbots to agentic systemsOver the past couple of years, large language models (LLM) have reshaped how we think about AI. As their capabilities expanded, many teams started running into the same limitations when trying to use them in real systems:They lack long-term memory and lose context over timeThey wait for prompts instead of operating autonomouslyThey cannot naturally interact with live systems, APIs, or data sourcesAgentic systems emerged to bridge this gap.Instead of treating AI as something you talk to, agents are designed as systems that can observe, reason, and act over time. At a high level, this usually means combining an LLM with a few additional capabilities:Memory, so context carries across days or weeksPlanning, to break down goals into smaller stepsTool use, to interact with APIs, databases, and external servicesThe result is software that is less reactive and more continuous in how it operates.Where this shows up in practiceThis approach is already appearing in newer tools, especially around monitoring and operations. One example is Fload, which applies agent-based thinking to continuous product monitoring.Fload connects to app store data, revenue signals, and usage behaviour to maintain an evolving picture of how an app is performing over time. Instead of relying on periodic reviews or manual checks, the system focuses on noticing when patterns drift, not just when something breaks.In practice, this means:Watching performance continuously instead of weekly or monthlyHolding context about what “normal” looks like for a productHighlighting changes that indicate early risk or opportunityReducing the need for constant manual monitoringWhile Fload is built for mobile apps, the underlying idea is broadly relevant. As systems grow more complex, the cost of missed signals increases, and continuous attention becomes harder to sustain manually.A pattern worth paying attention toFor developers, none of this should feel unfamiliar. We already care about logs, monitoring, and observability. What agents add is continuity. They help systems remember, notice slow changes, and surface context before small issues compound into larger ones.This shift, from periodic checking to continuous watching, is likely to influence how we design products, pipelines, and operational workflows in the years ahead.If you’d like to see one real-world implementation of this idea, you can explore Fload here.Get instant answers on your app growth for freeThat’s it from us for the year.Thank you for reading, replying, and sharing WebDevPro through 2025. We’ll be back in January with fresh issues and new ideas. Until then, take a proper break.Cheers!Editor-in-chief,Kinnari ChohanHave any ideas you want to see in the next article? Hit Reply!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;} }

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 #121: JavaScript turns 30, Django 6.0 arrives, and TypeScript 7 development updates Crafting the Web: Tips, Tools, and Trends for Developers The GenAI Experience Users Already Love, Securely Accessing Your SaaS Product AI agents are knocking on the door of your SaaS product. Open it up. Frontegg AgentLink gives you the confidence that any access to your SaaS product is done responsibly, so you can fast track your role in the AI revolution. What you get with AgentLink: ✅ No-code, hosted MCP server ✅ Pick which tools to expose ✅ Set fine-grained policies for agents ✅ Human-in-the-loop & step-up safeguards Get AgentLink now! Hi , Welcome to the final WebDevPro issue of the year 🎉 We made it. One more lap around the sun, one more swirl of releases, rewrites, patches, hot takes, and the occasional “wait, what just happened” moment that only web development can deliver. If you have ever felt like this industry moves at the speed of light, you are not imagining it. But through every shift, surprise, and trend cycle, one constant has been riding along with us since the Netscape era: JavaScript. Last week, our favorite semi-colon optional, closure loving, eventually async language celebrated its 30th anniversary. It is officially old enough to rent a car, yet it is still getting new features every year. Think about that for a second. Thirty years of function scope confusion, two years of mandatory jQuery, and countless hours battling asynchronous code. Through all of it, JavaScript did not just endure. It expanded. It stepped out of the browser, sparked the rise of Node.js, and now sits inside everything from cloud databases to tiny drones. So before we get into this week’s highlights, including updates from the official team on the upcoming roadmap and new progress on TypeScript 7.0, take a second to appreciate the small miracle that keeps our industry running. A language built in ten days now holds together most applications on the planet. Happy Birthday, JS! Let's now get to the news: 🧠 TypeScript 7 development updates 📦 Django 6.0 released with Template Partials, Background Tasks, and CSP support ☁️ Anthropic acquires Bun as Claude Code hits a billion-dollar milestone ⚡ API Caching in Angular offers simple wins for performance and responsiveness 🧭 Designing for Trust and Simplicity reframes how UI clarity shapes user confidence Advertise with us Interested in reaching our audience? Reply to this email or write to kinnaric@packt.com. Learn more about our sponsorship opportunities here. Latest news: what's new in web development? 📰 📦 Django 6.0 released:Django 6.0 is now available with Template Partials for modular markup, a built-in Background Tasks framework, new Content Security Policy support, and a refreshed Modern Email API. The release also shifts Django 5.2 into security-only maintenance until April 2028 which gives teams a long runway for planning upgrades. 🟦 TypeScript 7 development update: The TypeScript team reports steady progress on TypeScript 7 with gains in compiler performance, faster incremental builds, and cleanup work that improves the language service experience. The update confirms that 6.0 will be the final JavaScript-based release and will serve as the bridge to the new Go-powered compiler in 7.0, which is already showing speeds up to 10x faster. 🧠 Anthropic acquires Bun as Claude Code hits a billion dollar milestone: Anthropic has acquired Bun as part of its growing ecosystem around Claude Code, which just hit a one billion dollar annualized revenue milestone. The move signals a deepening commitment to performance-focused dev tooling, and Bun remains open source under Anthropic’s stewardship, now backed by more funding and long-term infrastructure support. ⚛️ React 19.1.2 released: The React team has released version 19.1.2 with a batch of fixes and quality-of-life updates. This patch focuses on improving stability and compatibility across frameworks and tools, giving teams on the React 19 line an updated, production-ready version without jumping into major changes. ☁️ Node.js 24 runtime available in AWS Lambda:AWS Lambda now supports Node.js 24 as the nodejs24.x runtime. The release introduces the updated Runtime Interface Client, removes callback style handlers, and encourages async and await as the default pattern which makes serverless functions feel more modern. AWS plans to support this runtime until April 2028. 🎨 CSS Subgrid enters practical use:Josh Comeau dives deep into CSS Subgrid, the long-awaited layout feature that brings alignment superpowers to nested elements. Subgrid allows child components to inherit parent grid structure, making responsive layouts cleaner and more maintainable. His post includes real-world examples that show how to replace fragile flex hacks with solid CSS patterns. Expert corner: what's the web community talking about?🎙 🗣️No More Self-Censorship in Developer Culture:Kerrick Long reflects on the hidden cost of silence in engineering teams. From avoiding hard truths to downplaying opinions in retros or code reviews, self-censorship erodes psychological safety and product quality. Long encourages devs to engage openly, challenge assumptions, and foster environments where candor is a strength, not a liability. ⚡ API Caching in Angular:Awais Afzal revisits a powerful but underused performance technique in Angular development: API caching. He outlines how simple memoization strategies and Angular’s built-in RxJS tools can reduce API calls, enhance responsiveness, and remove the need for premature architectural overhauls. 🦀 Rust’s Vision Document Lessons:The Rust Core Team shares a behind-the-scenes breakdown of how they developed the language's long-term vision. The post details how community consultation, iteration, and tough tradeoffs shaped the outcome and what other open source projects can learn from the process. 🧭 Designing for Trust and Simplicity: Jeremy Keith takes aim at overcomplicated UI trends with a call for straightforward design. He advocates for interfaces that prioritize user understanding, accessibility, and minimal assumptions, reminding devs that trust is built through clarity, not cleverness. 🧩 Why Tooltip Components Shouldn’t Exist: Dominik Dorfmeister critiques the prevalence of tooltip components in modern UI libraries. Rather than patching unclear interfaces with hover tips, he suggests that designers and developers focus on making core elements more self-explanatory. Tooltips, he argues, often mask deeper design problems. Want to be featured in WebDevPro? Share your tips or takes, we’re all ears! Featured tutorials🎓 🔷 Building a Metro Map UI with CSS Grid and SVG Jacob Filipp walks through how he recreated London’s iconic Victoria line using CSS Grid and SVG. The guide covers layout logic, interactivity, and keeping visual fidelity with real-world transit maps. 🧩 Custom Button Logic with Invoker Commands API This walkthrough explains how to use the Invoker Commands API to assign behaviors to buttons and extend them with custom JavaScript. Ideal for devs building accessible and interactive UI elements. 🎬 Aaand that's a wrap! As we close out the year, I want to say thank you for being here. Each issue is shaped by your curiosity and the conversations happening across the community. This is the last stop before a well-deserved break, so take care, rest well, and I look forward to starting a new chapter together in the new year. Until next time. Kinnari Chohan, Editor-in-chief 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;} }

Crafting the Web: Tips, Tools, and Trends for DevelopersAdvertise 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 #120: Angular 21 pushes reactivity forward, Node 24 reaches LTS, and the React community shares what matters nextCrafting the Web: Tips, Tools, and Trends for DevelopersHi ,Welcome to this week’s edition of WebDevPro!The conversation that stood out most for us this week came from the Cloudflare outage and the analysis that followed. What caught my attention was how many developers saw it as a reminder of how dependent the web has become on a small number of platforms. Instead of focusing on the technical misstep alone, much of the discussion centered on what real resilience looks like and how teams think about risk when so much of their stack lives on the internet’s shared backbone. It was interesting to see how quickly the community moved from surprise to reflection, using the outage as a moment to rethink assumptions that often sit quietly behind the scenes.Alongside that, the ecosystem kept moving in interesting ways, from new framework releases to deeper looks at the tools and habits shaping modern development.Before we jump in, here are this week’s highlights:📊 The State of React 2025 survey closes with insights that build on last year’s community trends🚨 Cloudflare outage analysis surfaces deeper lessons about resilience and infrastructure design🚀 Angular v21 introduces Signal Forms, stronger accessibility components and a modernized toolchain🟩 Node.js 24 enters long-term support with improved stability and broader platform readiness📱 CSS Grid support moves closer to React Native and brings more powerful layout capabilitiesAdvertise with usInterested in reaching our audience? Reply to this email or write to kinnaric@packt.com.Learn more about our sponsorship opportunities here.Latest news: what's new in web development? 📰🔧 Angular v21 released: Angular 21 is here with big changes: a new experimental “Signal Forms” system for reactive form state, a built-in accessibility/ARIA component library, and a revamped toolchain with a new default test runner. This release signals Angular’s push toward more reactive, type-safe patterns and modern developer ergonomics.📊 The State of React 2025 survey closes after another strong community turnout. Here'slast year's results: Devographics has closed the 2025 State of React survey, which remains one of the clearest signals of how the React ecosystem actually evolves, capturing what developers build with, what slows them down, and what they want to change. Last year’s results revealed a steady rise in TypeScript adoption, a shift toward lighter React frameworks, and growing dissatisfaction around performance debugging. This year’s data is expected to show how React developers are responding to React Server Components, new bundler competition, and the continued pressure to improve performance at scale.📱CSS Grid support may land soon on React Native:A proposal gaining traction suggests native CSS Grid support is coming to React Native, potentially bringing real layout-power (grid-based layout, responsive designs) to mobile frameworks that usually rely on flexbox or custom layout logic. This could narrow the layout feature gap between web and native apps.⚠️ Critical lessons from recent Cloudflare outage:A recent post reviews a serious Cloudflare outage and argues that the root problems were not just technical but architectural; urging teams to think harder about redundancy, failure modes, and resilience rather than just relying on cloud defaults.A sharp wake-up call for anyone building on third-party infra to treat outages as design constraints rather than rare events.🚀 Node.js 24 LTS goes live for production and serverless builds:Node.js 24 has entered LTS, and services like Vercel now offer first-class support for builds and functions targeting “24.x”.This is a good moment for teams to upgrade. The release brings improved runtime stability, updated Web API support, and long-term maintenance guarantees.Expert corner: what's the web community talking about?🎙🧠Debugging production is a mindset, not a toolset:This podcast explores how engineers approach debugging in real systems and why a calm, structured way of thinking often matters more than any particular tool. The discussion highlights how observability, curiosity and well-formed hypotheses help teams navigate failures in a way that scales with growing system complexity.🧪 A practical guide to integration testing in Django:Honeybadger offers a grounded walkthrough of integration testing in Django using the built-in test client, realistic database state and fixture patterns. The piece shows how to validate full request flows and avoid the false comfort that sometimes comes from isolated unit tests. It frames testing as a path to trustworthy backends.⏱️ Postgres can schedule tasks more cleanly than you think:This post presents a lightweight method for turning Postgres into a task scheduler by using advisory locks, row updates, and simple polling. It is a compelling alternative to heavier queue systems for tasks that do not need distributed orchestration. The approach encourages teams to examine how much infrastructure is truly needed for dependable background work.🎨 Understanding how CSS inherits and shares values across your UI:CSS-Tricks breaks down how inheritance actually works in CSS, how custom properties flow, and how shared values can simplify component systems. It is a clear explanation of why many layout issues come from assumptions about the cascade rather than the cascade itself.⚡A performance tier list for modern web animation approaches:Motion.dev evaluates various animation techniques on the web and ranks them by smoothness, reliability, and runtime cost. The analysis covers CSS transitions, CSS animations, WAAPI, JavaScript-driven motion, and mixed patterns. It is a helpful guide for choosing animation strategies that match performance goals instead of relying on guesswork.Want to be featured in WebDevPro? Share your tips or takes, we’re all ears!Agentic AI Frontier Summit 2025 (Online): From Single Models to Autonomous SystemsJoin us on Dec 13, 2025 · 9am–2pm ET / 6am–11am PT to discover how AG2, autonomous research agents, and real-world multi-agent systems are reshaping science, engineering, and AI-native companies. Get 40% off with code DEEPENG40 and secure your spot at the frontier of agentic AI.Unlock 40% off – Register with DEEPENG40This week's book drop📚RESTful API Design Patterns and Best Practices🚀 Design APIs that scale with your product using patterns that keep services stable as teams and traffic grow📘 Build confidence with a practical, hands-on approach that covers contracts, versioning, OpenAPI, and real-world design choices🧩 Avoid hidden complexity with guidance on domain-driven design, client-focused endpoints, and API evolution across distributed systems ⚡ Strengthen your architecture through techniques that reduce breaking changes and improve long-term maintainabilityOrder on AmazonOrder on PacktPubFeatured tutorial 🎓🌐 How many HTTP requests can a single machine handle?This article walks through load testing a simple HTTP server to measure how many requests a single machine can reliably serve under different concurrency scenarios. It shows how latency, CPU utilization, and event-loop behavior combine to produce real throughput limits. For developers deploying services on modest infrastructure or experimenting with serverless/hobby servers, this tutorial offers a practical exploration into performance ceilings and realistic capacity planning.Got a minute? Tell us what clicked (or didn't)🎬 That’s all for this week. If something in this issue sparked a thought, a question, or a new curiosity, I’d love to hear it.Until next time.Kinnari Chohan,Editor-in-chiefSUBSCRIBE 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;} }

Real-world insights for sharper web dev decisions 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 #119 Modern Async JavaScript, without the knots Real-world insights for sharper web dev decisions AI-Powered Development with Cursor Workshop Accelerate your coding workflow and ship apps faster with Cursor, Supabase, and OpenAI. Book Your Seat 🗓️Nov 29, 2025 | 8:30 AM – 12:30 PM (ET) | 💻 Virtual 🎟️ 40% OFF with codeCURSOR40+ 2 FREE e-books Fill This Form to Claim Your FREE E-books! Thanks for joining me for this week’s WebDevPro issue! Most things that feel slow in a web app are not actually slow. They are waiting. A request is in flight. A timer has not fired yet. The user has not clicked. Async JavaScript is how you keep the page responsive while that waiting happens. Once you see how the browser schedules work, how promises settle, and how await resumes your function, you stop guessing. Your UI starts to feel calm because your code is calm. This week’s deep dive is based on material from JavaScript from Beginner to Professional by Laurence Lars Svekis, Maaike van Putten, and Rob Percival. This book is a practical guide that breaks down modern JavaScript fundamentals with clarity. and the concepts discussed here draw from this book. Let’s start with the mental model, then build toward patterns that hold up when real-world complexity enters the picture. By the end, it becomes much easier to see what can run in parallel, what must be sequenced, what deserves a timeout, and what should be canceled the moment the user moves on. But before we get into it, here are the standout links from last week’s edition: 🪄Learn JavaScript by building Mario 🛡️ OWASP Top 10 2025 RC1 highlights emerging web security risks 📊 GitHub Octoverse 2025 🔬 Why TypeScript leads the AI era of development Have any ideas you want to see in the next article? Hit Reply! Advertise with us Interested in reaching our audience? Reply to this email or write to kinnaric@packt.com. Learn more about our sponsorship opportunities here. The event loop is the heartbeat JavaScript in the browser runs on a single thread. You do not spin up operating system threads. You schedule work that will continue later. The browser owns an event loop. It pulls tasks off queues and runs your callbacks when results are ready. There are two queues you feel every day. The task queue holds timers and I O completions. The microtask queue holds promise reactions. The loop runs a task, then drains microtasks, then gives the browser a chance to paint. That one detail explains a lot of puzzling behavior. A continuation after await is a microtask. A callback from setTimeout(fn, 0) is a task. The microtask wins the race. You can prove it with a tiny console exercise and watch the order of logs line up with the model. console.log("A: start"); Promise.resolve().then(() => console.log("B: microtask")); setTimeout(() => console.log("C: task"), 0); (async () => { console.log("D: before await"); await null; // schedules a microtask continuation console.log("E: after await"); })(); console.log("F: end"); // typical order: A, D, F, B, E, C If the page ever feels sticky, it usually means you blocked the main thread. The cure is not a trick. Break heavy work into small pieces, yield between pieces, and let the browser breathe. Promises are a contract, not a mystery A promise represents a later value or a reason for failure. It starts pending, then becomes fulfilled or rejected, and it never changes again. You do not poll a promise. You register reactions and the runtime calls you exactly once when it settles. Chaining works because .then returns a new promise that adopts what you return. If you return a plain value, the chain moves forward with that value. If you return a promise, the chain waits. If you throw, the chain jumps to the next rejection handler. Many head-scratching bugs come from forgetting to return the inner promise and letting a chain run ahead of the work. The fix is simple. If you start more async work inside a handler, return it. Make error handling part of the design. Decide where errors become messages and where they become quiet fallbacks. Unhandled rejections will shout in devtools, but your users need a calmer story. Async and await help you read what you wrote async and await do not change promise semantics. They make the choreography readable. An async function always returns a promise. await yields inside that function until a promise settles, then either gives you the value or throws the error. You get the same behavior as a well-written chain, but in the order your brain tells the story. Keep try and catch around logical chunks, not the entire function unless it truly is one unit. Put cleanup in finally so it runs whether you succeeded or failed. That is where you stop spinners, release locks, and finish metrics. Here is a compact pattern for network work that needs clear outcomes and guaranteed cleanup. async function loadProfile(id, { signal } = {}) { startSpinner(); try { const res = await fetch(`/api/profile/${id}`, { signal }); if (!res.ok) throw new Error(`HTTP ${res.status}`); return await res.json(); } catch (err) { return { error: true, message: err.message }; } finally { stopSpinner(); } } One pitfall to keep in mind. array.map(async item => ...) gives you an array of promises. If you want the values, await them as a group. If the steps depend on each other, resist cleverness and write them in sequence. Orchestrating what overlaps and what depends A calm UI often comes down to honest orchestration. Some work can run together. Some must wait. If you are fetching user data, preferences, and notifications, start them together and join them when all are ready. If you are logging in and need the token before fetching a profile, keep that flow in sequence so the dependency is clear. For batches where one failure should not sink the rest, gather everything and inspect the outcomes after. For timing concerns, compose a timeout without twisting the control flow. function withTimeout(promise, ms) { return Promise.race([ promise, new Promise((_, rej) => setTimeout(() => rej(new Error("Timeout")), ms)) ]); } These helpers do not remove thinking. They encode intent so the code reads like the plan you had in your head. Cancellation that matches how people behave People change their minds. They type again. They navigate away. If a search response from an old query lands after the new one, it can overwrite fresh state with stale data. Treat cancel as a normal outcome. The platform gives you AbortController and AbortSignal. Wire them in and clear the pending state when the user moves on. let current = 0; async function search(q) { const id = ++current; const controller = new AbortController(); const res = await fetch(`/api/search?q=${encodeURIComponent(q)}`, { signal: controller.signal }); const data = await res.json(); if (id !== current) return; // stale result, drop it renderResults(data); } Add a simple guard like that and you avoid ghost updates even if some lower level cannot be canceled. Do not toast an error when the user intentionally cancels. Just settle the UI and let them keep going. Concurrency limits and backpressure Starting twenty operations at once feels bold until your server pushes back and your tab stutters. A small limiter gives you backpressure. Allow a fixed number of active operations. Queue the rest. When one finishes, start the next. Median times improve. Tails tighten. Rate limits hurt less. You can write a limiter in a handful of lines or use a tiny utility if your team prefers. The key is to adopt the habit on the paths that matter. If you are streaming results into the DOM, apply the same idea. Do not reflow the page for every tiny chunk. Buffer a few and render on a steady rhythm so the browser can paint between updates. Streams and async iteration when a spinner is not enough Sometimes the right move is to show progress as it happens. Users prefer a trickle of real content over a long spinner. Async iterators make this clean. Loop over incoming chunks, render slices as they arrive, and the page feels alive. Pair it with a skeleton screen so the shape of the UI is visible from the start. Your content grows into a believable frame rather than jumping from nothing to finished. Wiring the UI so async behaves Most async work starts with an event. A click, a keypress, an input change. If you wire listeners at the right time and understand how events travel through the DOM, your async code stops fighting the page. The figure on the left shows bubbling: the event fires on the target, then moves outward through its ancestors. On the right, the figure shows capturing: the event moves in from the outer ancestor toward the target before the usual bubbling phase. Watch the order of the console messages. That order is the lesson. A normal listener gives you inner to outer. A capture listener gives you outer to inner. This is why delegation works so well. One listener on a stable parent can hear clicks from many dynamic children. Attach listeners when elements exist. DOMContentLoaded is the sweet spot. If you want to intercept early, register a capture listener. If you want one place to handle many items, register a bubbling listener on a parent and let events rise to it. Here is a tiny delegation pattern that stays out of the way: document.addEventListener("DOMContentLoaded", () => { const list = document.querySelector("#todo-list"); list.addEventListener("click", async (e) => { const btn = e.target.closest("[data-action='delete']"); if (!btn) return; try { const id = btn.closest("li").dataset.id; await fetch(`/api/todos/${id}`, { method: "DELETE" }); btn.closest("li").remove(); } catch (err) { alert(err.message); } }); }); Two controls to remember as you read the figures. event.preventDefault() stops the browser’s default action. event.stopPropagation() stops the journey through the tree. They solve different problems. Use them on purpose, not by habit. Debugging without guesswork There is a fast way to get unstuck. Put a breakpoint on the await line that surprises you. Step once. Watch local variables. Watch the call stack shift when the continuation runs. Put a breakpoint in the catch you believe is responsible for that block of work and confirm that it fires. Verify that it finally runs every time. Ten minutes of that beats an hour of logs. When a flow does something odd, ask three questions. Did the handler attach at the time I thought it did? Did the promise I awaited actually reject, or did it resolve to an error-shaped value? Did my cleanup run? You can answer those in the debugger faster than you can by guessing. Make it feel fast, not just be fast People judge speed by responsiveness. Start optimistic updates where it is safe and reconcile with the server when the result arrives. Keep event handlers small so the browser can paint and react to the next input. Defer non-critical work with requestAnimationFrame or a microtask. If you need heavy computation, hand it to a worker so the main thread stays clear. The goal is not a perfect number on a benchmark. The goal is a page that feels alive even on a noisy network and a mid-range phone. A short wrap so the ideas stick Promises are the contract. async and await make the contract readable. The event loop sets the rhythm and your code decides what runs together and what must wait. Add cancel so old results never clobber new ones. Add a gentle limiter so nothing overwhelms anything else. Add retries with timeouts so failures are handled on purpose. Wire events at the right time and let delegation carry some of the weight. Debug at the await points. If you keep these habits, your app will feel composed on a good day and resilient on a bad one. If you want to go deeper into these foundations, many of the concepts in this week’s issue come from JavaScript from Beginner to Professional. It’s a solid reference to keep on your shelf, or your Kindle! Cheers! Editor-in-chief, Kinnari Chohan Got 60 seconds? Tell us what clicked (or didn’t) 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;} }

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 #118: Octoverse shows explosive developer growth, OWASP highlights 2025 web risks, and TypeScript leads the AI era Crafting the Web: Tips, Tools, and Trends for Developers Hi , Welcome to this week’s edition of WebDevPro! Some weeks feel shaped by flashy releases, but this one stood out for a different reason. The conversations and updates circling the web development space leaned into insight, clarity, and a deeper understanding of the systems we depend on. From security researchers sharpening the industry’s awareness of real-world risks to language architects reflecting on how AI is subtly reshaping the developer workflow, the themes this week pointed toward a community thinking more carefully about the choices that guide modern engineering. Runtime maintainers, tool authors, and educators all contributed perspectives that make it easier to see where the ecosystem is heading and what skills will matter as it evolves. In this issue of WebDevPro, we look at ideas and updates that help developers work with more precision, more awareness, and a stronger grasp of the fundamentals that keep the web running. Before we dive in, here’s a quick look at this week’s highlights: 📊 Insights from GitHub Octoverse 2025 and what they signal for the developer ecosystem 🧠 TypeScript’s rise in the AI era, with perspective from Anders Hejlsberg 🛡️ OWASP Top 10 2025 RC1 outlining the most significant web application security threats 🟩 The State of Node.js 2025 explained by Matteo Collina 🔍 A deep dive into how JavaScript source maps work and how debugging tools reconstruct execution Advertise with us Interested in reaching our audience? Reply to this email or write to kinnaric@packt.com. Learn more about our sponsorship opportunities here. AI-Powered Development with Cursor Workshop Accelerate your coding workflow and ship apps faster with Cursor, Supabase, and OpenAI. Book Your Spot! 🗓️ Nov 29, 2025 | 8:30 AM – 12:30 PM (ET) | 💻 Virtual 🎟️ 40% OFF with code CURSOR40+ 2 FREE e-books After Purchase, Fill This Form to Claim Your FREE E-books! Latest news: what's new in web development? 📰 📊 GitHub Octoverse 2025: GitHub’s Octoverse report shows a remarkable acceleration in developer growth, with more than one new developer joining every second in 2025. The data highlights how AI usage is reshaping workflows and how TypeScript has climbed to the top of language adoption. These trends reflect a year defined by rapid skill expansion and a movement toward typed, tool-assisted development. 🛡️ OWASP Top 10 2025 RC1 highlights emerging web security risks: OWASP released the 2025 update of its Top Ten web application security threats, surfacing trends that reflect how modern applications fail in practice. The new categories emphasize supply-chain exposure, insecure AI integrations, and the growing risk in misconfigured authentication flows. This release gives teams a sharper framework for assessing where their systems are most vulnerable. 🐘 Storybook 10 introduces faster builds and a redesigned developer experience: Storybook 10 arrives with significant performance improvements, including faster story loading and a smoother preview environment. The update modernizes the internal architecture and improves compatibility with React Server Components and Next.js 16. It is a welcome upgrade for teams that manage large design systems and extensive UI component inventories. 🗄️The State of Node.js 2025 by Matteo Collina: Matteo Collina’s annual deep dive into Node’s roadmap covers performance trends, upcoming runtime features, and the growing influence of JavaScript tooling that builds on top of Node rather than around it. His perspective offers a grounded view of where the platform stands and where developers' needs are guiding its evolution. 📨 React Email 5: React Email 5 updates the library to React 19.2 and Next.js 16 while retiring the older renderAsync API. The new release simplifies template rendering and gives teams tighter compatibility with current React standards. It supports a growing shift toward using React for structured communication workflows that live alongside product code. 🟩Node.js v25.2.0:Node.js 25.2.0 arrives with refinements across utilities, networking behavior and diagnostic reporting. The release strengthens how developers observe and tune their runtime while keeping the platform aligned with modern JavaScript workflows. It signals a maturing phase for Node where clarity and stability are becoming core priorities. Expert corner: what's the web community talking about?🎙 🪄Learn JavaScript by building Mario: This hands-on tutorial rebuilds classic Mario mechanics from scratch to teach JavaScript fundamentals through motion, physics and sprite logic. It is a fun, visual way to understand how code interacts with real-time systems. 🔬 Why TypeScript leads the AI era of development: Anders Hejlsberg shares how TypeScript became the most active language on GitHub and why its type system aligns naturally with AI-supported development. His perspective connects ecosystem growth to the practical value of predictable, typed code in fast-moving projects. It is a thoughtful look at how the language continues to shape modern JavaScript practice. 🔥 Bringing high-performance syntax highlighting to the browser with CSS Highlights:This article shows how the CSS Custom Highlight API can replace token-wrapped DOM structures with lightweight highlight ranges. The approach improves rendering performance and keeps HTML cleaner, which benefits any team building editors, documentation tools, or rich UI surfaces. It feels like a practical upgrade to a problem developers have lived with for years. 🧠 Making time predictable in test suites:The Angular team explains strategies for testing code that depends on timers, scheduled events, or asynchronous transitions. The post outlines how mock clocks create predictable environments that avoid flaky tests and unclear timing behaviours. It is a helpful reminder to treat time as another dependency that deserves thoughtful design. 🔖How JavaScript source maps work under the hood: Polarsignals breaks down how source maps are generated, encoded, and consumed by modern tooling. The walkthrough connects the conceptual model to concrete examples, helping developers understand how debugging pipelines reconstruct real execution paths. Want to be featured in WebDevPro? Share your tips or takes, we’re all ears! This week's book drop📚 RESTful API Design Patterns and Best Practices 🚀 Design APIs that scale with your product using patterns that keep services stable as teams and traffic grow 📘 Build confidence with a practical, hands-on approach that covers contracts, versioning, OpenAPI, and real-world design choices 🧩 Avoid hidden complexity with guidance on domain-driven design, client-focused endpoints, and API evolution across distributed systems ⚡ Strengthen your architecture through techniques that reduce breaking changes and improve long-term maintainability Order on Amazon Order on PacktPub Featured tutorials 🎓 🔁 Importing torrents in Node.js with readable patterns: Evan Hahn shares a practical walkthrough on how to parse and import torrent files using Node.js, leaning on clear data structures and stream-based patterns. The tutorial illustrates how to inspect metadata, handle buffers with intention and keep parsing logic approachable for real-world file workflows. It offers a gentle deep dive into a format many developers rarely explore directly. 🧩 Understanding Module Federation through a hands-on guide: This guide breaks down the foundations of Module Federation with simple examples that reveal how JavaScript applications can share code at runtime. The author walks through configuration, dependency boundaries and loading strategies in a way that feels accessible without hiding the architectural implications. It helps developers grasp how to design microfrontends that stay flexible and maintainable. Got a minute? Tell us what clicked (or didn't) And before we say goodbye, here's a little web dev delight of the week 🌸 KokoScript lets you write JavaScript entirely in Japanese, complete with a playground that shows how the syntax compiles back to standard JS. It is a small, charming reminder of how creative the developer community can be when experimenting with language design. 🎬That’s all for this week. The ecosystem may be moving fast, but it is energizing to see so many developers share the ideas, tools, and experiments that help the rest of us grow a little sharper. If something in this issue sparked a thought, a question, or a new curiosity, I’d love to hear it. Until next time. Kinnari Chohan, Editor-in-chief 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;} }