Yes, I think you've captured the difference: An "extension" is written in an extension language like JavaScript, in a browser that's intended to be extended in that language. A "plugin" is a more independent piece of code written in a compiled language, plugged into a host that doesn't necessarily have its own extension language like JavaScript or Visual Basic.
But I think that may be largely an after-the-fact rationalization (like retronyming "YAML" from "Yet Another Markup Language" to "YAML Ain't Markup Language") and it's mainly a historical artifact that two different generations of browser extension technology have different names, because they're not precisely mathematically defined categories of computer science.
At the time that NSAPI came around, JavaScript wasn't really much of a thing, and DHTML didn't exist, so not many people would have seriously thought of actually writing practical browser extensions in it. JavaScript was first thought of more as a way to wire together plugins, not implement them. You were supposed to use Java for that. To that end, Netscape developed LiveConnect.
Microsoft eventually came out with "ActiveX Behavior Components" aka "Dynamic HTML (DHTML) Behaviors" aka "HTML Components (HTCs)" that enabled you to implement ActiveX controls with COM interfaces in all their glory and splendor, entirely in Visual Basic Script, JavsScript, or any other language supporting the "IScriptingEngine" plug-in interface, plus some XML. So you could plug in any scripting language engine, then write plug-ins in that language! (Easier said than done, though: it involved tons of OLE/COM plumbing and dynamic data type wrangling. But there were scripting engines for many popular scripting languages, like Python.)
https://en.wikipedia.org/wiki/HTML_Components
https://docs.microsoft.com/en-us/previous-versions//ms531018...
http://lua-users.org/lists/lua-l/2007-03/msg00047.html
LiveConnect:
https://techmonitor.ai/techonology/netscape_ships_liveconnec...
NETSCAPE SHIPS LIVECONNECT BETA. By CBR Staff Writer 30 May 1996.
>Netscape Communications Corp, Mountain View, California, this week released its LiveConnect SDK development kit in beta which enables live objects in Web pages – such as Java applets, JavaScript scripts and plug-ins – to communicate with each other. Netscape will deliver a pre-release version of Java user interface component and application programming interfaces acquired through its acquisition of Netcode Corp earlier this year. Netscape will release a beta version of its Java-enabled Navigator 3.0 client for Windows 3.1 in June.
http://medialab.di.unipi.it/web/doc/JavaScriptGuide/livecon....
Chapter 5. LiveConnect
LiveConnect enables communication between JavaScript and Java applets in a page and between JavaScript and plug-ins loaded on a page. This chapter explains how to use LiveConnect in Netscape Navigator. It assumes you are familiar with Java programming.
Use JavaScript to access Java variables, methods, classes, and packages directly.
Control Java applets or plug-ins with JavaScript.
Use Java code to access JavaScript methods and properties.
For reference material on the Netscape packages, see the JavaScript Reference.
For the HTML syntax required to add applets and plug-ins to your web page, see the Applet and Plugin objects in the JavaScript Reference.
For information on using LiveConnect with server-side JavaScript, see Writing Server-Side JavaScript Applications.
For additional information on using LiveConnect, see the JavaScript technical notes.
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.
https://docs.microsoft.com/en-us/archive/msdn-magazine/2001/...
http://www.delphigroups.info/2/b6/257655.html
https://donhopkins.com/home/interval/pluggers/activex.html
>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:
https://www.donhopkins.com/home/PieMenu/ActiveXPieMenus.html
https://www.donhopkins.com/home/PieMenu/ActiveXPieMenuSource...
https://www.youtube.com/watch?v=nnC8x9x3Xag&ab_channel=DonHo...
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:
https://www.donhopkins.com/home/PieMenu/JavaScriptPieMenus.h...
https://www.donhopkins.com/home/PieMenu/piemenu.htc
https://www.youtube.com/watch?v=R5k4gJK-aWw&ab_channel=DonHo...
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.