CPUs

Rokus are great devices, but when they are available at $30-$100 US dollars, they are not running 100 core CPUs enlisting additional processing help from 10,000 CUDA core GPU’s. These are $.50¢ CPU’s with limited processing power and memory bandwidth. Creating systems to make BrightScript more like what you are used to, JS, Angular, MVVM, OOP, or whatever, works and is a common approach, but when operations start getting nested in a dozen levels of hierarchy or indirection, and things like IoC, DI, bindings, and so on start coming into play the box has a noticeable performance hit, it just doesn’t have the beefiness we are used to and use on PC’s or gaming consoles.

I have seen systems where a few thousand lines of code lay on top of a framework that is many tens of thousands of lines. The compile time is slowed dramatically and depending on the quality, depth, and fit of the framework, performance can be noticeably degraded across the channel. Every line of code in a channel has a small initial compile cost, but every line executed has a definite CPU cost. Making life easier for a single programmer or small team has to be balanced against negatively impacting the user experience for many thousands (or even millions) of users. This isn’t to say or even imply frameworks are bad or inefficient in any way, just keep in mind the cost as compared to the benefit.

These concerns are more for frameworks that try to completely redefine BrightScript, not so much frameworks or libraries coded to work with and expand BrightScript. Again, they are not a bad thing to be avoided, but be aware of the potential performance cost.