Forem: Christopher Codes

Do we still use StackOverflow?

Christopher Codes — Sun, 08 Mar 2026 22:48:06 +0000

AI Is Not Your Product. It’s Just a Feature.

Christopher Codes — Thu, 15 Jan 2026 18:48:40 +0000

Every frontend project lately seems to start with the same sentence:

“We’re thinking about adding AI.”

Cool. But why?

After building real products that integrate AI, here’s the hot take I’ve landed on:
AI doesn’t make a product valuable. It only amplifies what’s already there.

If the product is weak, AI just makes that more obvious.

We’re in this phase where people are trying to build AI-first tools, and most of them feel backwards. The UI is vague. The workflows are unclear. The value prop is “trust the model.” And once the novelty wears off, users are left wondering what problem the tool actually solved.

That’s not a model issue. That’s a product issue.

The Best Products Don’t Need AI to Make Sense

Here’s something I’ve noticed working on frontend-heavy apps:
If your product needs AI to be useful, it probably isn’t ready.

The strongest products I’ve worked on already had clear value before AI ever touched them. Users understood what the app did. They knew where to click. They knew what success looked like.

When AI showed up, it didn’t replace the experience. It just smoothed it out.

Less friction. Less typing. Faster feedback. Better suggestions.

That’s it.

No magic. No “ask anything.” No black box UI where the user hopes the model guesses right.

Frontend Engineers Feel Bad AI Immediately

Bad AI integrations show up in the UI first.

You see it when the interface turns into a single text box with a vague prompt. You see it when the app can’t explain what just happened. You see it when the user doesn’t know whether to trust the output or double-check everything.

That’s not empowering. That’s stressful.

Good frontend design is about clarity. Predictable states. Intentional flows. AI works best when it stays inside those boundaries.

When AI becomes the assistant, not the decision-maker, the UI stays grounded. The user stays in control. And the product feels reliable instead of experimental.

AI Should Reduce Work, Not Responsibility

This is the line I don’t like seeing crossed.

AI is great at speeding things up. It’s great at drafting, summarizing, suggesting, and filling in gaps. What it’s not great at is owning outcomes.

The best use cases I’ve seen don’t ask AI to do the job. They ask it to help the user do the job faster.

That distinction matters.

Users don’t want a product that thinks for them. They want one that respects their time.

The Real Winners Are the “Boring” Products

Here’s the uncomfortable truth:
The tools people rely on every day are rarely exciting.

They’re consistent. Predictable. Clear. They do one thing well.

AI doesn’t replace that foundation. It sweetens it.

The products that will last aren’t the ones screaming about intelligence. They’re the ones quietly using AI to remove friction from workflows that already work.

As builders, especially on the frontend, our job isn’t to chase hype. It’s to ship products people trust.

AI is just another tool in that toolbox. A powerful one, sure. But still just a tool.

If AI makes the experience clearer, faster, or smoother, it belongs.
If it makes the product harder to understand, it doesn’t.

Simple as that.

Just Launch Already! 🚀🚀

Christopher Codes — Sun, 30 Mar 2025 22:07:37 +0000

Sip some coffee and ponder on this for a sec…

I know you probably hear this all the time as devs but we should constantly be reminded of this as we start new projects and work on existing ones. There are a lot of studies that show that projects launched before they are perfect are better off in the long term because feedback is acquired while building, instead of after. So here are a few things you can apply to your projects starting today to help you launch quicker without feeling like your work isn’t “good” enough.

1. Launch your MVP without fear

Fear comes in all shapes and sizes and can creep up quickly and have compound growth as time goes on. It could be the fear of someone hating your product. The fear of pushing bad code to production. The fear of bad comments or reviews. Just know there is no need to fear because most of these things never happen, so don’t hide from a not promised future.

2. Save the features for later

It is really easy to work towards your MVP and notice opportunities for improvement and include them in as a requirement for your MVP. As your feature / opportunities list grows your MVP turns into a feature heavy project that no one asked for. So much time is wasted on this list. The MVP should only be items required to solve the problem and once the problem is solved leave the “cool ideas” for later or until multiple customers request it.

3. The Sooner the Better

You could wait until the “perfect time”, but better, you could launch now and build to the perfect time. There are a lot of benefits to launching now. Gain feedback, generate your first dollar, acquire customers, validate ideas, validate the market/audience. Did I mention you can generate revenue in the process??

In my years of running an agency and working on side projects, I have found that launching NOW is better than launching never. To my surprise, your potential customers have very low expectations. Just look at Craigslist. Anybody remember the first version of Facebook? They launched solving a couple problems and everybody loved it. Most of us would never launch something that looks as simple and bad as Craigslist, but the difference is they launched and iterated versus, iterate and never launch. Now please understand I am not vouching for the current versions of Facebook or Craigslist but the difference is we have an opinion about them, and no one has an opinion on the idea you never launched, so go be a billionaire, and just launch already!

Let me know your thoughts on launching or share a project you’ve been sitting on that you haven’t launched yet! I’ll go first -> http://app.thenextbill.com

I hope you enjoyed this, I speak way more on Twitter if you’re into that kind of thing! https://twitter.com/christoph_codes

Tanstack Router's file generation is 🔥!

Christopher Codes — Thu, 27 Mar 2025 17:07:11 +0000

Why I recommend Optimizing File and Folder Composition for Server Components First!

Christopher Codes — Wed, 26 Mar 2025 15:40:00 +0000

With Next.js just announcing version 15, and evolving rapidly, server components have become a core focus. The new data-fetching paradigms and routing enhancements further solidify the framework’s push toward server-side rendering (SSR) as the default approach. To keep up with these changes, I’ve adopted a mindset of “server components first” while managing client-side functionality separately. Here’s why I believe this approach should be embraced by more teams, along with practical guidelines for structuring Next.js projects.

The Mindset: Server Components First

Server components are emphasized to allow developers to fully leverage SSR while also offering client-side flexibility. By default, the assumption is that all pages will be server-rendered, benefiting:

Performance: Offloading rendering to the server reduces the amount of JavaScript that runs on the client, leading to faster load times and a smoother user experience.
Data Fetching: Fetch data directly within server components using standard fetch and async/await. This approach takes full advantage of SSR without needing complex configurations, letting the server handle the heavy lifting while keeping the client-side lightweight.
SEO: Server-rendered pages deliver fully populated HTML to search engine crawlers, improving indexing and boosting search engine rankings.

Handling Client-Side Functionality Separately

Client-side interactivity remains crucial for certain features, such as form handling, animations, or dynamic state management. With Next.js, you can manage this by using the 'use client' directive, which declares that a component should be rendered on the client side. Here’s how to structure this:

Isolate client functionality in separate components: Create individual files for client-specific components and include the 'use client' directive at the top.
Leverage composition patterns to manage complexity: Utilize the composition patterns described in Next.js documentation to maintain clarity between server-rendered and client-rendered components. This ensures that client components are only introduced when necessary.

For example, consider a page that includes a server-rendered list but also requires a client-side filter:

page.tsx: This is the server component for rendering the list.
ProductFilter.tsx: A client component with the 'use client' directive to manage filter interactions.

What If There Are No Server-Specific Needs?

When server-side rendering isn’t required, you can add the 'use client' directive directly to the page.tsx file. This approach is suitable for scenarios where a page's content doesn’t benefit from being pre-rendered on the server, such as purely interactive dashboards or forms.

Structuring Your Next.js Project in Version 14+

To keep the project organized, follow a structure that clearly separates server and client components, utilizing composition patterns where appropriate. Here’s an example:

app/
  ├─ products/
  │   ├─ page.tsx                 // Server component for rendering the product list & imports ProductList.tsx
  │   ├─ ProductList.tsx          // Client page with 'use client' directive & imports ProductFilter.tsx
  │   ├─ ProductFilter.tsx        // Client component with 'use client' directive
  ├─ checkout/
  │   ├─ page.tsx                 // 'use client' directive if entirely client-side

This folder organization facilitates using different composition patterns like partial hydration (splitting pages into server and client sections) or lifting state management into a client component where necessary.

Data Fetching in Next.js

The new recommended way of data-fetching strategy involves:

Using fetch directly in server components: Data-fetching operations are performed inside server components, making SSR straightforward.
Async functions for data retrieval: Server components can use async/await for data-fetching without extra configurations. An example implementation:

// app/products/page.tsx
import React from 'react';

export default async function ProductsPage() {
  const res = await fetch('https://api.example.com/products');
  const products = await res.json();
  return (
      <div>
        <h1>Product List</h1>
        <ul>
          {products.map((product) => (
            <li key={product.id}>{product.name}</li>
          ))}
        </ul>
      </div>
    );
}

Composition Patterns for Enhanced Control

According to Next.js’s documentation on composition patterns, different approaches can be taken to balance server-side rendering and client-side interactivity:

Partial Hydration: Split a page into server and client components, keeping most content server-rendered for performance while allowing dynamic sections to be interactive.
Client Component Islands: Place interactive islands (client components) within server-rendered content. This approach helps reduce the amount of JavaScript needed on the client side while still providing rich interactivity.
Server-Rendered Shells: Build the outer structure (shell) of your application with server components and populate it with client components for specific sections that need user interactivity.

These patterns ensure that client-side JavaScript usage is minimized, leading to better performance and user experiences.

Why Adopt This Mentality?

Improved Performance: By defaulting to server components and the new data-fetching approach, your application will benefit from optimized SSR, resulting in faster page loads.
Enhanced SEO: Server-rendered pages provide search engines with fully populated HTML, making it easier to index content.
Reduced Client Bundle Size: Isolating client logic with 'use client' minimizes JavaScript sent to the browser.
Simplified Development: The new data-fetching approach integrates directly into server components, eliminating the need for helper functions.
Scalability and Maintainability: Using composition patterns makes it easy to scale features and manage rendering logic.

Conclusion

The shift toward “server components first” in Next.js aligns perfectly with the composition patterns described in the Next.js documentation. This approach simplifies SSR while maximizing performance and SEO benefits. By adopting this mentality and following the composition strategies, teams can quickly build scalable, fast, and optimized Awesome applications.

Happy coding 👌

Wallet » Where your credit lives | Redis Hackathon Submission August 2022

Christopher Codes — Tue, 30 Aug 2022 05:41:00 +0000

Overview of My Submission

I have built a personal credit card wallet that consolidates all of your credit card data to view in one glance.

The inspiration comes from dealing with multiple credit card companies and having to login to each one of them separately and also while trying to manage credit and calculate debt to income is always difficult because all of the data is not in one place.

Live Here!

wallet-82c94.web.app

Submission Category:

MEAN/MERN Mavericks

Language Used

Node.js & React.js

Link to Code

christoph-codes / wallet

A personal credit card wallet for the DEV Redis Hackathon. August 2022

wallet

A personal credit card wallet for the DEV Redis Hackathon. August 2022

Wallet

How it works

You create an account with a username and password which writes to Firebases authentication server.

The data returned from Firebase is then saved in the Redis database with some additional fields the app will later request.

Once the initial account creation process is complete, you are taken to your dashboard where you will have the ability to add your credit cards.

After a card is entered you can view its data and update at any point.

You can filter credit card transaction data based on certain data points.

How the data is stored:

Users

first name (chris)
last name (jones)
authentication id (unique, generated by firebase)
email (john@doe.com)
cards (an array of card ids) ['s9djf93j2pii','jasodi923hdo']

Cards

name (Cap1 Travel Purchases)
issuer (visa)
limit (1000)
balance (500)
expirationDate (0667 formatted to 06/67)
…

View on GitHub

Reverse Recipe

Christopher Codes — Thu, 13 Jan 2022 06:32:32 +0000

Overview of My Submission

The purpose of our app is to search our MongoDB database for a list of recipe's based on a list of entered ingredients. We connected our Mongo Realm account with serverless functions and made GraphQL calls to retrieve the data from our database. We plan for a lot more to come and plan to continue working on it post Hackathon. Feel free to check it out!

Submission Category:

Choose Your Own Adventure

Link to Code

Link to code

Additional Resources / Info

Home Page

Recipe Results Page

Single Recipe Page

Collaborators

@tkcwebdev - Chris
Github for Chris - Chris
@cmolisee - Cody
Github for Cody - Cody