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.
Related
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 was seeing the W3C Document Object Model and excited that different programming languages have to implement their interfaces accordingly. Like other languages, JavaScript also maintains the DOM.
So I'm curious to know about the following questions:
Which versions of javascript implements dom level 1, 2,3 and so
forth.
Are they all implemented in javascript?
Are they implemented by javascript or implemented by ECMAScript and
followed by JavaScript?
And what are the IDL definitions described in W3C DOM: Are they
needed to understand for javascript developers or is that the symbol
of implementation by HTML?
The pedantic answer is "none".
There is no formal mapping of JS iteration to DOM-specification.
In general, JS-versioning has all but been abandoned (save major overhauls), though can be seen as signposts of when you might start to consider feature-checking.
This is because...
Not really, no.
That is to say, yes, the APIs which you will use to interface with the HTML DOM are all implemented in JavaScript...
However, no browser has a stable, feature-complete implementation of either
JS or HTML DOM[1-4].
Because both specs are so large, and ever-changing, different vendors have prioritized different features at different times, leading to patches of incompatibility.
To further this actual answer, the JS spec says nothing of DOM or BOM ("Browser ...") APIs.
This is the reason #1 must be a "No", as different DOM/BOM combinations on different JS implementations leads to the fundamental inability to say "All JS1.7-compliant browsers are DOM3 compliant."
The truth is that no browser is wholly compliant with either spec, and neither spec is the latest, anyway. As for technical-implementation (the code behind the API), there are no rules, so long as the behaviour is well-defined. Some browsers defer to C/C++ for core JS/DOM/BOM functionality, while older IE browsers had an ActiveX layer between the browser and JS DOM access (making touching elements for any reason arbitrarily expensive).
Here's the rub.
Most people would consider them to be different things.
Most people would think "JS is the thing that you use in the browser, to do your scripting.".
Really, ECMAScript and JavaScript are the same thing, and "JavaScript" is a Sun (now Oracle) trademark... how none of us are getting sued is a mystery.
JS/ECMAS knows nothing of DOM or BOM, and it's up to the vendors to include DOM-access in their browser (on a per-feature, rather than per-version basis). It should also be noted that while VendorA might implement a feature from the spec, and VendorB might omit it, VendorC might have an off-standard implementation of it, and also implement a similar but completely out-of-spec feature, as well.
Don't worry about the DOM implementation specifics.
As a JS-dev, you won't need to know or care what a Java implementation of an HTML node might look like.
Even with WebIDL, and moving away from the old-world Java-centric view, as far as day-to-day usage of JS as a language, the DOM-node interfaces are as dry as toast, unbuttered, face-down in a sand dune, unless it's really what you're into.
Even then, it's more for people who make the browsers, and not the people who make things which run in them.
These aren't all of the answers. And while I've tried to remain subjective, I'm sure there's a little objectivism in there, as they aren't wholly cut and dry. I've tried to be, at least, factual.
From an engineering perspective, being careful about how and when you use the DOM in client-side JS is important -- both for making code portable and for allowing each language in the client-side stack to have access to the HTML in question, without doing somersaults in JS, to accommodate, because you built your whole site using DOM construction in JS.
From a pragmatic standpoint, rather than trying to match features to versions, use sites like http://caniuse.com to match features to browser versions. It's much more productive.
And have fun.
I was wondering why JavaScript has such a confusing API. It is not consistent across browsers, there is a different way to get the value from each type of form input, and it is unforgiving of mistakes. jQuery has changed my life because its API is so much easier. Why did the creators of JavaScript not set up the API like that in the first place?
The JavaScript API, itself, is consistent between browsers (and is defined by ECMA, though originally developed by Netscape). The difference between browsers is the document object model (DOM). The DOM was developed independently by the different browsers, originally IE and Netscape, but now IE, Mozilla and others. The W3C has joined to try to consolidate the differences and create a common standard. For backward compatibility, the old differences remain. And, yes, jQuery has gone a long way toward making the DOM easier.
Creators of Javascript did not setup the API, since Javascript is a language, not an API.
What you are refering to is the Document Object Model (DOM) which is the document manipulation API. It is a standard specified by the W3C and its behaviour should be consistent among browsers.
Unfortunately, some parts were badly specified, some other parts are badly implemented by browser vendors. Additionally, vendors extend this API with proprietary extensions that may never be added in the standard but that are very popular (like document.all in its time).
That's why today's API in browsers are so inconsistent.
I think most of it is the remnant of the browser war. Javascript had a very troublesome history, made of a total war between microsoft and netscape, with Sun involved as well. Javascript is actually a very nice language. It has some critical design mistakes, but you can work around them. As for the API, you can use a good wrapping library that hides all the complexity and uses the most appropriate API.
One important suggestion, if I may. Don't fight it, nor try to use it masked as something else. Embrace it even with its defects. Once you know them, you won't step on them anymore, or if something is fishy you will find the problem easily.
I'll bite. Check out Douglas Crockford's videos (http://javascript.crockford.com/), he does a good job explaining why some of JavaScript is in the situation that it's in. (http://yuiblog.com/blog/2007/01/24/video-crockford-tjpl/)
This doesn't directly answer your question, but:
A lot of people are bothered by the between-browser inconsistencies. While a few folks become really good at ironing out the differences in their own JavaScript code, most can't afford to spare the time. This is why there is such a profusion of frameworks available to do the dirty work for you. JQuery is the most popular of these, I think, and I'd recommend it to you as an alternative to swallowing a lot of Aspirin for your headaches.
Using the tiny Diggit/Blog feature of StackOverflow described here:
I would like to post the following Google tech talk video I have just saw and that I found quite interesting.
I have always had problems understanding javascript "nature".
Here, the JavaScript good parts are described by Douglas Crockford
I hope you find this link useful.
Now the question part:
What are your complaints about javascript?
Do you use an IDE for javascript editting?
Do you think this video helps to understand the "good parts"?
JavaScript: the bad parts.
The biggest mistake is late error detection. JavaScript will happily let you access a non-existant object member, or pass the wrong number of arguments to a function, and fill the gap with ‘undefined’ objects, which, unless you deliberately check for them (which is impractical to keep doing everywhere), will cause an exception or generate an unexpected value later on. Possibly much later on, resulting in subtle and difficult-to-debug errors appearing nowhere near the actual problem code. These conditions should have generated exceptions, except that JS didn't originally have exceptions to raise. ‘undefined’ was a quick and dirty hack we're now stuck with.
Undeclared variables defaulting to global scope. This is almost never what you want and can cause subtle and difficult-to-debug errors when two functions both forget ‘var’ and start diddling the same global.
The model of constructor functions is weird even for a prototype-based-OO language and confuses even experienced users. Forgetting ‘new’ can result in subtle and difficult-to-debug errors. Whilst you can make a passable class/instance system out of it, there's no standard, and most of the class systems proposed in the early tutorials that people are still using are both desperately inadequate, and obfuscate what JavaScript is actually doing.
Lack of bound methods. It's utterly unintuitive that accessing “object.method” when calling it makes a magic connection to ‘object’ in ‘this’, but passing “object.method” as a reference loses the connection; no other language works this way. When this happens, ‘this’ is set to an unexpected value, but it's not ‘undefined’ or something else that would raise an exception. Instead, all the property access ends up on ‘window’, causing subtle and difficult-to-debug errors later.
There is no integer type. Number looks like one but breaks down in various ways (eg. n+1==n for high enough n). Any time a NaN or Infinity sneaks in (quite unexpectedly if you think you are dealing with integers) you won't find out immediately; instead there will be subtle and difficult-to-debug errors down the line.
There is no associative array type. Object looks like one but breaks down under various unexpected keys. Arrays aren't pure lists. Any time you ever use ‘for...in’, you have probably fallen into a trap, and will experience... yes, subtle and difficult-to-debug errors.
Generally poor string handling, for a scripting language at least. String.split(, limit) and String.replace() don't do what you might think, causing... you know. The results of toString() are generally poor and not useful for debugging. Meanwhile we are stuck with a load of rubbish Netscape thought might be useful, like String.prototype.blink(), and the perpetually broken escape(). Yay.
And then there's all the browser differences (IE is still missing a lot of essential methods on the basic objects), and the DOM...
And finally, even when an exception does occur, it is hidden away from view, so the author won't even realise something is wrong. The result is that most sites are chock full of errors; turn on full JavaScript error reporting in IE and the result is unusable.
It scares me to think a new generation of programmers are learning this tosh as a first language. What's worse, most of the tutorial material they're learning from (“My fiRST AEWsome R0LL0VERZ!”) invariably encourages the worst possible practice. ‘javascript:’ URLs, ‘eval()’ for everything, browser-specific DOM access... oy.
The hard part about javascript, in my opinion, is:
Cross browser development/debugging issues
Cross browser dom/model issues (event bubbling, etc...)
Lack of "classes" (subjective)
Lack of good solid debugging support in browsers
Firebug helps a lot for FireFox, but I have not found anything that good for IE - and the mere fact that one has to is difficult.
On the bright side, if you build a script from the ground up and understand each step, it can be really enjoyable and powerful.
alt text http://oreilly.com/catalog/covers/9780596517748_cat.gif Javascript the Good Parts is a pretty decent book too.
For Javascript Firefox+Firebug and Notepad++ are my IDE. jQuery (and assorted plugins) is my Framework. My biggest complaint about Javascript is IE6
My biggest complaint while using JavaScript are the DOM bindings, but those are not really the fault of JavaScript so much as each browser implementing it their own way. Along those lines, IE is the worst offender.
In terms of pure JavaScript issues, I still don't fully grok prototyping in a way that allows me to use its full power; but that's less a complaint than my own personal failing. As a language I like JavaScript a lot, and any complaints I have on it are overshadowed by its interactions with the DOM.
I use Firefox + Firebug intensively for my main coding and debugging. There are debuggers in Opera and Safari that I use if either browser is having particular issues. Heaven help me when I need to debug IE.
I code in whatever text editor is available and has syntax highlighting. I tend to use the YUI framework, but that's just because I know it the best; I hope to someday learn more about other frameworks and decide which would be best for personal projects.
While I haven't seen the video, I just read "The Good Parts" this week. If the video is anything like the book, it'll be very helpful. The book itself is great because it's concise and informative. It goes into a level of language discussion that one doesn't see often enough when Googling for information, that gives one a better comprehension of the language as a whole.
I really like prototyping, it feels much more powerful than normal classes.
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.