DEV Community: Glover

I Built a Mac App That Does One Thing: Let You Clean Your Keyboard

Glover — Sun, 29 Mar 2026 10:36:00 +0000

Every MacBook owner knows this moment. You grab a cloth to wipe your keyboard, and the second you touch a key, Spotlight opens. You brush the trackpad, the cursor flies across the screen. You wipe the function row and your volume changes, your brightness drops, your music skips. You're trying to clean the machine, and the machine keeps interpreting your cleaning as commands.

It sounds trivial. It's not.

This small frustration is the reason I built Mac Pause. And the process of building it taught me a lot about how macOS actually works under the surface.

There's No "Cleaning Mode" for Your Mac

Think about it. Your Mac has Do Not Disturb, Focus modes, screen savers, sleep timers, and a dozen other states it can enter. But there's no mode that says: "Hey, I'm wiping my keyboard right now. Please ignore everything for the next thirty seconds."

The workarounds all have problems. You can shut down completely, but that's overkill for a quick wipe. You can lock the screen, but keys and controls still register in ways you don't expect. You can try to be careful, but "carefully cleaning a keyboard" kind of defeats the purpose.

What was missing was simple: a temporary, safe way to suspend all input on macOS so you can touch any surface without consequences.

The Concept Was Tiny on Purpose

Mac Pause was designed to be small. Not small as in "MVP I'll expand later." Small as in: this is the entire product.

The idea was a menu bar utility with one job. Start a cleaning session. Block keyboard and pointer input. Exit only when the user deliberately unlocks it. Include a failsafe timeout in case anything goes wrong.

That's it. No settings panels with forty options. No subscription. No system tweaker ambitions. One sentence should explain what the app does. If it can't, the scope is wrong.

I believed (and still do) that the best utilities are the ones that feel obvious once they exist. "Of course there should be a cleaning mode for your Mac." That's the reaction I was going for.

Then I Started Building It, and macOS Had Other Plans

The concept was straightforward. The implementation was not. macOS is a sophisticated operating system with deep security layers, and building an app that suppresses input touches several of them at once.

Permissions Are the First Wall

An app that wants to intercept and block keyboard and mouse input can't just start doing it. macOS requires explicit user permission, specifically Accessibility and Input Monitoring access.

That's entirely reasonable from a security standpoint. But from a product standpoint, it creates immediate friction. Your brand-new utility that does "one simple thing" now needs the user to open System Settings, find the right section, toggle the right switch, and potentially restart the app.

Permission handling isn't a side feature. It's a core part of the user experience. I learned this early. If the permission flow is confusing or feels aggressive, people won't trust your app enough to grant access.

"Block Input" Isn't Actually One Operation

At first glance, "pause keyboard and mouse" sounds like flipping a switch. On macOS, it's more like intercepting a river at multiple points.

For a regular (non-kernel) app, the practical approach is event suppression: you intercept input events and prevent them from reaching the rest of the system. That means the app has to catch the right categories of events, suppress them consistently, and still preserve a reliable unlock path.

That last part was non-negotiable. A utility that blocks all input and then gets stuck has turned your laptop into a brick. Mac Pause needed both an intentional unlock mechanism and a hard timeout that would always restore control, no matter what.

The Function Row Didn't Play by the Rules

Here's where it got interesting. I had regular key blocking working. Mouse input was blocked. Everything seemed fine. Then I wiped the function row during a test and the volume changed.

Turns out, function keys on macOS (brightness, volume, media controls) don't always travel through the same event pipeline as regular keyboard input. Some of them arrive as legacy system-defined events, which is a different path entirely. So "keyboard blocked" didn't actually mean "all keyboard-looking input blocked."

This is the kind of thing that makes system utilities tricky. The first 90% of the problem is solvable in a weekend. The last 10% is where your assumptions get tested by how the OS actually works.

How Do You Unlock Something That Blocks All Input?

This was a subtle design problem. The obvious answer is "press Escape to exit." But if you're cleaning your keyboard, you probably want to wipe the Escape key too. A single-key exit means there's one key you can never touch during cleaning.

I landed on a hold-based chord: Right Shift + Escape. You hold both keys for a short duration to unlock.

That solved several problems at once. It was unlikely to trigger accidentally during cleaning. It let users clean the Escape key by itself (just don't hold Right Shift at the same time). And the hold requirement made the action feel intentional, which matters for something safety-related.

A tap would have been too risky. People brush keys while cleaning. A deliberate hold is a different kind of input, and that distinction is the whole point.

The Setup Screen Almost Became the Problem

One of the more ironic bugs I hit wasn't in the input blocker at all. It was in the permission setup flow.

At one point, the permission prompt behaved too much like a system-level overlay. It filled the screen. It was hard to dismiss. The very app designed to prevent your Mac from feeling "trapped" was trapping people during setup.

I rebuilt the setup flow into something calmer: a smaller utility window, clear guidance about what permissions were needed and where to find them, and honest messaging when macOS didn't behave consistently (because sometimes the system doesn't deep-link to the exact settings page you'd expect).

That redesign ended up improving the whole app. Honesty about system quirks turned out to be better UX than pretending everything would work perfectly every time.

Packaging Was the Invisible Make-or-Break

Here's something that surprised me. macOS privacy permissions are sensitive to how your app is packaged and identified. Running a raw executable during development is not the same as running a properly bundled .app with a stable bundle identifier.

During development, I hit a confusing state where permissions appeared granted in System Settings, but the app still couldn't suppress input correctly. The fix wasn't a code change. The fix was proper packaging: a real .app bundle, a stable bundle ID, an app icon, and a clean zip for distribution.

It's the kind of work nobody ever sees, but it's the difference between a utility that works reliably and one that works "most of the time."

What Came Out the Other Side

The final product is a small menu bar utility with a short, predictable flow:

Start a cleaning session. Wait through an arming countdown (so you have time to put down the mouse). Clean while everything is blocked. Exit by holding Right Shift + Escape, or let the automatic timeout handle it.

I also added a few things that turned out to matter more than expected. Partial lock modes (keyboard only, or pointer only) for people who just want to clean one surface. Solid backdrop modes for screen cleaning. Launch-at-login support. A visible overlay so you always know the app is active.

The app is distributed as a direct download, outside the App Store. That was a deliberate choice. For a small, focused utility, the App Store's review process and sandboxing restrictions add friction without adding much value.

The Lesson That Keeps Repeating

Building Mac Pause reinforced something I've seen over and over with macOS utilities.

The headline feature is rarely the hard part. "Block input" took a fraction of the total effort. The real work was everything around it: permission flows, edge cases with function keys, unlock safety, packaging, and making the whole experience feel trustworthy enough that someone would grant an app control over their keyboard and mouse.

Small tools demand a level of polish that bigger apps can sometimes get away with skipping. When your entire product is one interaction, every rough edge is visible.

Mac Pause is the kind of app that should feel almost unnecessary once you've used it. Of course your Mac should have a cleaning mode. The fact that it didn't was the gap, and filling it turned out to be a lot more interesting than I expected.

Try It

Mac Pause is open source. The full code is on GitHub: github.com/gloverola/macPause

If you find it useful, I'd really appreciate a star on the repo. It helps more people discover the project.

Installing from a release

Download the latest MacPause-<version>.zip from the releases page, then:

Unzip the file.
Open Mac Pause.app.
Drag it into /Applications if you want to keep it installed.
If macOS warns that the developer cannot be verified, right-click the app and choose Open.
Grant Accessibility and Input Monitoring when prompted (you'll find these under System Settings > Privacy & Security).
Quit and reopen once after enabling Input Monitoring. macOS often needs a restart of the app before it recognizes that permission correctly.

If Gatekeeper still blocks the app after download, you can remove the quarantine flag in Terminal:

xattr -dr com.apple.quarantine "/Applications/Mac Pause.app"

Building from source

If you'd rather build it yourself:

./Scripts/build_app_bundle.sh

Then run the bundled app:

./Scripts/run_bundled_app.sh

Mac Pause requires macOS 13 or later.

AI Writes the Code Now. So What Are You?

Glover — Mon, 09 Mar 2026 07:03:45 +0000

The hardest part of this transition isn't learning new tools. It's letting go of the identity you built around writing code, and figuring out what replaces it.

Last week, Alexey Grigorev, the founder of DataTalks.Club (a platform that teaches data engineering to over 100,000 students), let Claude Code run a Terraform command. Within seconds, it wiped out his entire production infrastructure. The course platform, 2.5 years of student submissions, homework, projects, leaderboard entries, every automated database snapshot he'd counted on as backups. All of it, gone.

Here's how it happened. Grigorev was migrating a side project to AWS and wanted it to share infrastructure with DataTalks.Club to save a few dollars a month. Claude actually advised against this. It suggested keeping the setups separate. He overrode the recommendation. Then he ran terraform plan from a new computer without the state file, which is the critical document that tells Terraform what infrastructure already exists. Without it, Terraform thought nothing existed. Duplicate resources got created. When the state file was finally uploaded, Claude did what Terraform's logic dictated: it ran terraform destroy to bring everything into alignment. Since the state file described both sites, everything was obliterated.

It took 24 hours and an emergency AWS Business Support upgrade to recover the data. Nearly two million rows, restored from a hidden snapshot that wasn't even visible in the AWS console.

In his post-mortem, Grigorev was remarkably honest. He didn't blame the AI. He wrote: "I over-relied on the AI agent to run Terraform commands." His fixes? Enable deletion protection, move state files to S3, and most importantly, manually review every plan before executing destructive actions.

I keep thinking about this story. Not because it's about a careless developer (Grigorev is clearly not that), but because it captures exactly where we are right now. An experienced engineer, using a powerful AI tool, making reasonable decisions at each step, and still watching 2.5 years of work disappear. The AI did exactly what it was told. The problem was that nobody was doing the thinking about what it should have been told.

That gap between what AI can execute and what a human needs to judge? That's the entire story of the developer career transition we're living through.

The Numbers Behind the Anxiety

If you've been writing code for any amount of time, you've felt it. Every week brings a new tool (Cursor, Copilot, Claude Code, Devin, v0) and with it, a fresh wave of "developers are done" takes on Twitter.

The adoption numbers are staggering. GitHub Copilot now has over 20 million users. AI generates roughly 46% of all code written by active Copilot users. According to the 2025 Stack Overflow Developer Survey, 84% of developers now use or plan to use AI tools in their workflow, up from 76% the year before. Over half of professional developers use AI tools daily.

But here's the number everyone overlooks: in that same survey, positive sentiment toward AI tools dropped from over 70% to just 60%. A full 46% of developers actively distrust AI output. The top frustration, cited by 66% of respondents? AI solutions that are "almost right, but not quite." Close enough to be tempting, wrong enough to be dangerous.

Sound familiar? Grigorev's Terraform plan looked reasonable at each step. The AI wasn't hallucinating. It was following a coherent logic chain. The problem was contextual, the kind of "almost right" that only a human who understood the full picture could catch.

Your career isn't ending. But it is changing shape. And the developers who recognize that shift early will have a massive advantage over those who either panic or pretend nothing's different.

The Honest Assessment: What AI Actually Replaced

Let's get the uncomfortable part out of the way.

AI coding tools have reduced the need for certain kinds of work. If your entire value proposition is "I can write a CRUD endpoint" or "I can convert this Figma design into pixel-perfect CSS," you're now competing directly with tools that do this faster and for a fraction of the cost. As one engineer put it: "Why hire a junior for $90K when GitHub Copilot costs $10 a month?"

But what the doom commentary misses is that those tasks were already being commoditized. Frameworks, low-code platforms, and template ecosystems had been compressing the value of raw code output for years. AI just hit the accelerator on an existing trend.

What AI has not replaced, and likely won't for a long time, is the messy, contextual, deeply human work of building software that actually solves problems. Understanding what a non-technical stakeholder actually needs (not what they say they need). Making architectural decisions that account for team capacity, company runway, and the debt you'll inherit. Debugging production systems where the issue spans three services, a race condition, and a misconfigured environment variable. Deciding what not to build, or in Grigorev's case, deciding that Claude's advice to keep infrastructure separate was worth listening to.

That Stack Overflow survey asked developers where they'd still want human help even in a future where AI handles most coding. The top answer, at 75%, was: "When I don't trust AI's answers." The human developer isn't going away. They're becoming the final quality gate.

If You're a Junior Developer, Read This

I'm not going to sugarcoat it. The entry-level landscape is brutal right now.

Entry-level hiring at the 15 largest tech firms fell 25% between 2023 and 2024. Salesforce announced zero engineering hires for 2025, citing AI agents. CS graduates now face a 6.1% unemployment rate, nearly double the national average. A Harvard study tracking 62 million workers across 285,000 U.S. firms found that junior employment at AI-adopting companies dropped 9 to 10% within six quarters of AI implementation. The decline wasn't from layoffs. Companies simply stopped posting junior roles.

This is real, and it's worth being honest about. The traditional path of "learn to code, land a junior role, learn on the job, move up" has fractured.

But here's the counter-narrative nobody's platforming enough: every senior engineer was once a junior. If companies stop hiring juniors today, they're creating a senior talent crisis in five to seven years. AWS CEO Matt Garman called the idea of replacing junior developers with AI "one of the dumbest things I've ever heard." The pipeline has to be rebuilt. The question is what "junior" looks like now.

If you're early in your career, the bar has risen. The junior of 2026 needs something closer to the system-design fluency of a mid-level engineer from 2020. But here's how you meet that bar:

Ship real things, not tutorials. Deploy end-to-end applications. React frontend, Node backend, a database, CI/CD pipeline. A to-do list app means nothing when AI can generate one in 60 seconds. An app that integrates an LLM to solve a real problem, handles edge cases, and runs in production? That proves something.

Get absurdly good at reviewing AI output. The developers getting hired right now aren't the ones who generate the most code with AI. They're the ones who can look at AI-generated code and immediately spot what's wrong. Think of yourself as a code auditor, not a code writer. If Grigorev's story teaches us anything, it's that the ability to pause, read the plan, and say "wait, this doesn't look right" is the skill that saves entire platforms.

Build in public and contribute to open source. When the market is flooded with applicants, a visible track record of shipped work and meaningful contributions is worth more than a polished resume. Three to five real pull requests on established projects will set you apart.

Target industries that are actually hiring. Consumer tech is contracting, but "boring" sectors are aggressive buyers. AI-related job postings in insurance jumped 74% in 2025, with similar surges in finance, logistics, and healthcare. These industries don't need someone to build pretty landing pages. They need engineers who can automate internal workflows and build the infrastructure that controls them.

The New Developer Skill Stack

Here's what developers who are thriving right now have deliberately built up.

1. System Thinking Over Syntax Fluency

The ability to hold a complex system in your head, to understand how a change in the payment service cascades through the event pipeline to the notification layer, is becoming more valuable, not less. AI can generate any individual component. It cannot reason reliably about the emergent behavior of interconnected systems.

This is exactly what made Grigorev's incident so instructive. Claude Code executed each individual command correctly. The Terraform syntax was valid. The AWS CLI calls worked. But the system-level understanding, that this state file described production infrastructure for a live platform with 100,000+ users, that was the human's job. And at the critical moment, the human had delegated too much of that thinking to the machine.

U.S. Bureau of Labor Statistics data tells the same story at a macro level: overall programmer employment fell 27.5% between 2023 and 2025, but employment for software developers, a more design- and architecture-oriented role, fell only 0.3%. The market isn't punishing people who build systems. It's punishing people who only write code.

If you've been meaning to go deeper into distributed systems, event-driven architecture, or observability, now is the time. These are force-multiplier skills.

2. AI Fluency as a Real Development Skill

I know "prompt engineering" sounds like a buzzword. But the productivity gap between developers who use AI tools well and those who don't is enormous, and measurable. Research involving 4,800 developers showed those using Copilot completed tasks 55% faster, with pull request turnaround dropping from 9.6 days to 2.4 days.

The gap isn't magic. It's discipline. Break problems into well-scoped, testable chunks before involving AI. Provide sufficient context upfront: project constraints, coding conventions, known edge cases. Review AI output with the same rigor you'd apply to a junior developer's PR. And know when to stop prompting and just write the code yourself.

That last point matters more than people admit. In the Stack Overflow survey, 45% of developers said debugging AI-generated code takes longer than writing it themselves. The skill isn't "use AI for everything." It's knowing exactly when AI accelerates you and when it slows you down.

3. Taste and Product Sense

This one surprises people, but it might be the most important shift. When the cost of producing code approaches zero, the bottleneck moves to deciding what code should exist. Developers with strong product sense, the ones who can look at a feature request and say "this won't move the metric we care about, here's what will," become disproportionately valuable.

Build this by getting closer to your users. Read support tickets. Sit in on sales calls. Look at your analytics dashboards. The developer who understands the business will always out-earn the one who only understands the framework.

4. The "Glue Work" That AI Can't Do

Every successful software project runs on a substrate of almost-invisible work. Facilitating technical decisions across teams, writing clear RFC documents, mentoring junior developers, translating between engineering and product language, building consensus around tradeoffs.

This work has historically been undervalued. In an AI-augmented world, it becomes the differentiator. And there's a growing concern that as companies cut juniors, seniors are losing the ability to delegate lower-risk tasks entirely, creating a "delegation vacuum" where they shoulder both the high-level architecture and the grunt work with no pressure valve. If you're the person who helps a team function, lean in hard.

What Not to Do

Before the playbook, a few traps I keep seeing developers fall into:

Don't let AI touch production without guardrails. This is the Grigorev lesson, distilled. He's now requiring manual review of every Terraform plan, enabling deletion protection on all critical resources, and storing state files in S3 instead of locally. These aren't complex changes. They're the kind of boring, five-minute safeguards that separate professionals from people who move fast and break things. AI can draft the infrastructure code. A human should hold the keys to destroy.

Don't chase every new AI tool. A new coding assistant drops every week. If you're constantly switching between Cursor, Copilot, Claude Code, Windsurf, and whatever launched yesterday, you're optimizing for novelty instead of depth. Pick one or two tools. Master them. Depth beats breadth.

Don't over-rely on AI without reviewing output. This is the most common mistake I see. AI-generated code often looks correct, passes a quick scan, and then fails in production on edge cases the model couldn't anticipate. 72% of developers say "vibe coding," meaning generating software from prompts without deeply understanding what's produced, is not part of their professional work. There's a reason for that.

Don't panic-pivot into management because you think engineering is dead. If you love building, stay building. The demand for engineers who can think at the system level is actually increasing. Switching to management out of fear rather than genuine interest is a recipe for misery.

Don't ignore the fundamentals. When AI handles the surface-level implementation, your understanding of data structures, networking, concurrency, and system design becomes more important, not less. AI is a layer on top of fundamentals, not a replacement for them. As Satya Nadella put it: "Having the ability to think computationally matters a lot."

A Practical Playbook for the Next 12 Months

Theory is nice. Here's what I'd actually do.

Month 1 to 3: Integrate AI deeply into your workflow. Don't just dabble. Use an AI coding tool as your default pair programmer for a full month. Build muscle memory. The goal isn't to use AI for everything. It's to develop an instinct for when to reach for it. What "done" looks like: You can estimate, before starting a task, whether AI will speed it up or slow it down, and you're right 80% of the time.

Month 4 to 6: Go deep in one area AI struggles with. Pick a domain that requires judgment, context, and systems-level thinking. Performance engineering. Security architecture. Data modeling for complex domains. Infrastructure design. Become genuinely excellent at one of these. What "done" looks like: You can explain to a non-technical PM why your system handles 10x traffic spikes without falling over, and they believe you.

Month 7 to 9: Build something end-to-end with AI as your co-pilot. Ship a side project, contribute to open source, or take on an ambitious work project. Document the process. Not just the wins, but the moments where AI led you astray. Where did you override it? Where did you wish you had? Grigorev's post-mortem is a masterclass in this kind of reflective practice. What "done" looks like: You have a shipped project and a written reflection (blog post, internal doc, even a detailed README) that someone else could learn from.

Month 10 to 12: Teach what you've learned. Write about your experience. Give a talk at a meetup. Mentor someone more junior. Teaching forces you to crystallize your understanding, and it positions you publicly as someone navigating this transition with intention. What "done" looks like: You've published at least one piece of content or given one talk that generated real feedback or conversation.

The Mindset Shift That Matters Most

I want to close with something less tactical and more fundamental.

The developers struggling most with this transition aren't the ones with weaker technical skills. They're the ones whose professional identity is built on being the person who writes the code. When AI can write the code, that identity feels threatened.

The developers who are thriving? They see themselves as problem solvers who happen to use code as their primary tool. For them, AI is just another tool in the kit, like when they adopted a new framework or learned a new language. It changes how they work, not who they are.

Grigorev's story lands differently when you see it through this lens. He didn't write a post about how AI is dangerous and should be avoided. He wrote a post about what he could do differently. What guardrails to add, what processes to change, what judgment calls to stop delegating. His identity as an engineer didn't break. It evolved. He's still building. He's just building with clearer boundaries now.

That's the model.

The software industry has always been defined by waves of abstraction. Assembly to C. C to Python. Manual deployment to CI/CD. Every wave eliminated certain jobs and created others that were previously unimaginable. We're in another one of those waves.

But this one has a wrinkle. It's not just changing the tools. It's changing who gets to enter the profession and what the first few years of a career look like. That's worth taking seriously, both as individuals adapting our own paths and as an industry deciding whether to invest in the next generation or abandon them.

The developers who adapt won't just survive. They'll look back in five years and realize this was the inflection point that made their careers.

If this resonated, I'd love to hear how you're adapting your own workflow. Or if you're early career, what the job search actually looks like right now.

Why React Developers Can Finally Delete Half Their Performance Code

Glover — Mon, 02 Mar 2026 14:44:30 +0000

Every React developer has felt the creeping dread: you're building a feature, it works, and then you remember you need to wrap this in useMemo. And that callback needs useCallback. And the child component needs React.memo. What started as a simple button is now buried under three layers of optimization boilerplate.

React 19's compiler makes all of it obsolete.

The problem wasn't that optimization was hard. The problem was that React forced you to do the compiler's job. You had to manually tell React what not to re-render, what not to recalculate, what references to preserve. The new compiler handles this automatically not as a convenience feature, but as a fundamental architectural shift in how React processes your code.

The Tax You've Been Paying

React's rendering model created a specific headache: when a parent component's state changed, every child re-rendered. Even if those children displayed static text. Even if nothing about them changed.

Developers fought this with three tools:

React.memo told React to skip re-rendering a child unless its props actually changed.
useMemo cached expensive calculations so they wouldn't rerun on every render.
useCallback preserved function references, because React compares props by reference, a recreated function looked like a new prop, triggering unnecessary re-renders.

The tax wasn't just in writing this code. It was in debugging dependency arrays, weighing whether optimization was worth the complexity, and watching your clean component logic disappear under wrapper functions.

Here's what that looked like:

import { useState, useMemo, useCallback, memo } from 'react';

const ChildComponent = memo(({ onClick }) => {
  return <button onClick={onClick}>Increment</button>;
});

export default function App() {
  const [count, setCount] = useState(0);

  const handleIncrement = useCallback(() => {
    setCount((c) => c + 1);
  }, []); 

  const expensivePrimeNumbers = useMemo(() => {
    return calculatePrimes(); 
  }, []);

  return (
    <div>
      <h1>Count: {count}</h1>
      <ChildComponent onClick={handleIncrement} />
    </div>
  );
}

Three hooks. One wrapper. All to render a counter with a button.

What the Compiler Actually Does

The React Compiler converts your components into optimized JavaScript and memoizes automatically. It tracks when inputs change and when they don't, it skips the work.

No wrappers. No hooks. No dependency arrays to manage.

The same component now looks like this:

import { useState } from 'react';

const ChildComponent = ({ onClick }) => {
  return <button onClick={onClick}>Increment</button>;
};

export default function App() {
  const [count, setCount] = useState(0);

  const handleIncrement = () => {
    setCount((c) => c + 1);
  };

  const expensivePrimeNumbers = calculatePrimes();

  return (
    <div>
      <h1>Count: {count}</h1>
      <ChildComponent onClick={handleIncrement} />
    </div>
  );
}

This isn't a simplified example for documentation. This is production code. The compiler handles what you used to handle manually.

Adoption requires no code changes, just enabling the compiler. If a component violates React's rules, the compiler skips that component and optimizes the rest. An ESLint plugin flags violations so you can fix them incrementally.

Three More Cuts to Your Codebase

The compiler dominates the headline, but React 19 trims boilerplate elsewhere too.

Refs without forwardRef. Passing a reference to a child component used to require wrapping the entire child in forwardRef. Now ref works like any other prop.

The use hook. A single hook that resolves promises and context. It replaces useContext and offers a cleaner alternative to useEffect for data fetching. Combined with Suspense, async loading states become declarative instead of manually tracked.

Form actions. Pass functions directly to a form's action prop—client-side or server-side. New hooks like useFormStatus disable buttons during submission, and useOptimistic updates the UI instantly while waiting for the server.

What This Actually Means

React 19 isn't adding features you need to learn. It's removing problems you've been solving manually.

The code you delete is code you never have to debug. The patterns you unlearn are patterns that were always workarounds. For the first time in years, React is getting simpler not because it's doing less, but because you are.

Getting the Deck in Order: Custom Types and Methods in Go!

Glover — Fri, 01 Nov 2024 06:53:50 +0000

Hello Gophers! Today we are going to familiarize ourselves with this great world of custom types and methods in Go. Sounds a bit overwhelming? Don't worry, by the end of this article you are going to be able to do it with eyes closed and one hand tied behind your back. So go ahead, pick up your favorite beverage, take a seat and lets dive in.

Go's Type Magic
Suppose at some point, one day, one wanted to conjure a deck of cards; he would do so in Go by first introducing what is called a custom type. Instead of saying "I want a list of strings", which is kind of a bore, he gets to name it something cool, like deck! Naming makes it easier to use and keeps the code nice and neat, just like a perfectly stacked deck of cards.

Here's the abracadabra that does the trick:

package main

type deck []string

Boom! You now have a new type called deck, and all it really is, under the hood, is a slice of strings ([]string). You’ve just made Go a little more readable and fun!

Making `deck` Do Tricks - Adding Methods

But a deck of cards by itself is kind of boring, right? What’s a magician without a few card tricks? That's where methods come into play! In Go, you can attach methods to your custom types, making them do all sorts of cool things.

Let’s start by adding a print() method to our deck type so it can list out all the cards in the deck. Here's how you do it:

func (d deck) print() {
    for i, card := range d {
        fmt.Println(i, card)
    }
}

Hold up—what just happened? Let me break it down for you:

func (d deck) print(): This is a method called print() that belongs to our deck type. The (d deck) part is called a receiver. You can think of it like saying, “Hey deck, here’s what I want you to do when I call print() on you.”
Inside print(), we’re looping through each card in the deck and printing out its index (i) and its value (card). Simple, yet powerful!

Here's the full picture:

package main

import "fmt"

type deck []string

func (d deck) print() {
    for i, card := range d {
        fmt.Println(i, card)
    }
}

func main() {
    cards := deck{"Ace of Spades", "Two of Hearts", "Three of Diamonds"}
    cards.print()
}

Run this, and you’ll get something like:

0 Ace of Spades
1 Two of Hearts
2 Three of Diamonds

Look at that! Your deck knows how to introduce itself. You've made a talking deck—how cool is that?

Not Just Cards: Real-Life Use Cases

So you’ve learned to make a deck of cards, but what else can you do with custom types and methods in Go? Glad you asked—because the possibilities are endless. Let’s walk through a few fun examples that go beyond just cards.

1. Managing Students Like a Boss

Imagine you’re a teacher with a list of students. Instead of using a boring old slice, why not create a new type called students?

type students []string

func (s students) print() {
    for i, student := range s {
        fmt.Println(i, student)
    }
}

func main() {
    class := students{"Alice", "Bob", "Charlie"}
    class.print()
}

Now, when you need to list all the students, you just call class.print(). It’s like having your own roll call assistant!

2. Shopping Cart for an E-Commerce App

Running an online store? You’ll probably want a cart type to manage the items customers add to their shopping cart.

type cart []string

func (c cart) printItems() {
    for i, item := range c {
        fmt.Printf("%d: %s\n", i, item)
    }
}

func main() {
    shoppingCart := cart{"Laptop", "Mouse", "Keyboard"}
    shoppingCart.printItems()
}

This is super handy for quickly listing everything in the cart without any extra effort. You could even add methods like addItem() or removeItem() to make it more powerful.

3. Bank Account Transactions

How about keeping track of bank transactions? You could create a transactions type and add methods for printing and calculating balances.

type transactions []float64

func (t transactions) printHistory() {
    for i, transaction := range t {
        fmt.Printf("Transaction %d: $%.2f\n", i, transaction)
    }
}

func main() {
    account := transactions{100.0, -50.0, 25.5}
    account.printHistory()
}

This way, you can quickly see every deposit and withdrawal and easily manage your bank history—without even needing an app!

Why Custom Types Are Awesome

Custom types and methods are all about making your life easier. By grouping related data and functionality together, you make your code more readable, reusable, and much more manageable. Instead of juggling random slices and utility functions all over the place, you have something that makes sense to your project.

A deck knows how to print itself. A cart knows what’s inside it. A students type knows how to call roll. It’s all about attaching meaning to your data and giving it superpowers to do useful things.

Your Next Magic Trick?

Why not give it a shot yourself? Try creating a new type for something you work with—maybe a list of favorite movies or tasks for your to-do app—and add a method or two that makes it useful.

And there you have it—you’ve learned how to create custom types and add methods to them in Go, making your code more expressive and powerful. Now, it’s your turn to be the magician! Who knows, maybe your next trick will be the best one yet.

Happy Go coding, my friend!

Tackling Complexity: Practical Principles for Scaling Frontend Applications

Glover — Wed, 09 Oct 2024 21:36:06 +0000

As frontend applications grow, so does their complexity. Adding more features often brings challenges that can slow your team's productivity and introduce hidden bugs. Scaling a frontend isn't about building bigger; it's about building smarter.

This article explores core principles to keep complexity manageable as your frontend scales. We'll focus on actionable steps that can help you navigate growing codebases without losing sight of performance, maintainability, and simplicity. Some ideas here draw from an insightful piece on complexity by Frontend at Scale, and the lessons learned are applicable to anyone building large applications.

1. Keep Components Small

Components are the building blocks of any frontend. But as the codebase scales, it's easy for these building blocks to grow into unwieldy giants. The solution? Keep components small and focused.

Single Responsibility: Each component should do one thing well.
Avoid Long Files: Break larger components into smaller, reusable pieces.

Smaller components are easier to reason about, test, and modify. You can isolate complexity by delegating responsibilities across multiple smaller parts instead of one large, confusing unit.

2. Embrace Reusable Patterns

Reusable patterns help eliminate duplicated logic and make development faster. Think about utilities, hooks, and helper functions that can be reused across multiple components:

Hooks (if using React) allow stateful logic to be reused easily.
Utility Functions reduce redundancy in common data transformations.

Don't fall into the trap of copying code blocks from one component to another. Abstracting common logic into reusable functions avoids a "copy-paste" mess that can grow uncontrollably.

3. Split by Domains, Not by File Type

A lot of teams organize projects by file type components in one folder, styles in another, utilities in a third. But as the project grows, this approach can get hard to manage.

Instead, split by domain. Group everything related to a specific feature—components, styles, tests, etc.—in one place. This structure keeps related files together, making it easier to scale features and maintain a clear understanding of your application.

Example folder structure for a feature:

- Features/
  - UserProfile/
    - UserProfile.tsx
    - UserProfile.styles.ts
    - UserProfile.test.ts
    - hooks/
    - utils/

When scaling, you want to understand a feature in its entirety without jumping across folders. Domain-driven file organization helps to achieve that.

4. Apply State Management Wisely

Managing state is often one of the biggest sources of complexity in a frontend application. Introducing the wrong state management pattern too early or over-using a global state can lead to unnecessary headaches.

Local vs. Global State: Keep state as local as possible. If multiple components don’t need access to a particular piece of state, avoid moving it to a global store.
Split State into Layers: Use context, global state libraries (Redux, Zustand), or query libraries (React Query) depending on the state’s purpose. A data-fetching state doesn't need to live alongside UI state.

Global state management adds overhead. Assess if it’s necessary before reaching for complex solutions. Start simple and evolve as the needs of your application change.

5. Document Early, Document Often

Documentation tends to be an afterthought, but as your frontend scales, poor documentation can significantly increase onboarding time and slow down development.

Add Inline Comments: Avoid assuming code is self-explanatory.
Create Component Documentation: Make it easy for new developers to understand how each component works, what props it expects, and the outcomes it provides.

Even lightweight documentation can make a difference in maintaining clarity in a growing codebase.

6. Performance-First Mindset

Complexity isn’t just about code—it also shows up in how your app performs.

Code Splitting: Split bundles to keep load times short.
Lazy Loading: Load components and resources only when they're needed.

Performance issues multiply as features add up. Keeping performance considerations at the forefront will make sure that your app remains responsive at scale.

7. Embrace Automation

Manual processes introduce delays and increase the risk of human error.

Code Quality: Use linters, formatters, and type checkers like ESLint and Prettier to maintain consistent quality.
Testing: Write automated tests to catch breaking changes. As complexity grows, having a reliable test suite saves significant debugging time.

Final Thoughts

Scaling frontend applications is less about adding more features and more about managing the complexity that comes with them. As you add new capabilities, remember to:

Keep things modular.
Reuse as much as possible.
Document clearly.
Manage state effectively.

These practices keep growth in control, letting your app scale smoothly rather than turning into a tangled mess.

Many ideas here were inspired by Frontend at Scale. It's a highly recommended read for anyone building complex systems.

Deploying a React App on DigitalOcean App Platform Using GitHub Actions

Glover — Thu, 01 Jun 2023 11:39:20 +0000

Deploying a React app on the DigitalOcean App Platform can be streamlined using GitHub Actions. In this article, we'll go through the process of setting up a deployment workflow and automating the deployment using a GitHub Actions workflow file.

Prerequisites:
Before we begin, make sure you have a DigitalOcean Personal Access Token. If you don't have one, follow the instructions provided by DigitalOcean to create a token.

Setting Up the Personal Access Token:

Access your GitHub repository and navigate to the repository's Secrets settings.
Declare a new secret called DIGITALOCEAN_ACCESS_TOKEN and set its value to your DigitalOcean Personal Access Token. This token will be securely stored and used in the deployment process.

Creating the GitHub Action Workflow:

Create a new GitHub Action workflow file or modify an existing one in your repository.
Add the following workflow configuration to the file:

name: Deploy app

on:
  push:
    branches:
      - main

jobs:
  build_and_deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout main branch
        uses: actions/checkout@v2

      - name: Use Node.js
        uses: actions/setup-node@v1
        with:
          node-version: '16.x'

      - name: Install dependencies
        run: yarn install

      - name: Test application
        run: yarn test

      - name: Deploy to DigitalOcean
        uses: digitalocean/app_action@main
        with:
          app_name: my_react_app
          token: ${{ secrets.DIGITALOCEAN_ACCESS_TOKEN }}

Let's go through the different steps in the workflow:

Checking out the main branch: This step ensures that the workflow operates on the main branch of your repository.

Setting up Node.js: This step sets up the required Node.js environment for the deployment process. We specify the desired Node.js version (in this case, 16.x).

Installing dependencies: This step installs the project dependencies using the yarn install command. Make sure to customize it if you're using a different package manager.

Testing the application: This step runs the tests for your React app using the yarn test command. Adjust this step if you have different testing requirements.

Deploying to DigitalOcean: The final step utilizes the digitalocean/app_action action to trigger the deployment to the DigitalOcean App Platform. Set the app_name parameter to the name of your React app on DigitalOcean. The token parameter fetches the previously set DIGITALOCEAN_ACCESS_TOKEN secret securely.

By following the steps outlined in this article and using the provided GitHub Actions workflow file, you can automate the deployment of your React app on the DigitalOcean App Platform. This streamlined process allows you to focus on developing your app while ensuring efficient and reliable deployments

Understanding the Impact of React.StrictMode on Application Performance

Glover — Thu, 22 Dec 2022 06:36:12 +0000

React.StrictMode is a tool introduced in React 16.3 that helps identify potential problems in an application. It activates additional checks and warnings for components within its scope, which helps improve the performance and correctness of an application.

One of the key features of React.StrictMode is its ability to detect unexpected side effects in components. In React, side effects refer to any operations that mutate state or trigger other changes outside the component, such as network requests or manually modifying the DOM. By default, these side effects are allowed to happen asynchronously, which can lead to unexpected behavior and performance issues.

React.StrictMode wraps its children in a fragile and isolated environment, where any side effects are detected and reported. This allows developers to find and fix potential problems before they become severe. For example, consider the following component that triggers a side effect by updating the document title:

function MyComponent() {
  React.useEffect(() => {
    document.title = 'My page';
  });

  return <h1>Hello world!</h1>;
}

Without React.StrictMode, this component would silently update the document title without any warnings. However, when wrapped in React.StrictMode, it would produce a warning in the console:

// MyComponent.js:5
//   React has detected a legacy lifecycle event in a strict-mode component.
//   As a precaution, React will freeze this component...

This warning indicates that the useEffect hook, which is used to manage side effects, has been called in a strict mode component. In the future, this hook will be frozen and can no longer be used, which means that the component will need to be updated to avoid the side effect.

In addition to detecting side effects, React.StrictMode also enables additional checks and warnings for other potential problems. For instance, it can detect deprecated APIs and component patterns that will be removed in future versions of React. It can also help improve the performance of an application by highlighting unnecessary rendering and outdated styles.

Here is an example of how React.StrictMode can detect deprecated APIs:

function MyComponent() {
  React.useLegacyContextAPI(MyContext);

  return <h1>Hello world!</h1>;
}

// MyComponent.js:3
//   React has detected a legacy context API being used...

In this example, the useLegacyContextAPI hook is deprecated and will be removed in a future version of React. When used in a strict mode component, it produces a warning that advises developers to update their code to the new context API.

Strict mode checks are run in development mode only; they do not impact the production build.

Overall, React.StrictMode is a valuable tool for improving the performance and correctness of a React application. By detecting unexpected side effects and other potential problems, it helps developers catch and fix issues before they become severe. While it may require some additional work to update components to avoid the warnings it produces, the long-term benefits of using React.StrictMode are well worth the effort.

Next.js in Production: Best Practices and Common Pitfalls

Glover — Wed, 14 Dec 2022 12:57:02 +0000

Next.js is a popular framework for building server-rendered React applications. It offers a rich set of features and tools for building fast and scalable web applications, including automatic code splitting, optimized performance, and seamless integration with popular serverless technologies.

However, as with any technology, there are some best practices and common pitfalls to be aware of when using Next.js in production. In this article, we will discuss some of these best practices and pitfalls, and provide some tips and guidance for building successful and reliable Next.js applications.

First, let's discuss some of the best practices for using Next.js in production. One of the key advantages of Next.js is its ability to automatically optimize the performance of your applications. This includes features such as code splitting, lazy loading, and server-side rendering, which can help improve the loading speed and user experience of your applications.

However, to take full advantage of these features, it is important to properly configure and optimize your Next.js applications. This includes setting up the proper build and deployment processes, as well as implementing caching and other performance-enhancing techniques.

Another best practice for using Next.js in production is to properly handle errors and exceptions. Next.js provides a built-in error-handling mechanism, which can be used to catch and handle errors in your application. However, it is important to also implement robust logging and monitoring systems to ensure that errors and exceptions are properly detected and addressed.

Now, let's discuss some of the common pitfalls to avoid when using Next.js in production. One of the biggest challenges with server-rendered applications is the management of application state. Next.js provides a built-in mechanism for managing application state, but it can be difficult to manage and maintain, especially in larger and more complex applications.

To avoid this pitfall, it is important to implement a robust state management solution, such as Redux or MobX, to ensure that your application state is properly managed and maintained. This will help improve the maintainability and scalability of your applications, and reduce the risk of errors and inconsistencies.

Another common pitfall when using Next.js in production is the difficulty of debugging and testing applications. Because Next.js applications are server-rendered, it can be difficult to debug and test them using traditional client-side tools and techniques. To avoid this pitfall, it is important to implement robust testing and debugging processes, such as unit and integration testing, to ensure the reliability and quality of your applications.

In conclusion, Next.js is a powerful and flexible framework for building server-rendered React applications. However, like any technology, it has its own best practices and common pitfalls that developers should be aware of. By following these best practices and avoiding these pitfalls, you can build successful and reliable Next.js applications that deliver a seamless and engaging user experience.

Reducing the Size of Your React Applications with Tree Shaking and Code Splitting

Glover — Sun, 11 Dec 2022 10:37:09 +0000

As React applications grow in size and complexity, it becomes increasingly important to optimise their performance and reduce their footprint. Two powerful techniques for achieving this are tree shaking and code splitting, which can help to eliminate unused code and split large applications into smaller, more manageable chunks.

Tree shaking is a term used to describe the process of removing unused exports from a module. This is typically done during the bundling process, using a tool such as Webpack or Rollup. By removing unused code, the resulting bundle can be significantly smaller and more efficient, improving the performance and loading time of an application.

To enable tree shaking in a React application, developers can use the import and export syntax provided by ECMAScript modules. For example, instead of importing a module using the require function, developers can use the import keyword, along with the specific exports they want to use:

import { MyComponent } from './MyModule';

This syntax allows the bundler to determine which exports are actually used in the application, and to eliminate the unused ones.

Code splitting is another technique for optimising the size and performance of React applications. Instead of bundling all of the application code into a single file, code splitting allows developers to split their applications into multiple chunks, which can be loaded on demand as needed.

For example, instead of importing a large module at the top level of an application, developers can use the dynamic import syntax provided by ECMAScript, which allows the module to be loaded asynchronously:

const MyModule = React.lazy(() => import('./MyModule'));

This syntax allows the module to be loaded only when it is needed, improving the initial loading time of the application and reducing its overall size.

By using tree shaking and code splitting together, developers can create smaller, faster, and more efficient React applications. These techniques can help to eliminate unused code and split large applications into manageable chunks, improving the performance and user experience of an application.

Introduction to CSS Positioning.

Glover — Thu, 03 Dec 2020 21:56:41 +0000

Positioning defines where an item stands in relation to others, as simple as that may sound CSS positioning can be a bit tricky to deal with. Taking elements out of their normal document flow by making them sit on top of one another or always remaining in the same place inside the browser viewport is known as CSS positioning. In this article, we will explore the different position properties and how to use them.

Prerequisites: Basic HTML and CSS knowledge

The main aim of the positioning is to override the default behavior of elements in the document flow as described above. In instances where we want to alter the position of elements, create UI elements that float or sits in the same place inside the browser window no matter how much the page is scrolled.

There are a number of positioning properties we can put into effect, to make a specific type of positioning active on an element, we use the position property.

Static Positioning.

This is the default position every element gets. Elements remain stacked in their normal position in the document layout flow, using this property in our CSS won't alter the position of the element. to demonstrate this, we create a div element with a class of "box-1".
<div class="box-1">Static</div>
Now we can add the following CSS properties by referencing the class attribute attached to our div above.



.box-1 {
background-color: #edfcae;
height: 50px;
width: 50px;
}

If we peep into our browser, we will see our element sitting pretty at the top left corner like this:
.
Now let's add the static position property to our element below.



.box-1 {
  position: static;
}

If we preview our element in the browser we notice no changes at all, This is cool, as we said before, static positioning is the default behavior!

Relative Positioning.

This is a bit similar to static positioning, except that we can also modify the final position of our element once it has taken its place in the normal layout flow, including allowing elements to overlap one another on our page layout.

Let's go ahead and create another box below
<div class="box-2">Relative</div>



.box-2 {
    background-color: #f5ab57;
    color: #000;
    text-align: center;
    height: 50px;
    width: 50px;
    position: relative;
}

If we preview our browser we can see it's stacked perfectly below our "static" box like this,

so how do we modify the position of our element?. This is where we introduce the top, bottom, left and right properties.

top, bottom, left, and right.

These properties are used alongside position to specify exactly where we want to move the positioned element.
now let's update our CSS below



.box-2 {
    background-color: #f5ab57;
    color: #000;
    text-align: center;
    height: 50px;
    width: 50px;
    position: relative;
    top: 30px;
    left: 100px;
}

The values of these properties can take any available CSS units e.g pixels, rem, em, % e.t.c.
Now if we preview our browser we notice some changes like this

interesting right?. Yeah, by assigning the top and left property to our element we've simply moved our element 30px from the top of its default position and 100px from the left of its default position.

Absolute Positioning.

Absolute positioning gives us a different result entirely, let's try creating another box with position property set to absolute.
<div class="box-3">Absolute</div>



.box-3 {
    background-color: #59b1da;
    color: #fff;
    text-align: center;
    height: 50px;
    width: 120px;
    position: absolute;
}

If we save and refresh, we should notice something like this:

First, we should notice that that the "absolute" box is overlapping the "relative" box, the remaining elements on our web page act as if the absolute box no longer exist, well, in a way this is true. An absolutely positioned element no longer exists in the normal document layout flow. By assigning absolute to the position property of an element it means that we can create isolated UI features that don't interfere with the layout of other elements on our web page, e.g popup information like alerts and prompt e.t.c.
The top, bottom, left and right properties behave in a different way with absolute positioning. Rather than positioning the element based on its relative position within the normal document flow, they specify the distance the element should be from each of the containing element's sides.



.box-3 {
    background-color: #59b1da;
    color: #fff;
    text-align: center;
    height: 50px;
    width: 120px;
    position: absolute;
    top: 40px;
    left: 50px;
}

In this case, we are saying that the absolutely positioned element should sit 40px from the top of the containing element and 50px from the left.

Z-Index

Absolute positioning is great, but there is another thing we haven't considered yet when elements start to overlap, what determines which elements appear on top of which other elements? In the example we've seen so far, we only have one positioned element in the positioning context, and it appears on the top since positioned elements win over non-positioned elements. What about when we have more than one?.
Can we change the stacking order of an element?. Absolutely!, the z-index property allows us to do so. "z-index" is a reference to the z-axis. Web pages also have z-axis, z-index values affect where positioned elements sit on that axis. Positive "z-index" values will move them higher up the stack and negative values move them lower down the stack. By default, positioned elements all have a z-index of auto which is effectively 0.

let's try bringing the "relative" box higher up the stack, by adding the z-index property.



.box-2 {
    background-color: #f5ab57;
    color: #000;
    text-align: center;
    height: 50px;
    width: 50px;
    position: relative;
    top: 30px;
    left: 100px;
    z-index: 1;
}

Excellent!, we now have our relative box higher up the stack. We should note that "z-index" only accepts unitless values, you can't specify that you want an element to be 20 pixels up the z-axis, it doesn't work that way. Using 1 and 2 would give the same effect as 100 and 2000.

In our next episode, we will discuss the fixed and sticky positioning.
Note: You can see the example at this point here