Kind of. With hoisting, the compiler/interpreter will find variable declarations and execute them before executing the rest of the code. Hoisting leaves the variables as undefined until the code assigning the value to the variable is executed. Hoisting does not initialize the variables.
For example:
console.log(foo);
var foo;
//Expected output: console logs ‘null’
foo = ‘bar’;
console.log(foo);
var foo;
//Expected output: console logs ‘bar’
console.log(foo === undefined);
var foo;
//Expected output: console logs ‘true’
This means you can essentially write your code with variable declarations at the end, but it will still be executed as though the declarations were at the beginning. Your initializations and value assignments will still be executed as normal.
This is a feature that you should probably avoid because I honestly cannot think of any good use case for it that won’t end up causing confusion, but it is important to understand that every variable within your scope will be declared at the beginning of execution regardless of where it is written within your code.
If you have only one device on Wi-Fi, multiplexing turned off, or especially if you have MU-MIMO support, Wi-Fi can be faster than a single wired connection. It is still higher latency and subject to other drawbacks such as security and power consumption, but of course it offers advantages that can outweigh the disadvantages depending on use case and user needs.
That said, it’s technically not faster than the cable, but rather faster at the data link or network layer. For example, CAT8 physically supports up to 40Gbps, but most consumer and even professional electronics only support up to 2.5Gbps. Only really enterprise level switches can push up to like 100Gbps onto copper, and even then that’s using QSFP transceivers, not RJ-45 connections. Fiber cables regularly push 400Gbps.