I remember the Roku platform fondly, even if it had some design flaws that left it hamstrung. The biggest of those was the use of a proprietary language for app development called BrightScript. A sort of bastardized VBScript (from what I'm told, as I don't actually know VBScript, but it looks similar), all complex objects that required performance were "components" that you created with a special function, which really just provided a FFI to a system library through an in language object. For example, the video player, or cURL, or different predefined display screen types. The biggest downside to this approach is that the language was slow, and on a fairly low powered device to begin with, that made some things just too slow to be worthwhile.

As an example of this, a friend and I released a program called KidPaint, which was a simple paint/stamp program modeled after Tux Paint. Because the channel/app had to small (~$500k), there was very limited space to ship PNg files for stamps, and drawing shapes manually was actually a multi-second process in many cases. The way we found to get around this was to ship PNG shapes that were black with transparent backs, but with the black color defined in the palette block of the PNG. We would copy the PNG in memory, overwrite the color from the palette section with the desired color, write it to ramdisk, and use the screen component to place a PNG on the screen at the right location and with the right rotation. This process, including recomputing the CRC (and without shift operators, there was no bitshifts available), was much quicker than trying to implement deflate in brightscript, since it didn't come with compression components we could load (which would have been implemented as a library). It was hacky, it wasn't quick, but it was right at the edge of usability, so it's what we had to work with.

Now, imagine if they had just lifted one of open source the JS engines into the device. They could still have extended it for loading components if they wanted (browsers do stuff like that too), but they could have leverages the thousands of man-hours put into optimizing those engines, plus the many, many different JS modules out there to help build the ecosystem. Instead, we ended up writing our own serialization library, our own JSON parser/emitter, our own TAP testing protocol, a MOP to make complex object creation and management easier, some functional programming helpers, etc. We ended up open sourcing KidPaint and the libraries we wrote under https://github.com/rokudev originally, but Roku eventually asked nicely for that name since it would be beneficial for them, and we acquiesced. I think the original stuff is available now under https://libraries.io/github/rokudev/librokudev (maybe? I'm not actually seeing how to access it, and it would be a shame if it was gone).