>>>Okay, here's a comparable thing. Same code running over the years: my solitaire game. Apart from some minor cosmetic issues, the code is mostly the same as it was in 2003. Shortened it by a third when adding jQuery in 2008, which actually made it slower, but looked better.
>>>
>>>And guess what, it's now blazingly fast. I can't even notice when it reshuffled the cards and laid them down again. And back then I could just about see when that happened, or when it had to do a double loop to check whether the game was over after the last move. Even on my clumsy Pine64 phone...
>
>That's partly due to faster hardware, but mainly in improvements to JavaScript performance. When Google developed its V8 JS engine it improved JS performance by a lot - this source claims 10x: https://dri.es/a-history-of-javascript-across-the-stack . That forced all browsers to up their games.
>
>That's similar to the performance gain going from dBASE III+ to FoxBASE - about 6x if memory serves.

That came from Dragan ;-)

But yes, execution engine of Javascript (and Julia IIRC) and Hotspot made great strides.
Vfp stayed on a fast, but always interpreted p-code, but has fast runtime and reasonable C-interface.
Although the free wheeling monkey patch code from early Javascript or Python is an anathema to V8: even things like vfp addoject in the middle of code already optimized will start new dynamic compile efforts, which take time like early garbage collection.

Python was touted to get huge boosts - but they fizzled out, now they are tweaking the runtime again. I always thought the Cython angle of declaring base types for local variables and parameters to offer good value at reasonable code tweaking and hoped for automatic type identification (or better: type hinting) like the var in C# to get code stretches boosted, but that angle seems to turn Pythonistas off.

And WASM subset seems rather limited in the offered types to run - it maps everything via typed arrays but throws away those types with high speed benefit.