We Keep Coding

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.

Internet Explorer Doesn't Support JavaScript?

I am recently reading about Node.js and got an interesting statement about JavaScript and Internet Explorer:
Internet Explorer doesn’t actually support JavaScript or ECMAScript; it supports a language variety called JScript. In recent years, JScript has fully supported the ECMAScript 3 standard and has some ECMAScript 5 support. However, JScript also implements proprietary extensions in the same way that Mozilla JavaScript does and has features that ECMAScript does not.
Source: http://chimera.labs.oreilly.com/books/1234000001808/ch01.html#chap2_id35941400
Frankly speaking I am totally unable to understand the above statement. I know Microsoft has its own VBScript and it allowed JavaScript in IE that is why JS is more popular than any other scripting language. Is this statement true? If yes then the scripting engine of IE does the translations of native JavaScript to JScript or what is the other case?

ECMAScript is the official standard, JavaScript and JScript are implementations of that standard. Just like CPython and Jython are implementations of Python.
As so often if it's about browsers, they both don't necessarily fully support the standard or provide additional, non-standard features, partly because they started evolving when an official standard didn't exist yet.
From Wikipedia about JScript:
[Microsoft] did not want to deal with Sun about the trademark issue, and so they called their implementation JScript. A lot of people think that JScript and JavaScript are different but similar languages. That's not the case. They are just different names for the same language, and the reason the names are different was to get around trademark issues
From the Microsoft documentation about JScript:
JScript is the Microsoft implementation of the ECMA 262 language specification (ECMAScript Edition 3). With only a few minor exceptions (to maintain backwards compatibility), JScript is a full implementation of the ECMA standard.

well, this mainly depends on the version of IE you are using, as you havent mentioned that no one can say that for sure

I think it is not like that instead Microsoft gives you an option to enable Javascript on your IE like this:
Pull down your TOOLS menu
Select Internet Options...
Click the Security tab on the top of the resulting window
Click the Custom Level button
Scroll the list down to the entry for Active Scripting
Check the Enable radio button.
Click OK in all dialogs.
Also Jscript is same as Javascript
JScript is Microsoft's dialect of the ECMAScript standard[2] that is
used in Microsoft's Internet Explorer.
JScript is implemented as a
Active Scripting engine. This means that it can be "plugged in" to OLE
Automation applications that support Active Scripting, such as
Internet Explorer, Active Server Pages, and Windows Script Host.[3] It
also means such applications can use multiple Active Scripting
languages (e.g., JScript, VBScript, PerlScript, etc.).

What language is JavaScript written in?

If it's a scripting language as the name implies it must be written in a lower level language right? Like how PHP is written in C what language is JavaScript written in?

Javascript is just a standard, more formally known as ECMAScript. It can be implemented in any language, just like any standard.
Chrome's Javascript engine, V8, is written in C++.
From the project page:
V8 is written in C++ and is used in Google Chrome, the open source browser from Google.
V8 implements ECMAScript as specified in ECMA-262, 5th edition, and
runs on Windows (XP or newer), Mac OS X (10.5 or newer), and Linux
systems that use IA-32, x64, or ARM processors.
Firefox's Javascript engine, SpiderMonkey (and now TraceMonkey) is also written in C++. And as maerics below said, Rhino is written in Java.

All the answers so far are correct, but since it hasn't been mentioned yet, JavaScript can be written in JavaScript.

Most Javascript interpreters are written in C/C++ (V8, Nitro, etc…), however a compliant interpreter can be written in any language (Rhino→Java, Interpreter→Javascript, etc…).

Whichever language the client webbrowsers javascript interpreter was written in :)

Javascript is an implementation of the ECMAScript standard, but there is no singular canonical interpreter like you see with PHP.
Most of the major implementations (standalone or as parts of web browsers) out there tend to be largely written in C or C++ for performance reasons, but that's not necessarily always the case. Rhino, an engine maintained by Mozilla, is written in Java.

Most implementations of Javascript show behaviour that is clearly caused by the use of pointers and byref parameter passing, which normally points towards the use of C, or C++
This is clearly notable for instance when you are taking apart a multidimensional array in a loop, with the help of intermediate array's. These tend to behave very "strangely", if you are not familiar with pointers and byref passing of parameters (You need do var hlp = new Array() each time or it will overwrite the previous values which you already stored somewhere else)
I'm rather curious as to how an implementation of javascript in for instance Java, because I imagine that this kind of behaviour will be quite different in that case?

C++ is the fundamental language for anything modern and fancy. Most modern high level languages are subset of low level language,C++. All modern languages you see today is a subset of C++ someway or the other. Even Java is a subset of C++.

Why is JavaScript inconsistent across browsers?

Here's something I've been pondering after countless hours fixing JS to be cross-browser compatible (mostly IE): Why isn't Javascript consistent accross browsers?
I mean, why can't JS be nice like Java and Flash? Instead, we have to resort to frameworks like jQuery. Don't get me wrong, they make my life easier - but why do they even exist in the first place?
Is there a historical reason for this? Do companies rolling out browsers just ship their own JS engine? What are the politics that make standardization so difficult?
(Note: I understand that a good part of the problem is DOM related, but the question remains).

The Javascript core language for the most part is consistent ( Referring to ECMAScript version 3 released in 1999. )
It's the DOM implementations that cause headaches. Partly because at one point there was no DOM specification so browsers could do whatever the hell they wanted in terms of making up the rules for which to access and manipulate html elements in a web page.
For example:
window.addEventListener for DOM supporting browsers, while window.attachEvent for IE.
textContent for DOM supporting browsers, innerText for IE.
Memory leakage for attached event handlers in IE so you have to unload them manually
getElementById is buggy in IE and Opera because it returns elements by name
getAttribute('href') returns inconsistent values
There are also issues relating to the browser's CSS support.
IE6 doesn't support native PNGs so you are forced to use the filter library
Buggy animation in IE dealing with filter opacity
Language core inconsistencies would be things like
Inconsistencies between regex engines
But yeah, in short the point is that before, there was no standard. Since then, the w3 came up with standards, but every browser vendor has its own way of dealing with implementing it. There's no governing body that forces the vendors to fully apply the spec.

Do companies rolling out browsers just ship their own JS engine?
Yup, that's probably the main reason. There is no unified JS engine; there are various implementations of ECMAScript.

Browsers roll their own implementation, plain and simple. It's the same reason why rendering and CSS and all that are different across browsers. Java/Flash/etc. are more universal because they're abstracted out of the browser and accessed via a plugin of some sort. But their actual core implementations are separate from the browser and controlled by a single vendor.

To add to the other answers: there is a historical reason for this. I can write this myself, but quoting Wikipedia is easier on the fingers:
JavaScript was originally developed by
Brendan Eich of Netscape under the
name Mocha, which was later renamed to
LiveScript, and finally to JavaScript.
LiveScript was the official name for
the language when it first shipped in
beta releases of Netscape Navigator
2.0 in September 1995, but it was renamed JavaScript in a joint
announcement with Sun Microsystems on
December 4, 1995 when it was deployed
in the Netscape browser version 2.0B3.
[…]
JavaScript very quickly gained
widespread success as a client-side
scripting language for web pages. As a
consequence, Microsoft developed a
compatible dialect of the language,
naming it JScript to avoid trademark
issues. JScript added new date methods
to fix the non-Y2K-friendly methods in
JavaScript, which were based on
java.util.Date. JScript was included
in Internet Explorer 3.0, released in
August 1996. The dialects are
perceived to be so similar that the
terms "JavaScript" and "JScript" are
often used interchangeably. Microsoft,
however, notes dozens of ways in which
JScript is not ECMA-compliant.
In November, 1996 Netscape announced
that it had submitted JavaScript to
Ecma International for consideration
as an industry standard, and
subsequent work resulted in the
standardized version named ECMAScript.
As you can see, the standard, ECMAScript, was developed later than the original language. It's just a matter of adapting this standard in the current implementations of web browsers, that's still going on, as is the development of ECMAScript itself (e.g., see the specification of ECMAScript 5, published December 2009).

JavaScript versions later than 1.5 - why?

The Mozilla Foundation continues to add new language features to JavaScript. They're up to version 1.8 now where 1.5 was more or less the ECMA baseline.
However, Firefox is the only browser that supports the latest version and IE is firmly stuck at a 1.5-equivalent JScript.
What purpose do the Firefox-only extensions serve? Or are they just lying dormant until (and if) the rest of the browsers catch up?

Firefox, Thunderbird, and other XUL apps also have large portions of themselves written in JavaScript. A more featureful JavaScript means a better development environment for Firefox and other Mozilla apps.

Extending the language is a good idea, even if only one browser is doing it - eventually it will prove itself and be made into the standard at which time other browsers will have to catch up.
Otherwise, how can progress be made - Microsoft does this all the time: would XMLHttpRequest have ever made it into the standards if Internet Explorer wouldn't have implemented it first?
From the Mozilla perspective the purpose of these changes, except for adding more capabilities for use by web developers, is to lead up to JavaScript 2.0, that is being developed as the next revision of ECMA 262 (revision 4) TC39 workgroup.
Future browsers will support JavaScript 2.0. In the mean time, developers are invited to take advantage of these extra features - natively in Firefox and using JavaScript libraries that provide backward compatibility with Internet Explorer. I find this very useful.
Also, it may be interesting to note that Webkit (the engine developed by KDE and used by Safari, Chrome and several free software browsers) supports JavaScript 1.7.

The biggest reason at the moment for improved JavaScript is for extension writers, who need not worry about cross-browser compatiblity.

JavaScript is a trademark by Sun which was licensed to Netscape and is now held by the Mozilla Foundation. Microsoft has their own implementation of the language called JScript, but there are others (eg. DMDScript).
ECMAScript was an afterthought to add a common baseline to the various implementations. So it's only natural that language development continues outside the standards committee, which is free to add the changes pioneered by the implementors in future revisions of the standard (eg the array extras introduces in JS1.6 will be in ES3.1).