Super Mario Bros shipped in 40KB. A bare React app ships more before you write a line of your own. What did they know that we forgot?
Super Mario Bros shipped in 40KB. A bare React app ships more before you write a line of your own. What did they know that we forgot?
Stupidly easy answer: compatibility and visuals.
I recently did just that: I made a handheld physiotherapy game console base. The prototype ran on an Arduino Nano I had laying around. 32KB flash and 2KB RAM. That makes the 192kb ROM and 10kb RAM that Super Mario Bros has to work with look luxurous.
You fight for every bit on a platform like that but at the same time it’s also really easy to do so. With that little available resources you can optimize almost perfectly because there is so little code.
That doesn’t explain why a bare React app is larger than a finished Super Mario Bros. The answer is compatibility. SMB needs to run on exactly one platform with exactly one CPU, so it ships compiled.
React needs to run on a multitude of different browsers, so not only does it ship in source, but it also needs to ship hundreds of polyfils to work with different browsers. Not only that though, it needs to ship tons of features that any given app might need.
Which brings us to the next issue: content and visuals.
OOPs blog post formatted in ASCII contains 14.8kb in pure blog post text. At the level of performance these old games had, text was really expensive, which is why even RPGs of that time had very limited dialogue.
The NES had a resolution of 256x240px, or 637 kilopixel with less than 4bit color depth, which means a full screen image would take around 30kB (uncompressed). A full HD screen has 2 megapixel at 24-42bit color depth, so 6MB-10MB per full-screen image (uncompressed).
The 30kB would have been far to expensive on a NES, so in practice graphics were limited to a handful of small sprites moving over a background filled with repeating tiles. On the other hand it’s very common to have large, high-quality images on a website.
Sure, you can still make websites with the same graphics as a NES game, but then it also will look like a NES game.
And we aren’t even talking about animations, videos or anything like that at all.
TLDR: Yes, it’s still possible to program like on NES. The catch is quite plainly visible to anyone who has spent more than 3 minutes programming:
- It will look like a NES game
- It will take inordinate amounts of time to optimize
- It will run on exatly the one machine you build it for
OP’s point is… very uninformed.
The post using NES as a comparison is the main problem, in my opinion, especially given that Quake in 13k of javascript exists (only 3 levels, but still), which is a closer apples to apples comparison.
Besides, “needs to run on a multitude of browsers” is not hard unless you decide to make your javascript do absolutely everything, and even then it’s easy to keep it working on the major browsers, you just aim for the lowest common denominator (usually Safari). The browsers do the heavy lifting of running on a multitude of OSs and architectures.
I recently wrote a clock frontend for my NTP server and the whole page payload is less than the network MTU, so it should theoretically fit in one TCP packet.
That’s sexy. Thank you for your service (providing well developed software within constraints that haven’t been relevant for more than like 100 people in the last 30 years)
When I say that to younger developers, they nod politely and then ask what the catch is, because in their world nothing is ever just what it says. There isn’t a catch.
There’s absolutely a catch. You wrote that code for a single piece of hardware. You hand tuned it for that one specific platform taking advantage of every trick you could find. It probably took longer to write than your website and it didn’t really matter if it wasn’t perfect.
You can’t buy a system that slow or that memory constrained anymore (spare me your weird embedded processors, you know what I mean). Move on.
The other catch is something OOP mentions right at the beginning: The main reason their app was 2MB large was because it had images.
You couldn’t do full-frame images on a SNES. Instead, images were built up by pasting small sprites and repeating background tiles everywhere.
If you want high-res images with a colordepth of more than 13 colors per pixel, you will need a lot of storage space for that.
I put my personal site through the "fire"fox page profiler. Get rektum.
Technical breakdown
Frontpage :
Empty cache Number of requests Type Size Transferred Time Non blocking time 2 images 10.71 kB 2.52 kB 0.54s 0.54 s 1 css 3.82 kB 1.24 kB 0.24 s 0.24 s 1 html 2.08 kB 2.40 kB 1.81 s 0.76 s Cached responses: 0 Total requests: 4 Size: 16.60 kB Transferred Size: 6.15 kB Time: 2.58 seconds Non blocking time: 1.53 secondsPage with images
Empty cache Number of requests Type Size Transferred Time Non blocking time 4 images 79.16 kB 71.65 kB 2.01 s 2.01 s 1 css 3.82 kB 1.24 kB 0.28 s 0.28 s 1 html 1.38 kB 1.70 kB 0.75 s 0.75 s Cached responses: 0 Total requests: 6 Size: 84.36 kB Transferred Size: 74.59 kB Time: 3.04 seconds Non blocking time: 3.04 secondsJS application demo
Empty cache Number of requests Type Size Transferred Time Non blocking time 6 js 43.65 kB 10.48 kB 1.58 s 1.59 s 1 css 3.83 kB 1.06 kB 0.30 s 0.30 s 2 images 0.51 kB 1.03 kB 0.50 s 0.50 s 1 html 0.39 kB 0.71 kB 0.73 s 0.73 s Cached responses: 0 Total requests: 10 Size: 48.38 kB Transferred Size: 13.28 kB Time: 3.12 seconds Non blocking time: 3.12 secondsLol. I’m not writing compiled C code for a Ricoh 5A22. What a silly comparison.
We now have more capable hardware and there are different needs and constraints for web-development.
