EnTerr
12 years agoRoku Guru
Can Roku compete?
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:
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.