Hi Jonathan, sorry for the delay in getting back to you, I hadn't checked in on this in a while.
So your JS code doesn't exactly 'import' the web API. Think of it this way: the JS language is standardised by the ECMAScript specification, that describes the features of the language and the results they should produce. But it's the browser that is responsible for actually implementing that. So when the browser's JavaScript engine was written, it implemented all the individual features of JavaScript i.e. defined a process for turning JavaScript code into binary that the CPU can execute.
But it also provided other features - the web APIs. They're not really that different, it's just that they're not part of the ECMAScript spec, and you can't use them outside a browser, because only browsers have implemented them. There are now some standards for them too, by the way, by WHATWG: spec.whatwg.org/.
So when you are using some Web API like a DOM method or fetch(), etc., it doesn't really make much difference that it's 'not JavaScript', it is just another part of your instructions that the browser understands and will turn into binary to be run. So it's not implementing it 'in JavaScript', because the JavaScript engine is usually C++ code whose job is turning JS to binary.
So what I'm trying to say is that nothing about your JS file changes after it is written. Instead, all the functionality that it produces is a result of the work of the JavaScript engine, and from the JS engine's point of view, executing Web API functionality isn't that different (aside from differences to do with things like asynchronicity, but that's a different point).
Hope that makes sense and feel free to follow up. And thanks for reading 😊
"Think of it this way: the JS language is standardised by the ECMAScript specification, that describes the features of the language and the results they should produce. But it's the browser that is responsible for actually implementing that. So when the browser's JavaScript engine was written, it implemented all the individual features of JavaScript i.e. defined a process for turning JavaScript code into binary that the CPU can execute. "
So each browser is responsible for implementing the entire Javascript language, as long as they follow the ECMAScript specification? There's no "Central" implementation of the language (in the way that there is, for example, with C# or .NET...Microsoft itself would provide you with the .NET runtime and C#, although if there is some standard C# follows, anyone else could theoretically implement the language, the way different browsers implement javascript?
Is this the reason why it's oddly unexpected at times? Which browser do you think handles Javascript as "the most optimized" or closer to the "real thing", now im wondering about how important it is for browsers to get certain features of Javascript, I mean for what they're concerned, it should always run in a certain way. I didn't know about this said "implementation"
OK first I just want to correct my previous answer slightly - the Web APIs are provided by a JavaScript Runtime Environment, which works with the JavaScript engine, I should have made that clear. The JavaScript engine is a standalone entity that can be run in a browser or another environment i.e. in NodeJS. But again, the JavaScript Runtime Environment is implemented by the browser so the point still stands.
To answer your follow-up Jonathan, essentially yes, since there is nothing very 'central' about the web. However, it's not really 'each browser', since many browsers including Chrome, Edge and a lot of lesser known browsers use Chromium, with is all the core functionality of Google Chrome, but just missing some surface-level features which other browsers add on. So the main different implementations of JavaScript are the ones in Safari and Firefox.
As for your questions Eduardo, as far as I'm aware these days there aren't really any discrepancies in the results they produce, aside from newer features of JavaScript not being supported in older browsers. I'm not sure what you mean about 'oddly unexpected' results?
In terms of the most optimised one, if you mean fastest, I don't have the knowledge in that area to say, though I would guess V8 as it's very popular and focused on high performance. I'm also not sure what you mean by the 'real thing', since they are all the 'real thing' if they meet the requirements of the ECMAScript spec. The original implementation was Brendan Eich's original build of SpiderMonkey for the Netscape browser, but SpiderMonkey has changed a lot since then.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi Jonathan, sorry for the delay in getting back to you, I hadn't checked in on this in a while.
So your JS code doesn't exactly 'import' the web API. Think of it this way: the JS language is standardised by the ECMAScript specification, that describes the features of the language and the results they should produce. But it's the browser that is responsible for actually implementing that. So when the browser's JavaScript engine was written, it implemented all the individual features of JavaScript i.e. defined a process for turning JavaScript code into binary that the CPU can execute.
But it also provided other features - the web APIs. They're not really that different, it's just that they're not part of the ECMAScript spec, and you can't use them outside a browser, because only browsers have implemented them. There are now some standards for them too, by the way, by WHATWG: spec.whatwg.org/.
So when you are using some Web API like a DOM method or fetch(), etc., it doesn't really make much difference that it's 'not JavaScript', it is just another part of your instructions that the browser understands and will turn into binary to be run. So it's not implementing it 'in JavaScript', because the JavaScript engine is usually C++ code whose job is turning JS to binary.
So what I'm trying to say is that nothing about your JS file changes after it is written. Instead, all the functionality that it produces is a result of the work of the JavaScript engine, and from the JS engine's point of view, executing Web API functionality isn't that different (aside from differences to do with things like asynchronicity, but that's a different point).
Hope that makes sense and feel free to follow up. And thanks for reading 😊
"Think of it this way: the JS language is standardised by the ECMAScript specification, that describes the features of the language and the results they should produce. But it's the browser that is responsible for actually implementing that. So when the browser's JavaScript engine was written, it implemented all the individual features of JavaScript i.e. defined a process for turning JavaScript code into binary that the CPU can execute. "
So each browser is responsible for implementing the entire Javascript language, as long as they follow the ECMAScript specification? There's no "Central" implementation of the language (in the way that there is, for example, with C# or .NET...Microsoft itself would provide you with the .NET runtime and C#, although if there is some standard C# follows, anyone else could theoretically implement the language, the way different browsers implement javascript?
Is this the reason why it's oddly unexpected at times? Which browser do you think handles Javascript as "the most optimized" or closer to the "real thing", now im wondering about how important it is for browsers to get certain features of Javascript, I mean for what they're concerned, it should always run in a certain way. I didn't know about this said "implementation"
OK first I just want to correct my previous answer slightly - the Web APIs are provided by a JavaScript Runtime Environment, which works with the JavaScript engine, I should have made that clear. The JavaScript engine is a standalone entity that can be run in a browser or another environment i.e. in NodeJS. But again, the JavaScript Runtime Environment is implemented by the browser so the point still stands.
To answer your follow-up Jonathan, essentially yes, since there is nothing very 'central' about the web. However, it's not really 'each browser', since many browsers including Chrome, Edge and a lot of lesser known browsers use Chromium, with is all the core functionality of Google Chrome, but just missing some surface-level features which other browsers add on. So the main different implementations of JavaScript are the ones in Safari and Firefox.
As for your questions Eduardo, as far as I'm aware these days there aren't really any discrepancies in the results they produce, aside from newer features of JavaScript not being supported in older browsers. I'm not sure what you mean about 'oddly unexpected' results?
In terms of the most optimised one, if you mean fastest, I don't have the knowledge in that area to say, though I would guess V8 as it's very popular and focused on high performance. I'm also not sure what you mean by the 'real thing', since they are all the 'real thing' if they meet the requirements of the ECMAScript spec. The original implementation was Brendan Eich's original build of SpiderMonkey for the Netscape browser, but SpiderMonkey has changed a lot since then.