Are you ready?
If so, let’s start with the first element of the puzzle.
How your computer can understand what to do with a plain text script?
The engine is a container in which you run your program.
… or at least they should give the same results. Nowadays, the ECMAScript specification changes more dynamically than in the past. Not every engine keeps up the paces.
Java as a platform also has its specification. Oracle provides the official implementation but it’s not the only one. OpenJDK is another example.
- Chrome V8 – As you probably guessed the engine shipped in Google Chrome. It’s an open source project written in C++. V8 is also used in Opera, NodeJS, and Couchbase.
- SpiderMonkey – The open source engine implemented in C++. It’s maintained by Mozilla Foundation. You can find it in Firefox.
- Nitro – The engine developed by Apple. It’s used in Safari.
Let’s dig a little deeper.
What kind of features you may ask.
These can be utility libraries or APIs which allow communicating with the world surrounding the engine. An example here might be access to information about the web browser in which your script is executed. Or a notification about a mouse click.
In Java world, we have the Java Runtime Environment (JRE) which gives us access to supporting libraries and acts as a bridge between your program and the operating system.
No more multithreading pitfalls?
Well, it’s not entirely true.
This mechanism is called the Event loop.
The second group contains so-called event callbacks. An event callback is a piece of code executed when a particular event occurs. In a web page context, an example of an event is a mouse click or a return of a network request.
When you create a callback, you always associate it with a particular event. If that event occurs, the environment puts your callback into a so-called Event handlers queue. The Event loop constantly monitors the queue and executes its elements in the order they arrive.
Now something very important!
Callbacks are a l w a y s executed completely. The Event loop runs one callback at a time. No context switching. All callbacks in the queue have to wait until the current one is finished.
If a script runs too long, it blocks others. That’s why callbacks should be relatively short and simple.
First of all, a web browser allows for manipulation of static web pages through the API for the Document Object Model (DOM).
The DOM represents (Models) the tree of UI elements (Objects) in a particular web page (Document). Your web browser creates a DOM object for each page you visit right after it’s loaded.
But there’s more.
Beyond that, the user isn’t the only source of events. Your scripts can create events as well.
A very special type of events you create is a timer event. You can delay execution of some code by a specified amount of time. The browser handles these events with the already mentioned event loop.
But that’s not all, you can use browser’s API to communicate via the network with the server side of your application. The result of network communication is also an event.
Finally, a web browser gives you basic information about a host operating system in which it runs and allows to store data in the local storage.
Why am I doing this?
Think I’m exaggerating?
There’s a real-life example which demonstrates this approach is working.
You can find the V8 engine both in Chrome browser and NodeJS. One engine successfully utilized in two environments created for totally different uses.
What should you already know?