You can use WASM in extensions. WASM qualifies for independent pieces of code written in a compiled language. Does that make extensions plugins?
I really don't see how "compiled" versus "script" makes a difference. The are both independent pieces of code written to interact with an API to add functionality.
Extension, add-in, add-on, plug-in are all words describing the same thing.
Yeah, that's why I gave the definition above upthread. It's not compiled vs. script - it's whether it runs alongside the browser's own code, with the same OS access that the browser does, or whether it runs inside the browser, with a bit more access than web pages do.
By convention, "plug-in" means the former and "extension" means the latter. There is a big difference.
Yes, that's what I meant by "after-the-fact rationalization" and "it's mainly a historical artifact" and "they're not precisely mathematically defined categories of computer science." It's just a fuzzy descriptive convention, not a strict prescriptive category.
The terms are just historical accidents. There is no official definition that "plugin means compiled code" and "extension means interpreted code". There is no well defined dichotomy, and the boundaries are fuzzy, and there are many other synonymous terms like "add-in", "add-on", "library", "package", "module", "customization", "mod", "XP/COM Component", "ActiveX Component", "OLE Control", "COM Object", "Windows Scripting Component", "Dynamic HTML Component (HTC)", "Scriptlet", "Binary Behavior", "Browser Helper Object (BHO)" etc.
And technologies like Mozilla XP/COM and Microsoft ActiveX purposefully blur the compiled/interpreted dichotomy by letting you implement components as either compiled code or interpreted scripts.
The whole point of ActiveX/COM/OLE/ActiveScript/Windows Scripting Engine (and Mozilla XP/COM) is to hide the implementation language of components, and transparently enable components implemented in interpreted and compiled languages to interoperate seamlessly.
>OLE Scripting is Microsoft's mechanism for incorporating Visual Basic Script and scripts created in other interpreted programming languages, such as Java or JavaScript, within DocObjects. Get the details from http://www.microsoft.com/intdev/inttech/olescrpt.htm. This sounds quite interesting: a way to plug extension languages in as components, via the COM IScriptingEngine interface.
>First there were VBXs. Then there were OCXs. Then, Microsoft wanted us to call them OLE Custom Controls, but we persisted in calling them OCXs. So they must have figured that we wouldn't accept any control technology that didn't have a name ending in X. -Curt Hagenlocher
For example, here are pie menus implemented in compiled C++ as a binary ActiveX control, which can plug into the browser, but can also be used by any OLE container like Microsoft Word or an arbitrary MFC app, so they don't depend on the browser or JavaScript:
And here are pie menus implemented in text JavaScript+XML source code as a Dynamic HTML Behavior Control, which can only run in the browser, but can leverage browser technology like Dynamic HTML and CSS for rendering:
Both of those are COM Objects/OLE Components/ActiveX Controls, implemented in different languages, and dependent on the host implementing different interfaces. It doesn't make sense to classify one as a plug-in and one as an extension based on whether they're compiled or not, but the JavaScript one does have a lot of dependencies on the browser that hosts it, while the C++ one does not. But the HTC doesn't get its JavaScript interpreter directly from the browser, it gets it from the scripting engine interface, which exists independently from the browser, and it could as well have been written in Python or Visual Basic Script.
I really don't see how "compiled" versus "script" makes a difference. The are both independent pieces of code written to interact with an API to add functionality.
Extension, add-in, add-on, plug-in are all words describing the same thing.