Tag: frontend

  • DevDose: The Real Role of package.json in Your Frontend Project

    DevDose: The Real Role of package.json in Your Frontend Project

    Day Twelve of Devdose

    Introduction:

    I was reviewing a flaky build issue for a new team and noticed something off in their setup. It wasn’t the code, tests, or CI, it was a misplaced dependency in package.json.

    Real-World Issue:

    The project depended on a library only used in the build process, but it was declared as a regular dependency rather than a devDependency. On a clean install, the library triggered a version mismatch on production servers where it wasn’t needed at all. We lost half a day debugging an issue that didn’t belong in runtime.

    Concept:

    "dependencies": {
      "zone.js": "^0.13.0"
    },
    "devDependencies": {
      "@angular-devkit/build-angular": "^17.0.0"
    }

    Knowing where a package belongs matters. Dependencies ship with your production bundle. Dev dependencies do not.

    Insight:

    Treat package.json like a contract. It declares what your project needs to run, build, and test. Misplacing packages pollutes production environments and slows teams down.

    I now review this file line by line when joining a new repo. It’s one of the quickest ways to understand a team’s discipline.

    Conclusion:

    Every engineer should know how package.json works, not just what it is. It’s more than a config file; it’s your app’s first handshake with the ecosystem.

  • DevDose: Three Ways to Centre a div with CSS

    Day Seven of Dailydose

    This came up while mentoring a junior developer who was puzzled by layout inconsistencies. We explored different centring techniques and why they behave the way they do.

    One real-world case was a login box that wouldn’t stay centred in all screen sizes. We tested a few methods to find the one that best respected responsiveness and minimal CSS.

    Here are three standard techniques for centring a div both vertically and horizontally:

    /* Flexbox */
    .parent {
      display: flex;
      justify-content: center;
      align-items: center;
    }
    
    /* Grid */
    .parent {
      display: grid;
      place-items: center;
    }
    
    /* Margin Auto (horizontal only, needs fixed width) */
    .child {
      margin: 0 auto;
      width: 200px;
    }

    Each method solves a slightly different problem. margin: auto works well for horizontal centring of fixed-width elements. display: flex is more flexible and widely used, especially when vertical alignment is also needed. grid with place-items: center is concise and powerful, but less commonly used outside of fully grid-based layouts.

    In mentoring or code review, I prefer starting with flexbox for its balance of clarity and control, then switching based on project constraints.

    Choose the method that matches the layout’s intent and scale.

  • DevDose: From Div Soup To Semantic Clarity In Service Cards

    Day Six of Dailydose

    Intro

    While updating a pricing section for a client site, I wanted the layout fast. I defaulted to styled divs, but stopped to ask: if this is meant to sell services, why not make it easier for everyone, including search engines and screen readers, to understand?

    The Common Approach

    I sketched a service card using the usual non-semantic elements.

    div class="service-card">
      <div class="service-title">Premium Plan</div>
      <div class="service-price">£49/month</div>
      <div class="service-features">
        <div>Unlimited bookings</div>
        <div>Priority support</div>
        <div>Custom branding</div>
      </div>
    </div>

    This looks fine visually, but there’s no real structure here. A screen reader wouldn’t know what kind of content it is. A crawler wouldn’t understand this is a product or service.

    The Semantic Version

    Here’s the same card using meaningful HTML:

    article>
      <h2>Premium Plan</h2>
      <p><strong>£49/month</strong></p>
      <ul>
        <li>Unlimited bookings</li>
        <li>Priority support</li>
        <li>Custom branding</li>
      </ul>
    </article>

    Element Breakdown

    <article> identifies a self-contained block of content. Use it for product cards, service listings, or feature summaries.

    <h2> is the headline of the offering. It helps maintain a clear heading hierarchy across the page.

    <p> wraps the price. adds emphasis and improves accessibility.

    <ul> and <ui> present the features in a structured, readable format.

    My Insight

    It’s tempting to treat semantic HTML as a concern for blogs or longform content.

    But service pages are often where users make decisions.

    Structure supports that.

    It makes the content more accessible, easier to maintain, and more legible to crawlers.

    Conclusion

    Semantic elements add little friction but improve clarity and meaning. I now use this as my standard layout for service cards, feature grids, and pricing sections.