DEV Community: Krystian

I tested 20 websites for consent timing — 14 loaded analytics before user approval

Krystian — Thu, 12 Feb 2026 17:56:00 +0000

We see cookie banners everywhere.

But I wanted to check something simple:

Do websites actually wait for user consent before loading analytics?

So I tested 20 sites (SaaS, e-commerce, agencies, blogs).

The result?

14 out of 20 loaded analytics before the user clicked “Accept”.

In most cases:

The banner was visible
No interaction had happened
But GA/GTM requests were already firing

Visually compliant.
Technically… not really.

How I measured it

Instead of manually watching DevTools every time, I built a small tool to monitor:

Cookies being set
localStorage / sessionStorage usage
Network requests to common tracking domains
The exact timestamp of the consent click

Core logic:

If tracking_timestamp < consent_click_timestamp
→ tracking happened before consent

Simple in theory. Messy in real-world implementations.

The tricky parts

SPAs injecting CMP late
GTM containers firing too early
Server-side tagging hiding third-party domains
Heuristic detection vs explicit CMP integration

Most issues looked like misconfiguration — not intent.

Why this matters

As developers, we often:

install GTM
plug in analytics
add a CMP
assume everything is fine

But unless you verify timing, tracking may fire earlier than expected.

The browser doesn’t lie.
Network requests don’t lie.
Timestamps don’t lie.

If you want to test this yourself

I packaged the tool into a Chrome extension called ConsentScope.

You can check it here:
👉 https://www.consentscope.pro/

It’s not a legal tool — just a technical way to inspect what fires before and after consent.

Curious how others are validating consent timing in their projects.

No Kotlin? No Problem. How I shipped Android Apps using React & Capacitor

Krystian — Mon, 12 Jan 2026 17:50:29 +0000

For years, I thought mobile development was reserved for "native" developers. I looked at Java and Kotlin code, and frankly, I wanted to run away. I am a web developer. I think in terms of React components, hooks, and CSS.

But this week, I achieved something I didn't think was possible for me: I published my first two applications on the Google Play Store. And the best part? I didn't write a single line of native code.

Here is how I did it, and one mistake you should avoid.

The False Start: PWABuilder At first, I tried to take the shortest shortcut possible. I used PWABuilder to simply package my existing Progressive Web App into an APK.

It sounded perfect on paper, but in reality, it felt... pointless. While it technically worked, I felt like I had zero control over the native experience. It was just a website pretending to be an app, with limited access to device features and a shaky user experience. I realized that if I wanted to be on the Store, I needed something more robust.

The Solution: React + Capacitor. That’s when I found Capacitor. If you are a React developer, this tool is a superpower. Unlike PWABuilder, Capacitor allows you to keep your standard web development workflow but gives you a runtime that bridges the web world with the native world.

My workflow looked like this:

I built my UI in React (just like I do for the web).
I used Capacitor to wrap the build output.
I generated the Android project folder and opened it in Android Studio only to hit the "Build" button.

Suddenly, I had access to native plugins, a real file structure, and a performant app that didn't feel like a cheap wrapper.

The Boss Battle: Google Play Console Coding the app was actually the easy part. The real challenge was the Google Play Console. If you are an indie developer, be prepared for a bureaucratic nightmare:

The Verification Process: It’s getting stricter every year.

Privacy Policies: You can't just ignore them anymore.

Testing Tracks: You need 12 testers for 14 days before you can even think about production (if you have a personal account created after Nov 2023) - annoying AF...

It took me some time, but finally seeing that green "Approved" status is one of my biggest wins this year.

The Result Both apps are now live. They aren't perfect, but they are shipped.

So If you are a web developer afraid of mobile stores: Just do it. Don't waste time on shortcuts like basic PWA wrappers if you want a real store presence. Go with Capacitor (or React Native), leverage your JS skills, and push through the Google Play verification. It's worth it.

Stop Crashing VS Code: How to View 10GB Log Files in Your Browser

Krystian — Sat, 06 Dec 2025 00:13:59 +0000

The "Friday Deploy" Nightmare 😱

We've all been there. It’s Friday afternoon, production acts up, and you need to investigate. You SSH into the server, find the error.log, and... it’s 8.5 GB.

You download it. You try to open it with VS Code.
Result: The window freezes. Your fans spin up like a jet engine. The OS asks if you want to kill the process.

You try Notepad++. It complains the file is too big.
You try less or grep in the terminal, but reading JSON logs in a console is a pain.

This specific frustration led me to build a tool that solves this problem once and for all.

Meet Log Voyager 🛸

I built Log Voyager – a specialized, web-based tool designed specifically to handle massive log files without eating your RAM.

It runs entirely in your browser, works offline, and—most importantly—it opens 10GB+ files instantly.

🛠️ How It Works (The Technical Part)

Why does VS Code crash? Because it tries to load the entire file string into memory (RAM) to tokenize and render it.

Log Voyager uses a different approach: File Slicing.

Instead of reading the whole file, it uses the native HTML5 File API, specifically the .slice() method.

It reads the file metadata (size).

It calculates which "chunk" (e.g., 50KB) corresponds to your current scroll position.

It reads only those bytes from the disk into memory.

This means the memory footprint is constant (~20MB), whether your log file is 5MB or 500GB. It acts like a "window" sliding over the data on your hard drive.

✨ Key Features for Backend Devs

Besides not crashing your computer, I added features that I personally missed in other tools:

🔒 Privacy First (Local Execution): This was critical. Even though it's a website, your files are never uploaded anywhere. The processing happens 100% locally in your browser's sandbox. Safe for sensitive production logs.

JSON Prettifier: If your logs are messy JSON blobs, Log Voyager detects them. One click formats them into a readable tree structure.

Warp Jump Bookmarks: Navigating a 10GB file is hard. You can "bookmark" a line, scroll 5GB down, and then "warp" back to the exact byte offset instantly.

Mobile Friendly: Since it's efficient, it works perfectly on mobile. You can analyze logs on your phone while away from your desk.

🚀 Try It Out

It is a free, open-source project. If you are looking for a reliable huge log file viewer, give it a spin next time you face a giant log file.

👉 Live App: logvoyager.cc
💻 GitHub: hsr88/log-voyager

Let me know in the comments if you have any feature requests! I'm actively working on adding regex filtering next.

Happy debugging! 🐛

A Cyberpunk notification library with glitch animations and typewriter effects.

Krystian — Thu, 04 Dec 2025 17:48:58 +0000

Just finished my latest open-source project: CyberToast.js. A zero-dependency notification system focused on Sci-Fi aesthetics. It taught me a lot about DOM manipulation and CSS animations. Check it out on GitHub!
https://github.com/hsr88/cyber-toast-js