I would be interested to know a little about the history of the process of implementing touch events into the javascript language, such as when, but, better yet, the process by which the javascript developers decided on the rules for the touch api (is it an api?).
Also, do all touch devices adhere to a standard set of rules ... they would have to, right? otherwise how could javascript's touch api be cross-device dependable.
EDIT: wouldn't implementing a touch api into javascript constitute a new version of javascript?
wouldn't implementing a touch api into javascript constitute a new version of javascript?
Its important to recognize that the word Javascript can refer to many different things. There's the official ECMAScript spec, and then there are various implementations by different browsers and server-side environments. These implementations all implement different parts of the ECMAScript spec. Generally they each include some subset of the spec, along with some proprietary features as well. There were implementations of touch APIs (going back to safari on the original iPhone at least) well before it was part of the official spec.
This seems to be the spec that defines these events http://www.w3.org/TR/touch-events/, where it says:
Implementations that use ECMAScript to implement the APIs defined in
this specification must implement them in a manner consistent with the
ECMAScript Bindings defined in the Web IDL specification [WEBIDL] as
this specification uses that specification and terminology.
JavaScript is ECMAScript, or if you will, the ECMAScript implementation from Mozilla.
Related
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 don't mean the infamous HTML element <blink>, but the JavaScript function String.prototype.blink.
The MDN page in my link - but also a few other sources found by Google - indicate that this is a deprecated feature (W3Schools goes even further and lists it as nonstandard, incorrectly noting that it's not supported by any current browser, but anyway...)
alert("Hello World!".blink());
After a look into the ES6 specification (current RC is 34), I couldn't find any evidence for those claims: apparently, nothing in the spec suggests that the blink method is deprecated, obsolete or nonstandard.
Same thing for the other string methods big, bold, fixed, fontcolor, fontsize, italics, strike, sub, sup: while the respective HTML elements are deprecated, the JavaScript methods don't look like they are.
Of course, my sources may be inaccurate, but the MDN reference is usually quite reliable, so I'm suspecting that I'm overlooking something here.
Can someone else confirm or debunk the fact that the blink method is deprecated? Sources appreciated.
As neither the ES5 nor the ES6 spec uses the word "deprecated" anywhere, that leads me to believe that none of the methods are deprecated. Whether they should be is an entirely different matter...
They may produce tags that have been deprecated by the working group in charge of HTML or the DOM API, but the ECMAScript spec does not seem to recognize (or at least use) the concept of deprecated methods or classes.
Javascript in general doesn't have a concept of deprecation, even within the language, as discussed in this question. Some language features largely considered ambiguous or poor practice, such as the with statement, are not marked as "deprecated" in any official reference I can find. Methods like unescape are marked as deprecated in their MDN docs, but not the spec.
Yes
I think the description at the top of Annex B, where all these methods are defined, is pretty clear (emphasis mine):
The ECMAScript language syntax and semantics defined in this annex are required when the ECMAScript host is a web browser. The content of this annex is normative but optional if the ECMAScript host is not a web browser.
NOTE: This annex describes various legacy features and other characteristics of web browser based ECMAScript implementations. All of the language features and behaviours specified in this annex have one or more undesirable characteristics and in the absence of legacy usage would be removed from this specification. However, the usage of these features by large numbers of existing web pages means that web browsers must continue to support them. The specifications in this annex defined the requirements for interoperable implementations of these legacy features.
These features are not considered part of the core ECMAScript language. Programmers should not use or assume the existence of these features and behaviours when writing new ECMAScript code. ECMAScript implementations are discouraged from implementing these features unless the implementation is part of a web browser or is required to run the same legacy ECMAScript code that web browsers encounter.
Note that most of the string methods are not mentioned in ES5. As so often when it comes to web, browser vendors did their own thing and added custom extensions. In this case it got to a point where the TC39 committee decided that is important to at least mention them in the spec.
JavaScript and HTML (on the client side at least) are linked together. The blink method does the following (as per MDN):
The blink() method creates a HTML element that causes a string to blink.
Since the <blink> tag is deprecated, or at least classified as a non-conforming feature ...
The element is a non-standard element.
HTML5 classifies it as a non-conforming feature.
Source: http://www.w3.org/wiki/HTML/Elements/blink
... and the blink method generates such a deprecated tag, I think it's inferred that the JavaScript method is deprecated as well.
However, I can't find any official source saying as much, so I understand this is a less than perfect answer.
-EDIT-
As #ssube noted in a comment: A) the ES6 standard isn't even finalized yet, B) the drafts of it (which can be found here: http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts) don't even have the word "deprecated" in them. So it seems like in some sense it is true that the blink method isn't deprecated, because nothing is deprecated.
However, it seems any responsible documentation site (eg. MDN) is going to list it as deprecated because of it generating a deprecated tag, and that's the true origin of its "deprecated" status.
What i found:
Deprecated
This feature has been removed from the Web standards. Though some browsers may still support it, it is in the process of being dropped. Do not use it in old or new projects. Pages or Web apps using it may break at any time.
source: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/blink
I hope this can help you.
I wanted to ask a few questions about javascript:
1.Does each browser implement javascript by itself ? Or is their a common SDK\API or whatever ?
2.If each browser implement by itself, Is the javascript engine bounded to the browser version ?
I mean, can I have 2 different engines for the same browser version ?
3.Is there any standards all javascript engines must follow ? Does this standard define memory
allocation ? (Lets say, How I allocate a javascript string ?)
And last,
What are the names of implementation for each browser ? For example I understood FirFox uses an
implementation called "Rhino", Am I right ?
Thanks alot !
Michael
Yes, they implement JavaScript on they're own.
Yes, it is bound to the browser version. No, you can't have 2 different engines for the same browser version. You can though for different browser versions.
Yes, it is called EcmaScript. Most implementation follow it pretty good.
FireFox does not use Rhino. Mozilla developed it, but the implementation in FireFox is different. All browsers implement single-threaded JavaScript, while Rhino is not single-threaded.
Each browser does implement its own version of JS. Thus, why some browsers outperform others. They specification on what JS should do and how it should be done is based on the ECMAScript specification. The only case I've seen of having multiple engines (or versions of engines) is with IE's web dev toolbar, where you can "roll back" your IE version to test how previous versions react. I've found the JS engine to be pretty faithful when doing browser version tests.
Wiki has a nice write up on the different engines. http://en.wikipedia.org/wiki/JavaScript_engine#Mozilla
JavaScript is standardized through the ECMAScript specification which most browsers will adhere to.
However, not all features are implemented across all browsers and browser versions and some features have their own browser specific quirks.
You can find more details about ECMAScript and the versions browsers implement here:-
http://en.wikipedia.org/wiki/ECMAScript
You will not get two different JavaScript engines offered to you within the same browser (usually).
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.