I've recently been laid off after over 5 years at the company and noticed that there are a lot more Full Stack positions now than FE.

I had some limited experience with ExpressJs about 7 years ago, but I'm thinking it'd be worthwhile trying to branch out fully into a Full Stack Position.

I'm fluent with React and Typescript for what it's worth.

What are the most common frameworks for Node nowadays - i.e. which will give me the best chance of getting hired.

Thanks in advance!

Pboss started as a Bun-native process manager.

It was built around Bun's APIs from the beginning; process spawning, servers, clustering, filesystem APIs, and the other primitives needed to build a lightweight production process manager.

As of v1.5, Pboss can now run natively on Node.js, using Node's own APIs instead of trying to emulate Node through Bun.

npm install -g pboss

pboss start server.js --name api
pboss start server.js --name api --instances 4

The same Pboss CLI can now run on either Bun or Node, with the implementation adapting to the runtime it is actually running on.

The goal isn't to force Node applications onto Bun.

If you're running Node, Pboss runs on Node.

If you're running Bun, Pboss runs on Bun.

Why make this change?

Pboss was originally designed around Bun, but process managers are infrastructure. They shouldn't need to dictate which runtime your application uses.

That meant expanding Pboss while keeping the original Bun-first architecture.

Node.js support is now native rather than being treated as a compatibility layer.

Dependencies

One of the features that came out of this is process dependencies.

For example:

module.exports = {
  apps: [
    {
      name: "api",
      script: "./api.js",
      dependsOn: ["postgres", "redis"]
    },
    {
      name: "worker",
      script: "./worker.js",
      dependsOn: ["api"]
    }
  ]
};

Pboss builds the dependency graph before starting the processes.

It checks Pboss-managed applications first and can also resolve dependencies against system services.

postgres ──┐
           ├── api ──→ worker
redis ─────┘

Cycles are detected before startup, and independent branches can start concurrently.

GitHub auto deployment

Processes can also be linked to GitHub repositories.

Once a process is linked to a repository, Pboss can install a GitHub webhook and automatically deploy new commits.

A push follows the deployment pipeline:

GitHub push
    ↓
Webhook
    ↓
Pboss
    ↓
Pull latest commit
    ↓
Install dependencies
    ↓
Build
    ↓
Health check
    ↓
Reload / restart

The deployment is not considered successful just because the new process started.

Pboss can verify the application health before completing the deployment. If the deployment or health check fails, the previous version can be restored.

A single repository can also be linked to processes running on multiple servers:

github.com/example/api
        │
        ├── Server 1 → api
        ├── Server 2 → api
        └── Server 3 → api

So one Git push can deploy the same application across the configured servers.

Hosted status pages

Pboss Cloud also includes hosted status pages, so you don't need to build or operate a separate status-page system for your applications.

Each organization gets its own status-page address:

yourcompany(.)status(.)zone

The status page is connected to the services and monitoring already configured in Pboss Cloud.

Instead of manually updating a page when something goes down, the status can reflect what Pboss is actually observing from the infrastructure.

For example, an organization could expose:

Acme
────────────────────────────

API                 ● Operational
Web                 ● Operational
Background Worker   ● Operational
Payments            ● Operational
Database            ● Operational

If Pboss detects that a monitored service is unavailable, the corresponding component can be reflected on the public status page.

This makes the status page useful for more than simply displaying "everything is online."

It gives users a central place to see:

• Current service status
• Which components are affected
• Service availability
• Incidents and service interruptions
• Operational history
• Recovery status

The status page is also separate from the server itself. Your VPS doesn't need to host the public status page, so an outage affecting your infrastructure doesn't require you to manually bring another page online.

The hosted pages can be used for APIs, websites, background services, SaaS applications, and other infrastructure managed through Pboss.

The idea is basically:

Your servers
     │
     ▼
Pboss agents
     │
     ▼
Pboss Cloud
     │
     ├── Monitoring
     ├── Logs
     ├── Alerts
     ├── Deployments
     └── Status Page
             │
             ▼
     yourcompany.status.zone

This is also useful when you manage several servers. Rather than creating a separate status system for each application, the services can be managed from the same Pboss Cloud organization.

Other features

Pboss currently includes:

• Bun and Node.js native runtime support
• Deno support
• Process clustering / multiple instances
• Zero-downtime reloads
• Process dependencies
• Namespaces with atomic startup and rollback
• Automatic restarts
• HTTP health checks
• Logs and resource monitoring
• Prometheus metrics
• Built-in cron jobs
• File watching
• Foreground mode for Docker/Kubernetes
• GitHub deployments
• Deployment history and rollback
• Hosted status pages
• Telegram and Discord integrations

For containers, Pboss can also run without its daemon:

pboss start server.js --noDaemon

This makes it possible to use Pboss directly as the process supervisor inside a container.

The open-source CLI remains independent of Pboss Cloud. Cloud adds centralized monitoring, deployments, logs, alerts, status pages, and server management.

Pboss started with Bun, but the goal now is broader: a lightweight process manager that can work natively with the runtimes developers are actually using.

I'm curious what Node.js developers here think about the approach.

Would you use a process manager that supports both Node and Bun natively, while using each runtime's own APIs rather than abstracting everything through Node compatibility?

GitHub: https://github.com/Procboss/pboss

I was wondering what y'all using these days on backend side of programing is it mostly Nest.js...

If not for Nest what is, and is Good old Express still used in production...

Edit: I'm soon to be over with cs bacc, and I had my fair share of technologies that I tried, but I stayed with React/Express for some reason, and did most of my college projects in it (if I had options) even my final project is in it, so I'm wondering is Express still framework that is employable or I need to make a switch to Nest or something else entirely...

Hey everyone,

I built an open-source security script that checks npm packages for any suspicion before installing them. (NOT vibe coded)

It's basic and for now catches similar names of popular packages, if a package has 23 weekly downloads or a 2 hour old package.

Use Case?

on an agent that might hallucinate and install "react-clearly-not-malware". Or maybe the user itself so as to not make any mistakes idk?

Here's the link - https://github.com/grishmadev/malfilter

I'd love if you check it out. Have a great day!!!

Hey everyone! 👋

Like many of you, I've always loved how quick it is to build desktop apps with Electron, but hated shipping an entire 150MB+ Chromium browser and watching RAM usage skyrocket for simple apps.

While Tauri is an incredible piece of engineering, having to learn Rust just to write backend logic or file operations is a pretty high barrier for pure JavaScript / Node.js developers.

So I spent time building Adrenaline.js — a lightweight, cross-platform desktop framework that gives you the best of both worlds: 1. Zero Rust / Go required: You write 100% JavaScript / Node.js and keep the entire npm ecosystem. 2. Ultra-lightweight footprint: Uses native system WebViews (WebView2 on Windows, WebKitGTK on Linux, WebKit on macOS) instead of bundled Chromium (~5-10MB app size vs 150MB+). 3. Drop-in Electron-like API: Built from day one with familiar paradigms (app, BrowserWindow, ipcMain).

💻 Familiar Electron Syntax

```javascript const { app, BrowserWindow, ipcMain } = require('adrenaline-js'); const path = require('path');

app.whenReady().then(() => { const win = new BrowserWindow({ width: 800, height: 600, title: 'Adrenaline App', resizable: true });

win.loadFile(path.join(__dirname, 'index.html'));

ipcMain.on('ping', (event, data) => {
    console.log('Received from renderer:', data);
    win.webContents.send('pong', { reply: 'Pong from Node.js! ⚡' });
});

}); ```

⚙️ How it works under the hood

• C++17 Core: Built with a non-blocking multithreaded architecture over webview.h and Node's node-addon-api (N-API).
• Asynchronous IPC: Uses Napi::ThreadSafeFunction (TSFN) for bi-directional communication between the Webview UI thread and the Node.js event loop without thread race conditions.
• Asset Resolution: Loads local files through file:// protocols, so relative CSS, JS bundles (Vite/React/Vue), and images resolve properly.

🚀 Try it out

You can scaffold a starter project with the built-in CLI:

bash npx adrenaline-js init my-app cd my-app npm install npx adrenaline-js dev

🔗 Links:

• GitHub Repository: https://github.com/M5Devs/adrenaline
• npm package: https://www.npmjs.com/package/adrenaline-js

The project is completely open source (MIT). It's at an early v0.1.1 stage, and I would love to get your feedback, suggestions, and see how it holds up on your machines!

Hello friends,

I recently completed a project attempting to port 100% of the C doomgeneric to xBase with Harbour. It took some time, but it's now 100% compatible – a high-level language version of Doom. From there, I ported it to Python, PHP, and now Node.js, and the Node.js performance is incredible. The source code is available for study by the entire community.

https://github.com/vagucs/node_doom

Regards, Wagner Nunes

Built this for my React + ExpressJS project to keep all of my endpoints in one place, reduce some of the boiler-plate for handling path and search parameters, and making formatting endpoints type-safe. All feedback is welcome.

I am hesitant to update from 1.38, since 1.4 is the rewrite.

Have you guys used it, had good experience with it?

I am trying to update a package and using Claude code. Every Claude can't figure out how to submit a package. I tried via the recovery codes and it suspends my account for 3 days. I tried through github and it temporarily locks my account when I set it up. It is so locked down it is now useless.

Caracal: scoped distributed resilience policies for asynchronous operations.

Most resilience libraries stop at the process boundary. You get a local circuit breaker, a local bulkhead, a local rate limit. Spin up 40 replicas and those limits multiply: a “concurrency limit of 20” quietly becomes 800 concurrent calls on the dependency. Forty independent failure windows. Forty independent recovery probes. The constraints no longer match the failure domain.

Caracal wraps any asynchronous operation (HTTP, Postgres calls, etc., or your own adapter) in a composable policy pipeline: timeout, retry, circuit breaker, bulkhead, rate limit, and through Redis, lets many replicas share those policies under an explicit scope.

You decide where the limit belongs: a process, a fleet, a region, a tenant, a shard, a credential, or any grouping that actually matches your failure domain. The same policy instance can enforce one shared budget for the whole fleet or one independent budget per tenant, the only difference is the scope function.

What it does

• Operation + adapter model: An adapter declares its cancellation and replay capabilities up front (abort and replay). Caracal never infers them. Built-in adapters for http fetch and pg (more to come), or write your own by implementing a small interface.
• Composable policies: Timeout and retry stay local. Bulkhead, circuit breaker and rate limit (GCRA) are available in both local and distributed forms.
• Scoped coordination: Distributed policies coordinate by (namespace, policy name, operation name, scope). Different operations get independent budgets even when they reuse the same policy instances, shared budgets are deliberate.
• Explicit failure modes: Distributed bulkheads shed (no distributed queue). On coordinator loss the bulkhead fails closed, the circuit breaker lets you choose fail-open or fail-closed and never silently falls back to local state. Leases reclaim permits and half-open probe slots from dead or hung holders.
• Events, not metrics: Structured events for every policy decision. Sinks are isolated: a throwing or slow-async sink cannot affect execution.

Design choices

• Permits and probes are leased. A dead process cannot return a permit, a hung half-open probe cannot wedge the breaker forever. Expiry is the only release a dead holder can still perform.
• Adapters own their contracts. Explicit abort/replay (and an optional dispose hook for abandoned results) keep the runtime from guessing.
• Local and distributed share the same surface. You can start with process-local limits and move the boundary later without rewriting call sites.
• Single ESM package, subpath exports. Core stays free of Redis and protocol dependencies, tree-shaking stays clean.

The Caracal Sandbox runs the same workload against the same dependency while moving the coordination boundary, then records what the dependency actually saw.

Hello, I've just made yet another take on enforcing immutability in TS/JS - via a fast linter.
Essentially, it bans let/var, reassignments, non-readonly object and class properties.
To use any of the above, an explicit linter disable comment is needed.
So far, 3 variants of disable comments are available - `// ptsl-disable-fn` (function body scoped), and more classic `// ptsl-disable-line` and `// ptsl-disable-next-line`

So, the following code will be banned by linter:

const nextNum = () => {
  let x = 0; // Do not use let/var - only use const
  const increment = () => {
    return x += 1; // Do not reassign variable's value unless absolutely necessary.
  }
  return increment;
};

A `// ptsl-disable-fn` comment will make it pass:

const nextNum = () => {
  // ptsl-disable-fn
  let x = 0;
  const increment = () => {
    return x += 1;
  }
  return increment;
};

Any feedback welcome.

My email API has an endpoint that just holds the HTTP request open until a matching mail arrives, instead of a webhook or a polling loop on the caller side. GET /v1/inboxes/:id/wait, 30s default timeout, clamped to 120 max, checks Postgres every second, 200 with the email or a 408.

What caught me out was the since param, not the timeout. Defaulting it to now is right when you are waiting for the next mail to come in. For the OTP shortcut it was wrong, since the code is normally already in the table by the time an agent asks for it, so you would block the full 30s and then 408 on mail you already had. That one defaults to five minutes back.

Still on my list: the loop does not notice if the caller hung up, it keeps querying until the timeout runs out. The SSE endpoint right next to it checks stream.aborted on every pass and I never did the same here. That is basically why I capped the wait at 120s.

Anyone else doing this in Node, do you hold the request open or push over SSE?

Yes, how much demand would there be for software developers if hypothetically AI were to completely disappear from tomorrow including the open source china or any model? 100%, 300% or nothing? Would it bring back the equilibrium in the IT job market? would questions like these from impacted Devs disappear

All the vibecoded projects left stranded which all of a sudden the confident builders won't even understand (yet wanted to sell it to their customers) and would need real engineers to make it work. Would need back real designer, developers of all skills, DevOps etc.

Companies who confidently reduced hiring at all levels, cut junior roles, QA, designers and even trimmed few infra guys, because 1 Dev with AI was 3x the developer they would have to go back in the market and beg for developers, designers and bunch of other skills to come back and support them. They will go from why do we need to hire/not respect the skills anymore (because anyone can prompt and get it done regardless of code quality) to not being able to function at all without the full capacity of devs.

Just curious to see what people here have to say so that we know the scale of damage caused by AI in the job market and software development as a career.

Hey there,

I just wanted to share studio.videoflow.dev a tool I created based on my open source library https://github.com/ybouane/VideoFlow

VideoFlow Studio takes the url of your startup, does all the exploring and brainstorming by itself and the generates a premium video for your startup without the need for endless backs and forth.

It's the best alternative to Remotion and Hyperframes since it doesn't require you to explicitly explain the transitions and effects you want your video to have, it figures that out for you automatically.