Unlike the edittime, the runtime runs in a browser. This means you have access to all browser technologies, ranging from WebSockets and AJAX to the Web Audio API. Exciting stuff!
It is preferable to access jQuery via the full name (jQuery.foo()) rather than the short name ($.foo()) in order to maintain compatibility with other scripts that may be running in the page. For examples of using jQuery, the Mouse and Keyboard plugins use jQuery to detect input events.
You can find out more about jQuery at http://jquery.org/.
Google Closure Compiler compatibility
When exporting, Construct 2 gives the user the option to 'Minify script'. This runs the common and runtime scripts through Google Closure Compiler's ADVANCED_OPTIMIZATIONS mode. This imposes some limitations on what scripts can do. You must obey these limitations when writing your plugins, otherwise your plugin will be broken on export. More details can be found on the Closure Compiler website.
The main thing is to always use dot syntax (Object.property) rather than bracket syntax (Object["property"]) in your own code. All properties using dot syntax are changed by Closure Compiler, but none of the properties in bracket syntax are changed. Therefore, if you use Object.property in one place and Object["property"] in another to access the same property, the plugin will be broken on export. You may still use bracket syntax (e.g. for a dictionary of user-inputted strings) - just be aware of how Closure Compiler will transform the code.
If you refer to external libraries, you must always use bracket syntax (i.e. Object["property"]). If you use dot syntax, Closure Compiler will rename the property and it will access the wrong property of the external library after export.
Remember the edittime scripts are not passed through Google Closure Compiler, so you can write them how you like.
The Document Object Model (DOM)
1. Construct 2's exported projects are intended to be totally self-contained. Ideally the canvas is the only page element affected by the script.
2. Any DOM elements you change may not be present on some pages, or may be present but intended for a different purpose on other pages. Therefore modifying DOM elements can break compatibility with some pages.
3. Non-browser platforms like CocoonJS do not have a DOM, so your plugin will most likely not work on these platforms.
With careful consideration to the above three points, you could still try experimenting with DOM features in plugins.