DEV Community: Solo

Difference Between useEffect and useLayoutEffect in React

Solo — Mon, 08 Sep 2025 10:41:15 +0000

The difference between useEffect and useLayoutEffect is usually described in terms of timing one executes before the browser paints, and the other executes after. To verify this, I ran a controlled experiment and used Chrome DevTools to observe their execution on the performance timeline.

Experiment Setup

The React component under test

import { useEffect, useLayoutEffect } from "react";
import "./App.css";

function App() {
  useEffect(() => {
    performance.mark("effect-start");
    const waitUntil = Date.now() + 1000;
    while (Date.now() < waitUntil) {
      // Busy-wait
    }
    performance.mark("effect-end");
    performance.measure(
      "effect-duration",
      "effect-start",
      "effect-end"
    );
  }, []);

  useLayoutEffect(() => {
    performance.mark("layout-effect-start");
    const waitUntil = Date.now() + 1000;
    while (Date.now() < waitUntil) {
      // Busy-wait
    }
    performance.mark("layout-effect-end");
    performance.measure(
      "layout-effect-duration",
      "layout-effect-start",
      "layout-effect-end"
    );
  }, []);

  return <div className="center-box">Hello</div>;
}

export default App;

Both hooks record performance marks so their exact execution time can be identified in the timeline.

Observation

After recording the page load in Chrome’s Performance panel, the

following sequence was visible

The marker layout-effect-executed appears on the timeline before the first paint event.
The marker effect-executed appears after the first paint has completed.

The flame chart makes this distinction clear

useLayoutEffect occurs synchronously, inside the rendering pipeline.
useEffect is deferred until after rendering work concludes.

I think we need to start reading code than we write. As AI getting better at generating and completing code. A practice consciously reading code. because only if we truly and consciously understand it and trust it.

Solo — Sun, 07 Sep 2025 12:01:27 +0000

The true cost of Fargate vs 10,000 managed CI minutes

Solo — Fri, 29 Aug 2025 20:27:31 +0000

I was thinking about running Playwright tests in AWS ECS Fargate. Running Playwright on ECS Fargate is fast, cheap. For 10,000 minutes at 1 vCPU/2 GB in EU-London, Fargate is about $9.46 (or $7.57 on Graviton, $2.84 on Spot) versus $40–$100 for managed CI minutes on well known CI platforms like GitHub Actions, BitBucket, GitLab, AWS CodeBuild.

But minutes aren’t the whole bill—watch egress/NAT, caches & storage, and CloudWatch costs, handle Spot preemptions with retries and fallback, and rebuild the "just works" UX of managed CI (ephemeral runners, OIDC, autoscaling, sane defaults).

A quick, concrete baseline

Assumptions

Linux builds, EU (London) pricing, 1 vCPU / 2 GB RAM, 10,000 minutes (~166.7 hours).

Service	What you pay for	Ballpark cost for 10,000 min
ECS Fargate (1 vCPU, 2 GB RAM)	Raw compute only (you self-host the runner)	$9.46 in EU (London), or $8.23 in US-East
ECS Fargate (Graviton/ARM, 1 vCPU, 2 GB)	Raw compute only (you self-host the runner)	$7.57 in EU (London), or $6.52 in US-East
ECS Fargate Spot (Linux x86, 1 vCPU, 2 GB)	Interruptible compute (you self-host the runner)	$2.84 in EU (London), or $2.47 in US-East
AWS CodeBuild (general1.small)	Fully managed runner minutes	$50.00 ($0.005/min; first 100 min free)
GitHub Actions (Linux std)	GitHub-hosted runner minutes	$80.00 ($0.008/min)
GitLab SaaS (shared runners)	Shared runner minutes	$100.00 ($10 per 1,000 minutes)
Bitbucket Pipelines (extra minutes)	Additional pipeline minutes	$100.00 ($10 per 1,000 minutes)
CircleCI (Linux)	Credits → minutes (Performance plan)	$60.00 on Linux VM Medium (10 credits/min; credits $15 per 25,000 ⇒ ~$0.006/min). $30.00 on Docker Small (5 credits/min)
Azure Pipelines (Microsoft-hosted)	Parallel job, not per-minute	$40.00 for unlimited minutes after 1,800 free — buy 1 extra hosted parallel job ($40/mo)

But minutes aren’t the whole story The true cost of 10,000 build minutes

Data transfer & NAT

pulling repos and packages, docker layers, cache uploads. Use VPC endpoints for S3/ECR/CloudWatch and consider a package proxy (npm/pip/maven) to slash egress. You can run it in public subnet.

Caches & storage

BuildKit cache to ECR, language caches to S3. Keep short retention—caches grow fast.

Logs & metrics

CloudWatch ingestion + retention can quietly rival compute; cap retention to 7–14 days and sample.

Reliability

Fargate Spot saves the most but is preemptible—add automatic retries, idempotent pipelines, and a fallback to on-demand if the queue ages.

Product velocity

Managed CI buys you images, scaling, and fewer sharp edges. Your Fargate automation must recreate that "just works" feel (ephemeral runners, OIDC, autoscale, sane defaults). If it jut works to run tests.

Is $40 saved at 10,000 minutes justifiable—or just marginal?
At 10k, it’s mostly marginal: ≈ $40 vs CodeBuild (≈ $70 vs GitHub).
At 100k, it’s material: ≈ $405 (CodeBuild) / $705 (GitHub).
At 1M, it’s compelling: ≈ $4,054 / $7,054.

In my view, If you're building a Netlify or Vercel-style platform and can automate runner ops, ephemeral Fargate is dramatically cheaper per minute than most managed CI. The savings are real—but the non-minute costs and product trade-offs matter just as much.

If your CI bill dropped 60–90% with Fargate Spot, what’s the one blocker left?
At 10k minutes/month, is $40 saved marginal—or the start of a bigger shift? Why?
Would you trade occasional Spot retries for 5–10× cheaper minutes?
What’s your break-even minute count to justify self-hosted runners?

What do you think Choosing Fargate Spot over managed CI can justify any our your use case of CI? Let me know in the comments.

Progressive Rollouts AKA Canary Releases with Azure Front Door

Solo — Mon, 10 Mar 2025 10:18:54 +0000

While we want to ship new features, enhancements, and fixes to users with continuous integration and continuous delivery, as the number of users of your application increases, progressive rollouts help minimise risks and ensure a smooth user experience when releasing updates.

There are many ways to implement a progressive rollout, using Azure Front Door is one of the simplest and most suitable options for managing risks in small to medium applications. It provides an easy-to-configure strategy that balances stability with controlled feature releases.

Using Azure Front Door for Progressive Rollouts
Azure Front Door acts as a global load balancer and CDN, directing traffic across multiple backend pools based on routing rules. For progressive rollouts, In Front Door we can utilise few mechanisms based on our risk appetite.

Weighted Traffic Distribution

Azure Front Door allows traffic splitting between different backend versions using weighted routing. Example: 90% of traffic remains on stable version while 10% is routed to next-release version.

Geographic Rollouts

Deploy new features gradually to specific regions. Example: Start in Europe, then expand to North America.

Custom Rules with Azure Front Door Rules Engine

Create rules based on HTTP headers, cookies, or query parameters to control rollout logic. Example: Users with a "beta-user" cookie get routed to the new version.

Power Users vs. New Users Rollouts

Segment users based on experience level to control feature exposure. Example: Experienced power users in specific regions receive the new version first, while new users continue using the stable version to ensure a smooth onboarding experience.

1. Origin Group
Azure Front Door requires defining an origin group, which contains multiple origins (backend endpoints). In this setup:

The Stable Origin represents the existing production version, initially receiving most traffic.
The Next-Release Origin represents the new version, receiving a small portion of traffic that can be gradually increased.

Each origin within the group is assigned a
Each origin within the group is assigned a weight, dictating the proportion of incoming requests it should handle.

2. Configuring Weighted Traffic Distribution
Azure Front Door routes incoming requests to backends based on the configured weight values in the origin group settings. The load balancer evaluates these weights for each request and distributes traffic accordingly.

Weight-Based Load Balancing

If 90% weight is assigned to the stable backend and 10% to the new release, then out of 100 requests, roughly 90 will go to the stable backend and 10 to the new version.

These percentages can be modified as the rollout progresses.

*Each origin within the group is assigned a *

Azure Front Door Weight-Based Load Balancing
Priority Handling

Both origins in the group should have the same priority level to ensure they are load-balanced based on weight rather than failover behavior. If different priority levels are assigned, Azure Front Door will send all traffic to the higher-priority backend unless it becomes unhealthy.

3. Ensuring Session Consistency with Session Affinity
With this approach, enabling Session affinity on Front Door is critical in a progressive rollout to provide users a consistent experience. If session affinity is not enabled, users might experience. Switching between versions mid-session, leading to inconsistent behavior. Authentication issues if session tokens are not shared across instances.Summary: Azure Front Door Session Affinity

Azure Front Door uses cookie-based session affinity, leveraging managed cookies (ASLBSA and ASLBSACORS) that encode the origin URL. This mechanism differentiates users, even if they share the same IP address. Read more about Azure Front Door Session Affinity

Ensuring Session Consistency with Session Affinity

*Progressive Rollouts with Azure Front Door – Q&A *
Q: Will two users on the same public IP get different versions of the application?
A: Yes, because Azure Front Door does not use IP-based session persistence. Instead, it relies on cookies to maintain session affinity. Each user's browser session is assigned a unique session affinity cookie (FrontDoorAffinity), which determines which backend origin they will continue interacting with.

If session affinity is disabled or not functioning (e.g., due to caching issues), each new request is treated independently, and Azure Front Door routes traffic based on the weighted traffic distribution, which means different users even on the same IP may receive different versions of the application.

Azure Front Door does not use IP-based session persistence
Q: Why am I getting a different version of the application every time I refresh the page?
A: One of the following issues might be occurring:

Session Affinity is Disabled - Without the FrontDoorAffinity cookie, every request is independently routed, causing the backend selection to vary based on traffic weight distribution. Also check if the cookies are disabled in the browser. Read more about Azure Front Door Session Affinity
Cached Responses Prevent Cookie Assignment – If the response from the backend is cacheable (e.g., Cache-Control: public), Azure Front Door cannot attach the session affinity cookie, resulting in random backend selection.

Solution
Ensure that session affinity is enabled at the origin group level.
Check that the browser allows cookies and does not clear them between requests. Use "Cache-Control: no-store" in backend responses to prevent caching conflicts with session affinity.

Are We Asking the Wrong Question About AI Replacing Programmers?

Solo — Mon, 10 Mar 2025 10:17:06 +0000

Will AI can replace programmers ? The Real Question is will humans ever stop seeking more precise expression?

I believe we humans always strive to express ideas in a more precise form. This requires a deeper contextual understanding of the system. As computers advance, our ability to describe and manipulate systems grows deeper. In my opinion,

Role of Programming Languages in Methodological Expression

In my view, the book SICP: Structure and Interpretation of Computer Programs has proven that AI cannot replace programmers, even 40 years ago. This is, of course, a personal viewpoint, open to be proven wrong.

"First, we want to establish the idea that a computer language is not just a way of getting a computer to perform operations but rather that it is a novel formal medium for expressing ideas about methodology." — SICP

The Evolution of Computing and the Endurance of Technical Depth
The history of computing supports this notion. Abstraction layers have not rendered deeper technical understanding obsolete; they have, instead, co-evolved with fundamental advancements in computing.

Coexistence of High-Level and Low-Level Programming

Virtual machine (VM)-based programming languages like Java, C#, Python, and JavaScript have not replaced the need for system-level programming—instead, they coexist with low-level languages like C, C++, and Rust, which remain critical not only for performance but also for operating system kernels, system security, and hardware interaction.

Co-evolution of Programming Languages and Hardware Architectures.

As C and C++ pushed for more control and efficiency, ISAs evolved to unlock new possibilities, driving performance and scalability to levels once thought impossible. And as architectures like RISC streamlined instructions and CISC embraced complexity, compilers evolved to squeeze out every ounce of efficiency.

This dynamic is a feedback loop of innovation where software and hardware continuously push each other forward. In the end, it's this synergy that fuels the exponential growth of modern computing, reminding us that real breakthroughs happen when disciplines collide and evolve together.

The need to express precise low-level computation instructions ensures that ISAs—or something better—will keep evolving. As hardware demands shift with advancements in AI, quantum computing, and specialized accelerators, rigid instruction sets won’t be enough. The focus will move toward more flexible, efficient, and domain-specific ways to control hardware.

RISC-V is breaking away from traditional architectures like CISC due to the ongoing tension between complexity, efficiency, and the demand for flexibility in modern computing. CISC architectures (like x86) were designed to handle complex instructions within a single cycle, but this led to increased hardware complexity and less adaptability in a rapidly evolving tech landscape.

The Continued Importance of Foundational Knowledge in Circuit Design.

While VHDL and Verilog have streamlined digital circuit design, a deep understanding of digital logic remains essential. Engineers with strong fundamentals can debug efficiently, optimise for performance, and minimise resource usage in FPGA and ASIC designs. Knowledge of Boolean algebra, Karnaugh maps, and FSMs ensures better synthesis and hardware efficiency. Foundational skills also help in adapting to new technologies, bridging theory with real-world implementation. Despite advancements in HDL, digital logic remains the backbone of efficient and reliable circuit design.

Semiconductor Fundamentals Still Matter in Modern Digital Circuit Design.

While digital logic abstractions like logic gates and finite state machines have simplified circuit design, they fundamentally rely on the behavior of underlying semiconductor devices. A deep understanding of transistor-level physics remains essential for optimizing performance, power efficiency, and reliability. Technologies like CMOS, which dominate modern circuits, require knowledge of charge dynamics, leakage currents, and material properties to manage power consumption and thermal performance effectively. Advanced architectures such as FinFETs and GAAFETs, along with considerations of signal integrity and noise immunity, stem directly from semiconductor innovations rather than logical abstractions. Designers must also account for process variations and fabrication constraints that influence circuit behavior. As devices scale to the nanoscale, quantum effects further impact the behavior of logic gates, making semiconductor knowledge critical. Ultimately, mastering these fundamentals is vital for pushing the boundaries of digital design and achieving greater efficiency and performance.

Progressing Beyond Classical Electronics

While classical electronics and semiconductor physics form the backbone of modern technology, they haven’t limited innovation—they’ve propelled it. Engineers and scientists continue to push beyond traditional boundaries, diving into quantum mechanics to explore new computational possibilities and improve material properties. Advances in fabrication processes, such as EUV lithography and 3D chip stacking, have enabled more efficient, powerful, and compact devices. Meanwhile, quantum principles are increasingly influencing chip design, paving the way for quantum computing, spintronics, and neuromorphic architectures. By integrating classical principles with emerging technologies, the evolution of electronics continues to accelerate, redefining what’s possible in modern computing.

"The computer revolution is a revolution in the way we think and in the way we express what we think. The essence of this change is the emergence of what might best be called procedural epistemology—the study of the structure of knowledge from an imperative point of view, as opposed to the more declarative point of view taken by classical mathematical subjects." — SICP

Programming Languages as Tools for Procedural Epistemology
A programming language is a formal system for expressing procedural epistemology, providing a precise and structured way to define, manipulate, and execute knowledge. Unlike natural languages, it is rigorous and unambiguous, enabling clear representation of computational processes.

Unit Test Suit Scrutiny

Solo — Thu, 21 Oct 2021 16:26:16 +0000

Doing scrutiny with below points may help to maintain your unit test suite to make more sense

Developer experience

How easy it is to use the test suite for a developer in a busy day ?
Is your CI is good enough to execute your tests frequent enough ?

Test failures

Break a code unit and find which tests are failing. it should expose week points

Test case descriptions and error messages

how accurate are the Error messages on failure of test ? Are you able to find out what exactly broken just by looking at the message ?
How easy it is for you to understand what the code unit is responsible for just by looking at log of test suite execution ?

Test suite performance

Are there any tests taking unreasonable or significant amount of time ?
Consider skipping such tests and find the root cause of low performance of that test. This should help you to know the unknowns on which the implementation is relaying on.

Not Just Clean Code

Solo — Sat, 19 Dec 2020 12:53:15 +0000

The quote "Programs must be written for people to read, and only incidentally for machines to execute" By reading the book SICP or at least I believe it has a deeper meaning than readability of the code.

If we clearly read the actual phrases from SICP. They were talking about creating abstractions that hide details of the complexity of machine instructions which allows actual code looks closer to problem domain.

First, we want to establish the idea that a computer language is not just a way of getting a computer to perform operations but rather that it is a novel formal medium for expressing ideas
about methodology. Thus, programs must be written for people to read, and only incidentally for machines to execute.

A domain-specific language is something that can be understood and can be used as a medium of precise communication between people working in that domain is a higher-level abstraction that can be easily understood without thinking about how the computer manages memory and schedules the time of CPU to execute instructions of multiple programs in an operating system.

Flush those first bytes

Solo — Thu, 17 Sep 2020 08:40:23 +0000

series: strategic web performance

This is my first post from strategic web performance series where I publish my analysis and some strategies based on my understanding which may help other to understand and develop web applications by keeping performance in mind.

This post focuses on explaining the need of flushing the initial and critical HTML content to improve the server response times.

Let us start by understanding the journey of the page response from the server through telecommunications network, then we can think about strategies we can apply to design and applications with improved performance.

Browser sends request to the server and will be waiting for the server to respond.
If Server respond with HTML document after constructing complete document -- this will take several milli seconds or even more especially when construction of some parts of it require high computation or dependency on other systems.

Overlap

We will need to start flushing the meaningful HTML content to the stream as soon as it is available.

Then we will get an overlap of server time and network time. as when server is busy constructing remaining part of the page the response is already on the wire.