DEV Community: Royal Jain

Build component library using Storybook

Royal Jain — Thu, 04 Apr 2024 21:26:08 +0000

Storybook is an open-source tool for UI development that allows developers to build and organise UI components in isolation. It serves as a "workshop" environment where you can see how components look and behave in various states without needing to embed them in your application's main UI. This makes it easier to develop, test, and document components. Why should you use it?

Isolation: Develop components in isolation, which means that changes in one component won’t affect others. Which means that to see how components look and behave in various states, we don't need to embed them and navigate to that particular user journey. Look at storybook for popular video sdk, Agora. You can see each component and the states / controls it provides.

You can see their entire storybook here

Documentation: Generate documentation automatically, making it easier to share how components should be used. Often other developers are unaware of pre-existing components and end up creating their own version, which becomes a maintenance challenge.

Interactive Playground: Provides an interactive UI to play with component properties (knobs).

Visual Testing: Supports visual regression testing to catch visual bugs. Often visual regressions are hard to test with traditional e2e testing, visual testing helps in removing the manual inspection

Getting Started with Storybook

To start using Storybook, you typically integrate it into a project that's already set up with a UI framework like React, Vue, or Angular. Here’s how you can set it up in a React project:

Install Storybook:

If you have a React project set up, you can add Storybook by running the following command in your project directory:

 npx sb init

Run Storybook:

After installation, you can start the Storybook server with:

npm run storybook

This command will start the Storybook environment on a local server, typically accessible at http://localhost:6006.

Create a Story:

Stories in Storybook are JavaScript modules that define how to render a component. You write stories to display each state of your UI components. Here’s an example of a story for a simple Button component in a React project:

 // Button.stories.js
 import React from 'react';
 import { Button } from './Button';

 export default {
   title: 'Button',
   component: Button,
 };

 export const Primary = () => <Button primary>Click me</Button>;
 export const Secondary = () => <Button>Click me</Button>;

In this code title defines the name of the component group in the Storybook UI. Component is the actual component being documented. Primary and Secondary are variations of the Button component, known as "stories".

View Your Components in Storybook:

Once Storybook is running, you can navigate to its web interface where you will see the stories defined in your project. You can click on each story to view the rendered component and interact with it.

Documentation using Storybook

Storybook uses a feature called DocsPage to automatically generate documentation from your stories and code comments. Additionally, you can enhance documentation with Markdown or MDX (Markdown with JSX) to write narrative documentation.

Here’s how you can document your components in Storybook:

Set Up Documentation

Ensure that @storybook/addon-docs is installed and configured in your Storybook setup. This addon is often included by default when you initialize Storybook in your project. It parses your component and its comments to generate documentation.

Write Component Comments

Use JSDoc style comments in your component code to document props, states, and any other relevant information. Storybook's Docs addon can then automatically generate documentation from these comments.

For example:

// Button.js

/**
 * Primary UI component for user interaction.
 *
 * @param {Object} props - Props for button
 * @param {string} props.label - The text that the button will display
 * @param {function} props.onClick - The callback function to call on button click
 * @param {boolean} [props.disabled=false] - Whether the button is disabled
 */
const Button = ({ label, onClick, disabled = false }) => (
    <button disabled={disabled} onClick={onClick}>
        {label}
    </button>
);

export default Button;

Create Stories with Args In your stories, define args for your component to show different states and prop configurations. Storybook will use these args to render controls and actions in the DocsPage.

// Button.stories.js
import React from 'react';
import Button from './Button';

export default {
  title: 'Components/Button',
  component: Button,
};

const Template = (args) => <Button {...args} />;

export const Primary = Template.bind({});
Primary.args = {
  label: 'Click Me',
  disabled: false,
  onClick: () => alert('Clicked!'),
};

Enhance with MDX For more detailed documentation, you can use MDX. Create an MDX file where you can mix Markdown text with live Storybook previews.

// Button.stories.mdx
import { Meta, Story, ArgsTable, Canvas } from '@storybook/addon-docs';
import Button from './Button';

<Meta title="Components/Button" component={Button} />

# Button Component

The Button component is used for user interactions.

## Props

<ArgsTable of={Button} />

## Usage

<Canvas>
  <Story name="Primary" args={{ label: 'Hello', disabled: false }}>
    {Template}
  </Story>
</Canvas>

In this MDX file, Meta sets the component metadata, ArgsTable generates a table of the component's props, and Canvas and Story are used to render live previews.

Run and Review

Run Storybook to see your documentation in action. Navigate to your component in the Storybook UI, and you should see the generated DocsPage with your component’s documentation, including the interactive props table and live examples.

Documentation makes it easier for developers to understand and use your component library effectively.

Storybook offers a robust platform for building, documenting, and testing UI components in isolation. By integrating Storybook into your development workflow, you can create a well-structured, easily navigable, and thoroughly documented component library. This not only speeds up the development process but also ensures a consistent design and user experience across your projects.

Core Web Vitals: Rank your websites higher on SEO

Royal Jain — Thu, 28 Mar 2024 07:30:56 +0000

Google's Web Vitals initiative, aims to provide quality metrics essential to delivering a great user experience on the web. A website that performs well on these metrics generally offers a smooth experience for users, which can lead to longer visit durations, higher levels of engagement, and increased conversions.

Google incorporates these vitals in its search engine ranking to ensure websites with better experience rank higher. There are many signals but three most important, also known as Core Web Vitals are:

Largest Contentful Paint (LCP):Measures the loading performance of a webpage. Specifically, it marks the point in the page load timeline when the largest text or image content has been rendered. A good LCP time is considered to be 2.5 seconds or faster.

First Input Delay (FID): Measures the interactivity and responsiveness of a webpage. It captures the time from when a user first interacts with a page (e.g., clicking a link, tapping on a button) to the time when the browser is actually able to respond to that interaction. A good FID time is less than 100 milliseconds.

Cumulative Layout Shift (CLS): Measures the visual stability of a webpage. It quantifies the amount of unexpected layout shift of visible page content. A low CLS score indicates that the page is stable and content does not shift in a way that can be disorienting for users. A good CLS score is less than 0.1.

We'll look at each in detail now

Largest Contentful Paint

Largest Contentful Paint (LCP) is a metric that measures the loading performance of a webpage, specifically the time it takes for the largest content element visible in the viewport to fully load and be ready for user interaction. It's a critical factor in determining the perceived speed of a website.

Examples

Image-heavy Website: On a photography website, the LCP might be the time it takes for the largest photograph on the homepage to load. If this photograph is very large in file size, it can significantly delay the LCP.
Text-heavy Blog: On a blog, the LCP might be the largest block of text visible to the user when the page first loads. If this text is part of a large article or includes heavy fonts, it can impact the LCP.
E-commerce Site: For an e-commerce site, the LCP could be the main hero image or a large product image on the homepage. The faster this image loads, the quicker the user perceives the page as usable.

Best Practices

Optimize Images: Compress images without losing quality to reduce their file size. Use modern, efficient image formats like WebP. Ensure images are responsive and load different sizes based on the user's device to save bandwidth.
Prioritize Loading of Important Assets: Use resource hints such as preload to inform the browser about critical resources that need to be loaded first. This can ensure that the largest content element is loaded quickly.
Remove Unnecessary Third-Party Scripts: Third-party scripts can slow down your site. Evaluate and keep only essential third-party resources, or defer the loading of non-critical scripts until after the main content has loaded.
Use a Content Delivery Network (CDN): A CDN can serve your content from a server location closer to the user, reducing the time it takes for the largest contentful element to load.

First Input Delay (FID)

First Input Delay (FID) is a performance metric that measures the time from when a user first interacts with a page (like clicking a link, tapping a button, or using a custom, JavaScript-powered control) to the time when the browser is actually able to begin processing event handlers in response to that interaction.

Examples

Button Click: When a user clicks a button to submit a form, FID measures the time from the user's click to the browser's response to that click. If there's a delay in processing the click because the main thread is busy, the FID will be high.
Navigation: When a user selects a new page from a navigation menu, FID measures the delay before the browser starts loading the new page. If the browser is busy executing heavy JavaScript, the user might experience a noticeable delay.
Interacting with a JavaScript-driven element: For example, expanding a dropdown menu or interacting with a slider on a webpage. If the JavaScript is complex and the browser is busy, there could be a delay in expanding the dropdown or moving the slider, leading to a higher FID.

Best Practices

Minimize JavaScript Execution Time: Break up long tasks into smaller, asynchronous tasks to reduce the time the main thread is blocked, allowing it to respond more quickly to user inputs.
Optimize Page Load: Ensure that the critical path resources are loaded first and defer non-critical resources. This allows the browser to become interactive more quickly.
Use Web Workers: Move non-UI operations to a web worker to run them in a background thread, keeping the main thread free to respond to user input.
Avoid Large JavaScript Bundles: Splitting JavaScript bundles into smaller chunks ensures that only the necessary code is parsed and compiled on the page the user is interacting with, reducing the load on the main thread.
Prioritize Interactive Elements: Ensure that interactive elements like buttons or input fields are interactive early in the page load process, so users can interact with them without delay.

Cumulative Layout Shift (CLS)

Cumulative Layout Shift (CLS) is a metric that measures the visual stability of a website. It quantifies how much the content on the page shifts unexpectedly during the loading phase. High CLS values indicate that elements on the page are moving around a lot as the page loads, which can lead to a poor user experience.

How CLS is Measured

CLS is calculated by multiplying the impact fraction (the area of the viewport that shifts) by the distance fraction (the distance that the unstable elements move). This calculation is done for each unexpected layout shift that occurs throughout the entire lifespan of the page, and the individual scores are summed to get the final CLS score.

Examples of Layout Shifts

Images without dimensions: If an image loads without predefined width and height attributes, it can push content down or to the side once it loads, causing a layout shift.
Ads, embeds, and iframes without dimensions: Similar to images, these elements can load at different times and change the size of the space they occupy, shifting content unexpectedly.
Dynamically injected content: Content added to the page dynamically, like a newsletter sign-up banner or an alert message, can push other content down or to the side.
Web Fonts causing FOIT/FOUC: Flash of Invisible Text (FOIT) or Flash of Unstyled Content (FOUC) can occur when custom fonts load after the rest of the content, causing a shift.

Best Practices for Reducing CLS

Specify size attributes for images and videos: Always include width and height attributes for media elements to ensure the browser can allocate the correct amount of space while the media is loading.
Ensure ad elements have a reserved space: Predefine the size of ad slots so that when they load, they do not cause content to shift.
Avoid inserting new content above existing content: Be cautious about dynamically injecting content, especially if it affects the current layout significantly.
Use CSS aspect ratio boxes: For elements that don’t have an intrinsic size, use the aspect ratio property in CSS to reserve space based on the ratio of the width and height.
Preload fonts: Use font-display: swap or preload your fonts to avoid FOIT/FOUC, which can cause layout shifts when the font finally loads.

You can use https://pagespeed.web.dev/ to check and improve the web vitals of your website.

Cookies in Depth using Javascript and NodeJs

Royal Jain — Fri, 22 Mar 2024 08:13:02 +0000

What are Cookies?

Cookies are small pieces of data stored on a user's web browser. They are used to remember stateful information (such as items added in the shopping cart in an online store) or to record the user's browsing activity (like recording which pages were visited in the past). There are different types of cookies:

Session cookies: Temporary cookies that expire once you close your browser. They are used to track user activity during a single session like e-com websites use session cookies to track users' shopping cart items as they browse different pages of the site.

Persistent cookies: These remain on your device for a set period specified in the cookie. They are used to remember your preferences like news websites use persistent cookies to store preferred language, region, or layout settings.

Third-party cookies: Placed by a website other than the one you are currently visiting, these are often used for advertising and tracking across multiple websites. Ever searched for Ipad on Amazon and started seeing ads on other websites? That's third party cookies

Why are Cookies Useful?

Session management: They help manage user sessions, allowing websites to recognize users and their preferences as they navigate through the site. This includes keeping users logged in, tracking their progress through a site, and storing items in a shopping cart.
Personalization: Cookies store user preferences and settings to customize the user experience on a website. This can include language settings, themes, and other personalization details.
Tracking and analytics: Websites use cookies to gather data about user behavior, such as the pages visited, time spent on the site, and interaction with content. This information helps website owners understand how users interact with their site, allowing for improvements and more targeted content or advertisements.
Advertising: Cookies are used to deliver targeted advertisements to users based on their browsing history and preferences. They help advertisers show relevant ads to users and track the performance of ad campaigns.

Implementing Cookies

Cookies can be implemented on both client and server side.

Client Side (Javascript)

Creating Cookie: To create a cookie, you assign a string to document.cookie that contains the cookie name, value, and optionally other attributes like expiration, path, domain, secure, and SameSite. For example:

document.cookie = "username=JohnDoe; expires=Thu, 31 Dec 2029 23:59:59 GMT; path=/";

This line creates a cookie named username with the value JohnDoe that expires on December 31, 2029, and is accessible to all pages within the domain.

Reading Cookie: To read cookies, you access the document.cookie property, which returns all cookies for the current domain as a string. You then need to parse this string to find the value of the specific cookie you are interested in. For example:

var cookieValue = document.cookie
  .split('; ')
  .find(row => row.startsWith('username='))
  ?.split('=')[1];

This code snippet finds the username cookie and retrieves its value.

Server Side (Node.js)

Setup: In your project, create a file named server.js (or another name of your choice) and install basic Express server, along with cookie-parser library to handle cookies easily

npm install express cookie-parser

Then, you can use it in your Express application to read and set cookies.


// Import the required modules
const express = require('express');
const cookieParser = require('cookie-parser');

// Initialize the express application
const app = express();

// Use the cookie-parser middleware
app.use(cookieParser());

// Route to set a cookie
app.get('/set-cookie', (req, res) => {
    // Set a cookie named 'user' with a value of 'John Doe'
    res.cookie('user', 'John Doe', { maxAge: 900000, httpOnly: true });
    res.send('Cookie has been set');
});

// Route to get the cookie value
app.get('/get-cookie', (req, res) => {
    // Access the cookie named 'user'
    let userCookie = req.cookies.user;
    if (userCookie) {
        res.send(`Cookie value: ${userCookie}`);
    } else {
        res.send('No cookie found');
    }
});

// Start the server
const PORT = 3000;
app.listen(PORT, () => {
    console.log(`Server is running on http://localhost:${PORT}`);
});

In this example:

The /set-cookie route sets a cookie named user with the value John Doe.
The /get-cookie route reads the value of the user cookie and sends it in the response.
The cookie-parser middleware is used to parse the cookies attached to the client request object.

Run your server using the command node server.js, and then visit http://localhost:3000/set-cookie in your browser to set the cookie, and http://localhost:3000/get-cookie to retrieve and display the cookie value.

Cookies vs Local Storage

Cookies and local storage are both used to store data on the client's side in web applications, but they serve different purposes and have different characteristics:

Storage Size: Local storage can hold more data compared to cookies.

Lifespan: Cookies can be set to expire; local storage data stays until it is cleared.

Server Interaction: Cookies are sent with every request to the server, whereas local storage data stays on the client-side.

Scope: Cookies are accessible by both client and server; local storage is strictly client-side.

In summary, cookies are better suited for smaller amounts of data that need to be sent to the server with each request, while local storage is more appropriate for storing larger amounts of data that don’t need to be sent to the server and should persist beyond the session.

Be Careful

When maintaining cookies, there are several important points to consider to ensure security, privacy, and a good user experience:

Security:

-- Use the Secure attribute to ensure cookies are sent over HTTPS, protecting them from being intercepted during transmission.

-- Set the HttpOnly attribute to prevent client-side scripts from accessing the cookie, reducing the risk of cross-site scripting (XSS) attacks.

-- Consider using the SameSite attribute to control how cookies are sent with cross-site requests, which can help prevent cross-site request forgery (CSRF) attacks.

Privacy and Compliance:

-- Privacy laws and regulations, such as the General Data Protection Regulation (GDPR) in the EU, require obtaining consent from users before storing cookies that track information.

-- Offer users the ability to choose which cookies they want to allow (e.g., essential, analytics, marketing) and provide an easy way to change their preferences.

Expiration and Management:

-- Set an appropriate expiration date for cookies. Session cookies expire when the browser is closed, while persistent cookies last until their expiration date.

-- Regularly review and clean up unused or old cookies to avoid unnecessary data retention and potential security risks.

Domain and Path Attributes:

-- Specify the Domain and Path attributes correctly to control which domains and paths in your site can access the cookies, preventing them from being sent to or accessed by unintended parts of your site or application.

Data Sensitivity and Storage:

-- Avoid storing sensitive information (such as passwords, personal identification information, or credit card numbers) directly in cookies due to the risk of interception or unauthorized access.

-- Consider encrypting cookie values to protect the data they contain, especially if they are used for authentication or session management.

Performance:

-- Be mindful of the size and number of cookies used, as each cookie is sent with every HTTP request to the domain, which can affect performance, especially on mobile networks.

Cross-Site Tracking:

-- Be cautious with third-party cookies, as they can be used for tracking user behavior across different sites. Their use is increasingly being restricted by browser privacy features and regulations.

Getting started with PWAs

Royal Jain — Fri, 08 Mar 2024 08:52:14 +0000

A progressive web app (PWA) is an app that's built using web platform technologies, but that provides a user experience like that of a platform-specific app. Some popular PWAs are Starbucks, BMW

Try installing them by opening Browser Menu > Save and Share > Install

How does it work

PWAs are powered by the underlying browser engine (like Chrome, Safari, Firefox, etc.). It opens in a standalone mode that looks and feels like a native app. This mode doesn't show the browser's address bar, navigation buttons, or other interface elements associated with traditional web pages. The browser engine helps in

Rendering Web Content: This includes parsing HTML, applying CSS styles and laying out the web page.
Executing JavaScript: PWAs heavily rely on JavaScript for their interactive and dynamic features. The browser engine provides the JavaScript engine (e.g., V8 in Chrome, SpiderMonkey in Firefox) that executes the JavaScript code, enabling the dynamic functionalities of PWAs like responding to user interactions, making network requests, and manipulating the DOM.
API Access: Modern web browser engines provide a variety of APIs that enable web pages to access device features and perform more complex operations. These include service workers for offline support and background sync, Web App Manifest for installing the web app on the home screen, and other web APIs for accessing device hardware (like camera, GPS, etc.). PWAs utilize these APIs to offer a more app-like experience.

Native apps vs PWAs

So, should you build a native app or go with PWA? Here are some points to consider

Development: Native Apps are developed specifically for a particular platform (iOS, Android, Web) using platform-specific languages and tools. They require different codebases for different platforms. PWAs are Developed using standard web technologies (HTML, CSS, JavaScript). They are platform-independent and can run on any device with a compatible web browser, using a single codebase.
Distribution: Native Apps are distributed through app stores (Apple App Store, Google Play Store). They need to meet specific store guidelines and undergo a review process. PWAs are accessed through the web and do not require app store submission. They can be shared and installed directly from a website.
Performance: Native Apps, generally offer the best performance and smoothest user experience, as they can directly access device hardware and APIs. PWAs performance is improving but they are typically less performant than native apps. They also have more limitations compared to native apps for access to device APIs and features (camera, GPS, accelerometer, push notifications, etc.). Examples where PWAs won't be a good choice

Fitness tracking app

A native fitness tracking app can access a wide range of device features and sensors to offer an in-depth fitness tracking experience. It can use the GPS to track running routes accurately, the accelerometer to count steps, and even the heart rate sensor (on devices that have one) to monitor the user's heart rate in real time. Additionally, it can send push notifications to remind the user to exercise or drink water. A PWA for fitness tracking can also access certain device features through modern web APIs. It can use the Geolocation API to track running routes (though it may be less precise than a native app), and the Motion Sensors API to count steps. However, its access to hardware-specific features like a heart rate sensor is typically limited compared to native apps. While PWAs can send push notifications, their capabilities might be restricted on certain platforms, especially iOS.

Mobile Games

A native game app, especially one with high-definition graphics and complex physics simulations, is designed to leverage the device's hardware to its fullest. Native development allows the app to optimize performance by using the device's GPU (Graphics Processing Unit) and multi-core processors efficiently. A PWA game might not match the performance level of a native app, particularly for resource-intensive games. This is because they still operate within the constraints of the browser, which can limit access to the full computational power of the device. PWAs might exhibit longer load times or reduced frame rates during complex animations and gameplay compared to their native counterparts.

Building your first PWA

Set Up the Basic Web Application

First, you need to create a basic web application using HTML, CSS, and JavaScript. This is the foundation of your PWA and should be designed responsively to ensure that it works well on a variety of devices and screen sizes.

Create a Web App Manifest

The web app manifest is a JSON file that contains metadata about your app. This includes information like the name of the app, icons, and the start URL. The manifest allows your web app to be installed on the home screen of a device, similar to a native app. Here's an example of a basic manifest file:

{
  "short_name": "App",
  "name": "Example Application",
  "icons": [
    {
      "src": "icon/lowres.webp",
      "sizes": "48x48",
      "type": "image/webp"
    },
    {
      "src": "icon/hd_hi.ico",
      "sizes": "72x72 96x96 128x128 256x256",
      "type": "image/x-icon"
    }
  ],
  "start_url": "/",
  "background_color": "#FFFFFF",
  "display": "standalone",
  "scope": "/",
  "theme_color": "#000000"
}

Include this file in the root of your web application and link to it in the

section of your HTML:

<link rel="manifest" href="/manifest.json">

Implement a Service Worker

Service workers are at the heart of PWAs, enabling capabilities like offline support and resource caching. A service worker is a JavaScript file that operates as a type of network proxy between your app and the internet, allowing you to intercept and manage network requests.

Create a service worker file (e.g., sw.js) and include logic for caching resources and handling offline requests. Then, register the service worker from your main JavaScript file:

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/sw.js').then(function(registration) {
    console.log('Service Worker registered with scope:', registration.scope);
  }).catch(function(err) {
    console.log('Service Worker registration failed:', err);
  });
}

Ensure responsiveness, cross-Browser Compatibility and add offline Functionality by using the service worker to cache important resources (HTML, CSS, JavaScript files, images).

Adding PWAs to mobile

Users can add a Progressive Web App (PWA) to their mobile device, making it accessible like a native app from their home screen. The process varies slightly between different devices and browsers

Android Devices Using Chrome:

When a user visits a PWA with Chrome, they might see a prompt at the bottom of the screen asking if they want to "Add [App Name] to Home screen."

If the prompt doesn't appear, the user can tap the menu button (three dots in the upper right corner) and then tap "Add to Home screen."

They can then choose a name for the shortcut and confirm the action. The PWA will appear as an icon on their home screen.

iOS Devices Using Safari:

When visiting a PWA, tap the Share button at the bottom of the Safari window (the rectangle with an arrow pointing upward).
Scroll down and tap "Add to Home Screen."

Enter a name for the shortcut and then tap "Add." The PWA will now appear as an icon on the home screen.

Conclusion

PWAs are a powerful tool to build native apps like experience at lower cost. But whether it's the right choice depends on your use case and familiarity with web technologies

Firebase vs Supabase

Royal Jain — Wed, 06 Mar 2024 06:35:54 +0000

Supabase and Firebase are two of the most popular backend-as-a-service platforms to build and scale applications. Both are comprehensive products and provide realtime databases, file storage, authentication, client SDKs with good developer experience. However, there are some major differences -

Complex Queries:

Supabase uses PostgreSQL, an open-source object-relational database system that supports complex queries. Firebase offers two types of databases: Realtime Database (a NoSQL cloud database) and Cloud Firestore (an advanced NoSQL cloud database). They are optimised for performance at scale but don't support as complex querying as PostgreSQL.

Example SQL Query (Supabase/PostgreSQL)

Imagine you have two tables, orders and products, and you want to find the total amount spent on each product by each customer, along with product details, but only for those customers who have spent more than a certain amount on products in a specific category. Here's how you might write this query in SupaBase:


SELECT
    customers.name AS customer_name,
    products.name AS product_name,
    SUM(orders.quantity * products.price) AS total_spent
FROM
    orders
JOIN
    customers ON orders.customer_id = customers.id
JOIN
    products ON orders.product_id = products.id
WHERE
    products.category = 'Electronics'
GROUP BY
    customers.name, products.name
HAVING
    SUM(orders.quantity * products.price) > 500;

In Firebase, particularly in Firestore (Firebase's advanced database), queries are more limited:

No JOIN Operations: Firebase does not support traditional SQL-like JOIN operations. Instead, you would need to perform separate queries for each collection and then manually combine the data in your application code.
No Complex Aggregations: Firestore does not support complex aggregations like SUM, AVG, or HAVING clauses natively.

Functions (Serverless)

Firebase has Cloud Functions, which allow you to run backend code while Supabase does not have a native, integrated serverless function platform but can integrate with third-party services like AWS Lambda or Azure Functions.

Analytics

Supabase does not have a built-in analytics solution but can be integrated with third-party analytics tools. Firebase provides app analytics with detailed event reporting and user demographics like

User Engagement: Track how users engage with your app, including session length, app opens (active users), and frequency of use.
Demographics: Understand the demographic makeup of your users, such as age, gender, interests, and location.
Device Information: See what types of devices and operating systems your users are using, including device models, operating system versions, and screen sizes.
User Behavior: Track how users navigate through your app and which features they use. You can log custom events to track specific actions within your app, such as adding items to a cart, completing purchases, or achieving game levels.
Funnel Analysis: Analyze how users are completing a series of steps in your app (a funnel), such as the steps from adding an item to a cart to completing a purchase.

Pricing Model

Supabase provides tiered subscription models with limits going from Free, Pro (25$ / month) to Team (599$ / month) while Firebase charges basis number of reads, writes, storage etc

Reliability & Ecosystem:

Firebase offers a range of prebuilt extensions that integrate with other Firebase and Google Cloud services. It benefits from a large ecosystem due to its maturity and Google backing. Which means file storage is more scalable, client libraries are more comprehensive, has in-built app analytics and is far more battle tested. While Supabase doesn't have some of these in-built functionality but can be extended with PostgreSQL extensions, community plugins, and third-party services.

Conclusion

As always, the choice depends on your requirements

Choose Supabase when:

You Prefer SQL Databases: If you or your team are more comfortable with SQL databases or If your application requires complex data relationships or advanced database features, Supabase’s PostgreSQL backend offers more flexibility.
Open-Source Solutions are a Priority: If using open-source software is important for your project's philosophy, compliance, or cost considerations, Supabase, being an open-source alternative, would align well with your needs.
Self-Hosting is Required: If you need or prefer to host your backend infrastructure on your own servers or a private cloud for reasons such as data sovereignty, compliance, or cost, Supabase provides an option for self-hosting.

Choose Firebase when:

Rapid Development and Deployment: If your primary goal is to prototype and deploy quickly, Firebase offers a more comprehensive set of integrated services (like hosting, storage, real-time databases, and cloud functions) that can speed up development.
You Prefer NoSQL Databases: If your application’s data structure is more suited to a NoSQL database, or you prefer the scalability and flexibility that comes with NoSQL, Firebase’s Firestore and Realtime Database are robust options.
You Need Real-time Data Syncing: For applications that require real-time data updates, such as chat apps or live-updating dashboards, Firebase provides more mature and integrated real-time syncing capabilities.
You Want Seamless Integration with Google Services: If you are heavily invested in Google Cloud Platform or plan to leverage other Google services, Firebase integrates seamlessly with Google's ecosystem, providing an advantage in terms of connectivity and data movement.
You Require Advanced Analytics and Machine Learning Integration: Firebase offers powerful analytics solutions integrated with Google Analytics, and easy integration with machine learning services, which can be a deciding factor for data-driven applications.
Automatic Scaling is a Must: If you anticipate variable or growing traffic and want a backend that scales automatically without much configuration, Firebase provides a highly scalable infrastructure with minimal maintenance.

What the Hell is Closure in JavaScript?

Royal Jain — Tue, 27 Feb 2024 13:24:01 +0000

You might have heard the term "closure" tossed around in JavaScript conversations and tutorials, but what the hell is it really?

What is a Closure?

In the simplest terms, a closure is a function that remembers the variables from the place where it was defined, regardless of where it is executed later. Let's break it down with an example:


function outerFunction() {
    let outerVariable = 'I am outside!';

    function innerFunction() {
        console.log(outerVariable);
    }

    return innerFunction;
}

const myInnerFunction = outerFunction();
myInnerFunction(); // Outputs: 'I am outside!'

In this example, innerFunction is a closure. Why? Because it is a function defined within another function (outerFunction) and it has access to the variables of the outerFunction scope (in this case, outerVariable) even after outerFunction has finished executing.

When outerFunction gets called, it defines outerVariable, defines innerFunction, and then returns innerFunction. Even though outerFunction has completed execution and outerVariable would theoretically be out of scope and garbage collected, innerFunction still has access to outerVariable.

Why are Closures Useful?

Data Encapsulation:

You can use closures to create private variables and methods. This can be particularly useful in the modular design of your code.

function createCounter() {
    let count = 0;
    return {
        increment: function() {
            count++;
            return count;
        },
        decrement: function() {
            count--;
            return count;
        },
    };
}

const counter = createCounter();
console.log(counter.increment()); // 1
console.log(counter.increment()); // 2
console.log(counter.decrement()); // 1

In this example, count acts as a private variable. It's accessible only to the increment and decrement functions but not from the outside world.

Maintaining State

In JavaScript, closures are often used to maintain state in asynchronous operations, event handlers, and more.

function setupAlertTimeout() {
    var message = 'Message after 3 seconds';
    setTimeout(function alertMessage() {
        alert(message);
    }, 3000);
}

setupAlertTimeout();

Here, the alertMessage function maintains access to the message variable even after setupAlertTimeout has finished executing.

Currying

Closures allow the use of currying, which is a technique of evaluating functions with multiple arguments into sequences of functions with a single argument.


function multiply(a) {
    return function(b) {
        return a * b;
    };
}

const multiplyByTwo = multiply(2);
console.log(multiplyByTwo(4)); // 8

In this case, multiplyByTwo is a closure that remembers the value of a (which is 2).

Try it out

Consider the following code snippet:

function outer() {
    var count = 0;
    return function inner() {
        count++;
        return count;
    };
}
var counter1 = outer();
var counter2 = outer();
console.log(counter1());
console.log(counter1());
console.log(counter2());
console.log(counter2());

What will be the output of the above code and why?

Solution

In the provided code, two separate closures are created by calling outer() twice. Each closure maintains its own separate lexical environment, where the count variable is preserved between calls. Here's what happens step by step:

var counter1 = outer(); creates the first closure. Inside this closure, count is initialized to 0.
counter1() is called for the first time. This increments count to 1 inside the first closure and returns 1.
counter1() is called again. This increments count to 2 inside the first closure and returns 2.
var counter2 = outer(); creates the second closure. Inside this closure, a new, separate count is initialized to 0.
counter2() is called for the first time. This increments the count in the second closure to 1 and returns 1.
counter2() is called again. This increments the count in the second closure to 2 and returns 2. Therefore, the output of the code will be:

A real world example

function showDelayedMessage(message, delay) {
    setTimeout(function() {
        console.log(message);
    }, delay);
}

showDelayedMessage('Hello after 3 seconds', 3000);
showDelayedMessage('Hello after 5 seconds', 5000);

Writing a function like showDelayedMessage without leveraging closures would typically involve using global variables


var globalMessage; // Declare a global variable

function showDelayedMessageGlobal(message, delay) {
    globalMessage = message; // Assign the message to the global variable
    setTimeout(function() {
        console.log(globalMessage);
        globalMessage = null; // Clear the message after displaying it
    }, delay);
}

showDelayedMessageGlobal('Hello after 3 seconds', 3000);

This examples illustrate that while you can avoid closures, doing so often leads to less desirable coding practices, such as global namespace pollution, especially when dealing with asynchronous events or encapsulating functionality. Closures provide a clean and effective way to encapsulate data with functions, which is why they are so widely used despite the alternative approaches available.

How not to do CSS

Royal Jain — Tue, 20 Feb 2024 11:25:19 +0000

There are several common pitfalls that developers fall into when writing CSS, leading to bloated, hard-to-maintain codebases, and suboptimal user experiences. We'll explore the top ways not to do CSS -

Overusing !important

css
Copy code
.button {
  color: blue !important;
}

.button-important {
  color: red !important;
}

The !important rule in CSS is used to make a particular property and value the most important among conflicting rules. The !important declaration overrides any other styling rules, making it difficult to debug and maintain CSS. It leads to a specificity war where the only way to override a style is by using another !important, leading to a messy, hard-to-manage stylesheet.

Excessive Use of IDs for Styling


#header {
  background: #f1f1f1;
}

#footer {
  color: #333;
}

IDs are highly specific and should be used sparingly for styling purposes. Overuse of IDs in CSS makes it hard to reuse styles and can lead to specificity issues, where styles cannot be easily overridden by class selectors.

Not Using Shorthand Properties

.margin-example {
  margin-top: 10px;
  margin-right: 20px;
  margin-bottom: 10px;
  margin-left: 20px;
}

CSS offers shorthand properties to make your stylesheets more concise and easier to read. Not using shorthand properties, as seen above, can lead to unnecessarily verbose code. This could be simplified to:

.margin-example {
  margin: 10px 20px;
}

Using Inline Styles Excessively

<div style="background-color: #000; color: #fff; padding: 20px;">Content here</div>

Inline styles mix content with presentation, making it hard to separate concerns and maintain styles. They also have a high specificity, overriding external stylesheets and leading to inconsistency and duplication.

Not Using Responsive Units

.container {
  width: 960px;
}

Using fixed units like pixels (px) for layout dimensions can make your site unresponsive. It's essential to use relative units like percentages (%) or viewport units (vw, vh) for layouts to ensure your site is accessible and looks good on all devices.

Over-nesting in Preprocessors

.nav {
  ul {
    li {
      a {
        color: blue;
      }
    }
  }
}

While CSS preprocessors like SASS can enhance productivity, over-nesting selectors leads to overly specific CSS rules, making it hard to override styles and leading to bloated CSS files.

Css can be simultaneously be the easiest and the hardest language to learn. Some good practices go a long way in maintainability .

Understanding `this` keyword in javascript

Royal Jain — Sat, 10 Feb 2024 04:48:48 +0000

The this keyword in JavaScript is a reference to the object that is currently executing or invoking the current method or function. It is a context-specific keyword, meaning its value changes depending on where and how it is used within your code.

Let's see how this behaves in different contexts:

Global Context

When used outside of any function, this refers to the global object. In a browser environment, the global object is window,

console.log(this === window); // true in a browser environment

whereas in Node.js, it's called global.


// Define a global variable
global.myGlobalVar = 'Hello, global!';

// Use a built-in global function
setTimeout(() => {
  console.log(myGlobalVar); // Access the global variable without using 'global.' prefix
}, 1000);

// Access a global object property: process
console.log('Current version of Node.js:', process.version);

Function Context

In a regular function call, this refers to the global object (non-strict mode) or is undefined (strict mode).

function myFunction() {
  console.log(this);
}
myFunction(); // logs global object (window in browsers) or undefined in strict mode


/*node.js*/
function testFunction() {
  return this === global;
}

console.log(testFunction()); // true

Inside a method (a function inside an object), this refers to the object the method was called on.


const myObject = {
  myMethod() {
    console.log(this);
  }
};
myObject.myMethod(); // logs myObject

Arrow Functions

Arrow functions do not have their own this. Instead, they inherit this from the surrounding (lexical) context. This makes arrow functions particularly useful when you want to ensure that this within a function refers to the surrounding object.


const myObject = {
  myMethod: () => {
    console.log(this);
  }
};
myObject.myMethod(); // logs global object or undefined in strict mode, because arrow functions do not bind their own this

Event Handlers

In the context of DOM event handlers, this refers to the element that received the event, unless an arrow function is used or the function is bound to a different context.


document.getElementById('myButton').addEventListener('click', function() {
  console.log(this); // refers to the element that was clicked
});

Using call(), apply(), and bind() Methods:

JavaScript provides these methods to explicitly set the value of this for any function call. call() and apply() invoke the function immediately with a specified this value, while bind() returns a new function with this bound to a specific object.


function greet() {
  console.log(`Hello, ${this.name}`);
}

const person = { name: 'John' };
greet.call(person); // Hello, John

function greet() {
  console.log(this.message);
}

const friendlyGreet = {
  message: 'Hello, friend!'
};

const strangerGreet = {
  message: 'Hello, stranger.'
};

// Using bind() to create a new function where `this` is set to friendlyGreet
const greetFriend = greet.bind(friendlyGreet);
greetFriend(); // Outputs: Hello, friend!

// Similarly, binding greet to strangerGreet
const greetStranger = greet.bind(strangerGreet);
greetStranger(); // Outputs: Hello, stranger.

Understanding this can be tricky but is important, especially when dealing with object-oriented programming concepts, event handling, and functional programming patterns.

Now, if you understood this well. What do you think will be the output here?

var length = 10;
function fn() {
    console.log(this.length);
}

var obj = {
  length: 5,
  method: function(fn) {
    fn();
    arguments[0]();
  }
};

obj.method(fn, 1);

Why I won't use Next.js anymore 😡

Royal Jain — Tue, 06 Feb 2024 05:32:36 +0000

Warning: Rant ahead.

When NextJs first became popular, it was a remarkably easy way to build full stack application and soon became the my default choice. But after using it for years, I have decided to move away from it.

Problems

It has become too complex

Over time NextJs has introduced tons of complexity, with latest one being Server Actions. Learning curve is much higher now and going through NextJs documentation has become a herculean task. USP of simplicity is gone.

Too many breaking changes

Page router to app router has created so many problems. Like API level configs don't work anymore and now we need to learn about Server Actions to achieve this.

Customisation

Any use case which differs from what NextJs creators intended to do is simply painful. NextJs has decided that API requests can have 1Mb request body, I have an API which uses request body of > 1 Mb (passing a base64 image), achieving that has no good alternative.

Page router has some config options but app router doesn't or they are not documented. The only way to achieve it is either create a custom server (What's the point of NextJs then) or learn about Server Actions, which may or may not provide a solution.

At this point, you start wondering what was the problem with the simple express server.

My Conclusion

Any highly opinionated framework should be simple to work with, nobody wants something which is restrictive and needs a high learning curve. The only use cases someone should consider using NextJs is

Extreme need for Server Side Rendering
Hobby project with known and simple scope

How Google Drive handles HUGE File Uploads 🔥🔥

Royal Jain — Fri, 02 Feb 2024 12:22:40 +0000

Uploading large files in a browser can be challenging due to various limitations like browser timeout, server upload limit, or unstable network conditions.

One common approach is to split the file into smaller chunks and upload these chunks sequentially or in parallel. This method, known as "chunked upload", also provides better error handling, pause/resume capabilities, and progress tracking.

Here's a simple example how you can implement it:

Client Side Code

Split the File into Chunks - You can use the Blob.slice() method to split the file into manageable chunks.
Implement Chunk Upload Function - For each chunk, you'll need to send an HTTP request to the server. You can use the XMLHttpRequest object or the fetch API for this purpose.
Implement the Finalise Function - To signal the server that file upload is now complete


// Function to finalize the upload and start file reassembly
async function finalizeUpload(fileName, totalChunks) {
  const data = { fileName, totalChunks };
  const response = await fetch('YOUR_FINALIZE_ENDPOINT', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
    },
    body: JSON.stringify(data),
  });

  if (response.ok) {
    console.log('File reassembled successfully on server.');
  } else {
    console.error('Failed to finalize the upload:', await response.text());
  }
}


// Helper function to split file into chunks
function sliceFile(file, chunkSize) {
  let chunks = [];
  for (let start = 0; start < file.size; start += chunkSize) {
    const end = Math.min(start + chunkSize, file.size);
    chunks.push(file.slice(start, end));
  }
  return chunks;
}

// Function to upload a single chunk
async function uploadChunk(chunk, index) {
  const formData = new FormData();
  formData.append('fileChunk', chunk);
  formData.append('chunkIndex', index);

  // Update this URL to your upload endpoint
  const uploadUrl = 'YOUR_UPLOAD_ENDPOINT';

  try {
    const response = await fetch(uploadUrl, {
      method: 'POST',
      body: formData,
    });
    return response.ok;
  } catch (error) {
    console.error('Upload failed for chunk ' + index, error);
    throw error; // Rethrow so we can catch it later
  }
}

// Main function to handle the file upload
async function uploadFile(file) {
  const CHUNK_SIZE = 5 * 1024 * 1024; // 5MB chunk size
  const chunks = sliceFile(file, CHUNK_SIZE);
  for (let index = 0; index < chunks.length; index++) {
    try {
      await uploadChunk(chunks[index], index, progress => updateProgress(index, progress));
      console.log(`Chunk ${index + 1} of ${chunks.length} uploaded successfully`);
    } catch (error) {
      console.error(`Error uploading chunk ${index + 1}:`, error);
      return; // Exit the upload process on error
    }
  }

  console.log('All chunks uploaded successfully');
  // Call finalizeUpload after all chunks are uploaded
  await finalizeUpload(file.name, chunks.length);
}

Server Side Code

/upload - For uploading each file chunk. It temporarily stores each chunk with a unique name combining the original file name and the chunk index.
/finalize - For finalizing the upload. It reassembles the file by sequentially reading and merging each chunk, then deletes the chunks to free up space.

const express = require('express');
const multer  = require('multer');
const fs = require('fs');
const path = require('path');

const app = express();
const upload = multer({ dest: 'uploads/' }); // Temporary upload directory
const PORT = process.env.PORT || 3000;

// Endpoint to upload chunks
app.post('/upload', upload.single('fileChunk'), (req, res) => {
  const { chunkIndex, fileName } = req.body;
  const tempPath = req.file.path;
  const targetPath = path.join(__dirname, 'uploads', fileName + '.' + chunkIndex);

  // Move and rename the chunk for easier reassembly
  fs.rename(tempPath, targetPath, err => {
    if (err) {
      return res.status(500).send(err.message);
    }
    res.send('Chunk uploaded successfully');
  });
});

// Endpoint to finalize the upload and reassemble the file
app.post('/finalize', (req, res) => {
  const { fileName, totalChunks } = req.body;
  const targetPath = path.join(__dirname, 'uploads', fileName);

  // Create a write stream to assemble the file
  const fileWriteStream = fs.createWriteStream(targetPath);

  (async () => {
    for (let i = 0; i < totalChunks; i++) {
      const chunkPath = path.join(__dirname, 'uploads', fileName + '.' + i);

      await new Promise((resolve, reject) => {
        const readStream = fs.createReadStream(chunkPath);
        readStream.pipe(fileWriteStream, { end: false });
        readStream.on('end', () => {
          fs.unlink(chunkPath, (err) => { // Delete chunk after merging
            if (err) reject(err);
            else resolve();
          });
        });
        readStream.on('error', (err) => reject(err));
      });
    }
    fileWriteStream.end();
  })().then(() => {
    res.send('File reassembled successfully');
  }).catch(err => {
    res.status(500).send(err.message);
  });
});

app.listen(PORT, () => {
  console.log(`Server running on port ${PORT}`);
});

Bonus: Progress, Pause Functionality

Pause / Resume - The global isPaused flag controls the upload flow. The upload process checks this flag before uploading each chunk. If paused, it waits until the flag is cleared to resume uploading.
Progress Tracking - The uploadChunk function uses XMLHttpRequest to monitor the progress of each chunk upload. The onProgress callback is called with the chunk's progress, which can be used to calculate and display the overall progress.

let isPaused = false; // Global flag to control pause/resume

// Function to upload a single chunk with progress callback
async function uploadChunk(chunk, index, onProgress) {
  return new Promise((resolve, reject) => {
    const xhr = new XMLHttpRequest();
    xhr.open('POST', 'YOUR_UPLOAD_ENDPOINT', true);

    xhr.upload.onprogress = function(event) {
      if (event.lengthComputable) {
        const progress = (event.loaded / event.total) * 100;
        onProgress(index, progress);
      }
    };

    xhr.onload = function() {
      if (xhr.status === 200) {
        resolve(true);
      } else {
        reject('Upload failed: ' + xhr.statusText);
      }
    };

    xhr.onerror = function() {
      reject('XMLHttpRequest error: ' + xhr.statusText);
    };

    const formData = new FormData();
    formData.append('fileChunk', chunk);
    formData.append('chunkIndex', index);
    xhr.send(formData);
  });
}

// Main function to handle the file upload with pause/resume and progress tracking
async function uploadFile(file, onOverallProgress, onPauseResume) {
  const CHUNK_SIZE = 5 * 1024 * 1024; // 5MB chunk size
  const chunks = sliceFile(file, CHUNK_SIZE);
  let uploadedBytes = 0;

  // Function to update overall progress
  const updateProgress = (index, progress) => {
    uploadedBytes += progress;
    const overallProgress = uploadedBytes / file.size * 100;
    onOverallProgress(overallProgress);
  };

  for (let index = 0; index < chunks.length; index++) {
    if (isPaused) {
      await new Promise(resolve => {
        const interval = setInterval(() => {
          if (!isPaused) {
            clearInterval(interval);
            resolve();
          }
        }, 100); // Check every 100ms
      });
    }

    try {
      await uploadChunk(chunks[index], index, progress => updateProgress(index, progress));
      console.log(`Chunk ${index + 1} of ${chunks.length} uploaded successfully`);
    } catch (error) {
      console.error(`Error uploading chunk ${index + 1}:`, error);
      return; // Exit the upload process on error
    }
  }

  console.log('All chunks uploaded successfully');
  // Notify the server all chunks are uploaded, or handle the finalization process
}

// Example usage
// uploadFile(file, (progress) => console.log(`Overall Progress: ${progress}%`),
//             (paused) => console.log(paused ? 'Upload paused' : 'Upload resumed'));

// Functions to control pause/resume
function pauseUpload() {
  isPaused = true;
}

function resumeUpload() {
  isPaused = false;
}

Google Drive is lot more complex, as it needs to handle performance optimisations, security considerations and much more, but this is a good start for rest of us

Correct way to upload File(s)

Royal Jain — Wed, 31 Jan 2024 11:05:01 +0000

When uploading files in web development, there are generally two common methods: using FormData and directly through the request body. Each method has its own characteristics and use cases.

Uploading via FormData

Method: FormData is a way to encode data as a set of key-value pairs. When you use FormData to upload files, it is typically used in combination with multipart/form-data encoding type. This is the standard way to upload files in HTML forms.

// HTML form with input type 'file'
// <input type="file" id="fileInput">

const fileInput = document.getElementById('fileInput');

fileInput.addEventListener('change', function(event) {
    const file = event.target.files[0];
    const formData = new FormData();
    formData.append('file', file);

    fetch('/upload', {
        method: 'POST',
        body: formData
        // Note: no need to explicitly set the Content-Type header here
    })
    .then(response => response.json())
    .then(data => console.log(data))
    .catch(error => console.error(error));
});

Use Case: It is ideal for uploading files along with other form fields, such as text input, checkboxes, etc.

Compatibility: Widely supported by most browsers and can be used with XMLHttpRequest (XHR) and the newer Fetch API.

Advantages:

Can handle multiple types of data (files, text, binary data).
Easy to append additional fields and compatible with traditional form-based web applications.
Generally, no need to manually set headers as they are automatically set, which includes setting the Content-Type to multipart/form-data and the correct boundary.

Disadvantages:

Slightly more overhead due to the multipart encoding.

Uploading via Request Body

Method: Directly sending the file data in the body of an HTTP request. Here, you can set the Content-Type header to the file's MIME type (like image/jpeg, application/pdf, etc.) and place the file's raw data in the request body.

// HTML form with input type 'file'
// <input type="file" id="fileInput">

const fileInput = document.getElementById('fileInput');

fileInput.addEventListener('change', function(event) {
    const file = event.target.files[0];

    fetch('/upload', {
        method: 'POST',
        body: file,
        headers: {
            'Content-Type': file.type
        }
    })
    .then(response => response.json())
    .then(data => console.log(data))
    .catch(error => console.error(error));
});

Use Case: Suited for APIs or services where you're uploading only a file, without any additional form fields.

Compatibility: Works with both XMLHttpRequest and Fetch API. Requires manual setting of headers and handling of file data.

Advantages:

More efficient for sending only file data as it avoids the overhead of multipart encoding.
Offers more control over the request, such as setting custom headers.

Disadvantages:

Requires manual handling of content types and boundaries if needed.
Not suitable for situations where you need to send additional data alongside the file.

Summary

FormData is best for situations where a file is being uploaded as part of a form with other fields. It's more browser-friendly and straightforward to use. Direct Body Upload is more efficient for APIs where you're only uploading a file and need more control over the request. It's less suited for traditional form-based uploads and requires more manual setup.

Npm vs Yarn

Royal Jain — Tue, 30 Jan 2024 10:36:18 +0000

Npm is the default package manager for Node.js. It was the first package manager for JavaScript, it has a large community and comes bundled with Node.js installations. So why was Yarn created and why it gained so much popularity.

Performance

Yarn, was created by Facebook as a faster alternative to NPM. Why is it faster?

Concurrent Installation

Yarn installs multiple packages at the same time, whereas older versions of npm would do this sequentially. This concurrency significantly speeds up the installation process.

Efficient Caching

Yarn caches every package it downloads, so it never needs to download it again. This means that once you've installed a package using Yarn, it's available on your machine offline. npm also caches downloaded packages, but Yarn's caching mechanism was more efficient, especially in its early versions.

Flat Dependency Resolution

Dependency Resolution is the process through which a package manager determines which versions of each package should be installed to satisfy the requirements of all the packages in your project. This includes the dependencies of dependencies, and so on.

Npm resolved dependencies in a nested manner. This means that each package would have its own node_modules directory containing its dependencies, and those dependencies would have their own node_modules directories, and so on. This could lead to a deeply nested structure within the node_modules folder of a project.

Issues with Nested Dependency Resolution

One of the main issues with this approach is the potential for duplication. If different packages required different versions of the same dependency, that dependency would be downloaded and stored multiple times, once for each version required. Due to the potential for duplication the installation process could be slower. This approach could consume more disk space because of the duplicated packages across different dependency trees.

Yarn introduced a flat mode (using the --flat flag) that would install only one version of a package if possible, reducing duplication and minimizing disk space usage. This was particularly advantageous when dealing with large numbers of dependencies.

Conclusion

Over time, npm has closed the performance gap. Now, the choice often comes down to personal or team preference, and familiarity with the tool. Many projects that started with npm have continued to use it due to its improvements over time, while others prefer Yarn for its initial advantages in performance and consistency.