Roku Developer Program

[EnTerr]

Warning, i see the same blog cross-posted to viewtopic.php?f=28&t=72512 , so general discussion of Roku futures should probably head there.

The article is refreshingly independent. Seems well researched, there were couple of links i have not seen before. Rare to see technically competent person write on Roku. Overall enjoyable. Below are my comments as developer:

• BrightScript as a language - i find the scripting language easy to grok, will put it in-between Lua and Python. It's a version of BASIC with heavy influences from Perl that resembles VBScript. Recently looked at Lua details, i did not expect it but B/S has made some wiser choices than Lua and i expect development in Lua to be more problematic because of that (and Lua is popular lightweight scripting language, games etc). Language is decent, most problems lie in components API.


• Re physical player required for development vs emulator: does not bother me. It is akin to Apple requiring newest versions of Mac OS for iOS development and not Windows nor Linux [can apple release SDK for other platforms if they wanted to, sure.]. If you want to develop for said platform, you can acquire the environment.


• Re about Roku not supporting HTML/Javascript cross-platform apps, i hear you: if i were developer that wrote for multiple HTML platforms already (which i am not), i will totally bitch about not being able to copy&paste my apps to Roku. One can argue requiring commitment to Roku pays in better user experience at the end. Worked for Apple (after the initial shivers from ObjectiveC, i found it quite bearable - and appreciate its conservative approach to memory management, ultimately apps require 2-3x less memory than JVM based ones).


• Regarding dev.support, this dev.forum is the best place and i find that satisfactory. Yes, you can ask on S/O (and i may reply if i know the answer) - but best bet is here. It's a small but dedicated developer base.


• Re Eclipse plugin, i consider its existence an abomination. I am not questioning there was demand for it - it is just that all it does is putting lipstick on a pig. The "no need for IDE" applies in lesser extent to other script languages, like say Python - but at least in plugins for them you can get integrated debugging (breakpoints, watch list, variables, stack etc). The B/S plugin however with puffs of makeup only complicates common and simple activities, which i argue should not be complicated lest they break - and that plugin is known for breaking with changes in Eclipse, Java or plain old trying to use it. What i want at the end is some lean ham, don't care whether pig wore mascara.


• Platform release notes are not up to snuff and not reliable source of what had changed (there is no reliable source). Ditto for documentation, it is not reliably kept updated. One has to regularly read the dev.forum and experiment with the API.

[skeptic]

From a user point of view, Roku is very good at what it does. Ignoring hardware differences, it's big downside vs. Android based competitors is it's lack of different types of apps. I know it sounds funny considering 1,500 channels, but once you stray outside of video streaming channels... I'm sure some of the games are fun, but compared to what's available for Android based streaming boxes, well, it isn't much of a comparison. Ton's of other apps available for Android making them directly installable on or easily ported to Android streaming devices such as Fire TV or the upcoming Android TV.

I think a lot of these software limitations directly agree with what is posted above.

[renojim]

I enjoyed reading your article. There are a couple of things I'd like to point out. Webkit is supported, but like use of the NDK, you have to be blessed by the powers that be to be able to use it. Hulu+ has used Webkit for quite a while now, and that's probably why there's been so many issues over the years with that channel. I believe Youtube and Netflix now also use it and there's probably others. However, Webkit channels seem to have their problems on anything other than the latest hardware. I also don't see Brightscript as holding Roku back. Any developer worth his salt should be able to pick it up in a weekend. There are far too many "programmers" these days that couldn't write a bubble sort algorithm if their lives depended on it. If Brightscript keeps them from developing for the Roku, I'm all for it.

-JT

[RokuJoel]

Hi,

As Enterr noted, requiring developers to develop specifically for the TV as opposed to just dumping exising mobile apps onto our platform creates a better user experience.

Only Hulu+ used webkit, and BBC UK used HTML5, I think... Hulu+ is now 100% Brightscript on non-legacy devices, and at least one newer BBC channel is as well.

The one or two exceptions to that are not using HTML5 but using their own custom compiled Javascript engines in an NDK app.

Yes, it would be nice if there were more Brightscript libraries available like there are for Javascript like jQuery etc.

- Joel

[EnTerr]

"siekermantechnology" wrote:
- Regarding Eclipse plugin: I did without it as well, and instead opted to put together a simple language module for TextWrangler to at least get some syntax highlighting.

Yeah, me too - i use TextWrangler and quite satisfied with the arrangement i got. Instead of new language, i just mutilated "Contents/Resources/VBScript Keywords.txt", plus a few tweaks like making contextual "Find in Reference" work. Being a Windows hack coming to OSX, initially was running build script in terminal window on the side and that did not bother me the slightest. But luckily had a fruitful PM conversation over the setup with a proper Mac OSX user which made me realize there is better way, to integrate build script in TextWrangler. I keep telling myself that "one of these days" i will gather my notes into a write-up on "lightweight development" for Roku on Mac.

[skeptic]

"RokuJoel" wrote:

As Enterr noted, requiring developers to develop specifically for the TV as opposed to just dumping exising mobile apps onto our platform creates a better user experience.

I have to partially disagree. In some cases this is certainly true, but on the other hand there are a lot of great mobile apps that naturally work well or are easily ported in a remote/tv friendly way to a TV device (ie FireTV) but will never be developed for a TV only platform (ie Roku).

[EnTerr]

"skeptic" wrote:
.... on the other hand there are a lot of great mobile apps that naturally work well or are easily ported in a remote/tv friendly way to a TV device (ie FireTV) but will never be developed for a TV only platform (ie Roku).

That did not seem to help much GoogleTV, android market did not save it from tanking - nor did having to write mobile apps anew for iOS prevent Apple AppStore becoming #1. Those are two elephants - one from TV space, one from apps, both in our room. No, i am not saying that the more bizarre a platform is, the more likely to succeed - rather i think it is the vision about an ultimate goal and the concern about the overall experience that is likely to bring successful product - the underlying implementation matters only as a means to an end. Google's vision was "we'll build a PC but based on android and link it to your TV". And so they did and that was of little use to the unwashed masses. Apple OTOH put their foot down in the interest of the end-user: no memory hogs like Flash or Java VMs, no long-running background processes to drain battery, no WiFi when sleeping, stronger privacy controls (no, dear app - you cannot haz my contacts nor send me notifications - now do your job) - which made developers' life harder but panned out in a coherent reliable platform and the apps came. I guess " life, uh, finds a way."

Here is something interesting - and releated - i saw recently:

"Chris Adamson@SubFurther" wrote:
Third-party Roku apps are written in BrightScript, a simple language that is based on Visual Basic. That’s going to freak a few people out, but I see the value of it to Roku:

• Why not a popular and standard language, like Ruby or JavaScript?
  Because then Roku might be obligated to keep up with the evolution of those languages, even if those developments are meant for domains (Rails, the DOM) that are irrelevant to Roku. Owning their own language is smart. That’s why Apple controls Objective-C, Microsoft has C#, and Google f’ing stole Java. (Be honest, they did, and you know it.) BrightScript can have exactly what Roku needs in it and nothing more.


• Why not a compiled language, like Java or some C derivative?
  Apparently, Roku’s special friends get that, but if you’re just writing a content browser that throws to a player, do you need the hassle, or even the performance?


• But dude, really, Visual freakin’ Basic?
  Do you know how many professional programmers started on VB? Not my cup of tea, either, but why not co-opt the talent that’s out there? Chances are, it was comfortable to the guys and girls implementing it on Roku too.