Comment by georgefrowny
2 days ago
Turn on TV: 3 seconds
Roku boots: 10 seconds
Meanwhile turn on soundbar: 3 seconds
Press Roku remote button: 3 seconds until it wakes up and repairs (remote still eats batteries)
Open streaming app: 5-10 seconds
Select profile: 3 seconds
Scroll about looking for show: 5-20 seconds, or a minute to type it in
Select the right episode: 3-10 seconds depending on if it's currently on the right season (somehow not always)
Start and buffering: 5-10 seconds
Ad: 20-40 seconds (depending on platform)
And that's all if you're concentrating on getting through it and the device isn't a laggy UI toxic waste dump. Some TVs you have to press each button and wait for each one to register.
At least there isn't an FBI copyright warning at the start I suppose (when you don't live in the US).
Everybody complains about performance. Slow software feels like poison.
Except, anything written with a large JavaScript framework is allowed to be slow. In fact slow as syrup is strongly encouraged. To prove it just ask the developers. Mention it could be 8-50x faster just by not using their favorite framework and note the response. Even better, show them a proof of concept and take note of their unemotional objectivity.
This has nothing to do with the frameworks though. Almost every listed step of delay there is due to specific software design choices, not JS level stuff. For example search - why isn't every possible next letter prefetched before you even select it? It's trivially cacheable at local nodes anyway. Why isn't the first few seconds buffered by the time you open movie description? How is the UI even possible to be laggy - there are way larger services using react without issues.
Non-constructive reply: Developers have been burned too many times by snake oil vendors and "solutions" that only work for toy examples. Also, I've never seen being slow to be encouraged anywhere. Most consider it an acceptable tradeoff though.
Constructive reply: What would be an approach to writing a large web frontend (large as in, many pages and controls) without using a large framework?
I'm asking this because I know how to do it in React but also how to do it "the old jQuery way" (or equivalently, using today's standardized builtins). Productivity is easily 100x larger with React.
edit: Ideally, together with a link to an example open-source application that does it that way, to understand how it works and feels at (code) scale.
> without using a large framework?
I have explained this countless times. It rarely sinks in and quite often is met with hostility, so I don't bother any more. The problem is simple: its where people stake their career. Do they build their career upon writing original applications or upon using a tool? This difference is rather extreme.
By the way, without React shouldn't default to jQuery. If that is your perspective of reality you are already at the maxim of your potential.
1 reply →
> link to an example open-source application that does it that way
My experience is with this: https://github.com/Dolibarr/dolibarr (what I currently work on is quite similar, but it's not open source).
It works fine. Clients don't complain about the interface. The project has been going on for 20 years or so now, and doesn't need big refactors every time a dependency gets updated because it avoids dependencies.
1 reply →
In short, user experience and efficiency is sacrificed everywhere for development velocity, time to market and monies.
This is embodiment of worse (for the customer) is better (for the business) adage.
That is a rather generous comment. As a former JavaScript developer I can tell you the qualities of concern are not the business concerns of delivery. Delivery will increase just as dramatically by reducing the tech debt imposed from unnecessary code. All that really matters is solving for developer anxiety.
2 replies →
> anything written with a large JavaScript framework is allowed to be slow
also word, excel, ...
(which might actually be a large javascript framework on azure nowadays)
Your Roku had to "boot" for 10s - why? Would resume from standby in a couple of seconds, so you've chosen to slow yourself down.
My TCL TV runs Android/Google TV, wakes from standby in 2s while also waking the surround in ~3s via HDMI CEC (and I don't need to hear anything until I've chosen something to play) so really it only take me 2s before I can start to open a streaming app (via a button on my remote) vs your 16s to get to the same point.
It's the choosing what to play that's the slow bit for me - every app puts what you were last watching in a different place, and not all apps notify Google TV so its own attempt at letting you resume is incomplete...
It also frustrates me that profiles streaming apps don't link to profiles for the OS (e.g. Google TV) - seems obvious to me that by now they should all be seamlessly linked together in a way that delivers the most personalised experience, instead of muddling up everyone's profiles and watch history!
Rokus are ad selling devices, I wish someone would just hack them [devices] already so we can strip it out.