As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I want to embed Javascript in a hobby game engine of mine. Now that we have the 5th generation of Javascript engines out (all blazing fast) I'm curious what engine would you choose to embed in a C++ framework (that includes actual ease of embeding it)?
Note: Just to make it clear, I'm not interested in DOM scripting or writing Javascript in a browser.
Here's a compilation of links so far and some tips from the thread
SpiderMonkey
tracemonkey (note:backwards compatible with spidermonkey):
V8
Squirrelfish
Just for the record, I love Lua and have already embedded it in game engines about 5 times at work.
However now this is a hobby project, and I think that Javascript being known by most web developers and because its ECMA, Flash and Flex developers, a game engine that uses Javascript and XML for scripting would be more user-friendly and cater to a larger user base (and one that so far has not had a chance to use their skills for games) than one with Lua (and there are plenty of those around!).
Also for the record I'll go with V8 on this one, mostly because I like it's C++ style.
Mozilla's SpiderMonkey is fairly easy and well-documented. It's a C API, but it's straightforward to wrap it in C++. It can be compiled to be thread-safe, which is useful for games since you'd likely want to have your main logic in one thread and user interface logic in a second thread.
Google's V8 might be a good choice, since you're using C++, but I have no experience with it yet. According to the documentation (thanks to Daniel James), V8 is not thread-safe, although this may change in the future.
There's also WebKit's SquirrelFish, but I couldn't find a standalone version of that when I was looking earlier.
I've tried both SpiderMonkey and V8. With SpiderMonkey, I couldn't get anything to work. I couldn't even get the examples on mozilla.org to compile.
V8 worked out-of-the-box and I got some basic C++ <-> Javascript interaction going pretty quickly. There are some google lists for people using V8, and I found most of my questions answered there already.
I believe that v8 only works on x86, x64 and arm processors at the moment. Which might be a disadvantage.
With regards to thread safety, from include/v8.h:
* Multiple threads in V8 are allowed, but only one thread at a time
* is allowed to use V8. The definition of 'using V8' includes
* accessing handles or holding onto object pointers obtained from V8
* handles. It is up to the user of V8 to ensure (perhaps with
* locking) that this constraint is not violated.
You can read more in the source file (it looks like doxygen documentation, but they don't seem to have put it up anywhere).
Update: That comment has been removed, probably some time ago. It looks like v8 now has an Isolate object which represents an instance of the engine. A single Isolate instance can only be used in a single thread at a time, but other Isolate instances can be used in other threads at the same time.
Is Java Script really the right language for your game?
Many of games out there are using the Lua programming language for scripting. It's easy to integrate, it's very small, it compiles on almost every platform and it's easy to learn.
This somewhat off topic, but thinking outside the box can be important to get things right .
When speaking of a scripting engine and c++ you could also consider chaiscript. It is close to ecma script (~Javascript) and very easy to embed in c++.
Seller from the webpage:
... ChaiScript, on the other hand, was designed from the ground up
with integration with C++ in mind.
...
ChaiScript has no meta-compiler, no library dependencies, no build
system requirements and no legacy baggage of any kind. At can work
seamlessly with any C++ functions you expose to it. It does not have
to be told explicitly about any type, it is function centric.
With ChaiScript you can literally begin scripting your application by
adding three lines of code to your program and not modifying your
build steps at all.
The benchmark that came out when V8 first hit the scene that showed V8 being 1000% (or whatever) faster than other engines was heavily weighted towards favoring engines that were good at recursion. If your code uses a lot of recursion, then V8 might give you a significant advantage, speed-wise. For "real world" (currently, at least) web stuff, SquirrelFish Extreme seems to be the hands down winner at the moment (see my blog post on the topic for the results of my own, informal testing).
As others have pointed out, ease of integration and quality of documentation might prevail over pure speed. It don't mean jack if you don't ship!
I'd wait for TraceMonkey, the next evolution of SpiderMonkey to come out. Faster and better designed. ( Uses code donated from Adobe Flash ).
Tracemonkey prides itself in making repetitious actions much faster by aggressively optimizing the structure at runtime based on actual usage, which aught to be handy for game-augmentation.
Try Javascript .NET:
http://javascriptdotnet.codeplex.com/
It implements Google V8. You can compile and run Javascript directly from .NET code with it, and supply CLI objects to be used by the Javascript code as well. And V8 is probably the best engine ever created in terms of performance, it generates native code from Javascript.
You may also want to look at V8 from Google. It's pretty new, though.
I would keep an eye on v8 as it is screaming fast javascript engine, and i'm sure it will develop cross-platform support as it grows to maturity.
Related
A rookie here.
Messing with my google scripts projects I have found a strange thing, a method that I was using was strike-through in the editor and it looked like this --> substr . Researching, I found that it is because this method is being deprecated. And for people looking how to solve it look the documentation in developer.mozilla.org.
At first, I had no problem with this, but, if it was not there before, and it is now, that means that the version of javascript that my project is using is changing and I do not want that. And there is my question
Is there a way to make the version of V8 JavaScript that my google script uses constant?
Looking in to the app-scripts documentation I have found that it uses V8 and that it is defined in the manifest but the way of freezing to a certain version is nowhere to be found. Maybe there is an easy answer, but I have no clue where else to look. Any help will be welcomed.
No, there is no way to select a particular V8 version for your GAS.
That said, JavaScript engines are generally very conscious of backwards compatibility. It is extremely rare that features are removed -- there are a good number of "legacy"/"deprecated" things in JS that won't be removed for the foreseeable future, because there's too much old and unmaintained (but still used) code out there that depends on them, and browser makers don't want to break that code.
Regarding the specific case at hand, I personally would be quite surprised if String.prototype.substr ever got removed. I see its deprecation as more of a "pro tip: how not to confuse substr and substring: only ever use one of them".
FWIW, V8 itself has no notion of deprecated JavaScript features. The strike-through you see is just an editor feature. Updating or not updating the V8 version underneath wouldn't affect it.
Taking a step back: writing software once and then expecting it to work without maintenance or monitoring for decades is, unfortunately, generally not a thing. For instance, if you developed a game for Windows 95, you'd have to expect that it won't run well (or not at all) on modern Windows versions. There are countless more examples of operating systems, SDKs/toolkits, compilers/engines, and programming languages themselves evolving over time in ways that guarantee backwards-compatibility for a couple of years but not forever. This is the flip side of technological progress. Pinning yourself to certain outdated versions is generally not a viable solution, for a variety of reasons.
So actually, in comparison, when you write an app or script in JavaScript, you have a very high chance of it still working fine 20 years later. So I wouldn't worry about it too much.
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.
I am developing a Thunderbird extension, which is mostly done in JavaScript. I want to use several functions from Mozilla's NSS (Network Security Services) library in JavaScript. There is one JavaScript wrapper built into Thunderbird, named WeaveCrypto.js, which I currently use. The problem with WeaveCrypto is its age (AES-256-CBC might have been good enough in 2010, but is not recommended today anymore, e.g. through the this. SHA1 is also not really recommended as the prf-Algorithm in PBKDF2 anymore.) and hardcoded values like iterations, algorithms and key lengths.
The JavaScript Crypto already made it to the "Archive of obsolete content", while DOMCrypt is only available in Firefox.
I am currently chatting with Justin Dolske, the developer of WeaveCrypto. His current take is that I could fork WeaveCrypto and if I only add algorithm IDs and change only small pieces of logic (like the hardcoded values to changeable ones) they would likely add my forked version to Thunderbird.
I will do that if I have to, but it sounds a bit strange to me, that the huge NSS library is not completely accessible and useable in JavaScript without extra effort, even though all logic of Firefox and Thunderbird extensions is written in this exact language (or did I miss something?).
Any ideas appreciated :)
Justin Dolske told me about the WebCryptoAPI which uses the NSS library from JavaScript. It is completely available in Firefox since version 34 (so probably also in Thunderbird since then). Most parts are, however, not supported by the famous Internet Explorer, making it more difficult to use it in browser applications. It seems still perfectly suitable for Firefox and Thunderbird extensions.
Its documentation is incomplete, but not bad. Here is some JavaScript Example Code.
Documentation on common crypto functions is also available.
The Personal Security Manager (PSM) also uses the NSS library, but does not seem to be intended for the usage in JavaScript Extensions.
BUT: The supported algorithms in NSS are not state of the art. There are JavaScript Libraries like the SJCL JavaScript Crypto Lib that contain stronger algorithms. Unfortunately, it is not really recommended to use crypto functions written in JavaScript (Javascript Cryptography Considered Harmful).
Conclusion: That is the reason why the NSS library seems like the way to go, since it is written in C and should therefore be faster and more secure than JavaScript implementations. But it should be updated to the latest security standards. In the NSS 3.3 Plan they already mention "Update the list of encryption technologies" under "Must Have" and "Elliptic Curve Cryptography (ECC)" under "Nice to Have". I cannot see much information about that in the NSS BurnDownList, but I hope there is more to come.
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.
I need some embeddable language for tasks similar to query execution in mongodb. Language should be fast and it should have both JIT and interpreter (for frequent scripts that JIT-compiled and for one-time-run scripts too), should have in-memory runtime that I populate with specific API functions (or classes, whatever) by hand (and nothing "built-in" else like gettime, thread spawning or similar), it should have C API and it should work on ARM (MIPS also would be nice), not too big footprint also would be nice (but this is not critical).
I have two candidates:
Google V8.
Spidermonkey (There was IonMonkey's ARM support announced AFAIK).
I have not experienced embedding languages into C projects before so I have a few questions: recently there was a rumor that V8 is not thread-safe, is this problem still exists? If so, where that lack of thread-safe can cause problems?
Also I would be glad if anyone suggested embeddable language which is more suitable for my requirements (except lua, I can't find any advantages in comparison with js except smaller footprint about what I don't care).
I'm not sure how SpiderMonkey's multithreading embeddability compares to V8's, but I do know that it's possible to do with SpiderMonkey -- we have a few multiprogramming embedders on dev.tech.js-engine that you may want to post followup questions to.
Our web workers implementation in the browser uses one runtime instance per worker (you can multiply instantiate the runtime in a single process) -- we've moved away from an multithread-safe single-runtime approach over the past few years because it's unnecessary for the web and adds a significant amount of complexity to the engine.
An alternative to multiprogramming is also the asynchronous, select-based, run-to-completion approach a la node.
A nit: I don't think an interpreter is really a requirement of yours -- your requirement is fast start up times for one-off code. SpiderMonkey has an interpreter and V8 does not, but V8 has a fast-code-emission (which we tend to call "baseline") JIT compiler that offers comparable performance in that area. That capability is an important requirement for JS on the web in general. :-)