DEV Community: i am message

Component Architecture: Co-location, Composition, and Separation of Concerns, Different soups...

i am message — Fri, 16 Oct 2026 07:35:56 +0000

One thing I think frontend engineers need to be more deliberate about is how we apply software design principles when building component-based applications.

There is a tendency to treat co-location, separation of concerns, reusability, and Atomic Design as though they all mean the same thing: breaking code into smaller pieces and organizing those pieces into folders. They do not. Each principle addresses a different problem, and misunderstanding the distinction can lead to abstractions that look reusable on the surface but become increasingly difficult to maintain.

1. Co-location is about proximity, not combining everything into one component

Co-location means keeping code close to the part of the application it relates to. The underlying idea is that code that changes together should generally be located together.

For example, suppose a feature has a component, its validation schema, feature-specific hooks, helper functions, and tests. Keeping those things within the feature's module makes it easier to understand, modify, and maintain that feature without navigating an unrelated collection of global folders.

But co-location does not mean combining all those responsibilities into one component or file.

Consider a password input that is used only by an authentication feature. It makes sense to keep its implementation close to the authentication feature while it remains specific to that context. If it eventually becomes useful across multiple features, we can extract it into a shared UI module.

The important distinction is that co-location determines where code belongs; separation of concerns determines what responsibilities that code should have.

These principles complement each other. They do not compete.

2. Separation of concerns is about responsibility

Separation of concerns means dividing a system into units with clearly defined responsibilities. A component should have a coherent purpose and a contract that makes its behavior understandable.

Consider a generic input component. Its responsibility might include rendering a native input, forwarding standard input attributes, supporting accessibility, and applying the design system's styling.

Now imagine extending that same component to handle all of the following:

Standard text inputs.
Password inputs with visibility toggles.
OTP inputs with multiple digit slots.
Grouped inputs with prefixes, suffixes, or multiple fields.
Input-specific validation, formatting, keyboard navigation, and specialized error handling.

We could expose a type prop and several additional flags, then use conditional statements to decide which implementation to render.

That might appear efficient because everything is available through one component. However, the component is gradually taking responsibility for several different interaction patterns, each with its own state, behavior, accessibility requirements, and testing needs.

The problem is not simply that the file has become large. The deeper problem is that its interface and implementation are now responsible for too many distinct concerns.

A change to OTP navigation should not require us to reason about password visibility. A change to password visibility should not risk breaking the behavior of an ordinary text field.

A shared component should provide a stable foundation, not become a container for every component that happens to involve an input.

3. Atomic Design helps us reason about the level of abstraction

Atomic Design provides a useful vocabulary for organizing interfaces into atoms, molecules, organisms, templates, and pages.

A basic input can be treated as an atom: a foundational UI primitive. A form field combining a label, input, and error message can be treated as a molecule. A larger form section combining several fields, validation feedback, and submission controls might be an organism, depending on its scope and complexity.

However, Atomic Design is a mental model, not a rigid classification system. The correct level of abstraction depends on what a component does, what it depends on, and how it is used.

For example:

Input: A generic, reusable primitive with a clearly defined contract.
PasswordInput: A specialized component that composes the generic input with password-specific behavior, such as a visibility toggle.
OTPInput: A specialized component that manages multiple digit positions, focus movement, and keyboard interactions.
InputGroup: A composition that combines an input with adjacent elements, such as a prefix, suffix, or action.
FormField: A higher-level composition that associates a control with its label, description, and validation feedback.

These are not necessarily five atoms. They operate at different levels of abstraction.

The goal is not to create a separate component for every possible variation. The goal is to ensure that each abstraction represents a coherent responsibility and that higher-level components build on lower-level primitives rather than forcing every behavior into one primitive.

4. Composition is how we build specialized behavior without bloating foundational components

Composition allows us to build complex interfaces by combining smaller components with well-defined responsibilities.

Instead of making the generic Input component understand every possible input pattern, we can build specialized components around it.

For example:

function PasswordInput(props: InputProps) {
  const [visible, setVisible] = useState(false);

  return (
    <div className="password-input">
      <Input
        {...props}
        type={visible ? "text" : "password"}
      />

      <button
        type="button"
        onClick={() => setVisible((value) => !value)}
        aria-label={visible ? "Hide password" : "Show password"}
      >
        {visible ? <EyeOff /> : <Eye />}
      </button>
    </div>
  );
}

This is a simplified illustration, but it demonstrates the architectural distinction: the generic input remains responsible for rendering an input, while the password component owns the additional password-specific interaction.

The OTP input can have its own implementation for digit management, focus movement, and keyboard behavior. It may reuse the same design tokens, styling conventions, and lower-level primitives without forcing the generic input to implement OTP-specific logic.

Likewise, an input group can compose a generic input with prefixes, suffixes, or action buttons.

The objective is not to eliminate conditional rendering. Conditional rendering is perfectly reasonable when it expresses a genuine variation within a component's responsibility. The problem arises when a component becomes a large conditional dispatcher for unrelated behaviors.

Composition gives us a way to reuse implementation without coupling every consumer to every other use case.

React supports this through component nesting, children, and explicit props. A component can provide a structural foundation while allowing its consumer to determine what content or specialized component belongs inside it.

5. Reusability does not mean putting every use case behind one API

A common architectural mistake is assuming that if two components share a visual element, they should necessarily be represented by one highly configurable component.

But visual similarity does not always imply behavioral similarity.

A password input, an OTP input, and a grouped input all involve inputs, but their interaction models differ substantially. Their shared foundation does not justify merging their responsibilities.

A better approach is to reuse at the appropriate level:

Reuse design tokens for consistent spacing, typography, colors, and sizing.
Reuse generic primitives for common rendering and styling.
Compose specialized components from those primitives where it makes sense.
Keep feature-specific behavior within the feature that owns it.
Promote a feature-specific abstraction into a shared module when there is a genuine need for broader reuse.

This also avoids premature abstraction. A component does not need to become globally available simply because it has been written once. Reuse should emerge from a clear contract and a real need, rather than from the desire to eliminate every instance of duplication.

6. Component boundaries and code splitting are related, but they are not the same thing

There is another important distinction here.

Keeping unrelated implementations together can make architectural boundaries harder to understand and maintain. It can also contribute to unnecessarily large bundles when the module dependency graph causes code to be included together.

However, putting components in separate files does not automatically guarantee code splitting. Modern bundlers determine chunks from the import graph, build configuration, and dynamic import boundaries.

If an OTP implementation is only needed on a particular route, a deliberate dynamic import or lazy-loaded feature boundary may allow that code to be loaded separately. Merely extracting OTPInput into its own file does not guarantee this result.

The architectural benefit of separation is that it gives us clearer units of responsibility and makes independent loading, testing, and evolution easier to reason about. The bundler still needs the appropriate module boundaries to produce the desired output.

We should avoid confusing a good component architecture with an automatic performance optimization.

7. Why this matters even more in the AI era

AI can generate components, refactor files, create abstractions, and reproduce patterns very quickly. But generating code that works is not the same as designing a system that remains maintainable as it grows.

If we ask an AI tool to build a reusable input component without defining the intended boundaries, it may produce a single component with a long list of props, conditional branches, and flags to accommodate every foreseeable use case.

That implementation may work. It may even look elegant in a small example. But it can introduce hidden coupling, unclear contracts, and unnecessary complexity as more requirements are added.

The problem is not that AI inherently produces poor architecture. It is that AI needs architectural constraints and evaluation criteria, just as a human engineer does. Without them, local convenience can take precedence over the long-term structure of the application.

This is where engineering principles become more valuable, not less.

A design system should do more than standardize colors, spacing, typography, and component appearance. It should also establish rules for component responsibility, composition, dependency direction, state ownership, and reuse.

For example, a design system should make the following expectations explicit:

Foundational UI primitives should remain focused on their core responsibilities.
Specialized interactions should be composed from existing primitives where appropriate.
Feature-specific logic should remain close to the feature that owns it.
Shared components should expose clear, strongly typed contracts.
New abstractions should be introduced when they address a real need, not merely to make code appear more reusable.
Generated code should be reviewed for architectural fit, not only whether it renders correctly.

These rules give an AI coding tool a set of constraints against which to evaluate its own implementation. They also make code review more objective because the team can assess whether the implementation follows an agreed architectural model rather than relying solely on individual preferences.

Conclusion

Good component architecture shouldn't be about creating the smallest possible components or the fewest possible files. It should be about finding the right boundaries between responsibilities.

Co-location tells us where related code should live. Separation of concerns tells us which responsibilities should remain distinct. Atomic Design gives us a vocabulary for understanding levels of UI abstraction. Composition gives us a mechanism for building richer interfaces from focused components.

When these principles are applied together, a design system becomes more than a collection of reusable UI elements. It becomes an architectural contract that helps developers and AI tools build software that can evolve without accumulating unnecessary complexity.

Pixels, Tokens, and Grids: Speaking the Same Language in Design and Code

i am message — Tue, 02 Sep 2025 17:44:51 +0000

Design and development handoff is one of the most critical points in a product’s lifecycle. A design may look clean and polished in Figma, Sketch, or Adobe XD, but if the specifications handed off to developers are inconsistent—such as using fractional pixel values (13.7px, 22.4px, 47.2px) or icon sizes with decimals—it introduces friction, implementation errors, and long-term scalability problems.

This article explains why consistency in values matters, the technical issues caused by decimals and arbitrary sizing, and how they impact accessibility, developer experience, and the scalability of a design system.

The Role of Design Tokens

Modern front-end development relies heavily on design tokens. Tokens are named values representing design decisions:

Spacing: 4px, 8px, 16px, 32px
Typography: 12px, 14px, 16px, 20px, 24px
Colors: primary-500, neutral-200, etc.
Icons & Radius: multiples of 4 or 8

Tokens create a shared language between design and code. They ensure consistency, make global updates simple (e.g., updating brand colors or scaling typography), and eliminate arbitrary one-off values.

👉 When a designer specifies 23.7px padding or a 13.5px font size, it breaks this system. Developers cannot map those values to tokens and must either round them (losing fidelity) or create exceptions (increasing inconsistency).

Why Decimal Pixels Don’t Work

1. Rendering Inconsistency Across Devices

Web and native platforms rely on device-independent pixels (dp in Android, pt in iOS).
A fractional value like 13.5px doesn’t translate well into these units; it gets rounded differently depending on device pixel ratio (DPR).
Result: Slight misalignments, blurred icons, and inconsistent spacing across devices.

2. Icon Sharpness and Pixel Grid

Icons need to align perfectly to the pixel grid to render sharply.

A 23.7px icon will be anti-aliased (blurred edges).
Exporting icons at consistent whole sizes (16, 20, 24, 32px) ensures sharpness on all screens.

3. Scalability and Maintainability

Arbitrary decimals lead to CSS bloat: 23.7px, 47.2px, 11.3px all become unique rules.
This breaks the principle of reusable tokens → every new screen introduces exceptions.
When scaling designs (responsive layouts, theming, accessibility), inconsistencies multiply.

4. Cross-Platform Alignment

A design system must work across Web, iOS, and Android.

On iOS, pt values are integers.
On Android, dp/sp values are integers.
On Web, CSS pixels are integer-aligned per DPR.
Decimal values simply don’t exist natively, so developers must round → making the original design intent meaningless.

Accessibility Considerations

Accessibility (a11y) is often overlooked in the design-to-code pipeline, but inconsistent or fractional values can degrade accessibility in subtle but important ways:

Legibility of Text

Fonts sized at decimals (e.g., 13.5px) may render inconsistently across platforms.
On some browsers/devices, this causes text to appear slightly thinner or blurrier, impacting readability — especially for users with visual impairments.

Touch Targets and Hit Areas

Accessibility guidelines (WCAG, Apple HIG, Material Design) require minimum touch targets of 44×44px or 48×48dp.
A button with fractional padding or inconsistent sizing may fall short of these thresholds, making it harder for users with motor disabilities to tap reliably.

Zoom and Scaling

When users zoom or enable larger text settings, fractional values often compound rounding errors, leading to misaligned UI elements.
Sticking to consistent integer-based tokens ensures interfaces scale predictably.

👉 In short, clean integer-aligned values improve readability, usability, and compliance with accessibility standards.

Developer Experience Considerations

From the developer’s perspective, inconsistent values directly impact workflow efficiency, maintainability, and scalability:

Implementation Friction

Developers using frameworks like Tailwind, Chakra, or Material UI rely on token scales.
If a design specifies 13.7px spacing, there’s no matching class/token. The developer must approximate, hardcode, or create an exception → wasting time and introducing inconsistencies.

Code Bloat

Every arbitrary value creates a one-off CSS rule. Over time, this bloats the codebase and makes styles harder to manage.
Token-based systems, by contrast, enable lean, reusable CSS.

Onboarding New Developers

With inconsistent values, new team members struggle to understand what’s “standard” vs. what’s an exception.
With token-based, whole-number scales, the rules are predictable → reducing onboarding friction.

Collaboration Between Teams

Consistency reduces “pixel pushing” back-and-forth between designers and developers.
Developers can implement designs faster with fewer deviations, and QA testers spend less time verifying visual alignment.

👉 In short, inconsistency slows developers down and creates technical debt, while consistency accelerates delivery and preserves design intent.

The Power of Grid Systems

Most design systems advocate for the 4px or 8px grid system.

Keeps spacing, typography, and components consistent.
Scales well across screen sizes and densities.
Simplifies design handoff because designers and developers both speak the same scale.

Best Practices for Designers

Use design tokens only → stick to predefined scales.
Avoid fractional values → round to the nearest token value.
Export icons in whole pixel dimensions → 16px, 20px, 24px, etc.
Stick to a type scale → 12, 14, 16, 20, 24 (no decimals).
Collaborate with developers early → agree on token definitions to prevent drift.

Conclusion

Decimals and inconsistent values may seem harmless in design tools, but they cause real technical problems during implementation: blurry icons, rendering inconsistencies, bloated CSS, inaccessible touch targets, and broken design tokens.

By adhering to whole-number values aligned with design tokens and grid systems, designers and developers can ensure consistency, accessibility, scalability, and a smoother design-to-code workflow.

Design is not just about how it looks in Figma—it’s about how well it translates into code and scales across platforms. And that translation depends heavily on consistency, precision, and respect for the system.

📘 Essential Front-End Development Rules for Clean, Reusable Code

i am message — Fri, 22 Aug 2025 14:06:56 +0000

As frontend developers, one of the easiest mistakes we make early on is writing messy, inconsistent code, especially when it comes to styling. Between utility-first frameworks like Tailwind, component libraries like Ant Design, and old standbys like Bootstrap, it's easy to get carried away mixing tools or reinventing styles that already exist.

The key to writing clean, maintainable, and reusable code is discipline. Below are four fundamental rules that can help new frontend developers stay consistent and avoid common pitfalls.

Rule 1: Stick to One Library 🎯

If you've chosen a UI library, whether it's Bootstrap, Tailwind CSS, Shadcn (which builds on Tailwind), or Ant Design, commit to it.

Why This Matters:

Mixing multiple libraries creates unnecessary bloat and inconsistencies
A single library ensures your design system is predictable and your project remains easy for others to read and maintain
Most modern libraries are powerful enough to handle 90% of your use cases, so learn their feature set thoroughly before bringing in alternatives

Implementation:

Choose one styling framework as your primary solution
Resist the temptation to mix multiple frameworks unless absolutely necessary
Maintain consistency across your entire project

💡 Tip: Explore the documentation deeply. Chances are, the utility or component you're about to write already exists in your chosen library.

Rule 2: Exhaust the Utility Classes Before Writing Custom Styles 🔧

Many beginners jump straight into writing new CSS rules for simple tweaks like spacing, typography, or colors. This leads to duplicated styles and harder-to-maintain code.

Instead, trust the utility classes your library provides.

Benefits:

Rapid Development: Pre-built utilities speed up styling
Design System Consistency: Utilities enforce design constraints
Responsive Design: Most utilities include responsive variants
Reduced CSS Bloat: No duplicate or conflicting custom styles

Example:

Instead of writing:
❌ Bad:

.tiny-link { 
  font-size: 12px; 
  font-weight: bold; 
}

<a class="tiny-link">Read more</a>

✅ In Tailwind, you’d just use:

<a class="text-xs font-bold">Read more</a>

Using utilities keeps everything consistent, semantic, and maintainable.

Rule 3: Trust the Library Before Adding Custom Props or Overrides 🤝

Libraries and HTML elements already provide sensible defaults and properties. Before you override them with custom props or inline styles, see if the library can handle it first.

Key Principles:

Use library-provided components and their intended APIs
Prefer library's sizing, spacing, and layout systems
Utilize built-in responsive breakpoints and design tokens
Add custom modifications only when library solutions are insufficient

Example 1: Button Component

❌ Bad - Custom props that fight the system:

interface BadButtonProps {
  children: React.ReactNode;
  width?: number;
  height?: number;
  backgroundColor?: string;
  textColor?: string;
  borderRadius?: number;
  fontSize?: number;
  padding?: string;
  onClick?: () => void;
}

const BadButton: React.FC<BadButtonProps> = ({
  children,
  width = 120,
  height = 40,
  backgroundColor = '#3b82f6',
  textColor = '#ffffff',
  borderRadius = 8,
  fontSize = 14,
  padding = '8px 16px',
  onClick
}) => {
  return (
    <button
      onClick={onClick}
      style={{
        width: `${width}px`,
        height: `${height}px`,
        backgroundColor,
        color: textColor,
        borderRadius: `${borderRadius}px`,
        fontSize: `${fontSize}px`,
        padding,
        border: 'none',
        cursor: 'pointer'
      }}
    >
      {children}
    </button>
  );
};

// Usage creates inconsistency
<BadButton width={200} height={50} backgroundColor="#ef4444">
  Delete
</BadButton>

✅ Good - Extends HTML button with design system variants:

import { cn } from "@/lib/utils";
import { cva, type VariantProps } from "class-variance-authority";

const buttonVariants = cva(
  "inline-flex items-center justify-center rounded-md text-sm font-medium transition-colors focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-ring disabled:opacity-50 disabled:pointer-events-none",
  {
    variants: {
      variant: {
        default: "bg-primary text-primary-foreground hover:bg-primary/90",
        destructive: "bg-destructive text-destructive-foreground hover:bg-destructive/90",
        outline: "border border-input hover:bg-accent hover:text-accent-foreground",
        secondary: "bg-secondary text-secondary-foreground hover:bg-secondary/80",
        ghost: "hover:bg-accent hover:text-accent-foreground",
        link: "underline-offset-4 hover:underline text-primary"
      },
      size: {
        default: "h-10 py-2 px-4",
        sm: "h-9 px-3 rounded-md",
        lg: "h-11 px-8 rounded-md",
        icon: "h-10 w-10"
      }
    },
    defaultVariants: {
      variant: "default",
      size: "default"
    }
  }
);

interface ButtonProps
  extends React.ButtonHTMLAttributes<HTMLButtonElement>,
    VariantProps<typeof buttonVariants> {}

const Button: React.FC<ButtonProps> = ({
  className,
  variant,
  size,
  ...props
}) => {
  return (
    <button
      className={cn(buttonVariants({ variant, size, className }))}
      {...props}
    />
  );
};

// Usage follows design system
<Button variant="destructive" size="lg" className="w-full">
  Delete Account
</Button>

Example 2: SVG Icon Component

❌ Bad - Custom props that bypass HTML attributes:

interface BadIconProps {
  width?: number;
  height?: number;
  color?: string;
  strokeWidth?: number;
  className?: string;
}

const BadTrashIcon: React.FC<BadIconProps> = ({
  width = 24,
  height = 24,
  color = '#000000',
  strokeWidth = 2,
  className
}) => {
  return (
    <svg
      width={width}
      height={height}
      className={className}
      viewBox="0 0 24 24"
      fill="none"
      xmlns="http://www.w3.org/2000/svg"
    >
      <path
        d="M3 6h18M19 6v14a2 2 0 01-2 2H7a2 2 0 01-2-2V6m3 0V4a2 2 0 012-2h4a2 2 0 012 2v2"
        stroke={color}
        strokeWidth={strokeWidth}
        strokeLinecap="round"
        strokeLinejoin="round"
      />
    </svg>
  );
};

// Usage creates inconsistent styling
<BadTrashIcon width={32} height={32} color="#ef4444" strokeWidth={3} />

✅ Good - Extends SVG element and uses currentColor:

import { forwardRef } from "react";

interface IconProps extends React.SVGProps<SVGSVGElement> {}

const TrashIcon = forwardRef<SVGSVGElement, IconProps>(
  ({ className, ...props }, ref) => {
    return (
      <svg
        ref={ref}
        className={className}
        viewBox="0 0 24 24"
        fill="none"
        stroke="currentColor"
        strokeWidth="2"
        strokeLinecap="round"
        strokeLinejoin="round"
        {...props}
      >
        <path d="M3 6h18M19 6v14a2 2 0 01-2 2H7a2 2 0 01-2-2V6m3 0V4a2 2 0 012-2h4a2 2 0 012 2v2" />
      </svg>
    );
  }
);

TrashIcon.displayName = "TrashIcon";

// Usage works with design system classes
<TrashIcon className="h-6 w-6 text-red-500 hover:text-red-700" />
<Button variant="destructive" className="text-white">
  <TrashIcon className="h-4 w-4 mr-2" />
  Delete
</Button>

Why These Examples Matter:

Button Component Benefits:

Uses design system variants instead of arbitrary props
Extends native HTML button attributes for accessibility
Leverages Tailwind classes for consistent sizing and spacing
Maintains type safety with proper TypeScript interfaces

SVG Icon Benefits:

Uses currentColor to inherit text color from parent
Extends all native SVG properties for maximum flexibility
Works seamlessly with utility classes for sizing and colors
Can be styled contextually by parent components

This approach ensures you're working with your design system instead of against it. Override only when it's absolutely necessary.

Rule 4: Keep Components Small and Focused 🎯

One of the best ways to keep your code reusable is to make sure your components do one thing well.

The Principle:

A component should be focused on a single responsibility, whether that's rendering a button, a card, or a form input
If a component grows too large or tries to do too much, split it into smaller subcomponents
Smaller components are easier to test, reuse, and maintain

Example:

Instead of creating a single massive UserProfile component that handles layout, fetching data, and rendering UI:

✅ Better approach:

Create smaller components like UserAvatar, UserBio, and UserStats
Compose them inside UserProfile

This makes your project easier to extend later without rewriting large chunks of code.

Why These Rules Matter 🚀

Following these rules is essentially about discipline:

Consistency: Your code looks the same no matter who writes it
Maintainability: Anyone new to the project can jump in without learning multiple systems
Reusability: Components remain generic and adaptable instead of being one-off hacks
Performance: Avoid bloated builds from multiple frameworks
Team Collaboration: Shared conventions make collaboration smoother

Related Principles 📚

These rules don't exist in isolation, they reflect established software principles:

Single Source of Truth (SSOT): One UI library as the canonical styling source
Don't Repeat Yourself (DRY): Avoid writing styles that already exist
Convention over Configuration: Follow the conventions of your chosen library
Design System Discipline: Stick to the system, extend only when needed
Single Responsibility Principle (SRP): Each component should do one thing well

Industry Standards:

Utility-First CSS - Popularized by Tailwind CSS
Atomic Design by Brad Frost - Building consistent UI components
Design Tokens - Standardized design decisions in code
Component-Driven Development - Building UIs from reusable components

Conclusion 💡

Clean frontend code isn't about avoiding creativity, it's about using the right tools the right way. By sticking to one library, fully exploring its utilities, trusting its conventions, and keeping components small and focused, you'll write code that's not only clean and reusable but also easy for your team to maintain and scale.

Remember: discipline in following these rules early on will save you countless hours of refactoring later.

What's your biggest challenge when it comes to writing clean frontend code? Share your thoughts in the comments below! 👇

Set up github work/company email on mac together with your personal github account

i am message — Wed, 09 Jul 2025 15:40:10 +0000

Here’s a clean step-by-step outline to generate and add an SSH key from your macbook to GitHub, using your company email your_personal_company_email as the identifier.

🛠️ Add SSH Key to GitHub – Step-by-Step

1. Generate the SSH Key

In terminal, run:

ssh-keygen -t rsa -b 4096 -C "your_personal_company_email"

This command generates a new SSH key pair (used to securely authenticate with services like GitHub).

Explanation of Each Part:

Part	Meaning
`ssh-keygen`	The command to generate a new SSH key.
`-t rsa`	Specifies the type of key to create. `rsa` is a widely used algorithm.
`-b 4096`	Sets the bit size of the key. `4096` bits is stronger than the default `2048`.
`-C "your_email@example.com"`	Adds a label (comment) to the key file so you can identify it later — usually your email.

When prompted:
- Enter file name: give it a custom name like your_name-company (e.g. /Users/mac/.ssh/your_name-company)
- Press Enter to skip passphrase (or set one if you prefer extra security)

2. Add the Key to SSH Agent

The SSH agent is a background program that holds your private SSH keys in memory. This means you won’t need to enter your passphrase every time you use the key (e.g., when pushing to GitHub).

First, start the SSH agent:

eval "$(ssh-agent -s)"

This command starts the SSH agent and sets up the necessary environment variables so your terminal can communicate with it.

Next, add your private key to the agent:

ssh-add ~/.ssh/your_name-company

Replace your_name-company with the actual name of your private key file (not the .pub one).

Once added, the agent will remember your key for the current session, allowing passwordless SSH/Git operations.

3. Copy the Public Key to Clipboard

Run:

pbcopy < ~/.ssh/your_name-company.pub

This copies the SSH key to your clipboard.

4. Add the Key to GitHub

Go to: https://github.com/settings/ssh/new
Title: e.g. MacBook - Company
Key: paste the copied content (Cmd+V)
Click “Add SSH Key”

5. Update `~/.ssh/config` File

Open it:

nano ~/.ssh/config

Add this block:

# GitHub for company
Host github.com-company
  HostName github.com
  User git
  IdentityFile ~/.ssh/your_name-company
  IdentitiesOnly yes

Save:

Press Ctrl + O, then Enter to save
Press Ctrl + X to exit

6. Test the Connection

Run:

ssh -T git@github.com-company

Expected:

Hi your-username! You've successfully authenticated...

7. Clone the Repo Using the Alias

Use this to clone:

git clone git@github.com-company:company/repository.git

📚 Sources

Semantic HTML Not
Soup: The Importance of Semantic HTML in Modern Web Development

i am message — Mon, 02 Jan 2023 11:50:00 +0000

What is Semantic HTML?

Semantic HTML refers to the use of HTML elements that carry inherent meaning and purpose, both for developers and for the technologies that consume web content such as browsers, search engines, and assistive tools like screen readers. Unlike non-semantic elements (e.g., <div> and <span>), semantic elements clearly describe their role in the document structure.

For example:

<header> indicates introductory content or navigation.
<footer> represents closing content or metadata for a page or section.
<article> identifies independent, self-contained pieces of content such as blog posts or news stories.
<section> groups related content under a thematic division.
<aside> signals supplementary or tangential content, such as sidebars or callouts.

By applying these elements correctly, developers create documents that are not only visually structured but also meaningfully structured.

Why Semantic HTML Matters

1. Improved Accessibility

Semantic HTML is foundational for web accessibility (a11y). Screen readers and assistive technologies rely on the semantic meaning of elements to help visually impaired users navigate a webpage. For example, a screen reader can announce when it enters an <article> or <nav>, allowing users to skip to relevant sections.

Reference: W3C Web Accessibility Initiative (WAI) emphasizes semantic HTML as a best practice for accessible design.

2. Better SEO and Search Engine Crawling

Search engines use semantic elements to interpret the hierarchy and relevance of content. For example, wrapping content in <article> or <section> provides context that can improve how search engines classify and rank the content.

In addition, semantic HTML enhances the effectiveness of structured data (Schema.org), which can lead to rich snippets in search results (e.g., article previews, FAQs, product details).

Reference: Google’s SEO Starter Guide stresses the importance of semantic markup for crawlability and ranking.

3. Maintainable and Scalable Code

Semantic HTML improves developer experience by making the codebase more readable, maintainable, and collaborative. A new developer reviewing a project will understand <header>, <main>, or <footer> far more intuitively than a sea of nested <div> elements. This reduces onboarding time and the likelihood of errors.

4. Consistency Across Devices and Tools

Browsers, search engines, and assistive technologies have built-in behaviors for semantic elements. For instance, headings (<h1> through <h6>) automatically create a document outline, while <nav> elements are identified as navigation landmarks. These consistent behaviors make web content more robust across devices and tools.

Reference: HTML Living Standard – WHATWG outlines semantic elements and their intended roles in document structure.

Practical Examples

Consider the difference between these two snippets:

Non-semantic (div soup):

<div id="header">
  <div class="title">My Blog</div>
</div>
<div class="content">
  <div class="post">Latest Post</div>
</div>

Semantic (clear meaning):

<header>
  <h1>My Blog</h1>
</header>
<main>
  <article>
    <h2>Latest Post</h2>
  </article>
</main>

The second example not only conveys structure to developers but also communicates meaning to assistive technologies and search engines.

Semantic vs. Non-Semantic Elements

Here’s a comparison of some common semantic elements and their non-semantic equivalents:

Semantic Element	Purpose	Non-Semantic Equivalent	Problem with Non-Semantic Use
`<header>`	Introduces content, page, or section header	`<div id="header">`	Loses meaning to screen readers/search engines
`<footer>`	Closing or metadata for a page/section	`<div id="footer">`	No structural significance
`<nav>`	Defines primary navigation links	`<div class="nav">`	Search engines can’t identify navigation
`<main>`	Denotes the primary content of a page	`<div id="main">`	Harder for assistive tech to find main content
`<article>`	Self-contained, reusable content (blog post, news)	`<div class="article">`	Treated as generic container
`<section>`	Groups related content under a theme	`<div class="section">`	No semantic grouping, weak document outline
`<aside>`	Tangential or secondary content (sidebars)	`<div class="sidebar">`	No distinction from main content
`<h1>`–`<h6>`	Headings that define hierarchy	`<div class="title">`	Breaks page outline, harms SEO

This table demonstrates how semantics provide machine-readable meaning, while non-semantic markup only provides styling hooks.

Best Practices for Using Semantic HTML

Use headings in order (<h1> → <h2> → <h3>): Don’t skip levels; this ensures a proper document outline.
Reserve <h1> for the main page title: Each page should typically have only one <h1>.
Use <main> only once per page: This represents the central content, not repeated sections.
Wrap navigational links in <nav>: Helps screen readers quickly locate menus.
Prefer semantic elements over <div>s and <spans>: Use <section>, <article>, <aside>, etc., wherever they apply.
Combine with ARIA roles only when necessary: Semantic HTML often eliminates the need for extra ARIA attributes.
Ensure <section> has a heading: Each <section> should start with a heading for clarity.
Avoid misuse of <section> as a generic container: Use <div> when grouping content purely for styling.
Always provide alt text for images (<img alt="...">): This complements semantic markup for accessibility.
Validate HTML regularly: Use W3C Validator to catch semantic and structural issues.

The Bigger Picture: Accessibility, SEO, and DX

Accessibility (A11y): Semantic HTML is the baseline of WCAG compliance. Without it, ARIA roles and accessibility overlays are less effective.
SEO: Semantic HTML provides the structural clarity that modern search algorithms use to evaluate content authority and relevance.
Developer Experience (DX): Code readability and collaboration are improved, reducing cognitive load for developers.

When semantic HTML is combined with CSS and JavaScript responsibly, it creates content that is meaningful, accessible, and discoverable.

Final Thoughts

Semantic HTML isn’t just about cleaner markup, it’s about building websites that are inclusive, future-proof, and search-friendly. As developers, our goal should be to ensure that both humans and machines can understand and interact with the content meaningfully.

“Use the right element for the right job.” – MDN Web Docs

By embracing semantic HTML, we’re not just writing code, we’re shaping the way people and technologies interact with the web.

DEV Community: i am message

Component Architecture: Co-location, Composition, and Separation of Concerns, Different soups...

1. Co-location is about proximity, not combining everything into one component

2. Separation of concerns is about responsibility

3. Atomic Design helps us reason about the level of abstraction

4. Composition is how we build specialized behavior without bloating foundational components

5. Reusability does not mean putting every use case behind one API

6. Component boundaries and code splitting are related, but they are not the same thing

7. Why this matters even more in the AI era

Conclusion

Pixels, Tokens, and Grids: Speaking the Same Language in Design and Code

The Role of Design Tokens

Why Decimal Pixels Don’t Work

1. Rendering Inconsistency Across Devices

2. Icon Sharpness and Pixel Grid

3. Scalability and Maintainability

4. Cross-Platform Alignment

Accessibility Considerations

Developer Experience Considerations

The Power of Grid Systems

Best Practices for Designers

Conclusion

Further Reading

📘 Essential Front-End Development Rules for Clean, Reusable Code

Rule 1: Stick to One Library 🎯

Why This Matters:

Implementation:

Rule 2: Exhaust the Utility Classes Before Writing Custom Styles 🔧

Benefits:

Example:

Rule 3: Trust the Library Before Adding Custom Props or Overrides 🤝

Key Principles:

Example 1: Button Component

Example 2: SVG Icon Component

Why These Examples Matter:

Rule 4: Keep Components Small and Focused 🎯

The Principle:

Example:

Why These Rules Matter 🚀

Related Principles 📚

Industry Standards:

Conclusion 💡

Set up github work/company email on mac together with your personal github account

🛠️ Add SSH Key to GitHub – Step-by-Step

1. Generate the SSH Key

2. Add the Key to SSH Agent

3. Copy the Public Key to Clipboard

4. Add the Key to GitHub

5. Update ~/.ssh/config File

6. Test the Connection

7. Clone the Repo Using the Alias

📚 Sources

Semantic HTML Not Soup: The Importance of Semantic HTML in Modern Web Development

What is Semantic HTML?

Why Semantic HTML Matters

1. Improved Accessibility

2. Better SEO and Search Engine Crawling

3. Maintainable and Scalable Code

4. Consistency Across Devices and Tools

Practical Examples

Semantic vs. Non-Semantic Elements

Best Practices for Using Semantic HTML

The Bigger Picture: Accessibility, SEO, and DX

Final Thoughts

References

5. Update `~/.ssh/config` File

Semantic HTML Not
Soup: The Importance of Semantic HTML in Modern Web Development