Crafting a high-performance TV user interface using React • Hacker News Board

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

#181

Post by brogrammer_1 » Fri, Jan 13, 2017, 3:28 PM UTC

pbhjpbhj wrote: post #156

joezydeco wrote: post #106

Earlier quoted context omitted.

Because the software development was started 3 years ago on a platform that was spec'd out 5 years ago. Over those 5 years, the software requirements slowly crept upward while the hardware performance stayed the same and couldn't be changed.

If only we'd work together then the car could have a common bus system and you'd just swap out the control console on the front and choose your level of [stupid, annoying, distracting] graphics and what have you. There's no competition in these systems because people choose the car and get lumbered with the UI on the console. Kinda like if houses had unique electrical systems and you couldn't change the white-goods.

Cars already have CANBUS as a standard thing so it shouldn't be difficult.

I think the CarPlay/MirrorLink/Android Auto thing is probably a better model though. Make the console dumb and let me connect my upgraded-every-year phone that's far more powerful.

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

#182

Post by godelski » Fri, Jan 13, 2017, 7:43 PM UTC

yeukhon wrote: post #159

godelski wrote: post #154

I'm still waiting for them to support Firefox and Linux. Their support says they are working on it, but I am positive that is a lie. At least I can work around it by masking my user-agent string as Chrome (DRM needs to be enabled).

Netflix works on Firefox. I don't remember about Linux. ~3 years ago yes Netflix wouldn't work on Linux without plugins, but I thought they fixed it or provided a workaround. http://www.omgubuntu.co.uk/2016/08/firefox-49-linux-netflix-...

Nope, you have to do a user agent string to get around it. From what I can tell Netflix is filtering it. But I may be wrong, I'm not sure how this stuff works. But I can do it on Firefox and Linux as long as I have DRM enabled (the change in FF49+) and change my user agent string to Linux Chrome (see image http://i.imgur.com/twjpXgv.png). It WILL NOT work without changing the user agent string.

Talking to their support Netflix says it is FF's problem. From what I can tell it isn't actually FF's problem anymore (because this wouldn't work, right?).

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

#183

Post by jeremiep » Fri, Jan 13, 2017, 8:05 PM UTC

allover wrote: post #63

jeremiep wrote: post #25

Earlier quoted context omitted.

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.

Considering Clojure's impressive adoption I wouldn't call it a niche choice anymore; it even seems to be a win for most people adopting it.

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

#184

Post by jeremiep » Fri, Jan 13, 2017, 8:13 PM UTC

intrasight wrote: post #75

jeremiep wrote: post #45

Earlier quoted context omitted.

I really don't like that argument because it assumes your program is important enough to be the only one running on your user's machines; it rarely ever is. Everything easily wastes 90% of the CPU resources it touches and the task manager is completely oblivious to it, happily reporting high usage. When you have 20+ tabs open and 10+ apps all those "its fast enough" apps combine to create their own variant of hell. A…

We're talking here about the time to render JSON to HTML for one page - the page that this user is presumably looking at. If that takes 90% of your CPU for more that a few milliseconds, then it's time to refactor.

Its a bit more complicated.

Its that JSON data, the request to API endpoint(s) to get it, the JavaScript to drive it, the request to fetch that JS and whatnot. That may not waste much CPU indeed, but instead wastes bandwidth and time. This is quite easy to notice on mobile devices.

Your servers now have to serve these API endpoints; static pages can be deferred to proper CDNs. For larger deployments this can drive the server costs to eat your profits rather quickly. Not even considering the fact that the dynamic route was much more development than the static one in the first place.

About the 90% wasted CPU, I was talking about how the CPU constantly waits for memory because very, very few programmers optimize for cache misses and lots of dynamic languages make it impossible to. Waiting on memory still shows as activity in the task manager, but the CPU isn't computing anything.

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

#185

Post by gech » Fri, Jan 13, 2017, 8:30 PM UTC

pfranz wrote: post #35

problems wrote: post #23

Earlier quoted context omitted.

Yup, it's also important to be able to walk over to your friend's machine and help them do something.

I spend a good amount of time doing support. I still play around with plugins, tools, and interfaces, but I try really hard to stick with defaults. One thing I do often do is remap Caps Lock to CTRL and it surprised me how often this catches people (and drives me nuts when I'm using their computer). I have a Logitech Harmony 700 (a very mainstream universal remote), I don't care for it but it's the best I could find,…

This alone is why I wouldn't consider DVORAK. If we have to live in a top-down driven world, I'd at least be open to standards being driven that waay

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

#186

Post by allover » Fri, Jan 13, 2017, 10:35 PM UTC

jeremiep wrote: post #183

allover wrote: post #63

Earlier quoted context omitted.

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.

Considering Clojure's impressive adoption I wouldn't call it a niche choice anymore; it even seems to be a win for most people adopting it.

Can you provide stats on "Clojure's impressive adoption"? By my understanding it's still a very niche language.

The TIOBE index [0] fwiw (please debate) suggests by going from JS to Clojure you'd be switching from the 7th most popular language to the 47th.

In that 'top 47' there are only 3 lispy langs present, 'Clojure', 'Lisp' and 'Schema'. That suggests programming in lisps is a very unpopular idea.

[0] http://www.tiobe.com/tiobe-index/

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

#187

Post by [deleted] » Fri, Jan 13, 2017, 10:57 PM UTC

bsimpson wrote: post #109

cekvenich3 wrote: post #6

I assume that HTML Dom would be fastest. Statically generated. And that working w/ DOM/CSS would make it easier for team's designers to be more engaged.

Gibbon is Netflix's proprietary form of the DOM. They found that the standard DOM was too hard to optimize for embedded hardware, but that it was much easier if they removed the parts they didn't need. I believe Jafar gave a talk at one of the React Confs about it.

[deleted]

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

#188

Post by ricardobeat » Sat, Jan 14, 2017, 1:22 AM UTC

Sanddancer wrote: post #87

Why is it so hard to just say, "precompile your code?" Just in time means having to take the same code, and do the same transformations to it, parse and reparse the code, every time you start the app. Yes, React may be a nice templating engine, but why make everyone go through the same process over and over again when you can copy once and not have to worry about it anymore?

The templates are indeed compiled. All the optimisations they describe happens at runtime, when applying changes to the UI. Browser layout engines are complex beasts and writes can be very expensive.

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

#189

Post by jeremiep » Sat, Jan 14, 2017, 4:24 AM UTC

allover wrote: post #186

jeremiep wrote: post #183

Earlier quoted context omitted.

Considering Clojure's impressive adoption I wouldn't call it a niche choice anymore; it even seems to be a win for most people adopting it.

Can you provide stats on "Clojure's impressive adoption"? By my understanding it's still a very niche language. The TIOBE index [0] fwiw (please debate) suggests by going from JS to Clojure you'd be switching from the 7th most popular language to the 47th. In that 'top 47' there are only 3 lispy langs present, 'Clojure', 'Lisp' and 'Schema'. That suggests programming in lisps is a very unpopular idea. [0] http://www.…

TIOBE is a terrible indicator generally. More activity doesn't mean more people are using a language. I wouldn't work for anyone using it to make decisions :)

The Cognitect website[1] lists quite a few success stories using Clojure. I would trust the names in that list far more than TIOBE.

But really what sold me on the language was the quality of the libraries, the incredibly helpful community and its shared focus on simplicity. Reading about a thing is no substitute for hands-on experience; its hard to judge the trade-offs you're making without it.

[1]: http://cognitect.com/clojure

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

#190

Post by jeremiep » Sat, Jan 14, 2017, 4:33 AM UTC

grayrest wrote: post #61

jeremiep wrote: post #25

Earlier quoted context omitted.

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 s…

I tend to abuse the fact that subscriptions can compose in re-frame to lower the work needed in order to react to app-db changes. The fact that you can namespace keywords make it easy to scale as well.

Its also easy to optimize if you integrate day8/re-frame-tracer. I've lowered the number of views touched by updates quite a bit using it. I barely put any pressure on React anymore.

The bundle size usually isn't that bad with full optimizations enabled. An empty cljs project strips the entire cljs runtime for one, minus one defonce. You can also pass a compilation constant to react to strip its debugging features; that's saving you a few dozen kilobytes as well.

I'm currently building a small app to display Twitch chat as a personal side project and it handles GamesDoneQuick's chat effortlessly. Performance has been great so far.