Related
I was asked that today and was not able to give a proper answer.
Typescript transpiles to JS. Then there is tree shaking, "less" (optional) and what else in the process of making a deployment. But nothing like that (afaik) has anything to do with "compiling". Everything gets bundled and heavily optimized, but it's not actually compiled, right?
There is even an "ahead of time"-compiler, which really does a noticeable job. What do I miss?
Javascript itself is still interpreted, right?
You're presuming compiling means taking the source code and producing machine code, low-level codes, etc. But compiling actually just means taking one source code and turning it into another. So it seems reasonable to say that taking Typescript and producing JavaScript is a form of compiling. It's not dissimilar to what (for example) c# does when its compiled into IL language.
That said, I'd say a better word for this is Transpiling. I'd suggest that the Typescript compiler is better described as a Transpiler.
The difference is subtle and a transpiler can be thought of as a type of compiler; but a (pure)compiled language is (usually) turning a high-level language to a low(er) level language (nearer to machine code), like the C# example. A transpiler turns a high-level language into a similar level (of abstraction) language (also high level).*
The result of the compiled code is typically not a language that you would write yourself. The result of a transpiler is another high-level language. In theory, you could write IL (as an example) but it's really designed to be produced by a compiler and there are no tools or support for doing this, you produce IL by compiling C#/vb.net, only. Whereas Javascript is a usable (and used) programming language in its own right.
*Lots of caveats as the definitions of these words and their usage are pretty vague
You seem to be asking three questions in one:
What is the difference between a compiler and a transpiler?
Do Angular and TypeScript implement compilers or transpilers?
Is there a separate Angular compiler? What does it compile?
What is the difference between a compiler and transpiler?
#JörgWMittag provided a very good answer to this question.
Do Angular and TypeScript implement compilers or transpilers?
Both TS and Angular implement real compilers. They follow the same stages of lexical analysis, parsing, semantic analysis, and code generation as C/C++ compilers that produce assembly code (except probably for optimization). You can see that the class/folder are named "compiler" in both Angular and TS.
The angular compiler is not really related to TypeScript compiler. These are very different compilers.
Is there a separate Angular compiler? What does it compile?
Angular has two compilers:
View Compiler
Module Compiler
The job of the view compiler is to transform the template you specify for the component template into the internal representation of a component which is a view factory that is then used to instantiate a view instance.
Besides transforming the template, the view compiler also compiles various metadata information in the form of decorators like #HostBinding, #ViewChild etc.
Suppose you define a component and its template like this:
#Component({
selector: 'a-comp',
template: '<span>A Component</span>'
})
class AComponent {}
Using this data the compiler generates the following slightly simplified component factory:
function View_AComponent {
return jit_viewDef1(0,[
elementDef2(0,null,null,1,'span',...),
jit_textDef3(null,['My name is ',...])
]
It describes the structure of a component view and is used when instantiating the component. The first node is element definition and the second one is text definition. You can see that each node gets the information it needs when being instantiated through parameters list. It’s a job of a compiler to resolve all the required dependencies and provide them at the runtime.
I strongly recommend reading these articles:
Here is what you need to know about dynamic components in Angular
Here is why you will not find components inside Angular
Also, see the answer to What is the difference between Angular AOT and JIT compiler.
The job of the module compiler is to create a module factory which basically contains merged definitions of the providers.
For more information, read:
Avoiding common confusions with modules in Angular
Typescript transpires to JS. Then there is tree shaking, "less" (optional) and what else in the process of making a deployment. But nothing like that (afaik) has anything to do with "compiling". Everything gets bundled and heavily optimized, but it's not actually compiled, right?
Compilation means transforming a program written in a language A into a semantically equivalent program written in language B such that evaluating the compiled program according to the rules of language B (for example interpreting it with an interpreter for B) yields the same result and has the same side-effects as evaluating the original program according to the rules of language A (for example interpreting it with an interpreter for A).
Compilation simply means translating a program from language A to language B. That's all it means. (Also note that it is perfectly possible for A and B to be the same language.)
In some cases, we have more specialized names for certain kinds of compilers, depending on what A and B are, and what the compiler does:
if A is perceived to be assembly language and B is perceived to be machine language, then we call it an assembler,
if A is perceived to be machine language and B is perceived to be assembly language, then we call it a disassembler,
if A is perceived to be lower-level than B, then we call it a decompiler,
if A and B are the same language, and the resulting program is in some way faster or lighter, then we call it an optimizer,
if A and B are the same languages, and the resulting program is smaller, then we call it a minifier,
if A and B are the same languages, and the resulting program is less readable, then we call it an obfuscator,
if A and B are perceived to be at roughly the same level of abstraction, then we call it a transpiler, and
if A and B are perceived to be at roughly the same level of abstraction and the resulting program preserves formatting, comments, and programmer intent such that it is possible to maintain the resulting the program in the same fashion as the original program, then we call it a re-engineering tool.
Also, note that older sources may use the terms "translation" and "translator" instead of "compilation" and "compiler". For example, C talks about "translation units".
You may also stumble across the term "language processor". This can mean either a compiler, an interpreter, or both compilers and interpreters depending on the definition.
Javascript itself is still interpreted, right?
JavaScript is a language. Languages are a set of logical rules and restrictions. Languages aren't interpreted or compiled. Languages just are.
Compilation and interpretation are traits of a compiler or interpreter (duh!). Every language can be implemented with a compiler and every language can be implemented with an interpreter. Many languages have both compilers and interpreters. Many modern high-performance execution engines have both at least one compiler and at least one interpreter.
These two terms belong on different layers of abstraction. If English were a typed language, "interpreted-language" would be a type error.
Note also that some languages have neither an interpreter nor a compiler. There are languages which have no implementation at all. Still, they are languages, and you can write programs in them. You just can't run them.
Also, note that everything is interpreted at some point: if you want to execute something, you must interpret it. Compilation just translates code from one language to another. It doesn't run it. Interpretation runs it. (Sometimes, when an interpreter is implemented in hardware, we call it a "CPU", but it's still an interpreter.)
Case in point: every single currently existing mainstream JavaScript implementation has a compiler.
V8 started out as a pure compiler: it compiled JavaScript straight to moderately optimized native machine code. Later, a second compiler was added. Now, there are two compilers: a lightweight compiler that produces moderately optimized code but the compiler itself is very fast and uses little RAM. This compiler also injects profiling code into the compiled code. The second compiler is a more heavyweight, slower, more expensive compiler, which, however, produces much tighter, much faster code. It also uses the results of the profiling code injected by the first compiler to make dynamic optimization decisions. Also, the decision which code to re-compile using the second compiler is made based on that profiling information. Note that at no time there is an interpreter involved. V8 never interprets, it always compiles. It doesn't even contain an interpreter. (Actually, I believe nowadays it does, I am describing the first two iterations.)
SpiderMonkey compiles JavaScript to SpiderMonkey bytecode, which it then interprets. The interpreter also profiles the code, and then the code which gets executed most often is compiled by a compiler to native machine code. So, SpiderMonkey contains two compilers: one from JavaScript to SpiderMonkey bytecode, and another from SpiderMonkey bytecode to native machine code.
Almost all JavaScript execution engines (with the exception of V8) follow this model of an AOT compiler that compiles JavaScript to bytecode, and a mixed-mode engine that switches between interpreting and compiling that bytecode.
You wrote in a comment:
I really was thinking that machine code is somewhere involved.
What does "machine code" even mean?
What is one man's machine language is another man's intermediate language and vice versa? For example, there are CPUs which can natively execute JVM bytecode, on such a CPU, JVM bytecode is native machine code. And there are interpreters for x86 machine code, when you run of those x86 machine code is interpreted bytecode.
There is an x86 interpreter called JPC written in Java. If I run x86 machine code on JPC running on a native JVM CPU … which is the bytecode and which is the native code? If I compile x86 machine code to JavaScript (yes, there are tools which can do that) and run it in a browser on my phone (which has an ARM CPU), which is the bytecode and which is the native machine code? What if the program I am compiling is a SPARC emulator, and I use it to run SPARC code?
Note that every language induces an abstract machine, and is machine language for that machine. So, every language (including very high-level languages) is native machine code. Also, you can write an interpreter for every language. So, every language (including x86 machine code) is not-native.
Getting the code you've written to run on a browser involves two things:
1) Transpiling the Typescript into JavaScript. This is kind of a solved problem. I think they just use webpack.
2) Compiling the angular abstractions into JavaScript. I mean things like a components, pipes, directives, templates etc. This is what the angular core team work on.
In case you're really interested in that second bit, the angular compiler, watch compiler author Tobias Bosch explain the Angular Compiler at AngularConnect 2016.
I think there's a bit of confusion going on here between transpiling and compilation. It sort of doesn't matter and is a matter of personal taste, they're both just transforms between representations of code. But the definition I personally use is that transpilation is between two different languages at a similar abstraction level (eg typescript to javascript), whereas compilation requires a step down in level of abstraction. I think from templates, components, pipes, directives etc to just javascript is a step down the abstraction ladder, and that's why it's called a compiler.
Angular Compiler
One of the most important changes from Angular 4 to 5 is that the compiler has been rewritten be faster and more thorough. In the past, Angular applications used what we call Just-in-Time (JIT) compilation, where the application was compiled at runtime in the browser before running. The compiler updates in Angular 5 advanced the move to AOT, which made the app run faster as it performes less compilation when running the app. AOT become enabled by default in any production build since the 1.5 version of the Angular CLI.
Let's say we want to build an application for deployment and run the following command:
ng build --prod
A few things happen: production version, minification, bunddles assets, filename hashing, tree shaking, AOT ... (we can enable/disable this using flags, ex. aot=false). In short, the prod flag creates an optimized bundle of the application by doing AOT compilation using the ngc (the Angular compiler) to create optimized code ready for the browser (Yes, it pre-compiles templates).
TypeScript Compiler
The TypeScript compiler, tsc, is responsible for compiling TypeScript files. It is the compiler that is responsible for implementing TypeScript features, such as static types, and the result is pure JavaScript from which the TypeScript keywords and expressions have been removed.
The TypeScript compiler has two main features: it is a transpiler and a type checker. The compiler transpiles TypeScript to JavaScript. It does the following transformations on your source code:
Remove all type annotations.
Compile new JavaScript features for old versions of JavaScript.
Compile TypeScript features that are not standard JavaScript.
Invoking it, the compiler searches for configurations loaded in tsconfig.json (A detailed list of all the compiler options, along with default values, can be found here).
In most respects, the TypeScript compiler works like any compiler. But there is one difference that can catch out the unwary: by default, the compiler continues to emit JavaScript code even when it encounters an error. Fortunately, this behavior can be disabled by setting the noEmitOnError configuration setting to true in the tsconfig.json file.
To note: tsc and ngc have different purposes and it's not about selecting one over the other. This answer might be of interest.
This answer was crafted based on the content from the following books
Cloe, M. (2018). "Angular 5 Projects: Learn to Build Single Page Web Applications Using 70+ Projects".
Dewey, B., Grossnicklaus, K., Japikse, P. (2017). "Building Web Applications with Visual Studio 2017: Using .NET Core and Modern JavaScript Frameworks".
Freeman, A. (2019). "Essential TypeScript: From Beginner to Pro".
Ghiya, P. (2018). "TypeScript Microservices".
Iskandar, A., Chivukulu, S. (2019). "Web Development with Angular and Bootstrap - Third Edition".
Hennessy, K., Arora, C. (2018). "Angular 6 by Example".
Jansen, R., Wolf, I., Vane, V. (2016). "TypeScript: Modern JavaScript Development".
Mohammed, Z. (2019). "Angular Projects".
Seshadri, S. (2018). "Angular: Up and Running".
Wilken, J. (2018). "Angular in Action".
Asm.js comes from a new category of JavaScript apps: C/C++ applications that’ve been compiled into JavaScript. It’s a subset of JavaScript that’s been spawned by Mozilla’s Emscripten project.
But how does it work, and why would I use it?
Why compile to JavaScript?
JavaScript is the only language which works in all web browsers. Although only JavaScript will run in the browser, you can still write in other languages and still compile to JavaScript, thereby allowing it to also run in the browser. This is made possible by a technology known as emscripten.
Emscripten is an LLVM based project that compiles C and C++ into highly performant JavaScript in the asm.js format. In short: near native speeds, using C and C++, inside of the browser. Even better, emscripten converts OpenGL, a desktop graphics API, into WebGL, which is the web variant of that API.
How does asm.js fit into the picture?
Asm.js, short for Assembly JavaScript, is a subset of JavaScript. An asm.js program will behave identically whether it is run in an existing JavaScript engine or an ahead-of-time (AOT) compiling engine that recognizes and optimizes asm.js—except for speed, of course!
In terms of speed, it’s difficult to offer a precise measurement of how it compares to native code, but preliminary benchmarks of C programs compiled to asm.js are usually within a factor of 2 slowdown over native compilation with clang, the compiler frontend for C, C++, and Obj-C programming languages. It’s important to note that this is a “best” case for single-threaded programs. More on this limitation of the JavaScript language below.
On the backend, Clang uses LLVM, which is a library for constructing, optimizing and producing intermediate and/or binary machine code (those 0s and 1s again). LLVM can be used as a compiler framework, where you provide the “front end” (parser and lexer such as Clang) and the “back end” (code that converts LLVM representation to actual machine code)
Further reading: Alon Zakai of Mozilla has a fantastic slide deck which goes into further detail about how this all works.
So how cool is asm.js? Well it has its own Twitter account, #asmjs. While the asm site is a bit sparse, it does cover the W3C spec, in addition to having a thorough FAQ. Even better, Mozilla coordinated the Humble Mozilla Bundle in 2014, which allowed you to buy a bunch of gamest that took advantage of asm.js.
Why not just turn your JavaScript code into asm.js?
JavaScript can’t really be compiled to asm.js and offer much of a benefit, because of its dynamic nature. It’s the same problem as when trying to compile it to C or even to native code – a VM with it would be necessary to take care of those non-static aspects. You could write asm.js by hand, however.
If one could already translate standard Javascript in a fully static manner, there would be no need for asm.js. Asm.js exists so for the promise that Javascript will get faster without any effort from the developer. It would be very difficult for the JIT to understand a dynamic language as well as a static compiler.
To better understand this, it is important to comprehend why asm.js offers a performance benefit at all; or why statically-typed languages perform better than dynamically-typed ones. One reason is “run-time type checking takes time,” and a more thought out answer would include the enhanced feasibility of optimizing statically-typed code. A final perk of going from a statically typed language such as C is the fact that the compiler knows the type of each object when it is being compiled.
Asm.js is a restricted subset of JS that can be easily translated to bytecode. The first step required would need to break down all the advanced features of JS to that subset for getting this advantage, which is a bit complicated. But JavaScript engines are optimized and designed to translate all those advanced features directly into bytecode – so an intermediate step like asm.js doesn’t offer much of an advantage.
I go into greater detail and pictures in this post.
Recently i have played a lot with Javascript(Chrome) there are some things that came to my mind.
V8 has a JIT which make code running faster.
Functional programming means you write logic into functions and invoke/combine them by chain, means core functions will be invoked frequently(not its real definition just for get my point).
JIT is one best practice of exchange time with space basically in first time cache machine code of high-level functions and run caches in next time.
So may i say that apps will be faster if write code in FP way and run by VM that has JIT feature.
A good read on this subject is here: http://thibaultlaurens.github.io/javascript/2013/04/29/how-the-v8-engine-works/
Particularly the section that talks about how V8 compiles and injects JIT code
How V8 compiles JavaScript code?
V8 has two compilers!
A “Full” Compiler that can generate good code for any JavaScript: good
but not great JIT code. The goal of this compiler is to generates code
quickly. To achieve its goal, it doesn’t do any type analysis and
doesn”t know anything about types. Instead, it uses an Inline Caches
or “IC” strategy to refine knowledge about types while the program
run. IC is very efficient and bring about 20 times speed improvement.
An Optimizing Compiler that produces great code for most of the
JavaScript language. It comes later and re-compiles hot functions. The
optimizing compiler takes types from the Inline Cache and make
decisions about how to optimize the code better. However, some
language features are not supported yet like try/catch block for
instance. (The workaround for try/catch blocks is to write the “non
stable” code into a function and to call the function in the try
block)
In short, your fastest code is that which does not modify objects or prototypical function definitions after they've been defined
I can build SpiderMonkey as a library and use it as a Javascript engine in my C++ application.
In the documentation is been specified that SpiderMonkey is threadsafe, but what does it mean since Javascript/Ecmascript doesn't currently even have a threading model. What kind of calls or expressions are qualified as "safe" with this phrase about SpiderMonkey ? It's just about a piece of C++ code calling any JS functionality from any C++ thread to the Javascript virtual machine ?
Thread-safety of a library means that the library can be used in a multithreaded environment. SpiderMonkey library can be integrated into a multithreaded C++ application. That has nothing to do with JavaScript language model.
However certain rules and restrictions apply. Theses rules are confusing as they have been changing from one version of the library to another and the documentation wasn't and still isn't very clear about them.
Documentation pages often display notes like: "Deprecated since..." or "DRAFT IN PROGRESS...", or "Not Found 404".
Starting in Gecko 12.0 or SpiderMonkey 24, the rules are:
JSRuntime is single-threaded. You must only use it from one thread
To call the library APIs from more that one thread at once, use multiple JSRuntimes
In a JS_THREADSAFE build, many JSAPI functions must only be called
from within a request (JS_THREADSAFE is now permanently on)
Bracket API calls with JS_BeginRequest, JS_EndRequest functions or
use JSAutoRequest class
Garbage Collector suspends all other threads calling into SpiderMonkey. To keep wait time to a minimum, avoid long-running requests. Do not include blocking I/O or time-consuming calculations inside JS_BeginRequest, JS_EndRequest blocks.
You may consider building a debug version of SpiderMonkey to test your integration. Try using flags:
--enable-root-analysis --enable-debug --disable-optimize
Those add assertions in the library code to help catching thread (garbage collector, and memory) related problems earlier.
It's threadsafe in regard to your C++ application. You can use the library from multiple threads inside your C++ code, without concern for locking data structures, etc.
In this context, it's irrelevant what the library does (in your case, execute JS code). What matters is that the library itself can be used in a multithreaded environment.
From Wikipedia:
Implementation is guaranteed to be free of race conditions when
accessed by multiple threads simultaneously.
Read more about thread safety in Wikipedia.
I started to learn JavaScript recently. I've been working in the creation of applications with Node.js and Angular for a few months now.
One of the main aspects that was puzzling me was how it is possible to write asynchronous code in JavaScript in which I do not have to worry about things like thread synchronization, race conditions, etc.
So, I found a couple of interesting articles([1],[2]) that explained how I can be guaranteed that any piece of code that I write will always be executed by a single thread at the time. Bottom line, all my asynchronous code is simply scheduled to be executed at some point within an event loop. This sounds pretty much like the OS scheduler would work in a machine with a single processor, where every process is scheduled to use the processor for a limited amount of time, giving us the fake sense of parallelism. And the callbacks would be like interrupts.
The articles do not provide any particular references, so I thought that the best source on how the JavaScript execution engine work should certainly be the language specification, and so I got me the latest copy of EcmaScript 5.1.
To my great surprise I discovered that this execution behavior is not specified there. How come? This looks like a fundamental design choice done in all JavaScript execution engines in browsers and in node. Interestingly, I have not been able to find a place where this is specified for any specific engine. In fact, I have no clue how people find out this is the way things work to the point that is so categorically affirmed in books and blogs like the ones cited above.
So, I have a set of what I consider interesting questions. I would appreciate any answers providing insights, remarks or simply references pointing me in the right direction to understand the following:
Since the EcmaScript does not specify that the JavaScript execution engine should work with an event loop, how come may implementations of JavaScript seem to work this way, not only in browsers, but also in Node.js?
Does that mean I could implement a new JavaScript engine which is EcmaScript-compatible that in fact provides true multithreading capabilities with features like sychronization locks, conditions, etc?
Does this execution model using an event loop precludes me from taking advantage of multicores if I want to execute an intense CPU-bound task? I mean, I can surely divide the task in chunks (as explained in one of the articles), but this is still executed serially, not in parallel. So, how could a JavaScript engine take advantage of multicores to run my code?
Do you know of any other reputable sources where this behavior for any particular JavaScript engine implementation is formally specified?
How could the code be portable between libraries and engines if we cannot assume a few things about the execution environments?
It looks like too many questions, perhaps making this post too broad to be answered. If it gets closed I will try to ask them in different threads. But they all revolve around the fact that I want to understand better why JavScript and Node were designed with an event loop, and if this is specified somewhere (besides the browsers source code) that I could read and gain a deeper understanding of designs and decisions taken here and more importantly, to know exactly what is the source of information for people writing books and posts about it.
There are certain assumptions/weak references you make which lead you to this conclusion. Some of them are:
ECMAScript ECMA-XXX vs JavaScript vs JavaScriptEngine:
ECMAscript is a language specification, given by ECMA International. JavaScript is the most widely used web language that conforms to ECMAscript. For most part ECMAScript and JavaScript are synonymous (remember there is ActionScript). JavaScriptEngine is the implementation (interpreter) of JavaScript language code. It is a program in flesh and bones worked from ground-up unlike ECMAScript which only describes JavaScript's end goals and behaviour and JavaScript the code that uses the ECMAScript standard. You will find that an engine will do more than just conform to ECMAScript standard. They are at the ends of the specification/implementation spectrum. Example of this is ECMA-262/JavaScript/V8.
Event loop in browser vs Event loop in node.JS (JSEngine vs JSEnvironment):
This looks like a fundamental design choice done in all JavaScript execution engines in browsers and in node.
If you are using node.JS you may have used core libraries fs/net/http. These use event emitters which are hooked with the event loop provided with libuv. This is an extension to the JavaScriptEngine V8, forming node.JS platform. The event loop here involves objects like threads, sockets, files or abstract requests. But the event did not originate here. It was in first used in browsers. A browser implements a DOM which requires events for working with HTML elements. See the DOM specification and one implemented for Mozilla. They use events and require a event loop built on top of the JSEngine for browser use. Chrome adds DOM interface to the V8 engine it embeds.
Yes, you will feel this is common, because of the necessary DOM API in all browsers. Node developers brought forward this novel evented processing to server with the help of libuv which provides non-blocking, asynchronous abstraction for low-level operations required on server. As pointed already, not all server frameworks use event loop. Take example of Rhino which literally uses Java Classes for file,sockets (everything). If you actually use core Java IO, file operations are synchronous.
Now answering your questions in order:
explained in point 2 above
Yes, you can. Take a look at Rhino, there are many others. It may be possible in node but node is geared to be a high performance webserver and that might be against its zen.
Like I said event loop sits on JSEngine. It is a design pattern, that works best with IO. Multi-threaded design works better with high CPU-loads. If you want to use multiple cores in node.JS take a look at cluster module. For browsers you have webworkers
That varies from engine to engine. And how it is embedded. Browsers will have DOM and therefore event loop. Servers can vary. Check their specifications.
For browser it is possible to make it portable between them to a good extent. No promises for server.
Event loop doesn't have anything to do with javascript itself, it's a part of environment, not js engine. Since javascript was designed primarily to manipulate user interface, it was used heavily with event loop. But event loop is a part of UI implementation, not just in javascript, but in any language.
Yes, you can. But it will not be just engine, more like environment/platform. I think (but not quite sure) that you can use threads and related stuff in Rhino.
Yes, it does. In node this is usually solved by spawning more processes and in browser you can use WebWorkers.
I can't imagine a better source then specification. If something isn't there, it's just not a part of javascript (aka EcmaScript)
I have spent a good amount of time today trying to find the answers to my own questions, guided by some of the comments and other answers left for me here. I share my findings here in case others may consider them useful.
Event-Driven Design in JavaScript for Browsers
The decision to design JavaScript this way seems mostly related to the requirements of the DOM Event Architecture. In this specification we can find explicit requirements related to the implementation of events order and the event loop. The HTML5 specification goes even further, and define the terms explicitly and state specific requirements for the event loop implementation.
This must have certainly driven the design of the JavaScript execution engines in browsers. In this article Timing and Synchronization in JavaScript published by Opera we can clearly see that these requirements are the driving force behind the design of the Opera browser. Also in this another article from Mozilla, named Concurrency Model and Event Loop, we can find a clear explanation of the same event-driven design concepts as implemented by Mozilla (although the document seems outdated).
The use of an event loop to deal with this kind of applications is not new.
Handling user input is the most complex aspect of interactive
programming. An application may be sensitive to multiple input
devices, such as mouse and keyboard, and may multiplex these among
multiple input devices (e.g. different windows). Managing this
many-to-many mapping is usually in the province of of User Interface
Management Systems (UIMS) toolkits. Since most UIMS are implemented
in sequential languages they must resort to various techniques to
emulate the necessary concurrency. Typically this toolkits use an
event-loop that monitors the stream of input events and maps the events to call-back functions (or event handlers) provided by the
application programmer.
- Jonh H. Reppy - Concurrent Programming in ML
The use of event loops is present in other famous UI toolkits like Java Swing and Winforms. In Java all UI work must be done within the EventDispatchThread whearas in Winforms all UI work must be done within the thread that created the Window object. So, even when these languages support true multithreading they still require all UI code to be run in a single thread of execution.
Douglas Crockford explains the history of the event loop in JavaScript in this great video called Loopage (worth watching).
Event-Driven Design in JavaScript for Node
Now, the decision of using an event-driven design for Node.js is a bit less evident. Crockford gives a good explanation in the video shared above. But also, in the book, The Past, Present and Future of JavaScript, its author Axel Rauschmayer says:
2009—Node.js, JavaScript on the server. Node.js lets you implement
servers that perform well under load. To do so, it uses event-driven
non-blocking I/O and JavaScript (via V8). Node.js creator Ryan Dahl
mentions the following reasons for choosing JavaScript:
“Because it’s bare and does not come with I/O APIs.” [Node.js can thus introduce its own non-blocking APIs.]
“Web developers use it already.” [JavaScript is a widely known language, especially in a web context.]
“DOM API is event-based. Everyone is already used to running without threads and on an event loop.” [Web developers are not scared of
callbacks.]
So, it looks like Ryan Dahl, creator of Node.js, took into account the current design of JavaScript in browsers to decide which should be the implementation of his non-blocking, event-driven solution for Node.js.
The latest implementation of Node.js seems to use a library called libuv, designed for the implementation of this kind of applications. This library is a core part of the design of node. We can find the definition of event loops in its documentation. Evidently this plays an important role in the current implementation of Node.js.
About Other EcmaScript Compatible Engines
The EcmaScript specification does not provide requirements about how the concurrency needs to be handled in JavaScript. Therefore, this is decided by the implementation of the language. Other models of concurrency could easily be used without making the implementation incompatible with the standard.
The best two examples I found were the new Nashorn JavaScript Engine created for Oracle for the JDK8, and Rhino JavaScript Engine created by Mozilla. They both are EcmaScript compatible, and they both allow the creation of Java classes. Nothing in these engines requires the use of event-driven programming to deal with concurrency. These engines have access to the Java class library and since they run on top of the JVM they probably have access to other concurrency models offered in this platform.
Consider the following example take from JavaScript, The Definitive Guide to illustrate how to use Rhino JavaScript.
print(x); // Global print function prints to the console
version(170); // Tell Rhino we want JS 1.7 language features
load(filename,...); // Load and execute one or more files of JavaScript code
readFile(file); // Read a text file and return its contents as a string
readUrl(url); // Read the textual contents of a URL and return as a string
spawn(f); // Run f() or load and execute file f in a new thread
runCommand(cmd, // Run a system command with zero or more command-line args
[args...]);
quit() // Make Rhino exit
You can see a new thread can be spawned to run a JavaScript file in an independent thread of execution.
About Event-Driven Design, Multicores and True Concurrency
The best explanation I found on this subject comes from the book JavaScript The Definitive Guide. In this book, David Flanagan explains:
One of the fundamental features of client-side JavaScript is that it
is single-threaded: a browser will never run two event handlers at the
same time, and it will never trigger a timer while an event handler is
running, for example. Concurrent updates to application state or to
the document are simply not possible, and client-side programmers do
not need to think about, or even understand, concurrent programming. A
corollary is that client-side JavaScript functions must not run too
long: otherwise they will tie up the event loop and the web browser
will become unresponsive to user input. This is the reason that Ajax
APIs are always asynchronous and the reason that client-side
JavaScript cannot have a simple, synchronous load() or require()
function for loading JavaScript libraries.
The Web Workers specification very carefully relaxes the
single-threaded requirement for client-side JavaScript. The “workers”
it defines are effectively parallel threads of execution. Web workers
live in a self-contained execution environment, however, with no
access to the Window or Document object and can communicate with the
main thread only through asynchronous message passing. This means that
concurrent modifications of the DOM are still not possible, but it
also means that there is now a way to use synchronous APIs and write
long-running functions that do not stall the event loop and hang the
browser. Creating a new worker is not a heavyweight operation like
opening a new browser window, but workers are not flyweight threads
either, and it does not make sense to create new workers to perform
trivial operations. Complex web applications may find it useful to
create tens of workers, but it is unlikely that an application with
hundreds or thousands of workers would be practical.
What About Node.js True Parallelism?
Node.js is a fast-evolving technology, and perhaps that's why it is difficult to find opinions that are up-to-date. But basically, since it follows the same event-driven model as the browsers do, it is impossible to simply program a piece of code and expect it will take advantage of our multiple cores in the server. Since Node.js is implemented using non-blocking technologies, we could assume that every time we do some form of I/O (i.e. read a file, send something through a socket, write to a database, etc.), under the hood, the node engine could be spawning multiple threads and maybe taking advantage of the cores, but our code would still be run serially.
These days, it looks like node.js clustering is the solution for this problem. There are also some libraries like Node Worker that seem to implement the Web Worker concept in node. These libraries basically let us spawn new independent processes within node.js. (Although I have not experimented with this yet).
What About Portability?
It looks like there is no way that, in terms of the concurrency models, we can guarantee that all these libraries will play nice in all environments.
Although in the realm of browsers they all seem to work similarly, and since Node.js runs in an event loop, many things may still work, but there not guarantees that this should work in other engines. I guess this is probably one of the disadvantages of EcmaScript compared to other more extensive specifications like those defining the Java Virtual Machine or the CLR.
Perhaps something gets standardize later. In the future of EcmaScript, more concurrency ideas are being discussed today. See the EcmaSript Wiki: Strawman Proposals Communicating Event-Loop Concurrency and Distribution