Comment by georgefrowny

Comment by georgefrowny 9 hours ago

11 replies

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).

austin-cheney 5 hours ago

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.

  • viraptor 3 hours ago

    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.

  • moring 4 hours ago

    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.

    • austin-cheney 2 hours ago

      > 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.

    • seszett 2 hours ago

      > 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.

  • bayindirh 4 hours ago

    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.

    • austin-cheney 4 hours ago

      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.

      • bayindirh 4 hours ago

        > All that really matters is solving for developer anxiety.

        This is a new and interesting insight to me. Can you please elaborate it a bit further, if you wish?

        • austin-cheney 4 hours ago

          Imagine if you were an Uber driver and that is your full time job. Imagine it pays more than double the national average income. Also imagine you cannot navigate without a digital map and cannot work the car without AI assistance. If someone suggests taking the AI and the digital map away to increase road safety and driver performance you would likely lose your job for failure to perform. The very first thing you would do, as that driver, would make excuses and attack everything that threatens your career identity.

marcusjt 2 hours ago

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!

mlrtime 5 hours ago

Rokus are ad selling devices, I wish someone would just hack them [devices] already so we can strip it out.