Inside Netflix’s Project Griffin: The History of Roku Under Reed Hastings (2013)
fastcompany.com
fastcompany.com
It really sounds like a story that was respun at the end such that the development team didn't realize they were jerked around on a chain the whole time and were just a negotiating strategy.
Clients on TVs? Not even the iphone had "apps" when this decision was made. I doubt they had considered TV "apps" at the time (if anything they were thinking of stbs).
Cool story. I didn't realize Roku was originally a Netflix project.
The "Roku Streaming Stick (3600)" is simply not available in the UK for some bizarre reason, I think it is because Roku has a deal with Sky, or some other TV vendor, to not sell it here.
And now that I have a US one, I am not able to use some local UK apps on it, but that is the price you have to pay apparently.
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).
Edit: To answer your original question, Mozilla had an open source engine, and I believe even had a version you could install as a stand alone JS interpreter, Rhino.
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/ 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."
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.
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