Is there a standardized ES6 file extension? If so, what is it? - javascript

I'm wondering if there's a standardized file extension for ES6 yet. So far I've seen .es6 and .es6.js as two options, but I'm curious if one is generally better supported by third party packages and tools. And if Mozilla is leaning a particular direction.

There's no formal ES6/JS extension, although majority of people seem to prefer .js. ECMAScript specific suffixes aren't common.
Mozilla is using two extensions within Firefox and FirefoxOS: .js and .jsm. No ECMA Script specific suffixes.
For Gecko (the layout engine written largely in JS), they use both .js and .jsm. Example: one of the DOM modules source code.
In some other subprojects, such as Gaia, they use .js only. Example: "system" app for Firefox OS.
Note: .jsm is something specific to Gecko - it's a Javascript module.
Note: ECMAScript 6 is a standard that is later implemented in Firefox as Javascript. So those two terms are closely related, and are almost synonyms (source).
Heads up: source code on the Gecko side has the syntax that is plain JS with some extensions - some of which ended up in ECMA Script 6, some not. In general, though, Mozillians tend to follow ECMA Script spec closely. Possible differences are listed here.

Related

Is Babel used to produce backward or forward compatible Javascript code?

I have been reading through a book called You don't know JS and one thing that I can't wrap my head around is the concept of backward compatible and forward compatible Javascript.
From what I understand:
Backward Compatible: Once something is added to Javascript specification, it would never become invalid JS in future
Forward Compatible: Including a new addition to the language in a program would not cause that program to break if it were run in an older JS engine
Javascript is backward compatible and not forward compatible. This means that while including new feature in a program might break the program (forward compatible), Javascript engines would support older syntax forever in future (backward compatible).
To solve a problem of forward compatible issue, developers use transpilation and polyfills to convert new syntax to an older syntax supported in older Javascript engine.
So if transpilation is used to convert code into forward compatible code, does that mean Babel is used to solve forward compatibility issue and not backward compatibility issue?
This comes from the official doc in Babel website:
Babel is a toolchain that is mainly used to convert ECMAScript 2015+ code into a backwards compatible version of JavaScript in current and older browsers or environments.
I must have missed something and need some clarification on how to think through this.
Edit 1
I thought it would be helpful to quote parts of the book here:
Typically, forwards-compatibility problems related to syntax are solved by using a transpiler (the most common one being Babel (https://babeljs.io)) to convert from that newer JS syntax version to an equivalent older syntax.
Developers should focus on writing the clean, new syntax forms, and let the tools take care of producing a forwards-compatible version of that code that is suitable to deploy and run on the oldest-supported JS engine environments.
I believe your confusion is rooted in the mixing of the forwards- and backwards-compatibility terms for both the operating environment or language, and individual scripts themselves.
In the You Don't Know JS doc, the writer is describing the implementation of the language as whole as being backwards compatible, in the same way that many video games released for early generations of consoles (such as PlayStation and XBox) are able to played on their more recent successors (PlayStation 2 and XBox 360) due to the console (and its architecture, operating system, etc) being backwards compatible. When applied to JS, this means that a browser implementing a newer version such as ECMAScript 2015+ will fully support code written using an older version.
Babel, on the other hand, is referring to the code itself, and being able to create a backwards compatible version which can be run on older browsers, for example. To expand on the example above, this would be akin to being able to process an XBox 360 game through some engine (i.e. Babel) and have it give you a fully functional game to play on your original XBox. This is clearly a much more difficult problem, but is required due to JS not being forward-compatible.

Do compilers for javascript differ from web browser to web browser

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.

Internet Explorer Doesn't Support JavaScript?

I am recently reading about Node.js and got an interesting statement about JavaScript and Internet Explorer:
Internet Explorer doesn’t actually support JavaScript or ECMAScript; it supports a language variety called JScript. In recent years, JScript has fully supported the ECMAScript 3 standard and has some ECMAScript 5 support. However, JScript also implements proprietary extensions in the same way that Mozilla JavaScript does and has features that ECMAScript does not.
Source: http://chimera.labs.oreilly.com/books/1234000001808/ch01.html#chap2_id35941400
Frankly speaking I am totally unable to understand the above statement. I know Microsoft has its own VBScript and it allowed JavaScript in IE that is why JS is more popular than any other scripting language. Is this statement true? If yes then the scripting engine of IE does the translations of native JavaScript to JScript or what is the other case?
ECMAScript is the official standard, JavaScript and JScript are implementations of that standard. Just like CPython and Jython are implementations of Python.
As so often if it's about browsers, they both don't necessarily fully support the standard or provide additional, non-standard features, partly because they started evolving when an official standard didn't exist yet.
From Wikipedia about JScript:
[Microsoft] did not want to deal with Sun about the trademark issue, and so they called their implementation JScript. A lot of people think that JScript and JavaScript are different but similar languages. That's not the case. They are just different names for the same language, and the reason the names are different was to get around trademark issues
From the Microsoft documentation about JScript:
JScript is the Microsoft implementation of the ECMA 262 language specification (ECMAScript Edition 3). With only a few minor exceptions (to maintain backwards compatibility), JScript is a full implementation of the ECMA standard.
well, this mainly depends on the version of IE you are using, as you havent mentioned that no one can say that for sure
I think it is not like that instead Microsoft gives you an option to enable Javascript on your IE like this:
Pull down your TOOLS menu
Select Internet Options...
Click the Security tab on the top of the resulting window
Click the Custom Level button
Scroll the list down to the entry for Active Scripting
Check the Enable radio button.
Click OK in all dialogs.
Also Jscript is same as Javascript
JScript is Microsoft's dialect of the ECMAScript standard[2] that is
used in Microsoft's Internet Explorer.
JScript is implemented as a
Active Scripting engine. This means that it can be "plugged in" to OLE
Automation applications that support Active Scripting, such as
Internet Explorer, Active Server Pages, and Windows Script Host.[3] It
also means such applications can use multiple Active Scripting
languages (e.g., JScript, VBScript, PerlScript, etc.).

V8 and ECMAScript differences

Where can I find a list of all the differences between V8 and ECMAScript? For example V8 supports const, which isn't part of the ECMAScript standard.
Edit: Direct answer: Track status of ES5 implementations in progress which indicates the V8 googlecode issues tagged es5
or https://github.com/joyent/node/wiki/ECMA-5-Mozilla-Features-Implemented-in-V8
V8 implements all of ES5 currently aside from a handful of edge cases, and only then in order to be compliant with the majority of how other current browsers handle the given situation.
Because it won't be living on its own nearly all of the differences you'll be dealing with will be in the host environment implementation wrapped around it. For most uses this is the various APIs web browsers provide. As a non-browser example, Node.js provides custom APIs for file system and network interaction. In terms of core language there's just not that much wiggle room. Minus the DOM, JavaScript is a pretty damn simple language to use (part of why it's so awesome) and has a really specific Specification document.
ES5 is an iteration up from ES3 and nearly 100% backwards compatible if not using 'use strict'. After nearly a decade of stagnation along with inability to gain a consensus among major JavaScript engine implementers ES5 was born and limited primarily to cut out and address the worst issues with the language. The extent of mainstream use ES5 is Array extras, Object extras (mainly Object.create), Function.bind, and strict mode (which is entirely about stripping features out), and a handful of natives helpers like built in JSON and base64.
Most of this 240 page specification is spent in laboriously defining every detail about behavior that has existed in JavaScript for almost 15 years, as well as the list of features which will be deprecated and eventually removed (with, various uses of eval, etc.).
Harmony (ES6) is the first real big change we're going to see. ES5 accomplished the goal of getting engine implementations on the same page and gutting most of the problematic parts of JS. Looking forward to ES6, it's time to address some fundamental language issues that require syntax changes to fix. ES6 is scheduled for finalization in late 2013 but large chunks are already implemented in JS engines in order to test them and see how they work in practical usage. The web is a living thing and implementing new standards isn't a matter of creating a new spec and then unleashing it on the world like it is most other industries. Ideas are floated and must past muster at both the implementer level (the guys who write V8, Spidermonkey, JSC, Chakra, etc.) and then the actual user level (user in this case being web developers writing code to run in those engines). Ivory tower dictation just results in lack of use.
Specifically in the case of const: this is currently not exactly defined entirely. It's a keyword with similar but not exactly the same functionality in V8 and Spidermonkey, and has a similar but not exactly the same meaning for ES6. You're probably safe to use it if you expect your target audience's engine to support it currently, but as implemented it wasn't technically part of any official spec. migrating let' andconst'
Beyond that there's "Host Objects" which are exposed by the given engine a JS script is running in. JavaScript existed first as an implementation and second as a specification, so until recently it wasn't obvious to non-experts to know where the diving line is. When it's running in a browser (as is usually the case) the Document Object Model is exposed as a host object for automatic usage. The functionality of the DOM is largely described using IDL and is under the purview of the W3C. The multitude of specification implementations encompass 6 top level sections, almost 50 separate working groups, and around 1000 separate specifications. These are interfaces exposed to JavaScript but completely ungoverned by the requirements of any JavaScript specification. The DOM encompasses a huge space of described functionality and continuously changing implementations thereof.

How do browsers execute javascript

I'm trying to figure out if web browsers use an interpreter to execute javascript, or some sort of compiler. It is well known that scripting languages are interpreted not compiled; however there is the JScriptCompiler that can compile javascript into MSIL. This leaves me to wonder if IE, FF, Chrome etc are using some sort of compiler or if it's an interpreter.
Can anyone cite the specific method in which browsers run javascript?
In the past, Javascript was interpreted -- and nothing more.
In the past two years or so, browsers have been implementing new Javascript engines, trying to compile some portions of code, to speed Javascript up.
For more informations on what has been done for Mozilla Firefox, you should take a look at :
JavaScript:TraceMonkey
an overview of TraceMonkey
For more informations about Chrome's engine, you'll want to read :
Dynamic Machine Code Generation
And for webkit (safari) :
Announcing SquirrelFish
Not sure what has been (or is being) done on other browsers -- but I suppose the same kind of thing exists, or will exist.
And, of course, for more informations : JavaScript engine, on wikipedia.
Heres' for IE
http://blogs.msdn.com/b/ie/archive/2010/03/18/the-new-javascript-engine-in-internet-explorer-9.aspx
And here's FireFox:
https://hacks.mozilla.org/2009/07/tracemonkey-overview/
(thanks to Pascal MARTIN)
JScript is a scripting language provided by microsoft. Its compilation is taken care by CLR.
Also it can be interpreted. It have tighter integration with Visual studio.
Have a look at http://msdn.microsoft.com/en-us/library/72bd815a%28v=vs.80%29.aspx for detail Jscript description.
javascript scripts are usually interpreted in web browsers (not sure about chrome and V8), but here and there you can find some standalone software which can compile it more or less correctly. This language isn't as fast as many other and his speed and functionality depends on browsers engine.

Categories