POPULARITY
44 episodes with ben lesh
3 episodes with ben lesh
2 episodes with ben lesh
2 episodes with ben lesh
3 episodes with ben lesh
4 episodes with ben lesh
4 episodes with ben lesh
3 episodes with ben lesh
2 episodes with ben lesh
In this episode of the Modern Web Podcast, Rob Ocel, Danny Thompson, Adam Rackis, and Brandon Mathis discuss the role of abstractions in software development. They explore frontend tools like React and SolidJS, backend abstractions like serverless platforms, and the importance of understanding patterns and learning through mistakes. The group also highlights emerging trends for 2025, including opportunities in platform plugins and developer marketplaces. Key Points for the Episode: The Role of Abstractions in Development: The panel discusses the benefits and challenges of abstractions in software development, emphasizing the importance of understanding underlying systems to avoid over-reliance on tools like React hooks and serverless platforms. Learning Through Experimentation: Personal experiences with tools like Advent of Code, exploring new languages like Swift and Rust, and experimenting with new frameworks like SolidJS highlight the importance of hands-on learning and stepping outside comfort zones. Platform Opportunities: A growing interest in building apps and plugins on established platforms like Stripe, Zoom, and Chrome Extensions showcases untapped opportunities for developers to create impactful solutions and monetize their skills. Chapters 0:00 - The Potential of Plugins and Platforms 0:42 - Welcome to the Modern Web Podcast 0:47 - Introducing the Hosts and Guests 1:19 - Holiday Projects and Side Gigs 1:31 - Danny's Speedrun of a New Platform 2:07 - Adam's Holiday Reading List 3:38 - Brandon's Advent of Code Challenge in Swift and Rust 5:01 - Learning New Programming Languages Through Challenges 6:52 - Discussion on Abstractions in Software Development 7:10 - The Balance Between Abstractions and Understanding the Basics 8:56 - Learning Through Experience: The Importance of Stepping on Rakes 9:46 - React's Role in Frontend Development and Its Critics 10:39 - The Evolution of Frontend and Backend Abstractions 12:09 - The Impact of Serverless and Cloud Platforms 13:31 - Misuse of Abstractions and Overcomplicated Code 14:27 - The Common Pitfalls of React Hooks Misuse 15:29 - Overuse of `useEffect` and Its Performance Implications 16:41 - Learning from Industry Experts: Insights from Ben Lesh 17:53 - The Evolution of the Web from Static Documents to Interactive Applications 19:04 - The Role of Abstractions in Backend Development and Serverless Adoption 21:06 - Advice for Developers on Understanding Patterns and Abstractions 22:21 - Sponsor Message: This Dot Labs 22:27 - Looking Ahead to 2025: Technologies and Trends 22:43 - Excitement Around SolidJS and Signals-Based Frameworks 23:29 - The Growing Ecosystem Around SolidJS and TanStack Router 24:48 - Insights from a Conversation with Ryan Carniato 25:19 - Interest in TanStack Start and React 19 Features 26:09 - Danny Learning Spanish and Coding Challenges 27:16 - Exploring New Platforms for Side Projects and Monetization 27:55 - The Untapped Potential in Plugin and App Store Ecosystems 29:01 - Case Study: Monetization through Small Chrome and Office Extensions 30:09 - Growth of Developer Marketplaces (Stripe, Slack, Shopify, Zoom) 31:06 - The Challenge of Getting Projects in Front of Users 32:03 - Opportunities in Game Modding and Twitch Extensions 32:32 - Closing Thoughts and Future Podcast Episodes 32:45 - Sponsor Message and Where to Find the Podcast Online Follow the crew on Twitter and Linkedin: Rob Twitter: https://x.com/robocell Rob Linkedin: / robocel Danny Twitter: https://x.com/DThompsonDev Danny Linkedin: / dthompsondev Adam Twitter: https://x.com/AdamRackis Adam Linkedin: / adam-rackis-5b655a8 Brandon Twitter: https://x.com/BrandonMathis Brandon Linkedin: / mathisbrandon Sponsored by This Dot: thisdot.co
On this episode of Modern Web, hosts Tracy Lee, Ben Lesh, Adam Rackis, and guest JLarky share their takes on the JavaScript ecosystem, including thoughts on React version transitions and TypeScript compatibility. They also explore the challenges of library updates, as well as web standards and the complexities within standards bodies. Sponsored by This Dot Watch This Episode on YouTube Read more on our blog
Rich Harris, Tracy Lee, Ben Lesh, and Adam Rackis discuss the state of Svelte, React Server Components (RSCs), and the future of web development. Discover React Server Components, web development's next evolution in co-locating resources for improved data management, and reusability. Uncover the benefits of component-based data fetching, like improved composition, and ease of development. Sponsored by This Dot Watch this episode on our YouTube Channel Read more on our blog
Colby Fayock joins hosts Ben Lesh, Adam Rackis, and Tracy Lee to talk about their latest takes on React Server Components, Next.js, and performance optimization. If you want to learn more about the React Server Components conversations on the web, the intricacies of caching in web development, the ins and outs of SDK development for Next.js, the power of type enforcement with tools like Zod and TypeScript, and the art of async programming, check out this podcast. The four also talk about performance optimization and the complexities of integrating new technologies into existing applications. Sponsored by This Dot Watch this episode on YouTube
On this episode of the Modern Web Podcast, Tracy Lee, Adam Rackis, Ben Lesh, and guest Matthew Phillips discuss what's going on in the world of Astro. They explore the concept of 'Islands' and how Astro allows seamless integration of components from different frameworks like React or Vue. The conversation covers technical details like client directives for selective rendering and the challenges of collecting metrics. They also discuss the importance of type safety and the development of server actions in Astro, including the introduction of AstroDB for database integration. Sponsored by This Dot Watch this episode on YouTube Read more on our blog
Darcy Clarke shares vlt.sh, a new package manager which he has been building with npm Creator Isaac Schlueter and Node TSC member Ruy Adorno. Along with hosts Tracy Lee, Ben Lesh, and Adam Rackis, he shares insights on emerging developer tools, pair programming, and sustainability in open source. Sponsored by This Dot. Watch this episode on YouTube. Read more on our blog.
Tracy Lee, Adam Rackis, Ben Lesh, and guest Carter Rabasa discuss the democratization of AI technology and the challenges developers face with AI today. Carter educates the group on the significance of vector databases for fuzzy and similarity searches, along with the evolving landscape of AI technologies. The conversation also touches on the risks associated with advanced AI capabilities like privacy concerns. Don't miss this insightful discussion on the socio-economic impacts of technology adoption, and the importance of responsible development. Sponsored by This Dot Labs Watch this episode on our YouTube channel. Read more on our blog.
Jay Phelps, a Senior Software Engineer at Netflix, alongside Ben Lesh, Tracy Lee, and Adam Rackis, explores challenges facing React developers, the problem with Vercel and Next.js, and the solutions that the web platforms teams should be focused on to improve the web for everyone, especially those that use third party scripts. Sponsored by This Dot Labs Watch this episode on our Youtube Page! Read more on this blog.
Tracy Lee, Adam Rackis, Ben Lesh host Chance Strickland to discuss new web APIs, CSS, Tailwind and Atomic CSS pros and cons, React Server Component implementations, and so much more on this podcast. Sponsored by This Dot Labs Watch this Episode on YouTube. Read more on our blog.
What is the current state of React and its influence from Vercel? What are the challenges of upgrading to React 18 and the impact on testing? The hosts also cover the potential for the runtime Bun to become the default for node development. The conversation explores the future of front-end development, the complexities of modern web development, and the influence of content creators in the industry. Sponsored by This Dot Labs Watch this podcast on our YouTube channel! Read more on our blog.
In this episode of the Modern Web Podcast, Ben Lesh (Author, RxJS), Adam Rackis (Senior Software Engineer, Spotify) and Tracy Lee (Google Developer Expert, RxJS Core Team) discuss several hot topics bouncing around the web lately: Tailwind CSS: Is it a hero or a zero? Is Remix better than Next.js? Should e-commerce sites be using Qwik or Remix? Is React dying? Internal apps vs consumer apps: what are more fun to work with? Sponsored by This Dot Labs
In this episode of Syntax, Wes and Scott give a high level overview of the observer pattern, what is the observer, what are downsides to too many observers, and more. Show Notes 00:25 Welcome 01:42 Syntax Brought to you by Sentry 02:16 High level overview Syntax 694: What's Up With Angular with Mark Techson Godot Engine 03:36 What might you observe in game development? 06:50 What is the observer? 08:11 What are some downsides to too many observers? 10:17 IntersectionObserver, MutationObserver, and PerformanceObserver 12:25 ResizeObserver 13:04 What about addEventListener? @BenLesh on Callbacks being faster than observables 16:13 Signals are becoming a big thing Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads
On this episode of Modern Web, Tracy Lee, Ben Lesh, Adam Rackis, and Dax Raad discussed the cloud offerings of SST and the advantages of using AWS. Adam was excited about SST's cloud wrappers and the fact that they were built with Solid instead of React to meet ambitious performance requirements. SST helps people build on AWS by simplifying the hundreds of services available and providing an experience that allows users to become experts in AWS. Dax discussed his experience with React and Solid, and the trade offs between the two. [00:02:40] Building on AWS made easy. [00:06:00] Simplifying AWS: Less than five services. [00:10:43] Hidden gem: IoT core pubsub real-time. [00:14:33] AWS back-end and front-end support. [00:17:20] Reaching new audiences with NextJS. [00:20:06] Simplicity over complexity: Solid wins. [00:24:01] GitHub-powered effortless development for all. [00:26:24] Serverless event-driven architecture solves cold start issue. [00:30:13] Granular auto-scaling, milliseconds up/down. Sponsored by This Dot Labs
In this podcast episode, Tracy Lee, Ben Lesh, and guest Adam Rackis talk through the successful fusion of TypeScript and React. They chat about various web frameworks, like Angular and Svelte, emphasizing the impact of TypeScript support on the development process. The episode also highlights the excitement around Svelte's new feature, signals, and speculates on its potential standardization, as well as React 18's challenges and the evolution of the React ecosystem. Sponsored by This Dot Labs.
In this special episode of the Modern Web podcast, Tracy Lee and Ben Lesh are joined by Netflix Engineering Managers Ryan Burgess and Jem Young. They tackle the transition from coding to management roles, debunking myths and shedding light on real challenges. Emphasizing that management isn't a simple promotion, but a unique career track requiring distinct skills. Their candid conversation exposes the value of experienced architects guiding junior team members, fostering well-rounded teams. The group engages in lively banter, debunking the idea that management is the sole path to career growth, exploring industry trends, including streamlining management hierarchies for efficiency. This episode resonates with diverse tech career trajectories, inspiring you with insights into leadership, team dynamics, and the evolving landscape. Hosts Tracy Lee, CEO of This Dot Labs Ben Lesh, Author of RxJS Guest Jem Young, Engineering Manager at Netflix Ryan Burgess, Engineering Manager at Netflix Sponsored by This Dot Labs
In this episode of Modern Web, Tracy Lee and Ben Lesh are joined live at RenderATL by Francesco Ciulla, Tessa Mero, Ady Ngom, and Jessica Wilkins! Tune in as they double click into the highly debated subject of Tailwind CSS and explore the advantages, readability concerns, and overall consensus on its usage. Discover why Tailwind CSS is making waves in the industry, particularly for new projects, and how it can simplify your development process while enhancing productivity. But that's not all! The conversation takes an intriguing turn as the group dives into the realm of web components. Hear opinions on whether web components can be a viable alternative to traditional frameworks. Gain insights into the challenges and opportunities surrounding web components, including server-side rendering and widespread adoption. Hosts Tracy Lee, CEO of This Dot Labs Ben Lesh, Author of RxJS Panel Francesco Ciulla, DevRel at daily.dev Tessa Mero, Developer Advocate at Appwrite Ady Ngom, Chief Consultant at Techlabs 28 Jessica Wilkins, Software Engineer at This Dot Labs Sponsored by This Dot Labs
In this episode of Modern Web, co-hosts Tracy Lee and Ben Lesh sit down live at RenderATL with Scott Tolinski, co-host of the Syntax podcast and of Level Up Tutorials, to discuss his journey as a web development tutorial creator and YouTuber. He shares his experiences of transitioning from a full-time developer to creating YouTube tutorials as a side project. Initially, Scott started his YouTube channel to fill his free time but eventually saw it gain popularity and became his full-time career in 2017. However, he faced challenges when attempting to monetize his content and struggled to convince his audience to pay for his courses after providing free content for years. Scott also talks about the technical aspects of his work, highlighting the benefits of using Svelte, a JavaScript framework, and his preference for its close resemblance to the DOM. He also mentions the evolution of his content creation strategies, such as releasing teaser videos on YouTube to redirect viewers to his website, where the main courses were available behind a paywall. The conversation touches on the challenges of being a YouTuber, including the unpredictability of ad revenue and the abundance of kids' content that can be both entertaining and controversial. Scott expresses his openness to his own children exploring YouTube but emphasizes the importance of allowing them to choose their own path. Overall, the interview provides insights into Scott Tolinski's experiences as a developer, YouTuber, and co-host of the Syntax podcast, highlighting his journey from creating free tutorials to monetizing his content and the challenges he faced along the way. Guest Scott Tolinski, Co-host of Syntax.fm Hosts Tracy Lee, CEO of This Dot Labs Ben Lesh, RxJS Core Team Lead This episode is sponsored by This Dot Labs.
EPISODE DESCRIPTION:Suddenly jobless? Or maybe not but what if it happens in the future? As RxJS Core Team Lead Ben Lesh has learned, even with a rockstar resume, you never know when you could find yourself unexpectedly unemployed. Ben joins this episode of The Dev Life to talk about his experience of recently being laid off and shares advice for what to do if you find yourself in a similar situation. How can you plan ahead and be prepared for the financial and mental rollercoasters you might face? What can you be doing today to build a strong network and portfolio so any setbacks could actually become your greatest comeback? Hold on to your compilers and enjoy another episode of… The Dev Life!LINKS:https://twitter.com/benlesh?lang=enhttps://www.twitch.tv/benleshCONNECT WITH US:Ben Lesh - @BenLeshBrooke Avery - @jediBraveryPreston Lamb - @PrestonJLamb
In this episode, Rob Ocel is joined by Ben Lesh (RxJS Core Team Lead) and Ryan Carniato (Principal Engineer at Netlify, Creator of SolidJS) to discuss Signals. They talk about what Signal are, why they're suddenly so popular, how Signals differ from Observables, and whether Signals (or Observables) should be integrated into the web platform. They also cover how engineers should think about the "Signals hype", and how Signals are implemented differently from framework to framework. Guests Ryan Carniato - Principal Engineer @Netlify, Creator of @solid_js, and the CEO of Signals - @RyanCarniato Ben Lesh - RxJS Core Team Lead, and the CEO of Observables? - @BenLesh Host Rob Ocel - Architect and Engineering Lead @ThisDotLabs - @robocell
Signals are coming to Angular! So what does that mean for RxJs? In this episode we invite Ben Lesh to get his take on what the Signals story means for RxJs and Angular. How can Signals and RxJs work together, when one might be the better tool, and what bad patterns should developers watch out for as they begin to implement Signals in their code. Learn more about Ben LeshFind us and our guests on twitter:@BenLeshThe Angular Plus Show (@AngularShow)The Angular Plus Show is a part of ng-conf. ng-conf is a multi-day Angular conference focused on delivering the highest quality training in the Angular JavaScript framework. 1500+ developers from across the globe converge on Salt Lake City, UT every year to attend talks and workshops by the Angular team and community experts.Follow us on twitter @ngconfOfficial Website: https://www.ng-conf.org/
SELECT*: Your Resource for Innovative Tech & Developer Topics Hosted by HarperDB
This episode of Select*, the HarperDB podcast, features Ben Lesh. Ben is the RxJS core team lead, as well as a Dad and art lover. Questions covered include: Share a bit about you, your background and journey into tech, and what you're working on now.What is RxJS, what's it used for, how and why was it created?What's it like being in the open source space, what kind of strategies have been successful for you thus far?What piece of advice, good or bad, has really stuck with you throughout your career? What other technologies / tools / frameworks are you super excited about right now?Ben Lesh is a software engineer from Austin, Texas. He's best known for being the project lead on RxJS for the past 7 years (https://rxjs.dev). During his >20 year career he's worked at companies like Netflix and Google, and he's spoken about reactive programming all over the world. He has 3 kids. He loves painting, drawing, and visiting art museums.
In today's episode, RxJS Core Team Lead Ben Lesh joins us again to talk about facing public criticism. Ben talks about how to respond when others share harsh words or thoughts about you or your work, how these kinds of situations can be turned into something positive, and how to extend support to others who find themselves in similar situations.CONNECT WITH US:Ben Lesh @benleshBrooke Avery @jediBravery Erik Slack @erik_slack
Ben Lesh says if you can do your best to actually get the users focus on what matters and kind of limit the noisiness of the other things that would be a big deal for certain folks. Thanks to Tenon for sponsoring the transcript for this episode. Transcript Nic Hi, I’m Nic Steenhout. And you’re… Continue Reading Ben Lesh talks about ADHD and reducing “noise”
In this episode, we sit down with Ben Lesh, RxJS Project Lead. We wanted to know more about observables, use cases, and common pitfalls when using RxJS. Learn more in this episode. Links https://twitter.com/BenLesh (https://twitter.com/BenLesh) https://benlesh.com (https://benlesh.com) https://github.com/benlesh (https://github.com/benlesh) https://rxjs.dev (https://rxjs.dev) https://tc39.es (https://tc39.es) https://github.com/ReactiveX/rxjs (https://github.com/ReactiveX/rxjs) Contact us https://podrocket.logrocket.com/contact-us (https://podrocket.logrocket.com/contact-us) @PodRocketpod (https://twitter.com/PodRocketpod) What does LogRocket do? LogRocket combines frontend monitoring, product analytics, and session replay to help software teams deliver the ideal product experience. Try LogRocket for free today (https://logrocket.com/signup/?pdr). Special Guest: Ben Lesh.
In this podcast Tracy Lee and Ben Lesh, core team members of RxJS, talk about the big changes RxJS 7.0 ++ has brought to the community! Listen to this podcast to hear updates about upcoming deprecations, new performance improvements, typings fixes, improved multicasting, top level exports, the new configurable retry, and what's coming for RxJS 8. If you're interested in following along with ongoing updates to RxJS, the changelog is here: https://github.com/ReactiveX/rxjs/blob/master/CHANGELOG.md#features-2 Follow the roadmap for RxJS 7 to 8! Issue #6367 on github https://github.com/ReactiveX/rxjs/issues/6367 Full updates for RxJS 7.0 from RxJS Asia: https://docs.google.com/presentation/d/1-LU7YE3NWw8jHeAgdmLu4CBfG7osCx6MsSIeFs16k60/edit#slide=id.g389cbad6b8_0_36 For documentation, check out rxjs.dev. _______ Featuring: Tracy Lee (@ladyleet) - CEO, This Dot Labs Ben Lesh (@benlesh) - Software Engineer at Citadel & Author of RxJS This episode is sponsored by This Dot Labs.
In this podcast, Tracy Lee (@ladyleet) and Ben Lesh (@benlesh) sit down with Maximiliano Firtman (@firt) and discuss how performance in development is becoming required for development on the web and mobile, and the implications for not making sure performance is a part of your product strategy. They talk about what’s next after Lighthouse in a developer’s web performance journey, other tools such as Microsoft's webhint, and the new core web vitals that Google has recently published. Plus, they explore the importance (or lack thereof these days) of PWAs and how that is changing on mobile platforms. Guest: Maximiliano Firtman (@firt) - Freelance Mobile+Web developer | Author, Speaker, & Trainer Hosts: Tracy Lee (@ladyleet) - CEO, This Dot Labs Ben Lesh (@benlesh) - Software Engineer at Citadel & Author of RxJS This episode is sponsored by This Dot Labs.
In this podcast Tracy Lee (@ladyleet), Hunter Miller (@hmillerdev), and Ben Lesh (@benlesh) interview Jason Miller (@_developit), creator and core team member of Preact about Preact - its conception, where it's at today, who's using it, and what's coming up for the library. We also ask Jason about how being on the Google Chrome team has impacted the direction of Preact, and about his current project at Google, ModernJS. Guests: Jason Miller (@_developit) - Creator & Core Team Member, Preact | DevRel, Google Hosts: Tracy Lee (@ladyleet) - CEO, This Dot Labs Ben Lesh (@benlesh) - Software Engineer at Citadel & Author of RxJS Hunter Miller (@hmillerdev) - Software Engineer, This Dot Labs This episode is sponsored by This Dot Labs.
In this podcast episode, Tracy Lee (@ladyleet) and Ben Lesh (@benlesh) speak with Sam Saccone (@samccone), a software engineer at Google, about how to prepare for a tech interview. Topics discussed: How to approach interviewers What questions to prepare for What questions you should be asking the interviewer What algorithm questions are asked What questions are NOT asked Guests: Sam Saccone (@samccone) - Software Engineer, Google Hosts: Tracy Lee (@ladyleet) - CEO, This Dot Labs Ben Lesh (@benlesh) - Software Engineer at Citadel & Author of RxJS This episode is sponsored by This Dot Labs.
In this podcast episode, Tracy Lee (@ladyleet) and Ben Lesh (@benlesh) sit down with special guests, Zouhir Chahoud, Stephanie Stimac, and Craig Dunn from Microsoft about new CSS & media query APIs! Topics discussed: What is the new CSS & JS primitives What does this mea for developers and designers? How can you start experimenting right now? docs.microsoft.com/dual-screen for more info on designing and developing for these devices Guests: Zouhir Chahoud - Program Manager, Edge Stephanie Stimac - Program Manager, Edge Craig Dunn - Principle Software Engineer, Microsoft Hosts: Tracy Lee (@ladyleet) - CEO, This Dot Labs Ben Lesh (@benlesh) - Software Engineer at Citadel & Author of RxJS This episode is sponsored by KendoReact & This Dot Labs.
In this podcast, Luis Aviles (@luixaviles) and Tracy Lee (@ladyleet) interview Ben Lesh (@benlesh), author of RxJS on the most recent updates for RxJS 7 beta and it's targeted release date. We discuss how he made RxJS 7 smaller and where you can find the refactored code. We talk about what's next for RxJS 8, how they're using TypeScript in strict mode, what things to keep in mind while you're working with the reactive programming approach, and what deprecations to start looking out for so you can begin future proofing your code today well before the release. Hosts: Luis Aviles (@luixaviles) - Software Engineer, This Dot Labs Tracy Lee (@ladyleet) - CEO, This Dot Labs Guest: Ben Lesh (@benlesh) - Software Engineer at Citadel & Author of RxJS This episode is sponsored by This Dot Labs.
In this podcast episode, Tracy Lee (@ladyleet) and Ben Lesh (@benlesh) sit down with Aaron Frost and talk about Scully.io! Guest: Aaron Frost (@aaronfrost) - CEO, Founder, Architect of HeroDevs and ng-conf organizer This episode is sponsored by KendoReact & This Dot Labs.
Part 2 of our series on State Management in Angular focuses on the use of RxJS in order to leverage Observables, Subjects, and BehaviorSubjects in Angular applications.First, Aaron Frost and Jennifer Wadella talk through how RxJS is used by Angular developers to persist state in singleton services using Subjects. This is a common approach to implementing a single source of truth with the observable pattern in Angular. Another benefit of the approach is a path to implementing a state management library such as NgRx in an Angular application when necessary.Then, Ben Lesh joins Brian Love and the other panelists to share his story of how he personally got started on the RxJS project. One of the major drawbacks of using promises is a lack of a cancellation feature. While at Netflix, the team resolved this by using the Observable primitive. Ben also shares the story of how he was tasked with refactoring RxJS to follow the then-to-be approved TC39 proposal for the Observable primitive. We then learn from Ben about the current work that is being done by the RxJS core team and the future of RxJS.Finally, Ben drops some knowledge on a simple philosophy: if the code you write works, can be maintained, and is testable, then it's good code. The end.Show Notes: https://github.com/ReactiveX/rxjs/blob/8dacf256be307ba3b8b2e9c94badb4b398e1ec47/docs_app/content/guide/glossary-and-semantics.md
In this episode of Adventures in Angular Charles Max Wood does interviews at RxJS Live. His first interview is with Hannah Howard at RxJS Live about her talk. Hannah is really enthusiastic about RxJS especially when it comes to frontend development. Her talk is about how to architect full-scale apps with RxJS. Hannah gives a brief summary of her talk. Charles having met Hanna previously at Code Beam asks her how functional programming and reactive programming work together in her mind. Hannah describes how she sees programming. Charles’s next interview is with Ben Lesh, a core team member of RxJS. Ben has been working on RxJS for the last four years. In his talk, he shares the future of RxJs, the timeline for versions 7 and 8. With Charles, he discusses his work on RxJS and the adoption of RxJS. Next, Charles interviews Sam Julien and Kim Maida. They gave a talk together covering the common problems developers have when learning RxJS. In the talk, they share tips for those learning RxJS. Charles wonders what inspired them to give this talk. Both share experiences where they encouraged someone to use RxJS but the learning curve was to steep. They discuss the future of RxJS adoptions and resources. Finally, Charles interviews Kim alone about her second talk about RxJS and state management. She explains to Charles that many state management libraries are built on RxJS and that it is possible to roll out your own state management solution with RxJS. They discuss why there are so many different state management libraries. Kim shares advice for those looking to roll out their own solutions. Panelists Charles Max Wood Guests Hannah Howard Ben Lesch Sam Julien Kim Maida Sponsors Sentry -use the code "devchat" for 2 months free on Sentry's small plan CacheFly Links https://www.rxjs.live/ RxJS Live Youtube Channel https://twitter.com/techgirlwonder https://twitter.com/benlesh http://www.samjulien.com/ https://twitter.com/samjulien https://twitter.com/KimMaida https://www.facebook.com/javascriptjabber https://twitter.com/JSJabber
In this episode of Adventures in Angular Charles Max Wood does interviews at RxJS Live. His first interview is with Hannah Howard at RxJS Live about her talk. Hannah is really enthusiastic about RxJS especially when it comes to frontend development. Her talk is about how to architect full-scale apps with RxJS. Hannah gives a brief summary of her talk. Charles having met Hanna previously at Code Beam asks her how functional programming and reactive programming work together in her mind. Hannah describes how she sees programming. Charles’s next interview is with Ben Lesh, a core team member of RxJS. Ben has been working on RxJS for the last four years. In his talk, he shares the future of RxJs, the timeline for versions 7 and 8. With Charles, he discusses his work on RxJS and the adoption of RxJS. Next, Charles interviews Sam Julien and Kim Maida. They gave a talk together covering the common problems developers have when learning RxJS. In the talk, they share tips for those learning RxJS. Charles wonders what inspired them to give this talk. Both share experiences where they encouraged someone to use RxJS but the learning curve was to steep. They discuss the future of RxJS adoptions and resources. Finally, Charles interviews Kim alone about her second talk about RxJS and state management. She explains to Charles that many state management libraries are built on RxJS and that it is possible to roll out your own state management solution with RxJS. They discuss why there are so many different state management libraries. Kim shares advice for those looking to roll out their own solutions. Panelists Charles Max Wood Guests Hannah Howard Ben Lesch Sam Julien Kim Maida Sponsors Sentry -use the code "devchat" for 2 months free on Sentry's small plan CacheFly Links https://www.rxjs.live/ RxJS Live Youtube Channel https://twitter.com/techgirlwonder https://twitter.com/benlesh http://www.samjulien.com/ https://twitter.com/samjulien https://twitter.com/KimMaida https://www.facebook.com/javascriptjabber https://twitter.com/JSJabber
In this episode of Adventures in Angular Charles Max Wood does interviews at RxJS Live. His first interview is with Hannah Howard at RxJS Live about her talk. Hannah is really enthusiastic about RxJS especially when it comes to frontend development. Her talk is about how to architect full-scale apps with RxJS. Hannah gives a brief summary of her talk. Charles having met Hanna previously at Code Beam asks her how functional programming and reactive programming work together in her mind. Hannah describes how she sees programming. Charles’s next interview is with Ben Lesh, a core team member of RxJS. Ben has been working on RxJS for the last four years. In his talk, he shares the future of RxJs, the timeline for versions 7 and 8. With Charles, he discusses his work on RxJS and the adoption of RxJS. Next, Charles interviews Sam Julien and Kim Maida. They gave a talk together covering the common problems developers have when learning RxJS. In the talk, they share tips for those learning RxJS. Charles wonders what inspired them to give this talk. Both share experiences where they encouraged someone to use RxJS but the learning curve was to steep. They discuss the future of RxJS adoptions and resources. Finally, Charles interviews Kim alone about her second talk about RxJS and state management. She explains to Charles that many state management libraries are built on RxJS and that it is possible to roll out your own state management solution with RxJS. They discuss why there are so many different state management libraries. Kim shares advice for those looking to roll out their own solutions. Panelists Charles Max Wood Guests Hannah Howard Ben Lesch Sam Julien Kim Maida Sponsors Sentry -use the code "devchat" for 2 months free on Sentry's small plan CacheFly Links https://www.rxjs.live/ RxJS Live Youtube Channel https://twitter.com/techgirlwonder https://twitter.com/benlesh http://www.samjulien.com/ https://twitter.com/samjulien https://twitter.com/KimMaida https://www.facebook.com/javascriptjabber https://twitter.com/JSJabber
In this episode of JavaScript Jabber Charles Max Wood does interviews at RxJS Live. His first interview is with Hannah Howard at RxJS Live about her talk. Hannah is really enthusiastic about RxJS especially when it comes to frontend development. Her talk is about how to architect full-scale apps with RxJS. Hannah gives a brief summary of her talk. Charles having met Hanna previously at Code Beam asks her how functional programming and reactive programming work together in her mind. Hannah describes how she sees programming. Charles’s next interview is with Ben Lesh, a core team member of RxJS. Ben has been working on RxJS for the last four years. In his talk, he shares the future of RxJs, the timeline for versions 7 and 8. With Charles, he discusses his work on RxJS and the adoption of RxJS. Next, Charles interviews Sam Julien and Kim Maida. They gave a talk together covering the common problems developers have when learning RxJS. In the talk, they share tips for those learning RxJS. Charles wonders what inspired them to give this talk. Both share experiences where they encouraged someone to use RxJS but the learning curve was to steep. They discuss the future of RxJS adoptions and resources. Finally, Charles interviews Kim alone about her second talk about RxJS and state management. She explains to Charles that many state management libraries are built on RxJS and that it is possible to roll out your own state management solution with RxJS. They discuss why there are so many different state management libraries. Kim shares advice for those looking to roll out their own solutions. Panelists Charles Max Wood Guests Hannah Howard Ben Lesch Sam Julien Kim Maida Sponsors ABOUT YOU | aboutyou.com/apply Sentry use the code "devchat" for 2 months free on Sentry's small plan Links https://www.rxjs.live/ RxJS Live Youtube Channel https://twitter.com/techgirlwonder https://twitter.com/benlesh http://www.samjulien.com/ https://twitter.com/samjulien https://twitter.com/KimMaida https://www.facebook.com/javascriptjabber https://twitter.com/JSJabber
In this episode of JavaScript Jabber Charles Max Wood does interviews at RxJS Live. His first interview is with Hannah Howard at RxJS Live about her talk. Hannah is really enthusiastic about RxJS especially when it comes to frontend development. Her talk is about how to architect full-scale apps with RxJS. Hannah gives a brief summary of her talk. Charles having met Hanna previously at Code Beam asks her how functional programming and reactive programming work together in her mind. Hannah describes how she sees programming. Charles’s next interview is with Ben Lesh, a core team member of RxJS. Ben has been working on RxJS for the last four years. In his talk, he shares the future of RxJs, the timeline for versions 7 and 8. With Charles, he discusses his work on RxJS and the adoption of RxJS. Next, Charles interviews Sam Julien and Kim Maida. They gave a talk together covering the common problems developers have when learning RxJS. In the talk, they share tips for those learning RxJS. Charles wonders what inspired them to give this talk. Both share experiences where they encouraged someone to use RxJS but the learning curve was to steep. They discuss the future of RxJS adoptions and resources. Finally, Charles interviews Kim alone about her second talk about RxJS and state management. She explains to Charles that many state management libraries are built on RxJS and that it is possible to roll out your own state management solution with RxJS. They discuss why there are so many different state management libraries. Kim shares advice for those looking to roll out their own solutions. Panelists Charles Max Wood Guests Hannah Howard Ben Lesch Sam Julien Kim Maida Sponsors ABOUT YOU | aboutyou.com/apply Sentry use the code "devchat" for 2 months free on Sentry's small plan Links https://www.rxjs.live/ RxJS Live Youtube Channel https://twitter.com/techgirlwonder https://twitter.com/benlesh http://www.samjulien.com/ https://twitter.com/samjulien https://twitter.com/KimMaida https://www.facebook.com/javascriptjabber https://twitter.com/JSJabber
In this episode of JavaScript Jabber Charles Max Wood does interviews at RxJS Live. His first interview is with Hannah Howard at RxJS Live about her talk. Hannah is really enthusiastic about RxJS especially when it comes to frontend development. Her talk is about how to architect full-scale apps with RxJS. Hannah gives a brief summary of her talk. Charles having met Hanna previously at Code Beam asks her how functional programming and reactive programming work together in her mind. Hannah describes how she sees programming. Charles’s next interview is with Ben Lesh, a core team member of RxJS. Ben has been working on RxJS for the last four years. In his talk, he shares the future of RxJs, the timeline for versions 7 and 8. With Charles, he discusses his work on RxJS and the adoption of RxJS. Next, Charles interviews Sam Julien and Kim Maida. They gave a talk together covering the common problems developers have when learning RxJS. In the talk, they share tips for those learning RxJS. Charles wonders what inspired them to give this talk. Both share experiences where they encouraged someone to use RxJS but the learning curve was to steep. They discuss the future of RxJS adoptions and resources. Finally, Charles interviews Kim alone about her second talk about RxJS and state management. She explains to Charles that many state management libraries are built on RxJS and that it is possible to roll out your own state management solution with RxJS. They discuss why there are so many different state management libraries. Kim shares advice for those looking to roll out their own solutions. Panelists Charles Max Wood Guests Hannah Howard Ben Lesch Sam Julien Kim Maida Sponsors ABOUT YOU | aboutyou.com/apply Sentry use the code "devchat" for 2 months free on Sentry's small plan Links https://www.rxjs.live/ RxJS Live Youtube Channel https://twitter.com/techgirlwonder https://twitter.com/benlesh http://www.samjulien.com/ https://twitter.com/samjulien https://twitter.com/KimMaida https://www.facebook.com/javascriptjabber https://twitter.com/JSJabber
In this episode of React Native Radio Charles Max Wood does interviews at RxJS Live. His first interview is with Ben Lesh, a core team member of RxJS. Ben has been working on RxJS for the last four years. In his talk, he shares the future of RxJs, the timeline for versions 7 and 8. With Charles, he discusses his work on RxJS and the adoption of RxJS. Next, Charles interviews Sam Julien and Kim Maida. They gave a talk together covering the common problems developers have when learning RxJS. In the talk, they share tips for those learning RxJS. Charles wonders what inspired them to give this talk. Both share experiences where they encouraged someone to use RxJS but the learning curve was to steep. They discuss the future of RxJS adoptions and resources. Finally, Charles interviews Kim alone about her second talk about RxJS and state management. She explains to Charles that many state management libraries are built on RxJS and that it is possible to roll out your own state management solution with RxJS. They discuss why there are so many different state management libraries. Kim shares advice for those looking to roll out their own solutions. Panelists Charles Max Wood Guests Ben Lesch Sam Julien Kim Maida Sponsors Infinite Red G2i CacheFly Links https://twitter.com/benlesh http://www.samjulien.com/ https://twitter.com/samjulien https://twitter.com/KimMaida https://www.rxjs.live/ https://www.facebook.com/ReactNativeRadio/ https://twitter.com/R_N_Radio
In this episode of React Native Radio Charles Max Wood does interviews at RxJS Live. His first interview is with Ben Lesh, a core team member of RxJS. Ben has been working on RxJS for the last four years. In his talk, he shares the future of RxJs, the timeline for versions 7 and 8. With Charles, he discusses his work on RxJS and the adoption of RxJS. Next, Charles interviews Sam Julien and Kim Maida. They gave a talk together covering the common problems developers have when learning RxJS. In the talk, they share tips for those learning RxJS. Charles wonders what inspired them to give this talk. Both share experiences where they encouraged someone to use RxJS but the learning curve was to steep. They discuss the future of RxJS adoptions and resources. Finally, Charles interviews Kim alone about her second talk about RxJS and state management. She explains to Charles that many state management libraries are built on RxJS and that it is possible to roll out your own state management solution with RxJS. They discuss why there are so many different state management libraries. Kim shares advice for those looking to roll out their own solutions. Panelists Charles Max Wood Guests Ben Lesch Sam Julien Kim Maida Sponsors Infinite Red G2i CacheFly Links https://twitter.com/benlesh http://www.samjulien.com/ https://twitter.com/samjulien https://twitter.com/KimMaida https://www.rxjs.live/ https://www.facebook.com/ReactNativeRadio/ https://twitter.com/R_N_Radio
Recording date: 2019-04-09 John Papa @John_Papa Ward Bell @WardBell Dan Wahlin @DanWahlin Ben Lesh @BenLesh Resources: RxJS Angular Vue React NetFlix Engineering blog Lifecycle hooks for angula Angular Ivy Someone to follow Maria Lamardo Tracy Lee Anne Bonner Timejumps 02:06 Guest introduction 03:25 How much RxJS is in non-Angular projects? 06:10 How'd you get into RxJS? 12:35 RxJS tips 15:56 Sponsor: DevIntersection 16:48 How do you classify yourself these days? 24:44 Operator issues 29:34 Error handling 33:24 Debugging advice 38:00 Sponsor: IdeaBlade 38:58 What's the roadmap for RxJS? 44:37 Is RxJS being used in new ways in Angular? 46:43 What should people know about RxJS? 48:08 Someone to follow
Sponsors Sentry use the code "devchat" for $100 credit Clubhouse CacheFly Episode Summary In this episode of My JavaScript Story, Charles Max Wood hosts Ben Lesh, RxJS Lead and senior software engineer at Google. Ben studied to be an illustrator in Columbus College of Art & Design, but upon graduation he realized he wanted to work in web development. Ben thinks having an interest in problem solving was a key factor on his journey in becoming a developer. For his first programming job, he applied to a position and when he didn’t hear back he kept calling them until they gave him an opportunity. He then worked as a consultant at several other positions before he was offered a job at Netflix where he became the development lead for RxJS 5. Ben then switched over to Google’s Angular team. He is currently working on Angular Ivy at Google. Ben then talks about the projects he has worked on that he is proud of. In his journey as a developer, Ben believes that the take-away lesson is asking lots of questions. He himself had no formal programming training and he got to where he is today by asking sometimes embarrassingly simple questions. Links JSJ 248 Reactive Programming and RxJS with Ben Lesh VoV 020: Reactive Programming with Vue with Tracy Lee, Ben Lesh, and Jay Phelps AiA 199: RxJS with Ben Lesh, Tracy Lee, and Jay Phelps Ben's LinkedIN Ben's Twitter Ben's GitHub http://refactr.tech/ https://devchat.tv/my-javascript-story/ Picks Ben Lesh: Angular Ivy reactive.how Ben's Workshop http://refactr.tech/ Charles Max Wood: Charles' Twitter
Sponsors Sentry use the code "devchat" for $100 credit Clubhouse CacheFly Episode Summary In this episode of My JavaScript Story, Charles Max Wood hosts Ben Lesh, RxJS Lead and senior software engineer at Google. Ben studied to be an illustrator in Columbus College of Art & Design, but upon graduation he realized he wanted to work in web development. Ben thinks having an interest in problem solving was a key factor on his journey in becoming a developer. For his first programming job, he applied to a position and when he didn’t hear back he kept calling them until they gave him an opportunity. He then worked as a consultant at several other positions before he was offered a job at Netflix where he became the development lead for RxJS 5. Ben then switched over to Google’s Angular team. He is currently working on Angular Ivy at Google. Ben then talks about the projects he has worked on that he is proud of. In his journey as a developer, Ben believes that the take-away lesson is asking lots of questions. He himself had no formal programming training and he got to where he is today by asking sometimes embarrassingly simple questions. Links JSJ 248 Reactive Programming and RxJS with Ben Lesh VoV 020: Reactive Programming with Vue with Tracy Lee, Ben Lesh, and Jay Phelps AiA 199: RxJS with Ben Lesh, Tracy Lee, and Jay Phelps Ben's LinkedIN Ben's Twitter Ben's GitHub http://refactr.tech/ https://devchat.tv/my-javascript-story/ Picks Ben Lesh: Angular Ivy reactive.how Ben's Workshop http://refactr.tech/ Charles Max Wood: Charles' Twitter
Sponsors Sentry use the code "devchat" for $100 credit Clubhouse CacheFly Episode Summary In this episode of My JavaScript Story, Charles Max Wood hosts Ben Lesh, RxJS Lead and senior software engineer at Google. Ben studied to be an illustrator in Columbus College of Art & Design, but upon graduation he realized he wanted to work in web development. Ben thinks having an interest in problem solving was a key factor on his journey in becoming a developer. For his first programming job, he applied to a position and when he didn’t hear back he kept calling them until they gave him an opportunity. He then worked as a consultant at several other positions before he was offered a job at Netflix where he became the development lead for RxJS 5. Ben then switched over to Google’s Angular team. He is currently working on Angular Ivy at Google. Ben then talks about the projects he has worked on that he is proud of. In his journey as a developer, Ben believes that the take-away lesson is asking lots of questions. He himself had no formal programming training and he got to where he is today by asking sometimes embarrassingly simple questions. Links JSJ 248 Reactive Programming and RxJS with Ben Lesh VoV 020: Reactive Programming with Vue with Tracy Lee, Ben Lesh, and Jay Phelps AiA 199: RxJS with Ben Lesh, Tracy Lee, and Jay Phelps Ben's LinkedIN Ben's Twitter Ben's GitHub http://refactr.tech/ https://devchat.tv/my-javascript-story/ Picks Ben Lesh: Angular Ivy reactive.how Ben's Workshop http://refactr.tech/ Charles Max Wood: Charles' Twitter
In this modern web podcast, Tracy Lee speaks with 2 core team members of the Angular team - Hans Larsen who leads the CLI team and Ben Lesh, author of RxJS. Notes:- Ivy is the biggest focus on the Angular team currently. Ivy is almost done and will make things smaller and tree shakeable.- Hans is focused on schematics - a library to help you build and generate work flows. - CLI - Bazel support is a focus right now to make the CLI faster- Ng update is a smarter way to update dependencies across major versions - it will refactor your project to remove breaking changes and fix breaking changes so you won’t see something is breaking. Topics Covered:- What does schematics enable?- What is ng add and ng update and how are people using them?- What is the future of the CLI?- Angular console You can follow Tracy Lee on twitter @ladyleet, Hans Larsen @hanslatwork, and Ben Lesh @benlesh.
Recording date: 2018-10-30 Tweet John Papa https://twitter.com/john_papa Ward Bell https://twitter.com/wardbell Dan Wahlin https://twitter.com/danwahlin Tracy Lee https://twitter.com/ladyleet Notes (0:01:00) Ward reads the mailbag https://twitter.com/plambweb/status/1057291112807723013 (0:01:35) Tracy says often the best answer to RxJS memory leaks is to check to unsubscribe (0:02:01) Tracy talks about RxJS in stencil https://stenciljs.com/, vue https://vuejs.org, react https://reactjs.org, angular https://angular.io, ionic https://ionicframework.com/ (0:03:12) Learn by making mistakes (0:03:50) Tracy talks about some places you can go wrong in RxJS (0:03:55) Introducing Tracy (0:04:20) Tracy's company https://www.thisdot.co/ (0:05:45) Tracy says she prefers frameworks for what they offer (0:06:10) Tracy talks about rxjs https://rxjs-dev.firebaseapp.com/ (0:06:30) Tracy mentions Ben Lesh and RxJS https://twitter.com/BenLesh (0:07:04) Tracy talks about reactive programming https://en.wikipedia.org/wiki/Reactive_programming as sets of events over time (0:07:47) TC39 https://www.ecma-international.org/memento/tc39-m.htm (0:08:00) Tracy explains how, generally, observables are stateless and lazy (0:08:50) Tracy discusses the stages of the TC39 (0:09:03) Babel https://babeljs.io/ (0:09:33) Ward asks what questions Tracy hears at her RxJS workshops https://www.thisdot.co/rx-workshop (0:10:03) Tracy says she hears a lot of confusion on observables and observers https://toddmotto.com/rxjs-observables-observers-operators (0:10:11) Tracy says rxjs operators can be a source of confusion https://www.learnrxjs.io/operators/ (0:10:55) Ben Lesh is working on RxJS 7 (0:11:15) Ward asks tracy how she slides people into rxjs easily (0:11:30) Tracy says she likes that Observables are just functions (0:12:54) John asks Tracy which operators in rxjs to learn first (0:13:53) Ward asks Tracy about the new RxJS docs (0:14:04) Ward talks about one of the creators of RxJS, Matt Podwysocki https://twitter.com/mattpodwysocki (0:14:20) Tracy talks about how RxJS was created as it is today from Netflix and Microsoft (0:15:02) Tracy says there are over 12 million downloads of rxjs a month (0:15:24) Ward mentions the RxJS docs https://rxjs-dev.firebaseapp.com/ (0:16:46) RxJS on npm https://www.npmjs.com/package/rxjs (0:17:50) John asks Tracy how she advises people on upgrade strategies for RxJS (0:18:45) Ward mentions the RxJS change from method chaining to pipe (0:18:49) Upgrade rxjs 5 to 6 https://www.learnrxjs.io/concepts/rxjs5-6.html (0:19:46) John asks Tracy what kind of applications she sees people creating with RxJS (0:20:00) Tracy talks about multi-plex over a websocket with rxjs with node.js and react native (0:20:22) Tracy mentions React Native https://facebook.github.io/react-native/ (0:20:37) Ken Wheeler https://twitter.com/ken_wheeler (0:21:28) Ward asks if "just subscribe" is a useful bit of advice (0:23:30) Tracy talks about reactive aspects and non reactive aspects of code (0:24:15) John mentions how RxJS is not part of any particular front end framework (0:24:30) Tracy says she is seeing a lot of React folks taking learning and using RxJS (0:24:34) Tracy talks about how RxJS is framework agnostic (0:25:17) Tracy talks about prtoecting from JavaScript fatigue (0:25:40) Ward asks Tracy how she recommends debugging RxJS (0:26:10) Tracy asys to "keep tapping away" (0:26:31) Tracy says they are trying to make testing easier (0:26:58) Tracy talks about how you can get into the RxJS slack channel (0:27:50) Tracy talks about her use of Evernote for staying organized (0:29:00) Tracy talks about her efforts with Women in Tech https://twitter.com/ladyleet/status/985018157994831872?lang=en (0:29:31) Tracy talks about possibly announcing something at the ngAtlanta: https://ng-atl.org/#/ conference (0:30:00) Tracy talks about her passion for creating companies (0:30:26) Someone to follow: Jay Phelps https://twitter.com/_jayphelps https://medium.com/@jayphelps (0:31:10) Someone to follow: Dmitri Shekhovtsov https://twitter.com/valorkin (0:31:50) Someone to follow: Dam Abramov https://twitter.com/dan_abramov Additional Resources RxJS api https://rxjs-dev.firebaseapp.com/api RxJS and Angular https://angular.io/guide/rx-library Upgrade RxJS 5 to 6 https://www.learnrxjs.io/concepts/rxjs5-6.html
Ben Lesh joins us and discusses RxJS, Observables, and all about his HUGE fitness transformation.
In this Modern Web podcast OJ Kwon & Ben Lesh from the RxJS core team will discuss what's new in RxJS with Tracy Lee and Robert Ocel. Some topics covered:- What's new in the RxJS latest release- RxJS testing - what’s available today and coming for tomorrow- Support for async generators - RxJS staying framework agnostic- RxJS and Node - is there support for Node developers?- RxJS docs- A marketplace for operators?- Come contribute to RxJS If you need RxJS help, visit https://www.thisdot.co/labs You can follow us on Twitter:Tracy Lee @ladyleetRob Ocel @robocellBen Lesh @benleshOJ Kwon @_ojkwon
Panel: Nader Dabit Sia Karamalegos Special Guests: Tracy Lee, Jay Phelps, and Ben Lesh In this episode, the React Round Up panelists talk to Tracy Lee, Jay Phelps, and Ben Lesh about RxJS and redux-observable. Tracy, Jay, and Ben are the RxJS ThisDot Media group and where they do support contracts for RxJS, staff augmentation, developer relations, and put on events. They talk about what observables are and what they are trying to solve, the most common use cases for getting started with observables, and what Promises and Async/Await are. They also touch on what they like most about RxJS, how versatile it is, and more! In particular, we dive pretty deep on: Tracy, Jay, and Ben intro ThisDot RxJS What is an observable? What problems are observables trying to solve? JavaScript Learn observables Making everything functional in the library Means of encapsulating values you want pushed at you later on Downside to observables Little bit of a learning curve Most common uses for getting started with observables Can Promises and Async/Await be mixed with observables? What do Promises and Async/Await allow you to do? Defer function Await values coming in from observables What do you like about RxJS? Allows you to work with all different languages RxJS is very versatile ngrx “Rx all the things” What inspired you to write Redux observable? Redux-observable RxJS docs Epics And much, much more! Links: ThisDot JavaScript RxJS ngrx Redux Redux-observable RxJS docs @ladyleet Tracy’s GitHub @BenLesh Ben’s Medium Ben’s GitHub @_jayphelps Jay’s GitHub RxJS GitHub @ThisDotLabs Sponsors Kendo UI Digital Ocean FreshBooks Picks: Nader JSCamp Sia Sprint by Jake Knapp Tracy Fashionnova.com Francesca’s Jay deno applitools Ben react-streams StackBlitz
Panel: Nader Dabit Sia Karamalegos Special Guests: Tracy Lee, Jay Phelps, and Ben Lesh In this episode, the React Round Up panelists talk to Tracy Lee, Jay Phelps, and Ben Lesh about RxJS and redux-observable. Tracy, Jay, and Ben are the RxJS ThisDot Media group and where they do support contracts for RxJS, staff augmentation, developer relations, and put on events. They talk about what observables are and what they are trying to solve, the most common use cases for getting started with observables, and what Promises and Async/Await are. They also touch on what they like most about RxJS, how versatile it is, and more! In particular, we dive pretty deep on: Tracy, Jay, and Ben intro ThisDot RxJS What is an observable? What problems are observables trying to solve? JavaScript Learn observables Making everything functional in the library Means of encapsulating values you want pushed at you later on Downside to observables Little bit of a learning curve Most common uses for getting started with observables Can Promises and Async/Await be mixed with observables? What do Promises and Async/Await allow you to do? Defer function Await values coming in from observables What do you like about RxJS? Allows you to work with all different languages RxJS is very versatile ngrx “Rx all the things” What inspired you to write Redux observable? Redux-observable RxJS docs Epics And much, much more! Links: ThisDot JavaScript RxJS ngrx Redux Redux-observable RxJS docs @ladyleet Tracy’s GitHub @BenLesh Ben’s Medium Ben’s GitHub @_jayphelps Jay’s GitHub RxJS GitHub @ThisDotLabs Sponsors Kendo UI Digital Ocean FreshBooks Picks: Nader JSCamp Sia Sprint by Jake Knapp Tracy Fashionnova.com Francesca’s Jay deno applitools Ben react-streams StackBlitz
Panel: Shai Reznik Joe Eames Alyssa Nicoll Ward Bell Special Guests: In this episode, the Adventures in Angular panel talks to Ben Lesh, Tracy Lee, and Jay Phelps about RxJS. Tracey is the co-founder of This Dot Labs, which does a lot for the JavaScript community and does JavaScript consulting, as well as is on the RxJS core team. Jay is also a co-founder of This Dot Labs and used to be on the RxJS core team. Finally, Ben is an engineer at Google, is the RxJS project lead there, and is on the Angular team. They talk about the changes to RxJS from the past year, the API changes for version 6, and more! In particular, we dive pretty deep on: Ben, Tracey, and Jay intros What happened in the last year with RxJS? No longer a test scheduler Using real timers Version 5 VS version 6 TestScheduler.Run method Won’t have to write code with injecting a scheduler What’s the best way to get started? Look at the docs Understanding Marble diagrams Many blog articles on Marble syntax out there Wasn’t originally designed for public consumption Using the test Scheduler is not a requirement for testing RxJS code Jasmine testing framework Jest Marbles diagrams are a bit more declarative and specific to RxJS Is it a part of RxJS proper? API changes for version 6 Backwards compatibility package TSLint rules rxjs-tslint TypeScript And much, much more! Links: This Dot Labs JavaScript RxJS Angular TestScheduler.Run method rxjs-tslint TypeScript @ladyleet Tracy’s GitHub @BenLesh Ben’s Medium Ben’s GitHub @_jayphelps Jay’s GitHub RxJS GitHub @ThisDotLabs Sponsors Angular Boot Camp Digital Ocean FreshBooks Picks: Shai A Super Ninja Trick To Learn RxJS’s “switchMap”, “mergeMap”, “concatMap” and “exhaustMap”, FOREVER! by Shai TestAngular.com Joe notion.so WorkFlowy Framework Summit Ward National Day Calendar Tracey Rx Workshop Ben Experimental branch in RxJS Jay brow.sh
Panel: Shai Reznik Joe Eames Alyssa Nicoll Ward Bell Special Guests: In this episode, the Adventures in Angular panel talks to Ben Lesh, Tracy Lee, and Jay Phelps about RxJS. Tracey is the co-founder of This Dot Labs, which does a lot for the JavaScript community and does JavaScript consulting, as well as is on the RxJS core team. Jay is also a co-founder of This Dot Labs and used to be on the RxJS core team. Finally, Ben is an engineer at Google, is the RxJS project lead there, and is on the Angular team. They talk about the changes to RxJS from the past year, the API changes for version 6, and more! In particular, we dive pretty deep on: Ben, Tracey, and Jay intros What happened in the last year with RxJS? No longer a test scheduler Using real timers Version 5 VS version 6 TestScheduler.Run method Won’t have to write code with injecting a scheduler What’s the best way to get started? Look at the docs Understanding Marble diagrams Many blog articles on Marble syntax out there Wasn’t originally designed for public consumption Using the test Scheduler is not a requirement for testing RxJS code Jasmine testing framework Jest Marbles diagrams are a bit more declarative and specific to RxJS Is it a part of RxJS proper? API changes for version 6 Backwards compatibility package TSLint rules rxjs-tslint TypeScript And much, much more! Links: This Dot Labs JavaScript RxJS Angular TestScheduler.Run method rxjs-tslint TypeScript @ladyleet Tracy’s GitHub @BenLesh Ben’s Medium Ben’s GitHub @_jayphelps Jay’s GitHub RxJS GitHub @ThisDotLabs Sponsors Angular Boot Camp Digital Ocean FreshBooks Picks: Shai A Super Ninja Trick To Learn RxJS’s “switchMap”, “mergeMap”, “concatMap” and “exhaustMap”, FOREVER! by Shai TestAngular.com Joe notion.so WorkFlowy Framework Summit Ward National Day Calendar Tracey Rx Workshop Ben Experimental branch in RxJS Jay brow.sh
Panel: Shai Reznik Joe Eames Alyssa Nicoll Ward Bell Special Guests: In this episode, the Adventures in Angular panel talks to Ben Lesh, Tracy Lee, and Jay Phelps about RxJS. Tracey is the co-founder of This Dot Labs, which does a lot for the JavaScript community and does JavaScript consulting, as well as is on the RxJS core team. Jay is also a co-founder of This Dot Labs and used to be on the RxJS core team. Finally, Ben is an engineer at Google, is the RxJS project lead there, and is on the Angular team. They talk about the changes to RxJS from the past year, the API changes for version 6, and more! In particular, we dive pretty deep on: Ben, Tracey, and Jay intros What happened in the last year with RxJS? No longer a test scheduler Using real timers Version 5 VS version 6 TestScheduler.Run method Won’t have to write code with injecting a scheduler What’s the best way to get started? Look at the docs Understanding Marble diagrams Many blog articles on Marble syntax out there Wasn’t originally designed for public consumption Using the test Scheduler is not a requirement for testing RxJS code Jasmine testing framework Jest Marbles diagrams are a bit more declarative and specific to RxJS Is it a part of RxJS proper? API changes for version 6 Backwards compatibility package TSLint rules rxjs-tslint TypeScript And much, much more! Links: This Dot Labs JavaScript RxJS Angular TestScheduler.Run method rxjs-tslint TypeScript @ladyleet Tracy’s GitHub @BenLesh Ben’s Medium Ben’s GitHub @_jayphelps Jay’s GitHub RxJS GitHub @ThisDotLabs Sponsors Angular Boot Camp Digital Ocean FreshBooks Picks: Shai A Super Ninja Trick To Learn RxJS’s “switchMap”, “mergeMap”, “concatMap” and “exhaustMap”, FOREVER! by Shai TestAngular.com Joe notion.so WorkFlowy Framework Summit Ward National Day Calendar Tracey Rx Workshop Ben Experimental branch in RxJS Jay brow.sh
Tracy and Ben meet with three Preact Core team members to talk about the preact-cli, upcoming releases, and the general direction of this popular library. Hosts:Tracy Lee (@ladyleet) - This Dot Co-founder, GDE, RxJS Core teamBen Lesh (@benlesh) - Engineer at Google, Co-founder This Dot, RxJS Core team Guests:Jason Miller (@_developit) - Creator of @preactjs. Web DevRel at Google. Zouhir Chahoud (@_zouhir) - Technical Program Manager for Edge at MicrosoftPrateek Bhatnagar (@_prateekbh) - Works on Amp, User Experience Engineer at Google
Panel: Charles Max Wood Chris Fritz Erik Hanchett Divya Sasidharan Joe Eames Special Guests: Tracy Lee, Ben Lesh, and Jay Phelps In this episode, the Views on Vue panel talks to Tracy Lee, Ben Lesh, and Jay Phelps about reactive programming in Vue. They talk about the new additions to RxJS 6, what RxJS actually is, reactive programming, and Vue Rx. They also touch on the basics of RxJS, the difference between Promises and RxJS, and more! In particular, we dive pretty deep on: RxJS The difference between RxJS 6 and the past versions Moving towards pipeable operators Win for application size Error handling has changed What is RxJS? Utility library to better handle your complex asynchronous stuff Very versatile tool Reactive programming Most popular and well-known reactive programming paradigm Became open source at version 5 How does Vue Rx fit into all of this? What Vue Rx adds Using RxJS vs Promises Observables Subscription options Observable strings The underbelly of coding Error handling Functional programming Promises are eager Web sockets RxJS is not particular to one language Angular And much, much more! Links: RxJS Vue Rx Vue Angular @ladyleet Tracy’s GitHub @BenLesh Ben’s Medium Ben’s GitHub @_jayphelps Jay’s GitHub RxJS GitHub Sponsors Kendo UI Digital Ocean FreshBooks Picks: Charles Master Chef Junior Instant Pot Chris Back up your data more than weekly Divya The introduction to Reactive Programming you've been missing Erik Bracket Pair Colorizer Syntax.fm podcast Joe Backblaze Solo Framework Summit Tracy BeautyFix Subscription Box Blanton’s Ben RxJS docs Experimental branch of RxJS Get some exercise
Panel: Charles Max Wood Chris Fritz Erik Hanchett Divya Sasidharan Joe Eames Special Guests: Tracy Lee, Ben Lesh, and Jay Phelps In this episode, the Views on Vue panel talks to Tracy Lee, Ben Lesh, and Jay Phelps about reactive programming in Vue. They talk about the new additions to RxJS 6, what RxJS actually is, reactive programming, and Vue Rx. They also touch on the basics of RxJS, the difference between Promises and RxJS, and more! In particular, we dive pretty deep on: RxJS The difference between RxJS 6 and the past versions Moving towards pipeable operators Win for application size Error handling has changed What is RxJS? Utility library to better handle your complex asynchronous stuff Very versatile tool Reactive programming Most popular and well-known reactive programming paradigm Became open source at version 5 How does Vue Rx fit into all of this? What Vue Rx adds Using RxJS vs Promises Observables Subscription options Observable strings The underbelly of coding Error handling Functional programming Promises are eager Web sockets RxJS is not particular to one language Angular And much, much more! Links: RxJS Vue Rx Vue Angular @ladyleet Tracy’s GitHub @BenLesh Ben’s Medium Ben’s GitHub @_jayphelps Jay’s GitHub RxJS GitHub Sponsors Kendo UI Digital Ocean FreshBooks Picks: Charles Master Chef Junior Instant Pot Chris Back up your data more than weekly Divya The introduction to Reactive Programming you've been missing Erik Bracket Pair Colorizer Syntax.fm podcast Joe Backblaze Solo Framework Summit Tracy BeautyFix Subscription Box Blanton’s Ben RxJS docs Experimental branch of RxJS Get some exercise
Tracy Lee (@Ladyleet, Co-founder of This Dot, GDE, RxJS core team) and Ben Lesh (@benlesh, RxJS core team, Angular core team, Co-founder of This Dot) discuss Async React and the context API with... Michael Jackson (@mjackson, Founder of React Training, creator of unpkg) and Jay Phelps (@_jayphelps, RxJS core team, GDE, Chief Software Architect @ This Dot) To learn more visit thisdot.co Follow us on Twitter @moderndotweb
In this Modern Web Podcast Tracy Lee (@ladyleet) & Ben Lesh (@benlesh) ask questions regarding “What’s going on in VR?” with guests Aysegul Yonet (@AysSomething) and Martin Splitt (@g33konaut). Hosts: Tracy (@ladyleet) - RxJS core team, Google Developer Expert, co-founder This Dot Labs Ben (@benlesh) - RxJS core team, engineer at Google, RxWorkshop Guests: Aysegul Yonet (@AysSomething) - Senior Angular Engineer at Narwhal Technologies Inc, GDE Martin Splitt (@g33konaut) - Senior software engineer @ Archilogic3D Topics/Questions: - How to get started in VR.- Equipment you need to get started.- Practical applications of VR.- Where is VR used now?- Difference between Unity and VR- VR standards Places you can get started:vizor.ioplay.autodesk.comaws.amazon.com/sumerian Where to find 3D content - poly.google.comvr.google.com/blocks Art installation in Zurich - Birdly - http://iad.zhdk.ch/en/projects/birdly/ To learn more visit www.thisdot.co Follow today's members on twitter! @Ladyleet, @Benlesh, @AysSomething, @g33konaut, @moderndotweb Listen to more podcasts at http://moderndotweb.com
--- Support this podcast: https://anchor.fm/angularair/support
In this Modern Web Podcast Tracy Lee (@ladyleet) and Ben Lesh (@benlesh) speak with guests Jake Archibald (@jaffathecake) and Jay Phelps (@_jayphelps) to talk about upcoming proposals in TC39 and WHATWG. Proposals discussed:EventTarget Observable Proposal in WHATWGObservable Proposal in TC39 https://github.com/tc39/proposal-observable BigInt Proposal in TC39https://github.com/tc39/proposal-bigint Structure Cloning in WHATWGhttps://github.com/whatwg/html/issues/793 Pipeline operator in TC39https://github.com/tc39/proposal-pipeline-operator Other topics:How to get involved if you care about a proposalWhat Ben looks like with yogurt on his noseTracy’s BF said “let’s git committed!" To learn more visit www.thisdot.co Follow us on Twitter @moderndotweb http://moderndotweb.com
In this Modern Web podcast 4 JavaScripters discuss WebAssembly. Sean Larkin (@thelarkinn), core team member webpack Jay Phelps (@_jayphelps), co-author redux-observable, wasm enthusiast, compiler freak Tracy Lee (@ladyleet), RxJS core team, Google Developer Expert, co-founder This Dot Labs Ben Lesh (@benlesh), RxJS core team, engineer at Google, RxWorkshop Topics covered: - Should you care about WebAssembly?- How is webpack involved with WebAssembly?- What can you do now with wasm?- How is the wasm spec being formed and advancing?- How can you get involved with wasm? Listen to more podcasts at http://moderndotweb.com or find more events, content, and more at http://thisdot.co
Tracy Lee: @ladyleet | ladyleet.com Ben Lesh: @benlesh | medium.com/@benlesh Show Notes: 00:50 - What is This Dot? 03:26 - The RxJS 5.5.4 Release and Characterizing RxJS 05:14 - Observable 07:06 - Operators 09:52 - Learning RxJS 11:10 - Making RxJS Functional Programming Friendly 12:52 - Lettable Operators 15:14 - Pipeline Operators 21:33 - The Concept of Mappable 23:58 - Struggles While Learning RxJS 33:09 - Documentation 36:52 - Surprising Uses of Observables 40:27 - Weird Uses of RxJS 45:25 - Announcements: WHATWG to Include Observables and RxJS 6 Resources: this.media RxJS RX Workshop Ben Lesh: Hot vs Cold Observables learnrxjs.io RxMarbles Jewelbots Transcript: CHARLES: Hello everybody and welcome to The Frontside Podcast, Episode 91. My name is Charles Lowell, a developer here at The Frontside and your podcast host-in-training. Joining me today on the podcast is Elrick Ryan. Hello, Elrick. ELRICK: Hey, what's up? CHARLES: Not much. How are you doing? ELRICK: I'm great. Very excited to have these two folks on the podcast today. I feel like I know them… CHARLES: [Laughs] ELRICK: Very well, from Twitter. CHARLES: I feel like I know them well from Twitter, too. ELRICK: [Laughs] CHARLES: But I also feel like this is a fantastic company that is doing a lot of great stuff. ELRICK: Yup. CHARLES: Also not in Twitter. It should be pointed out. We have with us Tracy Lee and Ben Lesh from This Dot company. TRACY: Hey. CHARLES: So first of all, why don't we start, for those who don't know, what exactly is This Dot? What is it that you all do and what are you hoping to accomplish? TRACY: This Dot was created about a year ago. And it was founded by myself and Taras who work on it full-time. And we have amazing people like Ben, who's also one of our co-founders, and really amazing mentors. A lot of our friends, when they refer to what we actually do, they like to call it celebrity consulting. [Laughter] TRACY: Which I think is hilarious. But it's basically core contributors of different frameworks and libraries who work with us and lend their time to mentor and consult with different companies. So, I think the beautiful part about what we're trying to do is bring together the web. And we sort of do that as well not only through consulting and trying to help people succeed, but also through This Dot Media where it's basically a big playground of JavaScripting all the things. Ben and I do Modern Web podcast together. We do RX Workshop which is RxJS training together. And Ben also has a full-time job at Google. CHARLES: What do they got you doing over there at Google? BEN: Well, I work on a project called Alkali which is an internal platform as a service built on top of Angular. That's my day job. CHARLES: So, you've been actually involved in all the major front-end frameworks, right, at some point? BEN: Yeah, yes. I got my start with Angular 1 or AngularJS now, when I was working as a web developer in Pittsburgh, Pennsylvania at a company called Aesynt which was formerly McKesson Automation. And then I was noticed by Netflix who was starting to do some Angular 1 work and they hired me to come help them. And then they decided to do Ember which is fine. And I worked on a large Ember app there. Then I worked on a couple of large React apps at Netflix. And now I'm at Google building Angular apps. CHARLES: Alright. BEN: Which is Angular 5 now, I believe. CHARLES: So, you've come the full circle. BEN: Yeah. Yeah, definitely. CHARLES: [Chuckles] I have to imagine Angular's changed a lot since you were working on it the first time. BEN: Yeah. It was completely rewritten. TRACY: I feel like Angular's the new Ember. CHARLES: Angular is the new Ember? TRACY: [Laughs] BEN: You think? TRACY: Angular is the new Ember and Vue is the new AngularJS, is basically. [Laughs] CHARLES: Okay. [Laughter] CHARLES: What's the new React then? BEN: Preact would be the React. CHARLES: Preact? Okay, or is Glimmer… BEN: [Laughs] I'm just… CHARLES: Is Glimmer the new React? BEN: Oh, sure. [Laughs] CHARLES: It's important to keep these things straight in your head. BEN: Yeah, yeah. CHARLES: Saves on confusion. TRACY: Which came first? [Chuckles] BEN: Too late. I'm already confused. CHARLES: So now, before the show you were saying that you had just, literally just released RxJS, was it 5.5.4? BEN: That's right. That's right. The patch release, yeah. CHARLES: Okay. Am I also correct in understanding that RxJS has kind of come to very front and center position in Angular? Like they've built large portions of framework around it? BEN: Yeah, it's the only dependency for Angular. It is being used in a lot of official space for Angular. For example, Angular Material's Data Table uses observables which are coming from RxJS. They've got reactive forms. The router makes use of Observable. So, the integration started kind of small which HTTPClient being written around Observable. And it's grown from there as people seem to be grabbing on and enjoying more the React programming side of things. So, it's definitely the one framework that's really embraced reactive programming outside of say, Cycle.js or something like that. CHARLES: Mmhmm. So, just to give a general background, how would you characterize RxJS? BEN: It's a library built around Observable. And Observable is a push-based primitive that gives you sets of events, really. CHARLES: Mmhmm. BEN: So, that's like Lodash for events would be a good way to put it. You can take anything that you can get pushed at you, which is pretty much value type you can imagine, and wrap it in an observable and have it pushed out of the observable. And from there, you have a set of things that you can combine. And you can concatenate them, you can filter them, you can transform them, you can combine them with other sets, and so on. So, you've got this ability to query and manipulate in a declarative way, events. CHARLES: Now, Observable is also… So, when Jay was on the podcast we were talking about Redux observable. But there was outside of the context of RxJS, it was just observables were this standalone entity. But I understand that they actually came from the RxJS project. That was the progenitor of observables even though there's talk of maybe making them part of the JavaScript spec. BEN: Yeah, that's right. That's right. So, RxJS as it stands is a reference implementation for what could land in JavaScript or what could even land in the DOM as far as an observable type. Observable itself is very primitive but RxJS has a lot of operators and optimizations and things written around Observable. That's the entire purpose of the library. CHARLES: Mmhmm. So, what kind of value-adds does it provide on top of Observable? If Observable was the primitive, what are the combinators, so to speak? BEN: Oh, right. So, similar to what Lodash would add on top of say, an iterable or arrays, you would have the same sorts of things and more inside of RxJS. So, you've got zip which you would maybe have seen in Lodash or different means of combines. Of course, map and ‘merge map' which is like a flattening sort of operation. You can concatenate them together. But you also have these time-based things. You can do debouncing or throttling of events as they're coming over in observable and you create a new observable of that. So, the value-add is the ability to compose these primitive actions. You can take on an observable and make a new observable. We call it operators. And you can use those operators to build pretty much anything you can imagine as far as an app would go. CHARLES: So, do you find that most of the time all of the operators are contained right there inside RxJS? Or if you're going to be doing reactive programming, one of your tasks is going to be defining your own operators? BEN: No, pretty much everything you'd need will be defined within RxJS. There's 60 operators or so. CHARLES: Whoa, that's a lot. BEN: It's unlikely that someone's going to come up with one. And in fact, I would say the majority of those, probably 75% of those, you can create from the other 25%. So, some of the much more primitive operators could be used… TRACY: Which is sort of what Ben did in this last release, RxJS 5…. I don't know remember when you introduced the lettable operators but you… BEN: Yeah, 5.5. TRACY: Implemented [inaudible] operators. BEN: Yeah, so a good portion of them I started implementing in terms of other operators. CHARLES: Right. So, what was that? I didn't quite catch that, Tracy. You said that, what was the operator that was introduced? TRACY: So, in one of the latest releases of RxJS, one of the more significant releases where pipeable operators were introduced, what Ben did was he went ahead and implemented a lot of operators that were currently in the library in terms of other operators, which was able to give way to reduce the size of the library from, I think it was what, 30KB bundled, gzipped, and minified, to about 30KB, which was about 60 to 70% of the operators. Right, Ben? BEN: Yeah. So, the size reduction was in part that there's a lot of factors that went into the size reduction. It would be kind of hard to pin it down to a specific operator. But I know that some of the operators like the individual operators themselves, by reimplementing reduce which is the same as doing as scan and then take last, implementing it in terms of that is going to reduce the size of it probably 90% of that one particular file. So, there's a variety of things like that that have already started and that we're going to continue to do. We didn't do it with every operator that we could have. Some operators are very, very common and consequently we want them to be as optimized as possible. For example, map. You can implement map in terms of ‘merge map' but it would be very slow to do so. It might be smaller but it would be slower. We don't want that. So, there are certain areas we're always going to try to keep fairly a hot path to optimize them as much as possible. But in other spots like reduce which is less common and isn't usually considered to be a performance bottleneck, we can cut some corners. Or ‘to array' or other things like that. CHARLES: Mmhmm. TRACY: And I think another really interesting thing is a lot of people when learning RxJS, they… it's funny because we just gave an RX Workshop course this past weekend and the people that were there just were like, “Oh, we've heard of RxJS. We think it's a cool new thing. We have no plans to implement it in real life but let's just play around with it and let me learn it.” I think as people are starting to learn RxJS, one of the things that gets them really overwhelmed is this whole idea that they're having to learn a completely new language on top of JavaScript or what operators to use. And one of our friends, Brian Troncone who is on the Learning Team, the RxJS Learning Team, he pulled up the top 15 operators that were most commonly searched on his site. And some of them were ‘switch map', ‘merge map', ‘fork join', merge, et cetera. So, you can sort of tell that even though the library has quite a few… it's funny because Ben, I think the last RX Workshop you were using pairs and you had never used it before. BEN: Yeah. TRACY: So, it's always amusing for me how many people can be on the core team but have never implemented RxJS… CHARLES: [Laughs] TRACY: A certain way. BEN: Right. Right, right, right. CHARLES: You had said one of the recent releases was about making it more friendly for functional programming. Is that a subject that we can explore? Because using observables is already pretty FP-like. BEN: What it was before is we had dot chaining. So, you would do ‘dot map' and then call a method and then you get an observable back. And then you'd say ‘dot merge' and then you'd call a method on that, and so on and so forth. Now what you have is kind of a Ramda JS style pipe function that just takes a comma-separated list of other functions that are going to act upon the observable. So, it reads pretty much the same with a little more ceremony around it I guess. But the upside is that you can develop your operators as just higher-order functions. CHARLES: Right. And you don't have to do any monkey-patching of prototypes. BEN: Exactly, exactly. CHARLES: Because actually, okay, I see. This is actually pretty exciting, I think. Because we actually ran into this problem when we were using Redux Observable where we wanted to use some operators that were used by some library but we had to basically make a pull request upstream, or fork the upstream library to include the operators so that we could use them in our application. It was really weird. BEN: Yeah. CHARLES: The reason was because it was extending the observable prototype. BEN: Yeah. And there's so many… and that's one way to add that, is you extend the observable prototype and then you override lift so you return the same type of observable everywhere. And there are so many things that lettable operators solved for us. For example… CHARLES: So, lettable operators. So, that's the word that Tracy used and you just used it. What are lettable operators? BEN: Well, I've been trying to say pipeable and get that going instead of lettable. But basically there's an operator on RxJS that's been there forever called let. And let is an operator and what you do is you give it a function. And the function gives you the source observable and you're expected to return a new observable. And the idea is that you can then write a function elsewhere that you can then compose in as though it were an operator, anywhere you want, along with your other dot-chained operators. And the realization I had a few months ago was, “Well, why don't we just make all operators like this?” And then we can use functional programming to compose them with like a reduce or whatever. And that's exactly what the lettable operators are. And that's why I started calling them lettable operators. And I kind of regret it now, because so many people are saying it and it confuses new people. Because what in the world does lettable even mean? CHARLES: Right. [Laughs] BEN: So, they are pipeable operators or functional operators. But the point is that you have a higher-order function that returns a function of a specific shape. And that function shape is, it's a function that receives an observable and returns an observable, and that's it. So, basically it's a function that transforms an observable into a new observable. That's all an operator. That's all an operator's ever been. It's just this is in a different flavor. CHARLES: Now, I'm curious. Why does it do an observable into an observable and not a stream item into an observable? Because when you're actually chaining these things together, like with a map or with a ‘flat map' or all these things, you're actually getting an individual item and then returning an observable. Well, I guess in this case of a map you're getting an item and returning an item. But like… BEN: Right, but that's not what the entire operation is. So, you've got an operation you're performing whenever you say, if you're to just even dot-chain it, you'd say ‘observable dot map'. And when you say ‘dot map', it returns a new observable. And then you say ‘dot filter' and it returns another new observable. CHARLES: Oh, gotcha, gotcha, gotcha. Okay, yeah, yeah, yeah. Yeah, yeah. BEN: So, this function just embodies that step. CHARLES: I see, I see. And isn't there some special… I feel like there's some proposal for some special JavaScript syntax to make this type of chaining? BEN: Yeah, yeah, the pipeline operator. CHARLES: Okay. BEN: I don't know. I think that's still at stage one. I don't know that it's got a lot of headway. My sources and friends that are in the TC39 seem to think that it doesn't have a lot of headway. But I really think it's important. Because if you look at… the problem is we're using a language where the most common use case is you have to build it, get the size as small as possible because you need to send it over the wire to the browser. And understandably, browsers don't want to implement every possible method they could on say, Array, right? CHARLES: Mmhmm, right. BEN: There's a proposal in for ‘flat map'. They could add zip to Array. They could add all sorts of interesting things to Array just by itself. And that's why Lodash exists, right? CHARLES: Right. BEN: Is because not everything is on Array. And then so, the onus is then put on the community to come up with these solutions and the community has to build libraries that have these constraints in size. And what stinks about that is then you have say, an older version of Lodash where you'd be like, “Okay, well it has 36 different functions in it and I'm only using 3 of them. And I have to ship them all to the browser.” CHARLES: Mmhmm. BEN: And that's not what you want. So, then we have these other solutions around tree-shaking and this and that. And the real thing is what you want is you want to be able to compose things left to right and you want to be able to have these functions that you can use on a particular type in an ad hoc way. And there's been two proposals to try to address this. One was the ‘function bind' operator, CHARLES: Mmhmm. BEN: Which is colon colon. And what that did is it said, “You can use this function as a method, as though it were a method on an object. And we'll make sure that the ‘this' inside that function comes from the instance that's on the left-hand side of colon colon.” CHARLES: Right. BEN: That had a bunch of other problems. Like there's some real debate I guess on how they would tie that down to a specific type. So, that kind of fell dead in the water even though it had made some traction. And then the pipeline operator is different. And then what it says is, “Okay, whatever is on the…” And what it looks like is a pipe and a greater than right next to each other. And whatever's on the left-hand side of that operand gets passed as the first argument to the function on the right-hand side of that operand. CHARLES: Mmhmm. BEN: And so, what that means is for the pipeable operators, instead of having to use a pipe method on observable, you can just say, “instance of observable, pipeline operator and an operator, and then pipeline operator, and then the Rx operator, and then pipeline operator and the Rx operator, and so on.” And it would just be built-in. And the reason I think that JavaScript really needs it is that means that libraries like Lodash can be written in terms of simple functions and shipped piece-meal to the browser exactly as you need them. And people would just use the pipeline operator to use them, instead of having to wrap something in a big object so you can dot-chain things together or come up with your own functional pipe thing like RxJS had to. CHARLES: Right. Because it seems it happens again and again, right? Lodash, RxJS, jQuery. You just see this pattern of chaining, which is, you know… BEN: Yeah, yeah. People want chaining. People want left to right composition. CHARLES: Mmhmm. BEN: And it's problematic in a world where you want to shake off as much unused garbage as possible. And the only way to get dot chaining is by augmenting a prototype. There's all sorts of weird problems that can come with that. And so, the functional programming approach is one method. But then people look at it and they say, “Ooh, yuck. I've got to wrap things in a function named pipe. Wouldn't it be nicer if there was just some syntax to do this?” And yeah, it would be nicer. But I have less control over that. CHARLES: Right. But the other alternative is to have right to left function composition. BEN: Right, yeah. CHARLES: But there's not any special syntax for that, either. BEN: Not very readable. CHARLES: Yeah. BEN: So, you just wrap everything. And the innermost call is the first one and then you wrap it in another function and you wrap that in another function, and so on. Yeah, that's not [inaudible]. But I will say that the pipe function itself is pretty simple. It's basically a function that takes a rest of arguments that are all functions. CHARLES: Mmhmm. BEN: And so, you have this array of functions and you just reduce over it and call them. Well, you return a function. So, it's a higher function. You return a function that takes an argument then you reduce over the functions that came in as arguments and you call each one of them with whatever result was from the previous. CHARLES: Right. Like Tracy mentioned in the pre-show, I'm an aspiring student of functional programming. So, would this be kind of like a monoid here where you're mashing all these functions together? Is your empty value? I'm just going to throw it out there. I don't know if it's true or not, but that's my conjecture. BEN: Yes. Technically, it's a monoid because it wouldn't work unless it was a monoid. Because monoids, I believe the category theory I think for monoid is that monoids can be concatenated because they definitely have an end. CHARLES: Right. BEN: So, you would not be able to reduce over all those functions and build something with that, like that, unless it was a monoid. So yeah, the fact that there's reduction involved is a cue that it's a monoid. CHARLES: Woohoo! Alright. [Laughter] CHARLES: Have you found yourself wanting to apply some of these more “rigorous” formalisms that you find out there in the development of RxJS or is that just really a secondary concern? BEN: It's a secondary concern. It's not something that I like. It's something I think about from time to time, when really, debating any kind of heavy issue, sometimes it's helpful. But when it comes to teaching anybody anything, honestly the Haskell-isms and category theory names, all they do is just confuse people. And if you tell somebody something is a functor, they're like, “What?” And if you just say it's mappable, they're like, “Oh, okay. I can map that.” CHARLES: [Laughs] Right, right. BEN: And then the purists would be like, “But they're not the same thing.” And I would be like, “But the world doesn't care. I'm sorry.” CHARLES: Yeah, yeah. I'm kind of experiencing this debate myself. I'm not quite sure which side I fall on, because on the one hand it is arbitrary. Functor is a weird name. But I wish the concept of mappable existed. It does, but I feel like it would be handy if people… because there's literally five things that are super handy, right? Like mappable, if we could have a name for monoid. But it's like, really, you just need to think in terms of these five constructs for 99% of the stuff that you do. And so, I always wonder, where does that line lie? And how… mappable, is that really more accessible than functor? Or is that only because I was exposed to the concept of mapping for 10 years before I ever heard the F word. BEN: Yes, and yes. I mean, that's… CHARLES: [Laughs] BEN: Things that are more accessible are usually more accessible because of some pre-given knowledge, right? What works in JavaScript probably isn't going to work in Haskell or Scala or something, right? CHARLES: Mmhmm. BEN: If someone's a Java developer, certain idioms might not make sense to them that come from the JavaScript world. CHARLES: Right. But if I was learning like a student, I would think mappable, I'd be thinking like, I would literally be thinking like Google Maps or something like that. I don't know. BEN: Right, right. I mean, look at C#. C#, a mapping function is always going to be called select, right, because that's C#. That's their idiom for the same thing. CHARLES: Select? BEN: Yeah. CHARLES: Really? BEN: Yeah, select. So, they'll… CHARLES: Which in Ruby is like find. BEN: Yeah. there's select and then, what's the other one, ‘select many' or something like that. [Chuckles] BEN: So, that's C#. CHARLES: Oh, like it's select from SQL. Okay. BEN: Yeah, I think that's kind of where it came from because people had link and then they had link to SQL and then they're like, well I want to do this with regular code, with just using some more… less nuanced expressions. So, I want to be able to do method calls and chain those together. And so, you end up with select functions. And I think that that exists even in Rx.NET, although I haven't used Rx.NET. CHARLES: Hmm, okay. ELRICK: So, I know you do a lot of training with Rx. What are some of the concepts that people struggle with initially? TRACY: I think when we're teaching RX Workshop, a lot of the people sort of… I'll even see senior level people struggle with explaining it, is the difference between observables and observers and then wrapping their head around the idea that, “Hey, observables are just functions in JavaScript.” So, they're always thinking observables are going to do something for you. Actually, it's not just in Angular but also in React, but whenever someone's having issues with their Rx applications, it's usually something that they're like nesting observables or they're not subscribing to something or they've sort of hot-messed themselves into a tangle. And I'm sure you've debugged a bunch of this stuff before. The first thing I always ask people is, “Have you subscribed?” Or maybe they're using an Angular… they're using pipes async but they're also calling ‘dot subscribe' on their observable. BEN: Yeah. So, like in Angular they'll do both. Yeah. There's that. I think that, yeah, that relates to the problem of people not understanding that observables are really just functions. I keep saying that over and over again and people really don't seem to take it to heart for whatever reason. [Chuckles] BEN: But you get an observable and when you're chaining all those operators together, you're making another observable or whatever, observables don't do anything until you subscribe to them. They do nothing. CHARLES: Shouldn't they be called like subscribable? BEN: Yes. [Chuckles] BEN: They probably should. But we do hand them an observer. So, you are observing something. But the point being is that they don't do anything at all until you subscribe to them. And in that regard, they're like functions, where functions don't do anything unless you call them. So, what ends up happening with an observable is you subscribe to it. You give it an observer, three callbacks which are then coerced into an observer. And it takes that observer and it hands it to the body of this observable definition and literally has an observer inside of there. And then you basically execute that function synchronously and do things, whatever those things are, to set up some sort of observation. Maybe you spin up a WebSocket and tie into some events on it and call next on the observer to get values out of your observable. The point being that if you subscribe to an observable twice, it's the same thing as calling a function twice. And for some reason, people have a hard time with that. They think, if I subscribe to the observable twice, I've only called the function once. CHARLES: I experienced this confusion. And I remember the first time that that… like, I was playing with observables and the first time I actually discovered that, that it was actually calling my… now what do you call the function that you pass to the constructor that actually does, that calls next or that gets passed the observer? TRACY: [Inaudible] BEN: I like to call it an initialization function or something. But the official name from the TC39 proposal is subscriber function. CHARLES: Subscriber function. So, like… BEN: Yeah. CHARLES: I definitely remember it was one of those [makes explosion sound] mind-blowing moments when I realized when I call my subscribe method, the entire observable got run from the very beginning. But my intuition was that this is an object. It's got some shared state, like it's this quasar that I'm now observing and I'm seeing the flashes of light coming off of it. But it's still the same object. You think of it as having yeah, not as a function. Okay. No one ever described it to me as just a function. But I think I can see it now. ELRICK: Yeah, me neither. CHARLES: But yeah, you think of it in the same way that most people think of objects, as like, “I have this object. I have a reference to it.” Let observable equal new observable. It's a single thing. It's a single identity. And so, that's the thing that I'm observing. It's not that I'm invoking this observable to observe things. And I think that's, yeah, that's a subtle nuance there. I wish I had taken y'all's course, I guess is what I'm saying. ELRICK: Yeah. BEN: Yeah. Well, I've done a few talks on it. CHARLES: [Laughs] BEN: I always try to tell people, “It's just a function. It's just a function.” I think what happens to a lot of people too is there's the fact that it's an object. But I think what it is, is people's familiarity with promises does this. Because promises are always multicast. They are always “hot”. And the reason for this is because they're eager. So, by the time you have a promise, whatever is producing value to the promise has already started. And that means that they're inherently a multicast. CHARLES: Right. BEN: So, people are used to that behavior of, I can ‘then' off of this promise and it always means one thing. And it's like, yeah, because the one thing has nothing to do with the promise. It wasn't [Chuckles] CHARLES: Right. BEN: This promise is just an interface for you to view something that happened in the past, where an observable is more low-level than that and more simple than that. It just states, “I'm a function that you call. I'm going to be able to do anything a function can do. And by the way, you're giving me an observer and I'm going to do some stuff with that too and notify you via this observer that you handed me.” Because of that you could take an observable and close over something that had already started. Say you had a WebSocket that was already running. You could create a new observable and just like any function, close over that, externally create a WebSocket. And then everyone that subscribes to that observable is tying an observer to that same WebSocket. Then you're multicast. Then you're “hot”. ELRICK: [Inaudible] CHARLES: Right. So, I was going to say that's the distinction that Jay was talking about. He was talking about we're going to just talk about… he said at the very beginning, “We're just going to talk about hot observable.” ELRICK: Yup. CHARLES: But even a hot observable is still theoretically evaluating every single time you subscribe. You're getting a new observable. You're evaluating that observable afresh each time. It just so happens that in the lexical scope of that observable subscriber function, there is this WebSocket? BEN: Yeah. So, it's the same thing. Imagine you wrote a function that when you called it created a new WebSocket and then… say, you wrote a new function that you gave an observer object to, right? An observer object has next, error, and complete. And in that function, when you called it, it created a new WebSocket and then it tied the ‘on message' and ‘on close' and whatever to your observer's next method and your observer's error message and so on. When you call that function, you would expect a new WebSocket to be created every single time. Now, let's just say alternately you create a WebSocket and then you write a new function that that function closes over that WebSocket. So, you reference the WebSocket that you externally created inside of your function. When you call that function, it's not going to create a new WebSocket every time. It's just closing over it, right? So, even though they both are basically doing the same thing, now the latter one of those two things is basically a hot observable and the former is a cold observable. Because one is multicast which is, “I'm sharing this one WebSocket with everybody,” and the other one is unicast which is, “I am going to create a new WebSocket for each person that calls me.” And that's the [inaudible] people have a hard time with. CHARLES: Right. But really, it's just a matter of scope. BEN: Yeah. The thing people have a hard time with, with observables, is not realizing that they're actually just functions. CHARLES: Yeah. I just think that maybe… see, when I hear things like multicast and unicast, that makes me think of shared state, whereas when you say it's just a matter of scope, well then I'm thinking more in terms of it being just a function. It just happens that this WebSocket was already [scoped]. BEN: Well, shared state is a matter of scope, right? CHARLES: Yes, it is. It is. Oh, sorry. Shared state associated with some object identity, right? BEN: Right. CHARLES: But again, again, it's just preconceptions, really. It's just me thinking that I've had to manage lists of listeners and have multicast observers and single-cast observers and having to manage those lists and call notify on all of them. And that's really not what's happening at all. BEN: Yeah. Well, I guess the real point is observables can have shared state or they could not have shared state. I think the most common version and the most composable version of them, they do not have any shared state. It's just one of those things where just like a function can have shared state or it could be pure, right? There's nothing wrong with either one of those two uses of a function. And there's nothing wrong with either one of those two uses of Observable. So, honest to god, that is the biggest stumbling block I think that I see people have. That and if I had to characterize it I would say fear and loathing over the number of operators. People are like… CHARLES: [Chuckles] BEN: And they really think because everyone's used to dealing with these frameworks where there's an idiomatic way to do everything, they think there's going to be an RxJS idiomatic way to do things. And that's just patently false. That's like saying there's an idiomatic way to use functions. There's not. Use it however it works. The end. It's not… CHARLES: Mmhmm, mmhmm. BEN: You don't have to use every operator in a specific way. You can use it however works for you and it's fine. ELRICK: I see that you guys are doing some fantastic work with your documentation. Was that part of RxJS 2.0 docs? TRACY: I was trying to inspire people to take on the docs initiative because I think when I was starting to learn RxJS I would get really frustrated with the docs. BEN: Yeah. TRACY: I think the docs are greatly documented but at the same time if you're not a senior developer who understands Rx already, then it's not really helpful. Because it provides more of a reference point that the guys can go back and look at, or girls. So anyways, after many attempts of trying to get somebody to lead the project I just decided to lead the project myself. [Laughter] TRACY: And try to get… the community is interesting because I think because the docs can be sometimes confusing… Brian Troncone created LearnRxJS.io. There's these other visualization projects like RxMarbles, RxViz, et cetera. And we just needed to stick everybody together. So, it's been a project that I think has been going on for the past two months or so. We have… it's just an Angular app so it's probably one of the most easiest projects to contribute to. I remember the first time I tried to contribute to the Ember docs. It literally took me an hour to sit there with a learning team, Ember Learning Team member and… actually, maybe it was two hours, just to figure out how the heck… like all the things I had to download to get my environment set up so that I could actually even contribute to the darn documentation. But with the Rx, the current RxJS docs right now is just an Angular app. You can pull it down. It's really easy. We even have people who are just working on accessibility, which is super cool, right? So, it's a very friendly place for beginners. BEN: I'm super pleased with all the people that have been working on that. Brian and everybody, especially on the accessibility front. Jen Luker [inaudible] came in and voluntarily… she's like the stopgap for all accessibility to make sure everything is accessible before we release. So, that's pretty exciting. TRACY: Yeah. ELRICK: Mmhmm. TRACY: So funny because when me and Jen started talking, she was talking about something and then I was like, “Oh my god, I'm so excited about the docs.” She's like, “I'm so excited, too! But I don't really know why I'm excited. But you're excited, so I'm excited. Why are you excited?” [Laughter] TRACY: I was like, “I don't know. But I'm excited, too!” [Chuckles] TRACY: And then all of a sudden we have accessibility. [Laughs] ELRICK: Mmhmm. Yeah, I saw some amazing screenshots. Has the new docs, have they been pushed up to the URL yet? TRACY: Nah, they are about to. We were… we want to do one more accessibility run-through before we publish it. And then we're going to document. We want to document the top 15 most viewed operators. But we should probably see that in the next two weeks or so, that the new docs will be… I mean, it'll say “Beta, beta, beta” all over everything. But actually also, some of our friends, [Dmitri] from [Valas] Software, he is working on the translation portion to make it really easy for people to translate the docs. CHARLES: Ah. TRACY: So, a lot of that came from the inspiration from the Vue.js docs. we're taking the versioning examples that Ember has done with their docs as inspiration to make sure that our versioning is really great. So, it's great that we can lend upon all the other amazing ideas in the industry. ELRICK: Oh, yeah. CHARLES: Yeah, it's fantastic. I can't wait to see them. ELRICK: Yeah, me neither. The screenshots look amazing. I was like, “Wow. These are some fabulous documentation that's going to be coming out.” I can't wait. TRACY: Yeah. Thank you. CHARLES: Setting the bar. ELRICK: Really high. [Laughter] CHARLES: Actually, I'm curious. Because observables are so low-level, is there some use of them that… what's the use of them that you found most surprising? Or, “Whoa, this was a crazy hack.” BEN: The weirdest use of observables, there's been quite a few odd ones. One of the ones that I did one time that is maybe in RxJS's wheelhouse, it was just that RxJS already existed. So, I didn't want to pull in another transducer library, was using RxJS as a transducer. Basically… in Netflix we had a situation where we had these huge, huge arrays of very large objects. And if you try to take something like that and then map it and then filter it and then map it and then filter it, we're using Array map and filter, what ends up happening is you create all sorts of intermediary arrays in-memory. And then garbage collection has to come through and clean that up. And that locks your thread. And over time, we were experiencing slowness with this app. And it would just build up until eventually it ground to a halt. And I used RxJS because it was an available tool there to wrap these arrays in an observable and then perform operations on them step-by-step, the same map, filter, and so on. But when you do that, it doesn't create intermediary arrays because it passes each value along step to step instead of producing an entire array and then doing another step and producing an entire array, and so on. So… CHARLES: So, will you just… BEN: It saved garbage collection and it increased the performance of the app. But that's just in an extreme case. I would never do that with just regular arrays. If anything, it was because it was huge, huge arrays of very large objects. CHARLES: So, you would create an observable our of the array and then just feed each element into the observable one at a time? BEN: Well, no. If you say ‘observable from' and you give it an array, that's basically what it does. CHARLES: Okay. BEN: It loops over the array and nexts those values out of the array synchronously. CHARLES: I see, I see. BEN: So, it's like having a for loop and then inside of that for loop saying, “Apply the map. Apply the filter,” whatever, to each value as they're going through. But when you look at it, if you had array map, filter, reduce, it's literally just taking the first step and saying ‘observable from' and wrapping that array and then the rest of it's still the same. CHARLES: Right. Yeah. No, that's really cool. BEN: That was a weirder use of it. I've heard tell of other things where people used observables to do audio synchronization, which is pretty interesting. Because you have to be very precise with audio synchronization. So, hooking into some of the Web Audio APIs and that sort of thing. That's pretty interesting. The WebSocket multiplexing is something I did at Netflix that's a little bit avant-garde for observable use because you essentially have an observable that is your WebSocket. And then you create another observable that closes over that observable and sends messages over the WebSocket for what you're subscribed to and not subscribed to. And it enables you to very easily retry connections and these sorts of things. I did a whole talk on that. That one's pretty weird. CHARLES: Yeah. Man, I [inaudible] to see that. BEN: But in the general use case, you click a button, you make an AJAX request, and then you get that back and maybe you make another AJAX request. Or like drag and drop and these sorts of things where you're coordinating multiple events together, is the general use case. The non-weird use case for RxJS. Tracy does weird stuff with RxJS though. [Laughter] CHARLES: Yeah, what's some weird uses of RxJS? TRACY: I think my favorite thing to do right now is to figure out how many different IoT-related things I can make work with RxJS. So, how many random things can I connect to an application using that? BEN: Tracy's projects are the best. They're so good. [Laughter] TRACY: Well, Ben and I created an application where you can take pictures of things using the Google Image API and it'll spit back a set of puns for you. So, you take a picture of a banana, it'll give you banana puns. Or you can talk to it using the speech recognition API. My latest thing is I really want to figure out how to… I haven't figured out if Bluetooth Low Energy is actually enabled on Google Home Minis. But I want to get my Google Home Mini to say ‘booty'. [Inaudible] [Laughter] CHARLES: RxJS to the rescue. [Laughter] BEN: Oh, there was, you remember Ng-Cruise. We did Ng-Cruise and on there, Alex Castillo brought… TRACY: Oh, that was so cool. BEN: All sorts of interesting… you could read your brain waves. Or there was another one that was, what is it, the Microsoft, that band put around your wrist that would sense what direction your arm was in and whether or not your hand was flexed. And people… TRACY: Yeah, so you could flip through things. BEN: Yeah. And people were using reactive programming with that to do things like grab a ball on the screen. Or you could concentrate on an image and see if it went blurry or not. ELRICK: Well, for like, Minority Report. BEN: Oh, yeah, yeah. Literally, watching a machine read your mind with observables. That was pretty cool. That's got to be the weirdest. TRACY: Yeah, or we had somebody play the piano while they were wearing one of the brainwave… it's called the OpenBCI project is what it is. And what you can do is you can actually get the instructions to 3D print out your own headset and then buy the technology that allows you to read brain waves. And so with that, it's like… I mean, it was really awesome to watch her play the piano and just see how her brain waves were going super crazy. But there's also these really cool… I don't know if you guys have heard of Jewelbots, but they're these programmable friendship bracelets that are just little Arduino devices that light up. I have two of them. I haven't even opened them. CHARLES: [Laughs] TRACY: I've been waiting to play with them with you. I don't know what we're going to do, but I just want to send you lights. Flashing lights. [Laughter] TRACY: Morse code ask you questions about RxJS while you're working. [Laughter] CHARLES: Yeah. Critical bug. Toot-toot-toot-too-too-too-too-toot-toot. [Laughter] CHARLES: RxJS Justice League. TRACY: That would actually be really fun. [Laughter] TRACY: That would be really fun. I actually really want to do that. But… CHARLES: I'm sure the next time we talk, you will have. TRACY: [Laughs] Yes. Yes, yes, yes, I know. I know. we'll do it soon. We just need to find some time while we're not going crazy with conferences and stuff like that. CHARLES: So, before we head out, is there any upcoming events, talks, releases, anything that we ought to be, we or the listeners, ought to be aware of? TRACY: Yeah, so one of the things is that Ben and I this weekend actually just recorded the latest version of RX Workshop. So, if you want to learn all about the latest, latest, newest new, you can go ahead and take that course. We go through a lot of different things like multiplex WebSockets, building an application. Everywhere from the fundamentals to the more real world implementations of RxJS. BEN: Yeah. Even in the fundamentals area, we've had friends of ours that are definitely seasoned Rx veterans come to the workshop. And most of them ask the most questions while talking about the fundamentals. Because I tend to dig into, either deep into the internals or into the why's and how's thing. Why and how things work. Even when it comes to how to subscribe to an observable. Deep detailed information about what happens if you don't provide an error handler and certain cases and how that's going to change in upcoming versions, and why that's changing in upcoming versions, and what the TC39's thoughts are on that, and so on and so forth. So, I try to get into some deeper stuff and we have a lot of fun. And we tend to be a little goofier at the workshops from time to time than we were in this podcast. Tracy and I get silly when we're together. TRACY: It's very true. [Laughter] TRACY: But I think also, soon I think there are people that are going to be championing an Observable proposal on what [inaudible]. So, aside from the TC39 Observable proposal that's currently still at stage one, I don't know Ben if you want to talk a little bit about that. BEN: Oh, yeah. So, I've been involved in conversations with folks from Netflix and Google as well, Chrome team and TC39 members, about getting the WHATWG, the ‘what wig', they're a standards body similar to W3C, to include observables as part of the DOM. The post has not been made yet. But the post is going to be made soon as long as everybody's okay with it. And what it boils down to is the idea of using observables as part of event targets. An event target is the API we're all familiar with for ‘add event listener', ‘remove event listener'. So, pretty much anywhere you'd see those methods, there might also someday be an on method that would return an observable of events. So, it's really, really interesting thing because it would bring at least the primitives of reactive programming to the browser. And at the very least it would provide maybe a nicer API for people to subscribe to events coming from different DOM elements. Because ‘add event listener' and ‘remove event listener' are a little unergonomic at times, right? CHARLES: Yeah. They're the worst. BEN: Yeah. CHARLES: That's a very polite way of putting it. BEN: [Chuckles] So, that's one thing that's coming down the pipe. Other things, RxJS 6 is in the works. We recently tied off 5.5 in a stable branch. And master is now our alpha that we're working on. So, there's going to be a lot of refactoring and changes there, trying to make the library smaller and smaller. And trying to eliminate some of the footprints that maybe people had in previous versions. So, moving things around so people aren't importing stuff that were meant to be implementation details, reducing the size of the library, trying to eliminate some bloat, that sort of thing. I'm pretty excited about that. But that's going to be in alpha ongoing for a while. And then hopefully we'll be able to move into beta mid first quarter next year. And then when that'll be out of beta, who knows? It all depends on how well people like the beta and the alpha, right? CHARLES: Alright. Well, so if folks do want to follow up with y'all either in regards to the course or to upcoming releases or any of the other great stuff that's coming along, how would they get in touch with y'all? TRACY: You can find me on Twitter @ladyleet. But Ben is @BenLesh. RX Workshop is RXWorkshop.com. I think in January we're going to be doing state of JavaScript under This Dot Media again. So, that's where all the core contributors of different frameworks and libraries come together. So, we'll definitely be giving a state of RxJS at that time. And next year also Contributor Days will be happening. So, if you go to ContributorDays.com you can see the previous RxJS Contributor Days and figure out how to get involved. So, we're always open and happy and willing to teach everybody. And again, if you want to get involved it doesn't matter whether you have little experience or lots of experience. We are always willing to show you how you can play. BEN: Yeah. You can always find us on Twitter. And don't forget that if you don't find Tracy or I on Twitter, you can always message Jay Phelps on Twitter. That's important. @_JayPhelps. Really. TRACY: Yeah. [Laughter] BEN: You'll find us. CHARLES: [Chuckles] Look for Jay in the show notes. [Laughter] CHARLES: Alright. Well, thank you so much for all the stuff that y'all do, code and otherwise. And thank you so much Ben, thank you so much Tracy, for coming on the show. BEN: Thank you. CHARLES: Bye Elrick and bye everybody. If you want to reach out to us, you can always get in touch with us at @TheFrontside or send us an email at contact@frontside.io. Alright everybody, we'll see you next week.
Jay Phelps: @_jayphelps | jayphelps.com Show Notes: 01:25 - RxJS 10:09 - Observers 17:49 - Back Pressure 22:11 - Async Iterators and Generators 31:30 - Mapping Resources: The Observer Pattern Hot vs Cold Observables IxJS redux-observable Transcript: CHARLES: Hello everybody and welcome to The Frontside Podcast, Episode #84. My name is Charles Lowell, a developer here at the Frontside and your podcast host-in-training. With me today is Elrick Ryan. Hello, Elrick. ELRICK: Howdy. CHARLES: You and I have actually been on a roll lately, podcasting the hell out of these podcast. ELRICK: Yeah, I know. That is very true. CHARLES: It's been you and me but it's feeling great. It's good to have you on the show again. ELRICK: Yes, wonderful, man. Let's keep it rolling. CHARLES: All right. We will keep it rolling. Today, we are going to be talking about redux-observable and to help us understand and plumb this topic, we have someone who's very qualified to talk about it. Mr Jay Phelps, who in addition to having been the co-creator of redux-observable, also is on the core team of RxJS, which is a fascinating library on which it's based for many years and is currently a senior software engineer at Netflix. Welcome to the podcast, Jay. JAY: Hey! Good morning, everyone. I guess it's not probably morning to the people listening but good morning to you all. Thanks for having me. CHARLES: I'm excited about it. I know that kind of starting with the fundamentals, RxJS is something that was on my radar for a few years and it definitely [inaudible] once we started using redux-observable but the whole concept, I often feel like the world kind of is turned upside down when I'm working with observables, when I'm working with RxJS and I'm curious, how did you come to be a part of that project and what are the things that you use it to solve? Why did the solutions that you generated shake out that way? JAY: Sure. I actually was not introduced to Rx until I started working at Netflix. Netflix does have a fairly solid reputation for their usage of Rx, not just in the JavaScript world but also in the server world. Netflix wrote the original implementation of RxJava and it's used heavily on our backend systems. CHARLES: For some reason, I had this impression and maybe I'm mistaken that Rx originally came out of Microsoft. JAY: Let me continue with the story. It's confusing and I can actually take a step back and clarify that point in particular. Rx itself was originally came from Rx.net, which was indeed created by Microsoft many, many, many, many years ago. I don't know the exact date. I think it was at least 10 years ago. They, at the same time created or about the same time, Matt Podwysocki who was working at Microsoft and still is working at Microsoft, created Rx.net and RxJS. Then many years had passed and originally, it wasn't as popular as it got in the coming years. After several years, some employees from Microsoft ended up coming to Netflix. Jafar Husain is one of those employees. He came from Microsoft to Netflix and he brought that Rx knowledge and that advocacy. Rx is very ingrained in the Netflix culture and is used a lot by various teams for various purposes. Then when I joined Netflix and I got really exposed to it. One of my coworkers at the time, Ben Lesh was asked by several people at Netflix to consider and look into rewriting RxJS. At the time, the version was RxJS 2.0 and while it was great, we had some specific requirements for our website and some of our other applications that we were hoping for a better performance, smaller bundle size and better debugability and -- CHARLES: Also, when I first evaluated it many years ago, it felt very much like a port from another language, in another culture as opposed to something that from the ground up, considered as a JavaScript library. Is that a fair statement? JAY: Yes, somewhat. Definitely, there were more considerations this time around when it was rewritten and originally, it was going to be Version 3 but the rewriting process took quite a while as these things usually do. By the time we got a version out, it was Version 5. We started when RxJS was at Version 2 but it already released Version 3 and Version 4 by the time it released for the new version like a rewrite had been able to get out. When I say a rewrite, I mean like from scratch rewrite. Matt Podwysocki who was the maintainer, almost the sole maintainer of the previous version, also is now on the core team of the new version of RxJS and has been instrumental in pushing back forward as well, he has far more experience with this than either Ben are I so he's been invaluable. Sometimes, we'll think to make those decisions. We'll be like, "Why was this decision made? Was it made because of .net?" and we'll just assume that and we'll want to change it but Matt has the history involved in that. He knows why things were changed the way they were. For example, we changed one of the operators, flatMap to mergeMap. We know somewhat we go at least, I don't want to speak for the entire team but I regret that decision. Depending on the day that I've been talking to Ben, I could convince him to regret that decision as well. But we thought that mergeMap would make more sense and that very few people in practice would have heard of the word flatMap before and had experience with that so -- CHARLES: I have to say both of the terms coming at it were pretty opaque. I think there was a bout of equivalence in opacity. JAY: Yeah, good to know. That's just an example. I don't want to stick too much on that topic. Maybe someday we'll go back to flatMap and the flatMap still exists. If you're a purist, you can use it. Ben was the primary person who was working on this. He wasn't working on it full time but pretty close to full time to get that initial version out. Even though I used it, my involvement with it was fairly low at that point and then my involvement after it was released got increased. I found more time and started to get more involved, particularly there wasn't a lot of code to write. I have some PRs and stuff like that but particularly on the planning and the issue triaging and PRs and stuff like that, which is a pain in the butt. It's just massive. Particularly, around the same time that the rewrite was getting finished that Angular decided, "You know what? We're going to bet on Rx. We're going to depend heavily on it," so you really can't write Angular without writing some Rx these days. You can get away with not knowing Rx very well. You could just call subscribe and then just do a bunch of imperative stuff but for the most part, the paved path is observables in so many fashions. Now, there's this ngrx. I don't know if you have any exposure to the Angular community. I have quite a bit. CHARLES: I haven't recently. Certainly, since that kind of heavy investment in Rx, I haven't been exposed to it. JAY: I think that was your question, right? CHARLES: Yeah. It sounds like there's a Java implementation that gave rise or a .net implementation or Java implementation gave rise to a JavaScript implementation and that's the one that you got involved with but it suggests very strongly that Rx is an idea and it's played out in a bunch of different languages but really, there is a shift or it's an idea about the way you think about your programs. It's clearly been compelling to you so what is that idea and what is that shift from the way we normally think about things? JAY: The idea was realized very early on -- CHARLES: Yeah, both 10 years ago, right. JAY: Yeah, exactly. They dubbed it their reactive extensions, which is what Rx stands for. Pretty much, name a language and it's been ported to that. There's RxSwift, which is super popular. There's even things like RxCpp and stuff which if you look at it, it's awkward. It seems like we got less language in the world for doing this sort of thing. I actually like C++ in a lot of ways but it was awkward stuffing that stuff in there. It's a really popular pattern and the idea is just basically going all in on the observer pattern, saying that like, "Most people are building things in which you want to be pushed information." You want to be pushed events and the data should stream to you. Modeling most problems in the world as a stream, once you get over the initial barrier of getting away from your normal historical way of looking at things and you look at everything as a stream, it comes very natural because you can actually model literally anything as a stream because it could be a stream of one, it could be a stream of nothing, it could be a stream of infinite number of events or it could be a stream of 10. You can model anything as a stream. Once you start thinking about that, it just becomes very natural and particularly on the UI side of things, I think there's been a lot of success in RxJava stuff at Netflix but RxJava is also used in Rx.net for client-side stuff as well, for mobile development. CHARLES: I remember when I first was introduced to it, I think there was a lot of confusion for me around an observer in the context of Rx and an observer in the context of classical MVC. One particular manifestation of the MVC architecture where you have these kind of mutable objects and you're observing their properties. Like key value observation, which factors heavily into certain UI frameworks. Backbone is one that comes to mind or if you're familiar with Java, basically the JavaBeans, like the property model listeners. I kind of had that conception of what an observer was versus Rx has a very, very different take on observable things. Do you think you could maybe show where they're different? JAY: You can get the normal classic observer pattern using Rx, using a subject basically. But there's a subject class, which you're not going to use super often but there are certain cases where it makes sense. Also, it depends on what libraries. It is used more often in the Angular world because you want to get a stream of clicks or something like that but -- CHARLES: So what would be the subject in that case? JAY: The subject in that case would be you're going to pipe, you're going to emit. Every time they click on something, you're going to 'next' something into that subject, like 'next the event' into the subject. Basically, a subject is a really great way to go from some imperative world to the observable world. Without having to write all sorts of custom glue, you can just basically say, "I've got subject. Any time I 'next' into it, just notify anyone who's listening to this." A subject is hot observable and that's the closest to the typical observer pattern because Rx, it's usually like observables and are usually lazy or cold. That's also what people call it. In the normal observer pattern, there is not necessarily any concept of laziness like you listen to something and that producer is already producing usually. CHARLES: Right. You hit on that and I think that was something that was surprising and kind of delightful when I first started using observables is to realize that they were lazy. Let me make sure I understand it. What was cool is like I was going through some of the demos and I had this observable and is part of, forgive my terminology but when you create a new observer, you pass the function that will get called every time something subscribes to it, right? JAY: When you create a new observer it passes a function -- CHARLES: When you create a new observable, you pass a function that gets called when an observer subscribes and the thing that you can pass is the thing that you can call next on, right? JAY: That's exactly right. When it's a lazy observable, that only get called... Actually, you know, continue. You had a point. CHARLES: I was going to say what was a surprising and cool for me was that every single thing that subscribe to that observable got its own history of that observable from the very beginning. It got its own function invocation so the first example I did, I wanted to iterate over an array and just send 10 items to the observer. Then when you subscribe, you're starting from one every single time: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10. It's not like I subscribe and one gets five of the elements, then I subscribe to another one and that one gets the next five or those two get the next five together. It's like they each get their own version of that observable. JAY: That's exactly right and then that's the main difference between -- CHARLES: -- The whole thing, yeah. JAY: Yeah. This is still observer pattern because the observer pattern, at least to my knowledge, I'm not an expert on this or anything but my understanding is that the observer pattern does not necessarily dictate hot versus cold, per se but traditionally I would say, people interpret it as typically the hot type of thing or also the multicast, if you want to be like these cool buzzwords. CHARLES: Right. What you're thinking of it is when you've got this mutable object, you just dive in wherever it is at that moment and you're now observing events from it. JAY: And that's traditionally because the observer pattern was mostly created for that model view controller type of pattern as well. You can think of like a stream of clicks: the users clicking on things where a stream of keyboard events. That is inherently a hot or multicast stream. You can't tell the user, "Start clicking," or, "Start typing. Don't type." You can tell them that but it's futile. The point being is that you can't control the stream. It pushes data to you and it's already pushing, whether you're subscribing or not, the data is flowing so the traditional observer pattern works really well for that. Then the observables, it's usually lazy, Now again, with subjects and with multicasting, you can get the same behavior. You can get that observable that is hot and shares its subscriptions so that when multiple people subscribe to it, they all get the exact same underlying subscription that is already producing data. CHARLES: I see. That makes sense with to call of multicast because fundamentally, there's really only one observer. There's only one stream and you just happened to be entering in at a certain point. JAY: Right. Then the other one is called unicast but not everyone calls it that but that's usually what it's called. CHARLES: There's a lot of terminology. With subjects, is that just a fancy way of saying a hot observable? JAY: Not necessarily but almost always. If you include them together, you're not wrong 99% of the time. But as a quick drive by definition, it's totally fine. If you're teaching someone really all the things and then they want to fundamentally understand it, it's good to have some distinctions. A subject is hot and multicast but just because something is hot and multicast does not mean that it necessarily has a subject backing it. Maybe from the pattern perspective, you could call it 'the subject' or 'a subject' but in the Rx world, it's not necessarily a subject. CHARLES: Then for cold observables, what are good things that they model, like the execution of an algorithm or something? there's an instance of that algorithm, I'm going to add two numbers or I'm going to reduce this tree of numbers into a product or a sum or something like that, where you start from the beginning, there's a clear beginning, there's a clear end --? JAY: Right. The observables are really good at modeling side effects, for example. Things you want to do like make an Ajax call or read a file or something like that. In fact, reading from a file is actually not a great use case for observables just because you want to be able to control the back pressure. We can talk about that next if you want but -- CHARLES: Yeah. Back pressure is a concept. It's crazy to me and when people use it, I'm like, "How do you even do that?" You can say it and sounds good in practice but it sounds really, really complex. JAY: I think I can summarize it for you. The back pressure stuff is basically you have a data producer and you want to be able to control the rate in which it is producing so that you do not overwhelm the consumer. You can consider two servers. You've got Server A and it's sending events to Server B. If Server B can only process 10 events per second but Server A sends 100 events per second, what's going to happen? There's a deficit. There's a huge 90 events per second deficit and that means that the Server B is going to get more and more behind. Eventually, it will just fall over and run out of memory, CPU or whatever happens. Back pressure is basically just being able to control that somehow. There's lots of ways, there's several policies of back pressure. There's buffering, there's dropping and then there's the pull model where it's like, "I'm going to tell you when to give me the next event," or, "I'm going to tell you to give me six more. I can handle six more, give me six more," or, "Here's the next one." Those were -- CHARLES: Then polling would have to be combined with buffering or dropping still, right? JAY: Possibly but it becomes one of those like you use it just as a rarity. Because the problem with buffering is that it becomes usually unbounded and that means you can -- CHARLES: It's blowing up the producer, right? JAY: Well, you risk money out of memory, mostly. It just becomes completely unbounded. You can bound that buffer and then it becomes dropping. Then if it's dropping, that means it's lossy. In a lot of scenarios, it's important not to drop information. CHARLES: They're useful stuff. JAY: Right. At the same time, there are a lot where you can drop it. Like at Netflix, we have this data pipeline thing for these logs and I got a good talk on this actually. This data pipeline is called Mantis job platform where all this data flows through. It uses RxJava almost exclusively and we have a lot of different back pressure mechanisms but the one of the most popular is dropping data. If the consumer is being overwhelmed with the number of logs and events that are matching to it, we just start dropping them because they're logs. We want to keep them but we make a best effort and it's perfectly fine to drop them. In the observable world, it's usually going to be either buffer or drop. You're not going to usually be able to control the producer's rate. In RxJava, there is something called the flowable, which lets you control the rate by basically saying, "Give me N number. I want N number more." It's become more important on the server-side end of things but a normal observables -- CHARLES: That makes sense. JAY: Yeah and there's even a library that's brand new that Matt Podwysocki came out with called IxJS. Instead of RxJS, it's IxJS and it's iterator. It's for async iterator and regular iterators, which is good for that other end of the spectrum for back pressure. If you want to be able to control the producer, you're saying, "Give me the next five." That's what an async iterator is incredibly perfectly suited for. CHARLES: The async iterators are kind of like the logical inverse of the observables? JAY: That's exactly right. It's the dual, if you want to use the computer science term, I assume you knew that already and it was that was just a plant. CHARLES: Actually, I didn't terminology, the dual but it's like through the looking glass world, right? JAY: Yeah, that's correct. CHARLES: One hand you got Alice in our world and she's looking in the looking glass world. I'm not saying which one is which but one is observables and one is the async generators. When you would want to use async generators is when you want to have the consumer driving the entire stream. JAY: That's right. A lot of people, when they discover async iterators, they'll ask me, "Jay, why wouldn't I just always use that? It seems like they're more flexible of the two." The reason why is because you can't always control the producer. The fundamental example that I was giving earlier like mouse events or keyboard events, you cannot control what the user does so an async iterator would be a very poor primitive to model that because what happens if you decide to give me one keyboard event at a time and one per second. You're like, "Give me the next keyboard event." If you did that one per second and someone is typing on their keyboard, what do you do with all the events while you're waiting? You could buffer them but that's a back pressure problem. You have to choose and it's a very poor primitive model to that. CHARLES: Yeah, that would be a terrible user experience. The users want the consequences of their actions to be realized at the soonest possible point. JAY: That's exactly right. The other benefit of observables is a slight increase in performance because when you subscribe to an observable, it sets up the chain and then now only data needs to flow through that chain. Whereas an async iterator, every time you call next, you're going to get a brand new promise. If you used it for something very high volume, you might be able to see how now you've got a lot of excess allocations: CPU cycles being used, garbage collecting for each one of those promises. In Netflix, we got a lot of streams, which are hundreds of thousands of events per second. If you do that, those allocations of those promises can certainly add up. It's just not the most efficient primitives for that as well. CHARLES: I thought that async iterators used essentially continuations under the covers and not promises. JAY: Under the covers, I'm not sure how you would describe what -- CHARLES: I'm not super familiar -- JAY: It's basically an -- CHARLES: You're talking about like yield, right? JAY: You're talking of generators maybe? CHARLES: Uh-uh. JAY: Iterators and generators are although related because a generator is basically a factory for creating iterators. Does that make sense? CHARLES: Yeah. JAY: Every time you call that factory, you get a brand new iterator out of it. But then when you have an async generator, it's basically the exact same thing except for the iterator returns a promise. You're basically saying, "Give me the next thing." You call next on the iterator and the next will return a promise and that promise will resolve with a value. Why is that useful to standardize? Because you can have syntactic sugar like the [inaudible]. I don't know if you've seen that yet but it's like a loop primitive, where you can basically loop over an async iterator without needing to deal with the whole thing and all that stuff. The same way normal async/await is helpful. This await is helpful at the same time. CHARLES: It's way above my pay grade but maybe you're using both. I'm trying to think with async the way that works with promises, right? JAY: That's correct. CHARLES: So you got both the continuation and a promise. That's even more overhead than the promise because you've got to stuff away that whole call stack and the promise and yield to it. But anyhow... ELRICK: This is very interesting. RxJS is a very deep subject. What I'm interested to know is you have RxJS, you have observables and you have redux. Where's the union? How did that come to play that you guys came up and said, "You know what? We need to create redux-observable library?" JAY: Yeah, great question. It came about fairly organically and over many month period of time, actually. We bring Rx people as I mentioned and we were using redux at the time and we're still using redux but my team that I was on was using redux and we were using redux thunk and the thunks were getting incredibly out of hand. It was very hard for us to do things that we were used to doing that were very simple like debouncing. We were like, "This is really hard. It's just to do something so simple that in Rx, it's so simple." We try to stuff Rx into redux thunk and try to make conventions around that. It just didn't work out well and then we initially made something we called thunk-observables -- CHARLES: We really wish you would have stuck with the name even you didn't -- JAY: Yeah, so thunk-observable is probably what you can expect. You dispatch a thunk which returns an observable and that observable will be subscribed to and that was it. Basically, that was the primitive so that let us have our debouncing but in practice, we found that the thunk stuff cause way more confusion and then also did not let us do composition as much as we wanted to. We then extended thunk-observable thing to get receive a stream of actions so that you could compose the different thunk-observable together and then receive new actions to cancel things and stuff like that. We eventually just figured out that having basically the idea of thunk-observables but having of them be like almost static factories that are like process managers, that's the pattern that we ended up on today. That we coined calling them epics. Basically, an epic is a function, which receives as an argument, a stream of all of the actions. It gets an observable of every action that's going to be dispatched and it was a hot observable so that means that if you happen to subscribe to it later, you're not going to get all the actions from before. It doesn't replay them. It's just all actions from the time you subscribe and continuing. Then what that function is expected to return is a new stream of actions and that stream that it returns of actions gets subscribed to by the middleware under the hood and basically, it just calls stored dispatch on anything you emit. You can imagine the simplest epic would be a function that gets streamed of all the actions, it applies a filter operation on all of those and looks for a particular action and then based on that action, it performs some side effect and then when that side effect comes back, it emits a different action. Basically, to notify redux like, "Here's the results. Here's the change. I'm done," or what have you. let you just make arbitrary side effects but isolate them in a way that fits very naturally with your UI layer that you're using and with redux itself with the purity of the reducers. CHARLES: Right. For example doing an Ajax request, I think that's a good example. You get some action in, you're getting every single action that's dispatched to the store, the first thing you want to do is you want to filter that stream to only the actions that are user click the save button so I want to save off this form. To some action, that's my save action so then my job is to now map that eventually. Out the end of that stream, I want to have like the save either succeeded or the save failed. There's two forks on an Ajax request. The fundamental mapping that's happening is either from the user click save, whatever you want to call that action, I want to map that to the user if the save was successful or I want to map that to the save failed or rejected. The hard part then is executing those side effects and then putting them back into the stream. How would you do that then with redux-observable? JAY: If I'm following correctly, the typical almost all epics, not all of them but almost all, they're going to have a filter at the top of the epic, they're going to filter out looking for the action they want and then they'll have some sort of merging strategy operator like mergeMap, aka flatMap or they have something like switchMap. CHARLES: I feel like that's one of the harder concepts for me and I want to actually going to be a little selfish here and try and bounce my understanding off of a bit so you can be like, "No, your mental model is incorrect," but we'll find out how it's incorrect. With the mergeMap, is that a way of saying, "I can take other observable streams and inline them inside this one stream." That's the way I've been thinking about it. I can go out to the rest of the world, I can have some other stream and I can inserted into the processing chain of this other stream. In this case, I do a mergeMap of the actual fetch or the actual post but it's not a straight chain of implication like do a filter then I do a map then I do this. I've got to take this other observable, this thing, this other asynchronous process, which really represents another stream and I want to merge it into this one stream. Then once that's done, I get the result. now, once that happens outside the mergeMap, now the Ajax results whether it's a success or failure, the result of the request, now it becomes the next item in the stream, which then I have to map down to another redux action. JAY: That's right. The mergeMap operator has an alias and it also used to just be called flatMap so you can envision that you are creating an observable of observables, a higher order of observable. With mergeMap, you want to flatten that. You're saying that every time I get an event, I'm going to call this projection function and it's going to return a new observable, an inner observable and I want to merge each one of those into each other so that it becomes one stream. That means you can have concurrency. That means you can have multiple and simultaneous concurrent Ajax calls that can finish it arbitrary times. I think it's important then to contrast that with some of the other merging strategies like switchMaps or concatMap. With switchMap, as the name implies, you switch between observables so at any point in time, you can only have one observable subscribes to at a time. If a new event comes along and you call the projection function, it returns a new observable. If the previous observable has not yet completed, it will get unsubscribed to and anything it was doing gets cancelled. In the example you're talking about, if you've got an epic that goes and fetches your user model every time they click this button, let's say that they can click that button multiple times and you don't want to make 50,000 requests. The quintessential example is actually the auto suggest stuff. As you're typing key strokes, if the request is in processing and they type another keystroke, you don't want to wait for them the previous request to come back and process it. It's not only wasteful because you'll process the JSON and all that stuff. It can introduce bugs because it may come back out of order. It may come back actually after your new one comes back and that can cause all sorts of crazy weird bugs. That's what switchMap is really great for. I call it implicit cancellation. Ben doesn't like that because he's saying that in a switchMap, you are being explicit about it but you're not calling unsubscribe on it yourself, which is why I call it implicit. It happens automatically. There will never a new event pipes through there. Then there's the third one which I don't -- CHARLES: So this switchMap ever make sense outside the context of hot observables? JAY: I would say that it makes more sense usually on hot observables but there are certainly cases like let's say that you've got a web socket observable and every time you get an event, based on that event, it make some other request and that other request may or may not take a really long time. But if you get another thing back from the web socket, you want to cancel the previous one. That's somewhat not a great example as well because sometimes people use multiplexing for the web socket so that it becomes multicast. But the point being is that there are definitely times where you will use merge, switch or concat. That concatMap being the third one where as you might imagine, you are concating the observables, you line them up. If I get a new event, I'm going to call my projection function, create that new observable but I'm not going to subscribe to it. I'm going to keep it but I'm not going to subscribe to it and tell the previous observable I was subscribing to has completed. In a way, you're buffering the observables and because you're offering them, you can get in trouble where you end up buffering infinite observables. Let's say the first one never completes for some reason because of a bug, you may infinitely buffer them. ConcatMap is not used that often. I'd say it's very rarely used. Its use mainly when you don't want lossy behavior. You want, at most wants semantics like you're only doing one per time. CHARLES: The difference between mergeMap and concatMap is what? JAY: It's you're not going to do concurrent. That's probably the best way to explain it. You're going to do that in sequence instead of concurrently. CHARLES: I see. Maybe an example would be like file uploads or something. You probably want to do your file uploads in parallel but let's say, you want to conserve bandwidth or you're working where you've got a browser that only supports 10 connections or five upload connections but when someone selects 30 files, you don't want to just drop those files. You want to be uploading 10 concurrently but as soon as one finishes off of that 10, you want to start up another one. JAY: That's absolutely right. Another example would be like you are going to hit some API and it could be used as one mechanism to kind of throttle yourself. If you want to guarantee that you're only connecting at most once to this particular end point at a time, no matter what the upstream tells you to do. CHARLES: Right. I could see that. That makes sense. JAY: I can tell that you're a little bit struggling to see the use cases, which is totally normal. ConcatMap is not used very often. It's for of those fundamental operations, which primarily why it's included is it's non-trivial to implement yourself. CHARLES: Are there any other mapping operators that we should know about? JAY: Those are the three primary ones. There's a couple of other like boutique variations but they're all variations on the exact same thing. CHARLES: Right. ELRICK: Do we have like mergeMap, switchMap and concatMap that are specific to management of observable and that's specific to redux-observable. There's people out there using something like redux-saga or they're trying to compare and contrast these two libraries. How do these things contrasts? Because I don't think you would use either of these mapping operations inside of a saga. Is that correct? JAY: I just want to make a minor clarification. The Rx stuff and these operators that we've been talking about: mergeMaps, switchMap and concatMap, they are not actually related to redux-observable really in any way. The only thing they're related is that you just might happen to use them. Redux-observable is actually a very tiny library and it defers pretty much everything to just normal idiomatic RxJS code and that's really the biggest pro in comparing it to say redux-saga. Redux-saga came significantly over a year before redux-observable and without a doubt, were influenced. The pattern is very, very, very similar but there are some just fundamental differences and one of those is that difference. The most obvious thing is if you already know RxJS very well, without a doubt you're going to want to use redux-observable. I could tell you that, it's not possible but it's very unlikely you'd choose redux-saga over redux-observable if you're already a really big Rx fan because you basically know how to do it. You just have to think that the items you're modeling, the events you're modeling are actions, which just happens to be a convention really. There are some other differences though between redux-observable and redux-saga and the biggest difference being that redux-saga takes this effects as data approach, which is like Haskell if you're familiar with that. In a lot of ways, it's identical with the IO monad but it basically just means that you're not actually performing the side effects yourself right then and there when you call their operators. There are special utility functions, instead there's like an engine or a middleware underneath that performs the side effects on your behalf. You create a generator and that generator is the pattern that is called a saga is what they call it. That generator yields these objects, these effects objects. One of the effects objects might be to call some particular API to make an Ajax request so you're going to yield that object that basically describes the side effect you want to perform but doesn't actually do it itself. It's just an object. In the middleware will form it for you so why would you put that indirection. The indirection helps when you want to do things like testing. If you want to test it, you don't actually need to perform any of the side effects. You can just call next on the iterator that you get back from the generator, you call next on it, you will get the side effect object, the effect as data that you want to perform and you can just assert based on that. You don't need to do mocking in all of that stuff. You just have to assert that the effects that were yielded were the ones that you expected. Now, I don't like that approach personally because I actually use redux-saga quite a bit, not lately. It was like a year ago. You end up implementing almost all, not all but a lot of your business logic in your actual tests themselves. Your test become less about testing the behavior or the outcome of a particular thing and more about testing how it gets to that outcome and what steps it takes to get there. Some people think that's fine. For me personally, it felt like any time I made a change in my saga, I had to make the exact same change in my test even though the behavior of the saga did not change. The actual observable outside side effects did not change in any way but I may be refactored or renamed something. It felt very redundant and to me, felt brittle because I started to wonder who tests the test then. If the tests are in a lot of ways are reimplementation of the saga, how did I really test that the behavior of what I was trying to accomplish really was accomplished. I'm not an expert on it so certainly, I'm sure there are people who have patterns around this that can mitigate some of my concerns. But for me, I'm used to testing Rx and I'm used to Rx in particular so the pattern for me of using observables just made a lot more sense to me. Also, with either of these libraries, the learning curve is really steep. If you don't know redux-observable, let's say you don't know Rx, learning Rx just to use redux-observable is a pretty huge undertaking. I would usually recommend people to not do that. A lot of times these days is spent me helping people who are frustrated because they dug themselves in a hole by using all these new technologies. They'll pull in TypeScript and [inaudible] with every all of the cool new hotness and I don't blame them because they've been told that this is all the cool stuff. CHARLES: We got some great advice on that that you can have one vanity technology on every project and live it yourself. Indulge in that coolness, in that hotness and do something exciting but make sure you have one vanity technology and one only. Everything else, be very comfortable with and one is just crazy experimental like this is the coolest new thing and we're going to just drop it in. But if the rest of your chassis is solid, then you can support that crazy experimental engine that requires you to stand up on the front of it and feed gas in with your mouth like they did in Mad Max. JAY: And there are exceptions obviously but for the most part, I subscribe to that. I answer a lot of questions on Stack Overflow and redux-observable. I actually get sad and frustrated when I see people that it's very clear that they shouldn't be using this. Their use case is not complex and they haven't learned Rx yet. It's one thing if you're like, "I'm learning this and I know that I'm going to have pain." That's totally acceptable. There's plenty of times where it's like, "It's totally okay that there is no concrete deadline and I can take my time," but a lot of times and I would say, a majority of the time, you're slipping on the deadline and that's not a good thing. The people who are coming to me are just frustrated. They're like, "Why is this so complicated?" You're right, it is really complicated but its complication helps with some of the more complicated use cases. That's the irony behind both redux-saga and redux-observable is that they're both really complex for the trivial use cases like all I want to do is make an Ajax call. That's it. I don't want to cancel it, debounce it, I won't do anything. I just want to make an Ajax call. They are the biggest hammer you could possibly think of. Don't use them for that. CHARLES: The thing is if you're not sure, whether you need redux-observable, then you actually don't need redux-observable. JAY: I would say that usually that is the case, yes. The same with redux-saga. They're in the exact same league. It's basically, "Do you need complex side effect management?" With the redux-saga, the complications, even though generators have been around for a little while, a majority of people still are not familiar with them because they're just not used all that often. They're kind of mystifying. I would say, they're not super hard to learn. They're just alien. Then to add on top of that, the effect is data and you've got multiple curveballs. Same thing with redux-observable, they could never use observables. It's pretty alien. The reactive programming idea and model is pretty alien. I would advise, if you're not using redux, don't even consider redux-saga and redux-observable personally. If you're already are using redux and you think that you might need something like this, experiment with the primitives, try and see how well your team can pick up RxJS just by itself. Just learn some of the regular RxJS tutorials, don't even look at the redux-observable docs because it's not useful in any way when it comes to this. Just try and learn a little bit Rx and see does it click. Because some people is like, "I don't understand why everyone thinks it's complicated. It's easy." But a majority of people, it takes a while before they get that like Neo in The Matrix, I-know-kung-fu moment. CHARLES: All right. We're almost at time but I hope that that moment comes to everybody. I think we've certainly enjoyed a lot of success with it already and I think once you do get your head around the basic use cases and you know how to do an Ajax request, you know how to do just simple saves and gets and what have you, doing the trivial things becomes easy because you know which pathways to travel. But before we head out, is there anything that you've got coming up in the near future, any talks, appearances, meet ups, anything whether you or otherwise that people should be aware of? JAY: I would say on this topic, there's a new beta for RxJS with this new way of using operators. It's being dubbed lettable operators, like the 'let' keyword but it's not related to that. It's basically just a way of finally being able to import operators and to use normal tree shaking that people have asked for forever. Because the problem with observables is that they're prototype-based methods and you can't reliably tree-shake methods or prototypes. We've been trying to experiment with ways to have [inaudible] and the lettable operator stuff is interesting to check out. It's a stopgap measure until JavaScript has something like the pipeline operator, which just actually moved to stage one. It's a brand new operator. If you're familiar with a lot of functional programming stuff like F# and a lot of the functional programming language is actually have the pipeline operator, it'll make it so that you can basically have syntactic sugar to apply a function, basically to pipe the result of a function into the first argument of the next function, etcetera. You can pipe the argument and return values through a series of functions. If you do that without this syntactic sugar, you've got this massive nested function invocation, which is incredibly hard to read and hard to maintain. That's why the pipeline operator is so great. I would encourage people, that's in beta right now. I think it's 5.5 but it's in beta right now. I encourage people to check it out, find bugs and get feedback. Maybe this is completely off base and it's not the right direction that the team should be going but it's based on a lot of collaboration, particularly with the Angular community. They've been, in particular asking for this because they're pretty big and they've got to use the Clojure compiler and all sorts of things for trying to make their bundles incredibly small. For me personally, I don't have any Rx talks coming up. I've been pretty obsessed with web assembly here lately. I'm an armchair compiler nerd. I don't do compilers for a living but I have done them personally for a number of years so I'm obsessive with web assembly. I have number of talks in web assembly coming up but just nothing related to Rx at this point. CHARLES: That's totally okay. I'm actually, also have been obsessed with web assembly. JAY: Have you guys done a podcast on that yet? CHARLES: I don't know. ELRICK: No, not yet. CHARLES: I actually started out to write my own list compiler in web assembly and they got totally derailed on the list compilers. Actually I ended up switching tracks on the whole web assembly thing but I was really, really excited about it. Probably, it was about three months ago or something like that but I'm still excited about it. I just haven't been working on it actively so I'm very curious to hear about those talks. Let's post them on the show notes and who knows? We do a lunch and learn every Friday here and usually, it's one of us getting up there but sometimes, we'll just watch a talk. One of us has been wanting to watch. ELRICK: And you're always welcome to come back to any time and geek out with some web assembly. CHARLES: I'd say, we haven't podcast web assembly, you know? All right, you guys, we've been at this for another hour. Let's go. Everybody listening, strap your headphones on, we're going down for another hour. Changing the subjects: web assembly. It starts right now. ELRICK: It's going down. CHARLES: No, but we will have to have you on for that. Thank you so much for coming on and talking with us about observables, Rx, redux-observable but if folks want to continue the conversation with you, they can get in contact with you how? On Twitter, email? JAY: The best way is going to be Twitter probably. I'm at @_JayPhelps. Thank you guys very much for having me on today. It was a blast. I love talking about this stuff. ELRICK: Thank you. CHARLES: Thank you and for anybody out there, we can also be reached at @TheFrontside on Twitter or just drop us a line and Contact@Frontside.io and have a great week and we'll see you next.
In this Modern Web podcast Ben Lesh discusses the future of RxJS with Tracy Lee. Topics covered: - Decreasing the bundle size of RxJS- Implementing new operators- Lettable operators- A more functional RxJS- Using RxJS in frameworks To learn RxJS, visit http://reactivex.io/rxjs.Follow Ben and Tracy on Twitter @benlesh and @ladyleetListen to more podcasts at http://moderndotweb.com
Toran Billups @toranb | GitHub | Blog Show Notes: 01:44 - New Developments in ember-redux 04:23 - New Developments in the Wider Redux Community 06:26 - Using Redux in Ember 09:40 - Omit 10:45 - Reducers 25:42 - Fulfilling the Role of Middleware in Ember 28:12 - Ember Data in Redux-land 31:24 - What does Toran do with this stuff?? Links: The Frontside Podcast Episode 55: Redux and Ember with Toran Billups The Frontside Podcast Episode 18: Back-End Devs and Bridging the Stack with Toran Billups redux-offline ember-redux-yelp create-react-app "Mega Simple redux” Twiddle ember-concurrency Thomas Chen: ember-redux The Frontside Podcast Episode 067: ember-concurrency with Alex Matchneer normalizr Rich Hickey: Simple Made Easy Other Noteable Resources: ember redux: The talk Toran prepared for EmberJS DC in April 2017 github.com/foxnewsnetwork/ember-with-redux Transcript CHARLES: Hello everybody and welcome to The Frontside Podcast, Episode 69. My name is Charles Lowell. I'm a developer here at The Frontside and your podcast host-in-training. With me Wil Wilsman, also a developer here at The Frontside. Hello, Wil. WIL: Hello. CHARLES: Today, we have a special guest, an actual elite member of the three-timers club, counting this appearance. We have with us Toran Billups. Thank you for coming on to the show today. TORAN: Absolutely. I'm not sure how the third time happened but I'll take it. CHARLES: Well, this is going to be the second one, we're going to be talking about Redux and then I believe you're on the podcast back in 2014 or 2015. TORAN: That's right. CHARLES: That's one of our first episodes. Make sure to get in touch with our producer afterwards to pick up your commemorative mug and sunglasses to celebrate your third time on the show. Awesome. I'm glad to have you. We actually tend to have people back who are good podcast guests. TORAN: Thank you. CHARLES: Yeah, I'm looking forward to this one. This is actually a continuation of a podcast that we did back in January that was actually one of our more popular episodes. There was a big demand to do a second part of it. That podcast we talked about the ember-redux library, which you're a maintainer and just kind of working with Redux in Ember in general. We're going to continue where we left off with that but obviously, that was what? Almost six months ago? I was wondering maybe you can start there and there been any kind of new developments, exciting things, what's kind of the state of the state or the state of the reducer or the state of the store in ember-redux. TORAN: For ember-redux, in particular, we're working on three initiatives right now. The first is making the store creation more customizable. A lot of people that come from the React background in particular are very used to hand crafting how the stores put the other with the right middleware and enhancers and reducers and that's been fine. I wanted to drop people into the pit of success and everybody's cool with that but now we're getting to a point where there are people wanted to do different things and it's great to open the door for those people if they can, while keeping it very simple so we're working on that. We have here that's just undergoing some discussion. We're also, just as the wider Ember community -- you guys maybe involved in this as well -- and trying to get the entire stack over to Babel 6, the ember-cli Babel 6.10 plus stack. There is a breaking change between Babel 5 and 6 so we're also having some discussions about the ember-redux 3.0 version bump at some point later this year, just because we really can't adopt this without introducing basically a breaking change for older ember-cli users. CHARLES: Just in general, this is a little bit off topic, what does it mean to go from Babel 5 to Babel 6, if I'm an add-on author. TORAN: I would probably ensure that need to speak more with Robert Jackson about this. We just kind went back and forth because I thought I had a Babel compile error. He's like, "No, you're missing this dependency which is the object spread." Unfortunately, the object spread is rampant in React projects and this is totally cool. I had to actually add that and that's just a breaking difference between these two. If we adapt the new version of this in the shims underneath of it as an Ember 2.43 user, if you're on node four which is still supported, you will break without this. I'm trying to get some discussion going about what we should do here and if we even should push ahead and just say only node six is supported. There's some discussion and then back to your original question, the third piece is we've introduced the ability to replace the reducer but we need to get some examples for hot reloading the reducer. That's a separate project but it needs to be enabled by ember-redux. Those are the three main initiatives. CHARLES: Being able to you hot load your reducers, just to make changes to your reducer and you just thunk them into the application without having to lose any of the application state and that one of the reasons that's possible then is because you're reducers have no state themselves. They're just pure functions, right? TORAN: Exactly. CHARLES: Okay. Awesome. That sounds like there's a lot of cool stuff going on. Beyond ember-redux, are there any developments to look for on the horizon in the wider Redux community that might be coming to Ember soon? TORAN: Actually one of them is actually fairly new and it's already in Ember and just because I have already got a shim up for it is redux-offline, which I remember you had Alex on two episodes ago about breaking your brain around Rx. I feel like that happened for me trying to build apps offline first. This is, of course just another library that can drop in that place nicely with Redux but I feel like the community, at least it's got me thinking now about what an absolute that would really disrupt someone who's a big player today. I feel like you've built a great offline experience with true and well done data syncing. You could really step in and wreck someone who's in the space today. CHARLES: Right, so this is a sim around... what was the name of the library again? TORAN: Redux-offline. CHARLES: Okay, so it's just tooling for taking your store and making sure that you can work with your store if you're not actually connected to the network and like persisting your store across sessions? TORAN: Yeah. It uses a library that called redux-persist that takes care of and kind of hydrating the store if you have no network connectivity. But it's also beginning to apply some conventional pattern around how to retry and how to roll back. It's just an interesting look at the offline problem through the lens of an action-based immutable data flow story. It's interesting. I don't have a ton of experience with that kind of tweet and rewrote my Yelp clone with it and that was tough. That's what I mean by this. It's like I thought this is very trivial but you have to do a lot of optimistic rendering and then sort of optimistically gen primary keys that gets swapped out later and it's tricky. If you've never done offline first, which I have not, I just think offline is pretty cool and along those lines, there's been a lot of discussion around convention. There's of course, Create React app which is like a little library or CLI tool to kick off your Redux in React projects. It's kind of ember-cli, very trimmed down version of that right now and that's just getting incrementally better. Of course, you guys are in the React space so you may touch upon that story if you haven't already. CHARLES: All right. We talked to the very high level, I think the last time we had you on the show but now that the idea is gaining traction, kind of delve into more specifics about how you use Redux in Ember. I asked at the end of the last podcast, let's step through a use case like what would deleting an item look like in ember-redux land. Maybe we could pick that up right now and just understand how it all connects together. TORAN: Yeah, absolutely. Without understanding how this entire flow or this event bubbling happens is hard to get your head around it. The process we're going to walk through is exactly that use case you laid out, Charles. We're going to have a button in our component and that button, on-click the idea is to remove an item in a list that we happen to be rendering, let's say. If this is a child component like the very primitive literally button that you have and you just have your on-click equal probably a closure action in Ember, the parent component or the outer context is going to be responsible for providing the implementation details for this closure action and what it does. This is kind of the meat of what you're getting at. The high level here is there is a single method on the Redux store that you have access to and it is called dispatch. The nice thing about Redux again, the API surface area is very small. It's just a very handful of methods you need to get your head around. This one, in particular takes one parameter, this dispatch method. That parameter is a JavaScript object. Now, if you're just playing around, you just want to see the event flow up, there's only one requirement asked of you and that is type property. This JavaScript objects have a type that is often a string so it's very human friendly, you just put in there and the string remove item, let's say. Now of course, if you want to remove a particular item in this remove example, you of course want to pass some information as well beyond the type. The type is mostly just a Redux thing to help us identify it but in this case, you'll definitely know the primary key or the ID value, let's say of the item you want to remove. In addition to type, this JavaScript object, let's just say has an ID property and that can come up from the closure action somehow if you want. Once you click this, what's going to happen is you're going to fire this closure action, the closure action is going to invoke dispatch with the JavaScript object and dispatch is going to run through the reducer which is the very next step and what we do is we take the existing state. Let's say we have a list of three items, that's going to be the first argument now in the reducer. The second argument is this action which is just, as I describe it a JavaScript object with two properties: type and ID. You can imagine an ‘if' statement, conditional switch statement that says, "Is this the remove item action? If it is, okay." We had the ID of the item that want to remove and since we have a dictionary where the primary key of the item is the ID, we can just use lodash-omit and we basically use omit to filter out the ID and then use object assigned to a transform or produce a new state and then a callback occurs after this that tells your list component that somewhere in your Ember tree to re-render, now only showing two items. CHARLES: One of the things I want to point out there, you just touched on it but I think it's an interesting in the subtle point is that the lodash method that you used was omit and that's how this is kind of tangential or I'll say parallel to programming in this way is that you don't actually use methods that mutate any state. You calculate new states based on the old states. I think that's a great example of that -- that omit function -- omission is the way that you delete from something in an immutable fashion. You're actually filtering or you're returning a new copy of that dictionary that just doesn't have that entry. You're just a omitting it. You're not destroying the old one. You're not deleting anything. You're not changing it. You're just kind of Xeroxing it but without that one particular entry, which is ironic because the effect on the UI is that you have done a delete but really what you're doing is omitting there. I just think that's cool. I think it's one of the ways that using the systems teaches you to think about identity differently. Then the question I want to ask you was, this all happens in the reducer, what does that mean? Was that word mean -- reducer? I kind of like danced around that idea and I've tried to understand where that term came from and how it helps give insight into what it's doing and I come up short a lot. Maybe we can try and if we can't explain what the name of reducers, maybe there's some alternate term that we can help come up with to aid people's understanding of what is the responsibility of this thing? TORAN: Yeah, I think we can just break down reduce first then we'll talk about how it ends up looking. But I think it's reduced almost like it's defined in the array context. If I have an array of one, two and three and I invoke the reduce method on that, we actually just produced a single value, sort of flatten it out and produce a single value as the result to that, so three plus two plus one, six is the end result. What we've glossed over this entire time, probably last episode is that this reduce word, I believe is used because in Redux, we don't really just have one massive monolithic reducer for the entire state tree. We instead have many small reducers that are truly combined to do all the work across the tree. In my mind is I think reducer fits well here because we're actually going to combine all these reducers and they're all going to work on some small part of the state tree. But at the end of the day, we still have just one global add-on and that's the output. We want one global add-on with a new transform state and that is the reduced state. CHARLES: You take some set of arguments. One of which is the prior state and you reduce that into a single object. I like that. The other place where I've seen this term applied in a similar context is in Erlang. They talk about reduction so that you have an Erlang server where the way that the servers modeled is as a recursive function call where you pass in the prior state of the server plus any arguments if you're handling a request or something like that, bundled in there is going to be arguments of the request and then what that function returns is a new state, which is then used to pass in to the next state. They call this process reduction. We've got two data points. Maybe there, we can go search for the mathematical foundation of that later -- TORAN: I like it. CHARLES: -- if you want to geek out. I think that helps a lot. Essentially, to sum up the responsibility of the action is you take a set of arguments, it's going to take the existing state of the store, run it through your reducers and then it's going to set the next state of the store or yield the next state of the store. Is that a fair summary of what you would say the responsibility action is? TORAN: Yeah. I think you're right. In fact, in preparation for this talk, I just threw together really small Ember Twiddle that will link in a show notes what I call the mega trimmed down version of ember-redux. It's basically a really naive look but for conceptualizing this flow, it's about 24 lines of code that show exactly what you're saying which is I have this reducer, it's passed into this create store method in the syntax, how do this actually look? It better illustrates how the reducer is used when dispatch is invoked so a dispatch, if I was actually to walk line by line through this, which will be probably pretty terrible. But the very first line of dispatch is to just call the reducer. From that new state transformation, we just push in so the store gets a new entry into it's array of here's the next state and because we had never tampered or side effect-ted the old state, we could easily go back in time just by flipping the pointer in the array or that indexing the array back point. CHARLES: I guess my next question is we've talked a little bit about immutability and we know this reducer that we call at the very first point of the dispatch is a pure function. You were dealing with pure functions, immutable data but at least in perception for our users, our system is going to have a side effect. There's going to be calls to the network. We are, in the least in theory deleting something from that list. How do you go about modeling those side effects inside Redux? TORAN: This is a great intro because in fact a friend of mine is actually a teacher at a boot camp and he was telling me the other day that he was asked to do a brief look at Redux and his very first feeling when he was watching some of the Egghead.io videos is like, "Oh, so the reducer is pure but I have to side effects something so where do I do this?" It's not very clear, I think for the very beginner which is why we left it out of that part one podcast. Today, we're kind of hit that head on but before we get into that list, we can talk about what having actions in their simplest form look like today in your Ember app. As I mentioned earlier in this remove example, you got the button, it just takes the closure action the on-click. No big deal. The bigger work was on the parent contexts or the parent component to provide this action, which sounded very simple but imagine instead of just dispatching synchronously, which is we talked through. Imagine we only wants to dispatch that officially to change it if we have gotten a 204 back and the fetch request is deleted on the server -- normal Ajax or fetch-type flow. In this case, you start to add a little more code and imagine for the moment this is all inline in your component JS file. The component now is started to take on an additional responsibility. In addition to just providing a simple dispatch, as I say, "Go and remove this Mr Reducer later," you're now starting to put some asynchronous logic and as you imagine a real application, you grows and try catch stuff, some error handling, some loading, some modals. This gets out of hand. One of the things that I want to touch on briefly is, at least in the ember-redux case we ship this Promise-based middleware and I want to stop right there for just a second because I use that word 'middleware' and immediately we've got at least highlight what this is doing. In that pipeline -- we talked about earlier -- in the component I dispatch and it just goes right to the reducer. Well, technically there's actually a step or an extension point right before the reducer is involved and that is where middleware comes in. Technically, you could dispatch from this action and then you could handle and do the network IO type request in middleware instead, then porting on another dispatch of a different type with the final arguments to be transformed. That's really the role. CHARLES: Can middleware actually dispatch its own actions? TORAN: Correct, yep. In fact, one of the first big differences between this example as I'm kind of hacking around the component and I've got access to dispatch but there's two things I'm really actually lacking if I don't leverage middleware full on. The first is I do have some state in the component but often, it's actually just a very small slice of state that this component renders. If there's actually a little bit more information I need or actually need to tap into the full store, I don't have it and that might be considered a good constraint for most people. But there are times you imagine more complex apps, you need the store. You might even see a little bit more state, middleware provides that is where you trapped with just that slice of state and dispatch the keyword. That's about it in the component. But the other side effects are the benefit, as you break this out is you get another seam in the application where the component now is not involved with error handling and Promises and async flows or generators. It just does the basic closure action set up and fires dispatch almost synchronously like you did in our very simple example, allowing the middleware to actually step in and play the role of, "Okay, I'm going to do a fetch request and I'm going to use a generator." It's almost like the buffer for IO or asynchronous work that it was missing in our original equation. Imagine, you want to debounce something or you want to log something or you want to cancel a Promise, which you can't do, any of that stuff that's going to happen in this middleware component. That's one of the things I like about middleware as I learn more about it and the moment you get to a very complex async task where you're actually doing the typical type ahead, where you literally want to cancel and not do the JavaScript work or you like to cancel the Promise as quickly as you can, you can very quickly dive into something kind of like what you and Alex talk about with ember-currency in the Redux-land. It's called redux-saga. It's just a generator-based async work. CHARLES: Is saga kind of emerged as async library that everybody uses? I know it's very popular. TORAN: Yeah and a good reason, I mean it solves a lot of the problems that if you were to try and do the cancelation token Promise stuff that came out a while back where we're trying to figure out how to cancel Promises. There's a lot more ceremony and just a lot more state tracking on your own that generators and even when I played with this last week, which is actually redux-observable which is an Rx-based middleware. It's built by, I think Ben Lesh and Jay Phelps from Netflix or... sorry, Jay is still at Netflix but anyway... You could use Rx, you could use generators. This really is just the escape valve for async and complex side effect programming that can't or shouldn't take place in the reducer because it's pure. It shouldn't take place necessarily in a component because one of the best pieces of advice I got when I was younger was, " Toran, make sure you do or delegate," and we're talking really about levels of depth in your methods at the simplest. But it applies here as well, which is I would love it if I had just a very declarative component and I didn't have to get into the weeds as I was looking at it about, is this a Promise? Is this Redux thunk, as they call it? Is this a generator or is it Rx? I don't even care in the component for the most part. I just need to know the name of the action and the arguments. If I'm having a problem with the Rx side of the generator, I'll go into the middleware and work from that particular abstraction but you can see the benefits of the seam there. CHARLES: Are the middlewares match on the action payload in the same way that the reducers do? Is that fair to say? TORAN: That is fair and I will warn. If that seems very strange, you're probably not alone. In fact, the first time I did this with redux-saga, I was dispatching, only to turn around then dispatch again. It feels very strange the first time but again, keeping in mind that you're really trying to have a separation from the work that is side effect and the work that is pure. The first action in that scenario, we'll call it remove-saga because it's actually going to fire something to a middleware. That work is all going to be network-heavy and it's not really as easily undo-redo because it's not pure. But the second event invoked from the actual middleware itself that says, "Remove item. Here's the ID. We're good." That work could be undone-redone all day because it hits the reducer, which is sure you can in and out. CHARLES: It sounds like basically the middleware is allowing you to have a branching flow structure because they all do involve more actions getting dispatched back to the store to record any bookkeeping that needs to happen as part of that. If you want to set some spinner state, that will be an action that gets dispatched. But in terms of sync, they allow you to set up sequences of actions or if you basically have one action that will actually get resolved as ten actions or something like that. If you think about an asynchronous process, you have the action that starts it but that might end up being composed of five different actions, right? Like I want to set the application into some state that knows that I've started my delete and that means I want to show like the spinner. Then at some later point, I might want to show progress like this deletes really taking a long time and I might want to dispatch five different actions indicating each one of those little bits of progress. Then finally, I might want to say it's done or it fails so really those got decomposed into 10 actions or five actions or whatever so the middleware is really where you do that, where you decompose high level actions into smaller actions? Or it's one of the places? Is that a correct understanding? TORAN: Yeah, I think if you're an old school developer for a minute, it will cater to the audience that maybe came from early 2000s backend dev. Now, they're still pretty current in web dev. I see it talked about as business logic. I feel like this is really the bulk of the complex work, especially if you're using Rx. You're actually creating these declarative pipelines for the events to flow through. My components are much thinner by comparison. They're truly just fire off this action with the information to kick the async pipeline but in the async piece of it, there's a lot more work happening and that's I think because there's a lot of complexity in async programming. CHARLES: Right, and it's almost like with the reducers then, there's not so much business logic because you're just resolving the implications of the new state. Is that fair to say? It's like now we've got this information, what does this imply directly? TORAN: Yeah, I think there is this old [inaudible] thing where they're talking about what's should be thick. You know, thick controllers or thick models, what should it be? Of course, we never want 'thick' anything, is the right answer, I think. But the apps on building today, I feel like if any was thick-er -- a measure of degree bigger in effort or work -- it is these middleware components right now. I think the nature of what you describe, which is the reducer is not supposed to be doing anything complex. It's literally taking a piece of data in, producing a new piece of data out. Logically thinking about that takes much less effort, I think than the human brain applies to async programming in JavaScript. CHARLES: Right. I think it makes sense and some of these things are just going to be necessarily gnarly and hairy because that's where the system is coupled. I can't say anything about whether the delete succeeded or failed until I've actually fired off the request. Those are implicitly sequenced. There has to be some glue or some code declaring that those things are sequenced. That has to be specified somewhere, whereas theoretically with your reducers, you could just run them all in parallel, even. If JavaScript supported multithreading, there's absolutely no dependency between those bits of code. TORAN: I think so, yeah. I think there are still some challenges because in the reducer sometimes. We can talk about this in a few minutes but you may actually be changing several top level pieces of the tree. If you're de-normalizing, which is what we probably should touch on next, there are some cases where you want to be a little careful but like you said, generically immutable programming enables multithreading. We're not touching the same piece of state at same time. CHARLES: Right as long as that piece of state that you're touching, like you need to resolve the leaf nodes of the tree first but at any siblings, I guess is what I'm saying on there, ought to be able to be resolved in parallel. It's more an exercise in theory or just a way of thinking about it because like why you're able to do those reducers as kind of these pure functions is because there's no dependency between them. I guess I'm just trying to point out that to wrap my head around, there are places where there are just clear sequences and dependencies and those are things that would be in the middleware. TORAN: Gotcha. I came a little scared of service worker. [Laughter] CHARLES: Actually a great point is what kind is the analogous -- if there is anything analogous -- in Ember today that's fulfilling the role of middleware. What's the migration path? What's the alternative, just trying to explore like where you might be able to use these techniques that we've been describing inside your app? TORAN: I think, at least my look at it has been a service injected into a service, which sounds completely bad or sounds broken the first time you see because you're like, "We're injecting a service into an existing service." I say that because, for me at least there is a top level service that owns the data and provides read-only attributes but there should be some other piece of code -- not the component -- that is doing this asynchronous complex processing, we just talk about as middleware, that is often a different service than the service that owns the state add-on. That's what I meant by service-injected. There's some Ember service whose job is to manage the complexity and probably ended up in middleware from the Redux perspective or ember-concurrency is literally solving that in my opinion. They do a lot for you: solving the async problem generally and I haven't dug into ember-concurrency enough to know. The pipeline stuff, I think which you guys talked about, which is an RFC, that may have eventually be what I consider the Rx or redux-saga of the middleware today. CHARLES: Right. I think ember-concurrency is just absolutely fantastic but it is a hairy problem but there's some overlap in terms of what it is solving. I think that is interesting. I guess a case where you would use middleware would be anywhere that you would use ember-concurrency. I think the interesting thing to compare in contrast there is one of maybe advantages or disadvantages -- let's just call it a tradeoff -- is that with ember-concurrency, you have this middleware that is associated with an object. It's associated usually with a component or a route. When things happen to that component, you're able to affect your ember-concurrency process but it does mean, these things are sprinkles throughout your application and the rules that are governing them can be really different, depending on which part you're operating in or just because sometimes you're using them on a route. Sometimes, you're doing it on a component. Sometimes, you're doing it on a service, whereas with the putting in the middleware, it sounds like they're going to all be in one particular place. All right. Let's move on from the simple to the more complex because that's where it's at. We've talked about modeling async processes, we've talked about handling state transitions and all that, nothing typifies that more profoundly in Ember community than Ember Data as just a foundation for state and syncing it over to the network. Love it or hate it, it's very popular. What are the things that you do in ember-redux land? One, is it fundamentally incompatible with Ember Data or is it just more easily served with other alternatives? How do you handle those foundational interactions, those fun foundational async loading network interactions with Ember Data, just using an ember-redux? TORAN: Yeah, for myself, I don't have an experience actually using the two together on purpose. There is a gentleman who did a talk sometime last year and I'll dig up the YouTube clip for you guys, where he talked about his approach where you would actually produce new states so it's still Redux friendly. Ember Data itself just be a new Ember Data model, every time you transformed it. But one of the tricky points is the philosophy of both so in Ember Data, you're just invoking set on everything and not just how it works. That's how the events bubble through the system as you re-render. You never actually create a new state of the system that's a copy, minus or plus, other attributes. You just always touching a single source of truth. I felt like that was always a sticking point. Anyway, Thomas who did this talk and I'll point you guys to it, did a great job of saying like, "Look, if you're stuck in this world with a lot of Ember Data, you're having some pain points with it and you want to try Redux to see if this alleviates those by not changing the state, here is a middle ground," which he did, I think a fabulous job driving it out. Although I must admit, there's got to be some challenges in there just because of the philosophical difference between the two. CHARLES: Yeah. It definitely sounds like there's some challenges but I'm actually pretty eager to go and watch that, to see what they came up with. If you're using these snapshot states of your Ember objects, would it be possible then to take all of your save, delete records, even query and have them inside of middlewares like have a redux-saga for every single operation you want to take on the Ember Data store. TORAN: The example he showed is basically the best of both worlds. You don't want to ember-mutate so he has a special bit of code to do that. But because the rest of it is vanilla Ember, you could drop in concurrency if you want to do the saga-type generator stuff. But you could also just make your changes as you would otherwise. You use the adapters, you fetch, you save, you delete, whatever you want to do for the most part. It saves a lot on the de-normalized side, which you would have to do manually. You don't write any Ajax code, which you have to do manually on the Redux side. I think there are benefits if someone could get it to work where you're just not changing the state of Ember Data, which may actually just be the future Ember Data at some point as well. CHARLES: It sounds like there is a pathway forward if that's the way that you want to go and the road that you want to walk so we'll look for that in the show notes. But my question then is, you're here on the podcast, what do you do? TORAN: I do want to have one disclaimer here, just so that I'm not a complete poser but I am. If you guys don't know this, I'm not trying to hide this from the community but I don't work on ember-redux at work. I don't have a side gate, making money with it. I don't use it ever. I literally just build examples to try stuff out. There's both a blessing and a curse of that. The curse is that you're asking, "Hey, Toran, you're the author. How does this work, man?" I can give you my run at it which I will but there is the other side which is very clear is that I have not built and shipped Facebook -- the current company I'm with -- with X million people hitting every month. We're not using it. This isn't exactly 'Toran-stamp of approval' here but I do mess around with -- this week in particular -- Rx which I like. I think Rx is just something that it changes the way you think about the way programming, especially async programming works. I definitely cannot comment much on Rx other than I like Alex's challenge to the community on your podcasting. Go use Rx, even if you use ember-concurrency or don't use ember-concurrency, how to break your brain. It will be for the better. Actually, Jay did a mini code review with me because my first pass at Rx was just using the fetch-promise because I was like, "I want Rx for side effect modeling but I wanted to still work with Ember acceptance testing," because I still feel like Ember is leading in that way, as you guys talk about in podcast recently. What was really cool is actually there's a shim that obviously Rx has its own little Ajax thing but it is not actually Promise-based. The advantage of this that Jay called out is in the Promise-based, where I'm using ember-fetch, let's say and I'm just wrapping it with Rx, those Promises are still not really cancel-able so what Jay was warning me about is like, "If you're going to use this quick and dirty, great. but in a real app, these will still queue up in Chrome or IE and block the amount of network requests you can actually make," so don't use Promises, even though they're very familiar. Use this operator, I think it is or a helper inside Rx which is the Ajax non-Promise-based operator. Long story short though, there's a good amount of work involved that grass is greener. In Ember Data, if you've ever used 'belongs-to' or 'has-many', you have done the most magical thing right there. In all the right ways, it is amazing because once you're in Redux and you're like, "I have this very nested object wrap," but Redux isn't meant to operate on this nested object wrap. It's meant to operate on this single tree structure, at these many top level entities as I can. As a project that's pretty popular in React called normalizer, you will likely use this project eventually. Maybe, not your first 'Hello, world', but you'll use this to actually break apart or truly de-normalized the structure. What that does a lot of times is if you have a blog with comments nested all inside of it from your JSON API call or your GraphQL call, that's fine coming from the network. But since you're going to have different components listening for just the comments, maybe or different components that just listen and re-render when the blog name changes and they don't care about the comments, you want to actually de-structure that so you have a separate blog top level item and you have a separate comments top level item. They're still related so the blog can get through its comments and vice versa as belongs-to and has-many works in Ember Data but you've got to do that work now. There is, of course magical projects like redux-orm that I just can't speak to how well they work or don't work but they try and solve the more Ember Data, look at the problem which has define this and there's the RM take care of the magic for you. I actually don't mind normalizer. It's just something people should be aware of because it's more work. You've got to break that apart yourself, just as much as writing your own network requests. You're, hopefully not going to duplicate Ajax all over the place but you will have to do the work that you otherwise do not do in Ember Data for sure. CHARLES: It's very interesting. If you look at the Ember Data internals, it sounds like the Ember Data store is actually structured very similarly to the way you had structure a Redux store using something like normalizer where you have these top level collections and then some mechanism to both declare and then compute the relationships between these collections of top level objects. But I want to go back to your other point too. I just wanted to say this. Toran, you know, don't sell yourself short because you give an incredible amount of time, an incredible amount of support to the community. You're very active in the Ember Redux channel. When problems come up, you think about them, you fix them. Even if you're not actually watering the trees, you're planting the seeds. I think that's actually great. I think that is a very valuable and necessary role in any community is to have people who are essentially the Johnny Appleseed of a particular technology. I think you go around and you throw these seeds around and see where they take root, even if you're not there. You're on to the next shady lane to plant seeds, rather than stay and enjoy the shade and the fruit of the apple trees. TORAN: Yeah. I appreciate your kind words there because a couple of years ago, I got into open source because it provides good personal branding. It's like, "This project, it's Toran's. We should hire Toran." It just makes you look more from that perspective. It also gives you almost a way to skip out on tough interviews at times if people are like, "This guy have a decent program. Let's take a look at his PR. He communicates with other humans online." It gets rid of some of that. But there is a dark side. We don't talk about it because there is an upside to it, especially for consulting but the dark side can be time commitment: how much bandwidth do you have outside of your family life, your hobby, if you have one and any other open source or work-related stuff that you already have to do. For me, this is really an exercise in thought leader-y stuff. I saw the benefits of this. It made my Ember better. Even if I wasn't using Redux, it just made the Ember code I wrote at work better. It inspired me to look at different things like ember-concurrency and Rx, things that are just way out of my comfort zone two years ago. I think those are all the benefits that come with it but the easiest part is got to be some value from it. The juice is it worth the squeeze. I think the community we've built and the people using it and the problems we're solving are all definitely worth the squeeze. CHARLES: It definitely is and you can tell from the vibrancy of that community that a lot of people are experiencing that value from it. To your point, I think something that is often lost on people is that you can actually use a project without actually using it. I think that there might be many people, for example in the Ember community that have never use React but are actually in fact using it because of the wonderful patterns that have come out and it's brought to the fore. I had thought about immutability, certainly on the server side but I had thought about it really deeply on the client side until a library like React came along and people started talking about it. I would say before we actually started using React the library, we were using it in thought. You touched on that when you were saying, "It's changed the way I think, it's changed the way I code." Even it's changed the way that I do things at work, in fact you're using it in spirit, if not the actual structure but I almost feel like that's more important. It's longer-lasting and has a greater impact on you, 10 years down the road or even five years down the road when neither of the technologies that we're actually talking about today are even going to be in wide use. TORAN: Yeah, that's true. In fact the one thing I would call out that people check out, I think Alex mentioned this or at least you guys have to talked about it in passing but definitely, sometime this weekend, watch the Simple Made Easy talk by Rich Hickey. It will definitely make you think differently, regardless of the simple side or the easy side that you follow on, projects of course make tradeoffs both sides of that but it is a great talk. Especially, if someone who's been programming six months or a year or two years, they're going to get huge benefit from it, just as much as someone older like myself who has got 10 plus years in the biz. CHARLES: Yeah, I know. That is a fantastic talk. We need to link to it at every single show. TORAN: Exactly. CHARLES: Well, I think that is a fantastic note to end on so we will wrap it up. That's it from Frontside for this week. We're going to have you back, obviously Toran there's so much that we could cover. Six months down the road, we'll do part three but for now, that's it. Thank you, Wil. Thank you, Toran for podcasting with us this morning. TORAN: Thanks for having me on guys. I really appreciate it. CHARLES: Then everybody else, take it easy and we'll see you all next week.
Topic Vue.js with creator Evan You and Sarah Drasner Summary Vue.js is a JavaScript UI framework built to be approachable, versatile and performant. Its creator Evan You and the award winning writer of CSS-Tricks Sarah Drasner join us to discuss the creation of Vue.js, the beginner learning curve, how it handles data and animations, and how it differs from Angular and React. Panelists Evan You @youyuxi http://evanyou.me/ Sarah Drasner @sarah_edo https://sarahdrasnerdesign.com/ Host Ray Shan @rayshan https://shan.io Links Vue.js https://vuejs.org/ Angular https://angular.io/ Laravel https://laravel.com/ Object.defineProperty() https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperty Getter / setters in JavaScript http://speakingjs.com/es5/ch17.html#getters_setters http://exploringjs.com/es6/ch_classes.html#_getters-and-setters Animations in Angular https://angular.io/docs/ts/latest/guide/animations.html React Motion https://github.com/chenglou/react-motion Redux http://redux.js.org/ Vuex https://vuex.vuejs.org/ MobX https://mobx.js.org/ RxJS http://reactivex.io/ Ben Lesh https://twitter.com/BenLesh Chris Fritz https://github.com/chrisvfritz Evan’s Patreon https://www.patreon.com/evanyou Sarah’s CodePen http://codepen.io/sdras/ Upcoming VueConf in Poland, June 2017 https://conf.vuejs.org/
On today's episode, Charles Max Wood, Joe Eames, and Tracy Lee discuss Reactive Programming and RxJS with Ben Lesh. Ben works at Netflix and also has a side job for Rx Workshop with Tracy. He is the lead author of RxJS 5. Tune in to learn more about RxJS!
On today's episode, Charles Max Wood, Joe Eames, and Tracy Lee discuss Reactive Programming and RxJS with Ben Lesh. Ben works at Netflix and also has a side job for Rx Workshop with Tracy. He is the lead author of RxJS 5. Tune in to learn more about RxJS!
On today's episode, Charles Max Wood, Joe Eames, and Tracy Lee discuss Reactive Programming and RxJS with Ben Lesh. Ben works at Netflix and also has a side job for Rx Workshop with Tracy. He is the lead author of RxJS 5. Tune in to learn more about RxJS!
Episode notes and links available at: https://angularair.com/#episode-97 --- Support this podcast: https://anchor.fm/angularair/support
In this episode of the Modern Web podcast - Ben Lesh stars as the Jerry Springer of JavaScript stirs things up with the Polymer team Monica Dinculescu and Fred Schott with hard questions about louder voices representing Polymer on twitter and the reasoning behind perceived abrasiveness. Thankfully, no one gets pregnant in this episode and hard conversations are all in jest. The meat of this podcast is centered around the difference between Polymer and web components, composable components nested inside svg, where browsers are in supporting native custom elements, web components versus frameworks, the concept of using the platform, using Polymer in frameworks like Angular 2, the progression of the polymer-cli. Find more podcasts, videos, trainings and online conferences at http://modern-web.org or follow us on Twitter @modernweb_.
Netflix has a highly interactive user interface. As I move my mouse around the page, hovering over titles and inspecting movie descriptions, there is a lot going on under the hood. One component of this UI is RxJS, a library for building reactive JavaScript. Reactive programming uses the observer pattern to create objects that emit The post Reactive JavaScript with Ben Lesh appeared first on Software Engineering Daily.
1:50 - Introducing Jeff Whelpley at Angular Remote Conf Twitter Github Angular Air 3:40 - Working on Angular Air 6:25 - Lessons from Ben Lesh Episode Link 8:20 - Lessons from Gleb Bahmutov Episode Link 11:50 - Lessons from Aaron Frost Episode Link 14:00 - Lessons from Shai Reznik Episode Link 16:50 - Lessons from Joe Eames Episode Link 19:10 - Lessons from Uri Goldshtein 21:40 - Lessons from Wesley Cho and Jesus Rodriguez Episode Link 25:40 - Lessons from Brad Green 28:50 - Lessons from Igor Minar 31:40 - Lessons from Victor Savkin and Dan Abramov Episode Link 34:30 - Lessons from Amy Knight 36:05 - Lessons from Patrick Stapleton 39:00 - Lessons from Jamie King and Kyle Newman Fanboys movie Episode Link
1:50 - Introducing Jeff Whelpley at Angular Remote Conf Twitter Github Angular Air 3:40 - Working on Angular Air 6:25 - Lessons from Ben Lesh Episode Link 8:20 - Lessons from Gleb Bahmutov Episode Link 11:50 - Lessons from Aaron Frost Episode Link 14:00 - Lessons from Shai Reznik Episode Link 16:50 - Lessons from Joe Eames Episode Link 19:10 - Lessons from Uri Goldshtein 21:40 - Lessons from Wesley Cho and Jesus Rodriguez Episode Link 25:40 - Lessons from Brad Green 28:50 - Lessons from Igor Minar 31:40 - Lessons from Victor Savkin and Dan Abramov Episode Link 34:30 - Lessons from Amy Knight 36:05 - Lessons from Patrick Stapleton 39:00 - Lessons from Jamie King and Kyle Newman Fanboys movie Episode Link
1:50 - Introducing Jeff Whelpley at Angular Remote Conf Twitter Github Angular Air 3:40 - Working on Angular Air 6:25 - Lessons from Ben Lesh Episode Link 8:20 - Lessons from Gleb Bahmutov Episode Link 11:50 - Lessons from Aaron Frost Episode Link 14:00 - Lessons from Shai Reznik Episode Link 16:50 - Lessons from Joe Eames Episode Link 19:10 - Lessons from Uri Goldshtein 21:40 - Lessons from Wesley Cho and Jesus Rodriguez Episode Link 25:40 - Lessons from Brad Green 28:50 - Lessons from Igor Minar 31:40 - Lessons from Victor Savkin and Dan Abramov Episode Link 34:30 - Lessons from Amy Knight 36:05 - Lessons from Patrick Stapleton 39:00 - Lessons from Jamie King and Kyle Newman Fanboys movie Episode Link
Tracy Lee interviews Ben Lesh at React Rally. They discuss the React community compared to other JavaScript communities, which they boil down to being very similar to a “choose-your-own-adventure”. Important things to note in this podcast: The benefits and costs of new ES2015 features, Node’s position in the JavaScript ecosystem and how TC39 standards are affecting the node ecosystem, senior developers mentoring and making junior developers feel comfortable, the promises spec and cancellation tokens with observables. Other topics: how React trainings differ from Angular or Ember trainings, the new create-react-app and why it’s so amazing, the new screencast site Yolobrolo, and why @godtributes is the most amazing twitter bot ever. Ben also might have said that Dan Abramov is a React superstar, but you’ll have to listen to be sure. Tracy called out Ben on not wearing the hat that Sam Saccone’s mother purchased him. Find more podcasts, videos, trainings and online conferences at http://modern-web.org or follow us on Twitter @modernweb_.
Ben Lesh and Tracy Lee interview Ben Halpern, the "voice" behind the famous twitter handle, @ThePracticalDev. Did you know you can tweet The Practical Dev about your javascript homework? This podcast gives us a fun and quick view into what it's like behind the scenes as The Practical Dev. Learn about the organization and its the future. Hear stories about run-ins with Tim O'Reilly, the JavaScript community, and how why Sebastian McKenzie once blocked Jay Phelps on Twitter. Hint: It was Sam Saccone's fault. Find more podcasts, videos, trainings and online conferences at http://modern-web.org or follow us on Twitter @modernweb_.
In this episode I am joined by Ben Lesh, a senior software engineer at Netflix. Ben is one of the lead developers for RxJS, a reactive extension set for JavaScript, and a core component in the software stack at Netflix. Here we discuss everything from what is RxJS, to how it differs from common promises and callbacks in JavaScript. We also discuss who is using it and how it is playing a critical role in Angular 2. A writeup to this episode can be found via https://www.thepolyglotdeveloper.com/2016/08/asynchronous-event-based-programming-rxjs/ If you have questions that you'd like answered in the next episode, visit https://www.thepolyglotdeveloper.com/podcast-questions and fill out the form.
Ben Lesh and Tracy Lee interview Zabriskie’s Beard and Jamison Dance on the accidental creation of React Rally, how the JavaScript framework communities are organically formed based on the strength of the framework's opinions and exploration into why the react community exists in the form that it does. Also discussed are Power Rangers fighting bananas at React Rally, how redux is pushing the envelope for react developers to solve harder problems, and discussing the possibilities of a future react cli. Find more podcasts, videos, trainings and online conferences at http://modern-web.org or follow us on Twitter @modernweb_.
In this episode filmed at #ngconf, Jeff Cross and Alex Eagle fight over Ben Lesh and his awesomeness while wearing dino hoodies. The show begins with an angularjs tattoo branding of The Ben Lesh, then moves on to conversations around last minute bundling decisions for the Angular 2 RC and when RxJS will be incorporated in. Jeff, Alex, and Ben banter over TypeScript pros and cons (Ben doesn't hate TypeScript all the time), reveal the real reason that Ben Lesh is in all of Jeff Cross' talks, how to use operators and subscriptions in RxJS, decorators, antipatterns in RxJS, meta decorators, and the issues behind Angular 2 tree shaking and decorators. Find more podcasts, videos, trainings and online conferences at http://modern-web.org or follow us on Twitter @modernweb_.
In this Modern Web episode, Ben Lesh and Sam Saccone engage in a friendly debate on the merits of cancellable promises. They explore pros and cons of promises and how they trap errors in Node.js. Find more podcasts, videos, trainings and online conferences at http://modern-web.org or follow us on Twitter @modernweb_.
In this episode we explore contributing to the open source community, do's and don'ts for a beginner, and get the perspective of two well seasoned OSS contributors Ben Lesh and Zack Chapple. You can follow Ben Lesh @benlesh, Zack Chapple @zchapple, and Tracy Lee @ladyleet on Twitter. Find more podcasts, videos, trainings and online conferences at http://modern-web.org or follow us on Twitter @modernweb_.
In this podcast episode, we speak to Brandy Carney and Adam Bradley of the Ionic2 framework, what's coming down the pipeline, the Ionic CLI, what the integration with Angular 2 is shaping up to look like, and how they feel about Jeff Cross' beard and David East's ollie skills. Follow Brandy Carney (@brandyscarney), Adam Bradley (@adamdbradley), Ben Lesh (@benlesh), and myself Tracy Lee (@ladyleet) on Twitter for more JavaScript fun. Find more podcasts, videos, trainings and online conferences at http://modern-web.org or follow us on Twitter @modernweb_.
Matt Podcastwysocki brings us through the history of RxJS, thoughts on reactive streams, and tells you how he *really* feels about RxJS 5. Ben and Matt go back and forth on exploring conversations focused on backpressure, implementations of Rx in Ember, ES observables and the standardization process, and just overall how Rx makes your life as a developer better. Ben's favorite color will also be revealed in this podcast. It's a good one. Find more podcasts, videos, trainings and online conferences at http://modern-web.org or follow us on Twitter @modernweb_.
In the second episode of the Front End Happy Hour podcast, our special guest, Ben Lesh joins us to talk about all the great things in RxJS 5. Items mentioned in the episode: Rx Marbles Guests: Ben Lesh - @BenLesh Panelists: Brian Holt - @holtbt Jem Young - @JemYoung Ryan Anklam - @bittersweetryan Ryan Burgess - @burgessdryan Picks: Ben Lesh - Egghead.io Ben Lesh - Egghead.io - RxJS Creating Observables from Scratch Ryan Burgess - Netflix UIE YouTube Channel Ryan Burgess - Amazon Echo Augustus Yuan - Tilt Brush Jem Young - EcmaScript Proposals Ryan Anklam - VimCasts Ryan Anklam - Ready Player One Audibook Brian Holt - Factorio
In this podcast, Kent C. Dodds talks about JavaScript Air and the backlash he's experienced after leaving Angular Air, how he views learning frameworks, his favorite ES6 features, and how power poses play a significant role in his speaker life. Ben Lesh prods.Find more podcasts, videos, and online conferences at http://modern-web.org or follow us on Twitter @modernweb_.
Why are promises bad and observables good? Ben Lesh, lead on RxJS 5 talks to Taras Mankovski (@embersherpa) about how observables are the way of the future and why you should use them.Find more podcasts, videos, and online conferences at http://modern-web.org or follow us on Twitter @modernweb_.
Ben Lesh reveals all to Taras Mankovski (@embersherpa) and talks about frameworks at Netflix. Hear what he has to say about Angular vs Ember vs React at Netflix .Find more podcasts, videos, and online conferences at http://modern-web.org or follow us on Twitter @modernweb_.
What's new in RxJS 5.0? with Ben Lesh - RxJS is red hot right now in the JavaScript community and it is only going to get hotter once Angular 2 lands. Ben Lesh is a Senior UI Engineer at Netflix and is one of the core contributors to RxJS and has been focusing on the latest release (currently in beta) which is largely a rewrite. If you are unfamiliar with RxJS, join us to hear about the basics of Reactive Programming. If you have already started to us RxJS, join us to learn about all the cool changes coming with 5.0. This is one episode you are not going to want to miss! Panelists: Aimee Knight, Olivier Combe and PatrictJS Picks/Tips: Olivier - Everything is a Stream, Front end newsletter, A developer's guide to interviewing Aimee - Introduction to Reactive Programming - Egghead.io Jeff - Angular Universal Patrick - Read the Source: Angular Universal Ben - TC39 considered Observable spec, RxJS 5 repo, RxJS 5 docs, Netflix jobs and culture deck Angular Air is a video podcast all about Angular hosted by Jeff Whelpley. Please visit the Angular Air website (http://angularair.com) to see upcoming and past episodes. Also be sure to follow Angular Air on Twitter and Google+ to stay up to date with future episodes. Also, all episodes are on the YouTube channel as well. AngularClass Learn AngularJS, Angular 2, and Modern Web Development form the best. Looking for corporate Angular training, want to host us, or Angular consulting? twitter: @AngularClass email: info@angularclass.com chat: Join AngularClass Chat --- Support this podcast: https://anchor.fm/angularair/support
AngularConnect Track 1 Playlist Track 2 Playlist 02:30 - Going to Beta AngularConnect Keynote with Brad Green, Igor Minar and Jules Kremer 09:23 - Angular 1.x Angular 1.5 and beyond with Pete Bacon Darwin and Lucas Mirelmann 17:39 - Peter’s Thoughts as an Organizer of AngularConnect 26:33 - Highlights Routing in Eleven Dimensions with Component Router with Brian Ford Full Stack Angular 2 with Jeff Whelpley and Patrick Stapleton ngAnimate 2 0 with Matias Niemelä Testing Strategies with Angular 2 with Julie Ralph Ionic 2 Getting started in Angular 2 with Rado Kirov and Naomi Black Building apps with Firebase and Angular 2 with Sara Robinson 31:46 - Soft Skills Talks Becoming Betazoid How to Listen and Empathize with Others in the Workplace with Joe Eames Optimize Yourself 5 Key Traits of High Performing Humans with Sylvana Rochet Getting Comfortable Being Uncomfortable with Aimee Knight (Super)Power Management with Igor Minar @ ng-conf 2015 35:03 - What is the next big Angular Conference on the horizon? ng-conf 2016 36:09 - Going to Beta (Cont’d) Better Concepts, Less Code in Angular 2 with Victor Savin and Tobias Bosch 44:19 - NativeScript Building native mobile apps with Angular 2 0 and NativeScript with Sebastian Witalec 47:06 - Angular Cheat Sheet Tutorial: Tour of Heros - Angular 2 for TypeScript 49:54 - Material Design Joe’s List for ““talks to watch if you want to get up to date with Angular 2” AngularConnect Keynote with Brad Green, Igor Minar and Jules Kremer Angular 1.5 and beyond with Pete Bacon Darwin and Lucas Mirelmann Routing in Eleven Dimensions with Component Router with Brian Ford Getting started in Angular 2 with Rado Kirov and Naomi Black Angular 2 Data Flow with Jeff Cross and Alex Rickabaugh Better Concepts, Less Code in Angular 2 with Victor Savin and Tobias Bosch Google Angular Team Panel Joe’s Additional Recommendations Using Web Workers for More Responsive Apps with Jason Teplitz Building native mobile apps with Angular 2 0 and NativeScript with Sebastian Witalec Reactive Streams in Angular 1 and 2 Ben Lesh Suggest topics and guests! Contribute to the repo aiatopics! Picks AngularConnect (Joe) Denmark (Joe) Star Wars: The Force Awakens Trailer (Official) (John) Ultimate t-shirt for trolling science fiction fans (Chuck) Rush Revere and the Brave Pilgrims by Rush Limbaugh (Chuck) The Magician's Nephew by C. S. Lewis (Chuck) MONEY Master the Game: 7 Simple Steps to Financial Freedom by Tony Robbins (Chuck)
AngularConnect Track 1 Playlist Track 2 Playlist 02:30 - Going to Beta AngularConnect Keynote with Brad Green, Igor Minar and Jules Kremer 09:23 - Angular 1.x Angular 1.5 and beyond with Pete Bacon Darwin and Lucas Mirelmann 17:39 - Peter’s Thoughts as an Organizer of AngularConnect 26:33 - Highlights Routing in Eleven Dimensions with Component Router with Brian Ford Full Stack Angular 2 with Jeff Whelpley and Patrick Stapleton ngAnimate 2 0 with Matias Niemelä Testing Strategies with Angular 2 with Julie Ralph Ionic 2 Getting started in Angular 2 with Rado Kirov and Naomi Black Building apps with Firebase and Angular 2 with Sara Robinson 31:46 - Soft Skills Talks Becoming Betazoid How to Listen and Empathize with Others in the Workplace with Joe Eames Optimize Yourself 5 Key Traits of High Performing Humans with Sylvana Rochet Getting Comfortable Being Uncomfortable with Aimee Knight (Super)Power Management with Igor Minar @ ng-conf 2015 35:03 - What is the next big Angular Conference on the horizon? ng-conf 2016 36:09 - Going to Beta (Cont’d) Better Concepts, Less Code in Angular 2 with Victor Savin and Tobias Bosch 44:19 - NativeScript Building native mobile apps with Angular 2 0 and NativeScript with Sebastian Witalec 47:06 - Angular Cheat Sheet Tutorial: Tour of Heros - Angular 2 for TypeScript 49:54 - Material Design Joe’s List for ““talks to watch if you want to get up to date with Angular 2” AngularConnect Keynote with Brad Green, Igor Minar and Jules Kremer Angular 1.5 and beyond with Pete Bacon Darwin and Lucas Mirelmann Routing in Eleven Dimensions with Component Router with Brian Ford Getting started in Angular 2 with Rado Kirov and Naomi Black Angular 2 Data Flow with Jeff Cross and Alex Rickabaugh Better Concepts, Less Code in Angular 2 with Victor Savin and Tobias Bosch Google Angular Team Panel Joe’s Additional Recommendations Using Web Workers for More Responsive Apps with Jason Teplitz Building native mobile apps with Angular 2 0 and NativeScript with Sebastian Witalec Reactive Streams in Angular 1 and 2 Ben Lesh Suggest topics and guests! Contribute to the repo aiatopics! Picks AngularConnect (Joe) Denmark (Joe) Star Wars: The Force Awakens Trailer (Official) (John) Ultimate t-shirt for trolling science fiction fans (Chuck) Rush Revere and the Brave Pilgrims by Rush Limbaugh (Chuck) The Magician's Nephew by C. S. Lewis (Chuck) MONEY Master the Game: 7 Simple Steps to Financial Freedom by Tony Robbins (Chuck)
AngularConnect Track 1 Playlist Track 2 Playlist 02:30 - Going to Beta AngularConnect Keynote with Brad Green, Igor Minar and Jules Kremer 09:23 - Angular 1.x Angular 1.5 and beyond with Pete Bacon Darwin and Lucas Mirelmann 17:39 - Peter’s Thoughts as an Organizer of AngularConnect 26:33 - Highlights Routing in Eleven Dimensions with Component Router with Brian Ford Full Stack Angular 2 with Jeff Whelpley and Patrick Stapleton ngAnimate 2 0 with Matias Niemelä Testing Strategies with Angular 2 with Julie Ralph Ionic 2 Getting started in Angular 2 with Rado Kirov and Naomi Black Building apps with Firebase and Angular 2 with Sara Robinson 31:46 - Soft Skills Talks Becoming Betazoid How to Listen and Empathize with Others in the Workplace with Joe Eames Optimize Yourself 5 Key Traits of High Performing Humans with Sylvana Rochet Getting Comfortable Being Uncomfortable with Aimee Knight (Super)Power Management with Igor Minar @ ng-conf 2015 35:03 - What is the next big Angular Conference on the horizon? ng-conf 2016 36:09 - Going to Beta (Cont’d) Better Concepts, Less Code in Angular 2 with Victor Savin and Tobias Bosch 44:19 - NativeScript Building native mobile apps with Angular 2 0 and NativeScript with Sebastian Witalec 47:06 - Angular Cheat Sheet Tutorial: Tour of Heros - Angular 2 for TypeScript 49:54 - Material Design Joe’s List for ““talks to watch if you want to get up to date with Angular 2” AngularConnect Keynote with Brad Green, Igor Minar and Jules Kremer Angular 1.5 and beyond with Pete Bacon Darwin and Lucas Mirelmann Routing in Eleven Dimensions with Component Router with Brian Ford Getting started in Angular 2 with Rado Kirov and Naomi Black Angular 2 Data Flow with Jeff Cross and Alex Rickabaugh Better Concepts, Less Code in Angular 2 with Victor Savin and Tobias Bosch Google Angular Team Panel Joe’s Additional Recommendations Using Web Workers for More Responsive Apps with Jason Teplitz Building native mobile apps with Angular 2 0 and NativeScript with Sebastian Witalec Reactive Streams in Angular 1 and 2 Ben Lesh Suggest topics and guests! Contribute to the repo aiatopics! Picks AngularConnect (Joe) Denmark (Joe) Star Wars: The Force Awakens Trailer (Official) (John) Ultimate t-shirt for trolling science fiction fans (Chuck) Rush Revere and the Brave Pilgrims by Rush Limbaugh (Chuck) The Magician's Nephew by C. S. Lewis (Chuck) MONEY Master the Game: 7 Simple Steps to Financial Freedom by Tony Robbins (Chuck)
Ben Lesh is a senior UI engineer at Netflix, where he works on projects that use reactive programming in JavaScript to manage massive amounts of data. Ben talks with me about a variety of topics, focusing on reactive programming and data stream processing. Ben also gives his advice to you, whether you are a young developer or well into your career. Make sure you Tweet at Ben at https://twitter.com/benlesh and thank him for coming on the show! Today's episode is sponsored by DigitalOcean. Go to https://digitalocean.com to get started, and use the promo code "DeveloperTea" on the billing page after you create your account to get a $10 credit!
Ben Lesh is a senior UI engineer at Netflix, where he works on projects that use reactive programming in JavaScript to manage massive amounts of data. Ben talks with me about a variety of topics, focusing on reactive programming and data stream processing. Ben also gives his advice to you, whether you are a young developer or well into your career. Make sure you Tweet at Ben at https://twitter.com/benlesh and thank him for coming on the show!
© 2020-2025 Ivy Podcast Discovery LLC
