1

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!

Improve this question
3
  • Not a code related question, should be moved ? Commented Mar 21, 2012 at 22:11
  • mozilla.org/rhino Commented Mar 21, 2012 at 22:13
  • @RTulley rhino is about javascript, but not about browsers. Commented Mar 21, 2012 at 22:18

2 Answers 2

Reset to default
4

  • ECMA is the standards body that enforces the "standards" of JS. They keep the language consistent and documented (although knowing it's history, they didn't do good with that job as a "standards body")

  • A JavaScript engine is a piece of software embedded into the browser to parse JavaScript source code. It's what turns your JavaScript into actions on screen (and off screen). An example of these are V8 (Chrome), TraceMonkey (Firefox), Chakra (IE), Carakan (Opera) and Nitro/SquirrelFish (safari)

  • Before the above happens, one must introduce the JavaScript code into the browser to be parsed (usually using <script> tags)

  • JavaScript Plugins/Toolkits are just code developed by programmers to do stuff easily. they just do things that normally you would code 1000 lines for. these code also "improve" programming by giving consistency cross-browser. Examples of plugins/toolkits are jQuery (and it's UI plug jQueryUI), YUI, Dojo and so on.

  • Browser extensions/plugins on the otherhand "extends" the functionality of the browser. Examples are ADBlock (whick blocks page ads), FlashGet (Downloads flash files on the page). These guys are programmed into the browser rather than into the page. However, lately, these extensions are powered by JavaScript for the reason that it's easy to program

Improve this answer
Sign up to request clarification or add additional context in comments.

6 Comments

Thanks joseph! Great answer! On the plugins stuff - can you provide an example of a specific JS plugin and explain what it does and why it is necessary (as opposed to just writing a JS file)? Thanks!
In both Firefox and Chrome ALL plug-ins are written in Javascript (Firefox plug-ins also have this special HTML-like stuff called XUL, but that's not important). Javascript in plug-ins has access to MUCH more than Javascript on a page has. For instance, there is no Javascript you can write for a webpage that will make it automatically add itself as a bookmark, because browser-makers would never allow it (what if a bad website added 100 bookmarks of itself when you visited it?). However, a browser plug-in could bookmark every page you visit if it wanted to.
@machineghost what you mean are browser extensions am i right? well, i forgot about that. I though the OP meant plugins that enhance the page effects, like jQuery plugins. Browser extensions are software that are "plugged-in" or "extends" the functionality of the browser. Most of the extensions today are programmed using JavaScript itself (since JS is a widely known program, easy to understand, as compared to stuff like C++ and others)
So is a JavaScript plugin just a JS file a web developer would use, like any other API or reusable component?
Ah yeah; different browsers call them different things, but "extension" is probably the better term.
|
2

  • 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).

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.