Built-in modules overview in Node.js - Performance & Optimization

Performance: Built-in modules overview

MEDIUM IMPACT

This affects the initial load time and runtime performance by controlling how much code is loaded and executed from Node.js core modules.

Using functionality for file system operations

Node.js

import { readFileSync } from 'fs';
readFileSync('file.txt', 'utf8');

Uses Node.js built-in fs module which is already loaded and optimized.

📈 Performance Gainno extra bundle size, faster startup

Using functionality for file system operations

Node.js

import fsExtra from 'fs-extra';
fsExtra.readFileSync('file.txt', 'utf8');

Imports an external package increasing bundle size and load time unnecessarily when Node.js has a built-in fs module.

📉 Performance Costadds 50kb+ to bundle and blocks startup longer

Performance Comparison

Pattern	Module Size Impact	Load Time	Memory Usage	Verdict
Using external package for core functionality	Adds 20-50kb+	Slower startup	Higher memory	[X] Bad
Using Node.js built-in module	No extra size	Fast startup	Lower memory	[OK] Good

Rendering Pipeline

Built-in modules are loaded by Node.js runtime before user code runs, so they do not affect browser rendering but impact server startup and memory usage.

→Module Loading

→Execution

⚠️ BottleneckModule Loading when importing large external packages instead of built-ins

Optimization Tips

1Always prefer Node.js built-in modules over external packages for core functionality.

2Avoid importing large external libraries if a built-in module provides the needed feature.

3Check module size and startup time impact when adding dependencies.

Performance Quiz - 3 Questions

Why is using Node.js built-in modules better for performance than external packages?

A They provide more features than external packages

B They avoid adding extra bundle size and reduce startup time

C They always run faster at runtime

D They automatically cache data for faster access

DevTools: Node.js --inspect and Chrome DevTools

How to check: Run Node.js with --inspect flag, open Chrome DevTools, check the Modules section and memory profiler to see loaded modules and memory usage.

What to look for: Look for large external modules loaded unnecessarily and high memory usage during startup.

Practice

1. Which statement best describes Node.js built-in modules?

easy

A. They require manual compilation before use.

B. They must be downloaded separately before use.

C. They are only available through third-party packages.

D. They are pre-installed tools for common tasks in Node.js.

Solution

1. Step 1: Understand what built-in modules are

   Built-in modules come with Node.js by default and provide common functionalities without extra installation.

2. Step 2: Compare options with this fact

   Only 'They are pre-installed tools for common tasks in Node.js.' correctly states they are pre-installed tools. Others mention downloading, third-party, or compiling, which are incorrect.

3. Final Answer:

   They are pre-installed tools for common tasks in Node.js. -> Option D

4. Quick Check:

   Built-in modules = pre-installed tools [OK]

Hint: Built-in means included by default, no download needed [OK]

Common Mistakes:

• Thinking built-in modules need separate installation
• Confusing built-in with third-party packages
• Assuming manual compilation is required

2. Which is the recommended way to import the built-in fs module in Node.js using ES modules?

easy

A. import fs from 'fs';

B. import fs from 'node:fs';

C. import { fs } from 'fs';

D. const fs = require('fs');

Solution

1. Step 1: Identify ES module import syntax for built-in modules

   Node.js recommends using the node: prefix with ES module import syntax for built-in modules.

2. Step 2: Check options for correct syntax

   import fs from 'node:fs'; uses import fs from 'node:fs'; which is correct. import fs from 'fs'; misses the prefix, B uses CommonJS syntax, C incorrectly destructures.

3. Final Answer:

   import fs from 'node:fs'; -> Option B

4. Quick Check:

   Use import + node: prefix for built-in modules [OK]

Hint: Use 'import' with 'node:' prefix for built-in modules [OK]

Common Mistakes:

• Using CommonJS require() in ES modules
• Omitting 'node:' prefix for built-in modules
• Incorrect destructuring import syntax

3. What will the following code output?

import os from 'node:os';
console.log(os.platform());

medium

A. The current operating system platform, like 'win32' or 'linux'.

B. An error because 'os' is not a valid module.

C. Undefined because platform() is not a function.

D. The Node.js version number.

Solution

1. Step 1: Understand the 'os' module and platform() method

   The 'os' built-in module provides operating system info. The platform() method returns the OS platform string.

2. Step 2: Analyze the code output

   The code imports 'os' correctly and calls platform(), so it prints the OS platform like 'win32', 'linux', or 'darwin'.

3. Final Answer:

   The current operating system platform, like 'win32' or 'linux'. -> Option A

4. Quick Check:

   os.platform() returns OS platform string [OK]

Hint: os.platform() returns your system's platform name [OK]

Common Mistakes:

• Thinking 'os' is not built-in
• Assuming platform() is undefined
• Confusing platform() with Node.js version

4. Identify the error in this code snippet:

import path from 'node:path';
const fullPath = path.join('/home', 'user', 123);
console.log(fullPath);

medium

A. The number 123 should be a string to join paths correctly.

B. The import statement is incorrect; 'node:path' is invalid.

C. path.join cannot join more than two arguments.

D. console.log is missing parentheses.

Solution

1. Step 1: Check the import statement

   Importing 'path' from 'node:path' is correct syntax for built-in modules.

2. Step 2: Analyze path.join arguments

   path.join expects string arguments. Passing number 123 relies on implicit string coercion, which is not best practice and can lead to unexpected results.

3. Step 3: Identify the error

   Best practice is to convert 123 to string before joining paths to avoid issues.

4. Final Answer:

   The number 123 should be a string to join paths correctly. -> Option A

5. Quick Check:

   path.join needs string args, numbers cause issues [OK]

Hint: All path.join args must be strings, not numbers [OK]

Common Mistakes:

• Thinking 'node:path' import is invalid
• Believing path.join limits arguments
• Missing parentheses in console.log

5. You want to read a file asynchronously using the built-in fs module with promises. Which code snippet correctly imports and uses it?

hard

A. import fs from 'node:fs';
fs.readFile('file.txt', (err, data) => { console.log(data); });

B. import fs from 'fs';
const data = fs.readFileSync('file.txt');
console.log(data);

C. import { readFile } from 'node:fs/promises';
const data = await readFile('file.txt', 'utf8');
console.log(data);

D. const fs = require('fs/promises');
fs.readFile('file.txt').then(console.log);

Solution

1. Step 1: Identify correct import for promise-based fs

   Node.js provides promise-based fs functions under 'node:fs/promises' module, imported with ES module syntax.

2. Step 2: Check usage of readFile with await

   import { readFile } from 'node:fs/promises'; const data = await readFile('file.txt', 'utf8'); console.log(data); correctly imports readFile from 'node:fs/promises' and uses await to read file asynchronously.

3. Step 3: Verify other options

   import fs from 'node:fs'; fs.readFile('file.txt', (err, data) => { console.log(data); }); uses callback style, not promises. import fs from 'fs'; const data = fs.readFileSync('file.txt'); console.log(data); uses synchronous readFileSync. const fs = require('fs/promises'); fs.readFile('file.txt').then(console.log); uses require() which is CommonJS, not ES modules.

4. Final Answer:

   import { readFile } from 'node:fs/promises'; const data = await readFile('file.txt', 'utf8'); console.log(data); -> Option C

5. Quick Check:

   Use 'node:fs/promises' with await for async file read [OK]

Hint: Use 'node:fs/promises' and await for async file reading [OK]

Common Mistakes:

• Using callback style instead of promises
• Mixing CommonJS require with ES modules
• Using synchronous readFileSync for async needs