As in the memory or the final binary size? I would have thought memory management was the tricky part -- even with the mandatory 8 MB expansion in the GBA slot -- but I suppose they would have been under even more pressure to fit it onto the smallest cart possible, with the cost of the expansion pack added for every unit
The Opera code was very memory efficient after having gone through so many memory usage optimizations triggered by lots of mobile platform ports.
It was a really long time ago, sorry :)
The Wikipedia page [1] claims* they had an MMU on the expansion cart - so they could have taken your advice :)
* I couldn't find a source, and AFAICT the DeSmuME emulator [2] seems to treat it like a big chunk of linear memory?
[1] https://en.wikipedia.org/wiki/Nintendo_DS_Browser#Memory_Exp... [2] https://github.com/TASEmulators/desmume/blob/master/desmume/...
E: I forgot about the mobile Opera ports, that also tracks - I'd love to read about the engineering that went into them!
Can't really meaningfully expand on that, most of that happened before I joined in 2004, but I can tell you that the fact that Opera was extremely memory efficient made Opera Mini (250M monthly uniques, 150k web page transcodes/s) economically possible starting 2005.
We needed to keep the browser/window state around for each user until they clicked the next link. If we threw it out, any javascript state would be lost.
Reading about Mini doing layout specifically for devices with <128px wide displays, I wonder how well today's responsive design frameworks would deal with that...