*JavaScript* was initially created to *"make webpages alive"*.

Scripts are provided and executed a plain text. They don't need a special preparation or compilation to run.

When JavaScript was created, it initially had another name: "LiveScript". But Java language was very popular at that time, so it was decided that positioning a new language as a "younger brother" of Java would help.

But as it evolved, JavaScript became a fully independent language, with its own specification called [ECMAScript](http://en.wikipedia.org/wiki/ECMAScript), and now it has no relation to Java altogether.

It has quite a few special features that make mastering a bit hard at first, but we'll nicely deal with them later.

[smart header="Compilation and interpretation"]

There are in fact two general approaches to execute programs: "compilers" and "interpreters".

<li>*Compilers* convert the program text (source code) to another language, usually the machine language (binary code) without executing it. This is done by the developer and then the binary code is distributed to the system which actually runs it.</li>

<li>*Interpreters*, and in particular the one embedded in the browser -- get the source code and execute it "as is". The source code (script) is distributed to the system as a plain text.</li>

Modern interpreters actually combine these approaches into one: the script is distributed as a plain text, but prior to execution is converted to the machine language. That's why JavaScript is very fast.

All major browsers have an embedded JavaScript interpreter, that's why they are capable of script execution. But naturally JavaScript can be used not only in-browser. It's a full-fledged language usable at the server too and even in a washing machine if it gets a chip with the interpreter installed.

[warn header="Let's talk about browsers"]

The modern JavaScript is a "safe" programming language. It does not provide low-level access to memory or CPU, because it was initially created for browsers which do not require it.

Or, in more details, it is able to:

<li>Create new HTML tags, remove the existing ones, change styles, hide/show elements...</li>

<li>React on user actions, run on mouse clicks, pointer movements, key presses...</li>

<li>Send requests over the network to remote servers, download and upload data without reloading the page (a so-called "AJAX" technology)...</li>

<li>Get and set cookies, ask for data, show messages...</li>

<li>...and can do much more with the page and it's content!</li>

Such limits do not exist if JavaScript is used outside of the browser, for example on a server. Besides, modern browsers allow to install plugins and extensions which get extended permissions, but require actions from the user to accept that.

JavaScript abilities are also limited when it tries to access things outside of the current window/page.

<img src="limitations.svg">

Modern browsers allow it to work with files, but limit the access to a specially created directory called "a sandbox". There is a work going on to allow access to devices, with the user's permission.

<li>JavaScript can easily interact over the net to the server where the current page came from. But it's ability to receive data from other sites/domains is crippled. Though possible, it requires the explicit agreement (expressed in HTTP headers) from the remote side. Once again, that's safety limitations.

There are at least *three* great things about JavaScript:

Combined, these 3 things only exist in JavaScript and no other browser technology.

That's what makes JavaScript unique. That's why it is the most widespread way of creating browser interfaces.

It's crucially important that new standards, HTML5, EcmaScript 6 are still compatible with the previous code, so there are introduced into the ecosystem without problems with the existing applications.

Still, there is a small gotcha with those "extra-fresh" modern browser abilities. Sometimes browsers try to implement them on very early stages when they are nor fully defined neither agreed upon, but still are so interesting that the developers just can't wait.

...As the time goes, the specification matures and changes, and browsers must adapt it. That may lead to errors in JavaScript code which was too eager to use the early browser implementation. So one should think twice before relying on things that are in draft yet.

But what's great -- eventually all browsers tend to follow the standard. There are much less differences between them now than only a couple years ago.

<applet code="MyApplet.class" codebase="/path/to/code">

This tag loads the Java program from `MyApplet.class` and executes it with given parameters (`nodes`, `root`).

The applet runs in a rectangular part of the page, so called "container". All user actions inside it are processed by the applet. One can hide the container if the applet does something not fit for the show.

**Why us, JavaScript-developers should be aware of Java?**

Mainly because a signed Java-applet can do literally everything on a visitor's computer, just like any other program. Of course that requires a visitor's agreement to run it, but after that they can break of any restrictions.

So if the user trusts as (like he's already a client of ours), we can implement something that pure javascript can't do yet.

All modern browsers allow to write plugins using either JavaScript and/or C language.

The main drawback is that it needs Adobe Flash player to be installed and enabled. Users tend to disable it, because of nasty "multimedia" ads and many vulnerabilities in the past. Also, certain operational systems like iOS (iPhone, iPad) do not support it at all.

The syntax of JavaScript does not suit everyone's needs: some people think that it's too flexible, the others consider it too limited, the third ones want to add new features absent in the standard...

That's normal, because projects and requirements are different for everyone. There's no a single standard for a carpenter's hammer, why should it exist for the language?

So recently a plethora of new languages appeared, which add features "over" JavaScript, meaning that the source code in these languages is *transpiled* (converted) to JavaScript before they run.

The transpilation happens automatically, modern tools make the process very fast and transparent, actually allowing developers to code in another language. They still should know JavaScript, to better understand what they are doing.

A few examples of such languages:

<li>[Dart](https://www.dartlang.org/) was offered by Google as a replacement for JavaScript, but other leading internet companies declared that they are not interested. Maybe later, we'll see. Right now it can be transpiled to JavaScript, but used less often compared to two previous alternatives.</li>

Here in the first part of the tutorial I feel a little bit shy to use them, because without a native browser support such tools add unnecessary complexity at the start and can be easily integrated later when the basics are learned.

JavaScript is unique due it's full integration with HTML/CSS and wide browser adoption.

...But a good JavaScript-developer should be aware of other technologies too. Our ultimate purpose is to create best frontend apps, and sometimes Java, Flash or plugins can be helpful too.

Other languages like CoffeeScript and TypeScript can help to develop faster and write less bug-proof code. It is recommended to take a look at them, at least briefly, after mastering JavaScript.