标签：#JavaScript

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing What I Built The Comfort Atlas is a spinning 3D globe of comfort food from ~100 countries. Virtually travel the globe and have a taste of the comfort foods from 100~ countries. Moussaka in Greece, Jollof Rice in Nigeria, Pho in Vietnam. There is also a "featured dish of the day" that rotates deterministically so it's the same for everyone visiting that day. And the fun feature: visitors can type in their own comfort dish and generate a downloadable, passport-stamp-style card in one of three color styles. Demo https://comfort-atlas.netlify.app/ Journey I started with a flat SVG world map, clickable countries, keyboard support, a hover tooltip on the map, all built on real elements so accessibility came for free. It worked fine, but it looked very meh. So i decided to try something i have never done before. Make a globe! I used cobe which promised a 3D globe out of the box. First attempt rendered absolutely nothing but floating dots. 😂 With a lot of the help of my friend claude, we found out that their docs are outdated, and there is not a createGlobe() draws exactly one synchronous frame and expects you to drive a requestAnimationFrame loop calling .update() yourself. Two things on the globe I'm especially proud of, because neither had any library support: a hover tooltip that tracks a marker in 3D space, and a fading "trail" of great-circle arcs between the countries you've visited. Both came down to translating the projection math out of a minified bundle into something readable, then reimplementing it myself. What I would do next: dark mode. What I learned: a lot about accessibility in 3D/canvas, which is so much more difficult than the 2d one, one check for a11y is never enough. Maps are hard, and getting something to track a moving 3D object from regular DOM is even harder. Licensed under MIT Fun fact: I don't like Moussaka, even though i am greek, my comfort food is Pizza. xD

Introduction React is fast, but that doesn't mean every React application is. One of the most common performance problems—especially in growing applications—is unnecessary re-rendering . A small project with a few components may feel instant, but as your application grows, unnecessary renders can cause sluggish interfaces, input lag, excessive CPU usage, and poor user experience. The good news is that unnecessary re-renders are usually preventable once you understand why React re-renders components . In this article, we'll explore how React rendering works, learn how to identify performance bottlenecks, and apply practical optimization techniques such as React.memo , useMemo , useCallback , better state management, and component architecture. Whether you're building dashboards, e-commerce stores, SaaS products, or portfolio websites, these techniques will help you write more efficient React applications. Table of Contents Understanding React Rendering What Causes Unnecessary Re-renders? Identifying Performance Problems Optimizing with React.memo Optimizing Expensive Calculations with useMemo Preventing Function Recreation with useCallback State Colocation Splitting Components Optimizing Context Rendering Large Lists Using the React Profiler Best Practices Common Mistakes Performance Tips Security Considerations Accessibility Considerations SEO Considerations Real Project Example Conclusion Discussion Background Before optimizing anything, it's important to understand what React actually does. A render simply means React executes your component function to determine what the UI should look like. That does not always mean the browser updates the DOM . React compares the new Virtual DOM with the previous one and only updates the parts that actually changed. However, if many components re-render unnecessarily, React still has to: Execute component functions Recreate objects Recreate arrays Recreate event handlers Compare Virtual DOM trees All of that work adds up. Step

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art. ...

GitHub热门项目 | A modern JavaScript utility library delivering modularity, performance, & extras. | Stars: 61,273 | 26 stars this week | 语言: JavaScript

GitHub热门项目 | Curated lessons on getting started building agents with Copilot Studio | Stars: 3,131 | 6 stars today | 语言: JavaScript

GitHub热门项目 | Git. Ship. Done - Core | Stars: 7,532 | 49 stars today | 语言: JavaScript

It's easy to test a site on office fibre, get a 95+ Lighthouse score, and call performance "done." Then someone in a secondary city mentions the site feels slow on their phone, and the gap between tested performance and real performance becomes obvious. This isn't a Pakistan-specific problem in theory, but it's an unusually common one in practice — a large share of real users here are on congested 3G or throttled 4G, on mid-range Android devices, often outside the main metros where infrastructure is best. If you're building for a Pakistani (or generally emerging-market) audience, "works great in the office" isn't the same as "works great for the actual user." Here's what actually moves the needle, beyond just plugging in a CDN. A CDN helps, but it doesn't fix the last mile A CDN gets your assets physically closer to the user, which helps. But if the connection between someone's phone and the nearest edge node is still a congested 3G link, the CDN's job is basically done — the bottleneck is the last mile, and no amount of edge-caching fixes that. What actually helps is reducing how much has to travel down that last mile in the first place. That reframes the whole problem: less about "getting bytes there faster" and more about "sending fewer bytes." 1. Image weight is usually the biggest offender Images are typically the single largest contributor to page weight, and the fix isn't exotic: // Next.js example — explicit width/height prevents layout shift, // and the Image component serves modern formats automatically import Image from " next/image " ; < Image src = "/hero.jpg" alt = "Product hero shot" width = { 1200 } height = { 630 } priority // only for above-the-fold images /> A few concrete habits that add up: Serve WebP/AVIF instead of raw JPEG/PNG where you can — usually 25-50% smaller at equivalent visual quality Always set explicit width / height (or use a framework component that does it for you) so the browser doesn't shift layout while images load — this als

Welcome back to the React Mastery Series . In Day 1, we introduced the roadmap of this series and discussed what we will cover — from React fundamentals to enterprise-level architecture. Today, we will start with the most important question: What is React, and why was it created? What is React? React is an open-source JavaScript library for building user interfaces , especially single-page applications (SPAs). It was created by engineers at Meta (Facebook) and was initially released in 2013. React focuses on one core idea: Build complex user interfaces by breaking them into small, reusable components. Instead of creating a complete application as one large piece of code, React encourages developers to divide the UI into independent and manageable components. Example: A banking application dashboard can be divided into: Dashboard │ ├── Header │ ├── AccountSummary │ ├── TransactionList │ ├── TransferMoneyForm │ └── Notifications Each part can be developed, tested, and maintained independently. Why Was React Created? Before React, developers commonly used traditional JavaScript and libraries like jQuery to update web pages. For small applications, this approach worked well. But as applications became larger, several challenges appeared. 1. Managing Complex UI Updates Imagine a banking application where: Account balance changes Transactions are updated Notifications appear User profile information changes With traditional DOM manipulation, developers had to manually find elements and update them. Example: document . getElementById ( " balance " ). innerHTML = " $5000 " ; As the application grew, managing thousands of DOM updates became difficult. React introduced a different approach: Describe what the UI should look like, and React manages the updates. The Problem With Direct DOM Manipulation The browser provides the Document Object Model (DOM), which represents the HTML structure. Example: HTML | DOM Tree | Browser Rendering When we update the DOM frequently: Browser

If you've ever tried to turn a modern web page into a PDF programmatically, you've probably hit the wall: the file comes out blank, half-empty, or frozen on a loading spinner. The page looks perfect in the browser, so what gives? The answer is timing. Most PDF approaches grab the HTML before the JavaScript has rendered the content. On a server-rendered page that's fine — the markup is already there. On a React/Vue/Angular app, the server sends an near-empty shell and the browser builds the DOM afterward. Capture too early and you save the shell. Here's how to do it properly. Why the naive approaches fail wkhtmltopdf is the classic Google answer. It's fast and it's been around forever, but it uses an ancient WebKit build with effectively no modern JavaScript support. For a static page it's fine. For anything client-rendered, it captures the empty state. Browser window.print() / Ctrl+P works because it is a real browser — but it's manual, single-page, and impossible to automate cleanly at scale. Hitting the raw HTML with an HTTP client (axios/fetch then pipe to a PDF lib) has the same fatal flaw as wkhtmltopdf : no JS execution, no rendered content. What you actually need is a real browser engine that runs the page's JavaScript, waits for it to settle, and then prints. That's Puppeteer. The Puppeteer approach Puppeteer drives a headless Chromium. It executes the page exactly like a normal Chrome tab, so whatever renders on screen is what you capture. const puppeteer = require ( ' puppeteer ' ); async function pageToPdf ( url , outPath ) { const browser = await puppeteer . launch ({ args : [ ' --no-sandbox ' , ' --disable-setuid-sandbox ' ], // needed in most containers }); const page = await browser . newPage (); await page . goto ( url , { waitUntil : ' networkidle0 ' , timeout : 60000 }); await page . pdf ({ path : outPath , format : ' A4 ' , printBackground : true , // otherwise CSS backgrounds/colors are dropped margin : { top : ' 20px ' , bottom : ' 20px ' , left

Many independent service businesses already use WhatsApp to confirm appointments. The missing piece is often a small, clear landing page that answers the obvious questions before the first message: what is offered, how much it costs, and what a visitor should do next. I built a dependency-free Spanish booking-page pattern around that handoff. The booking flow A useful booking page does not need a heavy scheduling stack to start doing its job. Its core flow can be simple: Show a small set of services with understandable prices and durations. Put a clear call to action on every relevant section. Open WhatsApp with enough context that the owner does not have to ask the same first question again. Keep the page fast and editable. The key implementation detail is generating the WhatsApp link from a service-specific message: const phone = " 56900000000 " ; document . querySelectorAll ( " .whatsapp-link " ). forEach (( link ) => { const message = link . dataset . message ; if ( message ) { link . href = `https://wa.me/ ${ phone } ?text= ${ encodeURIComponent ( message )} ` ; } }); That lets a CTA such as “Reserve a hair ritual” arrive as a message like “Hola, quiero reservar el Ritual de cabello.” It is a small interaction, but it removes friction for both the customer and the business. Design choices that help Mobile-first layout: appointment links are frequently opened from a phone. Visible prices and durations: clearer expectations usually mean better-quality enquiries. Short FAQs: rescheduling, location, and confirmation are common blockers. Semantic HTML: headings, buttons, and disclosure details work without a framework. No fake live contact details: the phone number, copy, price, and social links are clearly marked for replacement. Live demo You can inspect the working beauty-studio demo here: WhatsApp Booking Landing Kit — Interactive Demo Editable bundle I also made the complete editable source available as a paid digital kit. It now includes three standalone Spani

GitHub热门项目 | Self-hosted family planner - tasks, calendars, shopping, meals, budget. Your data, your server. | Stars: 1,205 | 25 stars today | 语言: JavaScript

Hello Dev Community! 👋 It is officially Day 166 of my full-stack engineering track! Today, I designed and implemented the active messaging canvas component ( ChatContainer.jsx ) for my messaging app, QuickChat ! 💬📷⚡ Focusing on dynamic chat alignment, text bubble rendering, image attachments, and input controls was today's core milestone. Here is how I structured the component. 🛠️ Technical Breakdown: ChatContainer & Attachment Pipeline As captured in my UI and VS Code setup ( Screenshots ): 1. Dynamic Alignment & Sender Detection Conditioned flexbox directions based on authentication state so sender messages lock to the right while recipient messages render on the left: javascript

If you've tried building a Chrome extension recently, you've probably hit Manifest V3 and spent an hour just figuring out why your background page stopped working. MV3 replaced background pages with service workers, changed how content scripts communicate, and made permissions stricter. The official docs are... not great. So here's the structure that actually works. The folder structure chrome-extension/ ├── manifest.json ├── popup/ │ ├── popup.html │ ├── popup.css │ └── popup.js ├── options/ │ ├── options.html │ └── options.js ├── content/ │ └── content.js ├── background/ │ └── service-worker.js ├── utils/ │ └── storage.js └── icons/ The manifest.json (MV3) The biggest MV3 gotcha: background scripts are now service workers. { "manifest_version": 3, "name": "Your Extension", "version": "1.0.0", "permissions": ["storage", "activeTab", "scripting"], "action": { "default_popup": "popup/popup.html" }, "background": { "service_worker": "background/service-worker.js" }, "content_scripts": [ { "matches": [""], "js": ["content/content.js"] } ] } Communicating between popup and content script This trips up almost everyone. The popup can't directly access the page DOM — it has to message the content script. // popup.js const [tab] = await chrome.tabs.query({ active: true, currentWindow: true }); await chrome.tabs.sendMessage(tab.id, { type: 'RUN_ACTION' }); // content.js chrome.runtime.onMessage.addListener((message, sender, sendResponse) => { if (message.type === 'RUN_ACTION') { // do something on the page sendResponse({ success: true }); } return true; // keeps the channel open for async response }); The return true at the end is critical — without it, async responses silently fail. Storage that syncs across devices Use chrome.storage.sync instead of localStorage. Here's a utility wrapper that makes it clean to use anywhere: const Storage = { async get(key) { return new Promise((resolve) => { chrome.storage.sync.get([key], (result) => resolve(result[key])); }); }, async set

--- title : " Perfect Landing — Soul & Spoon (Comfort Food Edition) — Research Summary" published : false tags : [ " frontend" , " html" , " css" , " javascript" , " accessibility" , " performance" , " react" , " svelte" ] cover_image : " https://images.unsplash.com/photo-1543353071-087092ec393a?q=80&w=1600&auto=format&fit=crop&ixlib=rb-4.0.3&s=3" canonical_url : " " series : " " --- Perfect Landing — Soul & Spoon Research Summary A concise, ready-to-paste DEV post that summarizes the research, design decisions, technical choices, and next steps for the Soul & Spoon landing-page project — a warm, accessible, performance-minded single-page site celebrating soul food. What I Built Soul & Spoon — Comfort Food Landing Page is a single-page landing site that showcases soul-food plates with a polished, modern frontend. The static prototype includes: Hero with a full-bleed background and clear CTAs. Featured dishes section with responsive cards and descriptive copy. Gallery of soul-food plates with a keyboard-accessible lightbox. Contact form with client-side validation and toast feedback. Responsive, accessible, and performant implementation using semantic HTML, picture / srcset /WebP, lazy loading, and minimal JavaScript. Research Summary and Rationale Design goals Evoke warmth and comfort through color, rounded shapes, and soft shadows. Prioritize readability and hierarchy for quick scanning on mobile and desktop. Keep interactions simple and predictable: smooth scroll, accessible modal, and unobtrusive toast notifications. Accessibility findings Semantic elements ( header , main , section , figure , figcaption , footer ) improve screen-reader navigation and SEO. Keyboard operability is essential: gallery images must be focusable and open via Enter/Space; Escape should close the lightbox. ARIA attributes ( aria-hidden , aria-expanded , role="dialog" ) plus focus management significantly improve modal usability. Performance findings Images dominate page weight; srcset an

GitHub热门项目 | Auto-complete every Discord Quest in seconds. Paste one script, get all rewards. Resilient module loader, auto-claim, adaptive speed. No installs, no tokens, no dependencies. | Stars: 344 | 14 stars today | 语言: JavaScript

GitHub热门项目 | Low-code programming for event-driven applications | Stars: 23,474 | 4 stars today | 语言: JavaScript

GitHub热门项目 | State-of-the-art Machine Learning for the web. Run 🤗 Transformers directly in your browser, with no need for a server! | Stars: 16,221 | 1 star today | 语言: JavaScript

GitHub热门项目 | My blog website. | Stars: 302 | 37 stars today | 语言: JavaScript

TL;DR Hello everyone! It's been a while since I've posted a list of interesting projects,...

JavaScript vs React: Understanding How They Work Together If you're starting web development, you've probably heard about JavaScript and React. Many beginners think they are competitors, but they actually work together. Let's understand them in simple terms. What is JavaScript? JavaScript is a programming language used to make websites interactive. Without JavaScript, a website would mostly be static. JavaScript allows you to: Handle button clicks Validate forms Create animations Fetch data from APIs Update content without refreshing the page Example: document . getElementById ( " btn " ). addEventListener ( " click " , () => { alert ( " Hello World! " ); }); JavaScript is the foundation of modern web development. What is React? React is a JavaScript library created by Meta Platforms for building user interfaces. Instead of manipulating the webpage manually, React helps developers create reusable UI components. Example: function Welcome () { return < h1 > Hello World! </ h1 >; } React uses JavaScript to create dynamic and interactive user interfaces more efficiently. Simple Analogy Think of building a house: JavaScript = The tools and materials (bricks, cement, wood) React = A construction framework that helps you build the house faster and more efficiently You need JavaScript to use React. Key Differences Feature JavaScript React Type Programming Language JavaScript Library Purpose Adds logic and interactivity Builds UI components Learning Curve Easier to start Requires JavaScript knowledge Usage Works everywhere Used mainly for frontend applications Created By Netscape Meta (Facebook) DOM Updates Manual Virtual DOM for optimized updates Why React Became Popular As applications grew larger, managing UI with plain JavaScript became difficult. React solves this by providing: Component-based architecture Reusable code Better state management Faster UI updates with Virtual DOM Large ecosystem and community support This makes React ideal for building modern applications