What is Reddit's opinion of
Node.js?
From 3.5 billion Reddit comments
➔ Node.js website
By popularity on Reddit, this Service is:
100 reviews of this app found across Reddit:
For people who have no programming experience / never used Node.js, here is a (small) guide on how to use the program.
1) Visit the Github repository as linked in OP's post 2) In the top right corner press the green 'Clone or Download' button and select 'Download Zip' 3) Go to your downloads folder and extract the zipped file 4) Got to nodejs.org and download the latest version (either will do but I always prefer the LTS version) at: https://nodejs.org/en/ 5) After installation go back to your downloads folder where you have your extracted zip directory. 6) (If you know how to use the command line you can skip this step) Go to System Preferences -> Keyboard -> Shortcuts -> Services and select the 'new terminal from directory' 6) Right click the directory and select the newly activated service: 'open terminal from selected directory' found in the services tab of the right click context menu. 7) type "npm run install" and hit enter 8) wait for the installation to be completed and copy paste some examples into the terminal: e.g. "node index.js --zip=012345" and hit enter (changing the zip code of course)
If you come back later and want to run it again you only have to right click the directory in your download directory and select the 'open new terminal screen from directory' and you can run the examples again
The npm module "os" has 29K weekly downloads and 276 packages depend on it. This is NOT the Node core module OS. It is a one line module that is module.exports = require('os').
While it isn't currently malicious... one patch release and it would affect a lot. There is simply no need for this module, which begs the question of its purpose. I reported it to npm a while ago and it seems like they don't care.
https://nodejs.org/en/knowledge/HTTP/servers/how-to-create-a-HTTP-server/
Node.js won't exit until all open sockets (connections, ports) will be closed
The same in the case if you just connect to a database - it won't exit until you disconnect
This was a pretty high-level overview and is definitely not "complete" in any way shape or form from my knowledge of the event loop. It was a good quick summary though.
If you truly want to step up your game and understand the JS Event Loop I have two videos that will explain everything. Watching both will take about an hour. I've come back and watched both a few times now because they're truly such thorough explanations.
Then you can move on to understanding how Node's event loop differs from Chrome V8 using their docs.
If I didn't know the history of this subreddit and only judged it by the quality of content and general knowledge level of the average commenter, I'd assume it's some elaborate joke.
Hey, I'll help you out.
First off you need to install Node.js, which you can get here.
Once that's installed, Download the program from here, unzip the file and place the spoticord-master folder where you want it, this is the program.
Open that folder up and hold shift while right clicking and press 'Open command window here', then you'll see a command prompt window.
Once you see that window, type npm i in the command prompt box, it will install the dependancies for the program.
Open Spotify and Discord, play some music.
Once you've got some music playing, go ahead and type node app.jsinto the command box to get the application to run.
Hope this helps :)
Why not just stick to Javascript on the server as well by using Node? I'd say that (especially for a beginner) sticking to one language makes a lot of sense. You can invest all of your time learning one thing rather than two.
Short answer: Wait six months.
Long answer: Read https://nodejs.org/en/about/releases/
tl;dr: Only use even #'ed releases in production. And wait until they reach "Active" status (6 months after initial release, gives library authors time to add support)
>I'm really excited for ES6
As a web developer, I was like "Dude, ES6 is already here!" https://nodejs.org/en/docs/es6/ https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_in_JavaScript/ECMAScript_6_support_in_Mozilla
I've always stylized the Elder Scrolls as "TES" lol
> Benefits of including node_modules in git:
>
> Reproducible builds. Guarantee that if you clone the repo on two machines, you’ll get the exact same code.
Worth mentioning that dependencies that are built using Native abstractions for Node.js (Node-API is the preferred way though) will, in fact, not work on two different machines unless they use the same OS, the same CPU arch and the same Node.js version. So yeah, I'd advise against sharing node_modules.
Hey, nice of you to put this out there, but there a few things you should revisit/update before others follow this.
You should be using a package like dotenv to load in your database connection information and cookie secret. It is not noted in the article, but if someone were to leave the cookie secret as provided, it would be possible for attackers to generate signed cookies that your server would accept.
The register route does not check if the provided username is already in the database, and it redirects the user regardless of the outcome. You should verify the username is not in use, wait for the DB response and respond accordingly before redirecting.
Your passport.deserializeUser function is vulnerable to SQL injection. You should use a parameterized query like the query in verifyCallback.
The auth middlewares are returning json for an unauthorized request. This is inconsistent with the rendering of pages you have for all other requests. Instead of returning json, you should render an error page.
crypto.pbkdf2sync is blocking. Node.js is a single threaded runtime, so this means that no other request to your server will be processed while a password is being hashed. If you're going to use this hashing algorithm, you should use the asynchronous callback version. This will allow your server to process other requests, while the password is hashed in the background.
- The hashing algorithm you are using is a bit out dated and can be easily brute forced with modern hardware / GPUs. See the articles below for a rundown of other hashing algorithms you can use (argon2 is the industry standard right now).
https://medium.com/@mpreziuso/password-hashing-pbkdf2-scrypt-bcrypt-1ef4bb9c19b3
https://medium.com/analytics-vidhya/password-hashing-pbkdf2-scrypt-bcrypt-and-argon2-e25aaf41598e
Node's main selling point from the very first version (apart from using JS) is parallel, non-blocking IO. From my understanding, all user code is run in a single worker thread, but async IO (file system access, TCP, UDP, DNS) is done with libuv, using as many worker threads as reasonable.
Hell, on nodejs.org literally the first thing you see is:
>Node.js® is a JavaScript runtime built on Chrome's V8 JavaScript engine. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient.
I sent a similar email about my own concerns. While I don’t disagree that Reddit has a toxic element of anonymous users, I am especially troubled that they would characterize all 250m users as such, or even the 32k users of the Node subreddit. I do not appreciate being categorically referred to in the manner that this employee has chosen to, and I felt it in the community’s best interest to make my feelings on the matter known to those that she represents.
I am not an anonymous user. My profiles are public and I know that at least the COO read my email as my LinkedIn account was visited minutes later. I have no reason to hide myself. I am expressing plainly that the way this person chooses to interact with people is hateful and vile and should not be tolerated within an inclusive community. The fact that the employee even spoke on behalf of npm, Inc. and Node to inform the public that their opinions are not respected and are actually laughed at is especially hateful, disgusting, and divisive behavior.
I received a form response, which is to be expected, but I sincerely hope that npm, Inc. provides an official response in regard to the antics of this individual. That is troubling behavior for a company and it causes true concern for me and people I have discussed this manner with privately. The future of the Node community is looking pretty grim if this is where it’s heading.
Edit: If you care about the future of Node then I suggest joining the foundation as an individual member. It’s $100 to join, $25 if you’re a student, and free for contributors to Node. https://nodejs.org/en/foundation/members/
Here's the documentation for node.js https://nodejs.org/api/all.html
If you copy paste that into word and set it in Times New Roman 11pt it's 749 pages.
I can think of no better way to turn someone off of a new technology (and kill their weekend) than to have them read 700+ pages of documentation to start.
I know this will sound a bit naive of me; but why not have everything boot in parallel, and have event readying so that once storage is ready, servers make storage requests; once network readies, storage connects and readies etc, loading everything and waiting for it to say ready and/or (if it initialises faster than the reliant pieces) flip a bit to say it's ready and waiting for the process to attach.
Multiple <code>EventEmitter</code>s if you will; emitting "net_start", "db_ready", "store_ready", "net_ready", "net_shutdown" etc; even toggling between the values 0 (not ready), 1 (ready) and -1 (err, see stderr).
Edit: thanks to everybody for the detailed responses!
Personally, I use docker for practically everything.
I'd run nginx in a container to provide HTTPS (probably need a certbot container as well if you're going to use a free certificate from letsencrypt.org) and reverse proxy to your node app, and then dockerize your node app https://nodejs.org/en/docs/guides/nodejs-docker-webapp/
You're describing CommonJS aka CJS and it's really important to look at the module wrapper which is provided to each module. There really isn't anything special going on here - just a bunch of variables that are passed into a function which is wrapped around your module so that your module can append its exports to the module cache.
The module isn't treated as an object - the module is the code inside of a function call. You don't have to export anything from your module (eg only have a side effect)
// foo.js console.log('before'); return; console.log('after');
loading this module will wrap the source in the CJS wrapper:
node foo.js
would print "before" but not "after". In fact, you could even
console.log(arguments);
if you wanted to check out what the CJS module wrapper arguments are that are provided to the script.
So your shower thought is actually very much accurate. CJS modules literally are functions when the wrapper wraps it.
ESM is a different beast entirely
// foo.mjs console.log('before'); return; console.log('after');
Would yield
SyntaxError: Illegal return statement
This is because ESM doesn't have a wrapper and is instead statically parsed. I won't go into all the details here, but read the API docs they're very complete.
Usually when programmers refer to "the standard library" of a language, they are referring to the libraries that come included with the language.
For example, console.log is a function that exists in Node's standard library, and it's included when you install Node. You don't need to install anything separately to use it (https://nodejs.org/api/index.html everything in this link is Node's "standard lib").
The Go community tends to recommend that you avoid external libs in favor of Go's standard libs. In this case, they are suggesting that you use http.
Ignore the downvotes. Programmers, especially on reddit, are terrible people that tend to hate newcomers.
Alright. Here's the source code:
const fs = require("fs"); const path = require("path");
const runDir = process.cwd();
console.log(Looking for fish files in ${runDir}...);
const files = fs.readdirSync(runDir);
files.forEach(file => {
const matches = file.match(/^(.+)fish_(.+).png$/);
if (matches) {
const prefix = matches[1];
const number = matches[2];
const folderPath = path.resolve(runDir, prefix);
if (!fs.existsSync(folderPath)) {
fs.mkdirSync(folderPath);
}
const filepath = path.resolve(runDir, file);
const newFilepath = path.resolve(runDir, prefix, fish_${number}.png);
fs.renameSync(filepath, newFilepath);
}
});
console.log("Files moved");
You can run it by installing NodeJS, copying it into a file called index.js (inside the directory you want to organize), and then running node index.js in that directory from command prompt. I'll PM you the exe link.
Note on running: The only thing I'm uncertain of here is which folder this will run in. If no files match the pattern [x]fish_[y].png, it won't do anything, so I don't think there's too much to worry about, it's just a matter of getting it to work. I'd try running the exe in the folder you want sorted. If that doesn't work, go into command prompt and run renamer-win.exe inside that directory.
String and date formatting are part of the JS standard lib.
Streams are part of the Node.js standard lib https://nodejs.org/dist/latest-v10.x/docs/api/stream.html
Hey web-based software development IS actual software development, bub.
Do you know how hard it is to keep up with all of the dumb ideas that keep popping up in that space? Every day there is a new framework to assess or some new dumb build tool which will magically solve all your problems except they really only make things worse.
Then you need to deal with your colleagues who love these tools (I'm talking TypeScript, webpack, rollup, Babel, ES6 etc). Generally the ones who are in love with C# and Java flock to these things because if your software doesn't have a complicated build process then how can you write good software? /s. If your software doesn't rigidly adhere to typed variables and Classes then how can you write good software!? /s. Look at all the new versions of Angular since Angular 1.x to see how these ideas infest once-great frameworks. Now it's a real PITA to prototype anything.
The infestation of these ideas makes webdev a nightmare right now and no one coming out of a bootcamp is prepared.
As an aside, there are some extremely impressive and innovative things you can do with JavaScript these days and can be about half as fast as C++ but portable to practically any device. WebGL, WebRTC, WebSockets, ServiceWorkers, WebAssembly etc. are amazing tools that can get you to almost-native performance with a native feel. Just look at the awesome libraries available -- https://threejs.org/ https://www.babylonjs.com/ https://nodejs.org/en/ Plus all of the complexity of setting up a scalable architecture in AWS.
But I guess webdev isn't real software development though!
> This is also my biggest beef. ES6 modules are the future, and rewiring importing rules at runtime is completely antithetical to how they work.
RFC author here.
The monkey patching is only there because Node doesn't expose an API to hook into the CommonJS resolution (yet). We don't like it either (especially since it means we have to write some code we don't really care about), but we figured it was the best way to show how valuable it would be to have a dedicated way to achieve these kind of things.
Regarding ESM modules, Node 10 actually ships with a loader hook API, and as such I'm quite confident we won't have to patch like we did for CJS. At the very least, we'll be able to provide constructive early feedback on this API to the Node project.
Oh, is this the one that uses Node.js and V8 as an install requirement?
Edit: survey says yes:
dghost@Voyager ~> brew info npm node: stable 10.8.0 (bottled), HEAD Platform built on V8 to build network applications https://nodejs.org/ /usr/local/Cellar/node/10.8.0 (4,022 files, 48.7MB) * ... icu4c: stable 62.1 (bottled) [keg-only] C/C++ and Java libraries for Unicode and globalization http://site.icu-project.org/ /usr/local/Cellar/icu4c/62.1 (250 files, 67.3MB) ... Version 0.1.1 Total size 1.02 MiB Total dependencies 121 Tarball size 10.2 KiB Direct dependencies 4 Dependencies signale @ 1.2.1 -- 717.2 KiB (23 deps) update-notifier @ 2.5.0 -- 271.8 KiB (75 deps) meow @ 5.0.0 -- 150.1 KiB (46 deps) chalk @ 2.4.1 -- 32.2 KiB (6 deps) ```
Soooo, it's a 10KiB terminal todo app with 1MiB of direct dependencies that requires a 100MiB runtime.
If you care about the future of Node then I suggest joining the foundation as an individual member. It’s $100 to join, $25 if you’re a student, and free for contributors to Node.
How soon before we get yarn pre-bundled with node releases? Is anything planned? It would be super sweet to have the option to use it instead of npm at all.
I'm not advocating for replacing npm, but it would be great to have the option to pick between npm and yarn as clients.
I can't really give you an unbiased opinion, as I loathe Node.js and its event driven madness. But I can tell you that Go's use of CPU cores is leaps & bounds better, seeing as Node isn't multicore. Not to mention Go will be quicker than Node in many other ways, too.
The thing you really have to ask yourself, is this worth the cost of a rewrite + learning a new language & its idioms?
My experience is that it was definitely worth it, but those three months of not adding value to my business was hard - but now that I'm on the other side of it I'm very very happy I made the change. However, I like Go's clean syntax & idioms so YMMV.
Maybe you should just implement clustering into your project?
You don't need sudo for this. You can "install" a pre-built node.js binary into a user-writable location. https://nodejs.org/dist/v4.0.0/node-v4.0.0-linux-x64.tar.gz
You can do this with compilers too, but you don't need a compiler if you're not going to compile anything.
> You mean the timeout?
Yes. Granted, it's almost certainly fine to put a timeout direct from req.query in the call from a security/exploit standpoint (see documentation). I would definitely object to anybody doing that normally because it's a really bad habit to get into, even in this case. I would hope that when scrutinized a little harder you would find something weird going on.
I wouldn't expect a normal reviewer to actually notice the \u3164 though without the help of some automated tool.
Remember (per the docs), odd-numbered releases are not meant to be used in production environments. They are the “beta but not beta” releases, which will not get long term support.
You will probably have to use the Node.js child_process module. It can spawn a new process and execute a script (e.g. a python file). You'll have to communicate via the standard output streams (stdin, stdout, stderr). It's not super trivial.
Depending on what you need from numpy, I would simply look for a package that contains that functionality. And instead of trying to run MetaTrader5 python package, I'd probably just directly hook up to their websocket API.
Yes, though I personally had some conflicts with native modules running that way, though even if compiling native, no prebuilt node binaries yet for darwin arm, so we are kinda on our own currently.
I did test downloading NodeJS v12 from nodejs.org and it did run just fine, though the native module issues.
I am able to also run an app I am working on in NodeJS with its previously built binaries for x86 and all native modules prebuilt inside of it run under Rosetta 2 just fine, honestly Rosetta 2 is extremely impressive, doesn't feel emulated at all.
Problem though with Node is we really want full native all around for darwin arm64, since otherwise if you do have native modules running under Rosetta its like a JIT in a JIT in a JIT, so performance is extremely decreased compared to what it could be as native.
Node runs on ARM. https://nodejs.org/en/download/
So it looks like you can have an actual Dev environment.
I'll have to buy a note 9 ( when , if they ever go on sale ), to test , but having functional node opens up tons of opportunities. In theory any electron app will work.
Shout out to Samsung for giving a crap about a small minority of users.
Well then it's not static, isn't it.
Anyways, if you want to avoid Express, you have two alternatives:
Don't use a framework. Use Node low level API which for simple things should suffice.
Use a different framework. There are plenty of alternatives out there.
Using a framework, and more generally, having dependencies is a trade off. Dependencies will save you writing software for problems that are already solved. On the other hand, you tie your program to other things that are out of your hand.
It is true that with big dependencies like frameworks, sometimes "you wanted a banana but what you got was a gorilla holding the banana and the entire jungle."
There is here not a simple answer. You'll have to think what do you want to accomplish, and consider carefully the options you have.
Yarn downloads all modules to a global cache folder and then copies the files to node_modules. So it also only downloads once. NodeJS has legitimate issues with symlinks and commonjs modules. Which is why preserve-symlinks is a cmd-line option for modern node. https://nodejs.org/api/cli.html#cli_preserve_symlinks
This is all documented in the ES specs as well as the nodejs docs. Mozilla even documented it on mdn... so if you read the docs, this wouldn't be much of a "secret". for those that don't read api docs, then I guess it would be more of an "unknown" if you're a novice and haven't progressed to that comfort level yet. tbf, it takes awhile to get there.
A 4 digit number has a small entropy, most OTPs are 6 digits. If you go ahead with 4 digits make sure the validation period is very short (15min or so). Math.random() should be fine but you can take it a step further and use crypto.randomInt.
One thing you definitely want to do is strongly secure the login endpoint against brute force attempts. With a 4 digit number it's very easy to make a correct guess. Add an exponential rate limiter that kicks in after 3 wrong tries. Block the account if it had more than x wrong tries in a short period and send a recovery link. It also helps to keep a record of the user's usual login location and if you notice a login attempt from a different location, don't allow OTP and use SSO instead.
You can download and run any version of released Node. There’s an understanding these aren’t supported or maintained, but they’re there in case you need an older version for any reason. The cost is literally just a server to hold the file, this isn’t IE11 where security patches are coming in for deprecated software. This an archival for rare use cases when you need it, and it’s asshole design to make you PAY to not be forced out of these versions.
NodeJS has an API for c++. C++ Modules
After you make one, you can import it in NodeJS by using import
NodeJS also has an FFI, where you can build a shared library (not limited to c++) and import it. Node-ffi-addon
Performance wise, the NodeJS API is what I recommend you use. However, there is a little to learn. If you don't mind the performance drop, I recommend you use the FFI. You don't have to learn the NodeJS API, so it's a little easier
For something this simple you don't need an interface, you can just write a relatively simple Node script, this should get you started: https://docs.npmjs.com/files/package.json#bin
Be sure to start the file with #!/usr/bin/env node. Use <code>process.argv</code> to get the input (and potentially output?) filename argument(s). The fs and possibly the readline module will help you load a file as a string. For an extra challenge, learn about streaming so it will work even with massive files.
If you want it to work on Windows you may have to additionally make a .cmd file, but I'm not sure.
Edit: apparently npm creates a .cmd wrapper automatically on Windows, so no worries there.
You can use most ES6 features in Node 4 without babel. When you find one that isn't supported then you can start using babel or wait until the feature is added to V8 and Node OR you can use flags on the node command to enable features: https://nodejs.org/en/docs/es6/
I have been using babel because I want async/await which is still just a proposal. With babel I use npm i --save babel-runtime and babel --optional runtime --stage 2 for compiling.
The statement "You only got it because you're a girl..." might not "technically" be wrong... Is it an asshole thing to say? Absolutely. But at the same time I can kind of see the frustration of some kid not getting the internship he wants and seeing his female friends have access to "dedicated" programs for minority students. Of course the entire idea that you can "pick the best candidate a job" is terribly flawed (LOL@ technical interviews), but I doubt a kid in college is going to know that until he gets to the other side and starts interviewing people.
I don't doubt for a second that there is a tremendous amount of bullshit directed at female engineers but culture is an incredibly hard thing to change and I'm not sure harshness as a response to "backwards" attitudes is the right approach. Intent is incredibly hard to determine and reacting severely to "perceived bad behavior" can lead to people being overly sensitive, "non-issues" might get blown out of proportion, the community as a whole might get hurt, etcetcetc... (i.e https://nodejs.org/en/blog/uncategorized/bnoordhuis-departure/).
My hope is that these problems will get better with my generation... but that too might be wishful thinking.
> Granted, it's almost certainly fine to put a timeout direct from req.query in the call from a security/exploit standpoint (see documentation).
Are you speaking only to the injection vector? Because setting a timeout of 0 (or some exceptionally high value), coupled with a massive number of requests, would create a self-inflicted DoS. The code should at least provide a window of acceptable values.
Node has C++ extensions too. https://nodejs.org/api/addons.html
Extensions in PHP are not required, but they're strongly recommended because they offer much greater performance than something implemented in pure PHP (as you've mentioned). There are pure PHP MySQL clients for example. ReactPHP maintains one, since the mysql extension uses blocking I/O.
> and if we take a look at the overall picture, PHP's dependency management is more complicated than Node's.
That's a ridiculous statement. Composer is much simpler than NPM. It's not even close. It's also more secure, less risk of malware slipping into the supply chain due to the way it's designed. For NPM packages, the bundles uploaded don't necessarily need to match the code that exists in GitHub. With composer, they're one and the same. Also, package names are vendored in composer which helps a lot, avoids naming conflicts and typo-squatting.
There's hope that composer will eventually manage PHP extension installation (pickle) but that's been stagnant.
> PS: unless you use application server implementations in the cli, you also have to go with a webserver to load your php, which is a touch more complicated than with Node
You'll almost always have a proxy in front of node though, for load balancing, TLS termination, etc. Basically the same deal with PHP. You run PHP-FPM and put a webserver/proxy in front of it.
You'll need to build a back-end to communicate with your database. Trust me, it's easier than it sounds .
Since you already know JavaScript, my advice is to look into Node.js instead of Python. You won't have to learn a new language. It's very easy to setup and there are a lot of packages to boost productivity (so you don't have to re-invent the wheel).
To connect your Node.js app to your database you can use the Sequelize package.
To send the requests from your front-end to the server, you'll use Ajax requests (basic HTTP calls). Here's an intro about that.
Yes, they do.
With more cores the OS can use them to perform other tasks while node is busy in just one core, so overall you get some benefit.
But the right solution in this case is launch multiple node processes (https://nodejs.org/api/cluster.html) and use as much cores as you want.
It sounds like you just need some kind of "getting started" guide for Docker. You might start with something that focuses on Node.js apps, since this is a Node.js app. Beyond that, this looks really basic.
Here's an example: https://nodejs.org/en/docs/guides/nodejs-docker-webapp/
> This specific repo, https://github.com/the1laz/cgateweb, does not get updated frequently, but ideally the docker would check to see if the file's it's using are from the latest, most up-to-date, repo.
That is not a function of Docker, rather it is a function of a CI/CD tool that you might use to build your container image.
Just for clarification: "draxt is a jQuery-like utility module for selecting and manipulating file system's objects in node.js environment. It uses glob patterns as it's "selector engine". draxt also provides several DOM-like interfaces representing file system's objects that use promisified fs module's APIs."
If you have any programming skills or want to dip your toes into simple programming, a quick way is to use Ripple's NodeJS library ripple-keypairs (https://github.com/ripple/ripple-keypairs). At the end of the day it's the only piece of software I would trust with my private key. This library enables you to create a seed (aka the secret), generate cryptographic keys, and to derive a public key/address. I've used this method myself several times to create paper wallets. Since you already have the secret, I've skipped the step of generating one in my example:
Prerequisites: NodeJS and NPM. Get it at https://nodejs.org/en/
- Open the command line/terminal (Windows: "cmd", Mac: "Terminal")
- Create a new folder: mkdir ripplekeys
- Open the new folder: cd ripplekeys
- Initialize a new npm project: npm init (it will prompt you for input, just accept the defaults by pressing enter)
- Now install the ripple-keypairs library: npm install ripple-keypairs
With that done you are ready to use your secret (starts with an "s" e.g. s12345blablalotsofstuff) to derive a crypto keypair, and then derive the public address/key:
- Start the node command line interface by typing node then type the following commands: const r = require("ripple-keypairs") const keypair = r.deriveKeypair(YOUR_SECRET_HERE) const publicAddress = r.deriveAddress(keypair.publicKey)
- To see the public address, just type publicAddress
- To exit the node command line interface, type .exit
Happy coding!
For anyone wondering omg why? Check out Microsoft's explanation of why.
Here's my tl;dr understanding:
- Bing does lots of computational stuff and they use C++ because it's fast.
- The code needs to be easily changed, as they add and modify algorithms a lot. C++ not so good on this part.
- They want performance and flexibility, so Javascript stood out as a good choice (huge ecosystem helps).
However, they had a few extra requirements:
- Iteration on algorithms should be easy/fast
- Take advantage of multi-core
- Share memory across workers
- Minimise communication cost between threads
So either you write C++ code and have Node run it, which fails #1, or your use a cluster of Node processes which fails #3.
Napa.js is born.
Node is based on Chromium's JS runtime V8, which creates a process for every tab (this makes sure that if one tab crashes, the entire browser doesn't crash. Also why it takes up so much RAM, as making processes is more expensive than making threads within a process). Because Node is not a browser, it only runs one process. This is why Node "programmers" launch multiple Node instances in a cluster if they want to utilize multiple cores.
Electron is a step up from this, where it is not just the runtime but an entire Chromium distribution. So it doesn't need to make multiple instances, it just needs to open up a new window.
Why don't they just use a lanuage with proper threading? Because that would require learning a non-web technology and possibly gasp writing native applications.
1) basically it boils down to javascript's ignominious origins as a toy language for decorating markup. that perception has persisted even though — especially since the introduction of google chrome's javascript engine, v8 — javascript has gone through a major increase in the quality and complexity of programs that can be written with it.
2) yes. nodejs is basically v8 welded to libuv; it's great for I/O bound tasks, but suffers tremendously on CPU-heavy tasks. C# fills that role nicely, plus it has a much more mature security story (with tools like OWIN) than nodejs does. as a real-life example, netflix uses node for its UI and java with spring for its main operations.
3) yes and no; it really depends on your needs. specifically, you'd probably be using a framework like ionic, which spits out an angularized cordova app. developing with ionic can get you up and running in a frankly ridiculous amount of time — i once wrote a conference app with ionic in three days after knowing angular for about a week. i will say, however, that our shop is currently leveraging xamarin for our heavy-duty apps, though i can't offer much of any feedback on what the benefits or downsides are. either way, both technologies rely on garbage collection, so if you're making an app with larger memory requirements it's likely that both will prove a poor fit.
4) sure. for C# you'd probably want to look at .net core, which is designed as a modern, lightweight api framework (much of the bulk and cruft of .NET 4.5 and earlier has been stripped away, replaced with a much easier configuration and scaffolding story). for node, there's a variety of solutions for clustering, including their built-in Cluster module — though i've heard rumblings about it not scaling as efficiently as third-party solutions. again, depends on your needs.
I don't think you will have any pain using Node.js v6 since it is stable and well-tested and performance continues to be improved. I haven't noticed any significant package compatibility problems. In addition, Node.js v6 will be the next LTS release. If you wanted to play it really "safe" then Node.js v4 would be a reasonable alternative. More details: https://nodejs.org/en/blog/release/v6.0.0/
Make sure you always install packages with the --save option to ensure they get installed when you run npm install the next time. For example:
npm install some-awesome-package --save
I've not run into issues where deleting node_modules/ and running npm install breaks things.
npm shrinkwrap is recommend when you have verified everything is working and are preparing to deploy to production since it will lock down exact versions.
Hope that helps.
It's the first release since it joined the node foundation's incubator program, and a surprisingly long time for a major node project to go without a release. Express has been struggling a bit lately, and hopefully this release will help to assuage our fears.
I'd say that JS is too loose. Weak typing makes it really easy to do things, but it will lead to headaches. I like Python where 3 == '3' returns False. It's still dynamic, but types are enforced strongly and when your program fails, it fails quickly and descriptively unless you've explicitly disabled that behavior.
I also really dislike the tooling and looseness of practices in the Node community. A lot of projects tell you to install by doing curl http://something.com | sudo bash. This is really terrible and generally speaks to how some parts of the Node community don't give a shit about best practices.
Not to say that you can't build something that's useful and well designed with Node. I'm also not saying that every project that tells you to install in a stupid way is bad. I will say that the odds of failure under complexity are high though.
EDIT: I was incorrect about projects recommending installation via curl | sudo bash. HOWEVER, NodeJS itself advocates this terrible practice. Also, important tools like NVM offer this as their primary installation method in their official documentation. It's not fair of me to make the generalization I made, but wtf pls no don't tell people to execute random code off of the internet as root.
> Performance improvements are key in this latest release with one of the most significant improvements coming from module loading, which is currently four times faster than Node.js version 4 (Node.js v4). This will help developers dramatically decrease the startup time of large applications for the best productivity in development cycles and more seamless experience with end users. In addition, Node.js v6 comes equipped with v8 JavaScript engine 5.0, which has improved ECMAScript 2015 (ES6) support. Ninety-three percent of ES6 features are also now supported in the Node.js v6 release, up from 56 percent for Node.js v5 and 50 percent for Node.js v4. Key features from ES6 include: default and rest parameters, destructuring, class and super keywords.
What does that mean when they say modules? Does that just mean the require() function or NPM or something else?
Edit
Nevermind: https://nodejs.org/dist/latest-v5.x/docs/api/modules.html
In your package.json you put "type": "module"
https://nodejs.org/api/packages.html
You're trying to use ES modules instead of CommonJS modules
Here's a ton of information about ES vs CommonJS modules: https://hacks.mozilla.org/2018/03/es-modules-a-cartoon-deep-dive/
Regarding multi-threading, I was kind of surprised how easy it was to convert my first serious Node.js application from single-threaded to multi-threaded with the inbuilt Cluster functionality. I was expecting complicated load balancing, resource sharing problems and memory access violations. Instead I saw my app running on 8 separate threads without any changes! The only thing I had to refactor was the socket.io module - I had to introduce a state-sharing mechanism, but it was pretty easy to achieve with Redis. I guess my expectations were kind of biased because my last multi-threaded app was written in C++ and used pure std::thread.
For import semantics, there is a hook that can be implemented to do this -- https://nodejs.org/api/esm.html#esm_loader_hooks -- this allows changing how a file is imported - I believe it can change from where it is loaded as well (i.e. to load from a package manager's cache instead of node_modules)
Of course that only applies to --experimental-modules, and mjs mode. For regular 'ol CJS the static resolution is less of a problem - but I'm pretty sure the way they've done it with using -r allows for performing changes to Module._load before the entrypoint and nested requires have had a chance to call into it.
Your link to the Node docs for worker threads is a 404:
> A tiny wrapper for turning Node.js threads in easy-to-use routines for CPU-bound.
I think you probably meant this to be: https://nodejs.org/api/worker_threads.html
The SSR is your problem #1. Even the simplest pages take up to 10!!! seconds for me to load. But it should not be a bottleneck, usually, the SSR itself should take milliseconds. It may be as well that the hardware of your server can't keep up with the load. You need to find a way to profile your SSR and measure CPU usage, unfortunately, I have never used Vulcan, so I can only offer a link I found on google https://nodejs.org/en/docs/guides/simple-profiling/ Besides the SSR and hardware it may be that your web server or app are misconfigured (to handle a little load), try to read the documentation/blogs regarding recommended production configuration.
> but you very rarely need those in the first few seconds of using the site.
That is a very low bar. Your initial page should load within 1 second and DOMContentLoaded should happen around 3 seconds.
I just opened the site and first thing I see: https://i.imgur.com/HihYO0I.png
PS: Also your HTML is 1.5Mb which is suspiciously a lot. I see that most of it is some de/hydrated state of the app it is possible that the code that generates that initial state is including a lot of stuff that is not needed so it takes very long time.
This is pretty misleading. Its trivial to run a Node server across multiple cores with clustering. If you use a process manager like PM2 its even easier.
"With node, that's not a thing, so each client has to wait it's turn to retrieve data."
This is just false. Even without clustering, one of the main advertised benefits of Node is asynchronous by default IO. I'm not a huge fan of Node for most things personally but performance isn't this black and white.
https://nodejs.org/api/cluster.html
EDIT: @petepete made a similar point as I was typing this.
Depending on your usage, using buffer's instead of typed arrays might be possible. Their api's are now virtually identical, with a couple of caveats that may or may not work for your specific usage.
Replacing the new Uint8Array(1000000) in your code with Buffer.alloc(1000000):
let a = Buffer.alloc(1000000) const start = process.hrtime(); const runs = 1000; for (let i = 0; i < runs; i++) { a.fill(0); } let ms = to_ms(process.hrtime(start)); console.log(ms, "ms,", runs / ms, "op/ms");
function to_ms(hr) { return (hr[0] * 1e9 + hr[1]) / 1e6; }
Results in about a 50x performance improvement:
37.491576 'ms,' 26.672658412652485 'op/ms' 39.846483 'ms,' 25.09631778543667 'op/ms' 39.137584 'ms,' 25.55088735165666 'op/ms'
In NodeJS and other CommonJS environments, a file's code is already implicitly wrapped in an IFFE, so doing so yourself is generally unnecessary. Plus, there are ways to get around function scope anyway even if you do.
- Get a code editor - Sublime, Atom are probably the most commonly used for JS. They are both free.
- Download LTS version of Node.js and install it - https://nodejs.org/en/. This is free. It's a JS runtime and allows you to run JavaScript outside of a web browser if e.g. you want to make a JavaScript server.
Don't pay any money for anything JavaScript related. All the resources you need are available free online. JS runs in your browser (Chrome, Firefox, Safari, Edge) so you already have runtime on your computer.
The free course on https://www.codecademy.com/ is pretty good for getting started.
The Mozilla Developer Network (MDN - https://developer.mozilla.org/en-US/docs/Web/JavaScript) is probably the best reference for JS on the web. You don't need to buy any books.
Good luck!
Send me a PM if you have any questions.
With all of the dogma over threads and event loops, I'm very surprised that no one has mentioned the cluster module.
For anyone familiar with multiprocessing, it's a tad confusing how it duplicates sockets in children as though they are threads, but it's the way to go if you want to saturate all of the cores in the host.
I regularly see confusion in this sub regarding node, async, and how it relates to cores, threads, processes, HTTP servers, and even other platforms. If anyone is interested, I'm considering giving a talk (or two) at Nodevember this year.
>why prevent me from connecting to other sites?
Let's consider the options for what node could do in this situation:
- Proceed silently, and accept RC4 even though it is insecure. In this case, the user connects insecurely to a website without realizing the connection is insecure. This is almost certainly not what they wanted.
- Do not accept RC4 by default, and throw an error back to the user. If the user understands the consequences and still wishes to connect, they can override the accepted ciphers.
Node chose option 2, and I think this a reasonable, better, safer option. You aren't being prevented from using RC4 at all; it's just turned off by default. You can easily override the accepted ciphers globally with a command-line argument (as you mentioned), or for an individual connection by passing the options object to the corresponding <code>tls.connect</code> call.
I could see your argument if node completely did not allow any RC4 use, but that's not the case here. It disables them by default, which is what virtually everyone would want, and for the few people who still regrettably need to use RC4, they can enable it with a connection option or a command-line argument.
Node is not tied to single-threaded apps (though it used to be when it first came out, and when multiple thread support was released it was kinda a "silent" thing, even though it's huge). You can write multi-threaded code, it's just more work in that you have to manage the communication channels between threads.
The docs, and there are multiple libraries that handle much of the management for you.
From the docs,
> The correct use of 'uncaughtException' is to perform synchronous cleanup of allocated resources (e.g. file descriptors, handles, etc) before shutting down the process.
https://nodejs.org/api/process.html#process\_event\_uncaughtexception
There's also a ton of warnings about an application entering an undefined state -- I would imagine any async operations you perform there have a possibility to not succeed.
You can run Node on multiple cores, for most scenarios, via a child processes or a process manager like PM2
I'm afraid If you are not familiar with JavaScript there are many pitfalls when coming from OOP languages like Java, even for an experienced programmer.
That being said the functionality you need is extremely simple, you just need to use expressjs framework that you can download with npm. You can find many tutorials on making an API with express. I would just go along with them and make desired changes, you don't need to understand everything. Also Filesystem is built into node.
Per the other poster, I also got bored and wrote a solution. More functional programming style as practice for me.
Since you presumably don't want to paste your private key into a website (Runkit, where /u/atrizzle has hosted his code), here are the steps to run this little javascript on your own machine.
- 1) Download and install Node & Npm from here.
- 2) Fire up a node terminal and install ethereumjs-utils:
npm install ethereumjs-utils - 3) In the same directory, create file called
whatever.js - 4) Paste the below code into the file, making sure to substitute your partial private key and public address before hand at the bottom.
- 5) Run that file in Node:
node whatever.js - 6) Marvel when your private key appears on the screen!
const { privateToAddress } = require('ethereumjs-util') , chars = '0123456789abcdef'.split('') let key
const getKey = (partialKey, addr) =>
chars.some(i => chars.some(j => chars.some(k =>
checkKey(0x${partialKey+i+j+k},addr)
? (key = 0x${partialKey+i+j+k}, true)
: false))) ? Private key found!\n${key} : No private key found :(
const checkKey = (key, addr) =>
addr == 0x${privateToAddress(key).toString('hex')}
console.log(getKey('YOUR-PARTIAL-KEY-GOES-HERE', 'YOUR-PUBLIC-KEY-GOES-HERE'))
Since node is single-threaded, you can use node cluster to run one process per CPU on a single server, like this:
https://nodejs.org/api/cluster.html
If that is still not enough to handle the load, you can set up multiple servers and load-balance with HAProxy.
You can write Reddit bots in any language you'd like. I wrote one in PHP yesterday. Javascript is a fine language for writing a Reddit bot, especially in combination with Node.js. You should be able to find examples online.
Promises are currently the most popular solution for asynchronous programming in JavaScript
And if you're using node 7.10+, you can also use async/await which is syntactic sugar for working with Promises.
And if you're using node 8+ you can use util.promisify to convert a callback style function to a function that returns a Promise.
It's currently a bit of a challenge until Wildbow gets around to editing and publishing a proper ebook.
- Install the Current node.js and make worm-scraper work
- Install Calibre, add the generated epub to your library and convert to mobi
Then you sync over usb, or set up an email account for Calibre to use to drop it on the send-to-kindle email address.
> But it is a single threaded framework, so we should not use it for cases where the application requires long processing time. If the server is doing some calculation, it won’t be able to process any other requests. Hence, Node.js is best when processing needs less dedicated CPU time.
Uhhh ...
Node is able to fork child processes, thus taking full advantage of a machine's cores (minus one core for the master process which is responsible for managing forked child processes).
Check out the nodejs LTS schedule here: https://github.com/nodejs/LTS
The README does a great job explaining the release cadence going forward.
Here is a quick overview of the versions that can be installed right now:
v4 is the current active LTS (Long term support) release. It is meant to be a secure, stable version that will still receive security patches and will not have breaking changes for 18 months (until April 2018). This is nice for large organizations as they tend to move slower when upgrading. It allows them to plan upgrades well in advance and gives them certainty that breaking changes will not be introduced.
v5 was latest non-LTS "odd" release. It was meant for folks who wanted the latest cutting-edge features of node who didn't mind the lack of long term support and possible regressions. This version is essentially dead now since v6 is now available as the "latest release".
v6 is the latest release. It will become the new LTS release on October 1st. Until then, it will still get new features and could have regressions.
v7 will be created October 1st and will be in the same boat as v5 was... cutting-edge features with no long term support.
According to the release announcement for v6: > * Stay on or upgrade to Node.js v4 (currently at v4.4.3) if you need stability and have a complex production environment. > * Upgrade to Node.js v6 if you have the ability to upgrade versions quickly and want to play with the latest features as they arrive. > Note that while v6 will eventually transition into LTS, until it does, we will still be actively landing new features (semver-minor). This means that there is an increased chance for regressions to be introduced..
Check out the rest of that blog post for the new features in v6: https://nodejs.org/en/blog/release/v6.0.0/
Also check out http://node.green/ to see all the cool ES6 features that come with v6 (99% complete)!
Yep, Node even tells us so. If it's stable, you don't need to use a flag. harmony flagged items aren't even "Staged" yet.
> All shipping features, which V8 considers stable, are turned on by default on Node.js and do NOT require any kind of runtime flag.
>Staged features,which are almost-completed features that are not considered stable by the V8 team, require a runtime flag: --es_staging (or its synonym, --harmony).
>In progress features can be activated individually by their respective harmony flag (e.g. --harmony_destructuring), although this is highly discouraged unless for testing purposes.
once you understand the concepts (loops, functions, syntax, etc.), the best way to learn is actually build something. Most people do a program that spits out fibonacci sequence or a calculator or a simple webpage to take user input.
This is what they teach you in the first couple of years in college; the basics. Then you get into the more complex stuff. Some college programs (the good ones) ask you to build an application from scratch. From scratch is pretty dumb when there are many frameworks out there to be used. I would suggest trying to build an app with django (https://docs.djangoproject.com/en/1.9/) and also look into nodejs (https://nodejs.org/en/). Of course, along the way you will have to learn some html, css, and jquery but it comes with time. That's the biggest thing. You have to invest the time into figuring it out. If you get stuck trying to figure out how to logically do something, ask questions but in the real world you have to be able to google and find the answers. This doesn't mean copy/paste code. This means look at examples and figure out how they did it and maybe improve it.
node already has a standard library: https://nodejs.org/api/
For module discovery, focused packages are easier to find than all-in-one grab bags: https://github.com/substack/node-mkdirp/issues/17#issuecomment-5863086
Documentation, tests, and contributing is also easier with separate packages when the versions of packages can iterate independently of one another. With a grab-bag standard library, if one function changes its signature in a breaking way, the entire package should update its major version, even though each function is relatively independent.
From what I've seen in sprawling "batteries included" approaches in other languages, standard libraries are where software goes to die. Bugs calcify into features and you can't ever break an API because versions are completely coupled. Better libraries emerge in the ecosystem, but the standard library has to either ignore them to focus on stability or take in every new idea, breaking frequently and having a meaningless release cycle.
If you want to introduce curation, using the module loader is a terrible idea. There are so many other better ways.
Could be session management - SIDs, tokens, etc.
Though, really, seriously, use the fucking crypto builtin, people. Seriously, it's right there. Math.random() is just for cheap "randomness", as in I-need-to-shuffle-banner-images random.
Some good answers so far, I'll just expand on some of them.
AngularJS - someone mentioned this being the most popular, and with good reason. Its power is in its ability to do two-way data binding. You have a gmail account? Ever see your inbox UI pull up new email without having to refresh its page? That's what two-way binding is; it updates the UI with new data (in a ViewModel, part of the MVVM design pattern). Angular 2.0 will incorporate aspects of React -- namely the idea of using a "Virtual/Shadow DOM"
React - Facebook's brainchild. It's a framework for rendering only the view. Ideally, you want to use this in addition to another backend framework like: Backbone, Knockout, or jQuery(it has the capabilities) or whatever. It is causing a paradigm shift in how pages render by keeping a snapshot of in something called the Virtual DOM. The long and short of it is: React will only render parts of the page where the data has changed. Very performant.
Knockout/Backbone - I'm grouping these two together because I'm not an expert, but I have used them enough to know their application. They are great back-end frameworks for data binding, each with their own philosophy. I would say the primary difference is that knockout has two-way binding capabilities like Angular.
You wana get into some Javascript frameworks? Now is the time. It's experiencing a crazy boom right now especially with the advent of NodeJS. This is a whole other world with its own continent of frameworks.
Let me know if you want me to clarify anything, but those seem to be the bigger frameworks.
Node exposes the crypto module which is basically a wrapper for OpenSSL. This means all of node's crypto happens in native code land rather than in javascript land and therefore should always be faster than any pure js implementation.
Super!
​
Für alle nicht Coder:
- code in ein skript.js kopieren
- in einen Ordner kopieren-
- Node installieren (wenn nicht schon geschehen: https://nodejs.org/en/download/)
- Terminal öffnen
- cd ORDNERPATH
- "npm install follow-redirects" eintippen
- "npm install uuid" eintippen
- dann node skript.js ausführen
That's the results of `util.format` which is a format that nodejs uses for logging objects via the console.
https://nodejs.org/docs/latest-v14.x/api/util.html#util_util_format_format_args
For 1 and 2, there isn't really anything specific to JavaScript itself which maps to Python's __name__, however, with NodeJS's require (not JavaScript running in the browser) you can check to see if require.main is equal to the module to get something similar:
if (require.main === module) { // this file was run directly and not imported as a module }
For 3, in JavaScript you would use this instead of self. However, unlike Python, this is an implicit value that you don't have to include in your parameter list. It's always available and its value changes depending on context.
Something to be careful of, however, is that class methods don't auto bind their instances to this like python does with self. If have a method that you call without its instance, it won't remember what that instance is for the value of this
// JavaScript class a { meth () { console.log("inst:", this) } }
inst = new a() inst.meth() // a object meth = inst.meth meth() // undefined
vs
# Python class a: def meth(self): print("inst:", self)
inst = a() inst.meth() # a object meth = inst.meth meth() # a object
Otherwise, there are a lot of similarities. Motts_ points a few of these out, particularly in the case of classes, in this graphic: https://imgur.com/p9Kw815
Kind of true though. Node.js has installers, binaries, or you can compile from source. Compiling is arguably the most complicated way to do it, and even that's an essential part of programming.
The gist of the article is off; most programmers understand that there is a vast array of areas of expertise and that a embedded dev doesn't necessarily know anything about front end development and vice versa. It still doesn't override the need for basic self-help and resourcefulness, which are probably the most important aspects to being a successful developer.
Yep. You can even start on a Raspberry Pi (the one with 1 GB of RAM and 1.2 GHz CPU Clock).
I'd highly recommend a Linux-based OS for this purpose, since they are way lighter (50 MB - 1 GB RAM usage), they'll help you learn, they have man pages for kernel functions and they are just the best for coding.
Other than that, learn git. You don't need Java in 2021. C++, Python, Node.js and Rust are basically all you need nowadays.
For GUI frameworks, I'd recommend GTK/QT (C++, Python), NeutralinoJS (Node.js) and Flutter (Dart, Rust (experimental)).
Here are some tips:
- C++: Don't be afraid of
Makefiles, they make everything easier - Python: Please use
venv - Node.js: Read the Official Documentation before you search on the internet. It covers everything Node.js itself has to offer. If you are trying to do something with a package but can't, read the package's documentation. If you can't find it's documentation or the stuff you want to use are undocumented, read it's type definitions (Control+Click on VSCode by default). They tell you a function's arguments, what it returns, what should be in an object, etc. Try to avoid heavy dependecies if you can. Just don't touch Electron
- Rust: Read the beginner's guide.
- Dart: Never used it :/
git: Use a.gitignore. Read the manual pages (Linux-based Operating Systems only, access withman git). They help you a lot. Don't just run random commands off of webpages.
as per the spec:
https://nodejs.org/api/timers.html#timers_settimeout_callback_delay_args
When delay is larger than 2147483647 or less than 1, the delay will be set to 1. Non-integer delays are truncated to an integer.
So it's still constant time, but that does expose a limitation in the accuracy of the sort algorithm.
As mentioned, you're only serving the html file right now. When a browser makes a request for the index, that's all they get on the initial page load. After the index.html file is received, it then starts getting parsed by the browser from top to bottom. Whenever it sees that it needs a new resource(like a .css or .js file), it has to make a new request to the server to retrieve it. In this case, the browser is making a request to localhost:3000/ to get the HTML, then the HTML tells the browser to send another request for your CSS at say localhost:3000/css/styles.css, or wherever you're putting it. If you go into the developer console and view the "Network" tab you can see all this happen on page load.
If you don't want to use a framework like express or hapi, you're going to need to create a control flow for your routing to determine which assets to serve. See the http.IncomingMessage class documentation, specifically message.url to see how to access the URL on the request.
It actually has.
Previously nodejs was able to load ESM if you file was named with the .MJS extension (.JS was loading module through commonJS).
In Node12 you can activate the --experimental-modules flag. JS files will load ESM module and if you still need to use require() you can name your file with the .cjs extension.
Their is some limitation like __dirname doesn't working in ES module, or some package not correctly bundled yet, but mostly it work correctly.
https://nodejs.org/api/esm.html
Node clustering mode requires additional code in your main app entry point: https://nodejs.org/api/cluster.html
Multiple execution requires app server (like PM2 or phusion passenger or caprover) with the appropriate configuration turned on.
Which one is better? If you just need to have multiple instances because you're expecting a lot of traffic - multiple execution mode will do the trick - it is simpler to deploy and app server does everything for you. If you want to have full control over what are the responsibilities of each nodejs workers - implement clustering. Clustering gives (in principle) more power. There are a few examples of using clustering node in documentations (like messaging or server share).
If target path is guard path or subpath, permit.
Otherwise deny.
Never try to parse the path itself. There's so many ridiculous ways to get around that
Just compare the end result to the jail.
The easiest approach is path.relative/2
haha I was expecting this comment. --- Article & PM2 author here
Yes PM2 depends on Node.js and his asynchronicity makes a good fit for a process manager. Supervisord is coded in Python, why not a process manager in Node.js? :) Later we'll see to embed the node binary directly (https://nodejs.org/dist/latest-v10.x/)
Anyway, beyond the languages questions, PM2 will help you for sure, have a look and let me know.
It's my first trial to make PM2 support properly another language, and depending on the feedback of the Python community, we would love to bring the value and concepts we already built on Node.js for Python that time.
I'm speaking about some concepts like "custom actions"; custom actions is a way to interact asynchronously with an at application, at runtime. This allow to modify the behavior of an application without having to restart it. It's a sort of REPL system. Think database switch in real-time, queues management, in-memory structure inspection or even variable mutations. The only issue here is that Python is not asynchronous by nature, but I'm really excited to see efforts & standards growing, like asyncio.
We're also interested to maybe bring some kind of "cluster mode" we already built for Node.js, allowing 0 downtime reload and hot things like that, with minimal configuration, that's our credo.
​
Here's the main Node.js source code file: https://github.com/nodejs/node/blob/master/src/node.cc
Line 185 and 186 - you can see some variables there for thread pool sizes. Line 2078 calls "is_main_thread()" - implying there is more than one. Line 3194 creates an actual thread.
Simplifying this a bit, but Node.js works like this: asynchronous operations can spawn new threads. For example, a network socket. These operations run in parallel to the main Node.js thread. When the worker threads need to execute a callback or Promise in the main thread, they post a message to a queue. Node.js' main thread constantly processes that queue and executes JavaScript in the main thread.
Some people even write their own Node.js addons in C or C++ to do multithreading in this manner for performance and scalability reasons.
One of the main components of Node.js is a library called LibUV - a cross-platform multithreading library. It handles a lot of the "magic" described above. Take a look at https://nodejs.org/en/docs/guides/dont-block-the-event-loop/ Under the section "Why should I avoid blocking the Event Loop and the Worker Pool?" they describe the internal threadpool.
I think what most articles on the internet mean to state when they say "Node.js is single-threaded" is that the JavaScript code that runs inside of Node.js runs on a single thread. For most people that's where the largest chunk of their processing occurs, but I've worked on applications where that isn't true. As an example, we've tuned the thread pool sizes to optimize for a larger number of database connections in production environments.
Worker threads are implemented in the latest version of node (10.5.0) behind the --experimental-worker flag.
On top of Leaflet previously mentioned, knowing about GDAL is great, if you haven't been using it previously. Some of the surprisingly popular hits we've had have been simplistic applications that leverage Leaflet as a quick, responsive, and attractive map-based interface with a GDAL/python (maybe GRASS) back-end that provides quick analysis and outputs. Joined by node.js, we have created some useful tools that meet smaller highly customized needs with minimal development time. Node.js is one of the coolest things I've worked with recently and a popular flavor of backend to use right now. Not as beginner friendly, but something to look into next for a roadmap. The way its setup, is probably going to keep me as a long time user for a while.
Best part about this whole stack is it is all open source! :D
There is a Chrome extension called Scratch.js - it allows you to write and edit multiple lines of code and then execute them in the Chrome dev console.
If you want to work with actual JS files, you may want to install node (https://nodejs.org/en/). Once set up, you will be able to run any proper JS file with "node <myfilename.js>" in your command line.
In programming, spawning a "child process" (AKA a program created through another program) of a similar type to the original can sometimes be called "forking". Example
A "zombie process" is one which has finished, but because of some other circumstance (in this case, probably because the child process hasn't been garbage collected), it is still in the list of running processes.