Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Modern Node.js Patterns

kashw1n.com

Post reply on HN
Print view View original

241–250 of 448 posts

Re: Modern Node.js Patterns

#241

Post by jiggawatts »

ninetyninenine wrote: post #182
jiggawatts wrote: post #128

Earlier quoted context omitted.

In my experience, no. It's still single-threaded, it still uses millions of tiny files (making startup very slow), it still has wildly inconsistent basic management because it doesn't have "batteries included", etc...

You can bundle it all into one file and it's not single threaded anymore. There's this thing called worker_threads. But yes there are downsides. But the biggest ones you brought up are not true.

> You can bundle it all into one file

This is the first I'm hearing of this, and a quick Google search found me a bunch of conflicting "methods" just within the NestJS ecosystem, and no clear indication of which one actually works.

    nest build --webpack
    nest build --builder=webpack
... and of course I get errors with both of those that I don't get with a plain "nest build". (The error also helpfully specifies only the directory in the source, not the filename! Wtf?)

Is this because NestJS is a "squishy scripting system" designed for hobbyists that edit API controller scripts live on the production server, and this is the first time that it has been actually built, or... is it because webpack has some obscure compatibility issue with a package?

... or is it because I have the "wrong" hieroglyphics in some Typescript config file?

Who knows!

> There's this thing called worker_threads.

Which are not even remotely the same as the .NET runtime and ASP.NET, which have a symmetric threading model where requests are handled on a thread pool by default. Node.js allows "special" computations to be offloaded to workers, but not HTTP requests. These worker threads can only communicate with the main thread through byte buffers!

In .NET land I can simply use a concurrent dictionary or any similar shared data structure... and it just works. Heck, I can process a single IEnumerable, list, or array using parallel workers trivially.

Re: Modern Node.js Patterns

#242

Post by berkes »

simonw wrote: post #113

Whoa, I didn't know about this: # Run with restricted file system access node --experimental-permission \ --allow-fs-read=./data --allow-fs-write=./logs app.js # Network restrictions node --experimental-permission \ --allow-net=api.example.com app.js Looks like they were inspired by Deno. That's an excellent feature. https://docs.deno.com/runtime/fundamentals/security/#permiss...

I very much dislike such features in a runtime or app.

The "proper" place to solve this, is in the OS. Where it has been solved, including all the inevitable corner cases, already.

Why reinvent this wheel, adding complexity, bug-surface, maintenance burden and whatnot to your project? What problem dies it solve that hasn't been solved by other people?

Re: Modern Node.js Patterns

#243

Post by int_19h »

MuffinFlavored wrote: post #88

Is current node.js a better language than .NET 6/7/8/9, why or why not?

No. Because C#, while far from perfect, is still a drastically better language than JS (or even TS), and .NET stdlib comes with a lot of batteries included. Also because the JS package ecosystem is, to put it bluntly, insane; everything breaks all the time. The probability of successfully running a random Node.js project that hasn't been maintained for a few years is rather low.

Re: Modern Node.js Patterns

#245

Post by berkes »

tkzed49 wrote: post #214
austin-cheney wrote: post #181

Earlier quoted context omitted.

I never needed those. I would just have an application wide object property like: text: { angry : "\u001b[1m\u001b[31m", blue : "\u001b[34m", bold : "\u001b[1m", boldLine : "\u001b[1m\u001b[4m", clear : "\u001b[24m\u001b[22m", cyan : "\u001b[36m", green : "\u001b[32m", noColor : "\u001b[39m", none : "\u001b[0m", purple : "\u001b[35m", red : "\u001b[31m", underline: "\u001b[4m", yellow : "\u001b[33m" } And then you ca…

I think the widely-implemented terminal escape sequences are well-known at this point, but I don't see why I'd want to copy this into every project. Also, I'm guessing if I pipe your logs to a file you'll still write escapes into it? Why not just make life easier?

Arguably, using a library is also "copy it into every project".

Re: Modern Node.js Patterns

#246

Post by mitemte »

pavel_lishin wrote: post #87
vinnymac wrote: post #70

Earlier quoted context omitted.

If you haven't tried vitest I highly recommend giving it a go. It is compatible with `jest-extended` and most of the jest matcher libraries out there.

I've heard it recommended; other than speed, what does it have to offer? I'm not too worried about shaving off half-a-second off of my personal projects' 5-second test run :P

I don’t think it’s actually faster than Jest in every circumstance. The main selling point, IMO, is that Vitest uses Vite’s configuration and tooling to transform before running tests. This avoids having to do things like mapping module resolution behaviour to match your bundler. Not having to bother with ts-jest or babel-jest is also a plus.

Re: Modern Node.js Patterns

#247

Post by throwup238 »

motorest wrote: post #233
tankenmate wrote: post #221

Earlier quoted context omitted.

I wouldn't trust it to be done right. It's like a bank trusting that all their customers will do the right thing. If you want MAC (as opposed to DAC), do it in the kernel like it's supposed to be; use apparmor or selinux. And both of those methods will allow you to control way more than just which files you can read / write.

> I wouldn't trust it to be done right. I don't understand this sort of complaint. Would you prefer that they didn't worked on this support ever? Exactly what's your point? Airing trust issues?

Node allows native addons in packages via the N-API so any native module aren't restricted by those permissions. Deno deals with this via --allow-ffi but these experimental Node permissions have nothing to disable the N-API, they just restrict the Node standard library.

Re: Modern Node.js Patterns

#248

Post by fuzzythinker »

austin-cheney wrote: post #181
vinnymac wrote: post #81

You no longer need to install chalk or picocolors either, you can now style text yourself: `const { styleText } = require('node:util');` Docs: https://nodejs.org/api/util.html#utilstyletextformat-text-op...

I never needed those. I would just have an application wide object property like: text: { angry : "\u001b[1m\u001b[31m", blue : "\u001b[34m", bold : "\u001b[1m", boldLine : "\u001b[1m\u001b[4m", clear : "\u001b[24m\u001b[22m", cyan : "\u001b[36m", green : "\u001b[32m", noColor : "\u001b[39m", none : "\u001b[0m", purple : "\u001b[35m", red : "\u001b[31m", underline: "\u001b[4m", yellow : "\u001b[33m" } And then you ca…

I have a "ascii.txt" file ready to copy/paste the "book emoji" block chars to prepend my logs. It makes logs less noisy. HN can't display them, so I'll have to link to page w/ them: https://www.piliapp.com/emojis/books/

Re: Modern Node.js Patterns

#249

Post by mcv »

mythz wrote: post #196
stevage wrote: post #162

Earlier quoted context omitted.

I usually write it like: const data = (await fetch(url)).then(r => r.json()) But it's very easy obviously to wrap the syntax into whatever ergonomics you like.

why not? const data = await (await fetch(url)).json()

That's very concise. Still, the double await remains weird. Why is that necessary?

Re: Modern Node.js Patterns

#250

Post by ninetyninenine »

jiggawatts wrote: post #241
ninetyninenine wrote: post #182

Earlier quoted context omitted.

You can bundle it all into one file and it's not single threaded anymore. There's this thing called worker_threads. But yes there are downsides. But the biggest ones you brought up are not true.

> You can bundle it all into one file This is the first I'm hearing of this, and a quick Google search found me a bunch of conflicting "methods" just within the NestJS ecosystem, and no clear indication of which one actually works. nest build --webpack nest build --builder=webpack ... and of course I get errors with both of those that I don't get with a plain "nest build". (The error also helpfully specifies only the…

If you read my comment I said there are downsides:

"But yes there are downsides. But the biggest ones you brought up are not true."

My point is.. what you said is NOT true. And even after you're reply, it's still not true. You brought up some downsides in your subsequent reply... but again, your initial reply wasn't true.

That's all. I acknowledge the downsides, but my point remains the same.

Post reply on HN