DEV Community: Rashedin | FullStack Developer

How Programming Languages Are Converted into Machine Code

Rashedin | FullStack Developer — Wed, 10 Dec 2025 15:09:36 +0000

Programming is pretty much fun! We can do amazing things with programming, such as building a calculator, building a website, or even building an AI Agent (or LLM, you get the idea). But machines don't understand these programming languages directly. They only understand binary code — the 0s and 1s. So each programming language needs to be compiled or interpreted first.

But there’s more complexity. Not all machines, operating systems, or chips understand the same binary code. That’s why a Windows program cannot run on macOS or Linux. Each platform “speaks” a different machine language.

Let’s break this down in the simplest way possible.

🧠 Why Machine Code Is Different on Windows, macOS, and Linux

When you compile a program directly to machine code, the compiler must target:

A specific CPU type (Intel, AMD, ARM)
A specific operating system (Windows, macOS, Linux)

If either one is different, the binary will not run.

1. Different CPUs Understand Different Instructions

Every CPU has its own instruction set.

Intel/AMD use x86 / x86-64
Apple M1/M2 use ARM64
Many Android devices also use ARM

Machine code is literally a list of instructions for the CPU.

So:

❌ A Windows program compiled for an Intel x86 CPU will not run on a Mac with an ARM CPU.

The CPU simply does not understand those instructions.

2. Different Operating Systems Provide Different System Calls

Even if the CPU is the same (example: Intel), Windows and macOS give programs different ways to talk to the system.

For example:

Windows uses APIs like CreateFile()
macOS/Linux use open()

So:

❌ Even if the CPU matches, a Windows program won’t run on macOS

because it calls Windows-specific functions that macOS doesn’t have.

3. Different System Libraries

Windows uses .dll files.

macOS uses .dylib files.

Linux uses .so files.

Programs depend on these during execution.

❌ A Windows .exe cannot find the libraries it needs on macOS.

So it fails.

🍎 Easy Analogy: Why It Doesn’t Work

Imagine you write a recipe:

In English
Using tools found only in a Windows kitchen

Now you give it to:

A Mac chef
In a Mac kitchen

The chef sees:

Steps written in a different language (CPU instructions mismatch)
Tools that don’t exist in their kitchen (OS system calls mismatch)
Ingredients stored differently (system libraries mismatch)

So the chef simply cannot follow the recipe.

That’s why you must compile programs separately for Windows, macOS, and Linux.

1. Direct Compilation to Machine Code

Some languages compile straight to machine code for a specific CPU and OS.

Examples:

C, C++, Rust, Go

Flow:

Source Code → Compiler → Machine Code (Windows / macOS / Linux)

Pros: Fastest

Cons: Needs a separate binary for each platform

2. Bytecode: A Middle Step

Some languages convert your code into bytecode, a portable, OS-independent format.

Examples:

Java, Kotlin, C#, Python

Flow:

Source → Bytecode → Virtual Machine (VM) → Machine Code

Pros: Runs on any OS with a VM

Cons: Slightly slower

3. Interpreted + JIT Compilation

Some languages are interpreted but use JIT to speed things up.

Examples:

JavaScript, Python (PyPy), Ruby

Flow:

Source → Interpreter/JIT → Machine Code

4. Transpiled Languages

Some languages convert to another language first.

Examples:

TypeScript → JavaScript → JIT → Machine Code

Summary Table

Approach	Languages	How They Run
Direct Compilation	C, C++, Rust, Go	Machine code for a specific CPU + OS
Bytecode + VM	Java, C#, Python	Bytecode → VM → Machine Code
Interpreted + JIT	JS, Python, Ruby	Interpreter/JIT → Machine Code
Transpiled	TypeScript, Elm	Transpile → JS → JIT → Machine Code

Key Takeaway:

We write code in human-friendly languages, but CPUs and operating systems only understand their own binary “dialects.” Compilers, interpreters, VMs, and JIT help translate our code into something the machine can run.

express-error-toolkit — the One NPM Package to Handle All Express Errors

Rashedin | FullStack Developer — Tue, 30 Sep 2025 10:01:50 +0000

Error handling in Express has always been repetitive:

writing the same notFoundHandler, globalErrorHandler, asyncHandler, and custom error classes across every project.

Even with libraries like express-async-errors, you still end up wiring things manually — and none of them improve the DX in the terminal.

That’s why I built — 🔗 express-error-toolkit

✨ Core Features

✅ Pre-built middleware: globalErrorHandler, notFoundHandler
✅ Type-safe custom error classes (e.g. NotFoundError, BadRequestError)
✅ Simple asyncHandler utility to avoid try-catch blocks
✅ httpError() helper for one-liner errors
✅ Colorful, readable console logs (no chalk needed)
✅ Works with both CommonJS & ESM
✅ Fully configurable (via .env or code)
✅ Built with DX in mind

📖 Detailed guide, usage examples & console previews here:

➡️ Read the full article

If you find it useful, please consider giving it a ⭐ on GitHub 💙

🔗 GitHub Repo

GPT-5 vs GPT-4: Why Awareness Beats Accuracy

Rashedin | FullStack Developer — Tue, 02 Sep 2025 10:51:53 +0000

We’ve all heard the buzz — “GPT-5 is here, and it’s way more powerful.”

But is that really the case? And more importantly, what makes it different in practice?

Let’s dive in.

When One Wrong Assumption Breaks Everything

Suppose you’re building a financial projection.

Your inputs are solid, but GPT-4 makes just one wrong assumption in the middle — say it assumes a 15% tax rate instead of 12%.

Because of that tiny slip:

Profit margin → wrong
Cash flow forecast → wrong
Final valuation → wrong

The bigger issue? GPT-4 wouldn’t admit uncertainty. It would confidently declare, “Yes, this is correct,” even though the foundation was shaky.

This is exactly where GPT-5 changes the game.

From Blind Trust → Informed Trust

GPT-5 doesn’t just generate answers, it audits them.

It verifies steps, surfaces assumptions, and — when unsure — explicitly flags uncertainty.

That means in critical workflows (finance, medicine, law, engineering), you shift from blind trust to informed trust.

In practice:

GPT-4 gives you an answer.
GPT-5 gives you an answer plus reasoning, checks, and “confidence markers.”

This isn’t a small UX improvement — it changes the way you design systems around AI.

Deep Reasoning: From Lottery to Reliability

With GPT-4, deep reasoning felt like rolling dice.

Sometimes you’d get a thoughtful breakdown, other times just a shallow surface-level response.

That inconsistency is deadly for:

System architecture (where missing one detail means downtime)
Research (where assumptions must be transparent)
Legal or compliance writing (where precision is non-negotiable)

GPT-5, by contrast, applies something closer to judgment.

Example: Designing a Data Pipeline

Let’s say you ask:

“Design a data pipeline for processing 1M IoT events per second with fault tolerance.”

GPT-4’s answer:

A neat diagram — source → processing → storage → dashboard.

Useful, but shallow.
GPT-5’s answer:

It walks through the entire reasoning chain:
- Where load balancing should happen during ingestion.
- How to implement backpressure handling.
- Which nodes replay data during a fault.
- What thresholds trigger real-time alerts.

Instead of a static diagram, you get a living blueprint with rationale.

That’s the difference between a junior engineer sketch and a senior architect review.

Why Awareness > Accuracy

Here’s the key shift:

GPT-4 = Tries to be right.
GPT-5 = Tries to be right *and accountable*.

It’s not that GPT-5 never makes mistakes (it does).

But when it does, you can actually trace why — because it exposes reasoning and assumptions.

And in high-stakes work, knowing why is just as critical as knowing the answer.

Where This Will Matter Most

Expect GPT-5 to make the biggest impact in domains where reasoning transparency is non-negotiable:

Finance → risk modeling, portfolio forecasting.
Healthcare → diagnostic reasoning, treatment planning.
Engineering → system design, performance optimization.
Law & Policy → drafting, compliance verification.

In other words: any place where a hidden assumption could cost millions, or even lives.

Closing Thoughts

GPT-4 was a great assistant.

GPT-5 feels more like a colleague who explains their thinking out loud.

That shift — from raw output to accountable reasoning — is what makes GPT-5 not just an upgrade, but a platform shift in how we work with AI.

If you’ve already experimented with GPT-5, I’d love to hear your stories.

Did it help you catch something GPT-4 would’ve missed? Drop your experiences in the comments below 👇

Handle all Express errors effortlessly with a single npm package. Includes built-in globalErrorHandler, notFoundHandler, asyncHandler, custom error classes, and more. The colored console adds a cherry on top, making DX smoother.

Rashedin | FullStack Developer — Mon, 01 Sep 2025 11:30:51 +0000

Rashedin | FullStack Developer

Aug 28 '25

express-error-toolkit — the One NPM Package to Handle All Express Errors

#npm #express #dx #errors

Comments 8

3 min read

express-error-toolkit — the One NPM Package to Handle All Express Errors

Rashedin | FullStack Developer — Thu, 28 Aug 2025 10:25:45 +0000

As a full-stack developer, I’ve spent countless hours building robust backend applications with Express.js. While Express is lightweight and unopinionated — exactly what makes it great — error handling has always been repetitive and tedious.

I was tired of copy-pasting the same boilerplate across projects:

✅ Writing notFoundHandler manually
✅ Writing globalErrorHandler for every single project
✅ Wrapping every async function in a try-catch or asyncHandler
✅ Creating CustomApiError, NotFoundError, BadrequestError and other custom errors.
✅ Installing separate libraries like chalk just to make my logs more readable

Even after using popular libraries like express-async-errors or async-error-handler, I still had to manually wire up custom errors and error-handling middleware. And none of them improved the developer experience in the terminal.

So, I built - 🔗 express-error-toolkit — the one package to handle all Express errors.

🧰 What's Included?

This package provides everything you need to handle errors in a production-grade Express app:

✅ Type-safe custom error classes (NotFoundError, BadRequestError, etc.)
✅ Drop-in middleware: globalErrorHandler, notFoundHandler
✅ A clean asyncHandler utility
✅ A httpError() function for custom one-liners
✅ Colorful and readable console logs — no need for chalk or similar
✅ Flexible .env or programmatic configuration
✅ Built-in support for CommonJS and ESM
✅ Designed with DX in mind

🏗 Build Process

The package is written entirely in TypeScript and built with:

tsup — lightning-fast bundler
http-status-toolkit — my own utility, to handle http-status-codes in more human readable way
ANSI escape codes — to create colorful terminal output (no dependencies required)

The idea was to bundle everything in a single utility that you can drop into any Express project, and instantly get a polished, configurable, DX-optimized error system.

⚡ Installation

npm install express-error-toolkit

ℹ️ Requires Node.js version >=14

Make sure you have express installed in your project.

📦 Usage Examples

1. Wrap async route handlers

import { asyncHandler } from 'express-error-toolkit';

app.get('/users/:id', asyncHandler(async (req, res) => 
{throw new Error('User not found');   }) );

2. Use custom errors

import { NotFoundError } from 'express-error-toolkit';  

app.get('/user/:id', (req, res) => 
{throw new NotFoundError('User not found'); });

3. Catch unregistered routes

import { notFoundHandler } from 'express-error-toolkit';

app.use(notFoundHandler);

4. Global error handler

import { globalErrorHandler } from 'express-error-toolkit';  

app.use(globalErrorHandler);

By default, it includes stack trace and logs the error, but removes both when NODE_ENV=production.

🧪 Console Output — Traffic Light Theme

To make debugging more intuitive, express-error-toolkit uses ANSI escape codes to show:

🔴 Error Message in bold red
🟡 Error Details in bold yellow
🟢 Stack Trace in dim green, line-by-line

📸 Console Preview:

Colors are styled without external libraries — just pure ANSI codes

🛠️ Optional Configuration

5. Set Options Globally (Optional)

You can configure the error handling behavior (e.g., hide stack traces, configuring intro line in console, and disable console logging even in development) using either:

✅ Via && `.env`**:

SHOW_STACK=false LOG_ERROR=false

✅ Or directly in your code:

import { setErrorOptions } from 'express-error-toolkit'; 
 setErrorOptions({showStack: false, logError: false, introLine: false });

This overrides the default behavior (based on NODE_ENV or .env file).

📚 Utility Helpers

import { httpError, StatusCodes } from 'express-error-toolkit';

throw httpError('Something broke!', StatusCodes.BAD_REQUEST);

import { isCustomAPIError } from 'express-error-toolkit';  

if (isCustomAPIError(err)) {   console.log(err.statusCode, err.message); }

🔥 Why It Improves Developer Experience

🧼 Cleaner, centralized error handling
⌛ Saves hours of repetitive setup
🧠 Human-readable, styled error logs
🚫 No unnecessary dependencies (like chalk)
⚙️ Easily configurable — no lock-in, no magic

📁 Output

The build generates:

dist/index.cjs.js — CommonJS
dist/index.esm.js — ESM
dist/index.d.ts — TypeScript types

💼 Ideal For

Full-stack teams building REST APIs
Developers who care about clean DX
Production-ready Express.js apps
Anyone tired of writing error handlers over and over

🧭 Want to Explore?

📃 License

MIT © Rashedin Islam

🙌 Acknowledgements

http-status-toolkit
ANSI escape codes — for stylish logging without bloat

Built with ❤️ and TypeScript by Rashedin Islam

If you find it useful, consider giving it a ⭐ on GitHub.

From ThePracticalDev to DEV: The Story Behind Our Favorite Developer Community

Rashedin | FullStack Developer — Thu, 21 Aug 2025 12:06:31 +0000

If you’ve been a developer for a while, chances are you’ve read, shared, or even written something on DEV (dev.to). But do you know how it all started? Let’s take a little trip back in time and see how this amazing community was born, who created it, and why it’s still one of the best places for developers today.

👶 The Humble Beginning

It all started in 2014 with a single Twitter account called The Practical Dev.

Ben Halpern, a developer who loved sharing coding tips and memes, created the account. His tweets were short, funny, and relatable for developers. The account quickly grew and became a favorite spot for coding humor and useful programming wisdom.

But Ben didn’t stop there. He had a bigger dream:

👉 What if there was a place on the internet where developers could share articles, learn from each other, and grow together?

🚀 The Birth of DEV

In January 2017, that dream came true. Together with Jess Lee and Peter Frank, Ben launched DEV Community (dev.to).

The idea was simple yet powerful:

A blogging platform for developers, by developers.
A place where everyone — from beginners to experts — could write, share, and learn without fear of judgment.
A community where helpfulness and kindness mattered more than “who’s the smartest.”

🌟 Major Milestones

Here are some of the big moments in DEV’s journey:

2017 → DEV officially launched 🎉
2018 → Rapid growth as thousands of developers joined, sharing tutorials, career advice, and personal stories.
2019 → DEV turned into Forem, an open-source platform. This allowed other communities (not just developers) to build their own “DEV-like” spaces.
2020 → DEV raised funding to grow even further, while keeping the platform free for users.
Today → DEV has millions of members worldwide 🌍. It’s one of the biggest and friendliest developer communities out there.

💡 Why DEV is Special for Developers

There are many blogs and forums out there, but DEV stands out because:

Friendly culture → The community is welcoming. Even if you’re new to coding, you won’t feel out of place.
Open-source spirit → DEV itself is built with open-source software (Forem). Developers can contribute to the platform itself!
Diverse content → From JavaScript to Rust, from beginner tips to advanced system design, you’ll find content for every level.
Networking & growth → Many developers land jobs, collaborators, or mentors through DEV.

👩‍💻 The Founders

Let’s not forget the people who made this happen:

Ben Halpern → The original creator, who started with ThePracticalDev Twitter.
Jess Lee → Co-founder, helped turn the vision into a real product.
Peter Frank → Co-founder, focused on building and scaling the community.

Their shared mission was clear: make the developer world more welcoming, supportive, and fun.

🎉 The DEV We Know Today

Fast forward to today — DEV is more than a blogging platform. It’s a movement. A place where developers don’t just share code, but also share experiences, failures, lessons, and victories.

From small side projects to big career moves, DEV has been there for developers at every step.

❤️ Final Thoughts

The journey from The Practical Dev Twitter account to the DEV Community we know today is truly inspiring. It reminds us that with a simple idea, kindness, and a bit of code, you can create something that changes millions of lives.

So next time you publish an article here, remember — you’re part of a story that started in 2014 with a single tweet. And the best part? This story is still being written — by us. ✨

👉 What was your first DEV post? Or your favorite memory here? Share it in the comments — let’s celebrate this amazing community together!

GPT-4 vs GPT-5: From a Developer’s Perspective

Rashedin | FullStack Developer — Tue, 19 Aug 2025 10:36:30 +0000

GPT-5 is here — and as a developer, you might be wondering: "What’s really different, and does it matter for my work?"

Let’s break it down in plain English.

1. A Developer Example

Imagine you ask:

"Build me an e-commerce site."

What GPT-4 would do

It would create a functional site with product listings, a cart, and checkout.

But… it might skip deeper details like:

Secure payment integration
Rate limiting for API calls
How to handle heavy traffic during sales

What GPT-5 does instead

It goes beyond the basics and starts thinking like a senior engineer:

Chooses the right CDN for product images
Adds retry logic if a payment API fails
Decides between real-time or batch inventory updates
Plans database indexing for scaling to millions of users

Result: You don’t just get working code — you get a deploy-ready, well-structured, and edge-case-handled codebase.

2. A Non-Developer Example

Let’s say you ask:

"Make me a report."

GPT-4’s output

You’d get a report with data, charts, and summaries — but you might find:

Some data is wrong
Charts have mismatched scales
Conclusions lack context

GPT-5’s output

It works more carefully:

Verifies the data
Detects mismatches in charts
Writes conclusions with clear context
If data is uncertain, it warns you:

"I’m not confident about this section — needs verification."

3. The Reasoning Upgrade

This is where GPT-5 really shines.

With GPT-4, multi-step reasoning could go wrong if one step had an error — leading to hallucinations.

GPT-5 changes the process:

Works step-by-step
Cross-checks its own work
If unsure, it tells you instead of guessing

📊 OpenAI’s data:

Hallucinations: ↓ 45%
Long-context reasoning accuracy: 89%

4. Memory Boost

With GPT-4, long chats could lose context — it would “forget” things from earlier in the conversation.

GPT-5 now supports 256k tokens.

That means it can remember:

A 4–5 chapter book
Weeks of chat history
A large codebase — without losing track of variables, dependencies, or previous instructions

5. In Short

GPT-4 → An assistant you had to guide constantly.
GPT-5 → A partner that understands the deeper problem, builds solutions accordingly, and adapts — knowing when to go deep and when to keep it short.

Final Thoughts

If GPT-4 was like a junior dev who needed hand-holding, GPT-5 feels more like a tech lead — one who thinks about scalability, security, and long-term impact before writing a single line of code.

For developers, this means less micromanaging, fewer corrections, and more ready-to-deploy results.

A lightweight, TypeScript-friendly alternative to http-status-codes with ESM support and localization in 10+ languages. Feedback welcome!

Rashedin | FullStack Developer — Tue, 29 Jul 2025 10:26:07 +0000

Rashedin | FullStack Developer

Jul 21 '25

Why I Built http-status-toolkit — A Better Alternative to http-status-codes

#npm #node #dx #webdev

Comments 10

2 min read

Why I Built http-status-toolkit — A Better Alternative to http-status-codes

Rashedin | FullStack Developer — Mon, 21 Jul 2025 14:40:46 +0000

In my backend projects, I got tired of constantly writing raw status code numbers like:

res.status(200)
res.status(404)

It works — but it's not expressive. And honestly, it makes code harder to read and maintain over time. Like many developers, I wanted something cleaner, more intuitive, and easier to understand at a glance.

So I looked into existing solutions.

🚫 First I Tried `http-status-codes`

http-status-codes is a well-known package. With it, you can write:

import { StatusCodes } from "http-status-codes";
res.status(StatusCodes.OK);

Much better than hardcoded numbers — but it came with a few drawbacks:

❌ No ESM support
❌ No localization
❌ No detailed reason phrases
❌ Separate type definitions (@types/http-status-codes)
❌ No localization or i18n support

It didn’t quite solve my problems. So I kept looking.

😐 Then I Tried `http-status`

http-status is another popular choice. It does support both CommonJS and ESM out of the box — nice. But it still had some limitations:

❌ No localization or i18n support
❌ Only short, generic messages
❌ No detailed descriptions for each code
❌ Lacks modern TypeScript typings
❌ Not tree-shakable

So again — better than nothing, but not enough.

✅ So I Built `http-status-toolkit`

I created http-status-toolkit to solve all of the above. It’s modern, lightweight, and built for real-world developer needs.

Here’s what it offers:

✅ TypeScript-first with full type safety and autocompletion
✅ ESM and CommonJS support
✅ Short + detailed human-readable messages
✅ Localization support in 10+ languages
✅ Tree-shakable and subpath exportable
✅ Built with tsup for clean, modern builds
✅ Extremely lightweight: ~4.1 KB minified / ~2.2 KB gzipped

🧪 Example Usage

import { StatusCodes, getStatusMessage } from "http-status-toolkit";

console.log(StatusCodes.OK); 
// 200

console.log(getStatusMessage(StatusCodes.NOT_FOUND)); 
// "Not Found"

// Detailed message
import DetailedMessages from "http-status-toolkit/messages-detailed";
console.log(getStatusMessage(StatusCodes.NOT_FOUND, { variant: DetailedMessages }));
// "Not Found: The requested resource could not be found but may be available in the future."

// Localized message (Bengali)
import BengaliMessages from 'http-status-toolkit/messages-bn';
console.log(getStatusMessage(StatusCodes.NOT_FOUND, { variant: BengaliMessages }));
// Output: (Not Found message in Bengali)

📊 Feature Comparison

📦 Bundle size is based on Bundlephobia

💡 Why It Matters

http-status-toolkit improves:

Readability: No more res.status(403) — use StatusCodes.FORBIDDEN
Clarity: Choose between short, detailed, or localized messages
Internationalization: Easily display meaningful error responses in your users' languages
Developer Experience: Clean API, tree-shakable, and TypeScript-native

🧭 Want to Explore?

Built with ❤️ and TypeScript by Rashedin Islam

If you find it useful, consider giving it a ⭐ on GitHub.

Web Dev Origins: The History of npm

Rashedin | FullStack Developer — Mon, 14 Jul 2025 11:54:31 +0000

Whether you're just starting out with JavaScript or leading enterprise-grade frontend architecture, you're almost certainly using npm — the Node Package Manager — every day.

But do you know why npm was created in the first place?
What problems did it solve?
And why did each major version change the way we code?

This post is a deep dive into npm’s journey, covering:

Why it was created
What developer pain points it solved
What each major version introduced, and why was npm Created?

In 2009, Node.js brought JavaScript to the server — a huge step forward. But there was a serious problem:

❌ There was no reliable way to share and reuse Node.js code across projects.

Developers were forced to:

Download ZIP files manually
Copy-paste utility code across projects
Clone GitHub repos without versioning control

Isaac Z. Schlueter — a Node.js user himself — found this situation frustrating. So, in early 2010, he created a simple CLI tool to solve it: npm.

📈 Major Milestones in npm’s Journey

Let’s walk through npm’s evolution and how each milestone was a direct response to real-world issues.

🧱

2010 — npm CLI Launched

Problem: Node.js had no default package manager.
Solution: Isaac Z. Schlueter built npm, introducing:
- A central registry
- A CLI tool (npm install)
- A metadata file: package.json
Impact: JavaScript finally had a structured, versioned dependency system.

🏢 2014 — npm, Inc. Founded

Problem: npm was growing too fast for one person to manage.
Solution: Isaac created npm, Inc. to manage the ecosystem, registry, and future development.
Impact: Provided stability, funding, and a business model (free for public, paid for private).

💥 2016 — The left-pad Incident

Problem: A tiny package (left-pad) was unpublished and broke thousands of apps.
Solution: npm changed its policy — popular packages couldn’t be unpublished easily.
Impact: Forced the ecosystem to consider the importance of dependency stability.

📘 2017 — npm v5: Locking Dependencies with package-lock.json

Problem: Developers were getting inconsistent installs due to semver ranges in package.json.
Solution: Introduced package-lock.json:
- Locks exact versions of every dependency
- Ensures repeatable installs on any machine
Impact: Faster CI builds, consistent production environments, and easier debugging.

🔐 2018 — npm v6: Security Comes First

Problem: Security vulnerabilities in packages were going undetected.
Solution: Introduced npm audit, which:
- Scans installed packages for known issues
- Suggests or applies fixes
Impact: Security became an essential part of the development process.

🤝 2020 — GitHub Acquires npm

Problem: npm’s infrastructure and governance were stretched thin.
Solution: GitHub (owned by Microsoft) acquired npm, promising to keep it open and free.
Impact:
- Stability for the registry
- Deeper CI/CD integrations
- Better security workflows via GitHub Actions

🧰 2021 — npm v7: Workspaces and Peer Dependency Fixes

Problem 1: Managing monorepos was difficult.
Problem 2: Peer dependency conflicts were common.
Solution:
- ✅ Workspaces: Native monorepo support
- 🔁 Auto-install peer dependencies
- 📘 Lockfile v2: Smarter resolution and better VCS diffs
Impact: npm became more reliable for large-scale projects and package ecosystems.

⚡ 2022 — npm v8: Speed & Audit UX

Problem: The CLI was slower and audit reports were verbose.
Solution:
- Enhanced performance and caching
- Improved audit reporting UX
- Fine-grained configuration options
Impact: Developers got a faster, cleaner, more configurable CLI experience.

🔄 2023–2025 — Backend Scaling, CI Integration & Registry Stability

Problem: The registry needed to scale, CI/CD needed tighter npm integration.
Solution:
- Global edge caching for faster package fetches
- Smarter vulnerability resolution in npm audit
- Tighter GitHub Actions integration for npm publish, audit, and scoped packages
Impact: npm became more stable, CI-friendly, and scalable — without introducing another major CLI version.

🧠 Why This Matters

Every version of npm was created to solve real, developer-facing problems — from code sharing and dependency hell to security and monorepo complexity.

If you understand why a tool evolved the way it did, you'll not only use it better — you'll build better systems with it.

npm isn’t just a package manager — it’s the backbone of the modern JavaScript ecosystem.

Say Goodbye to Try-Catch: Smart Async Error Handling in Express

Rashedin | FullStack Developer — Tue, 08 Jul 2025 12:11:53 +0000

📌 This was originally posted on blog.rashedin.dev

When building a backend with Node.js and Express, we're likely using async/await to handle things like database queries or API calls.

But there’s a catch — if we don’t handle errors properly, our server can crash or behave unpredictably. 😬

In this post, you'll learn a clean, scalable way to handle async errors in Express:

Why try-catch in every route is painful
How to fix it with a reusable asyncHandler()
How to simplify this using external libraries
How to use my own package: express-error-toolkit
How to define custom error classes
And how to set up a global error handler

🚨 The Problem With Try-Catch Everywhere

Here’s how we usually handle errors:

app.get('/api/users/:id', async (req, res, next) => {
  try {
    const user = await User.findById(req.params.id);
    if (!user) return res.status(404).json({ message: 'User not found' });
    res.json(user);
  } catch (error) {
    next(error);
  }
});

Repeating this in every route is:

Redundant
Ugly
Easy to forget

Let’s fix that.

✅ Option 1: Write a Custom `asyncHandler`

// utils/asyncHandler.js
const asyncHandler = (fn) => {
  return (req, res, next) => {
    Promise.resolve(fn(req, res, next)).catch(next);
  };
};

module.exports = asyncHandler;

Use it like this:

const asyncHandler = require('../utils/asyncHandler');

app.get('/api/users/:id', asyncHandler(async (req, res) => {
  const user = await User.findById(req.params.id);
  if (!user) throw new Error('User not found');
  res.json(user);
}));

Clean. Reusable. No try-catch.

📦 Option 2: Use a Library (Highly Recommended)

🔹 express-error-toolkit — View on npm

I built this package to make error handling in Express apps much easier. It includes:

An asyncHandler() function
Predefined error classes (NotFoundError, BadRequestError, etc.)
A global error-handling middleware
Clean stack traces in development

Install

npm install express-error-toolkit

Use

const { asyncHandler } = require('express-error-toolkit');

app.get('/api/users/:id', asyncHandler(async (req, res) => {
  const user = await User.findById(req.params.id);
  if (!user) throw new Error('User not found');
  res.json(user);
}));

🧱 Define Custom Error Classes

If you don’t use a package, you can define your own:

// utils/ApiError.js
class ApiError extends Error {
  constructor(statusCode, message) {
    super(message);
    this.statusCode = statusCode;
    Error.captureStackTrace(this, this.constructor);
  }
}

module.exports = ApiError;

Usage:

const ApiError = require('../utils/ApiError');

if (!user) throw new ApiError(404, 'User not found');

Or use express-error-toolkit’s built-in errors

const { NotFoundError } = require('express-error-toolkit');

if (!user) throw new NotFoundError('User not found');

🌍 Global Error-Handling Middleware

Add this at the end of your middleware chain:

app.use((err, req, res, next) => {
  const status = err.statusCode || 500;
  const message = err.message || 'Internal Server Error';

  res.status(status).json({
    success: false,
    message,
    stack: process.env.NODE_ENV === 'production' ? null : err.stack,
  });
});

Or use express-error-toolkit’s built-in handler:

const { globalErrorHandler } = require('express-error-toolkit');

app.use(globalErrorHandler);

🧪 Full Example

const express = require('express');
const mongoose = require('mongoose');
const {
  NotFoundError,
  asyncHandler,
  globalErrorHandler,
} = require('express-error-toolkit');

const app = express();
app.use(express.json());

app.get('/api/users/:id', asyncHandler(async (req, res) => {
  const user = await User.findById(req.params.id);
  if (!user) throw new NotFoundError('User not found');
  res.json(user);
}));

app.use(globalErrorHandler);

app.listen(3000, () => console.log('Server running on port 3000'));

🧠 Final Thoughts

✅ Avoid try-catch in every route using asyncHandler

📦 Use express-error-toolkit for a full-featured, clean setup

🧱 Throw meaningful errors with custom classes

🌍 Catch and format all errors in one global middleware

Follow this approach and your Express backend will be clean, scalable, and production-ready.

DEV Community: Rashedin | FullStack Developer

How Programming Languages Are Converted into Machine Code

🧠 Why Machine Code Is Different on Windows, macOS, and Linux

1. Different CPUs Understand Different Instructions

2. Different Operating Systems Provide Different System Calls

3. Different System Libraries

🍎 Easy Analogy: Why It Doesn’t Work

1. Direct Compilation to Machine Code

2. Bytecode: A Middle Step

3. Interpreted + JIT Compilation

4. Transpiled Languages

Summary Table

express-error-toolkit — the One NPM Package to Handle All Express Errors

✨ Core Features

GPT-5 vs GPT-4: Why Awareness Beats Accuracy

When One Wrong Assumption Breaks Everything

From Blind Trust → Informed Trust

Deep Reasoning: From Lottery to Reliability

Example: Designing a Data Pipeline

Why Awareness > Accuracy

Where This Will Matter Most

Closing Thoughts

Handle all Express errors effortlessly with a single npm package. Includes built-in globalErrorHandler, notFoundHandler, asyncHandler, custom error classes, and more. The colored console adds a cherry on top, making DX smoother.

express-error-toolkit — the One NPM Package to Handle All Express Errors

express-error-toolkit — the One NPM Package to Handle All Express Errors

🧰 What's Included?

🏗 Build Process

⚡ Installation

📦 Usage Examples

1. Wrap async route handlers

2. Use custom errors

3. Catch unregistered routes

4. Global error handler

🧪 Console Output — Traffic Light Theme

📸 Console Preview:

🛠️ Optional Configuration

5. Set Options Globally (Optional)

✅ Via && .env**:

✅ Or directly in your code:

📚 Utility Helpers

🔥 Why It Improves Developer Experience

📁 Output

💼 Ideal For

🧭 Want to Explore?

📃 License

🙌 Acknowledgements

From ThePracticalDev to DEV: The Story Behind Our Favorite Developer Community

👶 The Humble Beginning

🚀 The Birth of DEV

🌟 Major Milestones

💡 Why DEV is Special for Developers

👩‍💻 The Founders

🎉 The DEV We Know Today

❤️ Final Thoughts

GPT-4 vs GPT-5: From a Developer’s Perspective

1. A Developer Example

2. A Non-Developer Example

3. The Reasoning Upgrade

4. Memory Boost

5. In Short

Final Thoughts

A lightweight, TypeScript-friendly alternative to http-status-codes with ESM support and localization in 10+ languages. Feedback welcome!

Why I Built http-status-toolkit — A Better Alternative to http-status-codes

Why I Built http-status-toolkit — A Better Alternative to http-status-codes

🚫 First I Tried http-status-codes

😐 Then I Tried http-status

✅ So I Built http-status-toolkit

🧪 Example Usage

📊 Feature Comparison

💡 Why It Matters

🧭 Want to Explore?

Web Dev Origins: The History of npm

📈 Major Milestones in npm’s Journey

2010 — npm CLI Launched

🏢 2014 — npm, Inc. Founded

💥 2016 — The left-pad Incident

📘 2017 — npm v5: Locking Dependencies with package-lock.json

🔐 2018 — npm v6: Security Comes First

🤝 2020 — GitHub Acquires npm

🧰 2021 — npm v7: Workspaces and Peer Dependency Fixes

✅ Via && `.env`**:

🚫 First I Tried `http-status-codes`

😐 Then I Tried `http-status`

✅ So I Built `http-status-toolkit`

✅ Option 1: Write a Custom `asyncHandler`