Traditional JS is actually among the safest environments ever created. Every day, billions of devices run untrusted JS code, and no other platform has seen sandboxed execution at such scale. And in nearly three decades, there have been very few incidents of large successful attacks on browser engines. That makes the JS engine derived from browsers the perfect tool to build a server side framework out of.

However, processes and practices around NodeJS and npm are in dire need of a security overhaul. leftpad is a cultural problem that needs to be addressed. To start with, snippets don't need to be on npm.

▲

spankalee 2 hours ago | parent | next [-]

Sandboxing doesn't do any good if the malicious code and target data are in the same sandbox, which is the whole point of these supply-chain attacks.

	▲	pixl97 an hour ago \| parent [-]
		I mean, what does do good if your supply chain is attacked? This said, less potential vendors supplying packages 'may' reduce exposure, but doesn't remove it. Either way, not running the bleeding edge packages unless it's a known security fix seems like a good idea.

▲

skydhash 2 hours ago | parent | prev | next [-]

I think the smallest C library I’ve seen was a single file to include on your project if you want terminal control like curses on windows. A lot of libraries on npm (and cargo) should be gist or a blog post.

▲

WD-42 2 hours ago | parent | prev | next [-]

Javascript doesn't have a standard library, until it does the 170 million[1] weekly downloads of packages like UUID will continue. You can't expect people to re-write everything over and over.

[1]https://www.npmjs.com/package/uuid

▲

simiones an hour ago | parent | next [-]

That's not the problem. There is a cultural (and partly technical) aversion in JavaScript to large libraries - this is where the issue comes from. So, instead of having something like org.apache.commons in Java or Boost in C++ or Posix in C, larger libraries that curate a bunch of utilities missing from the standard library, you get an uncountable number of small standalone libraries.

I would bet that you'll find a third party `leftpad` implementation in org.apache.commons or in Spring or in some other collection of utils in Java. The difference isn't the need for 3rd party software to fix gaps in the standard library - it's the preference for hundreds of small dependencies instead of one or two larger ones.

▲

jmull an hour ago | parent | prev | next [-]

FYI, there's crypto.randomUUID()

That's built in to server side and browser.

▲

skydhash 2 hours ago | parent | prev | next [-]

You have the DOM and Node APIs. Which I think cover more than C library or Common Lisp library. Adding direct dependencies is done by every project. The issue is the sprawling deps tree of NPM and JS culture.

> You can't expect people to re-write everything over and over.

That’s the excuse everyone is giving, then you see thousands of terminal libraries and calendar pickers.

	▲	chamomeal an hour ago \| parent [-]
		When I was learning JS/node/npm as a total programming newbie, a lot of the advice online was basically “if you write your own version of foobar when foobar is already available as an npm package, you’re stupid for wasting your time”. I’d never worked in any other ecosystem, and I wish I realized that advice was specific to JS culture

▲

an hour ago | parent | prev [-]

[deleted]

▲

kortilla 2 hours ago | parent | prev | next [-]

None of those security guarantees matter when you take out the sandbox, which is exactly what server-side JS does.

The isolated context is gone and a single instance of code talking to an individual client has access to your entire database. It’s a completely different threat model.

▲

galaxyLogic an hour ago | parent [-]

So maybe the solution would be to sandbox Node.js?

I'm not quite sure what that would mean, but if it solves the problem for browsers, why not for server?

	▲	simiones an hour ago \| parent \| next [-]
		You can't sandbox the code that is supposed to talk to your DB from your DB. And even on client side, the sandboxing helps isolate any malicious webpage, even ones that are accidentally malicious, from other webpages and from the rest of your machine. If malicious actors could get gmail.com to run their malicious JS on the client side through this type of supply-chain attack, they could very very easily steal all of your emails. The browser sandbox doesn't offer any protection from 1st party javascript.
	▲	int_19h an hour ago \| parent \| prev [-]
		Deno does exactly that. But in practice, to do useful things server-side you generally need quite a few permissions.

▲

mewpmewp2 2 hours ago | parent | prev [-]

Interestingly AI should be able to help a lot with desire to load those snippets.

What I'm wondering if it would help the ecosystem, if you were able to rather load raw snippets into your codebase, and source control as opposed to having them as dependencies.

So e.g. shadcn component pasting approach.

For things like leftPad, cli colors and others you would just load raw typescript code from a source, and there you would immediately notice something malicious or during code reviews.

You would leave actual npm packages to only actual frameworks / larger packages where this doesn't make sense and expect higher scrutiny, multi approvals of releases there.