Temporal API: A New Era for JavaScript Date Handling

I built a real-time currency converter in vanilla JavaScript and it actually talks to the internet. This one felt different. Projects 1 and 2 were self-contained all the data lived in the browser. This time my JavaScript sends a request to a real server, waits for a response, and displays live exchange rates. That moment when real data appeared on my screen for the first time? Genuinely exciting. Here's the problem I was solving: A friend invoices international clients and was Googling exchange rates from random sites with outdated numbers. One bad conversion cost them real money. So I built something cleaner. Here's what I learned building it: → async/await writing code that waits for things to happen → fetch() ending HTTP requests from the browser → try/catch/finally handling errors so the app never crashes → Working with a real REST API → JSON.parse and JSON.stringify for data handling → Building loading states so users know something is happening → Array methods unshift() and slice() This is project 3 of 5 I'm building in public as I grow my JavaScript skills. 🔗 Live demo: https://lnkd.in/dMgWQfmh 💻 GitHub: https://lnkd.in/dMMneYsY What was YOUR first API project? Drop it in the comments. #javascript #buildinpublic #webdevelopment #frontenddevelopment #API

using shadcn/ui and react-hook-form is the best stack in the react ecosystem but it has one massive flaw which is It is incredibly verbose. every single text input in every application likely looks like this: <FormField  control={form.control}  name="first_name"  render={({ field }) => (   <FormItem>    <FormLabel>First Name</FormLabel>    <FormControl>     <Input placeholder="Enter first name" {...field} />    </FormControl>    <FormMessage />   </FormItem>  )} /> That is 12 lines of code for one input. If a form has 10 fields, your component balloons to 150+ lines of pure boilerplate. so how did i solve this? simply i made several reusable form molecules with strict JSDoc comments. This will allow replacing those 12 lines with a single, highly readable line: <SharedTextField control={form.control} name="first_name" label="First Name" /> the idea is very simple but from my experience most developer are too lazy to do this kind of solutions thinking it won't make any real difference :)

𝗠𝗲𝗺𝗼𝗶𝘇𝗮𝘁𝗶𝗼𝗻 𝗶𝘀 𝗻𝗼𝘁 𝗮 "𝗳𝗿𝗲𝗲" 𝗽𝗲𝗿𝗳𝗼𝗿𝗺𝗮𝗻𝗰𝗲 𝘄𝗶𝗻. ⚡ It’s tempting to wrap every calculation in useMemo or every function in useCallback. But in a large-scale React application, this can backfire. 𝗧𝗵𝗲 𝗖𝗼𝘀𝘁 𝗼𝗳 "𝗢𝗽𝘁𝗶𝗺𝗶𝘇𝗮𝘁𝗶𝗼𝗻": Every time you use these hooks, you aren't just saving a calculation. You are: 1. 𝗜𝗻𝗰𝗿𝗲𝗮𝘀𝗶𝗻𝗴 𝗺𝗲𝗺𝗼𝗿𝘆 𝘂𝘀𝗮𝗴𝗲: React must store the previous value and the dependency array in memory. 2. 𝗔𝗱𝗱𝗶𝗻𝗴 𝗲𝘅𝗲𝗰𝘂𝘁𝗶𝗼𝗻 𝗼𝘃𝗲𝗿𝗵𝗲𝗮𝗱: On every render, React must run a shallow comparison on every dependency. If you are memoizing a simple .filter() on a 50-item list, the "optimization" overhead is often more expensive than the re-calculation itself. 𝗪𝗵𝗲𝗻 𝘁𝗵𝗲 𝘁𝗿𝗮𝗱𝗲-𝗼𝗳𝗳 𝗺𝗮𝗸𝗲𝘀 𝘀𝗲𝗻𝘀𝗲: ✅ 𝗛𝗲𝗮𝘃𝘆 𝗖𝗼𝗺𝗽𝘂𝘁𝗮𝘁𝗶𝗼𝗻: Expensive data processing (e.g., parsing large JSON or complex regex) that actually blocks the main thread. ✅ 𝗥𝗲𝗳𝗲𝗿𝗲𝗻𝘁𝗶𝗮𝗹 𝗜𝗻𝘁𝗲𝗴𝗿𝗶𝘁𝘆: When passing objects or functions to children wrapped in React.memo. Without it, the child re-renders on every parent update, defeating the purpose of React.memo. ✅ 𝗘𝗳𝗳𝗲𝗰𝘁 𝗦𝘁𝗮𝗯𝗶𝗹𝗶𝘁𝘆: When the value is a dependency in a useEffect that triggers an API call or a heavy subscription. 𝗧𝗵𝗲 𝗦𝘁𝗿𝗮𝘁𝗲𝗴𝘆: Don't guess—measure. I’ve started using the 𝗥𝗲𝗮𝗰𝘁 𝗣𝗿𝗼𝗳𝗶𝗹𝗲𝗿 to identify "Wasted Renders" before reaching for a hook. Often, the better fix isn't memoization, but 𝘀𝘁𝗮𝘁𝗲 𝗰𝗼𝗹𝗹𝗼𝗰𝗮𝘁𝗶𝗼𝗻 or 𝗺𝗼𝘃𝗶𝗻𝗴 𝘁𝗵𝗲 𝘀𝘁𝗮𝘁𝗲 𝗱𝗼𝘄𝗻 the component tree. 𝗜𝗻 𝘆𝗼𝘂𝗿 𝗰𝘂𝗿𝗿𝗲𝗻𝘁 𝘀𝘁𝗮𝗰𝗸, 𝗮𝗿𝗲 𝘆𝗼𝘂 𝘀𝗲𝗲𝗶𝗻𝗴 𝗺𝗼𝗿𝗲 𝗽𝗲𝗿𝗳𝗼𝗿𝗺𝗮𝗻𝗰𝗲 𝗴𝗮𝗶𝗻𝘀 𝗳𝗿𝗼𝗺 𝗺𝗲𝗺𝗼𝗶𝘇𝗮𝘁𝗶𝗼𝗻 𝗼𝗿 𝗳𝗿𝗼𝗺 𝗯𝗲𝘁𝘁𝗲𝗿 𝗰𝗼𝗺𝗽𝗼𝗻𝗲𝗻𝘁 𝗰𝗼𝗺𝗽𝗼𝘀𝗶𝘁𝗶𝗼𝗻? 👇 #ReactJS #WebPerformance #FrontendEngineering #JavaScript #ProgrammingTips #SoftwareDevelopment

🚀 The Event Loop: Browser vs. Node.js 🌐 Ever wondered how JavaScript stays "fast" despite being single-threaded? The secret sauce is the Event Loop. But depending on where your code runs, the Event Loop wears different hats. 🎩 Here is a quick breakdown of how it works on the Client-side vs. the Server-side: 🖥️ 1. JavaScript in the Browser (Client-Side) In the browser, the Event Loop is all about User Experience. The Goal: Keep the UI responsive. How it works: When a user clicks, scrolls, or fetches data, these actions are added to a task queue. The Flow: The Event Loop constantly checks if the Call Stack is empty. If it is, it pushes the next task from the queue to the stack. This ensures that heavy tasks don't "freeze" the screen while rendering. ⚙️ 2. Node.js (Server-Side) In Node.js, the Event Loop is the backbone of High-Concurrency servers. The Goal: Handle thousands of simultaneous requests without blocking. The Heavy Lifters: For "blocking" tasks like File System (FS) or Database operations, the Event Loop offloads the work to Worker Threads (via the Libuv library). The Callback Cycle: 1. The Event Loop registers a callback for an operation. 2. It hands the task to a worker thread. 3. Once the worker is done, it sends the result back to the queue. 4. The Event Loop picks it up and executes the final callback to send the response. 💡 The Bottom Line Whether you are building a snappy UI or a scalable backend, understanding the Event Loop is the difference between a laggy app and a high-performance system. #JavaScript #NodeJS #WebDevelopment #Programming #SoftwareEngineering #TechTips #react #express #next

I used to wonder: if JavaScript can only do one thing at a time, why doesn't the whole website stop whenever I'm waiting for a slow API? Today, I’m documenting the "Magic" behind the scenes: The Event Loop. Think of it as a traffic controller that keeps everything moving. Here is what I learned about how it works: The Call Stack: This is my "To-Do List." It finishes one task before moving to the next. 1) The Waiting Room (Web APIs): When I set a timer or fetch data, JavaScript sends it here so the main list stays free for other work. 2) The Callback Queue: This is where finished tasks wait in line for their turn. 3) The Event Loop: The star of the show. It waits until the Stack is empty, then pushes the next task from the line into the code. The "Senior Secret" I learned today: Never run massive calculations directly on the main thread. It blocks the loop and makes the website feel laggy or "dead." I'm not a master yet, but understanding this makes me much better at fixing bugs. Tomorrow, I'm looking at where we hide all our data: Browser Storage! Did the Event Loop ever confuse you? It definitely took me a few tries to finally "get it"! #CodeWithWajid #JavaScript #EventLoop #WebDevelopment #100DaysOfCode #LearningToCode #BuildingInPublic

These two hooks are widely misused — both overused and underused. useMemo — memoizes a computed value: ```js // Worth it: expensive computation on large dataset const sortedList = useMemo(() => largeArray.sort((a, b) => a.price - b.price), [largeArray] ); // Not worth it: simple operation const double = useMemo(() => count * 2, [count]); ``` useCallback — memoizes a function reference: ```js // Worth it: passed to a memoized child component const handleSubmit = useCallback(() => { submitForm(data); }, [data]); // Not worth it: not passed as a prop anywhere const handleClick = useCallback(() => setCount(c => c + 1), []); ``` The rule of thumb: → Don't add these by default → Profile first with React DevTools → Add memoization only where you measure a real impact Premature optimization adds complexity without benefit. #ReactJS #JavaScript #WebPerformance #Frontend

Debugging a real-world React code generated by Claude Code - React 19 Infinite Suspense Loop. Issue Summary: The observed behavior in the browser console aligns with a classic React 19 Infinite Suspense Looptriggered by an architectural mismatch between data fetching and component boundaries. Technical Breakdown:  The Child Component initiated data fetches via useXYZ(...) and immediately called use(...) to resolve them. This triggered React's <Suspense> architecture. However, the nearest <Suspense> boundary was located in a Parent Component. In React 19, when a component suspends and falls back to a parent, all local state and useXYZ(...) to cache generated in the child tree are destroyed. When the fallback completes, React attempts to mount the Child Component from scratch, creating new promises that immediately suspend again. This creates an infinite background loop of mounting, unmounting, and redundant API fetching. The "Heisenbug" Effect:  The delayed rendering upon opening the browser console was likely caused by a shift in the execution priority of the JavaScript engine's event loop. This micro-delay allowed a cached network response to resolve synchronously before React could abort the render, momentarily breaking the loop and allowing the UI to paint. The Resolution: The <Suspense> boundary was relocated from the Parent Component and placed directly inside the Child Component, specifically beneath the useXYZ(...) hooks. This ensures the component mounting the promises never unmounts during a suspension event. By retaining the cache intact, the component can now resolve its promises and render successfully on the initial pass. 𝘕𝘰𝘵𝘦: 𝘛𝘩𝘪𝘴 𝘪𝘴𝘴𝘶𝘦 𝘱𝘳𝘰𝘷𝘦𝘥 𝘤𝘩𝘢𝘭𝘭𝘦𝘯𝘨𝘪𝘯𝘨 𝘧𝘰𝘳 𝘊𝘭𝘢𝘶𝘥𝘦 𝘊𝘰𝘥𝘦, 𝘸𝘩𝘪𝘤𝘩 𝘶𝘯𝘥𝘦𝘳𝘸𝘦𝘯𝘵 𝘴𝘦𝘷𝘦𝘳𝘢𝘭 𝘩𝘰𝘶𝘳𝘴 𝘰𝘧 𝘵𝘳𝘰𝘶𝘣𝘭𝘦𝘴𝘩𝘰𝘰𝘵𝘪𝘯𝘨 𝘢𝘯𝘥 𝘴𝘪𝘨𝘯𝘪𝘧𝘪𝘤𝘢𝘯𝘵 𝘳𝘦𝘧𝘢𝘤𝘵𝘰𝘳𝘪𝘯𝘨 𝘸𝘪𝘵𝘩𝘰𝘶𝘵 𝘢 𝘴𝘶𝘤𝘤𝘦𝘴𝘴𝘧𝘶𝘭 𝘳𝘦𝘴𝘰𝘭𝘶𝘵𝘪𝘰𝘯. 𝘐𝘯 𝘤𝘰𝘯𝘵𝘳𝘢𝘴𝘵, 𝘎𝘦𝘮𝘪𝘯𝘪 3.1 𝘗𝘳𝘰 (𝘷𝘪𝘢 𝘈𝘯𝘵𝘪𝘨𝘳𝘢𝘷𝘪𝘵𝘺) 𝘪𝘥𝘦𝘯𝘵𝘪𝘧𝘪𝘦𝘥 𝘵𝘩𝘦 𝘳𝘰𝘰𝘵 𝘤𝘢𝘶𝘴𝘦 𝘢𝘯𝘥 𝘪𝘮𝘱𝘭𝘦𝘮𝘦𝘯𝘵𝘦𝘥 𝘵𝘩𝘦 𝘧𝘪𝘹 𝘰𝘯 𝘵𝘩𝘦 𝘧𝘪𝘳𝘴𝘵 𝘢𝘵𝘵𝘦𝘮𝘱𝘵. 𝘛𝘩𝘪𝘴 𝘴𝘦𝘳𝘷𝘦𝘴 𝘢𝘴 𝘢 𝘱𝘳𝘢𝘤𝘵𝘪𝘤𝘢𝘭 𝘳𝘦𝘮𝘪𝘯𝘥𝘦𝘳 𝘵𝘩𝘢𝘵 𝘦𝘷𝘦𝘯 𝘩𝘪𝘨𝘩𝘭𝘺 𝘤𝘢𝘱𝘢𝘣𝘭𝘦 𝘵𝘰𝘰𝘭𝘴 𝘩𝘢𝘷𝘦 𝘷𝘢𝘳𝘺𝘪𝘯𝘨 𝘴𝘵𝘳𝘦𝘯𝘨𝘵𝘩𝘴; 𝘴𝘸𝘪𝘵𝘤𝘩𝘪𝘯𝘨 𝘮𝘰𝘥𝘦𝘭𝘴 𝘤𝘢𝘯 𝘣𝘦 𝘢𝘯 𝘦𝘧𝘧𝘦𝘤𝘵𝘪𝘷𝘦 𝘴𝘵𝘳𝘢𝘵𝘦𝘨𝘺 𝘸𝘩𝘦𝘯 𝘢 𝘱𝘳𝘪𝘮𝘢𝘳𝘺 𝘢𝘴𝘴𝘪𝘴𝘵𝘢𝘯𝘵 𝘴𝘵𝘢𝘭𝘭𝘴.

𝗧𝗵𝗲 𝗚𝗹𝗼𝗯𝗮𝗹 𝗢𝗯𝗷𝗲𝗰𝘁 𝗶𝗻 𝗝𝗮 v𝗮𝗦𝗰𝗿𝗶𝗽𝘁 When you write code in Node.js, you use console and setTimeout without importing them. But have you wondered where they come from? Node.js creates a global object before your code runs. This object holds everything the runtime gives you for free. In the browser, this object is called window. In Node.js, it's called global. When Node.js starts, it creates a global object and provides it with every tool your code needs. You can use console.log and setTimeout without adding global every time. But what about this in Node.js? At the top of a Node.js file, this is not global. It's actually module.exports, which starts as an empty object. In a browser, this is window. In Node.js, this returns global when a function is called. For years, developers used global in Node.js and window in browsers. But this caused problems when building libraries that work in both environments. That's why ES2020 introduced globalThis, a standard way to access the global object in any JavaScript environment. globalThis works in Node.js, browsers, and Web Workers. You can use globalThis to access anything on the global scope. It's the recommended way to write code that might run outside of Node.js. So, when should you use global and when should you use globalThis? Use global when writing Node.js-specific code. Use globalThis when writing code that might run in a different environment. Remember, it's not recommended to put your own values on global. Instead, use imports and exports to keep your code organized and easy to maintain. Source: https://lnkd.in/gXmJEFRR

React is unidirectional. Data flows down. If you’ve spent any time in React, you know the drill, parents talk to children via props. It’s predictable, and it’s why the library scales. But it leads to the inevitable question, How does the child talk back? It’s not a "reverse prop" or some hidden magic. It’s actually a classic JavaScript pattern. While data flows down, functions are first-class citizens. To let a child communicate, the parent defines a "handler" function and passes it down as a prop. The child doesn't send data up in the traditional sense, it simply executes the function it was given. This is the essence of lifting state up. The parent keeps the "source of truth," and the child remains reusable, only triggering the parent’s logic when an event occurs. Of course, once you’re passing functions down five levels deep, you’re in prop drilling hell. That’s usually the signal to reach for the Context API or a state manager like Zustand to keep your components clean. Are you - context API purist? - prefer a dedicated state manager for handling these flows? #ReactJS #WebDevelopment #SoftwareEngineering #Frontend #Javascript

🚀 Practicing React by building a User Management System Recently, I’ve been practicing React by building a small project where I implemented: 1. Add User 2. Edit User 3. Delete User 4. Form validation using React Hook Form 5. Data persistence using localStorage While practicing, I ran into multiple bugs and learned a lot by debugging them 💥 Key Learnings: 🔹 State is asynchronous I was saving data to localStorage using old state, which resulted in empty arrays ([]). * Fixed it by saving the updated array instead of the old state. 🔹 Immutability matters While updating a user, I forgot to return inside .map() which broke the state. * Learned that state updates must always return a new array. 🔹 Avoid nested arrays I mistakenly did [users, newUser] instead of [...users, newUser] * This caused unexpected UI behavior. 🔹 Functional updates are safer Using: setUsers(prev => [...prev, newUser]) is more reliable than directly using state. 🔹 Attention to small details Even small mistakes like using a string instead of RegEx in validation can break logic. github : https://lnkd.in/gZNF6pxu #ReactJS #FrontendDevelopment #JavaScript #LearningInPublic #WebDevelopment