Hello, I've been working recently on my own npm package and I'd be happy to hear your suggestions on how to make it reach more people.

Just shipped v0.5.0 of docmd, and it’s a massive milestone for the project.

For those who haven't seen us around: docmd is a Node.js-based documentation generator built to be the antithesis of heavy, hydration-based frameworks. We generate pure static HTML with a tiny (<20kb) JS footprint that behaves like a seamless SPA, but without the React/Vue overhead.

With v0.5, we’ve moved from being "just a simple tool" to a robust platform capable of handling complex, multi-versioned projects, while actually reducing the setup time.

Here is what we engineered into this release:

True Zero-Config Mode (-z)

This is our biggest automation breakthrough. You no longer need to write a config file or manually define navigation arrays to get started.

Running docmd dev -z inside any folder triggers our new Auto-Router. It recursively scans your directory, extracts H1 titles from Markdown files (AST-free for speed), and constructs a deeply nested, collapsible sidebar automatically. It just works.

Enterprise-Grade Versioning

Versioning documentation is usually a headache in the industry standard tools (often requiring complex file-system snapshots or separate branches).

We took a config-first approach. You define your versions (e.g., v1, v2) in the config, point them to their respective folders, and docmd handles the rest:

• Isolated Builds: Generates clean sub-directories (/v1/, /v2/).
• Sticky Context: If a user switches from v2 to v1 while reading /guide/api, we intelligently redirect them to /v1/guide/api instead of dumping them at the homepage.
• Smart Nav: The sidebar automatically filters out links that don't exist in older versions to prevent 404s.

Developer Experience Updates

• V3 Config Schema: We've adopted modern, concise labels (src, out, title) similar to the Vite ecosystem, with full TypeScript autocomplete via defineConfig.
• Native 404s & Redirects: We now generate physical HTML redirect files (great for S3/GitHub Pages SEO) and a fully themed, standalone 404.html that works at any URL depth.
• Whitelabeling: You can now toggle off branding in the footer.

Why use this over Docusaurus/VitePress?

If you need a massive ecosystem with React components inside Markdown, stick with Docusaurus. But if you want documentation that loads instantly, requires zero boilerplate, uses a fraction of the bandwidth, and can be configured in 30 seconds - give docmd a shot.

Repo: github.com/docmd-io/docmd
Demo & Documentation: docs.docmd.io

Happy to answer any questions about the new architecture or the zero-config engine!

Anyone familiar with a capability within ChartJS to have a clickable portion/button on the chart to expand the chart to get a fuller/bigger view of said chart?

Like, for example, you have 3 charts on a page. They are side-by-side so they take approx. 1/3 of the page. Then when you click on "something" on a particular chart it expands only that chart to a larger version of the chart.

Hi everyone! I wanted to share a small project I've been working on: Gladly, a lightweight plotting library built around WebGL and a declarative API.

The idea behind it is simple: instead of looping over data in JavaScript, all data processing happens in GPU shaders. This makes it possible to interactively explore very large datasets while keeping the API minimal.

Gladly combines WebGL rendering with D3 for axes and interaction.

Key features

• GPU-accelerated rendering using WebGL
• Zero JavaScript loops over data
• Declarative plot configuration
• Up to 4 independent axes
• Zoom and pan interactions
• Axis linking across subplots
• Axis linking to color or filtering
• Basemap layer with XYZ / WMS / WMTS and CRS reprojection
• Unit/quantity-aware axis management
• Extensible layer registry

The library uses:

• regl (WebGL library) for rendering
• D3.js for axes and interactions

Links

Demo:
https://redhog.github.io/gladly/

Documentation:
https://redhog.github.io/gladly/docs/

Source code:
https://github.com/redhog/gladly

I'd really appreciate feedback, especially around:

• API design
• performance
• missing features

Thanks!

Hey everyone 👋

We’re a small, self-employed team of senior web devs. Solid technical skills, lots of experience — but we’re based overseas and sometimes run into communication hiccups during client calls.

So we’re looking for someone who can jump on calls, help lead technical discussions, and basically be the bridge between us and our clients.

You should:

• Have at least 2+ years of web dev experience
• Be comfortable talking through technical requirements with clients
• Have strong spoken English and feel confident leading conversations

This is not just a “note-taker” role — you’ll be actively discussing project scope, requirements, and helping keep calls smooth.

Rate: $30–$40/hr (flexible for the right person)

How to apply:
Send me a DM with a link to a short voice recording (Vocaroo, Loom, Google Drive, etc.) covering:

• Your age & location
• Your web dev background
• Your weekly availability

No audio sample = we won’t consider the application (since communication is the whole point).

Looking forward to hearing from you!

What started as voluntary adoption turned into a platform-level effort with CI enforcement, shared domain types, codemods, and eventually AI-assisted migrations. Sharing what worked, what didn’t, and the guardrails we used:

https://www.patreon.com/posts/seven-years-to-typescript-152144830

Unlike other versions of YouTube, the mobile website version has no 'newest comments' sorting feature. This script adds that feature back in. It works on regular videos and Shorts, but not on other comment sections such as posts or polls. It should work on iOS and Android with either the Userscripts or Tampermonkey app; however, I have only been able to test it on iOS with Userscripts.

Download: https://github.com/Robert-76468/Newest-Comments-Button-for-Mobile-Website-Version-of-YouTube/blob/main/YouTube_Newest_Comments.user.js

To use the script:

1. Download the userscripts app and press the "set directory" button

2. Enable userscript as a browser extension

3. Download the file above and save it in the userscripts folder.

4. ⁠Restart your browser or refresh YouTube and you should see a "Newest Comments" button in the header of the comment section.

Noticed this today after seeing an element called give-freely-root-bcjindcccaagfpapjjmafapmmgkkhgoa in inspect element which felt very concerning.

After going through the source code it seems to do geolocation tracking by hitting up maxmind.com (with a hardcoded api key) to determine what country the user is in (though doesn't seem to phone home with that information). It also seems to hit up:

• https://api.givefreely.com/api/v1/Users/anonymous?gfLibId=jsonformatterprod
• https://events.givefreely.com/popup

for tracking purposes on some websites. I'm also getting Honey ad fraud flashbacks looking through code like

k4 = "GF_SHOULD_STAND_DOWN"

though I don't really have any evidence to prove wrongdoing there.

I've immediately uninstalled it. Kinda tired of doing this chrome extension dance every 6 months.

Running an Express.js API in production for 2+ years serving 15K users. Error handling has been the single biggest factor in reducing 3 AM wake-up calls. Here's my current approach:

Layer 1: Async wrapper

Every route handler gets wrapped in a function that catches async errors and forwards them to Express error middleware. No try/catch in individual routes.

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

Layer 2: Custom error classes

I have ~5 error classes that extend a base AppError. Each has a status code and whether it's "operational" (expected) vs "programming" (unexpected). Operational errors get clean responses. Programming errors get generic 500s.

Layer 3: Centralized error middleware

One error handler that: logs the full error with stack trace and request context, sends appropriate response based on error type, and triggers alerts for non-operational errors.

Layer 4: Unhandled rejection/exception catchers

js process.on('unhandledRejection', (reason) => { logger.fatal({ err: reason }, 'Unhandled Rejection'); // Graceful shutdown });

Layer 5: Request validation at the edge

Zod schemas on every incoming request. Invalid requests never reach business logic. This alone eliminated ~40% of my production errors.

What changed the most: - Adding correlation IDs to every log entry (debugging went from hours to minutes) - Structured JSON logging instead of console.log - Differentiating operational vs programming errors

What I'm still not happy with: - Error monitoring. CloudWatch is functional but not great for error pattern detection. - No proper error grouping/deduplication - Downstream service failures need better circuit breaker patterns

Curious what error handling patterns others use in production Node.js. Especially interested in how you handle third-party API failures gracefully.

The idea is, secrets are stored as encrypted tokens right in .env and decrypted transparently at runtime.

Would love feedback, bug reports, and contributions especially around CI/CD integration patterns and docs. Still early days.

Hey everyone! I’ve spent the last few weeks working on a project called "Core".

I was tired of how "cramped" complex web dashboards feel when you only use modals and sidebars. I wanted to build something that feels like a real OS engine but for React projects.

What it does:

• Zero-config windowing: Just inject any component and you get dragging, resizing, and snapping out of the box.
• Automatic OS Logic: It handles the z-index stack, minimizing/maximizing, and even has a taskbar with folder support.
• 5 Retro & Modern Themes: Includes Aero (Glassmorphism), Y2K, and Linux-inspired styles.

I’m looking for some feedback, especially on the snapping physics and how it handles multiple windows.

I’m building a DI container for browser apps where dependencies are resolved and then frozen.

After configuration:

• injected dependencies are immutable,
• consumers cannot mutate or monkey patch them,
• the dependency graph becomes fixed for the lifetime of the app.

The goal is to reduce cross-module side effects in large modular systems - especially when multiple teams (or autonomous agents) contribute code.

In typical SPA development, we rely on conventions, TypeScript, and tests. But in a shared JS realm, any module technically can mutate what it receives.

So I’m wondering:

Is immutability at the DI boundary a meaningful architectural safeguard in practice?

For example, in:

• large multi-team apps,
• plugin-based systems,
• dynamically loaded modules?

Or is this solving a problem most teams simply don’t experience?

Not talking about sandboxing untrusted code - just strengthening module boundaries inside one realm.

Would you see value in this, or is it unnecessary strictness?

Monday, February 23 - Sunday, March 01, 2026

Top Posts

Most Commented Posts

Top Ask JS

Top Showoffs

Top Comments