3 ms·

> Now, imagine if they had just lifted one of open source the JS engines into the device. As someone who writes TV applications and Set-Top Box UI/UX code as m

> Now, imagine if they had just lifted one of open source the JS engines into the device. As someone who writes TV applications and Set-Top Box UI/UX code as my day job (and speaking only for myself and no one else), I actually vastly prefer Roku's approach here. If Roku had done what you suggest (use an open source JS engine), it would probably be a far worse experience for developers and users. As an example, I submit most "SmartTV" devices (anything pre-Tizen from Samsung, anything pre-WebOS from LG, most commercial/industrial STBs for hotels or signage, etc). These devices typically use some version of classic Presto-based Opera or Google Chromium (2012-ish forks). Devices with these codebases are still sold today, in new 2017 models. The problem with using a JS engine is that most developers (or their managers) will inevitably overload TVs with heavy JS clients, the same kind they send to $500+ laptops. They'll claim it's great for code reuse, or lower costs. And there may be some truth to that. But the experience somehow always goes bad. They'll re-implement bad versions of common controls that break all standard convention, and they'll port over a UI that sort-of runs ok-ish on a Desktop PC, but is slow as hell, frustrating, laggy to use. It's every complaint everyone has with Slack's "desktop app", except vastly more painful now the client isn't a super fast $1000 laptop, but a super slow (by comparison) $50 stick or box. The end result of this is people buying SmartTVs, ignoring almost all of the stuff on that Smart TV, and plugging in a Roku instead. This is totally a waste of hardware, but the SmartTV experience is usually so bad (despite having "better tooling/better languages/better support" than a Roku) that even regular non-technical people will often do this. 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. And a big portion of that is just not making it too tempting for developers to break the user's experience. Roku's restrictions aren't perfect or anything, but they are strong enough to prevent companies from taking their huge kludge of "support everything everywhere" shared codebases and making a Roku chew through it, which would be a detriment to all users. To target Roku, you write something small, lean, and reasonably fast, just for Roku devices to just meet the needs of your users on Roku. A philosophy I personally love. --- http://subfurther.com/blog/2014/02/06/a-roku-sdk-brain-dump/ http://subfurther.com/blog/2014/02/06/a-roku-sdk-brain-dump/ is dated now, but has a detailed writeup of that situation that I mostly agree with. Including : "Its may be hard for developers to have the right level of humility, but on (the Roku), you are not the star. (snip) The value of the Roku channel is whatever stream the viewer chooses to put on his or her screen. That’s why they have the Roku."

mrpippy 9y ago
This is probably why Apple doesn't expose WebKit as a public API on tvOS: regardless of how useful it would be, the danger is too great that you'll end up with garbage, lowest-common-denomiator web apps littering your platform. That said, I think the OP has a point that JS could have been used instead of BrightScript--no DOM, no possibility to re-use a generic or non-native UX design, just using the language. Given the timing though, it's hard to fault the choices made 10+ years ago.
kbenson 9y ago
> 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&hilit=performance#p283583 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 https://forums.roku.com/viewtopic.php?f=34&t=49609&p=338815

mrpippy 9y ago

This is probably why Apple doesn't expose WebKit as a public API on tvOS: regardless of how useful it would be, the danger is too great that you'll end up with garbage, lowest-common-denomiator web apps littering your platform. That said, I think the OP has a point that JS could have been used instead of BrightScript--no DOM, no possibility to re-use a generic or non-native UX design, just using the language. Given the timing though, it's hard to fault the choices made 10+ years ago.

kbenson 9y ago

> 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&hilit=performance#p283583 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 https://forums.roku.com/viewtopic.php?f=34&t=49609&p=338815