Additionally, the code that JavaScript JITs generate is not position independent, and it contains no linkage information (symbol tables, etc.). It contains raw addresses of various browser objects within it. You would need to introduce some sort of linker for that to work, which is a lot of complexity.
The point of the article is that v8's optimizations work by watching the code execute. It can inline functions because it saw where they got called from; it can turn property accesses into fixed-offset lookups because it saw what object the accesses happened to, and so on.
(Unless you're talking about asm.js-style optimizations, but then the answer is presumably to use asm.js...)
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.
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.
The person you are replying to's point is that they aren't the same paths, when you take into account the other code and data in the rest of the application, which effects how the code even in the shared libraries is compiled.
I don't know, I am outside of my area of confidence here. But in a world where the technological advances in computing have less to do with increasing computing capacity than reducing power consumption, whether on mobile, laptops or servers, the jquery library that needs recompiling on every execution feels like the non-recyclable plastic bag of computing.
Nah it's more complicated than that in reality (I work on dynamic languages and have a PhD in them). You just want to select based on an ID, but in order to make that operator fast, JavaScript would normally pass information about what you want to select, what possible values it could have, whether it's allocated on the heap or you somehow stored it somewhere else, and a whole host of other things.
You could say 'well don't do those optimisations then' but then you just have slow unoptimised code and the point was to make this fast.
https://hillbrad.github.io/sri-addressable-caching/sri-addre...
[edited, with thanks to delinka]
Though I've been trending away from using most libraries separately and bundling... may need to think about breaking things out again. For the most part, however, most of my bundle sizes are pretty small. React in dev, Preact for prod is the biggest mix... checking bundle size before/after adding a module (some will add a huge dependency tree).
There's no substitution for being judicious... and imho, even if you have to look it up frequently, using the DOM is usually better than loading in jQuery... even if you center around Array.from(document.querySelectorAll('...')) as your main usage.
And how exactly is your jquery.wasm going to access the DOM? Or expose methods to your application, for that matter?
wasm is not a drop-in replacement for JS.
I just wondered though, from a birds eye view, does using wasm effectively give you control of everything within the "frame" of your browser?
Can I get rid of the DOM(boilerplate aside), get rid of CSS?
For example HTMLCanvasElement is a flat surface. I can do what I want within it as a scene graph renderer.
Could I do that with wasm? Could I invent my own 2D entities (x, y, width, height). My own 2D Constraints resize like Apple Devices etc?
It is not a "drop-in" replacement in any way, but I'm pretty sure it will eventually replace JS completely.
In other spaces the pendulum is swinging away from shared libraries since storage space and bandwidth are relatively cheap.
Java is often distributed as "fatjars" these days. IOS and Android apps bundle their dependencies the same way as far as I know. The whole serverless movement is a move away from shared code for better or worse.