My point is that code density is code density regardless of underlying CPU, programming language, and libraries - up to a constant (bounded above by size of an emulator and said libraries). That’s actually very rigorously defined for those who care - and has a lot of implication. The rabbit hole starts with “algorithmic complexity” also known as “Kolmogorov complexity”.
The constants matter. It may be harder to get an impressive dwitter style output from bare NES or C64, but there a 32, 64, 128 and 256 byte demo “micro scene” for c64 and DOS that pumps out very impressive stuff for the size - some that would even be impressive on dwitter.
Most NES code is tight (due to constraints). Most JS code is not (there are essentially no constraints) but that’s not inherent, as is shown with demos and proven by kolmogorov solomonoff and chaitin.
The constants matter. It may be harder to get an impressive dwitter style output from bare NES or C64, but there a 32, 64, 128 and 256 byte demo “micro scene” for c64 and DOS that pumps out very impressive stuff for the size - some that would even be impressive on dwitter.
Most NES code is tight (due to constraints). Most JS code is not (there are essentially no constraints) but that’s not inherent, as is shown with demos and proven by kolmogorov solomonoff and chaitin.