Netflix JavaScript Talks - Async JavaScript with Reactive Extensions
Netflix JavaScript Talks - Async JavaScript with Reactive Extensions on HackerTube: recommended by 5 Hacker News commenters across 4 separate months, 2014–2016.
A Netflix JavaScript talk on using Reactive Extensions (Rx) for asynchronous UI code. It covers Observables, composing events such as drag and drop, and sequencing Ajax requests.
What HN commenters said
9 Hacker News comments link this video. Each one links back to its thread.
sktrdieJun 2016Strongly recommends
I don't really like await . It seems to be a syntactical fix which acts in a quite magical way. Not sure if introducing magic to a language syntax is what we want. Rather, we should think about data flow of our async apps differently. I believe Observables are the future of async code. Once you grasp the concept that everything in your app can be transformed into streams of events, and you work with these events using chains of .map(), .filter(), .reduce(), etc. you'll grasp the true power of this paradigm and how well it fits async and/or concurrent apps. I suggest anybody that doesn't quite swallow the await syntax, to have a look at this presentation about Observables at Netflix as it's quite mind changing: ▶ this video
in “Async and Await” · View on HN
film42May 2014Strongly recommends
The conf talk on youtube by Matt Marenghi [linked in the post] is really awesome. Provides great examples and resources. Really worth 28-min. Direct Link: ▶ this video
in “Asynchronous JavaScript at Netflix” · View on HN
srikuJul 2014Recommends
Yes I meant what "Reactive Extensions" does. Should've been clearer that it was a reference to "functional reactive programming" and not a specific library. edit: "Async Javascript at Netflix" is a great talk on this - ▶ this video
in “My Golang UI package: lessons learned about threading and plans for the future” · View on HN
shaydocJun 2014Recommends
i thought it was a good presentation, however, I recently watched a Netflix one, published by Matt Marenghi, which to me was infinitely better. I think the description of events as just another collection, albeit a time based collection flow was nicer ( Observable === Collection + Time ), and also that this collection must have the ability to tell you that it has terminated. ▶ this video
in “Erik Meijer: Duality and the End of Reactive [video]” · View on HN
mattpodwysockiJun 2014Recommends
It's not a fad at all, with Netflix and other companies using Rx in all flavors on their platforms. See this video from Jafar Husain, a tech lead at Netflix, talk about how they use RxJS at Netflix: ▶ this video
in “An Introduction to Reactive Programming” · View on HN
mattpodwysockiJun 2014Recommends
Why not try watching the video from Jafar Husain, a tech lead from Netflix, talk about Async JavaScript at Netflix which uses RxJS to explain these concepts? ▶ this video
in “An Introduction to Reactive Programming” · View on HN
Show 3 more comments
RobertKeransJul 2015Cites it
I assume you use SQL or similar? It's not exactly Haskell-level functional, but still, you're probably already using functional paradigms. In the case of JS, using functional techniques simplifies the code quite substantially. Testing becomes easier. Immutable data can be much easier to reason about. It's often orthogonal to OOP, functional techniques in the small, OOP to structure in the large. FRP is very useful for interactions front-end (form validation for example), but also is just all-round terrific for message passing. Recursion is ideal for certain scenarios. If you take something like handling errors, an example would be the way promises deal with them, with the ability to collect at the end of the chain, or deal on a case-by-case basis. I'm just listing stuff off the top of my head; with a general-purpose language [with the option of different paradigms] it's not so much a case of 'build a web app', it's more 'if you use these techniques, you may well find that your code is easier to reason about'. I think the metaphor I like is that with FP it's as if you have an assembly line of functions, and you pass your data down the line, with each function transforming in turn; each function can easily be ripped out and/or replaced and tested. There are multiple downsides and pitfalls - overly abstracted code being a very common one, but as a general approach it's often extremely useful. Books maybe worth a flick through (tried to pick stuff that is less...abstract, & I hav
in “Mostly Adequate Guide to Functional Programming in JavaScript” · View on HN
staltzJun 2015Cites it
With RxJS, you can compose with existing Promise-based libraries, solve asynchronous programming (and error handling) in an elegant fashion with code that looks like simple linear chains (or DAGs) of Observables, and you don't need to give up non-blocking JS. ▶ this video
in “Pseudosynchronous JavaScript” · View on HN
joubertApr 2014Cites it
Netflix. We are reinventing how people watch television. My team is a group of seasoned engineers that craft JavaScript-based UI's for the living room. You will architect and develop user experiences that will reach millions of customers worldwide on PlayStation 3, PlayStation 4, Xbox360, Apple TV, Chromecast, Roku, and hundreds of Smart TVs and Blu-ray players. You can read more about our flagship UI here: [link] And here are some articles/videos where we've talked about our technical work: * Building the New Netflix Experience for TV [link] * WebKit in Your Living Room [link] * Recent Reactive JavaScript programming event: ▶ this video * Building the Netflix UI for WiiU [link] Message me if you want to know more.
in “Ask HN: Who is hiring? (April 2014)” · View on HN