Inside Netflix’s Project Griffin: The History of Roku Under Reed Hastings (2013)
1–10 of 14 posts
Re: Inside Netflix’s Project Griffin: The History of Roku Under Reed Hastings (2013)
#2It seems like this ending was totally predictable at the outset of the project. To me, it sounds like this project was a total hedge against the case that the TV manufacturers didn't play ball and let them ship a Netflix client.
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.
Re: Inside Netflix’s Project Griffin: The History of Roku Under Reed Hastings (2013)
#3[deleted]
Re: Inside Netflix’s Project Griffin: The History of Roku Under Reed Hastings (2013)
#4Title should say 2013.
Cool story. I didn't realize Roku was originally a Netflix project.
Re: Inside Netflix’s Project Griffin: The History of Roku Under Reed Hastings (2013)
#5Title should say 2013. Cool story. I didn't realize Roku was originally a Netflix project.
Thanks! We've updated the headline.
Re: Inside Netflix’s Project Griffin: The History of Roku Under Reed Hastings (2013)
#6Interesting story, I own a Roku but I had to import one from the US in order to get the latest model.
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.
Re: Inside Netflix’s Project Griffin: The History of Roku Under Reed Hastings (2013)
#7I 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).
Re: Inside Netflix’s Project Griffin: The History of Roku Under Reed Hastings (2013)
#8It seems like this ending was totally predictable at the outset of the project. To me, it sounds like this project was a total hedge against the case that the TV manufacturers didn't play ball and let them ship a Netflix client. 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.
Hindsight is 20/20. It may see predictable now, but this all took place 10 years ago. It was a much different market.
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).
Re: Inside Netflix’s Project Griffin: The History of Roku Under Reed Hastings (2013)
#9I 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 real…
What open source JS Engines existed at the time Roku launched in 2002?
Re: Inside Netflix’s Project Griffin: The History of Roku Under Reed Hastings (2013)
#10I 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 real…
> 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/ 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."