Of course it's apples-to-oranges, but surely we can make such non-serious comparisons in a thread about a metroidvania game written for a fun contest?
(I recommend browsing through the https://www.dwitter.net/top/year top section to get more example of "demos that fit in a twit".
Just think of the boilerplate needed to set up graphics when you can't simply output to a canvas tag. That's the point being made - JS is an interpreted language, so you can't really compare code size with compiled code.
It actually is comparable in my experience and opinion.
Setting up graphics modes on the SNES was much easier (hardware wise) than e.g. switching VGA (or even CGA) to graphics mode - one did have bios INT 10h to rely on for the PC, but “select and set up graphics mode, colors, etc” in practice was a comparable effort.
And many games implemented tiny virtual machines to simplify and compress code. As another example, ZX Spectrum basic rom (16k of z80 machine code and data) spent a few hundred bytes implementing a floating point stack VM interpreter that compressed relevant math code by approximately 1:5 compared to “native” calls.
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.
Impressive stuff indeed.
1: 6502-ish, it was a clone with the BCD instructions disabled.
*a JS function, utilizing dwitter-specific functions, called in some other dwitter-specific function, included in some specifically designed frame
Wouldn't be surprised if the total JS code required nears the submitted game.
Castlevania 1 is not a Metroidvania. Metroid 1 is though.