DEV Community: Kristieene Knowles

My Windows Laptop Entered a Restart Loop — Then Came the 48-Hour Robocopy Adventure

Kristieene Knowles — Sat, 22 Aug 2026 15:36:57 +0000

Sometimes debugging starts with a neat error message, a useful stack trace and a reasonably obvious place to start looking.

This was not one of those times.

My Windows laptop had entered a restart cycle. Windows Automatic Repair would start, attempt to diagnose the problem, and ultimately tell me that it couldn't find anything wrong.

Which was particularly helpful considering Windows was very clearly not working.

Somewhere during all of this I had also encountered a warning relating to the Windows Recycle Bin and possible corruption. That immediately made the situation look considerably worse than it eventually turned out to be.

Thankfully, there were several very important signs that this wasn't catastrophic.

I could access Safe Mode.

BitLocker was working and I had access to my recovery keys.

My C:\ drive could still be mounted.

And, most importantly, my files appeared to be readable.

So before trying increasingly invasive repairs, I made a decision:

Don't fix anything yet. Get the data somewhere safe first.

And thus began what I have since affectionately named:

The 48-Hour Robocopy Adventure™

My plan sounded simple enough.

I had an external HDD available, formatted as exFAT, so I decided to use Robocopy from Safe Mode to copy the contents of C:\ onto it.

This wasn't intended to repair Windows.

It was insurance.

If I was going to start changing drivers, Windows configuration or anything else that could potentially make the situation worse, I wanted my data somewhere else first.

ChatGPT became my troubleshooting companion throughout this process. Rather than throwing random commands at Windows, I could describe what I was seeing, work through what each result meant, and decide what the next low-risk diagnostic step should be.

And at first, Robocopy behaved exactly as expected.

Files appeared.

Directories appeared.

More files appeared.

Then more directories.

And then I began discovering exactly how much stuff accumulates on a Windows development machine.

Robocopy Will Happily Show You Everything You've Forgotten About

There is something slightly surreal about watching an entire Windows installation scroll past you.

System32.

Program Files.

Steam.

Git.

VS Code history.

AppData.

Downloads.

Pictures.

npm caches.

Minecraft.

Temporary files.

And, naturally:

WinSxS.

So much WinSxS.

At various points I would see Robocopy apparently slow down and wonder whether something had gone wrong.

Usually the answer was:

No. It had just found something enormous.

One particularly memorable discovery was an Android virtual-device image weighing in at hundreds of gigabytes.

Ah.

That would explain the pause.

This was also not an entirely smooth 48-hour operation. At one point I had to interrupt a stalled copy and recover from it. At another point, several hours into the process, I realised something fairly important:

I hadn't made absolutely certain the laptop wouldn't go to sleep.

Nothing quite captures the glamour of software development like being several hours into a disaster-recovery copy and suddenly thinking:

"Wait. Can Windows still sleep?"

Back to PowerShell.

Back to ChatGPT.

Check the relevant power configuration, disable sleep and hibernation for the duration of the operation, and continue.

The copy marched onwards.

Meanwhile, My Development Environment Was... Fine

There was another realisation during all of this which made the situation considerably less frightening.

My laptop might have been having a terrible time.

My development environment wasn't.

I'd already structured my setup so that the important parts of my development environment lived on an external SSD: projects and the applications and tooling I need to get myself working again quickly.

That wasn't something I'd done specifically in preparation for this incident.

But suddenly its value became extremely obvious.

Had the laptop actually been unrecoverable, replacing the physical machine would have been annoying and potentially expensive.

It wouldn't, however, have meant reconstructing my entire development environment from memory.

That gave me one of the biggest lessons from the whole incident:

Your computer, your data and your development environment do not have to be the same thing.

The laptop is replaceable hardware.

My projects and data are not.

And my development environment should ideally be portable enough that losing one machine doesn't mean losing days rebuilding everything required to work.

BitLocker Wasn't the Problem Either

Seeing BitLocker during a failed Windows boot can initially add another layer of anxiety.

In my case, however, BitLocker was doing exactly what it was supposed to do.

I had my recovery keys.

The drive could be unlocked.

Safe Mode could access it.

And the files were readable.

Encryption hadn't caused the problem, and it wasn't preventing recovery.

That distinction became important:

Encryption and recoverability aren't opposites.

BitLocker protecting a drive is fine.

BitLocker protecting a drive when you've lost every recovery key is a very different situation.

This incident gave me a newfound appreciation for knowing where those keys are before you need them.

The Strange Recycle Bin Corruption Message

The corruption warning I'd encountered earlier was still sitting in the back of my mind.

At first it had sounded ominous.

A restart cycle plus Windows talking about corruption is exactly the sort of combination that makes you start imagining filesystem failure, damaged Windows components or dying storage.

But the evidence increasingly didn't support that theory.

The drive mounted.

Files were readable.

Safe Mode worked.

Robocopy was successfully reading huge portions of the filesystem.

Windows Automatic Repair hadn't identified the cause.

So rather than treating the word "corruption" as the diagnosis, I started treating it as what it actually was:

one symptom among several.

That turned out to be rather important.

Preservation Before Repair

By this stage I'd effectively separated the incident into two different jobs.

Job 1: Protect the data

Robocopy.

External drive.

Verify that the important files exist somewhere other than the affected machine.

Job 2: Find out why Windows won't boot

Only once Job 1 was sufficiently under control did I feel comfortable becoming more aggressive with Job 2.

This changed the psychology of troubleshooting considerably.

Instead of every experiment carrying the thought:

"What if this destroys something important?"

I had a recovery path.

That's something I'll carry into future incidents:

Before trying to repair a system, decide whether you first need to preserve the system.

Those aren't necessarily the same operation.

And Then We Found `aswNetHub`

After nearly two days of Robocopy, Safe Mode, Windows diagnostics, filesystem observations and general investigation, the actual root cause turned out to be rather less dramatic than the journey getting there.

The investigation eventually led to:

aswNetHub

This is an Avast network-related driver.

More importantly, it was configured as a system-start driver.

That immediately made it interesting.

Normal Windows startup loaded it.

Safe Mode didn't behave the same way.

Safe Mode worked.

Normal Windows didn't.

That difference gave us something useful to investigate.

I disabled aswNetHub.

Then came the slightly terrifying bit.

Reboot.

Windows started.

There was initially a black screen for a few minutes, which wasn't exactly reassuring after everything that had happened.

Then the wallpaper appeared.

Then the taskbar.

Then Windows was back.

The restart cycle was gone.

After approximately 48 hours of recovery work, the ultimate culprit was one network driver.

Of course it was.

So Was the 48-Hour Robocopy Pointless?

No.

And I think that's probably the most important part of this entire story.

If I'd known at the beginning that aswNetHub was responsible, I could have disabled it almost immediately.

But that's not how root-cause analysis works.

You don't begin an investigation knowing the root cause.

You gather evidence.

You eliminate possibilities.

You protect the things that matter.

You make increasingly informed decisions.

And you try very hard not to turn one problem into three new ones.

Robocopy didn't fix my computer.

What Robocopy did was give me the confidence to continue diagnosing the computer without putting my data unnecessarily at risk.

I didn't spend 48 hours fixing a driver.

I spent 48 hours making sure I could afford to be wrong while figuring out which driver needed fixing.

That's a rather different thing.

ChatGPT's Role in the Recovery

There's another part of this experience worth talking about because AI-assisted development and troubleshooting is becoming increasingly normal.

I used ChatGPT throughout the incident.

But I wouldn't describe what happened as:

"ChatGPT fixed my laptop."

That's not really accurate.

It was closer to having an interactive technical rubber duck sitting beside me for two days.

I could report:

what Windows was doing;
what Safe Mode showed;
what Robocopy was currently copying;
what commands returned;
whether networking was behaving differently;
what changed after a reboot.

Then we could reason about the next step.

That distinction matters to me.

I was still sitting at the machine.

I was still deciding which commands to execute.

I could stop when something didn't look right.

I could challenge a suggestion.

And because the conversation retained the context of the incident, I didn't have to reconstruct the entire situation for every individual question.

For an incident that stretched across roughly 48 hours, that continuity was genuinely useful.

AI didn't replace understanding the machine.

It helped me maintain a structured investigation while I was tired, staring at Safe Mode and watching several hundred gigabytes crawl through Robocopy.

Things I Would Do Differently Next Time

The experience definitely changed how I'd approach another Windows failure.

For starters, I probably wouldn't immediately Robocopy the entire Windows drive again.

Watching WinSxS, caches, temporary files, installed applications and enormous Android images consume time and disk space taught me that lesson fairly effectively.

I'd prioritise irreplaceable data first:

personal files;
development projects not already backed up;
configuration files;
PowerShell profiles and scripts;
credentials and recovery material that can safely be backed up;
anything else that cannot simply be downloaded or reinstalled.

Only after securing those would I consider whether a complete drive-level copy was actually useful.

I'd also make sure my recovery keys remain organised and accessible independently of the affected computer.

And I'm keeping the external development SSD strategy.

That one proved itself.

One More Backup Before Calling It Done

Once Windows was working again, there was one particularly important little file I wanted copied somewhere safe:

my PowerShell $PROFILE.

After everything we'd just been through, losing a heavily customised PowerShell environment because it existed in only one place suddenly seemed like an unnecessarily exciting future adventure.

So that got Robocopied over to the external SSD too.

Because apparently once you've spent 48 hours using Robocopy, eventually you start using it for everything.

What I Took Away From the Incident

The obvious lesson is that a third-party driver can cause surprisingly dramatic Windows startup failures.

But that isn't actually the lesson I value most.

The bigger ones are these:

A scary error isn't necessarily the root cause.

The Recycle Bin corruption warning looked significant. It wasn't the thing ultimately preventing Windows from starting.

Safe Mode is evidence, not merely a recovery button.

The fact that Safe Mode worked while normal startup didn't gave us information about where the problem might be.

Protect your data before performing risky repairs.

Diagnosis is easier when every experiment isn't gambling your files.

Keep recovery credentials somewhere recoverable.

BitLocker wasn't a problem because I still had the keys required to access my own drive.

Separate your development environment from the physical machine where practical.

My laptop temporarily becoming unusable didn't mean my entire development setup disappeared with it.

And perhaps most importantly:

Root-cause analysis is allowed to take you down paths that don't ultimately contain the root cause.

Those paths aren't necessarily wasted effort.

Sometimes they're what make the next diagnostic step safe.

The Five-Minute Fix That Took 48 Hours to Find

Looking back, there's something rather funny about the scale difference.

The failure looked catastrophic.

The recovery copy took nearly two days.

Windows Automatic Repair couldn't diagnose it.

I went through Safe Mode, BitLocker, Robocopy, power settings, filesystem concerns, enormous Android images, external storage and enough Windows directories to last me quite happily for several years.

And then:

aswNetHub

Disable one problematic driver.

Reboot.

Hello, desktop.

If I'd known the answer at the beginning, this would have been a five-minute story.

But I didn't.

And that's debugging.

I Got Tired of Running Lighthouse Manually, So I Automated It

Kristieene Knowles — Fri, 24 Jul 2026 14:13:33 +0000

Lighthouse has been one of those tools I've used throughout my web development journey.

For a small website, running a Lighthouse audit manually isn't really a problem.

Open DevTools, run the audit, look through the results, fix what needs fixing, and move on.

That works perfectly well when you're dealing with a handful of pages.

But Web Weavers World isn't really a handful of pages anymore.

As the site has grown, I've found myself wanting to audit more than just the homepage. There are project pages, showcase pages, tools, experiments, forms, and other parts of the site that can all behave differently.

Running Lighthouse manually across all of those pages gets repetitive very quickly.

So, naturally, I automated it.

The Problem Wasn't Lighthouse

I want to make something clear first: manual Lighthouse testing is still useful.

I haven't built this because I think manually running Lighthouse is somehow bad or outdated.

If I'm working on one page and want to quickly see how it's performing, opening Lighthouse and running an audit is probably still the easiest option.

The problem appears when I want to ask a slightly different question:

"How is the whole website doing?"

Suddenly, testing one page isn't enough.

If a website has 5 pages, manually auditing them isn't particularly painful.

If it has 50, 100, or more URLs, that's a very different workflow.

At that point I'm not really spending my time analysing Lighthouse anymore.

I'm spending my time repeatedly launching Lighthouse.

And repetitive development tasks are increasingly becoming something I look at and think:

"Can I automate this?"

Turning Lighthouse Into a PowerShell Function

My solution was to build a PowerShell Lighthouse auditing function.

Instead of opening each page individually, I can give the function the pages I want to audit and let it work through them for me.

More importantly, I added support for sitemap auditing.

That means I can point it at a site's sitemap, let it collect the URLs, and then run Lighthouse against those pages automatically.

For Web Weavers World, that changes the workflow completely.

Instead of:

Audit page.

Wait.

Save results.

Open next page.

Audit page.

Wait.

Repeat.

I can start one audit and let PowerShell work through the site.

Recently I ran it against my sitemap and watched it pass the 100-page mark.

At that point my PowerShell window started looking slightly like one of those games where hundreds of filenames fly past while something loads.

Except this time it was my website being audited.

Automation Doesn't Mean Ignoring the Results

This is something I've been thinking about quite a lot recently.

I've been automating more of my development workflow, but the goal isn't to remove myself from the process.

It's to remove the repetitive parts.

Lighthouse still decides what it wants to flag.

I still have to decide whether those findings matter.

A warning doesn't automatically mean something needs changing, and a good score doesn't automatically mean a page is perfect.

The automation simply gives me the information at a much larger scale.

That's the bit I find useful.

Instead of spending my attention running the tests, I can spend that attention understanding the results.

Then Came the Edge Cases

Of course, automating something that normally expects a human sitting in front of it introduces another problem.

Things go wrong.

One of the first things I wanted my auditor to handle properly was failed or unreachable pages.

When you're manually testing a website and a page doesn't load, you immediately know something has gone wrong.

An automated process needs to know what to do next.

I didn't want one broken URL to kill an entire site audit.

If the auditor has already successfully tested dozens of pages and then encounters one that fails, throwing everything away because of that single page would make the automation considerably less useful.

So the function can record that a page failed and continue onto the next one.

That distinction matters.

A failed page is itself useful information.

A failed audit shouldn't necessarily mean a failed auditing process.

Temporary Files Are Still Files

Another interesting part was cleanup.

Running Lighthouse programmatically creates temporary files and intermediate data that are useful while an audit is running but aren't necessarily things I want hanging around afterwards.

This produced one slightly terrifying moment.

During one of my runs I saw output saying files had been removed.

As a developer who has previously experienced the joy of seeing unexpected "deleted" messages appear in a terminal, that wording gets your attention very quickly.

Thankfully, it was doing exactly what it was supposed to do.

It was cleaning up its own temporary files.

But it highlighted another part of automation that I think is easy to overlook.

Cleanup is part of the feature.

Creating temporary files is fine.

Leaving temporary files scattered around after every audit isn't.

So the auditing process doesn't just need to know how to start.

It needs to know how to finish cleanly as well.

The Interesting Part Is Scale

The actual Lighthouse tests haven't fundamentally changed.

I'm still using Lighthouse.

I'm still looking at performance, accessibility, best practices, SEO, and the other information it provides.

What has changed is the scale at which I can use it.

That's something I've started noticing with quite a few of my development tools.

A manual workflow can be perfectly good and still stop being practical as a project grows.

The question isn't always:

"Is there something wrong with this workflow?"

Sometimes the better question is:

"Does this workflow still scale?"

For manually auditing one page, yes.

For repeatedly auditing an entire site, not really.

And that's where automation becomes useful.

What I've Learnt From Building It

One of the biggest things I've learnt from building development utilities like this is that the main feature is usually the easy part.

"Run Lighthouse against a list of URLs" sounds straightforward.

And conceptually, it is.

But a useful tool has to deal with everything around that happy path.

What happens when a page fails?

What happens when a URL can't be reached?

What happens to temporary files?

Should one failure stop everything else?

How do I make the final results useful instead of producing a mountain of raw output?

Those edge cases are what turn a script that works on my machine once into something I can actually rely on.

And I think that's probably my main takeaway from this project.

Automate the Repetition, Keep the Decisions

I don't think every development task needs automation.

Sometimes clicking a button is genuinely easier than building a system to click the button for you.

But once I notice myself doing the same predictable process dozens of times, that's usually a sign that it's worth reconsidering the workflow.

Lighthouse is a good example.

Manual auditing hasn't become bad.

My website simply grew beyond the point where manually running every audit was the best use of my time.

So now PowerShell handles the repetitive part.

Lighthouse handles the auditing.

And I get to focus on the bit that actually needs a developer:

Deciding what to do with the results.

Sometimes automation doesn't need to replace a tool.

It just needs to make an existing tool easier to use at scale.

From Project Feature to Reusable Package – Building My Dynamic Theme Kit

Kristieene Knowles — Tue, 14 Jul 2026 13:06:44 +0000

One of my recent goals has been making my code more reusable instead of solving the same problem in every project.

A good example of that is my Dynamic Theme Kit (DTK).

DTK didn't begin life as a package.

It started as the theming engine inside my One Piece Tracker project.

As that project grew, so did the theme system. It eventually reached the point where I realised I wasn't building a theme engine for one application anymore—I was building something that could be useful everywhere.

Instead of copying pieces of code into future projects, I decided it was time to extract it into its own standalone package.

Step 1 – Extracting it

At first I thought this would mostly be moving files around.

It wasn't.

The real challenge wasn't writing new code—it was separating reusable logic from application-specific logic.

That meant identifying everything that genuinely belonged to the theme engine and leaving behind everything that only existed because One Piece Tracker happened to need it.

After several rounds of refactoring, I ended up with a package whose only responsibility is generating theme variables.

It doesn't try to style an application.

It simply exposes CSS variables that each project can consume however it wants.

That separation of responsibilities immediately made the whole design cleaner.

Step 2 – Making it genuinely reusable

Extracting the code wasn't enough.

The next challenge was proving it wasn't secretly relying on assumptions from the original project.

I wanted integrating DTK to be as lightweight as possible.

Ideally, another project should only need to include the kit, provide a palette configuration, and continue styling itself normally.

That meant improving the documentation, simplifying the configuration, removing unnecessary coupling, and making sure DTK wasn't making decisions that belonged to the application itself.

Step 3 – Libraries expose your assumptions

The biggest surprise came once I started using DTK in other projects.

Every integration uncovered another assumption I'd accidentally baked into the original implementation.

One project still used an older CSS variable.

Another highlighted that gradient backgrounds needed different handling.

Another showed that parts of my documentation only made sense because I already knew how the original project worked.

None of those were bugs.

They were assumptions.

Every time I removed one, DTK became less like "theme code extracted from another project" and more like a toolkit that could genuinely stand on its own.

Those smaller projects became the perfect test environment.

Step 4 – Integrating it into Web Weavers World

Once I was confident DTK was genuinely reusable, I integrated it into my business website, Web Weavers World.

This felt like the real test.

Unlike my smaller experiments, this is the website that represents my work as a developer.

I didn't just want the themes to work—I wanted the integration to feel natural.

Seeing the site switch themes using a completely standalone package was a satisfying moment.

Even better, I realised future themes no longer require changes throughout the application.

Adding another theme is now largely a matter of adding another palette.

That's exactly what I'd hoped to achieve when I first started extracting the code.

Lessons learned

Extracting a feature into a reusable package is much harder than building it for a single application.

The difficult part isn't the code.

It's removing assumptions.

Questions like:

Is this variable actually generic?
Does this behaviour belong in the package or the application?
Am I solving a reusable problem or a project-specific one?

became much more important than writing new functionality.

More importantly, the process has changed how I think about development.

Instead of asking:

"How do I build this feature?"

I increasingly find myself asking:

"Could this become something I can reuse in every future project?"

That small change in mindset has probably been the biggest benefit of building DTK.

Sometimes the best refactor isn't making code shorter.

It's making code useful more than once.

Entering My Automation Era (Without Letting AI Build My Code)

Kristieene Knowles — Thu, 04 Jun 2026 05:59:04 +0000

On 30th June 2025, I started my web development journey. At the time, my focus was simple: learn the fundamentals, build websites, solve problems, and improve with every project. Like most developers starting out, I spent my days learning HTML, CSS, JavaScript, accessibility, responsive design, deployment, debugging, and occasionally breaking things in ways I didn't think were possible.

Fast forward to today, and I've realised I've entered a new phase of development.

Not an "AI builds everything for me" phase.

An automation phase.

When people hear the word automation, they often assume it means handing over your codebase and hoping for the best. For me, it's been the opposite. I still design my websites, write the functionality, make the architectural decisions, and review everything that matters. The websites are still mine. What has changed is that I've started automating the repetitive tasks around development rather than development itself.

Over the past few months, I've been building up a collection of GitHub Actions, repository audits, validation checks, reporting tools, and AI-assisted review workflows. My repositories now contain security scanning, dependency auditing, workflow validation, issue prioritisation reports, documentation updates, repository health checks, and automated quality reports. None of these tools are writing client projects for me. Instead, they're acting as a second set of eyes, constantly reviewing things that would otherwise require manual effort.

AI As A Team Member, Not A Replacement

One of the biggest mindset shifts I've had is moving away from asking:

Can AI build this for me?

and instead asking:

Can automation help me verify this?

As a solo developer, I don't have a dedicated QA engineer, security reviewer, documentation writer, or DevOps team. That's usually just... me.

Automation helps bridge that gap.

A GitHub Action can run checks while I'm asleep. An automated report can highlight issues before they become problems. An AI review can spot patterns I might miss after staring at the same code for hours. None of that removes my responsibility as the developer; it simply gives me more visibility into what's happening across the codebase.

The Review Era

The interesting thing is that most of my automation isn't focused on creating code.

It's focused on reviewing code.

That's where I've found the biggest value.

The more automation I add, the more involved I become in the actual development process. Instead of spending time on repetitive checks, I spend more time making decisions, reviewing results, improving architecture, and focusing on the user experience. Automation hasn't reduced my responsibility as a developer; it's given me better tools to manage it.

That small change in thinking—moving from code generation to code verification—has probably saved me more time than any code-generation tool ever could.

Looking Back

If you had told me on 30th June 2025 that I'd eventually have automated audits, repository health reports, workflow validation, issue prioritisation, monitoring, and AI-assisted review processes running across my projects, I probably wouldn't have believed you.

At the time, I was just trying to make websites work.

Today, I'm building systems that help keep those websites healthy.

And honestly, that's been one of the most rewarding parts of my development journey so far.

The code is still mine.

The decisions are still mine.

The responsibility is still mine.

I've just built myself a really efficient team.

That Moment You See ‘Deleting…’ in Git Bash

Kristieene Knowles — Wed, 04 Mar 2026 20:51:34 +0000

The Fear of Using Git Bash Too Early in Your Dev Journey

When I first started learning development about six months ago, Git Bash felt like stepping into a control room full of buttons I didn’t understand.

I had connected Git to my local VS Code environment and thought:

“Okay, this must be what developers use… I’ll just follow along.”

The problem was that I didn’t actually understand the commands I was running.

One day I ran a command in Git Bash and suddenly my terminal started printing lines that included words like “deleting”.

My brain instantly went into panic mode.

Not deleting in the repo.

Deleting in my actual Windows file system.

Inside my /htdocs/ folder.

At that moment I realised something important about Git:

Git is powerful — but if you don’t understand what a command does, it can be terrifying.

I aborted the command as quickly as I could, but by then the damage had already started.

For a few seconds I genuinely thought I had just lost my entire working project.

Thankfully, I had a backup, so I restored everything and carried on.

But that moment taught me two lessons that stuck with me.

Lesson 1 — Git Isn’t Dangerous, Ignorance Is

Git commands can look intimidating because they operate at a very powerful level of your file system.

When you see words like:

reset
clean
rm
delete

…it feels like you're about to destroy your project.

But Git isn't the enemy.

Running commands without understanding them is.

Once I slowed down and actually learned what commands like checkout, pull, and reset do, Git stopped feeling scary and started feeling like a safety net.

Lesson 2 — Always Backup Your Work

The real hero of that moment was my backup.

If I hadn’t had one, I genuinely could have lost hours (or days) of work.

After that experience, I decided to automate the process.

I created a small PowerShell script that automatically backs up my /htdocs/ folder, so I always have a copy of my working files.

Now backups happen without me even thinking about them.

That one small script removed an enormous amount of stress from my workflow.

Lesson 3 — Fear Is Part of the Learning Curve

Looking back, the fear I felt in that moment was actually part of the learning process.

Every developer eventually reaches a point where they realise:

Tools like Git aren’t just version control — they’re power tools.

And power tools require respect.

Once you understand them, they stop being scary and start being incredibly useful.

Final Advice for New Developers

If you're just starting with Git:

Don’t blindly copy commands from tutorials

Take time to understand what each command does

Always keep backups of your important work

Because one day you will see the word “deleting” fly past in a terminal…

…and your heart will skip a beat.

Trust me on that.

I Built My Own dev.to Feed Page Instead of Embedding a Widget

Kristieene Knowles — Sat, 28 Feb 2026 20:21:11 +0000

There’s an easy way to show your dev.to posts on your website.

You paste in a widget.
You let it render.
You move on.

I almost did that.

But the more I looked at it, the more it felt slightly disconnected from how I build everything else.

So I didn’t embed it.

I built my own feed page instead.

Why I Didn’t Use the Widget

This wasn’t about avoiding convenience.

It was about consistency.

My site is fully hand-built — HTML, CSS, JavaScript, structured layouts, injection layers, theme handling. Everything is intentional.

Dropping in a third-party widget would have worked, but it wouldn’t have felt like part of the system.

It would’ve been something sitting inside it.

And that difference matters more than it sounds.

The Approach

dev.to provides a public RSS feed. That’s data.

So instead of embedding a UI component, I fetched the feed, parsed the XML, and rendered the posts as native components on my site.

No iframe.
No external styling.
No layout overrides.

Just data → structured objects → my own card components.

That means:

The posts match my design system
The spacing, typography, and hover states are consistent
The performance impact is minimal
The page works whether someone is logged into dev.to or not

It feels integrated rather than attached.

What I Like About This Pattern

RSS is simple.

It’s stable.
It’s predictable.
It doesn’t try to control your layout.

That separation — content from presentation — is powerful.

dev.to handles publishing and discovery.
My site handles display and brand.

Both do what they’re good at.

A Small Architectural Win

This isn’t a huge feature.

It’s not complex.

But it reinforces something I’ve been learning while building everything from scratch:

Control over the surface area of your site makes everything cleaner long term.

When you own the presentation layer, you’re not negotiating with someone else’s styles, scripts, or structure.

You’re just working with data.

And I prefer building that way.

If you’re building a personal site and want your blog content there too, consider pulling the feed instead of embedding the widget.

It’s a small change — but it keeps your architecture intentional.

I Built My Own Wordle Engine to Support How I Actually Think

Kristieene Knowles — Sat, 28 Feb 2026 10:30:56 +0000

Why I Built My Own Wordle

Like a lot of developers, I enjoy Wordle.
But after playing for a while, I realised I didn’t just want to play it — I wanted to understand it.

So instead of cloning a template, I built my own Wordle engine from scratch.

Not because the world needed another clone.

But because I wanted:

Full control over the word pool
Seeded daily logic I understood completely
A stats system I could extend cleanly
And a version that reflected how I actually think when solving puzzles

That’s how Web Weavers Wordle started.

Custom Word Pool (Under 1k → Nearly 6k Words)

Originally, my word list was tiny — under 1,000 entries.

It worked, but it felt constrained.

So I rebuilt the dictionary layer entirely.

Instead of a single static list, I moved to:

Separate .txt files per word length
Dynamic loading
A combined VALID_SET for fast validation
Per-length counts for UI stats

The pool is now just under 6,000 words, all curated to match the theme (every answer starts with W).

It’s modular, scalable, and easy to extend — without bloating the main script.

That refactor alone made the project feel like a proper engine instead of a weekend experiment.

Daily Logic (Seeded, Predictable, Controlled)

For the daily mode, I didn’t want randomness.

I implemented seeded selection based on the local date:

function seedFromDate() {
  const d = new Date();
  return d.getFullYear() * 10000 + (d.getMonth() + 1) * 100 + d.getDate();
}

This means:

Everyone gets the same word on the same day
The day flips at local midnight
No server needed
No external API calls

It’s deterministic and self-contained.

Which is exactly how I like my systems.

The UX Gap I Noticed

This is where it got interesting.

When solving Wordle, I don’t like filling unknown spaces with random letters.

Before, if I was thinking through a word like:

W _ S T _

I would temporarily type something like:

W W S T W

Just to fill the row visually.

But that felt wrong.

Those letters weren’t information — they were noise.

So I added a new state.

A manual ? placeholder.

Now I can type:

W ? S T ?

It:

Visually preserves structure
Doesn’t affect validation
Cannot be submitted
Acts as a deliberate “unknown” marker

It sounds tiny.

But it fundamentally changed how the puzzle feels to solve.

It added an intentional “thinking state” between blank and evaluated.

And I haven’t seen other clones do that.

What I Didn’t Build (Yet)

I considered expanding daily mode to every word length.

Technically, it would be easy.

Architecturally? It touches:

Stats storage
Streak logic
UI distribution trees
LocalStorage keys
Share formatting

So I didn’t.

The current version is:

Stable.
Clean.
Focused.

I’d rather refine than expand.

Final Thoughts

This project started as curiosity.

It’s now a modular, seeded, PWA-enabled Wordle engine with:

Nearly 6,000 words
Custom daily logic
Clean stats tracking
Share image generation
And a small UX improvement I genuinely love

Sometimes the best way to understand a system is to rebuild it.

And sometimes rebuilding it lets you improve it in small, meaningful ways.

The live version is here, if you'd like to try it; https://webweaversworld.co.uk/html/main/wordle/index.html

When Regex Meets the DOM (And Suddenly It’s Not Simple Anymore)

Kristieene Knowles — Thu, 26 Feb 2026 10:03:46 +0000

I recently built a custom in-page “Ctrl + F”-style search and highlight feature.

The goal sounded simple:

Support multi-word queries
Prefer full phrase matches
Fall back to individual token matches
Highlight results in the DOM
Skip <code> and <pre> blocks

In my head?

“Easy. Just build a regex.”

Step 1: Build the Regex

If a user searches:

power shell

I generate a pattern like:

power[\s\u00A0]+shell|power|shell

The logic:

Try to match the full phrase first
If that fails, match individual tokens

On paper? Clean.

In isolation? Works.

Step 2: Enter the DOM

This is where things escalated.

Instead of just running string.match(), I had to:

Walk the DOM
Avoid header UI
Avoid <pre>, <code>, <script>, <style>
Avoid breaking syntax highlighting
Replace only text nodes
Preserve structure

That meant using a TreeWalker.

const walker = document.createTreeWalker(root, NodeFilter.SHOW_TEXT, {
  acceptNode(node) {
    const p = node.parentElement;
    if (!p) return NodeFilter.FILTER_REJECT;

    if (p.closest("code, pre, script, style")) {
      return NodeFilter.FILTER_REJECT;
    }

    return NodeFilter.FILTER_ACCEPT;
  },
});

Now we’re not just doing regex.
We’re doing controlled DOM mutation.

Step 3: The Alternation Problem

This is where it got interesting.

Even though the phrase appears first in the alternation:

phrase|token1|token2

The engine still happily matches:

power
shell
PowerShell

Depending on context.

So now the problem isn’t “regex syntax”.

It’s:

Overlapping matches
Execution order
Resetting lastIndex
Avoiding double mutation
Preventing nested <mark> elements

Step 4: Two Passes?

At one point I thought:

Maybe this shouldn’t be one regex.

Maybe the logic should be:

Try phrase match
If none found, then try token match

Which sounds simple…

Until you realise your DOM has already been mutated once.

Now you’re managing state across passes.

The Realisation

I understand JavaScript logic.

I understand regex.

But applying that logic safely across a live DOM tree?

That’s a different tier of problem.

Regex is deterministic.
The DOM is structural and stateful.

And once you start replacing text nodes, everything becomes delicate.

What I Learned

Regex problems are easy in isolation.
DOM mutation problems are easy in isolation.
Combining them multiplies complexity.

Also:

The line between “simple feature” and “mini search engine” is very thin.

Where I Am Now

The search works.

Mostly.

It highlights.
It skips protected blocks.
It respects structure.

But it’s not a browser-level Ctrl + F.
Not yet.

And that’s the interesting part.

I now respect the DOM far more than I did before.

And I never thought I’d say this sentence naturally:

I get the logic of JavaScript.
Making that logic behave predictably inside a living DOM tree is the real challenge.

There’s still refinement to do.
Edge cases to tame.
State to simplify.

But that’s the line between “feature complete” and “actually robust.”

And I’m somewhere in the middle of that line.

I Learned More Building One Testimonial System Than From Months of Tutorials

Kristieene Knowles — Wed, 25 Feb 2026 06:10:40 +0000

When I first got into web development, it was very much the “web” side of things that pulled me in.

HTML. CSS. Making something appear on a screen from nothing.

There’s something powerful about writing a few lines of code and seeing it come alive in a browser. That never really gets old.

But over time, something shifted.

I started caring less about just how things looked… and more about how they worked.

The logic.

The structure.

The “why is this doing that?” moments.

Recently, I built my own testimonial system for my site. On the surface, that sounds simple. Just a form and some displayed text, right?

It wasn’t.

I had to think about:

How the data gets stored
How to structure it properly
Validation
Preventing abuse
Connecting front-end to database
Triggering actions after submission
And making sure it all behaves in production, not just locally

There were moments where I broke it.
Moments where I misunderstood how APIs worked.
Moments where I thought I’d finished… only to realise I hadn’t accounted for edge cases.

But that’s where the learning really happened.

I realised something important:

You don’t become “full-stack” by calling yourself full-stack.

You become it by building things that force you to learn the layers underneath.

What started as “I want a testimonials page” turned into:

Working with databases
Understanding data flow
Thinking about security
Writing logic I didn’t think I could write a few years ago

And honestly? That’s been the most satisfying part.

Not the polished UI.
Not the final version.

The messy middle.

The debugging.
The rewrites.
The moments where something finally clicks.

I’m still learning. A lot.

But every time I build something that stretches me a bit further than last time, I feel like I’m actually becoming the developer I wanted to be when I was younger.

And that’s a good feeling.

Why I Still Build Websites From Scratch in 2026

Kristieene Knowles — Tue, 24 Feb 2026 05:15:08 +0000

In a world of drag-and-drop builders, AI site generators, and one-click themes, choosing to build websites from scratch can feel unnecessary.

But I still do.

I run an independent studio, Web Weavers World, where every site is hand-coded. No templates. No visual builders. No plugin stacks layered on top of each other.

That’s not because modern tools are “bad.” They’re incredibly useful. They solve real problems.

I just value control.

When I build from scratch, I know exactly:

What loads and when
Why a layout behaves the way it does
How performance is impacted
What the accessibility trade-offs are
Which scripts are truly necessary

There’s no mystery layer.

Performance matters to me. Not just Lighthouse scores, but real-world responsiveness. Clean architecture matters. Maintainability matters. Accessibility matters.

And honestly ~ I enjoy it.

There’s something satisfying about understanding every moving part of a system you built. From the CSS structure to the backend logic to the analytics tracking.

It also forces better decisions.

When you don’t have a plugin to solve everything, you think more carefully about whether something needs to exist at all.

That constraint is valuable.

I’m not anti-tool. I use modern workflows, automation, and analytics daily. But I choose intentional complexity over hidden complexity.

That’s why I still build websites from scratch in 2026.

Curious how others approach this ~ are you all-in on frameworks and builders, or do you still enjoy the raw build process too?