> The problem with using a JS engine is that most developers (or their managers) will inevitably overload TVs with heavy JS clients
This happened anyway. Hulu, with help from Roku released a channel that did not use the built in components, and on original Roku devices had horrible usability. Second plus delays before key presses registered, fuzzy and almost unreadable fonts when it downscaled to SD TVs, and it would crash often. All it meant is that you had to have some weight to throw around. Roku enforced size, color and usability guidelines. They could just as easily have put in some language about specific usability with regards to lag. They controlled the store, so it's easy for them to enforce, and you could always note which Roku models your channel was available for, so older ones that were too slow or didn't have certain hardware capabilities could be excluded.
> Roku's job is not to be a computer connected to a monitor -- there are plenty of other devices that do that. Roku's job is to make sure internet video "always just works" as much as possible.
Except that Roku actively courted alternative applications, including games. In the end, their solution to games was to announce that you could design your game for Unity, and they would work with you to get it ported. In the meantime, they had an enthusiastic developer community that was embracing the platform, even as it restricted them in multiple ways.
Let me put this in perspective. We wrote a testing framework to test different language operations, such as addition, division, multiplication for integers and floats, array and associative array creation, etc. Adding ints took a microsecond, adding doubles took 50+ microseconds, and some function calls with lots of params might take as much as half a millisecond.[1] Given that later they provided a bitmap type interface specifically for game and other development, where you could register sprites and flip buffers, that's woefully inadequate for doing any real amount of work between frames if you're trying to achieve any decent framerate. This on a 400 MHz Processor with 256 MB of RAM.
For another example, before they finally added a JSON parsing component (quite late, actually), different people rolled their own.[2] A 100k JSON string took well over 10 seconds to parse. An actual tokenizing parser took over 200 seconds. Again, consider the specs.
If Roku actually didn't want to push it towards non-video and non-audio markets, they could have done that. Instead what we got was encouragement but not enough resources available on their end to provide the tools we needed in an adequate time frame. That's why I think JS could have helped. A lot of optimization and resource development could have been supplied for free.
1: https://forums.roku.com/viewtopic.php?f=34&t=41645&p=283583&... - I can provide a legend for this, but the accum_ and sum_ tests are the ones I'm referring to.
2: https://forums.roku.com/viewtopic.php?f=34&t=49609&p=338815