JavaScript Fundamentals and React Basics

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 are your 37 topics organized by section: Execution, Scope & Memory 1. Execution context & call stack 2. var, let, const (scope + hoisting + TDZ) 3. Lexical scope & scope chain 4. Closures (behavior, not definition) 5. Shadowing & illegal shadowing 6. Garbage collection basics & memory leaks Functions & this 7. Function declarations vs expressions 8. this binding rules (default, implicit, explicit, new) 9. call, apply, bind 10. Arrow functions vs normal functions 11. Currying & partial application 12. Higher-order functions Async JavaScript 13. Event loop (call stack, microtasks, task queue) 14. Promises & chaining 15. async / await (error handling & sequencing) 16. Race conditions & stale closures 17. Timers (setTimeout, setInterval) vs microtasks 18. Promise utilities (all, allSettled, race, any) Data, References & ES6+ 19. == vs ===, truthy / falsy & type coercion deep dive 20. Object & array reference behavior 21. Deep vs shallow copy 22. Destructuring, rest & spread 23. Map, Set, WeakMap, WeakSet Prototypes & OOP 24. Prototype chain & Object.create() 25. class syntax vs prototype under the hood 26. Inheritance patterns Error Handling 27. try/catch with async/await edge cases 28. Custom error types 29. Unhandled promise rejections Modules 30. ES Modules (import/export) vs CommonJS (require) 31. Tree shaking concept 32. Dynamic imports — import() Iterators & Generators 33. Symbol.iterator & iterable protocol 34. Generator functions (function*) 35. Connecting generators to RxJS mental model Browser & Runtime Fundamentals 36. Event bubbling, capturing, delegation, preventDefault vs stopPropagation 37. DOM vs Virtual DOM, Reflow vs repaint, Web storage, Polyfills #angular #javascript #html #css #webdeveloper #angularDeveloper

Most developers know map, filter and reduce exist. Fewer know when to use which one. Here is how I think about it: map() — when you need to transform every element Same number of items in, same number out. Just different shape. filter() — when you need to remove some elements Same data, fewer items. Nothing is transformed. reduce() — when you need one value from the whole array Total, average, grouped object, flat list — anything single. The real power comes from chaining them: devs  .filter(d => d.active)  .map(d => d.name)  .sort() Three operations. One clean chain. No loops. No temporary variables. And the ones people forget: find() — returns one element, not an array some() — true if at least one matches every() — true only if all match flatMap() — map + flatten in one step Save this for your next code review. Which array method do you reach for most often? #JavaScript #WebDevelopment #Frontend #CleanCode #SoftwareEngineering

There's always something to gain from going back to the fundamentals. Between client projects and building out systems, I've been carving out time to sharpen my JavaScript. Recently covered: → Primitive vs Reference Data Types → Number, Null, Undefined, BigInt, and Symbols → The typeof operator → Ternary operators → Introduction to Object Destructuring None of this is glamorous. But the designers and developers who write clean, predictable code are almost always the ones who took the fundamentals seriously. Still a few more concepts on the list. Sharing the progress as I go. #JavaScript #WebDevelopment #Webflow #LearningInPublic

Built a Blog Manager using Vanilla JavaScript with multiple real-world features. This project includes CRUD functionality (create, edit, delete), localStorage for data persistence, markdown support for rich content, image rendering, and a tag system with real-time filtering. Also focused on clean modular architecture by separating data, UI, and logic. JASIQ Labs Live Demo: https://lnkd.in/g7vf9_AD GitHub: https://lnkd.in/gsaV5BPB Working on this helped me understand how frontend applications are structured and managed without using frameworks. #javascript #frontend #webdevelopment #learning

Today was one of those days where things finally clicked While working on one of my ongoing projects, I built a VS Code–like File Explorer from scratch in React — and it turned out to be a great learning experience. Here’s what I explored 🔹 Built a recursive tree structure to handle nested folders & files 🔹 Understood how recursion actually works in real UI problems 🔹 Implemented core features: → Create file / folder → Delete (with full nested structure) → Dynamic rendering 🔹 Learned an important pattern: 🔹filter + map + recursion = tree operations 🔹 Got deeper clarity on handling nested data: → Managing deeply nested state → Updating tree efficiently → Thinking recursively instead of flat logic Biggest takeaway: If you truly understand recursion, you can solve complex UI problems much more cleanly. Building real features inside projects hits very different than just watching tutorials #React #FrontendDevelopment #WebDevelopment #LearningInPublic #JavaScript #BuildInPublic

In 2026, the "React Hack" is simply Suspense + the use hook. ### 💻 The Code Shift: function UserProfile({ id }) {  const [user, setUser] = useState(null);  const [loading, setLoading] = useState(true);  useEffect(() => {   fetchUser(id).then(data => {    setUser(data);    setLoading(false);   });  }, [id]);  if (loading) return <Spinner />;  return <div>{user.name}</div>; } The 2026 "Clean" Way: // No state, no effect, no manual loading checks. function UserProfile({ userPromise }) {  const user = use(userPromise);   return <div>{user.name}</div>; } // Wrapped in a Parent <Suspense fallback={<Spinner />}>  <UserProfile userPromise={fetchUser(id)} /> </Suspense> Why this is a win: Readable Logic: The component only cares about the UI, not the lifecycle of the fetch. Streaming: The server starts sending HTML to the browser before the data is even finished loading. Less Bugs: No more "race conditions" where the wrong data shows up because an old fetch finished late. The best code is the code you don't have to write. Are you still a useEffect purist, or have you moved your data fetching to the server? Let's talk architecture below. 👇 #ReactJS #CleanCode #WebDevelopment #JavaScript #SoftwareEngineering #Frontend

You’re still building forms manually from JSON? --- Every time I get a JSON response, I end up doing the same thing: → read structure → map fields → wire inputs → repeat… again --- It’s boring. It’s repetitive. And it shouldn’t exist in 2026. --- So I built something for myself: 👉 Paste JSON 👉 Get a working form instantly --- No setup. No backend. No config headaches. Just: JSON → UI --- Introducing: 🔧 JSON → Form (part of useSignal) 👉 https://lnkd.in/grSx-SEi --- It’s fully browser-native. Which means: - your data never leaves your machine - everything runs instantly - no dependency on any service --- This isn’t just a generator. It’s a way to: → skip repetitive UI work → prototype faster → actually focus on logic --- Try it once. You probably won’t go back to building forms manually. --- 💬 Curious — how are you handling JSON → forms today? #frontend #webdevelopment #javascript #reactjs #devtools #buildinpublic #productivity #developers #webdev

Custom hooks can make your codebase harder to debug. Not easier. Here’s why 👇 We often extract logic into hooks: → useUsers → useAuth → useDashboard Sounds clean. But over time: ✖ Logic becomes hidden ✖ Data flow becomes indirect ✖ Debugging requires jumping files Now imagine debugging: → Component → Hook → Another Hook → API You lose context. What I’ve learned: ✔ Not everything should be a hook ✔ Keep critical logic visible ✔ Avoid over-abstraction Use hooks for: → Reusability with clarity Avoid hooks for: → Hiding complexity Key insight: Abstraction reduces duplication. But increases cognitive load. Balance matters. #ReactJS #CustomHooks #Frontend #SoftwareEngineering #Architecture #JavaScript #CleanCode #AdvancedReact #Engineering #Programming

💡Don't Use Array Spread Operator In Every Case💡 Yes, you heard that right. If you have a very large data set, then using array spread operator to create a new array will slow down your application and you might receive, "Maximum call stack size exceeded" error. So instead of using array spread operator, use array concat method. const largeArray = [/* your large array */]; const newArray = [/* additional items */]; // Using spread operator (slow for large arrays) const combinedArray1 = [...largeArray, ...newArray]; // Using concat method (more efficient for large arrays) const combinedArray2 = largeArray.concat(newArray); So If you have a very large array, then avoid using spread operator, instead use array concat method. This is because spread operator creates a new array which means each spread operator like …arr1, …arr2 will create a new array and then iterates and then returns a new array. For example, with const result = […arr1, …arr2], javascript will create three arrays one for the result and one for each spread operator (and then iterates it) If we use the same for concat method then there would be one array creation which is result meaning the concat method directly iterates the array. 𝗙𝗼𝗿 𝗺𝗼𝗿𝗲 𝘀𝘂𝗰𝗵 𝘂𝘀𝗲𝗳𝘂𝗹 𝗰𝗼𝗻𝘁𝗲𝗻𝘁, 𝗱𝗼𝗻'𝘁 𝗳𝗼𝗿𝗴𝗲𝘁 𝘁𝗼 𝗳𝗼𝗹𝗹𝗼𝘄 𝗺𝗲. #javascript #reactjs #typescript #webdevelopment