Develop Reference

What exactly does "Javascript can be run outside the browser" mean in plain English? [duplicate]

This question already has answers here:
What is client side javascript and what is server side javascript?
(8 answers)
Closed 9 months ago.
I'm learning Javascript, and I keep seeing this phrase being used when speakers are explaining NodeJS and the V8 engine in relation to Javascript. I know because of Node, we can run JS "outside of the browser," but what does that mean? Oftentimes, instructors use terms I don't know yet (like "server-side scripting") to explain, which makes it difficult to understand.
From what I know so far, it means that you can use JS like a back-end language..? Whereas "running inside a browser," means you can only code visual/front-end interactions, things only users see. Am I correct?

Yes you are more or less on the right track. The V8 engine is what powers both chrome and nodejs. When used with nodejs, it provides a runtime environment for javascript that allows JS code to be run "outside the browser". Traditionally the only place javascript could run was in a browser that implemented support for ECMAScript (all major browsers). But then along came node.js, which pulled out the critical v8 engine from chrome, and mixed with LibUV for C++ support, created the first runtime that successfully allowed Javascript to run without a browser to run the code. With Node.js (and Deno if you are curious) we can implement a variety of "back-end", server-side, code. Think anything you could program in another language now available to be programmed in Javascript. Node.js and Express js are absolutely great for running web servers, microservices, and many other services independent from a browser run time environment.

Originally, the ability to process the JavaScript language was something that Netscape added to their browser so that it could process not only HTML and CSS, but also JavaScript. Microsoft followed suit and so did all the other browsers. That's what we call running JavaScript within the browser.
But (as an example) Node.js is a command line runtime that includes the core JavaScript runtime, but extracted from the Chrome browser itself. So, with Node, you have the ability to write and run JavaScript, but you aren't running it inside of a browser and therefore you don't have the Document Object Model (DOM) or the Browser Object Model (BOM) available to you because those are APIs that are native to browsers.
But you do have the core JavaScript language and can create applications that do all sorts of non-browser tasks.
You'll find that many other development environments and tools have similar set ups, where the core JavaScript runtime has been added so that you can develop with JavaScript, but outside of a browser.

Are Runtime environments and Compilers/Interpreters the same?

I'm just getting started with Node.js and I have quite a bit of background in Python and C++. I got to know that Node.js is a runtime environment but I'm having a rough time understanding what actually it does to a code that makes it different from a compiler. It would be better if someone can explain how specifically runtime environments differ from typical compilers and interpreters.

Let's take it this way:
Node.js is a JavaScript runtime built on Chrome’s V8 JavaScript engine.
V8 is the Google Javascript engine, the same engine is used by Google Chrome.
There are other JS engines like SpiderMonkey used by Firefox, JavaScriptCore used by Safari, and Edge was originally based on Chakra but it has been rebuilt to use the V8 engine.
We must understand the relationship first before moving to how the V8 works.
JavaScript engine is independent of the browser in which it's hosted. This key feature enabled the rise of Node.js. V8 was chosen to be the engine that powered Node.js.
Since V8 is independent and open-source, we can embed it into our C++ programs, and Nodejs itself is just a program written in C++. Nodejs took the V8 and enhanced it by adding features that a server needs.
JavaScript is generally considered an interpreted language, but modern JavaScript engines no longer just interpret JavaScript, they compile it.
Since you have a C++ background, C++ performs what is called ahead-of-time (AOT) compilation, the code is transformed during compilation into machine code before the execution.
JavaScript on the other side is internally compiled by V8 with just-in-time (JIT) compilation is done during execution. While the code is being executed by the interpreter it will keep track of functions that are called very often and mark them as hot functions then it will compile them to machine code and store them.

A compiler is a program that converts code from one language to another. In Java for example we have a the java compiler javac that you can run on your .java files to compile your code into platform independent java file (can be understood and executed by any jvm).
Since you are new to JavaScript, you will encounter the transpilers (like babel) that turns your next generation JavaScript code into a legacy JavaScript code that can be handled by all browsers (even old ones).
A runtime is a more vague concept. It can go from being a set of functions to run a compiled code on a specefic operating system to being the whole environment in which your program runs.
For the case NodeJS, it's the environment on which you can run a JavaScript program out of the browser. It took the V8 Engine of Chrome that runs JavaScript on the Chrome browser and made it available everywhere. That's how JavaScript moved from being a Client side Programming Language that runs only on the browser to a server side Programming Language that can run on servers equiped with the runtime environment NodeJS.

A few simple points that might help:
C/C++ code will be compiled by the C/C++ compiler into the machine code and will not need any runtime environment to run (mostly, except the run-time libraries)
Python code needs Python interpreter to execute it. As you say you have background in C++/Pythons you must be familiar with all these nitty-gritty
JavaScript was meant to run in the browser and it does mostly, however some smart folks thought of running it outside the browsers and they created the JavaScript execution engine (which is kind of stand alone JavaScript executor) and Node.js is just one of them. It simply runs the JavaScript code outside browser on it's own. The execution is still interpretation of JavaScript code so it is just an interpreter with hell lot of support functions for managing the runtime dependencies, package management, etc.

Launch an external JS engine with forwarding data from the browser

I want to analyze a large and confusing JS code. The code is heavily obfuscated and even tools like JStillery cannot work with it.
I would like to somehow build one of the open JS-interpreters, run it outside the browser and debug in more traditional ways, if necessary, applying patches inside the interpreter.
Unfortunately, the code uses DOM and cannot be executed without a browser.
The question is: are there any known techniques to take any external engine (such as V7, V8, DukTape, JerryScript, MuJS, quad-wheel, QuickJS, tiny-js, ...) and run code inside them that contains calls to DOM and other browser parts?

There are pure-JavaScript implementations of the DOM, such as https://github.com/jsdom/jsdom. Not sure how useful that is for your use case, but it does address your primary question: it allows you to run JavaScript that assumes a browser environment outside the browser environment.
I believe jsdom is fairly accurate in its implementation; there are other implementations out there that are more mock-like. Either way, there are probably some remaining differences, so heavily obfuscated code may well include mechanisms to detect emulated environments...

Difference between JavaScript shell and node.js

I have been developing in Node.js for some time now.
Today, I came across this article
Introduction to the JavaScript shell - Mozilla | MDN
It talks about javascript shell and goes onto say that it can execute javascript programs from a file as well.
I was able to research and understand V8 and spydermonkey.
I want to know the difference between Node.js and the javascript shell talked about in this article since it says that the shell can execute javascript programs on its own.
Do they only differ in that the node.js uses a V8 engine while the other uses a spidermonkey?
if so then why is it that node.js is so popularly used for writing Server Side JavaScript?
I couldn't exactly find what I was looking for on the Internet. either google showed me difference between spidermonkey and v8 or some forums on "difference between javascript and node.js" and since I am a new developer its really hard for me to understand,
Can spidermonkey be used to achieve the same?

JavaScript is a language.
node.js is not a language or a special dialect of JavaScript - it's just a thingamabob that runs normal JavaScript.
All browsers have JavaScript engines that run the JavaScript of web pages. Firefox has an engine called Spidermonkey, Safari has JavaScriptCore, and Chrome has an engine called V8.
Node.js is simply the V8 engine bundled with some libraries to do I/O and networking, so that you can use JavaScript outside of the browser, to create shell scripts, backend services or run on hardware (https://tessel.io/).
Credits : https://www.quora.com/What-is-the-difference-between-JavaScript-and-Node-js
I hope that helped clearing out the basic difference between them. The specifics you required are not answered here.

Node.js enables JavaScript to be used for server-side scripting, and
runs scripts server-side to produce dynamic web page content before
the page is sent to the user's web browser.
Source: https://en.wikipedia.org/wiki/Node.js
Obviously the shell can not serve HTML web pages by itself.
In addition, Node.js is asynchronous, and non-blocking, meaning it can serve multiple requests and host multiple processes simultaneously.
EDIT: provided source.

Where is the main event loop in the Firefox source code?

I am looking through the Firefox source code and trying to determine the source for the main loop that executes all the event handlers in Javascript.
I have looked over this overview of the directory structure, but I still cannot find the event loop.
Which source lines should I look at to find the main event loop?
Update: I am building and running Firefox on Linux x86_64.

Disclaimer: I worked on the Chakra JavaScript engine between 2014 and 2015 while at Microsoft.
Firefox's JavaScript engine is called SpiderMonkey, and can be considered a separate project - and it can be used by other applications too ( https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/How_to_embed_the_JavaScript_engine ).
Modern JavaScript engines are JIT-based: they don't interpret code in a giant loop - instead they compile JavaScript functions into native code - effectively their own program, and this dynamically generated program will have its own event flow - but it isn't necessarily a "loop" - and there isn't necessarily "one" individual program either - because it depends on the JavaScript hosting environment: a web-page can run multiple JavaScript "workers" simultaneously (acting as different threads - this is beyond JavaScript's current asynchronous model). Also note that "Firefox" is just a wrapper around Gecko - and Firefox runs multiple Gecko instances side-by-side, and in different runtime worker processes.
That said, pretty much all JIT JavaScript engines still retain their interpreters - Chakra does - because the JIT process takes a while, so they will initially run script in interpreted mode for immediate results - and the interpreter part of the engine may as well be a completely independent JavaScript engine implementation (ignoring the parser and standard library components).
It's been almost 18 months since I last worked with the Chakra source code (it's open-source now) but from what I remember (and without breaking my NDA) the only real main "loop" in Chakra was the interpreter loop (a giant switch statement for the current opcode enum value) - the event handlers were handled through asynchronous IO - so it's actually up to the Chakra host to provide the asynchronous IO functionality - so in short, there is no "event loop". I'd be surprised if Firefox's SpiderMonkey or Chrome's V8 didn't work on the same basis.