Marek P. Kracl

🚨 Frontend Devs, quick question: Where do you store data on the client side? If your answer is always LocalStorage… we need to talk. 👀 🔗 Read full article here: https://lnkd.in/gtPWeMUU I see this mistake all the time: saving everything in LocalStorage — from auth tokens to big chunks of data. It feels convenient, but it can silently break your app’s performance, security, and scalability. The truth is: client-side storage isn’t one-size-fits-all. Each option — LocalStorage, SessionStorage, Cookies, IndexedDB — has strengths and serious pitfalls. 👉 In my latest blog, I break down: ✅ What each storage type is really good (and bad) at ✅ Real-world scenarios (dark mode, multi-step forms, caching, auth) ✅ A simple decision tree to help you pick the right one 🔗 Read full article here: https://lnkd.in/gtPWeMUU Curious to hear: how do you decide where to store data in your apps? Do you stick with one, or mix based on context? #Frontend #WebDevelopment #JavaScript #ReactJS #Performance #Architecture #Cookies #LocalStorage #IndexedDB #SoftwareDevelopment #WebPagePerformance #PageSpeed #Security #Architecture #ArtificialIntelligence #WebTechJournals #Fintech #FinancialApps

3

1 Comment

How are you managing multiple coding agents without it becoming a headache? I’ve got a system. Not sure if it’s good and it’s certainly not scaling to 10 agents running concurrently flexes I keep seeing, but here it is… Most task managers assume linear work. That breaks the moment you have several agents running in parallel. You end up with refactors half-done, tests generating, PRs waiting on judgment, specs that need tightening — and you bouncing between all of them “just to check.” I use two lists. **To do list** Conventional 'To Do' list. But more of a dumping ground than normal -- for anything new that comes in, I try not to let a new task become something I do immediately unless it relates to a customer. **Work list** The live queue. I pick one task and stay on it until it’s either done or genuinely blocked (agent running, waiting on input from a human, running slow tests). When it blocks, I scan the work list for the top thing that’s unblocked and continue. If everything’s blocked, only then do I pull something new from capture. That’s it. One human-attention thread at a time. Agents can parallelize. I can’t. Still requires a bunch of focus to keep me in flow state because of the context switching though. What else are people using to tackle this? How do I adapt this to get to next level concurrency?

27

8 Comments