Develop Reference

Read codebase of javascript function

I just realize that I can use the function console.log to read a codebase of any javascript function. Anyone how it happens? and what behind the sense of this action (read codebase)
Example:
Open chrome console and paste this code
function superMan(){
var i=i+1;
var j=i+1;
}
then you use the function console.log like console.log(superMan) and you can see the codebase of SuperMan

In javascript, When a program is run a execution context is created. There are 2 phases in which its created namely below.
Creation phase
Execution phase
What you are referring to in the question is mostly related to the creation phase. In this phase all the variables are declared and initialized to undefined ( incase of var) and for variables with let and const they are declared in the Temporal Dead Zone and are unreachable and only reachable when the code is executed in execution context.
For functions(specifically Function statements and not function expressions) these are taken in as it is in memory and stored. So, when you try to log in the function in console.log it shows the variable in memory. This will be also true for function expression once the execution runs over it(since before its treated like a normal variable and not function). They will be showed as it will now be pointing to the function directly assigned to that variable. Also, You need to understand function in Javascript are first-class functions meaning it can be passed and treated like a normal variable (containing a number) and so.

It's part of the spec but a good reason to use it is in edge-cases where the code of the function could be important to its execution (usually for an API, interface or some form of abstraction) where you need to know a bit more about the function before acting upon it. There are many use-cases, but it can be particularly useful to try to detect and handle edge-cases for a transpiler (the code you write isn't verbatim to the code that the browser sees)

pre-parsing and execution context

I am trying to better understand what exactly happens when, for example, the V8 engine parses code and defines an execution context for a function.
What most JS courses and books typically discuss is what happens during a "creation phase" and an "execution phase". The language used for JS engines is different: pre-parsing, parsing, AST, baseline and optimized compiling.
My understanding based on my reading so far, although I may be very wrong, is that the "creation phase" is the same as pre-parsing the source code, where the parser does the bare minimum in terms of variable and function declaration so that the code can run. For example, it would not attempt to build an AST for a function before it is invoked in the code. When a function is invoked from the global scope, it will then be pre-parsed (creation phase) and then fully parsed (execution phase). A new execution context with lexical environment, etc. will be created during pre-parsing. This process would then be repeated for each nested function.
Question 1: Are my assumptions correct? Is pre-parsing===creating phase.
Question 2: This is the bit that I am mostly unclear about. Does pre-parsing create a function object for a function that is not yet invoked. Is the function object shown in Chrome dev tools at the debugger below, actually created based on pre-parsing alone. Are the argument and caller properties then just updated during the subsequent execution phase.
let fun1 = function(name){
let newname="Tom";
console.log(name, newname);
};
debugger
fun1("John");
//fun1 function as it appears in the dev tools before it is invoked (and presumably before it is added to the execution stack)
Script
fun1: ƒ (name)
arguments: null
caller: null
length: 1
name: "fun1"
prototype: {constructor: ƒ}
proto: ƒ ()
//fun1 function after it is invoked and added to the execution stack.
Local
name: "John"
newname: undefined
this: Window
Script
fun1: ƒ (name)
arguments: Arguments ["John", callee: ƒ, Symbol(Symbol.iterator): ƒ]
caller: null
length: 1
name: "fun1"
prototype: {constructor: ƒ}
proto: ƒ ()

What most JS courses and books typically discuss is ...
I don't know "most JS courses and books", and that reference is not specific enough to look it up. If you want a specific comparison to a specific usage of terms somewhere, please specify the source you are referring to.
When a function is invoked from the global scope, it will then be pre-parsed (creation phase) and then fully parsed (execution phase).
Pre-parsing is only useful when it happens (long) before the function is invoked or fully parsed -- that's why it's called pre- parsing.
Parsing is not part of execution. Parsing happens as the first step of compiling (or you could say: "right before compiling"; same thing), which must happen before execution can begin. (At least that's the case in modern high-performance engines; you could build an engine that doesn't compile anything but directly interprets source code, which would mean that effectively parsing and executing would be the same thing, but that would be much slower for everything except trivial scripts.)
Question 1: Are my assumptions correct? Is pre-parsing===creating phase.
Generally speaking, there is no close correspondence between high-level conceptual phases of JS execution, and engine-internal implementation details.
Pre-parsing is (part of) an entirely optional performance-enhancing implementation strategy. You can turn it off if you want -- things will be slower, but observable behavior will be the same. The basic idea is that the engine will generate code "lazily", i.e. when a function is invoked the first time (because generating all code "eagerly" up front would make for annoyingly slow startup). In order to be able to do that, it must solve the problem "here's a couple hundred kilobytes of JS code, compile function fun1 please", so it must know where "fun1" is. That's the information that the "pre-parsing" step generates: it basically creates an index mapping function names to the place in the source text where the respective function is defined.
(As another entirely optional performance-enhancing implementation strategy, modern engines make sophisticated choices about internal variable representation/allocation, which in order to produce the correct behavior require pre-parsing to generate additional data about variables referenced from other functions; so if you look at the implementation, you'll see that it is quite a bit more complicated than just identifying function <name> { ... } ranges. You're correct that pre-parsing doesn't build an AST, but it does build scope chains for this reason.)
Question 2: Does pre-parsing create a function object for a function that is not yet invoked.
Pre-parsing, full parsing, and compiling all only affect the code for a function. They are unrelated to the function object itself. When you have a function object, you generally can't tell whether it has been pre-parsed or not, whether its code has been compiled or not, or whether its code has been optimized (=compiled again, later, taking type feedback into account) or not. The function object is created by executing the respective outer function (which may be the code in the global scope). It has internal, hidden references to metadata (code and otherwise) required for its execution.
To emphasize this again: all the details about when-does-the-engine-parse/compile-what are internal implementation details that are different between engines and change over time (as the respective teams improve their engines), so they generally must not affect how your program is executed.

Strategy for JavaScript interpreter implementation (functions) -- am I making sense?

I'm writing a js-to-js interpreter (that is, a Javascript program that takes a Javascript program as an argument and executes it). I'm not trained in compiler theory, I'm just faking it. The expression-evaluation machine is working (using a kind of clunky operator-precedence algorithm), but not yet for functions. So here's my question.
The way I'm thinking of implementing functions looks something like this: When a function is invoked, I'll create a namespace / context for it, also allowing access to the namespaces of enclosing functions and the global namespace.
I'm not yet implementing closures, but these namespaces are designed to work for them. Basically, as I understand it, closures are just the way Javascript refuses to forget the context of a function when it hasn't forgotten the variable which holds the function.
So, when the function is invoked, I'll pass into its context object a copy of the statement which invokes it, along with a pointer to the expression that triggered the function call. Each expression in that statement that has been evaluated already will remember its value. When we return from the function, that statement becomes the current statement, and I start to execute it again -- but I don't re-evaluate expressions that have already been evaluated, including the function just completed. So then I go merrily along with the rest of the statement, potentially calling more functions, etc.
Each statement, expression, and function has an abstract representation built during parsing. During execution, only the current statement has any actual existence, aside from that abstract representation, because really all I need to remember at any given time is:
variables in the current context
variables in enclosing contexts (that is, the most recent invocation of a function -- including the global context -- which encloses the current function)
the current statement
what statement is next
what blocks I'm inside of (just so I know what to do when I hit
the end of one)
the call stack, which is a stack of contexts including variables and the
statement that triggered the call, with its expressions.
A pointer to the specific expression to update with return value from the function / context.
So am I making sense? Thanks for your help!

What you're describing is basically what an interpreter does, yes, but I'd still strongly recommend rethinking your approach. Interpreting Javascript in Javascript is going to run extremely slowly as soon as you're doing anything more complex than adding numbers. Is there some reason you can't separate your debugger from actual execution? If that's not possible, I'd really suggest doing your interpreter in a plug-in or something that gives you lower level speed. Or consider mod'ing something like this: https://developers.google.com/blockly/installation/js-interpreter?hl=en

Does a browser truly read JavaScript line by line OR does it make multiple passes?

I understand that JavaScript is interpreted and not compiled. No problem there. However, I keep reading here that JavaScript is executed "on the fly" and that lines are read one at a time. This idea is confusing me quite a bit when it comes to the following example:
writeToConsole();
function writeToConsole() {
console.log("This line was reached.");
}
For the record, this bit of code will write to the console just fine. Still, how would the browser know of the existence of exampleFunction() if it had not yet reached the function?
In other words, when exactly is this function first interpreted?

First, you make an incorrect assumption: modern JavaScript is compiled. Engines like V8, SpiderMonkey, and Nitro compile JS source into the native machine code of the host platform.
Even in older engines, JavaScript isn't interpreted. They transform source code into bytecode, which the engine's virtual machine executes.
This is actually how things in Java and .NET languages work: When you "compile" your application, you're actually transforming source code into the platform's bytecode, Java bytecode and CIL respectively. Then at runtime, a JIT compiler compiles the bytecode into machine code.
Only very old and simplistic JS engines actually interpret the JavaScript source code, because interpretation is very slow.
So how does JS compilation work? In the first phase, the source text is transformed into an abstract syntax tree (AST), a data structure that represents your code in a format that machines can deal with. Conceptually, this is much like how HTML text is transformed into its DOM representation, which is what your code actually works with.
In order to generate an AST, the engine must deal with an input of raw bytes. This is typically done by a lexical analyzer. The lexer does not really read the file "line-by-line"; rather it reads byte-by-byte, using the rules of the language's syntax to convert the source text into tokens. The lexer then passes the stream of tokens to a parser, which is what actually builds the AST. The parser verifies that the tokens form a valid sequence.
You should now be able to see plainly why a syntax error prevents your code from working at all. If unexpected characters appear in your source text, the engine cannot generate a complete AST, and it cannot move on to the next phase.
Once an engine has an AST:
An interpreter might simply begin executing the instructions directly from the AST. This is very slow.
A JS VM implementation uses the AST to generate bytecode, then begins executing the bytecode.
A compiler uses the AST to generate machine code, which the CPU executes.
So you should now be able to see that at minimum, JS execution happens in two phases.
However, the phases of execution really have no impact on why your example works. It works because of the rules that define how JavaScript programs are to be evaluated and executed. The rules could just as easily be written in a way such that your example would not work, with no impact on how the engine itself actually interprets/compiles source code.
Specifically, JavaScript has a feature commonly known as hoisting. In order to understand hoisting, you must understand the difference between a function declaration and a function expression.
Simply, a function declaration is when you declare a new function that will be called elsewhere:
function foo() {
}
A function expression is when you use the function keyword in any place that expects an expression, such as variable assignment or in an argument:
var foo = function() { };
$.get('/something', function() { /* callback */ });
JavaScript mandates that function declarations (the first type) be assigned to variable names at the beginning of an execution context, regardless of where the declaration appears in source text (of the context). An execution context is roughly equatable to scope – in plain terms, the code inside a function, or the very top of your script if not inside a function.
This can lead to very curious behavior:
var foo = function() { console.log('bar'); };
function foo() { console.log('baz'); }
foo();
What would you expect to be logged to the console? If you simply read the code linearly, you might think baz. However, it will actually log bar, because the declaration of foo is hoisted above the expression that assigns to foo.
So to conclude:
JS source code is never "read" line-by-line.
JS source code is actually compiled (in the true sense of the word) in modern browsers.
Engines compile code in multiple passes.
The behavior is your example is a byproduct of the rules of the JavaScript language, not how it is compiled or interpreted.

All functions will be examined first by the browser before any code is executed.
However,
var foo = function(){};
This will not be examined, and thus the following will throw a TypeError: undefined is not a function
foo();
var foo = function(){};

It does take 2 passes. The first pass parses the syntax tree, a part of which is performing hoisting. That hoisting is what makes your posted code work. Hoisting moves any var or named function declarations function fn(){} (but not function expressions fn = function(){}) to the top of the function they appear in.
The second pass executes the parsed, hoisted, and in some engines compiled, source code tree.
Check out this example. It shows how a syntax error can prevent all execution of your script by throwing a wrench in the first pass, which prevents the second pass (actual code execution) from ever happening.
var validCode = function() {
alert('valid code ran!');
};
validCode();
// on purpose syntax error after valid code that could run
syntax(Error(
http://jsfiddle.net/Z86rj/
No alert() occurs here. The first pass parsing fails, and no code executes.

The script is first parsed, then interpreted, and then executed. When the first statement (writeToConsole();) is executed, the function declaration has already been interpreted.
Since all variable and function declarations are hoisted in the current scope (in your case, the global script scope), you will be able to call a function that was declared below.

JavaScript is actually interpreted line by line. BUT, before it's executed, there is a first pass made by the compiler, reading certain things in (pretty geeky, have a look at this: https://www.youtube.com/watch?v=UJPdhx5zTaw if you're really interested).
The point is, JavaScript will be first "read" by the compiler, who stores functions defined as function foo(){...} already. You can call those ones at any given time in the script, given you are calling them from the same or a subordinate scope. What modern compilers also do is preallocate objects, so as a side effect it does make sense to strongly type your variables for the matter of performance.
var foo = function(){...} will not be stored by the compiler, due to the fact that JavaScript is loosely typed and the type of a variable could change during execution time.

The javascript engine create a execution context before executing your code. The execution context is created mainly in two phases:
Creation phase
Excecution phase
Creation Phase
In the creation phase we have the Global object, this and outer environment reference.In the creation phase as the parser runs through the code and begins to setup what we have written for translation, it recognizes where we have created variables and where we have created function. Basically it setup memory space for variable and functions Hoisting.
Execution Phase
In this the code is run line by line(interpreting, converting, compiling and executing it on the computer).
consider the following example, in this we are able to call the function b even before its declaration. This is because the javascript engine already knows the existence of the function b. And this is also referred to as hoisting in javascript.
b();
function b() {
console.log("I have been hoisted");
}

Why do you need to pass in arguments to a self executing function in javascript if the variable is global?

I was looking at the code for the underscore.js library (jQuery does the same thing) and just wanted some clarification on why the window object is getting passed into the self executing function.
For example:
(function() { //Line 6
var root = this; //Line 12
//Bunch of code
}).call(this); //Very Bottom
Since this is global, why is it being passed into the function? Wouldn't the following work as well? What issues would arrise doing it this way?
(function() {
var root = this;
//Bunch of code
}).call();

I suspect the reason is ECMAScript 5 strict mode.
In non-strict mode, this IIFE
(function() {
console.log(this); // window or global
})();
logs the window object (or the global object, if you're on a node.js server), because the global object is supplied as this to functions that don't run as a method of an object.
Compare that result to
"use strict";
(function() {
console.log(this); // undefined
})();
In strict mode, the this of a bare-invoked function is undefined. Therefore, the Underscore authors use call to supply an explicit this to the anonymous function so that it is standardized across strict and non-strict mode. Simply invoking the function (as I did in my examples) or using .call() leads to an inconsistency that can be solved with .call(this).

jQuery does the same thing, and you can find several answers to your question on SO by searching along those lines.
There are two reasons to have an always-available global variable like window in local scope, both of which are for the sake of fairly minor optimizations:
Loading time. Looking up a local variable takes a tiny bit less time than looking up a global variable, because the interpreter doesn't have to look as far up the context tree. Over the length of a function the size of Underscore or jQuery, that can theoretically add up to a less-trivial amount of time on slower machines.
Filesize. Javascript minification relies on the fact that variables can be named anything as long as they're consistent. myLongVariableName becomes a in the minified version. The catch, of course, is that this can only apply to variables defined inside the script; anything it's pulling from outside has to keep the same name to work, because if you shrink window down to pr the interpreter won't know what the hell you're talking about. By shadowing it with a reference to itself, Minify can do things like:
(function(A){ B(A, {...}); A.doStuff(); //etc });})(window)
and every time you would otherwise have put window (6 characters) you now have A (1 character). Again, not major, but in a large file that needs to explicitly call window on a regular basis for scope management it can be important, and you've already got an advantage by a few characters if you use it twice. And in large, popular libraries that get served by limited servers and to people who might have lousy Internet plans, every byte counts.
Edit after reading comments on question:
If you look at what function.call() actually does, your second snippet wouldn't actually work - the this being passed in isn't an argument, it's an explicit calling context for the function, and you have to provide it to .call(). The line at the beginning of the file serves the two purposes above. The reason for setting the context explicitly with call is futureproofing - right now, anonymous functions get the global context, but theoretically that could change, be discouraged in a future ECMA specification, or behave oddly on a niche browser. For something that half the Internet uses, it's best to be more explicit and avoid the issue entirely. The this/window choice at the top level I think must have something to do with worrying about non-PC devices (i.e. mobile) potentially using a different name for their top-level object.