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.
Related
I would like to filter an array in my XPage with serverside Javascript. Unfortunately I get the following error:
Error calling method 'filter(Function)' on an object of type 'Array [JavaScript Object]'
I have an Array of Strings like ["elem1","elem2","elem3"]
I call the function like this:
list.filter(function(){
});
Is there any reason why this error happens? Does this function even exist in ssjs?
This question is not duplicate since it is not clear that Xpages/Lotus Notes runs Rhino in background.
It sounds like whatever server-side JavaScript environment you're using doesn't support ES5 features (that's features from the 5th edition specification from December 2009).
You can use a polyfill for that and other things that were added to Array, see MDN, but beware: If ES5 features aren't supported, it's impossible to add things to Array.prototype without making them enumerable, meaning any code (mis)using for-in to loop through arrays will be affected.
There is Rhino behind XPages. And this SO topic
No Array.filter() in Rhino? says, it is out of date.
Edit:
No, it is not. Years ago I read somewhere about it. Now it seems it was not true. According to comment by Dan Sickles (quoting Philippe Riand?) here:
It runs on the server jvm and uses javascript as the application
language. For licensing reasons, IBM wrote their own jvm javascript
engine instead of using Rhino. With Rhino shipping in java 6, they
should be able to ship it in Designer 8.5 (or later). The licensing
problems may have been around the extensions like #Formulas and type
declarations. Classes, modules/namespaces and type declarations are
coming in javascript 2 and even google is helping to get that
implemented in Rhino. I'd hate to see a non-standard, javascript
engine underlying the coolest web development technology in Domino.
Speaking of Rhino, the "most important new feature that is not as
certain to be in 8.5 as XPages" uses Rhino and other jvm scripting
languages on the client. If this makes it into the product, two years
from now most new Notes applications will be written in neither
Lotusscript nor Java. I'll leave it at that.
In fact, there are few topics how to use Rhino in XPages, so with newest Rhino version your code would work. Anyway, my advice is to use Java calls.
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'm interested to find out how the JavaScript interpreter (engine if you like) works. I'm aware that JavaScript isn't compiled.I have looked at the ECMA specification, but it doesn't explain how the actual engine works.
The main reason why I'm asking this is because I'd like to understand why IE7 behaves slightly differently to IE8 or Firefox 3.5+.
I suspect that certain function calls get handled in a different order, but I'd like to know for sure.
I have also watched few videos by Google talks on JavaScript optimization along with the JavaScript: Good Parts video. These touched on the topic briefly.
I have exactly the same problem - Execution Contexts in the ECMA spec. does provide some obscure! insight. Idiosyncrasies though are rampant amongst even a single platform's versions.
Generally, topics on Automata, Recursive Function Theory, Formal Language Theory and Compiler Design provide a solid background for "understanding" an interpreter.
In the abstraction, if the semantics are exhaustively well-defined, without requiring "disambiguation", then the formal function results will be identical regardless of implementation. In practice, there is a lot of wriggle room, as seen by the extras such as .toSource(), that one engine might have and another not.
stackoverflow ref: What are Gecko's operational semantics?
If you can deal with low-level languages, look at the sources of V8 or TraceMonkey and research them. It is a bit difficult way to understand the internals of the JavaScript engines, but it is quite interesting.
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.