also a brightscript/roku dev here. There's a nice code color plugin for sublime you can use and it's a bearable platform to develop on. Definitely use the console to just send the debug build up to the device and start debugging. It's really not that bad. Probably took me about a day to get used to it.
Honestly, as long as you stick within their control schemes you're fine. Trying to break out of the roku app controls leads to a total nightmare so be weary of that trap ;)
I don't know how it is on the newer versions, but BrightScript was always very, very slow. Much slower than you would expect. Most of the time it never matters, since you are calling out to compiled object code that exports APIs for complex tasks, but when it matters, it matters. For example, implementing CRC32 (no built-in shift operators!), or minmax for game AI (for Reversi of all things, it's not like there's that many possible moves) always required heavy optimization to achieve performance that was near acceptable.
It always boggled my mind why they didn't just take a JS implementation and port it, but I guess it's hard to justify throwing away IP which already exists because of a prior product.
The engineers at Roku and the community were always great though.
There's a certain point of "good engineer's" career where they want to make their own language/vm. I'm 99% sure this is what happened here. It's always a train wreck.
They really should have used lua. It would have been very simple to put in and it's robust enough and efficient for small memory devices.
While I appreciate the power/flexibility/efficiency of js it is no where near as efficient as lua. Lua keeps things as ints until they aren't needed etc. Very much build for embedded systems almost. I'm probably biased in that I've worked on a lua VM for mobile handsets for a few years.
Honestly, as long as you stick within their control schemes you're fine. Trying to break out of the roku app controls leads to a total nightmare so be weary of that trap ;)