Dan Neciu’s Post

Most performance problems are not caused by heavy code. They are caused by code running too many times. A search API called on every keystroke. A scroll event firing hundreds of times. A resize event triggering expensive calculations continuously. The UI feels slow. The backend gets unnecessary load. Users feel the lag. This is where Debounce and Throttle make a huge difference. Debounce says: “Wait until the user stops.” Perfect for: ✔ Search input ✔ Form validation ✔ Auto-save ✔ Final resize calculations Throttle says: “Run, but in a controlled way.” Perfect for: ✔ Scroll tracking ✔ Mouse movement ✔ Drag events ✔ Live UI updates Simple rule: Need the final result? → Debounce Need continuous controlled updates? → Throttle Performance optimization is not always about writing faster code. Sometimes it is simply about deciding when code should run. Small decision. Massive production impact. #JavaScript #ReactJS #Debounce #Throttle #FrontendDevelopment #PerformanceOptimization #WebDevelopment #SoftwareEngineering

I built a JS Minifier that does more than just remove whitespace. 🛠️⚡ Most online minifiers are "black boxes." You paste code, and you get a mess back. I wanted to build something that helps developers understand how their code is being transformed. The Engineering Details: AST Debugging : Built-in visualization using acorn to inspect the Abstract Syntax Tree. Zero UI Lag : Minification runs in a Web Worker, keeping the main thread free for a 60fps experience. Modern Compatibility: Fully supports ES2024+ syntax, powered by Terser. Smart State: Persistent configuration via localStorage and a responsive UI using react-resizable-panels. Mangle & Compress: Smart variable renaming and dead-code removal. The Results: In my tests, I'm consistently seeing 40-60% size reductions in milliseconds. #JavaScript #WebDev #Performance #Frontend #VibeCoding

Here's a refactor that improved TypeScript compile times, IDE responsiveness, and bundle size without changing a single line of product logic. Replacing wildcard barrel exports with explicit named re-exports. The setup most teams have: ``` // components/index.ts export * from './button'; export * from './input'; export * from './modal'; export * from './dropdown'; // ... 30 more ``` Convenient to write. Problematic at scale. Why export * hurts: 1. Tree shaking breaks. Bundlers eliminate dead code by statically analysing exports. export * makes this analysis ambiguous. The bundler must be conservative, often keeping code it could safely drop. 2. Circular dependencies hide. When everything re-exports everything, circular import chains become nearly invisible. They only surface as runtime errors or inexplicable behaviour. 3. TypeScript gets slower. The language server resolves more surface area on every save. In a large project, this is measurable. The fix: ``` // components/index.ts export { Button } from './button'; export { Input } from './input'; export { Modal } from './modal'; ``` Every export is a deliberate decision. Every import is statically traceable. Dead code is safely eliminable. This is unglamorous work. It ships in commits nobody applauds. But it makes every future feature cheaper to build. Do you use barrel files? Wildcard or explicit? #react #performance #web #frontend #optimisation

You’ve probably come across “JavaScript hoisting” before. Most of us were told that variables and functions get moved to the top of the scope. It sounds simple, so we just accept it and move on. But that explanation is not really accurate, and it is exactly why things like undefined and weird scope behavior end up feeling confusing later. Nothing actually gets moved. The engine sets up memory before execution, and that’s what creates the illusion of hoisting. If this is new to you, I’ve broken it down in a simple way in my blog here: https://lnkd.in/gxuyJxik

𝗝𝗮𝘃𝗮𝗦𝗰𝗿𝗶𝗽𝘁 𝗘𝘃𝗲𝗻𝘁 𝗟𝗼𝗼𝗽 𝗘𝘅𝗽𝗹𝗮𝗶𝗻𝗲𝗱 JS runs one thing at a time. This is single-threading. Long tasks freeze your screen. The event loop manages async code. It connects these parts: - Call stack: Where code runs. - Web APIs: Browser tools like timers. - Task queues: Where callbacks wait. The order is strict: - Call stack finishes first. - Microtasks run second. - Macrotasks run last. Example: 1. Start runs first. 2. setTimeout moves to the task queue. 3. Promise moves to the microtask queue. 4. End runs fourth. Result: Start, End, Promise, Timeout. A zero-millisecond timer does not run now. It waits for the stack to empty. It waits for microtasks to finish. This fixes weird bugs in your code. Source: https://lnkd.in/gjBYnFZB

Devs built SOAP, REST, GraphQL to structure how we ask machines questions. To render html. What happens when structure disappears? Browser: "Hello, send my settings in rich HTML." And the server with agents understands intent, not syntax. Quick render no development cost. I think I had a good thought to explore. Does anyone have any idea how to choose a stack for this to simply test out this?

Day 22 #100DaysOfCode 💻 1. Difference between map and filter? — B. map transforms, filter selects 2. What triggers this? (addEventListener) — B. Button click 3. What happens here? (onclick) — B. Runs on click 4. What is the output? (map without return) — B. [undefined, undefined, undefined] 5. Which is correct to get input value? — B. value 6. What is the output? (array.find) — B. 2 7. What does async/await simplify? — B. Callbacks 8. What is the output? (array.filter) — B. [3, 4] 9. Which is best for spacing between flex items? — B. gap 10. What does querySelector do? — B. First match 11. Layout direction (Tailwind flex-col md:flex-row) — B. Column on small, row on medium+ 12. Why does map return undefined? — B. Missing return 13. What does JSON.stringify() do? — A. Converts object to string 14. What does Array.push() do? — A. Adds element to the end 15. What is the use of the spread operator (...) ? — C. Copying or merging arrays/objects 16. How to save data in LocalStorage? — B. setItem('key', 'value') 17. Difference between const and let — A. const cannot be reassigned 18. == vs === — B. === checks both value and type 19. What is the output of typeof null? — C. "object" 20. What is Hoisting? — A. Moving declarations to the top 21. Why is useState used in React? — B. To manage component state 22. What does p-4 mean in Tailwind? — A. Padding on all sides 23. What does Array.reduce() do? — B. Accumulate values to a single result 24. Why use event.preventDefault()? — A. Stops default browser behavior 25. Which method does fetch() use by default? — A. GET 🚀 #javascript #reactjs #webdevelopment #frontenddeveloper #coding #learninginpublic #Akbiplob

jsbundling + Vite. Not one or the other... but, ABRACADABRA, BOTH! Introducing rails_vite: it drops Vite into your existing Propshaft pipeline with with instant HMR, code splitting, zero deploy changes. Read all about it in this article by Svyatoslav Kryukov: https://lnkd.in/gDC2UmnH

5 TypeScript shorthands to write cleaner, more compact code: 01 `const { url, level } = queue.shift()!;` `!` — The non-null assertion operator. `queue.shift()` returns `T | undefined`, so appending `!` tells the compiler the value is guaranteed to exist. 02 `const href = await anchors.nth(i).getAttribute('href');` `.nth(i)` — A Playwright locator method that selects the i-th matching element (here, an anchor) from a locator set. Zero-indexed, readable, and chainable. 03 `finalUrl && this.isInternalUrl(finalUrl, rootUrl) ? finalUrl : url;` `&&` requires both conditions to be true. `? :` picks between two outcomes. Together, they replace an entire if/else block in one line. 04 `return [...new Set(normalizedUrls.filter(Boolean))] as string[];` Three operations, one line: `filter(Boolean)` removes falsy values → `new Set()` deduplicates → `...` spreads back into an array. 05 `if (fileExtensions.some((ext) => target.pathname.endsWith(ext))) return false;` `.some()` + an arrow function checks whether any file extension matches the URL path — and bails early if so. A clean guard clause that replaces a verbose for loop. Have fun using these in your next project! 🚀

𝗧𝗲𝘀𝘁𝗶𝗻𝗴 𝗬𝗼𝘂𝗿 𝗙𝗿𝗼𝗻𝘁𝗲𝗻𝗱 𝗕𝗎𝗶𝗹𝗱 𝗪𝗶𝗍𝗵 𝗕𝗮𝗛𝗲𝗹 You want to improve your frontend build with Bazel. Here's how you can do it: - Run your tests with Bazel to get better caching and parallelism. - Use the `bazel test` command to run your tests. - Add tags to your tests to filter them. To get started, you need to update your `package.json` script to use `bazel test`. You can do this by replacing your old test script with `bazel test //packages/... --test_tag_filters=jest`. You also need to add a `test:coverage` script to generate an HTML coverage report. You can do this by running `bazel coverage :jest --config=html_coverage --strategy=TestRunner=local`. To aggregate your coverage reports, you can use `bazel coverage //packages/... --test_tag_filters=jest`. This will generate a combined LCOV file that you can use to generate an HTML report. Some benefits of using Bazel include: - Better caching and parallelism - Improved test filtering with tags - Simplified coverage aggregation You can learn more about Bazel and how to use it in your frontend build by checking out the following resources: - Bazel For a Frontend Monorepo - Aggregating Unit Test Coverage for All Monorepo's Packages - Auto-Publish Your Test Coverage Report on GitHub Pages Source: https://lnkd.in/gQcPNspY