2026-01-08 21:00:12
I’m not a fangirl of any single framework. For me, frameworks are tools. Just like I prefer a good, sturdy hammer over a rusty one with holes... I also prefer tools that help me build software that’s maintainable and pleasant to work with. That’s why I like to stay up-to-date, understand how things work under the hood, and not just “use the thing everyone uses”.
I work with Angular on a daily basis — and yes, Angular forces you into a certain architecture (although believe me, you can still build absolute spaghetti in it… ask me how I know 😬).
But I genuinely love React. Whenever I do a side project, I very often reach for it. I adore JSX and how close React feels to plain JavaScript, especially compared to Angular. But… you know what they say: with great power comes great responsibility 😎 And in the wrong hands… that freedom can burn a project.
I’ve seen more than a few projects that weren’t just messy.
They looked like someone wrote them in jQuery, deleted $(document).ready, sprinkled some JSX over it… and genuinely tried to make it work 🤡
Was it a blind migration from an old codebase?
Was it devs who, deep in their hearts, never really left jQuery behind? 😉
Hard to say.
Either way - here are some classic signs your React code isn’t really React… it’s just jQuery wearing JSX. And yes, it shows. Loudly.
React file. Looks like .tsx. Technically it has sub-components. Maybe even a utility for CSS class names. But emotionally?
Emotionally, it feels like an old-school index.html with a giant script tag living inside 😂
Big blob. Fetching data. Updating UI. Managing events. Managing layout. Oh, and probably a modal, three dropdowns, a table and a sidebar too, because why not.
function App() {
const [data, setData] = useState([]);
const [sidebarOpen, setSidebarOpen] = useState(false);
const [filter, setFilter] = useState("");
useEffect(() => {
fetch("/api/items")
.then(res => res.json())
.then(setData);
document.getElementById("loader").style.display = "none";
document.getElementById("list").style.display = "block";
const el = document.getElementById("filter");
el.addEventListener("input", e => setFilter(e.target.value));
}, []);
return (
<>
<input id="filter" />
<div id="loader">Loading...</div>
<ul id="list">
{data.filter(d => d.includes(filter)).map(d => <li>{d}</li>)}
</ul>
<button onClick={() => setSidebarOpen(!sidebarOpen)}>Toggle</button>
<div className="sidebar">{sidebarOpen && "Hello"}</div>
</>
);
}
separate:
move logic to custom hooks when appropriate
avoid direct DOM manipulation — let React own the UI
remember: lots of small components > one god-component
useEffect that does… everything
useEffect(() => { /* 🤹♂️ everything happens here */ }, [])
Fetching data, adding event listeners, toggling classes, updating the DOM, talking to 7 different services, scrolling, analytics, toast notifications… all in one glorious effect.
Basically:
Take
$(document).ready, replace it withuseEffect, ship to prod 😎
useEffect(() => {
fetch("/api/stats")
.then(res => res.json())
.then(data => {
setStats(data);
document.title = "Dashboard";
document.getElementById("counter").textContent = data.users;
});
const resize = () => document.body.classList.toggle("mobile", window.innerWidth < 700);
window.addEventListener("resize", resize);
window.scrollTo(0, 0);
return () => window.removeEventListener("resize", resize);
}, []);
useEffect into multiple focused effects
useEffect !== lifecycle method
- avoid stuffing all app behavior into a single “runs once” effect
useEffect for things that should simply be in JSX
This one hurts a little 😅
Doing DOM manipulation in an effect just to update text, class, visibility, or something that JSX can declare naturally.
Instead of:
if condition → change DOM
React wants:
if condition → render something else
useEffect(() => {
const el = document.getElementById("message");
if (error) {
el.classList.add("visible");
el.textContent = error;
} else {
el.classList.remove("visible");
}
}, [error]);
Meanwhile React:
{error && <p className="message">{error}</p>}
think:
UI state stored… not in state
…not in props
…but… 🥁 in CSS class names.
The application logic becomes:
Congrats, you built a state machine… in your stylesheet 🙃
useEffect(() => {
const steps = document.querySelectorAll(".step");
steps.forEach(step => {
step.addEventListener("click", () => {
steps.forEach(s => s.classList.remove("active"));
step.classList.add("active");
});
});
}, []);
for complex flows consider:
useReducerrule of thumb:
Need animation?
Add/remove class in JS. Done.
React? Oh yes, still technically there 👀 Just quietly watching.
No state. No declarative transitions. No structure.
Just:
click → add class → remove class later → hope nothing breaks
function Notification() {
useEffect(() => {
const btn = document.getElementById("show");
const box = document.getElementById("note");
btn.onclick = () => {
box.classList.add("visible");
setTimeout(() => box.classList.remove("visible"), 2000);
};
}, []);
return (
<>
<button id="show">Show</button>
<div id="note" className="notification">Hello!</div>
</>
);
}
simplest option:
better options:
avoid imperatively driving animations when you can declare them
Rare… but I’ve seen it.
And once you see it, you never really forget it — it leaves a mark 😅
useState<HTMLDivElement | null>(null)
And then logic like:
That’s not React. That’s absolutely raw DOM puppet-mastering.
const [el, setEl] = useState(null);
useEffect(() => {
setEl(document.getElementById("target"));
}, []);
function highlight() {
el.style.background = "yellow";
}
ref
I’m not saying code must always be perfect.
Sometimes quick hacks are fine. Sometimes deadlines win. Sometimes legacy constraints are real.
But when React is used like jQuery with JSX…
React is powerful not because it manipulates DOM better.
It’s powerful because:
✨ State → UI
not
🔧 UI → patch → patch → patch
React gives freedom. And that freedom is beautiful.
But freedom requires responsibility. Without it, React becomes:
a jQuery with better branding
And that’s a bit sad, because React can give us structure, clarity, predictability — if we let it.
If your project smells like the things above…
it’s not a shame.
It just means there is history, pressure, context, and human decisions behind it.
But maybe it also means…
it’s time to pause, breathe, and rethink a little 😊
I’m super curious:
👉 Have you seen “React in jQuery cosplay” in the wild?
Share your stories, scars, confessions, or survival tips!
2026-01-08 21:00:00
Welcome to the finale of our Local Agent series.
Processing sensitive user data (PII) is risky. You can't send it to the cloud. You don't want to read it manually.
The PII Scrubber Agent demonstrates a "Level 2" Agent capability: Writing its own tools.
users.csv).users_cleaned.csv.Instead of rewriting the CSV line-by-line (slow and expensive), the Agent writes code to do it efficiently.
This workflow crashed smaller models (llama3.2). They would try to run the script before writing it!
We upgraded to gpt-oss:20b, which successfully:
We've built 4 agents:
And we did it all locally. No API keys. No data leaks. Just you, Goose, and Ollama.
Complete code is available on Github here.
Go build something cool! 🪿
2026-01-08 20:54:15
DTAP is a new testing protocol allowing to test infrastructure with just a Bash scripts. Here is a quick example, let's test that /etc/dhcp/ directory and /etc/dhcpcd.conf file exists:
#!/bin/bash
session=$(date +%s)
ls /etc/dhcp/ 2>&1 | dtap --box - \
--session $session \
--params path=/etc/dhcp/ \
--check path-ok \
--desc "dhcp/ dir"
ls /etc/dhcpcd.conf 2>&1 | dtap --box - \
--session $session \
--params path=/etc/dhcpcd.conf \
--check path-ok \
--desc "dhcpcd.conf file"
dtap --report --session $session
The result will be:
DTAP report
session: 1767875428
===
dhcp/ dir ...... OK
dhcpcd.conf file ...... OK
Plain and simple
As one can see test scripts are just plain Bash commands, no fancy YAML or even high level programming languages.
Also DTAP follows WYSIWYG principle when we get exactly what we see, in a sense this something we would do trying to check existing of mentioned directory and file:
ls /etc/dhcp/
ls /etc/dhcpcd.conf
And if any errors occurred we will will get exactly what we are asking for - output of ls command which most of the Linux users probably are familiar with:
!/bin/bash
ls /etc/does-not-exist 2>&1 | dtap --box - \
--session $session \
--params path=/etc/does-not-exist \
--check path-ok \
--desc "/etc/does-not-exist dir"
Output:
DTAP report
session: 1767875841
===
/etc/does-not-exist dir ...... FAIL
[report]
15:37:22 :: [sparrowtask] - run sparrow task .@path=/etc/does-not-exist
15:37:22 :: [sparrowtask] - run [.], thing: .@path=/etc/does-not-exist
[task run: task.bash - .]
[task stdout]
15:37:23 :: ls: cannot access '/etc/does-not-exist': No such file or directory
[task check]
stdout match <^^ "/etc/does-not-exist" $$> False
=================
TASK CHECK FAIL
2
How this works?
There are two essentials primitives in DTAP:
boxes
and - checks
Box is an abstraction for everything we want to test - from web server to messages in syslog files. Boxes produces some output to be checked against check rules ( aka checks ). In the previous examples - boxe is just ls command which output redirected to a certain check rule via --box - notation ( meaning read box output from STDIN ). DTAP comes with some predefined boxes user can use them without writing any piece of code, but most of the time boxes - are something a user would write as a chain of Bash commands something likes that:
#!/bin/bash
(
2>&1
cmd1;
cmd2;
cmd3;
# ...
) | tap --box -
Or with a single script:
#!/bin/bash
. /some/box/script.sh | tap --box -
Checks are rules written on formal DSL and executed remotely on DTAP server, so users don't need to install anything, only small tap binary written on golang that interacts with a server send output from boxes to a server and get results back. Checks DSL is based on Raku regular expressions and is super flexible, allowing many things to do including extension by using many general programming languages. To list available checks just run:
tab --check_list
Follow double tap web site documentation to get details on using available checks.
It's easy to create new checks and add them to DTAP distribution, if you are instead please let me know. There is quick start introduction into check DSL could be found here
Conclusion.
DTAP is a new kid on the block, that allows to test infrastructure with using just a Bash yet very flexible and powerful. I encourage you to play with it, you can start with installation guide
Thanks for reading
2026-01-08 20:50:25
API inspectors and debuggers are essential tools for web application development. Being able to inspect API requests and responses makes debugging much easier and more effective.
I often use Chrome DevTools to check request and response data. I have also been using HTTP Tracker, but one important feature was missing: capturing the response body.Since HTTP Tracker is open source, I spent a long time exploring the codebase and trying to implement this feature, but I was not successful at first.
I finally found a solution by using Chrome Debugger Mode, which makes it possible to capture the response body. While working on this, I also improved the UI to make it clearer and easier to use.
The update includes:
Response body capture for selected requests only
UI improvements for better readability and usage
I plan to publish this version to the Chrome Store and also submit a PR to the original project so others can benefit from it.
I have added a short GIF demo to show how it works.
GitHub repository (check the new branch): https://github.com/devded/http-tracker-plus
Feedback and suggestions are welcome.
2026-01-08 20:44:24
Most keyword tools are just thin wrappers around Google Autocomplete — but they hide the implementation behind subscriptions, APIs, and dashboards you don’t control.
I wanted something different:
A local desktop app
Written in plain Python
No API keys
No accounts
Full access to the source code
So I built KeySage, a Google Autocomplete keyword research tool using Tkinter, ttkbootstrap, threading, and requests — and I’m releasing both the EXE and the full source code.
Why Google Autocomplete?
Google Autocomplete is one of the most honest keyword datasets available.
Every suggestion:
Comes from real searches
Reflects user intent
Surfaces long-tail queries early
Under the hood, most SEO tools call the same endpoint:
https://suggestqueries.google.com/complete/search
KeySage connects to it directly — no API, no authentication.
High-Level Architecture
KeySage is a single-process desktop app with a background scraping thread.
Main components:
UI layer → Tkinter + ttkbootstrap
Networking → requests
Concurrency → threading + Event flags
Data model → sets + defaultdict
Exports → txt / csv / json
The goal was simplicity and hackability.
The Scraping Logic
Each base keyword goes through a configurable expansion pipeline:
Base keyword input
Optional prepend/append words
Character expansion:
a–z
a–z + 0–9
Google Autocomplete request
Deduplication
Live UI update
Example request:
params = {
"client": "firefox",
"q": query,
"hl": language,
"gl": country
}
requests.get(GOOGLE_SUGGEST_URL, params=params)
Results are streamed back to the UI using app.after() to keep Tkinter thread-safe.
Threading Without Freezing the UI
Tkinter is single-threaded, so scraping runs in a background thread.
Key patterns used:
threading.Thread(..., daemon=True)
threading.Event() for safe cancellation
UI updates marshaled back to the main loop
This allows:
Real-time keyword output
Instant cancellation
No UI hangs
Rate Limiting & Stability
Google doesn’t love aggressive scraping.
KeySage includes:
Built-in delays between requests
Optional proxy support
Stop-safe execution at every loop
This keeps the app usable without being reckless.
Automatic Keyword Clustering
After scraping, keywords are grouped by root word:
root = keyword.split()[0].lower()
clusters[root].append(keyword)
Simple? Yes.
Effective for content planning? Also yes.
Clusters are preserved across all export formats.
Exporting Data (Developer-Friendly)
Supported formats:
TXT → human-readable clusters
CSV → SEO tools & spreadsheets
JSON → automation & pipelines
Everything stays open and editable.
UI: Tkinter, But Not Ugly
The interface uses ttkbootstrap to avoid the “default Tkinter look”.
Features:
Responsive layout
Themed widgets
Collapsible advanced settings
Live scrolling output
Built-in help window
It’s intentionally minimal — no Electron, no web stack.
EXE vs Source Code
I’m offering three options:
Windows EXE ($7) — run instantly, no Python required
Full Source Code ($10) — learn, modify, extend
EXE + Source ($12) — best of both
👉 Get KeySage here:
https://matetools.gumroad.com/l/zwqcli
Why Release the Source Code?
Because developers learn best from real tools — not toy examples.
You can:
Add async requests
Improve clustering
Add new export formats
Integrate other suggestion sources
Turn it into a CLI or API
This is meant to be a foundation.
Final Thoughts
KeySage isn’t trying to replace enterprise SEO platforms.
It’s a transparent, hackable keyword tool built with:
Python
Common libraries
Simple architecture
No vendor lock-in
If you want a practical example of a real-world scraping + desktop app — or a tool you can actually use — this is for you.
👉 Buy / Download KeySage:
https://matetools.gumroad.com/l/zwqcli
2026-01-08 20:37:10
Nasab — Lineage
A framework for building AI systems that learn like nature intended.
This is documented thinking. The framework emerged through conversation with multiple AI systems. Each contributed. Each critiqued. The full lineage is preserved. Nothing is hidden. Nothing is deleted.
Nasab: Rethinking AI from First Principles
Faith, Evolution, and the Crocodile Strategy