Posts in Nodejs (8 found)
David Bushell 1 weeks ago

Friendship ended with Deno, now Node is my best friend

It’s finally time I go crawling back to Node! I’ve been using Node heavily this month on a SvelteKit client project. When did Node get so good‽ Deno has been my go-to runtime for so long I forgot how to Node. Now I’m back, I find all the ECMAScript † sugar is supported and the old annoying APIs have been replaced or modernised. Most importantly, I never have to see . † Doesn’t seem like that Oracle trademark dispute will see a positive end :( The official Node docs recommend piping an internet script straight to bash (we never learn) to install NVM to manage Node & NPM. My (ancient) experience with NVM and NPM hasn’t been stellar. I heard Fast Node Manager (FNM) was better to switch Node versions. Obviously I roll bleeding-edge but I have client projects that demand stability. I opted for PNPM too to avoid getting immediately pwned. (The “M” in NPM stands for “malware.”) Some scripts I use have hard-coded binary names, so I added two aliases: Maybe that’s a crime but so far it’s worked flawlessly. PNPM also blocks post-install scripts. Does NPM still yolo those? I added additional settings to to delay malware updates. At first I tried setting the minimum release age to “one month” because it takes Microsoft at least that long to remove reported malware. This caused dependency issues where PNPM struggled to match suitable versions. I settled for “one day”; long enough to allow some other sucker to beta test the next Shai‑Hulud. Node can now run TypeScript without throwing a tantrum like a baby if the stars don’t align. That said, one does not simply publish TypeScript packages to NPM. Why? Just strip the types bro, I know you can! Let me sign a deal with the devil! To discourage package authors from publishing packages written in TypeScript, Node.js refuses to handle TypeScript files inside folders under a path. Node.js v26.10.0 documentation This restriction is philosophical rather than technical. I get it though. TypeScript is a Microsoft product. Opening that floodgate would pollute the entire ecosystem. Nobody wants more Microsoft. I’d love to see light “native types” in ECMAScript. There are type annotation proposals . I suspect I’ll be retired before those bear fruit. No TypeScript packages mean I need to find the latest churnware slop to bundle my stuff. Tsdown did the trick, with only two additional dotfiles. Not thrilled about that (every dotfile represents a mistake). I suppose I break even after deleting etc. Speaking of Microsoft lock-in, because they wrecked GitHub I’m self-hosting my own Forgejo instance . NPM limitations mean my packages have lost “provenance”. I had to configure the PNPM trust policy to allow my own stuff. Fun times! My final test for Node was converting my static site generator from Deno. Not many Node versions ago this would have required a major refactor. Today with I found surprisingly little work to do. The only required changes were to replace Deno’s file system API with — which is vastly improved from what I remember (literally ~10 years ago). Aside from that, I had to replace with Hono’s node adapter (a wrapper around ). After this minimum-viable migration I was shocked to see 15% faster builds . My codebase still favours idiomatic Deno. I bet I’m leaving performance on the table by not using other built-in Node APIs. That’s something to explore later. The only further change I made was to replace Deno’s with which is a straight import swap. So if I were to TL;DR in the middle: Node got a glow-up, wow! You’ve probably known this for a while. I kept using Deno out of habit and familiarity. And I haven’t exactly been enthused to write server-side JavaScript recently. I’m burying this part because it’s flogging a dead horse. Ultimately, Deno failed when they allowed the Silicon Valley Circus to define “success”. Deno went from an innovative modern JavaScript runtime to a boring start-up with uncompelling products . Half the employees were laid off and what’s left are tweeting AI fantasies and vibe-coding Temu Cloudflare. There is no reason to use the Deno runtime today. Deno Land Inc. stopped innovating that years ago. Node has slowly but surely caught up, even surpassing Deno in places. What finally pushed me away was: Basically stuff that made it borderline unusable on top of my other criticism. JSR support were very quick to delete my account on request. I don’t like leaving dead profiles around the internet. None of my packages are visible but old versions remain installable. It was fun early on but now it’s time to say goodbye. Thanks for reading! Follow me on Mastodon and Bluesky . Subscribe to my Blog and Notes or Combined feeds. Broken ZSH integration for weeks JSR’s aggressive “429 (Too Many Requests)” Bug(s) that made Deno choke on concurrent HTTP requests

0 views
Thomasorus 12 months ago

Cross platform web app solutions

A discovery list of technical solutions to produce a desktop and/or mobile app using web technologies. Apparently (all this is quite new to me) most solutions embed NodeJS inside them, making executing JavaScript the easiest part of the problem. Real trouble comes when talking about the UI, since each OS has different ways of rendering UI. Several solutions exist to make the programs multiplateform. Those solutions package webkot (chromium) and nodejs inside the app and make it work as a fake app on the desktop. Works well but comes with a lot of bloat and heavy ram consumption. Overall both are in the same family but they are differences between NW.js and Electron . Since bringing chromium makes the program very big, there are solutions to bridge between web apps and existing, lighter UI frameworks. Most of the time then, the framework is used to create a bridge between HTML/CSS and the existing frameworks components, modules or UI API. Since all OSes can render webview, it's possible to ask for one at the OS level by providing a bridge. The problem with this solution might be that if the OS has an outdated webview engine, all modern HTML/CSS/JS solutions might not work? Except for neutralino, most projects of this type tends to use webview , a C/C++/Go library. Several bindings library for other languages already exist. Electron is made by Github NW.js is made by Intel NodeGui provides a bridge between HTML/CSS and QT. Deno webview Sciter is a binary that can be used to create web apps. But under the hood it's using a superset of JavaScript called TIScript Sciter JS seems to be Sciter but with common JavaScript, using the quick JS engine.

0 views
Dizzy Zone 1 years ago

Malicious Node install script on Google search

Sometimes I have to install Node on my machine for work, or a personal project. This occurs rarely, so I keep forgetting how to do it. So I did what I usually do, and Googled how to install nvm. To my surprise there’s a sponsored result, which immediately triggers a red flag: This link leads to a repo in Github. It has the following readme - I’ve omitted the domain and path: If we look at the script in question: It prompts for your pass, stores it in a file and downloads a binary. It then executes that binary and your system is compromised. This attack seems to target quite a few google keywords, as I’ve tried other queries related to installing Node and quite a few of them show the sponsored malware. I’ve reported the repository and the ad as malicious and hopefully Github/Google will take it down. Nevertheless - it serves as a reminder that it’s as important as ever to stay vigilant and never execute arbitrary scripts on your machines. Stay safe!

0 views
Takuya Matsuyama 1 years ago

Integrating my note app with Claude's MCP

Hi, it's Takuya here. I've been fiddling with Claude, which provides an interesting protocol for third-party AI integrations called MCP (Model Context Protocol). Some of my note app (called Inkdrop ) users requested that they want to let Claude use their tech notes as knowledge via MCP. Yeah, that sounds very interesting, so I tried to support it. MCP itself is a pretty simple protocol and there is already a TypeScript SDK, so you can quickly start implementing it: The Claude desktop app invokes MCP servers locally to interact with external data or services. MCP can accept data via stdio or SSE (HTTP). Inkdrop supports running an HTTP server locally so you can programmatically access your notes. It allows you to access via MCP as well. For example, to let MCP clients to read a note in the Inkdrop database: Pretty simple! I've published a repository and npm package for Inkdrop: Let me know what you will do with this integration! That's it! I hope you enjoy it 😄 Set up a local HTTP server Add server config to Claude Desktop: MacOS:  Windows:  Can you find my reading notes about a book called "Four Thousand Weeks" in Inkdrop? Then, can you create a new note to summarize these notes in the notebook "Blog"?

0 views
Rafael Camargo 1 years ago

How to easily convert HTML to image in NodeJS or in the browser

Ever thought about turning a piece of HTML into an image? Well, it’s totally possible. And even better, you can do it either on the server or right in the browser. To generate an image from HTML on the server, you'll need a library called Puppeteer. Puppeteer is a NodeJS library that lets you control Chrome or Chromium programmatically...

0 views
blog.philz.dev 2 years ago

Observability in Trouble

Writing down and sharing a tools and tricks that got us out of a jam. These tools and jams are quite generic, and I wouldn't hesitate to re-implement them in new contexts. A specific kind of request for a very specific customer was really, really slow. We could see the slowness in the logs (hey, why is that taking 30+ seconds?), but we couldn't tell why, or what had changed. An incident formed, and folks started combing through commits. and all that. This particular system was NodeJS-based, and it turns out that if you send (via something like ) to a NodeJS process, it will start listening to the debugger. It'll spew something like the following to stderr: Then, you use some incantations to tunnel your local port 9229 to production's 9229, and then you can use to attach Chrome's debugger to your remote process. And then you use the simplest of profilers: you hit pause, note the stack trace, and hit play. And you do that a few more times. And it's very surprising that the stack trace is always the same: that's your hot spot! Once we had the stack trace, and we could inspect some variables and arguments for state, we quickly realized what was "accidentally quadratic" (hat tip to the Accidentally Quadratic blog ) and the rest was history... ( Ctrl-C Profiling is in the same spirit.) The above--connecting to production, SSH tunnels, clicking around in your debugger--is a bit imposing. It can be finnicky. It should be gated with permissions and processes. Instead, set up something that allows you to start a profiler via some HTTP path (preferably gated with permissions), possibly via a magic header. Have that profiler run for, say, 60 seconds, and dump its output to S3. Log the path to a proxy that will let you download the profile to your logging system. Now, you can trigger a profile, trigger the errant action, and analyze the profile, all from the convenience of home! Since profiles only have function names and timing information, they are, unlike customer data, allowed to be on your dev machine. If you want to go one step further, integrate directly with Speedscope and serve the profiler UI directly. See Stripe's write-up on Canonical Log Lines . Have a structured log line for every request and point your log analysis tool (e.g., Kibana) at it. Just looking for the slowest requests can often pin point a source of trouble. Having p95 latencies in your monitoring stack is nice and all, but, at the end of the day, you need to find some actual requests that experienced those latencies, and it sure is handy when that's easy. If your app talks to a database, a common source of latency and load is the SQL queries made in responding to a request. If you have a misbehaving query, it's hard to figure out what code path is invoking it (especially if it's in a library or an ORM layer is involved). If you have a slow request, it's hard to to know which queries are slowing it down. Sure, you can keep a query counter and a query latency total in your canonical log line, but you still need to figure out which queries are at the heart of the issue. So, for every Nth request (N=10,000 is reasonable), log all the queries that request does! If you have enough QPS flowing through your system, you'll have a pretty effective sample of all those queries in your log system to do further analysis. If you have a tracing header in your system (e.g., OpenTelemtry's ), you can tie the sampling to the trace-id. If you're comfortable with the security implications, you can, perhaps, learn how to inject a trace-id that will make sure that your particular request that you're making right now with is one of the Nth requests that gets sampled. It's often useful to know the stack trace that triggered a SQL query to be executed. Taking stack traces (via or the like) can be expensive in your runtime. Sampling can come to the rescue again: do it every Mth request that's already sampled, and your logs will give you stack traces. I've also, in the past, built a CI job that annotated all SQL queries and shoved them into a SQLite file (viewable, e.g., with https://datasette.io). That worked, but logs turned out more useful. You can also put them stack trace into a query comment, as suggested by Henry . Sometimes, you want to sneak a bit of data into your profile. For (a made-up) example, say you're executing a query, and you want to replace with , so that you can discern which table is being scanned. In a sufficiently dynamic language (Java, Python, JS all qualify), you can sneak a string into a profile like so: The output looks like: Note that Content Security Policies can disable the use of and this trick.

0 views