The Roku is not a general computer. It has no keyboard and no persistent storage.
There is an on-screen keyboard, but none of the examples use it, and so far I haven't seen an app use it either. The spirit of the Roku is that apps give users a screenful of things to choose from, and users choose. Equally, it has support for USB, but read-only so apps can see what's on a USB stick, but never, ever store anything. Very secure: A user can stream, but cannot store and therefore cannot copy. DRM taken to its logical conclusion.
Apps start from scratch every time. Stop and restart and app, and the app has lost all state. The only way to cache state is to use the device registry, which is limited to 16k and vaguely discouraged.
I like it, it has a certain honesty and simplicity.
There seems to be no way to cache web resources, so an app had better be able to start up without needing any web resources, or else it will start up very slowly.
The same applies later: If a web resource is slow, the UI blocks. I managed to avoid strict blocking using asyncGetToString() and asyncPostFromString(), but the result is still not quite good. Even though he UI reacts at once, the reaction is usually to present the outline of a screen at once and only fill it in a little later.
The key to achieving even this was to use the same roMessagePort for all screens and all roUrlTransfers, and write a function to process all roUrlEvents and perform callbacks to update whatever needs to be visited. I had to write three lines of boilerplate near every call to wait(), but the rest was quite pleasant. I got some HTTP caching for free too, so selecting the same item a second time works instantly.
There's a brightscript emacs mode floating around the web; I hacked a bit on it and someday maybe I'll post my version to github.
Mark Roddy, who I now see may be the original author of brightscript-mode.el, has written a test framework.
I cannot count the number of times I've expected
a=b; to work.
My fingers type semicolons on their own.