If I use Node.js without a transpiler, i.e. something as simple as
node hello.js
what language is hello.js? I thought that, since Node.js is based on V8, it would be V8's language (presumably something close to a recent version of ECMAScript).
But Node also supports the require() function, which isn't in ECMAScript (or in V8).
Perhaps Node's language is V8 plus a subset of CommonJS? What subset?
As with every JavaScript engine out there, Node.js supports:
A collection of features from various versions of JS (since they get implemented feature-by-feature (as opposed to a single big release where ever change in a new version of ECMAScript is released at once). https://node.green/ maintains a list of features in various versions of ECMAScript and the support for them in different engines.
A bunch of extensions in the form of APIs that aren't defined by the ECMAScript specification (e.g. for filesystem access and CommonJS module support)
Related
How to check the ECMAScript standard version that the currently installed JS on the system is using, is there any special command to know or we need to check the JS version and then Google it to know on which ES standard version it is based up on.
Environments do not run "a particular version of the standard." Rather, environments implement features from different years of the specification piecemeal. For example, it may be that in June 2022, a particular browser has implemented, say, 7 of 9 specification additions or tweaks from the prior year - and a different browser will implement those things on a different schedule.
Even if something is in the standard, there's no absolute guarantee that environments will support it, unfortunately. Usually they will, and often in a reasonably timely manner, but not always. For example, proper tail calls, from ES6, still have not been implemented in V8 or SpiderMonkey.
So, to figure out what is supported in a given environment, you'll have to test all the properties/features you're looking for individually. (eg window.hasOwnProperty('Promise'))
Often, rather than script-writers trying to detect what a browser currently supports, and working around that, script-writers will simply use a polyfill service (example) that adds all necessary missing features - that way you can get on with the main logic of your application and simply not worry about it.
Vanilla JS does not have any version as of Jquery,Angular, Reactjs, etc which are build using vanilla JS. It depends whether the current browser update supports upto which version of ECMA Script. You can use any version syntax as long as you can compile your code to ES5 syntax if your browser does not understand higher version of JS.
I have a very big doubt and it is that if ActionScript and JScript are based on ECMAScript, it is possible that they can be executed in environments like Google Chrome and if not, why not?
Any code that 100% conforms to supported versions of ECMAScript can be run in Chrome. But, you can't actually do anything useful in a browser with pure ECMAScript code because you can't interact with anything in the browser itself - instead you have to use browser-specific APIs to do that which are not ECMAScript methods, but browser-specific methods that are documented in different standards. Similarly, an ActionScript script likely interacts with its environment through non-ECMAScript methods which are not support in a browser.
And a new language that conforms to 100% to the latest version of ECMAScript would not have problems with the interpreter of each browser? I say this because every browser has a dedicated JavaScript interpreter or that's what I understand so far.
It's hard to tell what you're asking. There is no such thing as a new language that conforms to 100% of ECMAScript. That would just be an implementation of ECMAScript (not a new and different language) - just like each browser has its own implementation of ECMAScript. If it is indeed a new language, then it must have things in it that are not in ECMAScript. But, my point is that, pure ECMAScript code should run in any "compatible" ECMAScript implementation that is targeting the same ECMAScript version.
There are details of implementation that are not always complete in each browser since ECMAScript is a moving target (new revisions regularly) and the development on the implementation is ongoing work in each version. So, there can be compatibility issues around the edges of newish features, but that is true of any Javascript code running across browsers that is leverage very new features. Developers who are interested in good cross browser compatibility either stay away from the very latest features, cross compile their code to a lower common denominator using something like Babel or TypeScript or they study and test exactly what they can and can't use across all their target browsers.
According to https://nodejs.org/en/
Node.js® is a JavaScript runtime built on Chrome's V8 JavaScript engine.
However, according to this answer, JavaScript is:
JavaScript = ECMAScript + DOM API;
and there is no DOM in Node.js runtime. (or is there?) Also quoting from the book: Professional JavaScript for Web Developers:
Though JavaScript and ECMAScript are often used synonymously,
JavaScript is much more than just what is defined in ECMA-262. Indeed,
a complete JavaScript implementation is made up of the following three
distinct parts:
The Core (ECMAScript)
The Document Object Model (DOM)
The Browser Object Model (BOM)
which supports the answer I link to.
Considering the facts above, isn 't it correct to say Node.js is a ECMAScript runtime? If not, what do we need to remove (or add?) if we wanted to fork Node.js and make it an ECMAScript runtime instead of a JavaScript runtime?
The difference between JavaScript and ECMAScript is just a pedantic difference that most people don't really care about. Technically the official language name according to the standard is ECMAScript, but for historical and convenience reasons people almost always call it "JavaScript". I've never met anybody who calls themselves an "ECMAScript developer".
As far as I know, JavaScript doesn't even have an official formal definition. While ECMAScript has a prescriptive definition with versions that are formally defined by their various specifications, the meaning of "JavaScript" is essentially defined by how people use it.
For this reason, Node.js advertises itself as a JavaScript runtime. It might be more "technically correct" to call it an ECMAScript runtime, but it would be more confusing for most people to advertise it that way.
There are many JavaScript run time environment:
Browsers
Node.js
Deno
Edge Workers
Moddable
Databses
Productivity Software
source: https://www.youtube.com/watch?v=JN7UjvceOlw
I want to use ES6 features in my script, and having all browsers support it. How can I do that, and can I?
I've been thinking about using some tool that will convert my code to ES5 automatically on git pulling it on the server, and create the second file out of it. And then in the browser I could use one of those scripts, depending on the browser and its version.
Is this possible?
It would however create some problems:
Converted code would have the same performance as writing the code
in ES5 natively.
I would have to write some kind of if in the HTML, and I want to
include just one script, without anything else.
What's the best way to do this?
Until more browsers support ES2015 (aka ES6) features, using transpilers and polyfills will be the only way to go. Checkout the ES6 compatibility table to determine what features you can use today for the browsers your site supports.
Keep in mind that there are two main parts to ES6:
new language features
new native API features
Until all the browsers your site supports have support for the new ES6 language features, you won't be able to use them in your scripts without first transpiling them to an ES5 equivalent. I've used babel and it has worked great. The ES5 equivalent code that is generated has performed just fine. It also beats me trying to write equivalent ES5 code manually. The code generated by babel has been thoroughly tested by babel's test suite and has been used by thousands of developers around the world. Also, writing your code with ES6 is shorter and easier to maintain. This saves a lot of developer time. When the day comes that when all the browsers your site supports have support for all the ES6 features, then you can turn off the transpiling step in your build and you'll get the full benefit of native browser performance without having to manually convert your manually written ES5 code to ES6.
Many of the new native API features can be used today by providing a polyfill. The polyfill is only needed when you want to use an ES6 feature AND you need to support older browsers. With a polyfill, only the older browsers may have slower performance compared to the native implementation. Since most of the modern browsers already support many of the native ES6 API features, many of your users will get the full performance of the browser's native implementation. From my experience with polyfills, I have not noticed any significant performance implications.
If you are concerned about modern browsers unnecessarily downloading and running the polyfill all for naught, then there are techniques you can to do minimize the impact:
On the server-side, you can detect the browser making the request and determine whether to bother sending the polyfill script tag in the response.
You can properly version the polyfill and make sure the web server's caching is set so the browser will rarely make a request for the polyfill after the initial download.
babel used to be able to transpile the ES6 code in your html files, but that feature has been removed. You can just move your embedded code to a separate external JavaScript file. If you don't like the idea of incurring another request to get this external JavaScript file, then you can do the following:
Write your ES6 code in a separate file.
Run this file through babel
Use your server-side scripting language to include the transpiled content directly in your HTML.
#DannyHurlburt's answer was correct at the time of posting it, but now, you can use TypeScript language (with .ts file extension) to work around this. TypeScript is a strict superset of JavaScript, so any ES6 code you have is also lexically valid TypeScript. TS compiles to old versions of JavaScript as old as ES3.
Browsers support JavaScript, and Node.js supports it too. I want to know if there any syntax difference between them?
Node uses Google V8, which implements the ECMAScript standard (link to non official annotated copy).
How it differs from browsers will depend on which browser (and version) you're talking about.
For example, Mozilla browsers implement JavaScript (which is an implementation and superset of ECMAScript).
JavaScript includes:
for each - in loops
destructuring assignment
let expressions
array comprehensions
...among other enhancements that utilize non ECMAScript standard syntax. These are all part of JavaScript, but not currently part of the ECMAScript standard.
(Of the 4 items listed, the last 3 are proposals for the next ECMAScript version.)
No. The Syntax is exactly the same. There are differences in the apis however. The standard browser dom is not available in node but it has additional apis found at nodejs.org. Any syntax differences are due to quirks in browsers.
No. The syntax is exatcly the same, but you're working it provides with different environment - for example, you don't have DOM and have API for file system access and sockets.