DEV Community: Ahmed Hinedy

The Hidden Cost of “Best Practices” in Frontend Systems

Ahmed Hinedy — Thu, 12 Feb 2026 10:55:10 +0000

A decision framework for adopting, keeping, or retiring frontend practices in systems under change.

1. Best practices aren’t stupid. but they age

Why following them is necessary early, and insufficient later

Best practices are taught for a reason.

When you’re early in your career. or new to a codebase. they’re often the fastest way to become effective. They compress hard‑won lessons into usable rules. They reduce obvious mistakes. They help you ship something reasonable before you fully understand the system you’re working in.

Learning and applying best practices is often the shortest path to competence.

Learning when they no longer fit is what comes later.

That second skill isn’t rebellion. It’s not contrarianism. It’s what emerges once you’ve seen the same practice succeed, struggle, and eventually get in the way across different systems.

The problem isn’t that these practices are wrong.

Frontend best practices rarely fail because they’re incorrect. they fail because the system they were optimized for no longer exists.

2. The optimization mismatch

Review-time clarity versus change over time

This isn’t about taste, preference, or engineers disagreeing about style. It’s about what different systems are optimized for.

Many frontend best practices are designed to optimize for moments of inspection:

clarity during code review
visible consistency across files and teams
confidence that the current state is "correct"

These are real needs. They reduce friction and make systems easier to reason about.

Frontend products, however, are governed by something else entirely:

long stretches of continuous change
requirements that evolve faster than documentation
UX and workflows that are reshaped incrementally

Most frontend best practices are optimized for how code looks at review time.
Frontend products are governed by how code behaves over months of change.

When those optimization targets diverge, tension is inevitable. Practices rarely fail loudly. they simply stop fitting the system they’re embedded in.

When practices optimized for inspection meet systems governed by change, the stress shows up first at the edges.

3. Why frontend absorbs change differently

Where product churn concentrates first

Frontend sits at an unstable intersection.

It’s where product decisions land, design iterates, backend inconsistencies surface, and edge cases become user-visible.

UI boundaries rarely stay fixed. Flows evolve. Screens merge. State that once felt local needs to be shared. Components quietly turn into systems.

As a result, frontend absorbs churn earlier and more often than most layers.

Practices that resist change. or assume stable boundaries. fail fastest here. This isn’t accidental. It’s structural.

4. How reasonable practices turn into liabilities

When decisions harden into constraints

Most frontend practices don’t start as dogma. They start as solutions.

A team hits a real problem. unreadable code, regressions, slow reviews, duplicated logic. and introduces structure to relieve that pain. In that moment, the decision is usually correct.

Many frontend architecture decisions don’t fail immediately. They fail once the original context disappears.

Early on, shared understanding substitutes for documentation. The team is small, the constraints are obvious, and everyone knows why certain choices exist. Patterns are applied with judgment because the reasoning is still alive.

As the product evolves, that context fades. New engineers copy patterns without knowing which problems they were meant to solve. The code still works, but the assumptions behind its structure are no longer visible.

Eventually, someone asks: “Why is this done this way?” And no one can answer.

At that point, the practice hasn’t failed. it has hardened. The system has changed, but the constraint remains. Change becomes slower, estimates become conditional, and teams start navigating structure instead of solving user problems.

The issue isn’t that the original decision was wrong. It’s that it stopped being treated as a decision at all.

5. The common failure pattern (tool-agnostic)

Why this repeats across frameworks and eras

This isn’t about frameworks or trends. The tools change every few years. The failure mode doesn’t.

The recurring issue:

Early abstraction hardens assumptions
Structure is introduced to reduce ambiguity and make the system legible. In the moment, this is usually the right call.
Product evolution invalidates those assumptions
Requirements shift, flows merge, and edge cases accumulate. The system changes in ways the original abstraction didn’t anticipate.
The abstraction remains because removal is expensive
By the time the mismatch is visible, the structure is deeply embedded. Changing it risks regressions, rewrites, and coordination overhead.

The result isn’t immediate failure. It’s slow friction.

Teams spend more time navigating structure than solving user problems. The issue isn’t the tools. it’s what the system was designed to optimize.

6. Quality vs adaptability

Why clean code can still be expensive to change

This is where many frontend teams get stuck.

Practices that once reduced chaos start being used as proof of quality. Clean structure, strict rules, and strong guardrails become proxies for correctness.

In frontend systems, quality only reveals itself over time. when requirements shift, flows merge, and assumptions quietly break.

Some practices improve readability and safety today while increasing fragility tomorrow. They make the current state feel orderly, but raise the cost of the next meaningful change.

This is why a frontend codebase can look immaculate and still feel slow to work in.

Good frontend code isn’t just easy to read or hard to misuse.

It’s code that tolerates change without forcing rewrites, architectural debates, or cascading refactors every time the product evolves.

Adaptability isn’t a lack of discipline.

It’s a different definition of quality. one that accounts for time, churn, and uncertainty.

7. This is not an argument against standards

Why ownership matters more than rigidity

Standards matter. Without them, teams drift and duplicate effort.

The problem isn’t standards. it’s standards that can’t be renegotiated.

The opposite of rigid best practices isn’t chaos. It’s active ownership.

Healthy teams treat practices as agreements: revisable, removable, and owned.

8. A better definition of “best practice”

A decision filter, not a checklist

Instead of a checklist, treat best practices as a filter.

A frontend practice is “best” if it lowers the total cost of the next change.

Not just the next pull request. the next product adjustment or shift in direction.

Helpful tests:

Does it survive product churn?
Can a new hire understand why it exists?
Can it be removed without destabilizing the system?

If not, the practice may still help. but it isn’t universally best.

9. Renegotiation is the work

Why maturity shows up in what teams revisit

This doesn’t produce a new checklist. It changes how teams relate to the practices they already have.

Useful questions:

Which practices exist only because no one has questioned them recently?
What would break first if the roadmap doubled?
What would you remove to make onboarding faster?

These questions surface hidden costs without prescribing solutions.

The best frontend teams don’t follow best practices blindly. They continuously renegotiate them as the product evolves.

That renegotiation isn’t inconsistency. it’s professionalism in a system defined by change.

Frontend best practices don’t fail because teams are careless. They fail when practices stop being treated as decisions and start being treated as facts.

Knowing when that shift has happened. and having the judgment to respond. is one of the most valuable frontend skills there is.

How We Cut Our React App's Bundle Size in Half

Ahmed Hinedy — Sun, 23 Feb 2025 12:11:35 +0000

Our React application's bundle size had reached 1.54MB (gzipped). The app worked fine, but loading times kept increasing. This post explains the steps we took to reduce the bundle size in half and its impact on performance.

Understanding the Problem

Lighthouse and Chrome DevTools painted a clear picture:

Pages took too long to become interactive
Mobile users faced significant load delays
Users downloaded and parsed more code than they needed for basic interactions

The Optimization Strategy

1. Route-Based Code Splitting

In our app using createBrowserRouter from React Router 6, we implemented route-based code-splitting to defer code loading until a user navigates to the relevant route:

import React, { lazy, Suspense } from "react";
import { createBrowserRouter, RouterProvider } from "react-router-dom";

const LazyLoadedPage = lazy(() => import("./LazyLoadedPage"));

const router = createBrowserRouter([
  {
    path: "/feature",
    element: (
      <Suspense fallback={<div>Loading...</div>}>
        <LazyLoadedPage />
      </Suspense>
    ),
  },
]);

2. Strategic Library Loading

Heavy dependencies don't need to load immediately. The key is to move imports inside the functions that use them:

// Before - importing at the top level
import { PDFDocument } from "@react-pdf/renderer";
import * as XLSX from "xlsx";

// After - inline imports when needed
async function generatePDF(data) {
  const { PDFDocument } = await import("@react-pdf/renderer");
  // PDF generation logic
}

async function exportToExcel(data) {
  const XLSX = await import("xlsx");
  // Excel export logic
}

We applied this pattern to several large dependencies:

PDF generation (@react-pdf, ~450KB) → loads only during PDF exports
Spreadsheet functionality (xlsx, ~214KB) → waits for export operations
Date handling → moved to lighter alternatives for common operations

Other common libraries worth deferring in React apps:

Rich text editors (draft-js, quill) → load when editing starts
Chart libraries (chart.js, recharts) → load when viewing data visualizations
Complex UI components (@mui/x-data-grid, ag-grid) → load when data tables mount
Image manipulation (sharp, jimp) → load when editing starts

The pattern remains consistent: identify when users need the functionality, and load it at that moment. This approach is particularly helpful during initial page loads.

3. Measurement-Driven Optimization

Three tools drove our decisions:

source-map-explorer analyzed dependency sizes
Chrome DevTools' Performance tab showed load behavior
Regular Lighthouse audits tracked improvements

The Results

Metric	Improvement
Main Bundle Size	-49.5%
First Contentful Paint	+28.5%
Total Blocking Time	+20%
Speed Index	+46.4%

Key Learnings

Target the right components for code splitting. Focus on larger features that deliver meaningful impact.
Performance tools reveal opportunities you might miss otherwise. Regular bundle analysis became essential to our process.
Performance optimization doesn't stop. Each improvement reveals new opportunities.

Maintaining Performance

Three practices keep our bundle size in check:

Regular bundle analysis during development
Performance budgets for new feature development, including:
- Maximum initial bundle size: 500KB after gzip
- Route-level budgets: 200KB per lazy-loaded route
- Time-to-Interactive budget: < 3.5s on 4G connections
- First Contentful Paint target: < 1.8s
- Third-party script size limit: 100KB total
- Image size budgets: 200KB max per image, WebP format required
- These budgets are enforced through:
- webpack configuration using performance.hints
- size-limit checks in CI
- Lighthouse performance scoring thresholds
Automated performance testing in our CI pipeline using:
- Lighthouse CI for performance metrics
- Bundle size tracking with bundlewatch
- Jest Timer snapshots for runtime performance
- webpack-bundle-analyzer in build pipelines
- GitHub Actions workflows triggered on PR deployments

Conclusion

Performance optimization delivers real user value. We reduced our bundle size by carefully analyzing and making targeted improvements, improving every key performance indicator.

Three steps can start your optimization journey:

Measure your current state
Split code strategically
Monitor consistently

Every kilobyte impacts user experience. Start measuring yours today.

HTTP Cookies Demystified: A Web Developer's Guide

Ahmed Hinedy — Sun, 08 Sep 2024 21:49:47 +0000

Understanding HTTP Cookies in Web Development

In this article, we'll explore the ins and outs of HTTP cookies, their significance in web development, and how they compare to alternatives like localStorage. Whether you're new to web development or looking to refine your skills, understanding cookies is key to building robust, efficient, and secure web applications.

HTTP cookies are small pieces of data stored on a user's device by the web browser that can be used for managing user sessions, tracking user behavior, and enhancing the overall user experience.

Cookies are regular headers. On a Request, they are stored in the Cookie header. On a Response they are in the Set-Cookie header

Cookies vs localStorage

When it comes to client-side storage, developers often choose between cookies and localStorage. Let's compare these options:

Localstorage is designed to be accessible by javascript, which makes it convenient for storing client-side data. However, this accessibility comes with a significant drawback: it doesn't provide any protection against Cross-Site Scripting (XSS) attacks. There are multiple ways an attacker could exploit an XSS vulnerability to access data stored in localStorage.

On the other hand, cookies have security flags that make them more secure for storing sensitive data:

HttpOnly flag prevents client-side JavaScript from accessing the cookie, mitigating XSS risks.
Secure flag ensures that the browser only transfers the cookie over SSL, protecting against man-in-the-middle attacks.
SameSite flag helps prevent Cross-Site Request Forgery (CSRF) attacks by ensuring that the cookie is only sent to the origin site.

So cookies are a more secure choice for storing authentication data. However, localStorage can be more appropriate for storing non-sensitive client-side data like user preferences or cached content.localStorage offers larger storage capacity (usually 5-10MB compared to 4KB for cookies) and easier JavaScript access, making it suitable for improving application performance and user experience in scenarios where the enhanced security of cookies isn't necessary.

How does Cookies Work

Setting the Cookie: When a user visits a website, the backend server can send a cookie to the browser. This is done via the Set-Cookie header in the HTTP response.
Storing the Cookie: The browser automatically stores these cookies. As a developer, you don't need to write any client-side code to save the cookie.
Accessing Cookies: On the client side, you can access some of the cookies (not **HttpsOnly) using document.cookie. For example:
```
console.log(document.cookie);
// Output: "username=John Doe; session_id=1234567890"
```
Sending Cookies: The browser automatically sends all relevant cookies (based on domain and path) with every request to the server. This includes regular page loads, AJAX calls, and resource requests like images or scripts from the same domain.

However, there's an important exception to note: cookies are not automatically sent with cross-origin POST requests. To include cookies with cross-origin requests, you need to enable the withCredentials option in your client-side API request headers, as shown

axios.post('https://api.example.com/data', {
  key: 'value'
}, {
  withCredentials: true 
})
.then(response => console.log(response))
.catch(error => console.error('Error:', error));

Keep in mind that this requires the server to respond with the appropriate CORS headers, including Access-Control-Allow-Credentials: true. If the server does not allow credentials, the browser will still prevent the inclusion of cookies, even if you set withCredentials: true on the client side.

Cookie Attributes

Cookies can have various attributes that control their behavior:

Expires: Determines how long the cookie should last.
Domain: Specifies which domains the cookie is valid for.
Path: Limits the cookie to a specific path on the server.
Secure: Ensures the cookie is only sent over HTTPS.
HttpOnly: Prevents JavaScript from accessing the cookie.
SameSite: Controls how the cookie is sent with cross-site requests.

IETF Standards provide the definitive guide to cookies.
Learn more.

Setting Cookies

The method of setting a cookie depends on the context:

HTTP Headers

This is the common server-side approach. Servers send a Set-Cookie header in the response, containing cookie details such as name, value, and various attributes like expiry time and domain. This is typically done in server-side languages like PHP, Python, or JavaScript(Express).

app.get('/set-cookie', (req, res) => {
  res.setHeader('Set-Cookie', [
    'user=John; HttpOnly; Secure; SameSite=Strict',
    'session=1234567890; HttpOnly; Secure; SameSite=Strict; Max-Age=3600'
  ]);
  res.send('Cookies are set');
});

JavaScript

JavaScript, through the document.cookie property, allows you to set cookies directly on the client-side.

 document.cookie = "username=John Doe; expires=Thu, 18 Dec 2023 12:00:00 UTC; path=/";

However, this approach has limitations as it cannot set certain attributes like HttpOnly which are crucial for security.

You can refer to MDN's Extensive documentation on cookies for more details and examples.