Home/ Questions/Q 7673233
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-31T16:27:54+00:00

The first part of this question is actually a request for confirmation based on

  • 0

The first part of this question is actually a request for confirmation based on JavaScript-centric research I’ve been doing all afternoon. If I am incorrect about any of these items, please correct me!

  • The ECMA is the official standards body that “maintains” JavaScript
  • Any browser that wishes to support JavaScript (which all/most of them do), must include some sort of interpreter (what is it???) engine deep inside the browser code
  • When someone points a JavaScript-enabled browser to a URI that contains JavaScript code, that browser downloads the JS file(s) along with the HTML, CSS, etc., runs the JS through this interpreter, and the resultant output affects how the page is ultimately rendered

In addition to these items I’ve also heard terms like JavaScript “plug-ins” or modules that browsers can have. What are these plugins/modules and why would a browser need them if they are ECMA-compliant and already contain a JS interpreter?

Thanks in advance!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    • The ECMA is the official standards body that sets the standard for ECMAScript which JavaScript implements. So does ActionScript. ECMAScript covers all the programming essentials and basic structure of the language.

    • The ECMA spec does NOT cover browser-oriented APIs like the DOM. This is covered by the W3C DOM standard which is meant to define a language neutral API. IE has supported the ECMA spec fairly religously since IE 6 while almost completely ignoring the DOM stuff in favor of its own proprietary BS all the way up until IE9.

    • The spec itself is just a bunch of rules for how the language is supposed to work. As long as you write the same stuff and a given browser’s interpreter gives the expected result as defined by the spec, it is ECMA compliant to whatever version being considered.

    • An interpreter parses and tokenizes the actual text you’ve written and turns it into instructions to be read by the browser’s run-time environment. Modern browsers sport actual JIT compilers which actually convert your JS into bytecode as it’s executed so that the browsers run-time environment itself doesn’t have to translate.

    • Most browsers cache the actual binary of a js file. So pages on the same domain that link to the same server location won’t have to download the same file twice when a new page links to it. This is the same as with any resource (images, css files, etc.) I don’t believe they cache the results of any of the interpretation that goes down but I think in the case of the JITs the results of certain pre-execution routines (JIT prepwork basically) might be kept in memory (pure speculation on my part – but it seems kind of duh).

    • We’ve been a bit fast and loose with language in regards to usage of words like plugins, frameworks, tools, libraries etc… It’s all just JavaScript, usually. You “plug them in” by linking a file or cutting and pasting into an existing one like any other JS. By plugin, however, people usually mean it works with some existing pre-fab JS, like JQuery, which tends to be expanded on by adding methods to the object that it returns (JQuery is just a big fancy function that builds and returns the same object every time you fire it basically). A library tends to be a large collection of pre-defined methods for doing all sorts of things. Like a warehouse ‘o stuff you can use. I think of JQuery as more of a tool than a library because its focus is more on reducing cruft and normalizing browser differences. JQ by itself doesn’t really do anything all that far removed from core JS methods. It just makes it much easier/faster to do them. It has a UI library, which is basically a large set of plug-ins that actually spit out pre-fab UI elements, HTML, CSS and all. A framework tends to be more of a system for building large-scale app-type structures on the front end. It’s not just a bunch of methods to call, it’s a way of building things aimed at making it easy to barn-raise entire app structures while skipping a lot of the more granular work one typically needs to do to keep things flexible (as a result, frameworks usually aren’t particularly flexible but that doesn’t mean they can’t be).

    • 0