Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Crafting a high-performance TV user interface using React

techblog.netflix.com

Post reply on HN
Print view View original

61–70 of 198 posts

Re: Crafting a high-performance TV user interface using React

#61

Post by grayrest »

jeremiep wrote: post #25
rtsao wrote: post #2

For folks who really care about performance, the easiest win is just switching to Inferno or Preact. You can pretty much leave your React code unmodified and get massive performance gains.

Easiest win for me was trying out re-frame[1]. Not only do you get the best performance out of react, to the point where the actual virtual-dom implementation doesn't matter, but you also gain productivity and since it forces you to build apps made out of 95% pure functions and immutable data, reasoning even at scale is still incredibly easier than anything else I've ever tried to build GUIs with. [1]: https://github…

I've maintained a ~20k LoC re-frame app for a year and a half. The performance of Clojure's persistent datastructures with pervasive sCU gives you generally good performance but it's not panacea. I've debugged a hundreds-of-milliseconds freeze on laptops from a poorly written hierarchical menu and I get pauses of 70-100ms if enough data comes in on our main view.

Using it with cljs-time and storing times in the app state is a really easy way to shoot yourself in the foot perf-wise since that's based on closure's date object and two equal date objects are not identical. This fails the fast identity check but will pass the structural equality check so no vdom gets generated but the check is not that much cheaper than a diff.

This is also a B2B app where we have no demand for mobile use so I haven't had to do load time or mobile perf optimization. If I did, the first thing I'd be concerned about is the bundle size since the cljs runtime plus React represents a fairly sizeable amount of overhead.

Not to say that reagent+re-frame is bad, it's just not so amazing you don't have to care about perf. I think Reagent would run particularly well on top of Inferno since the library provides lifecycle events to function components and I did experiments back in April and June on Inferno with persistent datastructures to good results. I just don't want to maintain it.

Re: Crafting a high-performance TV user interface using React

#62

Post by ashmud »

1_2__3 wrote: post #43
makecheck wrote: post #26

Interface performance is one of the strangest problems to have in this age of crazy processing power but it is extremely common. Some of the delay is just plain silly and avoidable, like having long and synchronous opening animations in response to an action, which only serve to waste the user’s time. (Oh how I love being on a web site like AT&T and watching their JavaScript poorly zoom open a blank box from the cent…

Companies don't make money off of performance.

They can. I bought a Roku 3 after seeing how much more responsive it was compared to my Sony BDP-S790 for streaming apps.

Re: Crafting a high-performance TV user interface using React

#63

Post by allover »

jeremiep wrote: post #25
rtsao wrote: post #2

For folks who really care about performance, the easiest win is just switching to Inferno or Preact. You can pretty much leave your React code unmodified and get massive performance gains.

Easiest win for me was trying out re-frame[1]. Not only do you get the best performance out of react, to the point where the actual virtual-dom implementation doesn't matter, but you also gain productivity and since it forces you to build apps made out of 95% pure functions and immutable data, reasoning even at scale is still incredibly easier than anything else I've ever tried to build GUIs with. [1]: https://github…

re-frame might be technically interesting, but you're switching to writing in a lisp, which is a very niche choice. That's not going to be an overall win for many people.

Re: Crafting a high-performance TV user interface using React

#64

Post by andrewstuart2 »

makecheck wrote: post #26

Interface performance is one of the strangest problems to have in this age of crazy processing power but it is extremely common. Some of the delay is just plain silly and avoidable, like having long and synchronous opening animations in response to an action, which only serve to waste the user’s time. (Oh how I love being on a web site like AT&T and watching their JavaScript poorly zoom open a blank box from the cent…

As far as the less-clear cases, this is basically CAP theorem, with some physics thrown in for good measure. In some sense there is always a partition of some length between two points, thanks to the speed of light: the theoretical limit of information propagation through space.

So in the presence of this delay "partition," you have three choices, really, and the choice you make depends on the application.

A) You can choose to be available and responsive. Show the user feedback immediately and never concern yourself with global state. Technically, I'd call this an illegal choice because you must have some sort of state to even be executing code. Unless you simply don't write the code, in which case your job is easy!

B) You can choose to be immediately available and eventually consistent. You calculate the response quickly with the assumptions you have most available (local memory, disk), all while transmitting events and waiting for the further-away less-available state to become available.

This is the way many online games that need quick feedback to be fun are done. [1] Unfortunately, this is also the source of the lag jumps that you see. You're always running with [partition-size in ms] outdated global state, so the assumptions you made when calculating outcomes are going to be incorrect. This is why your headshot might turn into a total miss when the player jumps five feet to his right and, oh yeah, you also died.

3) Don't react to events until the global state has been updated. This means a full round-trip plus processing remotely and locally before that click event performs the action it is supposed to. This can be anything from a crappy experience (I shot into the ground, why should I wait), all the way to the only sensible choice (if integrity is highly important, say in transactions and avoiding double-spend).

Really, it's so much more than this too. On top of availability vs consistency you have to account for some trust model (the game client says it was a headshot, but how do I know I can trust the client) and information security (confidentiality, availability, integrity).

So TL;DR there are lots of very hard problems in distributed systems and sometimes people just default to one stance or the other to balance their cognitive load or for any number of reasons (ranging from legit to ridiculous). Sometimes they default to consistency. That's probably the case for your button-click example.

[1] https://developer.valvesoftware.com/wiki/Source_Multiplayer_...

Re: Crafting a high-performance TV user interface using React

#65

Post by chris72205 »

goostavos wrote: post #55
Domenic_S wrote: post #53

Earlier quoted context omitted.

That's just patently false. One of many, many articles to the contrary: http://blog.gigaspaces.com/amazon-found-every-100ms-of-laten...

Uh.. they've already _bought_ the car. What percentage of people will return a car due to a little lag when adjusting radio stations? e-commerce findings from a major retailer are, alas, not applicable to every domain

Someone may choose to not buy a car after test driving it and experiencing the laggy touchscreen...or after reading reviews by people who did already buy the car.

Re: Crafting a high-performance TV user interface using React

#66

Post by droopyEyelids »

91bananas wrote: post #49
usaphp wrote: post #34

Earlier quoted context omitted.

Especially the lag that you see on some brand new cars, only BMW and Audi seem to have lag free interface, but anything else that involves touch interface is just horrid! I've recently sat in my friend's brand new Honda SUV and the interface lag is just plain silly, for a car that costs $30,000+. Why is that?

Because Honda at its core is not a software company?

Most manufacturers are only responsible for powertrain components, contracting and assembly.

They're not experts in much, but contracting for quality parts IS something they're supposed to be experts in.

Re: Crafting a high-performance TV user interface using React

#67

Post by untog »

dlbucci wrote: post #4
stuckagain wrote: post #3

I hope someone from amazon is reading this. Their new app on the roku is unbelievably slow, 5+ seconds for transitions.

I don't think Roku apps are written in JavaScript/HTML. I believe they use BrightScript (at least on the older models), so I don't think React would help.

It is possible to work directly with C++ though, which I think Netflix must be doing with their Gibbon framework because their interface is very different from those obviously using the Roku tools (and looks exactly like their interface everywhere else). As the article states, Netflix aren't necessarily working with HTML when they make these React views - it sounds very much like how React Native works.

Re: Crafting a high-performance TV user interface using React

#68

Post by allover »

sergiotapia wrote: post #58
Akujin wrote: post #7

What's with everyone's obsession with React recently? All I see is a template engine and not a particularly good one. You're still left with the same problem mixing your HTML into JavaScript.

You don't have to use JSX if you're a purist - but why? JSX is just an easier way to write React components.

Yep I wish Elm people would wake up to this too

https://github.com/elm-guides/elm-for-js/issues/5

https://news.ycombinator.com/item?id=9860693

(EDIT: Help - how do you post 2 links on adjacent lines without HN breaking the formatting and sticking them on the same line?)

Re: Crafting a high-performance TV user interface using React

#69

Post by teddyc »

goostavos wrote: post #55
Domenic_S wrote: post #53

Earlier quoted context omitted.

That's just patently false. One of many, many articles to the contrary: http://blog.gigaspaces.com/amazon-found-every-100ms-of-laten...

Uh.. they've already _bought_ the car. What percentage of people will return a car due to a little lag when adjusting radio stations? e-commerce findings from a major retailer are, alas, not applicable to every domain

Consumer Reports has found that the functionality of the in-car entertainment system is the #1 indicator of customer satisfaction. You might not return the car, but you can bad mouth the system to anyone who will listen and purchase a different brand car next time.

Re: Crafting a high-performance TV user interface using React

#70

Post by nodamage »

usaphp wrote: post #34
makecheck wrote: post #26

Interface performance is one of the strangest problems to have in this age of crazy processing power but it is extremely common. Some of the delay is just plain silly and avoidable, like having long and synchronous opening animations in response to an action, which only serve to waste the user’s time. (Oh how I love being on a web site like AT&T and watching their JavaScript poorly zoom open a blank box from the cent…

Especially the lag that you see on some brand new cars, only BMW and Audi seem to have lag free interface, but anything else that involves touch interface is just horrid! I've recently sat in my friend's brand new Honda SUV and the interface lag is just plain silly, for a car that costs $30,000+. Why is that?

Same with in-flight entertainment systems on planes. They always have terrible, slow interfaces.
Post reply on HN