5 ms·

Please clarify how you'd be e.g. reading JS files in a Node.js/Bun/worker/function/etc without using Node.js (or any of those platform/runtime-specific platform

• nine_k 2y ago
  "Drag the project folder onto that" probably means you're uploading the entire project, and them make the result downloadable (as e.g. tar.gz or zip), without ever having to directly interact with stuff like filesystem. If that could be pulled off, it would be a great way to isolate the build process and prevent malicious packages or build tools from mucking with your system. Does not look very realistic for projects of any considerable size though.
  • cxr 2y ago
    "upload" and "download" are misnomers, but yeah, pretty much. To the original commenter: I don't recommend using Node. I said use the World Wide Wruntime instead. Even so, there's a difference between an app that might incidentally use an API somewhere down the line versus programming directly against that interface. Look at the early versions of the TypeScript compiler. Here's 1.8: <https://github.com/microsoft/TypeScript/blob/release-1.8/src/compiler https://github.com/microsoft/TypeScript/blob/release-1.8/src...> tsc doesn't care whether it's running on Node or in the browser or somewhere else. I think the TypeScript team originally bootstrapped it with the Windows Script Host JScript implementation (available pre-installed on all Windows machines) and didn't start using Node until later on. The only thing the compiler cares about is that something implements the ts `System` interface, so the compiler can invoke e.g. the read-file operation (which belongs to `sys`, i.e. `sys.readFile`) and that it does what it's supposed to do. And it can use the method/capability for listing directory contents, the one for getting the arguments, and so on. That's all defined and implemented straightforwardly in a short file sys.ts. Figure out what services (capabilities) your program actually needs and sketch out an interface that permits all those things. Then write your program against that interface. It'll make your program more readable, anyway. > Does not look very realistic for projects of any considerable size though. Define "realistic" (or "considerable size"). All of Firefox's non-core (i.e. not Gecko) components and the build phase involving them that produces the final release package (~90MB[1]) could probably work this way. (If anyone actually cared about it[2].) Maybe even VSCode, too. Could you do this with any given project you stumble across on GitHub today? Maybe not, but that's because your average NPM programmer turns out programs that use entirely Too Much Fucking Code for what ultimately is just a todo app or whatever. I once benchmarked create-react-app's "hello world" exercise from a blank slate a few years ago. The numbers involved ended up with `node_modules/` taking up something like just under HALF A GIGABYTE of disk space. For a "hello world" app. That's nuts. 1. <https://ftp.mozilla.org/pub/firefox/nightly/2024/09/2024-09-01-09-21-44-mozilla-central/ https://ftp.mozilla.org/pub/firefox/nightly/2024/09/2024-09-...> 2. <https://news.ycombinator.com/item?id=41358029 https://news.ycombinator.com/item?id=41358029>