Roku has been erupting these past few years. Beginning as a lowly startup in 2002 and now boasting over 10 million users, Roku is the biggest player in the home media streaming device market, having sold 37% of all streaming devices last year. The next closest competitor is Chromecast at 19%. So even though this startup has been duking it out with goliaths like Apple and Google for the home media market, it's been doing so quite successfully.
In case you've never heard of Roku before, it's a small, inexpensive (usually < $100) box you can connect to your TV and stream videos from different channels, or apps. The job of a Roku developer is to program a channel which the user can open and stream videos to their TV through. So if one develops, say, a Youtube channel, he or she would be making an app through which users can search for and watch Youtube content on their Roku.
Upon starting to program, you'll rapidly realize that Roku, in fact, has no simulator to speak of -- any code you write and want to test must be uploaded to an actual Roku device and then run on the machine to do the debugging. If you've had a busy day at work and need to work on some at home, be prepared to take the device home with you and hook it up to a spare TV that you hopefully have lying around. Debugging is done through the use of placing "stop" commands through the code to set breakpoints, then creating a telnet session to your Roku device and stepping through with text commands in the terminal. It's painful if you're used to a GUI debugging interface, but it's definitely doable.
One of the more interesting things is that, instead of adopting an existing language in the way Android did with Java, the Roku team decided to do the counterintuitive and make the box run on its own proprietary scripting language - Brightscript.
Now, at first glance this sounds like the typical mistake all entrepreneurial engineers make when they create a product - rather than use something that's already out and proven to work, they re-invent the wheel because, well, that's what engineers love to do. Meanwhile, this has a tendency to cause all kinds of minor problems. And believe me, Brightscript has plenty of them. From forgetting about quirks when performing boolean operations to introducing a slew of other idiosyncrasies, making a brand new programming language is actually much more complex than it first seems.
But once we get past all the exasperated sighing and eye rolling and "ugh, typical"s we all feel at a company making yet another proprietary language, we can see there's actually a lot of sense to Roku doing this. For one, they don't have to worry about a new version of the language coming out and having to upgrade their libraries constantly to keep up. They have complete and utter control over how the language interacts with their software; they are beholden to positively nobody. Brightscript lives and dies at Roku's desire.
In terms of actually working with the language, one of Brightscript's greatest features is its size. This language is tiny. The entirety of the codebase only consists of about 90 class types or so. That means if you're a new Rokuist/ista, it's simple to learn the ropes and slap together some easy code that more or less works.
The most interesting thing is that Brightscript doesn't allow you to format the layout of your views (or screens) in your app. Yep, that's right. Roku allows you almost no control over where your screen elements go or how your UI looks. You choose one of the 10 or so templates Brightscript offers you and pass your information to it. From there, the program lays out everything according to its own ways whether you like it or not.
In a sense, there's something liberating about this. Writing an app becomes super simple as all you have to do is write something like:
poster = CreateObject(„roPosterScreen”)
contents = [
{
Title: „Show 1”
Description: „The hottest thing on TV”
}
{
Title: „Show 2”
Description: „The next hottest thing on TV”
}
]
poster.SetContentList(contents)
poster.Show() And you've got a decent looking page with two elements on it ready to go. All the styling will be done according to the "roPosterScreen" template's presets.
At the same time, this is one of the worst things about Roku. If you have clients who ask questions that start with "Is it possible for us to change that one little...?" -- get used to saying no. Get used to saying it a lot because one thing Roku does not much allow for is customizability. Usually about the only thing that Brightscript lets you change is the background color and some minor positioning of elements in the banner at the top of the screen. Other than that, you've got nothing.
Anything more custom than having your own background color requires you to build an interface using the "roImageCanvas" class wherein you have to specify every box, text object, and image's coordinate, width, and height. Then if you want to add any form of animation, you have to render everything manually. Needless to say, it requires painstaking effort to build your own custom interface and it is not really something you want to do unless you've got a lot of time to crank it out.
Despite this, the promising thing about Roku is that the streaming device industry has been booming lately. A Parks Associates study shows that the number of U.S. households owning a streaming device has increased by 63% since last year, from the 13% to 21%. The same report also predicts that companies will sell up to 86 million streaming devices in 2019. Seeing as how Roku owns a big share of that, there's a strong possibility that demand for Roku programmers will surge in the next two years or so.
Given how fast the streaming device market has been escalating, learning to program for one of them is becoming increasingly viable. If one can tolerate the platform's shortcomings, Roku's popularity makes learning it an obvious choice. It's still in its infancy, but Roku's already meteoric rise promises a lot for the future.
by Radu Murzea
by Delia Mircea
by Ovidiu Mățan
by Ovidiu Mățan
