DEV Community: Tech Webster

React List Keys: Keep Edited Text with the Right Record

Tech Webster — Sat, 31 Oct 2026 05:35:26 +0000

You type a note in the first row of a list. Then you sort the list. The note stays in the first row, but that row now shows a different record.

This can happen when a React list uses its array index as a key. The rows look correct until someone edits a field and changes the order.

Why the text ends up in the wrong row

Each editor below stores its text with useState. React uses the key to decide which editor instance belongs to which item.

An index key identifies a position: first row, second row. After sorting, a different record can occupy that position while the editor keeps its previous state. A record ID gives React a way to match the editor to the same record after it moves.

Try the example

Paste this component into a React application's App.jsx. Start with the default stable keys, edit a note, and reverse the list. The note should follow its record.

import React, { useState } from 'react';
const initialDrafts = [
  { id: 'incident-42', title: 'Cache invalidation review', body: 'Check the stale key path.' },
  { id: 'incident-57', title: 'Retry policy review', body: 'Check the backoff limits.' },
];
function DraftEditor({ draft, position, stableKeys }) {
  const [body, setBody] = useState(draft.body);
  return (
    <article aria-label={`Draft at position ${position + 1}`}>
      <h2>{draft.title}</h2>
      <label>
        Reviewer notes for {draft.id}
        <textarea value={body} onChange={event => setBody(event.target.value)} />
      </label>
    </article>
  );
}
export default function ReviewQueue({ stableKeys = true }) {
  const [drafts, setDrafts] = useState(initialDrafts);
  const reverseQueue = () => setDrafts(current => [...current].reverse());
  return (
    <main>
      <p>Key strategy: {stableKeys ? 'draft id' : 'array position'}</p>
      <button type="button" onClick={reverseQueue}>Reverse review order</button>
      {drafts.map((draft, position) => (
        <DraftEditor
          key={stableKeys ? draft.id : position}
          draft={draft}
          position={position}
          stableKeys={stableKeys}
        />
      ))}
    </main>
  );
}

To see the bug, render the component with stableKeys={false}. Edit incident-42 before reversing the list. The first row will now display incident-57 while keeping the text you entered for incident-42.

The important line is:

key={stableKeys ? draft.id : position}

In a real editable list, use a stable value that represents the item among its siblings. Avoid generating a new random key during every render: that gives the component a new identity and resets its state.

What keys do not save

If you remove a row from the tree, its local state is discarded. Bringing it back with the same key does not restore the old text. If edits must survive filtering or navigation, store them in a parent or another persistent store, indexed by record ID.

For a single editor, you might deliberately want to clear the local buffer when the selected record changes. Keying that editor by the selected ID makes that reset explicit. Keep the key on the smallest subtree you intend to reset.

Test the interaction that caused the bug

Edit one record, reorder the list, and check that the edited value still belongs to that record. Checking only the displayed row order misses the problem.

Then remove the edited record and bring it back. Decide whether losing the local text matches your product's requirements. That is a persistence decision as well as a rendering decision.

Read more in React's state identity guide and list key guidance.

Learn React by Building a Searchable Book List

Tech Webster — Fri, 30 Oct 2026 05:24:56 +0000

If you know JavaScript functions, arrays, objects and events, you can start learning React. Use one small project—a searchable book list—to learn components, props and state without adding a database or routing first.

If those JavaScript topics still feel unfamiliar, practice them before starting this roadmap. React uses them throughout the code.

1. Build a static version

Create a page header, a book card and a list. A component is a function that returns part of the interface. JSX lets you write that interface alongside JavaScript expressions.

Put a few fictional books in an array. Pass each book's title, author and category to the card as props. Props are values the parent provides to a child component.

Your first checkpoint is a readable list with no interaction. Change the array and confirm the page shows the new content.

2. Render lists and empty results

Use map to render the books. Give each item a stable key from the data, especially if the list can be filtered or reordered.

Add a message for an empty list. Sketch which component owns the list and which component renders a card. Keep the structure small enough to explain.

React's Thinking in React walks through this process with a product table.

3. Add search and a category filter

Store the search text and selected category in state. State holds values that need to survive between renders and change through interaction.

Calculate the visible books from those values and the original array. Do not store another copy of the filtered list unless you have a specific reason; duplicate state can drift out of sync.

Use a labeled input for search and native controls for the filter. Test with a keyboard. A query with no matches should show a useful message rather than a blank area.

4. Add one form

Let someone add a book to the in-memory list. Show an error for an empty title and preserve what they typed while they correct it.

With a controlled input, its value comes from state and its change handler updates that state. Check that the form behaves correctly after several submissions. A refresh can reset the list at this stage.

5. Load data and handle failure

Once local state makes sense, load a small JSON dataset. Show loading, error, empty and successful states. Handle an older request finishing after a newer one so it cannot overwrite the current result.

Learn Effects as a way to synchronize with an external system. Filtering an existing array is a calculation, so it usually belongs in render logic rather than an Effect. See React's Effect guide.

Before adding more libraries

Explain how a typed character reaches state, changes the filtered result and updates the list. Then add one feature without duplicating data in state.

When you can do that, explore testing, routing, TypeScript and deployment as separate next steps. Keep the book list as a project you understand rather than expanding it until every part depends on a new tool.

Start with the official React Quick Start.

Wrong Image or Title When You Share a Link? Check These Four Things

Tech Webster — Wed, 28 Oct 2026 05:04:17 +0000

You share a page on LinkedIn or Facebook, but the preview shows an old title, the wrong image, or no image at all. The page looks fine in your browser. What should you check next?

A link preview depends on several steps: the platform fetches the shared URL, reads its metadata, fetches the image, and may reuse a cached result. A failure at any step can produce the wrong card.

Work through these four checks in order. The examples below use placeholder URLs: replace them with your deployed page and image URLs.

1. Check the metadata in the HTML response

Start with the exact URL you are sharing, including its path and any query parameters. Checking only the homepage can miss a problem on an individual article or product page.

A basic Open Graph configuration looks like this inside the document's <head>:

<meta property="og:title" content="A useful page title">
<meta property="og:description" content="A short, accurate summary of this page.">
<meta property="og:type" content="website">
<meta property="og:url" content="https://example.com/guides/launch">
<meta property="og:image" content="https://example.com/images/launch-card.jpg">
<meta property="og:image:alt" content="An illustrated checklist for launching a website">

Use your intended canonical page address for og:url and a public, absolute URL for og:image. Use article instead of website when describing an article. The Open Graph specification defines the fields and optional image properties.

Fetch the deployed HTML without relying on your browser's JavaScript:

curl -sS -L --max-time 30 \
  -D /tmp/card-headers.txt \
  -o /tmp/card.html \
  -w 'Final URL: %{url_effective}\nStatus: %{http_code}\n' \
  'https://example.com/guides/launch'

cat /tmp/card-headers.txt
grep -iE 'og:(title|description|type|url|image)' /tmp/card.html

-L follows redirects. Inspect the headers as well as the final status: a redirect to a login page, a challenge page, or the wrong route can explain a missing preview. A 200 response alone does not prove that you received the intended page.

The grep command is a quick search, not an HTML validator. Inspect the full saved response if tags span multiple lines or the result is unclear. Compare it with the browser's rendered DOM. Tags added only by client-side JavaScript may be absent from the response a preview crawler reads.

Next.js detail: metadata can stream for ordinary clients, while Next.js handles known HTML-limited bots differently. For example, its documented behavior for facebookexternalhit places resolved metadata in the head before returning the page. A normal curl request therefore does not always reproduce the crawler's response. You can compare a second request:

curl -sS -L --max-time 30 \
  -A 'facebookexternalhit/1.1' \
  -o /tmp/card-facebook.html \
  'https://example.com/guides/launch'

This changes the user agent only. It does not reproduce the platform's network, cache, or full crawler behavior. Use the Next.js metadata documentation and the platform inspector together.

2. Look for conflicting or inherited values

A layout, route, CMS plugin, and manually written tag can each contribute metadata. Check the final response for the page, rather than assuming a configuration file tells the whole story.

Look for:

A product page that inherits the homepage title or image.
An old image URL emitted alongside the intended one.
Different canonical and Open Graph URLs pointing at unintended pages.
A nested route whose metadata differs from what you tested locally.

Multiple og:image tags can be intentional; Open Graph supports arrays and gives preference to the first value when conflicts occur. Remove unintended duplicates and put the preferred image first. Associate each image's structured properties with that image.

In Next.js, nested metadata such as openGraph uses shallow merging between route segments. Defining openGraph in a child segment can replace fields supplied by a parent. Check that your page still includes its intended image and description after an override. See the merging documentation.

Checkpoint: inspect both the homepage and one nested page after deployment. Each should describe its own content.

3. Fetch the image without your login

Copy the final og:image URL and request it separately:

curl -sS -L --max-time 30 \
  -D /tmp/card-image-headers.txt \
  -o /tmp/card-image \
  -w 'Final URL: %{url_effective}\nStatus: %{http_code}\nType: %{content_type}\n' \
  'https://example.com/images/launch-card.jpg'

cat /tmp/card-image-headers.txt
file /tmp/card-image

Check that the response contains the intended image, with a successful status and an appropriate image content type. An HTML error page saved with a .jpg name is still an error page.

A file visible in your signed-in browser may depend on a session cookie. Expiring image URLs, hotlink protection, CDN rules, or bot challenges can also prevent a platform from fetching it. Check crawler access to both the page and image; an unauthenticated curl request is useful evidence, but it cannot guarantee that the platform can reach them.

Use a supported image format and the target platform's current size and file limits. Keep important text and logos away from the edges because platforms may crop differently. If you include og:image:width, og:image:height, or og:image:type, make them match the actual file. Add useful og:image:alt text.

Checkpoint: open the downloaded file and confirm it is the image you intended to share.

4. Check the platform's cached preview

Once the deployed HTML and image are correct, inspect the same shared URL using the destination platform's tools:

These tools may require sign-in. Review any fetch errors and the values the platform detected. Where offered, request a fresh scrape or inspection after deploying your fix.

If you replaced an image while keeping its URL, your own CDN may still serve an older file. Check that cache too. A new, stable image filename can help distinguish a new asset, but update og:image and recheck the page rather than relying on a filename change alone.

Refreshing a preview does not guarantee that every existing post will update immediately. Platforms can cache and display cards differently.

Avoid appending random query strings to every shared page URL as a permanent workaround. That can create more URL variants while leaving the original issue unresolved.

A quick way to narrow it down

What you see	Where to investigate first
Homepage card appears on every page	Route metadata, inherited defaults, and redirects
Correct title, missing image	Image URL, response type, and crawler access
Old card after a deployment	Deployed HTML, CDN caches, then platform cache
Correct in browser, wrong in inspector	Server response, user-agent differences, and access rules

These are starting points, not definitive diagnoses. Record the shared URL, final redirected URL, image URL, deployment time, and inspector result so you can compare the same evidence after a fix.

At TechWebster, we built SEO By TechWebster to help inspect metadata and social-card setup before launch. Use it as an initial check, then confirm the result with the destination platform's own inspector.

For a wider launch review, see 5 SEO Checks to Run Before Launching Your Website.

Which preview problem have you run into most often: the wrong title, a missing image, or a card that refuses to refresh?

React Syllabus for Beginners: A Step-by-Step Roadmap

Tech Webster — Tue, 27 Oct 2026 03:16:02 +0000

Comfortable building a page with HTML, CSS and JavaScript? React is a next step for building interfaces from reusable components and keeping them in sync with changing data.

This syllabus follows our HTML, CSS and JavaScript roadmaps. Work through the topics in order, try the checkpoints, and build one feature at a time. It is a learning plan, not a promise that reading a list makes you production-ready.

Before You Start

You should be able to use JavaScript functions, arrays, objects, destructuring, modules, events, promises and async/await. Practice mapping and filtering arrays without React first. You do not need to learn Node.js backend development before starting.

Revisit our HTML syllabus, CSS syllabus and JavaScript syllabus when those foundations need more practice.

The Learning Order

Stage	Sections	Try this before moving on
1. Components and rendering	1–7	Build a static book list from data and explain each component's props.
2. Interaction and state	8–14	Add search, filters and a validated form without duplicating state.
3. External systems and reusable logic	15–19	Handle loading and failure, clean up an Effect and explain when a ref or custom Hook helps.
4. Quality, delivery and next steps	20–24	Test a user journey and finish a small accessible capstone before adding ecosystem tools.

The later topics build on the earlier ones. Return to a checkpoint when you cannot yet explain the result.

1. Introduction to React

What a UI library does and how React differs from plain DOM scripting
Describing the interface from data instead of manually changing each element
Components, props and state at a high level
Core React versus frameworks, routing libraries and build tools

React does not replace HTML, CSS or JavaScript. Start with the official React Quick Start.

2. Setting Up Your Workspace

A code editor, modern browser and browser developer tools
Trying examples in the interactive sandboxes in React's documentation
For local learning, a React project created with a current build tool such as Vite
Reading the generated files, package scripts and development-server output
Distinguishing development from a production build

Use React's setup guidance to choose an approach. React recommends a framework for new production apps; its from-scratch guide also supports learning the basics with a build tool. Follow Vite's current instructions and Node.js requirements if you choose that route. This syllabus does not depend on Create React App.

Practice: run a starter app, change the heading, and find the error when you deliberately break a component name.

3. JSX and Rendering Markup

Writing markup in JSX and embedding JavaScript expressions
Closing tags, returning one enclosing structure and using fragments
Using className and JavaScript objects for inline styles
Keeping render logic predictable and free of side effects

Practice: rebuild a simple profile card with a heading, image and descriptive text.

4. Components and File Organization

Function components and capitalized component names
Defining a component separately from rendering it
Nesting components and organizing imports and exports
Splitting by responsibility rather than turning every line into a component

Practice: draw a component tree for a page header, search bar, book list and book card.

5. Props and Composition

Passing strings, numbers, objects and callbacks to children
Reading props without modifying them
Using children to compose a reusable layout
Keeping data flow understandable from parent to child

Practice: render different book cards with the same component. Explain which values come from props.

6. Lists and Stable Keys

Transforming arrays into elements with map
Giving sibling items stable keys from their data
Avoiding array-index keys when items can move, appear or disappear
Understanding that keys help identify items rather than becoming ordinary child props

Practice: reorder editable rows and verify that each edit stays with its record. Read the official list-key guidance.

7. Conditional UI and Styling

Showing different output with conditions and conditional expressions
Rendering helpful empty results instead of a blank area
Applying styles from state or props
Reusing responsive CSS and semantic HTML

Checkpoint: build the static book-list interface before adding interaction. Thinking in React demonstrates that sequence.

8. Events and Handlers

Passing an event handler rather than calling it during render
Responding to clicks, changes and form submissions
Passing callback props to communicate user actions
Understanding default browser behavior and event propagation

Practice: add a button that reports which book was selected.

9. State with useState

Adding state for values that change through interaction
Reading state as a snapshot for a particular render
Requesting an update with the setter
Using an updater function when the next value depends on the previous value

Practice: build a counter with increase, decrease and reset controls. Explain why changing an ordinary variable is not enough to update the interface. See Adding Interactivity.

10. Updating Objects and Arrays

Treating objects and arrays in state as read-only
Producing updated copies rather than mutating existing state
Adding, removing and editing items using stable IDs
Copying nested values when the update requires it

Practice: toggle a book's completed status and remove a book without changing the previous array.

11. Controlled Forms and Validation

Connecting text inputs, checkboxes and selects to state
Keeping controlled values consistent rather than switching between controlled and uncontrolled inputs
Handling submission and preserving entered values when validation fails
Associating labels, instructions and errors with form controls

Practice: add a book with a required title and a category. Check keyboard submission and repeated submissions. Client validation supports usability; a backend must still validate and authorize requests. Consult React's input reference.

12. Choosing and Deriving State

Storing the smallest useful representation of the interaction
Calculating filtered lists and totals from existing data
Avoiding duplicate state that can fall out of sync
Representing loading or submission status without contradictory flags

Practice: store search text and category, then calculate the visible books during render. Do not add an Effect just to copy that filtered list into state. See You Might Not Need an Effect.

13. Sharing State Between Components

Finding the closest common parent that needs the data
Lifting shared state up and passing values and callbacks down
Keeping one source of truth for a shared value
Distinguishing local editing state from shared application data

Practice: keep a results count and book list synchronized from the same filter values. Review Managing State.

14. State Identity and the Rules of Hooks

How position, component type and keys affect whether state is preserved
Resetting a small editor intentionally when its selected record changes
Understanding that removing a component discards its local state
Calling ordinary Hooks such as useState at the top level of components or custom Hooks

Practice: switch records and decide which edits should survive. Read Preserving and Resetting State and the Rules of Hooks. Keep the Hooks lint rules enabled.

15. Effects for External Synchronization

Using an Effect when synchronizing with an external system
Distinguishing rendering calculations, user events and Effects
Specifying dependencies honestly and cleaning up subscriptions or timers
Understanding development Strict Mode checks rather than disabling them to hide cleanup problems

Practice: subscribe to a browser event and remove the listener in cleanup. Filtering data and handling a click usually do not need an Effect. Follow Synchronizing with Effects.

16. Loading Data and Handling Failure

Displaying loading, error, empty and successful states
Checking HTTP status and the shape of data before using it
Avoiding stale responses overwriting newer results
Offering a useful retry path

Practice: load a small public JSON dataset and simulate a slow request, a failed request and no results. A simple Effect-based fetch can teach request lifecycles; production frameworks and data libraries may provide better loading, caching and request coordination. Keep private credentials out of browser code.

17. Refs and DOM Access

Using useRef for a value that does not need to trigger a render
Accessing a DOM node when focus, scrolling or measurement requires it
Understanding why changing a ref does not update the UI
Avoiding manual changes to DOM that React manages

Practice: focus the search input from a clearly labeled button. Learn these features as escape hatches, not the default way to manage data flow.

18. Reusing Logic with Custom Hooks

Extracting repeated stateful logic after its behavior is understood
Naming custom Hooks with use
Keeping each Hook's responsibility specific
Understanding that sharing a Hook does not automatically share its state between callers

Practice: extract a small online-status subscription used by two components. Explain the setup and cleanup. Use Reusing Logic with Custom Hooks as a reference.

19. Reducers and Context When Needed

Consolidating related state transitions with useReducer
Keeping reducer logic pure and testing transitions separately
Passing shared values deeper through context when props become cumbersome
Avoiding global context for every local input

Practice: move increasingly complex book-editing actions into a reducer only when it makes them clearer. A small list can remain in useState. See Scaling Up with Reducer and Context.

20. Accessibility and Responsive Interaction

Using real links, buttons, headings and labeled controls
Testing the full interaction with a keyboard
Managing focus after important changes and communicating status or errors
Checking narrow layouts, zoom and readable content

Practice: add a book and find it using only the keyboard. Check the no-results message and make sure the result does not depend on color alone.

21. Debugging and Testing Basics

Reading component errors, warnings and network failures
Inspecting props and state with React Developer Tools
Testing visible behavior rather than private component details
Starting with a test runner and a component-testing library appropriate to the project

Practice: test searching, no matches, invalid submission and a successful addition. Include a loading or failure case when fetching data. React Testing Library provides tools for tests that resemble how people use an interface.

22. Routing, Frameworks and Performance: Next-Stage Topics

Adding URLs and navigation when the app actually needs multiple views
Distinguishing client rendering, server rendering and Server Components
Understanding that routing and production data-loading choices depend on the chosen framework or libraries
Measuring a performance problem before adding memoization

These are ecosystem and architecture topics, not prerequisites for your first component. Follow the chosen framework's current documentation rather than mixing incompatible setup instructions.

23. Capstone: An Accessible Reading List

Build this in small steps:

Render fictional books with reusable cards and stable IDs.
Add search, category filters, a results count and an empty state.
Add, edit and remove books through labeled, validated controls.
Load a dataset and provide loading, error and retry behavior.
Add local persistence only if needed; label it clearly as browser-local storage rather than cloud sync.
Test a complete user journey, review keyboard access and explain the component tree.

The separate book-list practice article is a companion exercise; this syllabus is the wider curriculum. Do not add authentication, payments or a database just to make the first project look bigger.

24. Production Build and What to Learn Next

Run the project's production build and preview it locally
Check navigation, assets, empty states and failed requests in that build
Deploy using the hosting instructions for the chosen build tool or framework
Continue with TypeScript, routing, more testing or backend integration according to the project

A browser-only React app cannot keep a secret API key private. Keep privileged operations on a suitable backend. Finishing a starter project is a foundation for further practice, not proof of production expertise.

How to Practice

Read a topic, build a small example, change it and observe what happens. Revisit the book list as you learn. Before moving on, explain where its data lives, why it re-renders and what happens when something fails. Your pace depends on your experience and practice time.

A Few Common Questions

Do I need JavaScript before React?

Yes. Functions, arrays, objects, modules and asynchronous code appear throughout React applications. Return to the JavaScript exercises whenever React syntax hides a language concept you do not yet understand.

Should I learn React or Next.js first?

Learn components, props, state and events as React concepts. A framework can supply the project setup and production features, but those fundamentals still matter. A small learning app does not need every framework feature on day one.

Do I need Redux or another state library?

Not for the first project here. Start with local state, lifting shared state and clear data flow. Learn reducers and context when a concrete problem justifies them; evaluate additional libraries later.

How long does it take to learn React?

There is no fixed mastery timeline. Being able to build, explain, test and debug a small feature tells you more than checking off topics or counting days.

Helpful Resources

React Learn — official lessons and interactive examples.
Thinking in React — component structure and minimal state.
Managing State — state organization and sharing.
Escape Hatches — refs, Effects and reusable logic.
Creating a React App — current setup choices.

Related TechWebster Roadmaps

Which React topic would you like us to explain next with a hands-on example?

LiteLLM 1.107.0 Was Compromised: What to Check Before You Reinstall

Tech Webster — Sun, 25 Oct 2026 10:28:35 +0000

If your team installed LiteLLM 1.107.0, check which builds and servers used it. LiteLLM says an attacker compromised its release pipeline on 21 October 2026 and published malicious packages.

The difficult part is the cleanup. Removing the package may leave malicious files behind, and replacing the software does not invalidate credentials that were already stolen.

What was affected?

The maintainer’s report identifies malicious PyPI wheels for version 1.107.0 and affected container releases, including v1.107.0, latest, main-latest, and main-stable during the incident’s exposure window. The artifacts were subsequently removed or repointed.

A wheel is the packaged Python code your installer downloads. A container tag such as latest is a label that can point to different images over time.

That distinction matters here. The maintainers say the official GitHub source tag did not contain the malicious files. Reviewing that source alone would not tell you whether a downloaded package was safe. They also say customers using the private enterprise registry were unaffected.

Start with the maintainer’s incident report for the current scope and recovery instructions.

Why isn’t uninstalling enough?

The malicious release could place files in Python’s startup path. Python can load those files when it starts, before your application explicitly imports LiteLLM.

Wiz identifies files including cook.pth and sitecustomize.py. Its researchers describe credential theft and the ability to load more code, with targets including cloud credentials, developer secrets and AI provider keys. They also report observed use of stolen credentials. These findings do not establish what happened on your particular server. See Wiz’s analysis.

Do not begin by running pip in a suspected environment. The maintainer warns that starting Python there can execute the malicious startup files again. Even a command intended to inspect the installation may start Python.

How do I find out whether we installed it?

Begin with records you can inspect outside the suspected environment:

Check build logs and lockfiles for LiteLLM 1.107.0.
Check when CI jobs or servers installed it.
For containers, find the image digest that actually ran. A digest identifies a particular image; a moving tag such as latest does not.
List the services, jobs and machines that used those builds.
List the credentials those environments could access.

For example, pulling a clean latest image today does not tell you what yesterday’s deployment used. Look at the deployment record and original image digest.

Using LiteLLM does not by itself mean you installed an affected artifact. Establish that from the records before describing a particular system as exposed.

What should an affected team do next?

Bring in the person responsible for security or infrastructure and follow the live maintainer instructions. Preserve relevant logs before cleanup removes evidence.

Track two parts of the recovery:

Rebuild the affected environment. The maintainer recommends treating it as compromised, addressing the startup files and rebuilding where possible. A fresh environment avoids relying on package removal to find every malicious file.

Replace exposed credentials and review their use. Work with the services that issued those credentials. Check for unexpected access, resources or charges. Deploy replacement credentials to the rebuilt application and test that it still works.

A successful application restart only shows that the application starts. It does not show that stolen credentials have stopped working elsewhere.

What changed in the root-cause report?

The 23 October canonical investigation supersedes early theories about tokens being taken from request logs. LiteLLM says a master key exposed in a public repository was not revoked. An attacker used it to access the Agent Platform and retrieve an organization owner’s GitHub token, then obtained additional CI secrets and altered the release workflow.

For teams building agents, the practical lesson is to revoke exposed keys immediately and give automation narrowly scoped credentials. Removing a leaked key from Git history does not revoke it.

What should we change in our release process?

Keep enough information to identify the artifact each deployment used: the package version, build time and container digest where applicable. Pinning versions helps you reproduce a build, but a pinned version can still be malicious.

For this incident, the useful review questions are specific: Did we run an affected artifact? Which environments used it? Which credentials could they reach? Those answers give the recovery team somewhere concrete to begin.

Checked 25 October 2026 against the linked incident report, canonical investigation and Wiz analysis. Consult the live maintainer guidance before recovery. TechWebster has not independently reproduced the malware.

PHP2Shell Follow-up: Do You Need to Change Your Session Settings?

Tech Webster — Sat, 24 Oct 2026 14:36:29 +0000

If you already updated PHP after PHP2Shell, there is one more notice to review. On 23 October, the PHP team described an additional risk involving session upload progress and a particular way of changing session settings.

The notice does not say every PHP application is affected. The first thing to check is whether your application changes its session serializer while handling a request.

What does that mean in ordinary PHP code?

A session lets PHP keep information between requests, such as the data associated with a signed-in user. The session serializer controls how that data is encoded when PHP stores it.

PHP also has an upload-progress feature that can store information about an upload in the session. An application can use this to report how much of a file has arrived.

The new notice concerns a combination of these features. PHP describes a possible remote-code-execution issue, meaning an attacker could potentially make the server execute code. The issue is tracked as CVE-2026-115560.

Which combination should I look for?

The PHP notice describes an application that:

Starts with session.serialize_handler set to php_binary or php_serialize.
Changes that setting to php using ini_set() before calling session_start().
Still has session upload progress enabled.

Read those as a combination. Seeing session_start() in your project alone does not establish that the application matches the notice.

Search your application and relevant dependencies for session.serialize_handler, then inspect any code that changes it. Check the PHP configuration used by the web application as well. Your command-line PHP installation may use a different configuration.

If someone else manages the server, send them the official notice and ask them to check these settings in the environment serving your site.

What does PHP recommend?

PHP suggests disabling session upload progress until the next regular bugfix release:

session.upload_progress.enabled=0

There are two qualifications in the notice:

Applications that never change the serializer at runtime can keep the feature enabled.
If you already applied this setting for the earlier CVE-2026-109619 advisory, keep it in place. PHP says no further action is needed for that case.

Source: PHP’s 23 October informational advisory.

What should I check after changing the setting?

If you need to apply the setting, have the person responsible for the deployment put it in php.ini, an FPM pool or server configuration that applies before request parsing, then restart every relevant PHP worker. Do not rely on ini_set() or FPM .user.ini for this mitigation. These deployment instructions come from PHP’s 21 October security advisory. Then confirm the effective setting in the web-serving environment.

Test any upload-progress interface your application uses, because disabling the feature can affect how progress is reported. Also run your usual session and upload checks after the configuration change.

Record where the setting was changed and which application instances received it. That avoids assuming that a configuration edit reached every running worker.

Do I still need the original PHP2Shell update?

Yes. Keep the original fixes and any applicable mitigation in place. This follow-up adds a configuration check; it does not replace the previous patch guidance.

Our original PHP2Shell article covers CVE-2026-109618 and CVE-2026-109619. Keep that update record together with the outcome of this session-setting review.

What is still pending?

PHP says a full advisory will accompany the next release. This preliminary notice does not provide a complete account of affected builds or exploit conditions.

For now, write down whether your application changes its serializer, whether upload progress is enabled, and which guidance you followed. Revisit that record when PHP publishes the full advisory and release.

Checked 24 October 2026 against PHP’s official notices. TechWebster has not independently reproduced the issue.

Node2Shell: Is Your Node.js App Affected? What to Check and Update

Tech Webster — Fri, 23 Oct 2026 17:44:43 +0000

If you run a Node.js backend, check the Node version running in production. The October security release fixes a bug that can allow an attacker to run code by sending specially crafted compressed data to a vulnerable application.

That does not mean every Node.js app is exploitable. The risk depends on whether the app processes that data. Here is what to check, what to update, and how to confirm the update reached your server.

What happened?

Brotli is a compression format: it makes data smaller before it travels over the network. The receiving application decompresses it to read the original content.

Node.js has built-in support for this. The vulnerability is in the part that decompresses Brotli data. A malicious input can make it write outside the memory it should use. In certain circumstances, that can let an attacker execute code inside the Node.js process.

The issue is tracked as CVE-2026-111497 and rated High by the Node.js project. “Node2Shell” is the name Imperva uses for its research into the bug.

Could my app reach the vulnerable code?

Start with two places: data your server receives and data it fetches.

1. Your app accepts compressed request bodies.

Check the middleware that reads incoming requests. Imperva tested an application using configured Express/body-parser middleware that decompressed incoming Brotli data. Simply using Express does not establish that your app follows this path.

2. Your app fetches a compressed response from another server.

Think of a backend that downloads content from a URL. The response can be compressed, and the client may decompress it for your code. Imperva also demonstrated the issue through Node’s built-in fetch.

This second case is easy to overlook: your app makes the request, but another server supplies the response. A firewall filtering incoming requests to your site may not cover it.

A basic Node HTTP server does not automatically decompress every request body. Look at the libraries and code that handle the data. If you are unsure which paths your app uses, update the runtime while you investigate.

Which versions contain the fix?

The Node.js security release lists these fixed versions:

Your Node.js version line	Fixed release
22.x	22.23.4
24.x	24.22.1
26.x	26.12.1

Use the listed release or a newer release in that line that includes the fix. These are the release lines covered by the advisory; an older version is not automatically safe because it is absent from the table.

If your Linux distribution supplies Node.js, check its security notice too. Distributions can apply a fix to their own package without adopting the same upstream version number.

Source: Node.js October security release.

How do I check and update my deployment?

Run this inside the environment that runs your app:

node --version

Running it on your laptop tells you about your laptop. For a container deployment, check inside a running application container. For a server, check the Node installation used by the application service.

Then follow the route that matches your setup:

You manage the server: install a fixed Node release, restart the application with it, and confirm the serving process uses the updated installation.
You deploy containers: update the Node base image, rebuild your application image, and deploy it. Existing containers keep their old runtime until replaced.
Your hosting provider manages Node: check its advisory for your runtime version and any required redeployment. For Vercel, use its Node.js security bulletin.

After deployment, check the version again in the running environment and test your app’s normal requests, uploads and external API calls.

Updating npm packages alone does not update Node.js. The fix is in the runtime that executes your JavaScript.

What did the researchers actually demonstrate?

Imperva reports code execution in its tested applications on an official Node.js 24.22.0 Linux ARM64 image. Version 24.22.1 rejected the same inputs.

The demonstration needed multiple attempts and did not cover every build or application. It shows a working attack under those test conditions; it does not show that every vulnerable deployment has been compromised. See Imperva’s technical analysis for the details.

Before you close the update ticket

Make sure you can answer three questions:

Which Node version is running in production now?
Have all the old instances been replaced or restarted with the fixed runtime?
Did the application pass its normal checks after deployment?

Keep the deployed image or release identifier with those answers. It gives the next developer a way to confirm what changed.

We covered a similar runtime-maintenance problem in our PHP2Shell explainer. The vulnerabilities are separate, but both require checking the software actually running on the server.

Sources checked on 23 October 2026. The exploit findings above are attributed to Imperva; TechWebster has not independently reproduced them.

PHP2Shell: How the Vulnerabilities Were Found—and What Developers Should Check

Tech Webster — Thu, 22 Oct 2026 06:53:37 +0000

Research checked: 22 October 2026. This is a source-based explainer, not original vulnerability research or a claim that TechWebster reproduced the exploits.

An application can be up to date while the runtime underneath it still needs a security patch.

That is the practical reason to pay attention to PHP2Shell. Before deciding whether your WordPress site, Laravel application or custom PHP service is covered, identify the PHP runtime actually handling its web requests.

This article explains the published discovery story, the underlying failure pattern and a practical response checklist. Discovery, reporting and public disclosure are separate events; the dates below preserve that distinction.

What PHP2Shell refers to

On 21 October 2026, PHP released fixes for two critical vulnerabilities that can permit remote code execution without authentication:

Identifier	Underlying problem
CVE-2026-109618	An out-of-memory failure can interrupt initialization; cleanup may subsequently trust invalid internal request data.
CVE-2026-109619	Request-owned state can outlive the memory behind it; a later request may use that stale state.

PHP lists PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed among the affected web-serving setups. It identifies mod_php as the highest-risk setup, with a demonstrated attack that runs before application code. PHP's security advisory

This is a runtime security issue. A vulnerable installation and a confirmed compromise are different findings; discovering an affected version does not establish that an attacker has used it.

How the vulnerabilities were found

Earlier investigation provided clues

The PHP Foundation describes a 2024 audit performed by Quarkslab through OSTIF. While fixing an audit finding, a PHP core developer found signs of the OOM problem later associated with CVE-2026-109618.

At that stage, a potential exploit had been theorized, but concrete attack vectors had not been found. The Foundation describes difficult compatibility and implementation trade-offs, limited specialist capacity and a decision process that delayed a fix. That is more precise than saying nobody had noticed anything before 2026. PHP Foundation's account

Calif revisited fatal-error behavior

In its own account, Calif dates the start of its audit to 30 July 2026 and its first discovery to 1 August. Researcher Ryan Austin examined memory-limit failures and the points where they could interrupt PHP's native operations.

One finding involved bookkeeping becoming visible before an operation had fully initialized its data. If an allocation failed at that point, later cleanup could treat unfinished data as valid. Calif then used the observed pattern to guide AI-assisted searches for related failure paths.

Its timeline separates discovery from reporting: the first bug was reported to PHP on 11 August, followed by an RCE proof of concept on 14 August. Calif's original write-up

Wiz independently found related vulnerabilities

Wiz records its first discovery on 19 August, RCE validation against Drupal on 20 August and WordPress on 21 August, and reporting to PHP on 24 August.

Its write-up describes four exploitable instances grouped into the two CVEs, including memory disclosure and memory corruption. WordPress, Drupal and Joomla were demonstration targets, rather than the location of the underlying PHP engine flaws. Wiz's research and timeline

These accounts describe overlapping work. They should not be compressed into a story about a single researcher, company or model finding everything.

What role did AI actually play?

The published accounts describe researchers directing AI-assisted investigation, testing and validation. OpenAI says Calif identified a critical flaw using GPT-5.6 Sol through Patch the Planet, while Wiz independently discovered and reported both vulnerabilities. PHP's maintainers led the fixes and release. OpenAI's coordination account

Wiz reports using Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol. It says adapting working exploit chains required repeated testing and debugging across different memory layouts and that frontier models reduced that effort. Those are the research team's reported results, not a benchmark we independently reproduced. Wiz's description of AI's role

The useful engineering lesson is to examine interrupted operations as carefully as successful ones:

Operation begins
    ↓
Some state becomes visible
    ↓
A failure interrupts initialization
    ↓
Cleanup or a later request trusts incomplete or stale state

This is a conceptual explanation of the failure pattern, not an exploit recipe or a model of every affected path.

Does this mean every WordPress or Laravel site is exposed?

The application name alone cannot answer that question. The runtime build, hosting environment and applied fixes matter.

For example, Automattic stated on 21 October that WordPress.com, WordPress VIP, WP Cloud, Pressable and Tumblr were already protected. That prevents a misleading conclusion that every WordPress installation still requires its owner to patch PHP personally. Automattic also explains that application, theme and plugin updates alone do not replace a runtime fix. Automattic's notice

Keep maintaining the application. Also establish who maintains its runtime: your team, your hosting provider or another platform operator.

Which releases contain the upstream fixes?

PHP's 21 October security releases are:

PHP branch	Fixed upstream release
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35

Distribution and LTS vendors may backport the fix while retaining an older upstream version number. PHP 8.1 and older have no routine upstream updates; vendor fixes and exceptional minimal source backports for 7.4, 8.0 and 8.1 require checking the relevant guidance. PHP release and update guidance

Ubuntu illustrates why the full package version matters: its notice lists fixed distribution builds, including 8.3.6-0ubuntu0.24.04.13 for Ubuntu 24.04. It also states that applications using PHP may need restarting after the update; installing packages alone may leave old processes running. Ubuntu's package and restart guidance

A practical checklist for your team

Use the following as a working record for each deployment:

Inventory: hostname or application, owner, hosting provider, PHP branch, full package/image version and web-serving runtime.
Patch evidence: the applicable upstream release or vendor advisory confirming the backport. Record the complete build, not just “PHP 8.3.”
Deployment: the package or image that was installed, where it was deployed and when the relevant workers were restarted or replaced.
Verification: confirmation that web traffic is reaching the updated deployment, followed by normal application smoke checks.

Check the serving environment explicitly. A local terminal's PHP binary is not evidence about every FPM pool, Apache instance, container or replica.

For a managed host, ask:

Have CVE-2026-109618 and CVE-2026-109619 been fixed in the PHP runtime serving our site? Which package or build contains the fix, and have all relevant workers been restarted or replaced?

This makes the response auditable without asking a website owner to diagnose engine internals.

If you cannot patch immediately

CERT-EU recommends considering isolation of internet-facing applications from public networks until the fix is applied and verified. It also emphasizes that temporary measures cover specific paths and do not make an installation safe. CERT-EU advisory

Choose interim controls with the operator responsible for that environment. Avoid copying a configuration change without understanding its availability effects and the attack paths it does not address.

What developers can take from this

Our practical interpretation of the published research is:

Review failure paths. Ask which state remains visible when initialization stops halfway through.
Keep discovery and proof separate. A suspicious pattern, a crash and demonstrated RCE provide different levels of evidence.
Make runtime ownership explicit. Application maintenance and runtime maintenance need named owners and separate verification.
Close the deployment loop. “The fix exists” and “our serving processes use it” are different milestones.

For this incident, prioritize patching and verifying the PHP deployment. A change of programming language is a separate architectural decision.

Need help with the PHP runtime behind your website? Contact TechWebster to discuss your setup and next steps.

This article summarizes the linked primary disclosures and separates reported research from our operational recommendations. We have not independently reproduced the exploits. Recheck the official advisories before applying changes, as guidance may evolve.

5 SEO Checks to Run Before Launching Your Website

Tech Webster — Mon, 19 Oct 2026 07:56:49 +0000

Your website loads. The layout works on mobile. The forms submit correctly.

Before you announce the launch, there’s another check worth making: what does your production site tell search engines—and what happens when someone shares its URL?

A leftover indexing directive or a canonical pointing to staging can be easy to miss during visual testing.

I’m Ashirbad, CEO of TechWebster. We built SEO By TechWebster to make these checks easier. It’s a free tool that checks public URLs without requiring an account.

Whether you use an analyzer or inspect your pages manually, here are five checks to include in your launch process.

1. Check whether production pages allow indexing

A staging environment might intentionally include:

<meta name="robots" content="noindex">

That becomes a problem if it reaches a production page you want people to find through search.

Check both the page’s robots meta tag and the X-Robots-Tag response header for unintended indexing restrictions.

Also review robots.txt, but remember that crawling and indexing are different. Blocking a URL in robots.txt can prevent Google from reading its noindex directive; it does not reliably keep the URL out of search results. Google’s robots documentation explains how these controls interact.

To inspect the response headers from a normal GET request, run:

curl -sS -D - -o /dev/null https://yoursite.com

Look for an X-Robots-Tag header. In your browser, view the page source and search for noindex; check the rendered HTML too if your app changes metadata with JavaScript.

Before launch: verify the settings on the deployed URL, including any rules added by your hosting platform. If you have access to the site’s Search Console property, use Google Search Console’s URL Inspection to inspect Google’s indexed information and run a live test.

2. Give each important page a useful title and description

Check for placeholder titles, missing descriptions, and metadata copied across unrelated pages.

Compare:

<title>Home</title>

With something more descriptive:

<title>Custom Web Development | Example Studio</title>

The second version helps someone understand the page before opening it.

Write a description that accurately summarizes that particular page, too. Your homepage, services page, and product page serve different purposes.

Google can generate different title links and snippets, so these fields are inputs rather than a guaranteed preview. Its developer SEO guide recommends descriptive titles and meta descriptions.

Before launch: inspect several important routes, rather than checking only the homepage.

3. Make sure canonical URLs point to the right pages

A canonical identifies your preferred URL when similar or duplicate versions exist.

For example:

<link
  rel="canonical"
  href="https://example.com/services/web-development"
/>

Check for:

References to a staging domain.
HTTP URLs when production uses HTTPS.
Every page pointing to the homepage.
Multiple conflicting canonical tags.

The goal is to give search engines consistent information about your preferred URLs. Google’s JavaScript SEO guidance also covers canonical handling.

Before launch: open a few nested pages, view their source, and search for rel="canonical". Confirm each canonical is intentional.

4. Check the preview people will share

Launch day often means sharing a link through LinkedIn, messaging apps, and other social platforms.

Review your Open Graph and social-card metadata:

<meta property="og:title" content="Example Studio">
<meta
  property="og:description"
  content="Custom websites and applications for growing businesses."
>
<meta
  property="og:image"
  content="https://example.com/social-preview.jpg"
>
<meta name="twitter:card" content="summary_large_image">

Make sure the image URL is public, loads successfully, and points to the intended asset.

Before launch: test a real share preview with LinkedIn’s Post Inspector. Platforms may cache older metadata, so inspecting your HTML alone doesn’t confirm what someone will see.

5. Review discovery files and page structure

Finish with a few checks that are easy to overlook:

Does robots.txt allow access to the public sections you want crawled?
Does your sitemap contain the intended production URLs?
Do headings describe the content in a sensible order?
Do informative images have meaningful alternative text?
If you include JSON-LD, does it parse correctly and describe the visible content?

Not every page needs every type of structured data. Choose markup that actually applies.

Before launch: review warnings in context. A checklist score is useful for finding things to inspect; it isn’t a prediction of search rankings.

A repeatable launch workflow

My suggested process is:

Deploy to the production URL.
Check the homepage and key landing pages.
Fix unintended indexing restrictions and incorrect metadata.
Test social previews.
Run the checks again after deploying fixes.

SEO By TechWebster brings metadata, social cards, discovery files, headings, image alt text, and JSON-LD checks into one report, with suggested fixes.

Use it as an initial review alongside browser testing and Google Search Console. A passing report doesn’t guarantee indexing or rankings.

What’s one SEO detail you always check before shipping a website?

JavaScript Syllabus for Beginners: A Step-by-Step Roadmap

Tech Webster — Sun, 18 Oct 2026 18:22:09 +0000

Know a little HTML and CSS, but want your pages to do more? JavaScript is the next step. It lets you respond to clicks, work with forms, update content, and bring data into a page.

There is a lot to learn, so we have put the topics in an order you can follow. Start with the basics, try the small exercises along the way, and use the projects to see how the pieces fit together.

Before You Start

You should be able to create a simple HTML page, add a stylesheet, use links and form controls, and work with files and folders. You do not need previous JavaScript experience. If those foundations are new, start with our HTML syllabus and CSS syllabus.

The Learning Order

Stage	Sections	Try this before moving on
1. Language fundamentals	1–11	Write a small calculator and filter a list of product objects without copying a solution.
2. Browser interaction	12–14	Build a counter you can use with a keyboard and handle a form submission.
3. Modern JavaScript and data	15–22	Save a task list locally and fetch data with loading and error messages.
4. Projects and next steps	23–24	Finish a small project, explain your code, and fix a bug using developer tools.

Work through the sections in order. If an exercise feels difficult, spend a little more time on that topic before moving on.

1. Introduction to JavaScript

What JavaScript does in a browser
How HTML, CSS, and JavaScript work together
Browser JavaScript versus server-side JavaScript
Examples: menus, counters, forms, and live search

2. Setting Up Your Workspace

A code editor and a modern browser
Opening the browser console
Connecting an external script to an HTML page
Running your first script and reading its output

Practice: display a welcome message in the console.

3. Syntax, Variables, and Comments

Statements, expressions, and comments
Declaring variables with let and const
Reassigning values and choosing clear names
Recognizing var when reading older code

4. Data Types

Strings, numbers, booleans, undefined, and null
An introduction to BigInt and Symbol
Using typeof and recognizing its limitations
Understanding that typeof null returns "object"

5. Operators and Type Conversion

Arithmetic, assignment, and comparison
Strict equality with === and !==
Logical operators and truthy/falsy values
Explicit conversion with Number, String, and Boolean

6. Working with Strings

Quotes and template literals
String length and accessing characters
Trimming, searching, and replacing text
Combining values into useful messages

7. Conditions and Decisions

if, else if, and else
switch statements
Conditional expressions
Combining conditions clearly

Practice: show a different message depending on a user's score.

8. Loops

for and while loops
Iterating over values with for...of
Using break and continue
Avoiding infinite loops

9. Functions and Scope

Function declarations and expressions
Parameters, arguments, and return values
Arrow functions
Global, function, and block scope

Practice: write a function that calculates a shopping-cart total.

10. Arrays

Creating arrays and accessing items
Adding, updating, and removing items
Iterating with forEach
Transforming and searching with map, filter, and find

11. Objects

Properties, values, and methods
Reading and updating properties
Objects inside arrays
Destructuring and spread syntax

Practice: represent a list of products using an array of objects.

12. The Document Object Model (DOM)

How JavaScript interacts with a page
Selecting elements
Updating text, attributes, and classes
Creating, inserting, and removing elements

13. Events and User Interaction

Registering event listeners
Handling clicks, typing, and changes
Reading the event object
Default behavior and basic event bubbling

Practice: build a button that increases a visible counter.

14. Forms and Input

Reading input values
Handling form submission
Required fields and helpful validation messages
Converting text input when numbers are needed

Browser validation improves usability, but it does not replace server-side validation.

15. Organizing Code with Modules

Splitting related code into separate files
Exporting and importing functions
Using module scripts in the browser
Keeping responsibilities small and clear

16. Working with JSON

Objects versus JSON text
Converting with JSON.stringify
Parsing with JSON.parse
Handling invalid JSON

17. Browser Storage

localStorage and sessionStorage
Saving, retrieving, and removing values
Serializing arrays and objects as JSON
Understanding that browser storage is local, not cloud sync

Do not store passwords or private API keys in browser storage.

18. Asynchronous JavaScript

Synchronous versus asynchronous work
Callbacks and timers
A beginner introduction to the event loop
Understanding why a result may arrive later

19. Promises and Async/Await

Pending, fulfilled, and rejected promises
Chaining with .then and .catch
Writing asynchronous functions
Handling failures with try...catch

20. Fetching Data from an API

Making a request with fetch
Checking the HTTP response status
Reading JSON responses
Showing loading, empty, success, and error states

A completed request can still return an HTTP error. Check the response before treating it as successful. Keep private API keys out of browser code.

21. Debugging and Error Handling

Reading syntax and runtime errors
Using console messages and breakpoints
Inspecting variables and network requests
Fixing one problem at a time

22. Building Usable Interactions

Using real buttons and labeled form fields
Supporting keyboard interaction
Keeping focus and status messages understandable
Using textContent for plain text instead of inserting untrusted HTML

23. Practice Projects

Build these in order, adding one feature at a time:

Counter: increase, decrease, and reset a number.
To-do list: add tasks, mark them complete, delete them, and save them locally.
API-powered directory: fetch public data, display results, add search, and handle loading and errors.

Explain how your project works and test both normal input and unexpected input.

24. What to Learn Next

After you can build and debug a small project independently, explore:

Closures, this, and prototypes
Automated testing and deeper asynchronous patterns
Node.js for backend development
A frontend framework such as React

You do not need to rush into a framework. A strong understanding of JavaScript makes the next step easier.

How to Practice

Read a topic, write a small example, change it, and observe the result. Revisit earlier projects as you learn new ideas. Your pace will depend on your experience and practice time; finishing the list matters less than understanding what you build.

A Few Common Questions

What JavaScript topics should a beginner learn first?

Start with variables, data types, operators, strings, conditions, loops, functions, arrays, and objects. Then use those ideas with DOM manipulation and events before moving into promises, async/await, and API requests.

Do I need HTML and CSS before learning JavaScript?

You can learn the core language separately, but basic HTML and CSS will help with the browser projects here. They let you see what your scripts are changing.

How long does it take to learn JavaScript?

That depends on your programming background, how often you practice, and what you want to build. Try the exercises and projects as you go. Being able to explain your code and fix a bug tells you more than the number of topics you have checked off.

When should I learn React or Node.js?

Begin after you can work with functions, arrays, objects, modules, and asynchronous code. For React, also practice DOM events and state changes in a small browser project. For backend work, continue with our Node.js learning roadmap. You can return to deeper language topics while building.

Helpful Resources

Use these resources alongside your practice:

MDN JavaScript fundamentals curriculum — learning outcomes and topic references.
MDN beginner JavaScript lessons and challenges — explanations, exercises, and browser projects.
The Modern JavaScript Tutorial — detailed language and browser tutorials.
JavaScript developer roadmap — a broader map to revisit as you progress.

Related TechWebster Roadmaps

Which JavaScript topic would you like us to explain next with a hands-on example?

Node.js Syllabus for Beginners 🚀 | Complete Backend Roadmap

Tech Webster — Sun, 12 Jul 2026 16:32:43 +0000

Node.js Syllabus for Beginners 🚀

If you're planning to become a Backend Developer, Full Stack Developer, or JavaScript Developer, learning Node.js is one of the best places to start.

This beginner-friendly roadmap covers everything from installing Node.js to building REST APIs with Express and MongoDB.

Whether you're a student or someone switching careers, this syllabus provides a structured learning path to help you become a Node.js developer.

Let's begin! 🚀

1. Introduction to Node.js

What is Node.js?
Why Node.js?
Features of Node.js
V8 JavaScript Engine
Event-Driven Architecture
Non-Blocking I/O
Real-world Applications

2. Installing Node.js

Download Node.js
Install Node.js
Verify Installation
LTS vs Current Version
Node Version Manager (NVM)

3. Node.js Command Line

node Command
Running JavaScript Files
Node REPL
Useful CLI Options

4. Your First Node.js Program

Hello World
Running Files
Understanding Execution

5. Global Objects

global
console
process
__dirname
__filename

6. Modules

What are Modules?
Built-in Modules
Local Modules
CommonJS
ECMAScript Modules (ESM)
require()
module.exports
import
export

7. NPM (Node Package Manager)

What is npm?
package.json
package-lock.json
Installing Packages
Updating Packages
Removing Packages
npm Scripts
Semantic Versioning

8. File System (fs)

Reading Files
Writing Files
Appending Data
Renaming Files
Deleting Files
Creating Directories
Removing Directories

9. Path Module

path.join()
path.resolve()
dirname
basename
extname
normalize()

10. OS Module

Platform
CPU Information
Memory Information
User Information
Network Interfaces

11. Process Module

process.argv
process.env
process.cwd()
process.exit()
process.pid

12. Buffer

What is Buffer?
Creating Buffers
Reading Buffers
Writing Buffers
Buffer Encoding

13. Events

EventEmitter
Creating Events
Listening Events
Removing Listeners
Custom Events

14. Timers

setTimeout()
setInterval()
clearTimeout()
clearInterval()
setImmediate()
process.nextTick()

15. URL Module

URL Object
URL Parameters
Query Parameters
URLSearchParams

16. HTTP Module

Creating HTTP Server
Request Object
Response Object
HTTP Methods
HTTP Status Codes
HTTP Headers

17. Streams

Readable Streams
Writable Streams
Duplex Streams
Transform Streams
Piping Streams

18. Working with JSON

JSON.parse()
JSON.stringify()
Reading JSON Files
Writing JSON Files

19. Asynchronous Programming

Synchronous vs Asynchronous
Callback Functions
Promises
Async / Await

20. Event Loop

What is Event Loop?
Call Stack
Callback Queue
Microtask Queue
Execution Flow

21. Error Handling

try...catch
throw
Custom Errors
Handling Async Errors

22. Environment Variables

process.env
.env Files
Configuration Management

23. Working with File Streams

Reading Large Files
Writing Large Files
Stream Piping

24. Child Process Module

exec()
spawn()
fork()
execFile()

25. Crypto Module

Random Bytes
Hashing
Creating Hashes
Encryption Basics

26. Util Module

promisify()
format()
inspect()
inherits()

27. Debugging Node.js

console.log()
Node Inspector
Debugging with VS Code
Error Stack Traces

28. Performance

Blocking vs Non-Blocking Code
Memory Usage
Performance Monitoring
Best Practices

29. Node.js Best Practices

Folder Structure
Code Organization
Modular Programming
Error Handling
Logging