We Keep Coding

Where is low level code of Javascript standard built-in objects?

I'm looking for the way to get low level code of javascript built-in function.
For example, there is an polyfill(I want like this form and I call this low level code in my way) in mdn site of 'Array.prototype.indexOf()'
(https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/indexOf)
And I get to understand that it is kinda low level code of built-in method.
Here is my question, where can I see the code to look inside of method of 'String.prototype.toLowerCase()'?

It'll depend on your javascript implementation.
For V8, here is the guts of toLowerCase (and toUpperCase)
Low level functions (such as these) are generally written in whatever language the javascript engine is written in - that's why they're so fast. So don't go in expecting something that's easy to read for the average javascript-only developer :)

The answer you are looking for probably doesn't exist but I'll do my best do help you out.
The low level function are dependent on which Engine you are using.
A few examples are:
V8 — open source, developed by Google, written in C++
Rhino — managed by the Mozilla Foundation, open source, developed entirely in Java
SpiderMonkey — the first JavaScript engine, which back in the days powered Netscape Navigator, and today powers Firefox
JavaScriptCore — open source, marketed as Nitro and developed by Apple for Safari
I assume you are looking for the function to understand what they are doing. If this is the case and you don't understand the languages that the engines are written it might be an idea to look at the polyfill implementation of those functions. Those are written in javascript and might help you understand them if that's what you are looking for.
Good luck! :)

JavaScript is defined by a standard, with many major implementations.
The definition for that method and others can be found in the TC39 website. It is only defined algorithmically, not in actual code.
That being said, for the open-source implementations, you can actually look at the source code for those implementations, though they will probably be in some other language, such as C++.
The major current open-source implementations of JavaScript are Google's V8, Apple's WebKit and Mozilla's SpiderMonkey.

JS on site behaves differently; browsers, os are same

We are debugging a site; these are the conditions:
Both devs are on same OS, same version (Windows 10)
Both devs are using same browser, same version (Chrome)
Since our dev boxes where built out identically (corporate america), there are no differences in other elements. JS version, so on.
I visit the site, JS fires differently than when co-worker visits.
What is going on? Are the End Times coming?

Read this It may be helpful
Browser incompatibilities
When a user receives a page which includes JavaScript, the JavaScript interpreter of his browser kicks in and tries to execute the script. Now the main problem here is that the various browsers each use their own interpreter, and that sometimes browser vendors have chosen not to implement a bit of JavaScript. Their reasons were usually related to business advantage over the competitors.
Hence the feared browser incompatibilities.
In addition each new browser version understands more JavaScript and allows more and more parts of the HTML page to be changed by scripts. This leads to even more incompatibilities.

Do compilers for javascript differ from web browser to web browser

So I am asking does each web browser have there own compiler example IE compiles Javascript from a website and generates sequence A of byte code .
On the other hand, google chrome compiles the same Javascript from the same website and generates sequence B .
I am wondering this because if that is the case would it be beneficial to run the compiler on the Javascript and upload the generated byte code to the website rather than the Javascript itself. And send different byte code based on each browser.
Or are there some other limitations.

As others have pointed out, there are different ECMAScript engines and some of them use a JIT (Just-In-Time) compiler while some others use runtime interpreters, being the former the preferred option for most browsers nowadays as it gives some performance benefits over the latter option.
You can see another question about this on: https://softwareengineering.stackexchange.com/questions/138521/is-javascript-interpreted-by-design
For example, V8 is the JavaScript engine used in Google Chrome, node.js and can also be embedded into C++ applications.
About your idea of sending compiled or precompiled code to the client instead of the raw JS, there are some projects working on something similar:
Asm.js consists of a strict subset of JavaScript, into which code written in statically-typed languages with manual memory management (such as C) is translated by a source-to-source compiler such as Emscripten (based on LLVM). Performance is improved by limiting language features to those amenable to ahead-of-time optimization and other performance improvements.
The important fact about Asm.js is that existing JavaScript engines do work quite well with its style of code, so you can start using it right now! But the code it produces is still (a subset of) the JS we know but written in some way that helps JS engines to run it faster:
Of course, there are also a lot of restrictions about what you can do with it, as it is mainly oriented to work with just numbers. See http://ejohn.org/blog/asmjs-javascript-compile-target/
Real support for Asm.js is still a limitation, so you can't use things like "use asm" and although you can run Asm.js code on today browsers and get some performance improvements, it won't be as good as it could be in browsers that could optimize Asm.js code. However, we may start having that and some other improvements in the (hope that near) future. See https://blog.mozilla.org/research/2015/02/23/the-emterpreter-run-code-before-it-can-be-parsed/
Meanwhile, and for a more general purpose JS that needs to work with more than just numbers, you can use Google Closure Compiler. I would recommend that you take a look at the FAQ first, and then you could start playing with it in the online tool.

There are several JavaScript (or rather ECMAScript) implementations in wide use, and while in theory there are standards, most widely used one being ES5 (ECMAScript 5) - yes, not everything in all browsers is properly, consistently implemented (I'm looking at you, old IE).
Here's nice compatibility table for ES5 (the one you're writing in today): http://kangax.github.io/compat-table/es5/
And here's same thing for shiny-new ES6: http://kangax.github.io/compat-table/es6/
Note the disclaimer at the top of these tables:
Please note that some of these tests represent existence, not functionality or full conformance.
Also, on the issue of whether JavaScript is compiled or interpreted language: it is definitely interpreted language - at least originally. But most common JavaScript engines in use today implement JIT (Just-In-Time compiler), translating much of JavaScript to byte or machine code before executing it (ergo - compiling).
Most widely used (and most performant as well) of these engines is V8, used by WebKit (and therefore present in Chrome, Safari, Opera, ... - Node.JS is using it as well). Read more about V8 and its JIT implementation: How the V8 engine works?

Yes, each browser has its own implementation of an ECMAScript engine, most commonly implementing/supporting ECMA-262, commonly known as JavaScript. While there are several large related families of browser engines such as Webkit, each engine further can have its own JavaScript engine. For example, as many have pointed out, Google use the V8 engine. Because these engines each do things a little differently, there is no one set of code that is promised to be deterministic across them, the way say Java code will run the same on any machine that supports the JVM.
Inherently, JavaScript is not compiled like a traditional language such a Java or C/C++. This is why, without the help of a 3rd party program, you cannot find non-syntax errors in your JavaScript code until that code runs. ECMAScript is an interpreted language.
Now, this is the tricky part. Most modern JavaScript engines do in fact compile JavaScript, often to another language (also known as Source-to-Source compiling or transpiling) such as C, to perform performance optimizations on it. Of course, at some point, all code gets compiled into byte code.
Your best bet for writing JavaScript that will work on all major browsers is to use core/standard features. For example, this means passing timestamp string in the form of "yyyy/mm/dd" instead of "yyy-mm-dd" when using new Date() since Firefox does not support the latter format - the Chrome developers simply added it to be nice to you. IE is notorious for handling certain non-standard features differently. I'm a big fan of http://caniuse.com/ to help with this.

Nowadays most javascript engines are JIT compilers. More here: What does a just-in-time (JIT) compiler do?
So yes, javascript is compiled (not interpreted), and most major browsers do it differently.

On an html page, is javascript the only way to programatically manipulate the DOM?

Is JavaScript the only language that can be run on the client side in a browser for client side scripting like DOM manipulation? I think VBS used to be available in older versions of internet explorer, but is no longer available?
With about a zillion server side languages, I have only really seen JavaScript on the client side. Sorry if this is a dumb question, but is it possible to use any other scripting language for client code? Do any browsers natively (or at least reasonably) allow for scripting in another language, or accessing the DOM directly in some other way? I am aware of using clever CSS3 for things like nested menu items, so not that.

More than JS or no JS, it's the HTML(5) and ECMAScript spec that matters. It really depends on browser to implement the specs. For example Google uses V8 for JS processing. For local storage Google and MS uses IndexedDB (for html5) while others uses different client db (like FF and Safari-SQL Lite - I think).
Not sure about VBS in IE anymore but it's not supported in any other browser anyway. And IE is sort of very much behind the curve.
JS is now de-facto standard in browser world and gaining popularity even in Server side with the help of node.js ...
To be more specific - there are other languages available for browsers and multiple efforts took place (and going on) to present a logical substitute for JS. Example - VBS, PERL, TCL, Python plugin in FF etc - but none became a viable option against JS (especially with multiple JS frameworks showing up almost everyday).
Other approach was Flex / Silverlight type environment which essentially provide a viewport on top of browser to overcome limitations of HTML. But with present HTML5 specification, the trend is reverse now - all are flocking around HTML5 and JS.

VBScript is supported by Internet Explorer. You can use ActionScript and Java Applet at the client side too.

Do browsers compile and cache javascript?

I’ve noticed that after making a change to a javascript file, clearing the cache, and reloading; one function in particular runs in about 90ms, the next time I load the page, it runs in 40ms, the next time I run it, it runs in 20ms … then never gets faster.
It kind of looks like IE is compiling my javascript and caching that compiled version somewhere, similar to how SQLServer processes queries.
Is that what is happening?
Does anybody know where I can find a clarification of how browsers process javascript?

You may want to check out Eric Lippert's comment to Peter Torr's blog post Compiled, interpreted, whatever:
JScript Classic acts like a compiled language in the sense that before any JScript Classic program runs, we fully syntax check the code, generate a full parse tree, and generate a bytecode. We then run the bytecode through a bytecode interpreter. In that sense, JScript is every bit as "compiled" as Java. The difference is that JScript does not allow you to persist or examine our proprietary bytecode. Also, the bytecode is much higher-level than the JVM bytecode -- the JScript Classic bytecode language is little more than a linearization of the parse tree, whereas the JVM bytecode is clearly intended to operate on a low-level stack machine.
The post and the comment are from September 2003, but judging from Ralph Sommerer's On JavaScript performance in IE8 post, they haven't changed much in the underlying JScript engine:
Unless the JavaScript engine used in IE (and elsewhere) employs some sort of compilation to native code, it will always lag behind its competitors with respect to performance. From what I gather in their Channel9 appearance they have made improvements in bytecode execution, but their main targets were JavaScript native objects (Array, String, ...) and JavaScript-DOM-interaction.

IE8 is not open-source, so one can only make hypotheses; however, open-source browsers (such as Chromium, Firefox, Webkit) do work roughly as you say, as do many other interpreters in non-browser and not necessarily JS settings (compile new sources when first seen or reloaded, cache or save the compiled version for faster execution in the future), so it seems very reasonable that IE's Javascript approach should be very much the same, as you surmised.

I know you asked about IE8, but here is V8 - Google's engine. Includes videos on how V8 works.
http://code.google.com/p/v8/