FediScanner

#react

← Back
07.10.2026 11:36
display (@display@www.urbanmind.net)

A competitor comparison page is a set of public assertions about somebody else's business. Three states instead of two, a required sentence in every cell, and a source note that renders nothing when there is nothing to cite.#webdev #seo #react #typescript #software #coding #development #engineering #inclusive #community
Our comparison tables have three states, and 15 of their 46 rows hand the win to the other product

Show Original PostReport
07.10.2026 09:43
medconweb (@medconweb@mastodon.social)

REACT soll KI-Entscheidungen auf Intensivstationen verbessern
Forschungsverbund erhält 2,8 Mio. Euro und entwickelt FHIR-basierte Datengrundlage für Antibiotikatherapie und Kreislaufwarnung

medconweb.de/blog/it-edv/react

Show Original PostReport
07.10.2026 09:00
mzunain (@mzunain@mastodon.social)

🌐 Building multilingual apps with Next.js i18n:

Key decisions:
→ next-intl (my pick, great DX)
→ URL strategy: /en/about vs about (default EN)
→ RTL support: dir="rtl" on <html>
→ Pluralisation rules differ per language!
→ Date/number formatting: always use Intl API

Building for Arabic taught me more about i18n than any tutorial.

Always test with real users of target language.

Show Original PostReport
07.10.2026 08:23
meduz (@meduz@m.nintendojo.fr)

GitHub has fully moved off CSS-in-JS to #CSS Modules, resulting in 55% less server-side render time and 25% faster component init: github.blog/engineering/archit

Took them a while to reverse their 2nd #frontend bad decision (the first one being: using #React).

If you know any team needing long-term help to reverse or avoid bad decisions, I can save you years. :n8rd:

Show Original PostReport
07.10.2026 08:18
GripNews (@GripNews@mastodon.social)

🌘 GitHub - shader-effects-inc/shaders：適用於 React、Vue、Svelte、Solid、JS 及 Framer 的 WebGPU 組件庫
➤ 跨框架 WebGPU 視覺特效的新標竿：從設計到程式碼的無縫體驗
✤ github.com/shader-effects-inc/
這款開源專案為開發者提供了一套強大的 WebGPU 宣告式組件庫，支援 React、Vue、Svelte 等多種主流框架。它將複雜的視覺特效封裝成直覺的組件結構，開發者只需透過疊加與混合圖層，便能在網頁上實現高品質的漸層、雜訊、玻璃質感與光影效果。專案結合了視覺化編輯器、CLI 工具以及 AI 代理支援，讓從視覺設計到程式碼實作的流程變得極其高效，大幅降低了高效能網頁圖形開發的技術門檻。
+ WebGPU 終於有這麼好用的宣告式庫了，以後在 React 實作酷炫特效省事得多。
+ 支援 MCP 協定讓 AI 代理能直接安裝並編輯 shader，這套工作流非常現代化且迷人。

Show Original PostReport
07.10.2026 07:34
display (@display@www.urbanmind.net)

I Spent an Entire Night Chasing 380 MB of Ghost Data


Tags: #react #debugging #javascript #webdev

Okay so. It's 2:47 AM. I'm on my third espresso. The cursor is moving through what I can only describe as wet cement. And I just realized the app is leaking memory. Like, aggressively leaking it. 380 MB per cycle. And I have to fix it before standup in nine hours.

Here's the thing that made this one special: nothing was broken. No red text in the console. No React warnings. No crash. The app just... got slower. Gradually. The way a room fills with smoke before you notice it. You'd use it for 20 minutes and suddenly every click felt like you were clicking through a thick liquid.

Users weren't filing bug reports. They were just closing the tab. Opening a new one. Feeling briefly better. And then it started again.

That's the worst kind of bug. The kind that doesn't announce itself.

So I did what any reasonable person does at 1 AM: I opened DevTools and started taking heap snapshots.

First one: 45 MB. Normal. Healthy. A resting heartbeat.

Then I opened and closed the dashboard ten times. Just mashing it. Stress test.

Second snapshot: 425 MB.

I stared at that number for a solid minute.

380 MB of new memory. That never got freed. And the pattern was monotonic — it only went up. Every single cycle added another chunk that just... stayed. Like someone was leaving the lights on in every room they walked out of.

I pulled up the comparison view and filtered for detached DOM nodes. And there they were. Hundreds of them. DOM elements from a component that had unmounted ages ago, still sitting there, still holding references, still existing in a way they shouldn't.

Ghosts.

Now, here's where it gets embarrassing.

I found three leaks. All in the same component. All fixable with cleanup functions I knew I should have written. All the kind of thing that takes four seconds to fix once you see it.

But you don't see it until 2 AM when you're comparing heap snapshots and your eyes are starting to glaze over.

The first one was a WebSocket. Opened on mount. Never closed. Every time someone navigated away, a new connection got created. The old one? Still there. Still breathing. Still holding data. Ten cycles meant ten live connections to a server that thought it was talking to one person.

The fix? return () => ws.close(). One line. I felt like an idiot.

The second one was event listeners. resize and scroll. Added on mount, never removed. After ten cycles, the window had twenty resize handlers and twenty scroll handlers. Every scroll event fired twenty functions. Every resize fired twenty more. It was like having twenty alarm clocks go off at 6 AM and somehow that's worse than one.

The third one is the one that actually kept me up. The subtle one.

A fetch call. Totally normal. Except the component could unmount before the promise resolved. And when it did resolve — 34 MB of chart data — it had nowhere to go. The component was gone. But the closure wasn't. It was still holding that data. Still referencing it. Keeping it alive in an empty room.

I had even created an AbortController. It was sitting right there in the code. Unused. Like a fire extinguisher bolted to the wall of a building that's already on fire. I just... never wired it up.

I don't know what I was thinking. Probably nothing. Probably I wrote it in a hurry, got distracted, and moved on. And it sat there for weeks doing nothing.

So I fixed all three. Wrote the cleanup functions. Added the abort logic. Added a mounted flag because I'm not a saint.

Ran the test again. Ten cycles. Snapshot.

46 MB.

From 425 to 46. The ghosts were gone. The dashboard could finally die when it was supposed to.

I closed DevTools. Stared at the ceiling. Drank the rest of the espresso. It was cold and I drank it anyway.

What I actually learned from this (beyond "write your cleanup functions, you absolute disaster"):

The bug wasn't hard. The finding was hard. The code was obvious in hindsight. But at 2 AM, when you're comparing two snapshots that look 90% identical, when the retained objects are spread across three different categories, when you're tired enough that your brain keeps auto-correcting "this shouldn't be here" to "this is probably fine" — that's when it gets hard.

So now I have a rule. A stupid simple rule I tape to my brain:

If your effect sets something up, it tears it down. No exceptions. No "I'll do it later." No "it's probably fine."

If you add a listener, you remove it. If you open a connection, you close it. If you start a fetch, you can cancel it. If you subscribe to anything, you unsubscribe.

That's it. That's the whole lesson. I just needed to write it down so I remember it the next time it's 2 AM and I'm drinking cold espresso and my cursor is moving through wet cement.

If you've ever spent an unreasonable amount of time on a bug that turned out to be a missing cleanup function, I need you to know: I see you. I respect you. I am you.#react #debugging #webdev #software #coding #development #engineering #inclusive #community
I Spent an Entire Night Chasing 380 MB of Ghost Data

Show Original PostReport