DEV Community: Dominic Magnifico

The Struggle Is What We Crave

Dominic Magnifico — Wed, 01 Apr 2026 16:56:42 +0000

The confession

I've been working a lot more lately. Way more than I used to. I've had a pretty solid work life balance in the past that I kind of prided myself on. After 7pm was my time. My kid was in bed (or should have been), Slack was shut down, and the client work that was on my mind took a back seat. But something changed, or maybe several things all at the same time kind of. But the first thing to change was my desire to be a part of something bigger than myself. It's a cliche or whatever, but every year that goes by I see my son become more and more enthralled with the world around him. He notices shit, remembers that time I said something off-hand. Point being, I want to make sure that he sees how important it is to be a part of something bigger than himself in a world that's becoming more isolated day after day.

There's a million different variations of isolationism that are taking hold in the world today, and the one I'm going to be talking about is probably the least impactful of all of them. But it's the one right in front of me. The one I've been a part of for more than 15 years, and it's the isolation of the web. It feels like an oxymoron to say, I mean, the web was built to connect the world. There was some god damn inspiring stuff that happened between the days of Ada Lovelace and the .com boom in the 90s. Stories of nerds coming together to make the component parts of computers more accessible to normal folks. The Tim Berners-Lee's of the world who pushed for a standardized way of sharing and linking documents. Some real populist shit.

When I was coming up in the web world, the community was the thing that made it so appealing. There were so many meetups, conferences, workshops and the like. And they were centered around some of the core pieces of what building on the web are. I remember going to the CSS Dev Conf in Estes Park in 2013 and being blown away by the breadth of knowledge being shared. The whole conference was focused on CSS. Chris Coyier gave the opening keynote, there were a couple talks on Sass and Compass that were so cutting edge and cool. Tab Atkins even spoke on the future of CSS. It was so rad to see a group of folks I looked up to coming together to talk about what I thought was the best part of web development at the time.

It feels like the COVID days really fucked up the momentum that tech conferences like this had, and I imagine it was a nightmare trying to manage one of these things anyway. Skip a year of funding or ticket sales or sponsors or whatever, and then pair that with the uncertainty of a conference ever happening again, and I think the switch just kind of flipped off.

I read a book a long time ago called "The Sixth Extinction" by Elizabeth Kolbert that outlined the five previous mass extinction level events that had occurred over the past half billion years, and then explored and identified that we were the catalyst in the current ongoing sixth extinction. I think web development has gone through several extinction level events too. And the latest one we're witnessing is AI.

It's tough to see it from the inside. It's even tougher to see it when you're so blinded by the productivity gains you’re seeing in your day to day work. But the deeper I dive into it, the clearer it becomes:

The thing I loved about this industry is dying, and I'm watching it happen from the inside.

The Reason We Found Each Other

Alright. You're into my line of thought at this point, so follow me here.

Why did conferences like CSS Dev Conf exist in the first place? They happened because CSS was hard. If you lived through those days you'll remember that floats were annoying as hell, vertically centering a div was a meme, and figuring out how to do responsive design was a totally foreign concept (if you didn't live through those days consider yourself very lucky). We needed these communities so that we could leverage someone else's hard won knowledge. The struggle is what created the community.

We have way less of that now.

Things like JSConf, and CSSConf don't really exist anymore. That domain knowledge has effectively been abstracted away by the ability to just let Claude do it for you, without understanding the fundamentals. Take it a step further and look at StackOverflow. I can't tell you how many times I'd leveraged SO to make it look like I knew what I was talking about early on in my career. They went from 200,000 new questions a month to under 50,000 in three years. Nobody's asking questions (at least publicly) anymore. And that's a fucking problem.

The struggle of sifting through several Stack Overflow threads, trying one piece of code, mashing it up with another from a comment that got fewer upvotes, and seeing how that affected your specific problem was a pretty amazing way to learn lots of different concepts. And the Stack Overflow Gods that provided extremely detailed responses that linked out to MDN docs, or the spec itself were better teachers than half the ones I had getting my bachelors in "Web Development and Interactive Media" in 2010.

These cornerstone pieces of the web were some the first casualties in the web's "sixth extinction". The next domino to fall, which we're already seeing, is the death of open source contributions.

The entire open source contribution model is changing. There are so many selfless developers out there who built, or are building open source tools to give back to the same community that I came up loving, and are getting absolutely inundated with AI slop contributions because people see those GitHub "contributed to" lists as some kind of status symbol. I generalize here obviously, but it's breaking so many good developers trying to sift through all this garbage that some open source projects like Ghostty and tldraw are having to write aggressive AI usage policies, or are locking the doors completely to prevent people from spamming them with AI slop PRs.

It gets even more horrifying when you start to realize how truly immense the loss of jobs is going to get. Look at companies like Block, Oracle, Amazon and pretty much every other big name. They're laying off workers in droves after posting record profits. I've lived through several of these extinction level events in web development but this one I think has had the most staggering number of layoffs that can be directly tied to it. People in these positions, were literally building the tech the higher ups were going to use to replace them. They were building their own coffins.

It leads us to the last casualty in this extinction that I'll talk about, and that's the junior developers. Junior developers were having a miserable time finding a job before the AI boom. The industry was doing everything it could to snatch up every senior dev on the block to avoid having to train up the juniors. That created a talent pool of so many people that remains untapped. I can't fathom how much potential here got pushed out and had to find work in a different industry. It's a shame because there was so much wonder around the industry when I first started, and seemingly the 7 month bootcamps really started to suck that wonder out of these juniors, with AI being the final straw that's going to make it even more difficult for junior devs to break into the industry.

It's depressing to realize, but, the thing that was supposed to help developers write better code is destroying the ecosystem. It was supposed to allow us to focus on bigger issues, and instead is effectively locking down open source projects, making it easier for soulless execs to justify laying off massive swathes of their workforce, and is making it harder for meaningful progress to be made in the effort to bring new, passionate talent into the industry.

The Callouses

I've got a lot of these.

It's hard to pick one that really illustrates the point. I could tell you about the time I built a multi stream gaming platform that took raw video feeds from Esports competitions, used ffmpeg to encode them, live stream them, and allow users to switch between feeds as the tournament was going on to see different perspectives. The sheer amount of AWS hot garbage documentation I had to read to try to understand how the hell to use MediaEncoder to get the bitrate right so six streams were the right quality. The all nighters that we pulled using test feeds from six Xbox's connected to a server to make sure the demo we were running the next day would work just long enough to sell the product.

Or I could go into depth as to why the partnership between two really close friends who helped me build House of Giants fell apart. These were people I'd had amazing relationships with. I hired one of them at my first agency. We had this grand vision for how we'd run House of Giants. We modeled ourselves as an anti-agency. A buck against the status quo because we absolutely despised how the agencies we worked at in the past were run. Out of touch executives and leadership who would clutch their pearls harder than the clam they stole them from. And it was great for a while, but then the stakes were raised. Our ambitions diverged, the way we wanted to run things, chase work (or not) became an argument rather than a conversation. How we went about learning and expanding our technical knowledge and skillsets turned into arguments about who's job it was to do Task X over task Y.

The struggles in these moments..those are the things that teach you the most. The ambitions of the project, your uncertainty about how the fuck you're going to execute on the idea. The panic scrolling through Stack Overflow. The unbearable contemplation of how you stop being business partners with friends. That's where the growth happens. It feels paradoxical, especially in the moment, that the struggle during these times is what would end up making you more efficient in the long run. And I think a lot of shops, and even gigantic corporations (looking at you GitHub, with your newly acquired 90% uptime milestone) are going to face the wrath of this in short order.

I'm not afraid that AI exists. I do client work, and I'm doing that client work faster than I ever have in the past, while simultaneously building more than I've ever built on the side. Taking side projects from an idea I've had for years to production in a week. The tools are getting better, and they're helping me do more.

What I'm worried about is that in five years, the people making the architecture decisions won't have the scar tissue to know what to do when it breaks. They'll patch it with another AI slop generated set of changes that start with "Great catch! We should get that fixed" coming back from their agent.

I'm worried about an entire generation of developers who are going to build without callouses like these to inform their decisions. That judgment layer, the thing that separates "I can build this" from "should I build this?", is completely disappearing.

The Paradox of Ease

I keep coming back to something I've written about before. Being comfortable with being uncomfortable. I think that a lot of humanity is lost when we avoid the struggle. The more comfortable we are with being comfortable, the harder it is for us to push ourselves to do something difficult.

This is another thing I want my son to know about me, that I wasn't afraid to do something I was scared of. I'm the type of person that puts the spider in your basement in a cup, and takes it outside instead of smashing it. I used to collect the rollie pollies in my parents garage and take them to the grass. See a worm on the sidewalk after it rains? I'll pick you up and put you back in the mud dude, I got you. In total opposition to those convictions I went hunting for the first time last October and killed an elk. Field dressed it (with the help of some very good friends), and packed it out. I had a ton of internal conflict about that. But at the end of the day I wanted to show my kid that there are times in life you have to make a decision that might go against everything you think you're about.

Now when I ask my kid what his favorite food is he says "elk steak!", and that gives me some sort of weird primal satisfaction knowing what I went through to provide that experience for him. That's a part of his life now, something that was so emotionally taxing for me, will live as a positive experience for him.

We keep trying to move so fast to build tools that eliminate all the friction in our lives and then sit wondering why nothing feels like it matters anymore. We stop getting together to talk about those hard fought battles, and we scream into the void that is our AI agent, and all that does is reflect back to you all the bullshit you want to hear beneath the subtext of your prompt. I build a ton of stuff with a swarm of AI agents and I still feel this way. That says something.

Ten Years Uncomfortable

Dominic Magnifico — Tue, 24 Mar 2026 19:36:52 +0000

When I was 25 I wrote a blog post about leaving the best job I'd ever had. Not because it was bad...because it was comfortable. I said something about developers finding comfort in the repetition of a well-written loop. Everything comes out uniform, just how you intended it. And I said it was time to break the loop.

That was ten years ago.

I'm 35 now. I have a kid. I run a development studio. I haven't written anything real in a long time.

Not because I don't have things to say. Because somewhere along the way I convinced myself my opinion doesn't matter anymore. There are louder people. More charismatic people. People who seem to have the time and energy to sit down and craft a take and put it out there. I am not those people. I'm the guy who's trying to find 30 minutes that aren't already claimed by something else.

But here's what I've been thinking about lately.

At 25, being uncomfortable meant leaving a job. It was dramatic. It was a clear before and after. You could point to the moment and say "that's when things changed."

At 35, being uncomfortable is quieter. It's running a studio and quoting $25k/month to clients while wondering if you're worth it. It's turning down projects because they don't meet your bar, even when the money would help. It's building something at 10 PM on a Saturday not because anyone asked you to, but because you still can't stop tinkering. It's knowing you're good at this and still feeling like you haven't earned the right to say it out loud.

The discomfort at 25 was about leaving. The discomfort at 35 is about staying...staying in the work, staying honest about what you don't know, staying visible when it's easier to just put your head down and build.

I don't have a framework for this. No five steps. No thread with a fire emoji. Just the observation that the guy who wrote that blog post at 25 was onto something, and the guy at 35 keeps forgetting it.

Some change is good, as hard as it is to recognize. I learned that once in a big, dramatic swing, and then again in smaller ways through years like 2015 and first-time leaps like giving my first meetup talk.

I wrote that. Ten years ago. I should probably listen to myself more.

I Didn't Like Other Workout Tracking Apps, So I Built My Own.

Dominic Magnifico — Tue, 27 Jan 2026 21:37:27 +0000

I've been lifting for years. And I've tried every workout app out there. Strong. Hevy. FitNotes. Ladder. They all fall short in the same predictable way.

You're 30 seconds into your rest period, sweaty, trying to log a set, and the app wants you to:

Tap "Add Set"
Tap the weight field
Wait for the keyboard
Type the weight
Dismiss the keyboard
Tap the reps field
Wait for the keyboard AGAIN
Type the reps
Dismiss the keyboard AGAIN
Scroll to find the "Save" button
Tap "Save"

By this point your rest timer expired 45 seconds ago and you're late for your next set.

The Problem Nobody Was Solving

Most workout apps treat logging like you're sitting at a desk with a cup of coffee and unlimited time.

Meanwhile, in the real world, you've got maybe 60-90 seconds between sets.

So we built OpenTrainer. Two taps per set.

The Tech Stack (And Why We Chose It)

Here's what we're running:

Next.js 16
Convex
Clerk
OpenRouter
shadcn
Vercel

Why Convex?

Convex is awesome for this use case.

Traditional workout apps use REST APIs. You tap "Log Set" → HTTP request → server processes → database write → HTTP response → UI updates. If you're on sketchy gym WiFi, that's 2-3 seconds of loading spinner hell.

Convex gives us real-time sync with zero setup. The mutation fires, the optimistic update shows instantly, and the actual database write happens in the background. If it fails, it rolls back automatically. If you go offline mid-workout, it queues the mutations and syncs when you're back online.

We have optimistic updates working with seven lines of code:

const logSet = useConvexMutation(api.workouts.addLiftingEntry);
const handleLogSet = () => {
  logSet({
    workoutId,
    exerciseName: "Bench Press",
    clientId: generateClientId(), // Deduplication
    kind: "lifting",
    lifting: { setNumber: 1, reps: 8, weight: 225, unit: "lb" }
  });
  // UI updates instantly. Done.
};

Convex handles:

Optimistic UI updates
Deduplication via clientId
Offline queueing
Conflict resolution
Real-time sync across devices

The Schema

We use a discriminated union pattern for entries. One table, multiple exercise types:

// entries table
{
  kind: "lifting" | "cardio" | "mobility",
  lifting?: {
    setNumber: number,
    reps: number,
    weight: number,
    unit: "kg" | "lb",
    rpe?: number
  },
  cardio?: {
    durationSeconds: number,
    distance?: number,
    intensity?: number
  },
  mobility?: {
    holdSeconds: number,
    perSide?: boolean
  }
}

This beats having separate tables for lifting_entries, cardio_entries, mobility_entries. Querying a workout's full history is a single query. This way if we want to add a new exercise category we just extend the union.

Next.js 16

What worked:

Parallel routes made the bottom navigation clean
Metadata API makes SEO easier
Clerk's new clerkMiddleware (v5+) works perfectly with Next.js 16

What hurt:

The dev server randomly decides to recompile everything. Often.
Hot reload occasionally needs a manual refresh
Some Convex types needed manual casting (minor annoyance)

Auth Setup: Clerk + Convex requires a JWT template in the Clerk dashboard. Standard stuff, nothing custom:

// convex/auth.config.ts
export default {
  providers: [{
    domain: process.env.CLERK_JWT_ISSUER_DOMAIN!,
    applicationID: "convex",
  }],
}

You just need to grab your JWT issuer URL from Clerk and set it as an env var. That's it.

The AI Layer

Here's where we diverged from every other fitness app.

Most apps with "AI" just slap ChatGPT on a prompt and call it a day. We wanted something smarter.

Why OpenRouter Instead of Direct APIs

We use OpenRouter as our AI gateway. One API, multiple models. Right now we're using Gemini 3 Flash through OpenRouter's unified endpoint.

Why OpenRouter?

No vendor lock-in - Switch models with one line of code
Cost optimization - OpenRouter shows pricing for every model
Fallback logic - Can implement automatic failover to Claude/GPT if Gemini is down
One API key - Don't need separate Google, Anthropic, OpenAI accounts

const response = await fetch("https://openrouter.ai/api/v1/chat/completions", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.OPENROUTER_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    model: "google/gemini-3-flash-preview",
    messages: [
      { role: "system", content: systemPrompt },
      { role: "user", content: userMessage },
    ],
  }),
});

The Routine Generation Problem

Ask GPT-4 to generate a workout routine and you get:

Generic "bro split" garbage
Exercises you don't have equipment for
Zero consideration for your actual goals
Hallucinated exercise names ("reverse cable overhead skull-tricep extension")

We built an equipment audit during onboarding. User checks off what they have access to. Planet Fitness member? Cool, we know you have Smith machines and dumbbells, not barbells. Home gym? Tell us what you've got.

Then we pass that to Gemini with a structured prompt:

const routinePrompt = `
Generate a ${goal} program for ${experienceLevel} lifter.

EQUIPMENT AVAILABLE:
${equipment.join(", ")}

CONSTRAINTS:
- ${weeklyAvailability} days per week
- ${sessionDuration} minutes per session
- Must use ONLY the equipment listed above
- Use standard exercise names (no made-up movements)

OUTPUT FORMAT: JSON matching this schema...
`;

This works way better than you'd expect. Gemini's actually pretty good at constraint satisfaction when you give it clear boundaries.

The Training Load Calculation

Most apps calculate "volume" as sets × reps × weight. That's... fine. But it doesn't account for intensity.

We use a modified training load formula that factors in RPE (Rate of Perceived Exertion):

function calculateTrainingLoad(entry: Entry): number {
  if (entry.kind !== "lifting") return 0;

  const { reps = 0, weight = 0, rpe = 5 } = entry.lifting;
  const volume = reps * weight;
  const intensityFactor = rpe / 10;

  return volume * intensityFactor;
}

A set of 5 reps at 225 lbs with RPE 9 (brutal) counts for more than 10 reps at 135 lbs with RPE 5 (warm-up). This gives us way better insights into actual training stress.

The UI Philosophy

Here's the entire interaction model for logging a set:

Tap the weight number → Quick adjust (+5 lb) or type any value
Tap "Log Set" → Done

We use large tap targets (minimum 48px). Everything important is in thumb-reach on a phone held one-handed. The rest timer starts automatically after you log a set. Haptic feedback on every interaction so you get confirmation even with sweaty hands.

The Stepper Component

Building good steppers for weight/rep adjustment was surprisingly tricky:

<SetStepper
  value={weight}
  onChange={setWeight}
  step={5}  // +/- 5 lbs per tap
  min={0}
  max={1000}
  label="Weight"
  unit="lb"
  enableDirectInput  // Tap the number to type
/>

We're using optimistic updates here too. The value updates in local state immediately, then fires a debounced mutation to Convex to persist it.

The Stuff That Broke

Problem #1: The Rest Timer Kept Getting Killed

Mobile browsers are aggressive about killing background JavaScript. We had users complaining the rest timer would stop if they switched to Spotify between sets.

Solution: Web Workers + Service Workers + loud-ass notifications.

// rest-timer-worker.ts
self.addEventListener("message", (e) => {
  if (e.data.action === "start") {
    const interval = setInterval(() => {
      self.postMessage({ timeRemaining: getRemainingTime() });
    }, 1000);
  }
});

Plus we request notification permissions so we can send an annoying alert when rest time is up. It works. Users hate it. But they also don't miss their rest periods anymore.

Problem #2: Clerk JWT Validation Failing Randomly

Convex needs to validate Clerk JWTs. The issuer domain kept changing between clerk.accounts.dev and accounts.dev for a reason I'm still not clear on.

We set up a .env var for the issuer domain and made it configurable.

Problem #3: The "My Phone Died Mid-Workout" Problem

Users would start a workout, log 10 sets, phone dies, come back and... everything's gone.

We added a recovery mechanism:

// On app load, check for incomplete workout
const checkForIncompleteWorkout = async () => {
  const activeWorkout = await getActiveWorkout(userId);
  if (activeWorkout && activeWorkout.status === "in_progress") {
    // Show "Resume workout?" dialog
    showResumeDialog(activeWorkout);
  }
};

Now if your phone dies, the workout stays in "in_progress" state. When you open the app again, it asks if you want to resume. Crisis averted.

What We'd Do Differently

1. User Testing Sooner

We built the "perfect" UI in our heads, then watched actual users struggle with it.

Try It

OpenTrainer is in alpha. It's free. No ads. No tracking pixels. Your data exports as JSON whenever you want.

Try it here

Or clone the repo and run it yourself. It's Apache 2.0 licensed. Do whatever you want with it.

GitHub: house-of-giants/opentrainer

TLDR

We built a workout tracker that doesn't suck. Two taps per set. Real-time sync. AI that actually knows your gym has a Smith machine, not a barbell. Next.js + Convex + Clerk + OpenRouter.

The hardest parts weren't the tech. They were:

Making everything feel instant (optimistic updates everywhere)
Keeping timers alive on mobile (Web Workers + notifications)
Building UI that works with sweaty hands (big tap targets, haptic feedback)

If you're building something similar, use Convex. Seriously. It's rad for real-time apps.

A searchable reference for WordPress Gutenberg block markup

Dominic Magnifico — Tue, 15 Jul 2025 16:38:03 +0000

I built out a documentation site for the insane block markup associated with WordPress's Gutenberg blocks. There was sparse documentation around this, and parsing the WP Block GitHub was ridiculous, especially as someone trying to push production work out into the world.

Why This Exists

Block comment syntax is often poorly documented
HTML output varies between themes and contexts
FSE markup quirks are scattered across various resources
Real-world examples are hard to find in one place

What the site provides

✅ Complete HTML markup reference for WordPress core blocks
✅ Interactive examples with syntax highlighting
✅ Copy-paste ready code snippets
✅ Block validation tools
✅ FSE quirks and gotchas documentation
✅ Best practices and guidelines
✅ Comprehensive resource directory

Features

Comprehensive Block Documentation

Core Blocks: Complete documentation for most common WordPress core blocks
Markup Examples: Real-world HTML output with explanations
Properties Reference: Detailed attribute and property documentation

Developer Tools

Block Validator: Validate your block markup for errors
Pattern Library: Ready-made block combinations
Code Highlighting: Syntax-highlighted examples throughout

Learning Resources

Best Practices: WordPress block development guidelines
FSE Quirks: Known issues and workarounds
Resource Directory: Curated links to essential tools and documentation

Contributions and feedback welcome 🤘

Documentation Site: https://www.wpblockdocs.com/
GitHub: https://github.com/house-of-giants/wp-block-docs

🚀 Building a Role Based Navigation in NextJS using Clerk

Dominic Magnifico — Wed, 30 Oct 2024 15:44:27 +0000

💥 The Challenge

We’ve been working on a few projects with fairly complex navigation systems here at House of Giants. Different user types need to see different parts of an application and are separate in what they can see based on the role that they’re assigned. As these applications grow these navigation systems can become unwieldy. We’ve developed a system that we think works pretty well.

At a high level, here are a few of the things we’ve found that make role-based navigation tricky:

⚖️ Duplicated items across various roles
😵‍💫 Hard-to-maintain code when you need to update shared elements
🔐 Complex logic around who can see what
🔄 Difficulty in adding new roles or items without breaking things

Let’s see how we can alleviate some of these issues.

🛠️ Step 1: A Modular Navigation Structure

Using a modular approach gives us the ability to change only what we need, only for the user types that are affected. Keeping logic separate ensures that changing one piece doesn’t create a litany of issues for other users.

1. Define Individual Navigation Items

Start by setting up a single source of truth for all navigation items. This keeps things consistent and eliminates redundancies. These are just basic objects, customize them and their data based on your needs.

// items.js

export const navItems = {
  admin: {
    text: "Admin Dashboard",
    icon: <svg>cool admin icon</svg>
    href: "/dashboard/admin",
  },
  myTasks: { 
    text: "Todos", 
    icon: <svg>an icon here</svg>, 
    href: "/dashboard/todos"
  },
  profile: { 
    text: "Profile", 
    icon: <svg>an icon here</svg>,
    href: "/dashboard/profile"
  },
  logout: {
    text: "Logout",
    icon: <svg>logout</svg>,
    logout: true
  },
};

2. Create Reusable Navigation Sets

At this point we found it helpful to define some commonly used groupings. This lets us build different navigation layouts without repeating ourselves. ✨

// sets.js
export const navSets = {
  userEssentials: ["profile", "myTasks", "logout"],
  taskManagement: ["myTasks"],
  adminEssentials: ["admin"],
};

3. Organize Navigation into Sections

With items and sets defined, we can further organize the navigation into logical sections. This keeps everything structured and makes it easy to add or remove sections later. We’ve opted to create a new Set to further ensure that no duplicate routes are provided. A value in a set may only occur once, duplicates are omitted.

In our case, we’re adding a text value to our sections, this acts as the parent dropdown label for the set of navigation items.

// sections.js
import { navSets } from "./sets";

export const sections = {
  admin: {
    text: "Admin",
    children: [...new Set([...navSets.adminEssentials])],
  },
  user: {
    text: "User",
    children: [...new Set([...navSets.userEssentials])],
  },
};

4. Configure Role-Based Access

Here’s where we map user roles to the sections they should see. This keeps role-based logic centralized and easy to adjust 🔒 – keep in mind here, we’re using Clerk role names here, yours may be different.

// roles.js
export const roleConfig = {
  "org:admin": ["admin", "user"],
  "org:user": ["user"],
};

5. Build the Navigation Hook

We decided that building a custom hook here would serve us best when building the UI for the navigation. Our hook assembles the navigation based on the user’s role and will return only the sections relevant to each user.

// ./hooks/navigation/useNavigation.js
import { auth } from "@clerk/nextjs/server";
import { navItems } from "@/config/navigation/items";
import { sections } from "@/config/navigation/sections";
import { roleConfig } from "@/config/navigation/roles";

function getNavigationItems(userRole) {
  const sectionNames = roleConfig[userRole] || roleConfig["org:user"];

  return sectionNames.map(sectionName => {
    const section = sections[sectionName];
    return {
      text: section.text,
      children: section.children.map(itemKey => navItems[itemKey]),
    };
  });
}

export async function useNavigation() {
  const { sessionClaims } = await auth();
  const userRole = sessionClaims?.org_role || "org:user";

  const navigationItems = getNavigationItems(userRole);
  return { navigationItems };
}

You’ll see above that we’re creating a function called getNavigationItems and passing this function the userRole from Clerk. We then define the sectionNames based on that userRole, or default to the nav a basic user would see, providing us with a clean fallback.

We then map over those section names and return the title as well as the nested navigation items.

Finally, we define our hook. We get the User’s role from Clerk using the sessionClaims object that is returned with await auth(), thus returning our navigation object, which will look something like this:

[
  {
    text: 'User',
    children: [
      { 
        text: "Todos", 
        icon: <svg>an icon here</svg>, 
        href: "/dashboard/todos"
      },
      { 
        text: "Profile", 
        icon: <svg>an icon here</svg>,
        href: "/dashboard/profile"
      },
      {
        text: "Logout",
        icon: <svg>logout</svg>,
        logout: true
      },
    ]
  }
]

🌟 Why This Works

This setup has some awesome advantages:

Single Source of Truth 📚: All navigation items are defined once, cutting down on duplication.
Composable Structure 🧩: You can create new sections easily by reusing existing sets.
Easy Maintenance 🔧: Shared items only need updates in one place.
Scalable 📈: Adding new roles or navigation items is a breeze.
Type Safety ✅: Using keys helps catch typos and enables IDE autocompletion.
Logical Structure 📂: Sections are organized in a clear, modular way.

Example Usage

Here’s how you might use this navigation structure in a Sidebar component:

File: Sidebar.js

// Sidebar.js
import { useNavigation } from "@/hooks/useNavigation";

function Sidebar() {
  const { navigationItems } = useNavigation();

  return (
    <nav>
      {navigationItems.map((section) => (
        <div key={section.text}>
          <h2>{section.text}</h2>
          <ul>
            {section.children.map((item) => (
              <li key={item.text}>
                <Link href={item.href}>
                  {item.icon}
                  {item.text}
                </Link>
              </li>
            ))}
          </ul>
        </div>
      ))}
    </nav>
  );
}

📝 Best Practices

A few tips to keep your navigation organized and manageable:

📁 Store navigation items in a separate configuration folder.
✨ Use descriptive names for navigation sets and sections.
✅ Use Set to avoid duplicates.
🔒 Set defaults for unknown user

This approach provides a solid foundation for a scalable, maintainable navigation structure. By organizing navigation into modular components, you get a flexible system that grows with your app—without becoming an absolute nightmare to maintain.

Remember, the goal is to strike a balance between flexibility and simplicity. This setup does just that, making it practical for real-world applications. 👌

A Thank You ❤️

Dominic Magnifico — Tue, 18 Jun 2024 21:29:49 +0000

✨ An army of 10,000 of you have hit the follow button next to my name.✨

That's far and away the largest number of people that have knowingly hit a button to engage with me in the 25+ years that I've existed on the internet.

That's a ludicrously large number to me, and it felt like a milestone worth celebrating. 🤘

With that, I just wanted to throw out a whole hearted thank you to everyone here. I've been writing on Dev.to off and on for just over 5 years now and it's been nothing but welcoming, and filled with enjoyable interactions with folks in the community.

Community is hard to find, but when you do find it, nurture it and enjoy it.

Thank you all very much!

Some UX Design Principles Everyone Should Know 🥸

Dominic Magnifico — Tue, 18 Jun 2024 18:13:14 +0000

Hitting the ground running with a new app idea is tough. There are a million things to do and no time to do them. You’ve gone through the “justification” phase, explaining to everyone and their mom why the world needs your application. You’ve documented every single forecast and business plan. Now it’s time to start thinking about actually executing your vision. It all begins with User Experience. Great UX design isn't an afterthought or a “nice to have”; it's an absolute necessity for any application aiming to stand out and thrive. That said, let's dive into some UX design principles that everyone should know.

User-Centered Design 🗣️

First things first: always put your users at the center of your design process. This means understanding their needs, behaviors, and pain points. It's not about what you think looks good; it's about making sure your users can accomplish the goal you’ve set out for them with the least amount of resistance.

Conduct User Research: Surveys, interviews, and usability tests are your best friends here.
Create Personas: Develop detailed profiles of your target users to guide your design decisions.
User Journey Mapping: Map out the steps users take to complete tasks within your application, to identify opportunities for improvement.

Simplicity and Clarity 🧘

Less is more. Seriously. Don't overload your users with information or options. Keep your design clean, straightforward, and intuitive. As users flock to your application, you’ll be able to take their feedback and make well educated, data-driven decisions about what to improve.

Clear Navigation: Make sure users can easily find what they need without getting lost. Don’t hide primary actions behind layers of interaction.
Minimalist Design: Remove any unnecessary elements that don't add value. Truly ask yourself why something exists, and how it aids in users accomplishing their goals.
Readable Content: Use clear, concise language and break up text with headings, bullet points, or some very cool emojis if you’re hip 😎.

Consistency

Like all things, consistency is key. Especially when it comes to creating a seamless user experience. This means maintaining uniformity in your design elements across your website or app.

Design System: I love design systems. There’s nothing better than an organized style guide that includes typography, color schemes, button styles, and all the little components that make your application unique.
Consistent Interactions: Make sure similar actions produce similar results throughout your site. Don’t have twelve different variations of that modal. People notice, and it makes you look silly.
Branding: Keep your branding elements consistent to build trust and foster that brand recognition.

Accessibility

Accessibility needs to be top of mind at the outset of any project. Baking accessibility best practices into the UX and design phase of your application will ensure you’re providing an equitable experience for each and every one of your users, regardless of how they interact with the web. Make sure you’re at a minimum making these considerations:

Alt Text for Images: This is too easy not to be doing. Provide descriptive text for images to assist screen readers.
Keyboard Navigation: Not everyone browses the web with a mouse or a $130 Apple trackpad. Make considerations for those who navigate with a keyboard.
Contrast Ratios: I’m old and this one bothers me more and more. Do a quick check to make your text has at least a AA contrast ratio. There are several tools for this. Pick one.

Feedback and Responsiveness

In our wild world of JavaScript applications, ensuring that a user knows that something is happening, has become more important than in the past. Our applications connect to more third-party services these days, and our users must know that an action they’ve taken is processing. We use these strategies to help with that;

Loading Indicators / Skeletons 💀: Skeleton loaders not only sound cool, they also provide anticipatory design elements that give users a sense of what will be on the page, before the data has fully loaded.
Error Messages: Provide clear, helpful error messages when something goes wrong. There’s nothing worse than a user seeing Uncaught ReferenceError: Invalid left-hand side in assignment or some other nonsense. Give them plain English feedback instead!
Performance Optimization: This is becoming more and more tricky. The more services we integrate, the more complex a database becomes the more creative you have to get to ensure an application is performant.

Emotional Design

This is such a cool concept to us. Emotional design focuses more on creating experiences that evoke a particular feeling from your users. As cliche, as it may sound, this creates a unique connection and keeps your users feeling positive about the service you’re providing them. This can be done in a few ways;

Storytelling: Visual storytelling on the web is an art form. We love expressing our creativity through creating a full-fledged digital experience.
Micro-Interactions: Small, thoughtful animations and interactions tend to put you in a position to entertain and engage your users and drive them to keep coming back.
Human Touch: Incorporate human elements, like friendly language, relatable imagery, or exceptionally witty content, like the content you’re reading right this second.

Iterative Design

Everything is iterative. After you build an MVP, it’s back to the drawing board. Starting the process over and continuously iterating is the only way to keep pace with the multi-billion dollar applications that exist in our world. Stay engaged with your user base, listen to their feedback, and they’ll remain loyal to you.

Usability Testing: Regularly test your designs with real users. This is and always will be something that the tech giants miss out on. Don’t miss the mark here.
A/B Testing: Get super granular with this. A/B test simple language, or small components, and use that information to inform the larger design.
Analytics: Use data to inform all of your decisions. There needs to be a why, and data will uncover it.

Focus on Business Goals

While user satisfaction is paramount, your application should align with your business objectives. All that work you did at the inception of your idea shouldn’t go to waste. The forecasts and the documentation are invaluable, but balance user needs with your goals. No bullet points here, those business goals are yours to define. We’ll be here to help you refine and execute them.

Keep testing, collaborating, learning, and evolving.

Raising a Web Studio Without Selling Your Soul 👹

Dominic Magnifico — Tue, 04 Jun 2024 15:47:31 +0000

Building a business is hard. That’s a pretty obvious statement, but there’s so much nuance to it that it bears repeating. How am I going to get more work? How am I going to finish the work that I have? What about taxes? Did I send out that status update on time? Are my clients properly informed about the status of their projects? Should I start scaling? Shit. It’s a lot to think about. I’ve committed to building House of Giants in a way that ensures it will never become a soulless code farm churning out sub-par websites for profit. Here’s what it’s taken to get us this far.

Avoiding the Scale-At-All-Costs Mind Game ⚖️

I've seen it too many times and to too many awesome companies. The critical point where businesses decide to scale aggressively to take on more work, build faster, churn churn churn. This often means rapid hiring, taking on projects that aren’t the right fit, and pushing quick, generic solutions that don’t scale. Sure, it might bring short-term gains, but it usually leads to long-term headaches. A marked reduction in quality and a noticeable uptick in employee turnover. Nobody is happy doing that work. And the voices of the passionate few get drowned out by the shrieks of account managers making promises nobody can keep.

House of Giants was built to avoid these distractions. We focus on sustainable and thoughtful growth, putting everything we have into the work we love.

Personalized Solutions Over One-Size-Fits-All 👖

Another massive issue with traditional agencies is their tendency to use the same set of cookie-cutter tech for everyone, with little to no thought into how that tech should grow with a business. This approach might make some processes smoother, but it often fails to address the unique challenges each client faces.

When we start a new project, we dive deep into our partner’s business, objectives, hopes, dreams, and desires. We conduct thorough discovery sessions to understand the specific challenges and goals of each project we take on. This means asking the right questions to get to the root of our partner’s issues and finding the best way to address them.

Every project is different. Sometimes the solution is a robust content management system; other times, it's a custom web application or a mix of several integrations. We tailor our technology recommendations to fit each of our partner’s needs, ensuring the solution we provide them can grow and evolve with their business.

Emphasizing Collaboration and Partnership 🤝

I can’t tell you how many times I’ve seen people passed from account manager to project manager, to executive and then back down to the production team before any meaningful collaboration has even begun. It’s exhausting, and business owners shouldn’t have to go through that when embarking on a website build. This only serves to break down communication and ensure that some key feature or functionality is built poorly, or not at all.

House of Giants prides itself on maintaining a small, supremely passionate team. Maintaining the small but mighty approach allows us to work closely with our partners, fostering genuine collaboration and partnership. This enables us to truly integrate with our partners and become an extension of them. We find immense satisfaction in understanding the issues of our partners and finding creative ways to solve them.

Building a Flexible Foundation 🧘

We build solutions that solve our partners’ immediate problems and adapt as their business evolves. This means choosing technologies that are flexible and scalable, allowing for growth and change without needing a complete overhaul.

For small business owners, having a flexible technology foundation is crucial. Markets change, customer bases shift, and businesses need to adapt quickly. Our approach ensures that our partners are never locked into a single solution but have the tools and flexibility to pivot as needed.

Staying Connected to the Work 🔌

One of my biggest fears in scaling House of Giants is losing touch with the production work. So many business strategists and YouTube evangelists advocate for scaling to free up the owner’s time, but this often results in a massive disconnect from the fun of the production. If we’re not enjoying at least some of what we do daily then why are we doing it at all? Every single time, when leadership becomes disconnected from production, it results in a painful tone-deaf existence and yields massive distrust from anyone else within the production team.

To combat this, I stay involved and thrive in the production process. This helps me maintain a clear vision of how House of Giants can improve and innovate. It also ensures that I remain connected to the quality of our work and the happiness of the partners and colleageues we choose to work with.

All this is to say that building a successful web studio doesn’t mean losing touch with your values or the quality of the work you produce. By avoiding the scale-at-all-costs mentality, focusing on thoughtfully built solutions, fostering collaboration, and staying intimately familiar with the production process, you can create a studio that not only thrives but also delivers exceptional value to your partners.

Running a web studio, or any business for that matter, is hard as hell. But with the right approach, it’s possible to grow sustainably while maintaining the integrity and quality that sets you apart. Let’s build something great together, without losing sight of what actually matters. ❤️

The Authenticity Wars - SEO Strategies In The Age Of AI 🤖

Dominic Magnifico — Mon, 15 Apr 2024 14:43:45 +0000

SEO was always one of those things that made me cringe every time I heard the phrase. I always envisioned cramming keywords into content just for the sake of their existence on the page. Endlessly looping phrases like “Denver web development” or “WordPress Development Denver web dev” are unnatural and meaningless. This practice inevitably left site visitors with information that didn’t convey anything useful.

Luckily these days authentic content that genuinely serves your audience’s needs inherently ranks higher and performs better than the keyword-stuffing days of the past.

The Dark Ages 😨

Since the dark days of keyword stuffing and aggressive backlinking, SEO and the algorithms that drive the machine have evolved to prioritize content relevance over keyword frequency. This is such a welcome change from how aggressively agencies were working to game the system, trying to outsmart Google to rank #1 for “Denver web development design Denver web agency”. A notable shift occurred with the introduction of Google’s RankBrain. This AI algorithm works to understand search queries and deliver relevant results by analyzing how users interact with the search results themselves, and learn from that interaction. Before RankBran, this was done manually by developers and prompted (virtual) riots anytime the algorithm changed.

After learning about this change, and understanding that RankBrain increases or decreases the importance of various SEO metrics based on the keyword, I became slightly more satisfied with the state of SEO. It’s a step in the right direction to serve results based on relevancy rather than keyword density. It also forces us to generate content that is genuinely useful and engaging, which results in a better experience for the end user.

What is Authenticity? 🤷

I did a little research for this post trying to find examples of truly authentic content, which by the way, is becoming increasingly more difficult in the age of ChatGPT (I’m guilty of using AI to write content from time to time because god damn is it hard to organize the thoughts in my brain into words on a page). But I came across Tim Urban’s site Wait but Why and started reading. Apparently like 20 minutes have passed since I stumbled across the site. I wanted to stay there, and keep reading because the content was genuine human experience and commentary. This is something that’s lost in our industry all too easily. We worked hard at House of Giants to tailor our voice, and we get complimented on it almost every time we speak to a prospective partner. Using your genuine voice in your content, no matter how boring the subject matter may be, is going to be increasingly important to encourage people to stay on your site and engage with you and your business.

Black Hat SEO 🎩

I would have much rather used a fedora emoji for this section if one existed. In any case, if you’re not convinced by my heartfelt call to action about authenticity, then maybe the scared straight approach is a better one for you. Since the SEO grifter became popular ten-ish years ago, search engines have become wise to the games that were being played. These days keyword stuffing, excessive backlinking, cloaking, link farms, and content automation are all events that search engines like Google are getting better at detecting. Some SEO companies will employ varying levels of these strategies to give a quick, seemingly authentic boost in rankings for their clients. Proving their success they take their payment and run. Over time, as these strategies get picked up by Google, a site that employs these doomed strategies may face drastically reduced visibility and overall credibility. There’s no doubt that if you care about your business, you care about the perception of your business too. Users can tell when content isn’t genuine, and that has an effect on your reputation.

Let’s Find Authenticity Together 💬

I challenge you to find genuinely authentic content sources. What makes them successful, what makes you want to keep reading? Share them with us. The more automated the world gets the more we digress from the awe of the infinite community that the internet promised us. Let’s encourage writing that resonates with us all so we can learn how to be more authentic ourselves.

🧐 Rethinking WordPress: The Pros and Cons of Going Headless

Dominic Magnifico — Tue, 02 Apr 2024 17:02:57 +0000

Ah yes, the first quarter of the year is done. Marketing budgets have been set, and for some, that means embarking on the journey of a website rebuild. You’re familiar with WordPress, but your experience with it in the past has been harrowing. Bloated, slow, a pain in the ass to update. You might have developers on one hand shouting from the rooftops to use anything other than WordPress. On the other you have some pushing pre-built templates in your direction as if they’ve crafted them from marble themselves. It’s a lot to process.

I want to take the opportunity to write a few posts that provide some insight into considerations I make when choosing a technology stack for projects at House of Giants. Today, we’ll explore the differences between a traditional WordPress build and Headless.

The Traditional: Ol’ Reliable WordPress

Traditional WordPress builds are rich in features and supported by a robust community, making it a solid choice for many projects. Let’s take a look at some of the positives that make traditional WordPress builds a compelling option for many:

Pros:

⚔️ Good Themes Go Far: Well-crafted themes are hard to come by, and finding one of these gems isn't always straightforward. But when you do, the benefits can be well worth it. Great SEO, performant, and accessible, a thoughtfully built WordPress theme will last you years, and enable you to seamlessly manage your content.
🦑 A Community of Giants: One of WordPress's most invaluable assets is its vast, well-established community. This network of users and developers creates an environment where troubleshooting becomes less intimidating and far more manageable.
📡 Timeless Technology: Traditional WordPress is built using a server-side rendered approach, where PHP is responsible for rendering the site. This means all of your content is easily available to be crawled by Google. The result is classic, easy-to-read HTML, CSS, and JavaScript.
🛋 A Comfortable Dashboard: WordPress has always provided an excellent editing experience for folks who need it. Pair this with the illusive well-built theme, and managing your content can become as stress-free as possible.

On the flip side, a traditional WordPress build isn't without its flaws. Certain aspects can hinder site performance and flexibility. We have to consider these factors when choosing a technology stack for our partners. Here's a closer look at some of the cons associated with a traditional WordPress build:

Cons:

⚡️ Plugin Overload: The allure of plugins is undeniable, offering tons of features and customizations. However, this can quickly become the bane of all existence as casually adding plugin after plugin will weigh your site down. The result is a sluggish theme that not only tests the patience of your users but inevitably will affect your revenue.
📊 The Data Dilemma: WordPress's default data structure, designed to be versatile, often ends up delivering more than what's needed. It uses a bit of a catchall approach that returns all the data it has, rather than the bits and pieces you need. This overabundance of data can further strain your site's performance, making efficiency a casualty of excess.
🙆 Flexibility vs. Rigidity: While WordPress offers a broad canvas for development, certain creative efforts can be difficult. Were you dreaming of seamless page transitions or weaving complex animations into your site? Working this into the server-side rendered magic of PHP may create some speed bumps during development. These aspirations, though achievable, demand a deeper development effort, pushing the boundaries of WordPress's traditional setup.

These challenges highlight the need for a thoughtful approach to WordPress development, where the balance between functionality and performance is carefully managed.

Let’s Go Headless

Venturing beyond the traditional WordPress framework introduces us to the fairly trendy realm of the Headless CMS. Here, the frontend presentation layer is decoupled from the backend content management system. In this context, WordPress serves purely as a repository for your content, accessible via API. This separation allows developers the freedom to use any frontend technology they prefer, from React to Vue, or even HTMX. Thus, enabling the creation of dynamic, fast, and highly personalized user experiences. A Headless CMS represents a leap toward flexibility and performance, redefining how we think about content delivery and site architecture. Let’s break down the pros and cons of this approach:

Pros:

🎉 Freedom of Tech: A headless build enables you to choose the stack you want. There are a million to choose from, and a lot of times it comes down to the developer experience. When choosing a stack, however, it’s important to ensure that it’s something that will be around for more than a few months. Most clients will need that stability.
🏎 Speed, I Am Speed: With the ability to statically generate pages, or even individual components, Headless builds have the opportunity to be faster than fast. (I made two references to the cinematic masterpiece that is Cars in this one bullet point. Impressive.)
💅 Speed AND Style: Pair that speed with as many crazy page transitions and complex animations as you like. Leveraging JavaScript instead of PHP to render the front end makes all that parallax I know you want to add much easier to accomplish.
⚖️ Scalable by Nature: Traffic spikes? Headless laughs in the face of the traffic you’ll get off that viral TikTok you made promoting it.
🏰 Fort Knox Level Security: With less surface area for attacks, and the ability to obscure the domain used to manage your content, you’ll set yourself up for some additional security with a Headless build.

Cons:

🎓 Learning Curve: There’s no doubt that a headless build has a bit more of a learning curve. There are necessary connections that need to be made between the frontend and the backend that go beyond the tasks in a traditional build.
🤡 Setup Shenanigans: Because your frontend and backend are decoupled, they end up needing to be hosted in different places (however products like[Atlas from WPEngine]are making this a bit easier). Managing code in two different places presents some unique challenges.

Making the Call

So, which road should you take? If you're running a content-heavy site that values ease of management over everything else, traditional WordPress may be a great choice. But if you’re aiming for speed, and a tailor-made user experience, headless might suit your needs best.

In the end, it's not just about choosing a CMS. It’s about choosing the right tool for the story you want to tell and the experience you want to create. Whether you stick with WordPress or go headless, the best choice is the one that aligns with the project needs, goals, and, importantly, the needs of the end users who will interact with your site.

10 Web Dev Qualities That Actually Matter 🦄

Dominic Magnifico — Thu, 28 Mar 2024 16:22:36 +0000

When it comes time to build or expand a team, we often encounter the same tired songs;

“How’s the culture fit?”,

“What do their GitHub contributions look like?”

And let’s not forget the parade of live work examples 🙄. While these elements hold some value, they often overshadow what truly energizes a development team. We’re on the lookout for individuals who are not just looking for a job but are eager to build cool shit, learn relentlessly, and dive into the depths of collaboration and shared knowledge.

1. Grasping the Holy Trinity

The cornerstone for most web devs is a solid understanding of HTML, CSS, and vanilla JavaScript. This forms the bedrock upon which all other skills are built, allowing for versatility and adaptability in the face of evolving project needs. The commitment to continuous learning is what inevitably distinguishes a good developer from a great one.

2. Problem-Solving Skills

The essence of development lies in tackling challenges that may seem daunting at first. The ability to dissect a problem logically and creatively is non-negotiable. But more than finding a solution, understanding the path to that solution enriches a developer, enabling them to apply these insights to future challenges.

3. Communication Skills

Clear communication helps to ensure a project moves smoothly. It’s not just about being articulate but about translating the complex language of code into narratives that stakeholders of any technical level can grasp. This skill is equally vital for effective documentation and ensuring that knowledge is accessible to anyone who may encounter the project.

4. Collaboration and Teamwork

The magic 🪄 of development often happens in the spaces between us. The ability to work within a team, to be receptive to feedback, and to contribute to the collective knowledge pool is what propels a team forward. It’s the shared victories and learnings that forge stronger connections between you and your peers.

5. Curiosity and Passion for Learning

This is the quality I search for most in people. In a field like ours, stagnation is the enemy. A genuine passion for technology and a hunger to keep abreast of the latest trends and tools are invaluable traits. They ensure that a developer not only keeps pace with the industry but also brings fresh perspectives and ideas to the table.

6. Attention to Detail

The devil is in the details, especially in the final 10% of a project where the most intricate challenges lie. A keen eye for detail ensures that projects are not just completed, but polished to shine, embodying quality and care. All the hard work that leads to a product or project launch boils down to this last 10%. The attention to detail put in up to that point can make the final push delightful, or miserable.

7. Time Management and Organization

The ability to juggle tasks 🤹‍♂️, prioritize effectively, and meet deadlines is crucial to your team’s collective success. It’s about delivering quality work within the constraints of time, without dropping a single ball.

8. Adaptability and Flexibility

When thinking about both client and product work, the ability to adapt and embrace change is vital. It’s vital to understand that a client, or the collective stakeholders in a product, may change and shift their expectations and vision. Developers must be willing to navigate these changes with grace and flexibility instead of throwing up their hands in frustration.

9. Creativity and Innovation

At its heart, development is a creative pursuit. It’s about thinking outside the box to devise innovative solutions that push the boundaries of what technology can achieve, enhancing both the project and the user experience.

10. Empathy and User Focus

Ultimately, the end goal of any project is to serve the user, not the client or the stakeholders. Empathy for the user’s experience, prioritizing their needs, and ensuring that the solutions we build genuinely solve problems is the hallmark of exceptional development work.

As we navigate the complex terrain of hiring developers and building teams, let's shift our collective focus toward these essential attributes. It's not just about filling a position but about enriching our teams with individuals who bring more than just technical skills to the table.

Have you encountered these attributes in your new hires, or are there others you hold in high regard? Share your experiences and insights below. Let’s cultivate a community where knowledge and passion for development are celebrated and shared!**

Five Syntax Highlighting Plugins for NextJS that aren't Terrible 🎨

Dominic Magnifico — Thu, 14 Mar 2024 17:06:41 +0000

As a connoisseur of artisanal tech blogs myself, I’ve found myself lost in the world of syntax highlighters, and after building our new blog here at House of Giants, I’ve found myself at a crossroads: which syntax highlighting plugin do we embrace? Fear not, for we shall explore the crème de la crème of syntax highlighting plugins, dissecting their virtues and shortcomings, and offering you a skeleton key for setup.

1. PrismJS

Pros:

PrismJS used to stand as a colossus, offering an unparalleled breadth of themes and languages. Customizability is its crown jewel, enabling you to tailor the aesthetics to your blog’s unique style.
Performance-wise, it’s a lightweight contender, ensuring your blog remains quick and bloat-less.

Cons:

The setup might summon a bit of a Herculean effort, particularly for those less acquainted with Webpack configs. I despise messing with a Webpack config 😬.
Seemingly inactive. Prism v2 began development in August of 2022 but development has since seemed to stall out. The last update was almost two years ago.

Setup Snapshot:
From the Prism Docs:

If you want to use Prism with a bundler, install Prism with npm:

$ npm install prismjs

You can then import into your bundle:

import Prism from 'prismjs';

To make it easy to configure your Prism instance with only the languages and plugins you need, use the babel plugin, babel-plugin-prismjs. This will allow you to load the minimum number of languages and plugins to satisfy your needs. See that plugin's documentation for configuration details.

2. Highlight.js

The Jack-of-All-Trades

Pros:

Highlight.js is praised for its out-of-the-box readiness, and eagerness to embellish your blog without demanding much in return.
Support for over 190+ languages. If it’s code, it can be highlighted.

Cons:

Themes exist, there are close to 500 themes to choose from, but customizing outside of those themes may be a bit cumbersome.
Requires additional setup to be integrated into Markdown blogs.

Setup Snapshot:

npm i highlight.js

Simplicity reigns. Include the Highlight.js library and desired stylesheet in your project, most simply in your _app.js file, or for our Next 13+ friends, your default layout.js file.

import 'highlight.js/styles/default.css';

Once the styles are imported you can register the languages you’d like to highlight and create a Component to apply syntax highlighting to the code within.

import hljs from 'highlight.js/lib/core';
import javascript from 'highlight.js/lib/languages/javascript';
hljs.registerLanguage('javascript', javascript);

export default function CodeBlock() {
    const myCode = "console.log('Hello World!')";
    const myHtml = hljs.highlight(myCode, { language: 'javascript' }).value;
    return (
        <pre>
            <code dangerouslySetInnerHTML={{ __html: myHtml }} />
        </pre>
    );
}

3. react-syntax-highlighter

Pros:

As a native citizen of the React ecosystem, it integrates seamlessly with NextJS, like a hand fitting perfectly into a glove.
Offers a broad selection of themes and the flexibility to dynamically render code blocks without the need for server-side processing.

Cons:

Its dependency on the React framework might be considered overkill for projects seeking the utmost in performance and minimalism.

Setup Snapshot:
Fairly similar to Highlight.js.

$ npm install react-syntax-highlighter --save

Create a new component, and import the package, along with the theme you’d like to use:

import { Prism as SyntaxHighlighter } from 'react-syntax-highlighter';
import { solarizedlight } from 'react-syntax-highlighter/dist/esm/styles/prism';

const CodeExample = () => {
    const codeString = `function add(a, b) {
    return a + b;
  }`;

    return (
        <SyntaxHighlighter language="javascript" style={solarizedlight}>
            {codeString}
        </SyntaxHighlighter>
    );
};

From the docs as well:

This example demonstrates how to import the Prism version of the syntax highlighter along with a specific style. The Prism version is optimized for JSX and other web technologies, making it a popular choice for React developers.

4. Shiki

Pros:

Utilizes the same syntax highlighting engine as VS Code, promising a result that’s not just visually consistent with your development environment but also striking.
Offers an impressive range of themes and the ability to extend with custom VS Code themes.

Cons:

Shiki’s richness comes with a cost—additional setup steps that may deter those in pursuit of simplicity.

Setup Snapshot:
Shiki provides straightforward setup instructions to highlight code passed to it via helper functions, that can then be used within React components like the others listed above. Where Shiki pulls ahead is its integrations. One I particularly like is the Rehype integration:

$ npm install -D shiki @shikijs/rehype

After installation, you can pare Shiki with Remark and its various modules to highlight your markdown files. I struggled with this myself, but what usually ends up having to happen, within a Next application this file will live as a helper function that converts your markdown to HTML.

import { unified } from 'unified';
import remarkParse from 'remark-parse';
import remarkRehype from 'remark-rehype';
import rehypeStringify from 'rehype-stringify';
import rehypeShiki from '@shikijs/rehype';

export default async function markdownToHtml(markdown) {
    const file = await unified()
        .use(remarkParse)
        .use(remarkRehype)
        .use(rehypeShiki, {
            // or `theme` for a single theme
            themes: {
                light: 'vitesse-light',
                dark: 'vitesse-dark',
            },
        })
        .use(rehypeStringify)
        .process(markdown);

    return String(file);
}

5. MDX

Pros:

MDX transcends traditional markdown, allowing you to use JSX within your blog posts. This means you can directly leverage React components for syntax highlighting, offering an unparalleled level of flexibility and interactivity.
Perfect for those who wish to blend technical writing with React-powered features, from interactive diagrams to live code editors.
Next has an MDX plugin and can be easily integrated into existing Next sites.

Cons:

With great power comes great complexity. MDX’s learning curve is steep, requiring familiarity not just with markdown, but also with React.

Setup Snapshot:
I’m just going to link you to the comprehensive Next documentation for this one.

In our quest to adorn our blogs with beautifully highlighted code, the path we choose is as much about personal preference as it is about technical requirements. Each plugin offers a unique set of features, each containing unique narratives and complexities. May this guide serve as a compass, leading you to the syntax highlighting plugin that balances the annoyance of build processes and integrations.

Which syntax highlighter has proven itself to you, and are there any that you believe deserve exile from our codebases? Let me know which method of syntax highlighting has proved the easiest to set up, or you can be like me and share your disdain for messing with a Webpack config. I'm fine with either 🤷