Most of what jQuery does could be moved into standard browser APIs and then presumably implemented in native code. I feel that implementing it that way would certainly be significantly faster, because any performance loss from impossibility of trace-directed optimizations is outweighted by significant reduction of amount of crossings between native and JS code with completely different memory model. The fact that VM/native transition is expensive is exactly the reason why things like WebAssembly cannot directly manipulate DOM.
But this could not be implemented by writing C++ class that gets exported to JS code as $ when something that looks like jquery is loaded. In JS you can load jQuery and then monkey patch it, which will break when you use this kind of "transparent" optimization.
Most of what jQuery does could be moved into standard browser APIs and then presumably implemented in native code.
It pretty much has been. CSS syntax for selection lead to querySelectorAll, simpler AJAX calls to fetch, DOM manipulation functions were ported into the DOM spec wholesale.
But this could not be implemented by writing C++ class that gets exported to JS code as $ when something that looks like jquery is loaded. In JS you can load jQuery and then monkey patch it, which will break when you use this kind of "transparent" optimization.