Podcasts about lodash

Play Episode Listen Later Sep 26, 2019 68:04

Mike North is the Ember guy at Frontend Masters and LinkedIn’s web developer trainer. Today the panel is talking about the upcoming Ember update, which Mike calls a total reinvention of the way you build with Ember. Finally, they are letting go of the cruft and stuff they had to hold on to in order to support IE8 and using modern interface The panel talks about some of the issues with IE8, and agree that the reason Ember felt its age because it was built for IE8. Ember 314 is moving from the past into the present, a sleek modern way to build apps. Mike talks about how easy the new Ember is to use. Mike talks about the excitement in the Ember community because the new build is focused on stability and seamlessness. Charles talks about his less seamless experience with the Angular community. For context, Mike North’s first frontend masters course was recorded in 2014, and he’s only had to change two lines of code. Ember is the only framework that has managed to go all the way from IE7/IE8 to today without a major gap,breaks, or rewrites. They transition to talking about what keeps Ember going. There is an effort to make sure things are decentralized and not tied to any specific company, although Apple, Netflix, Nasa, and PlaysStation all use it. LinkedIn has also been hiring Ember core member to continue working on it, and sponsoring open source work. Next, they talk about how Ember works with TypeScript. You can install an Ember add on with one terminal command that will enable TypeScript in an Ember app.There are some issues that could cause misalignment with JavaScript and TypeScript, but Ember has designed things around it. MIke talks about the major change in the learning curve with using Ember and how far Vanilla JS will take you. Overall, it is a lot more approachable than it used to be. They move on to talk about the availability of third party solutions with Ember. Mike assures them that Ember has add-ons, and parts of the framework are opening up to allow experimentation with components. There are lots of ways to make Ember your own without running the risk of diverging, giving more flexibility than ever while maintaining the happy path. Testing within Ember is also a priority, and they want the code to be as readable as possible. The last topic discussed in this show is the importance of developer education. LinkedIn looks at employment numbers and the rate at which new jobs open, and software engineering is growing like crazy and will likely continue to grow.The rate at which new people are graduating with computer science and programming degrees, as well as those from unconventional backgrounds, is not keeping up with the number of jobs. This means that there will be fewer senior people spread across bigger groups of developers with less experience. The panel agrees that it is the responsibility of people who have been around or learned something period to pass on the knowledge because the more knowledge is passed on, the more stable things will remain as seniors become more scarce. It is also important for companies to level up junior developers. They conclude by talking about tools available for people who want to learn more about Ember Octane, and Mike makes an open request to the JS community. Panelists Charles Max Wood Steve Emmerich Chris Ferdinandi Aimee Knight AJ O’Neal Christopher Buecheler With special guest: Mike North Sponsors React Native Radio Sentry use the code “devchat” for 2 months free on Sentry’s small plan Dev Ed Podcast Links Ember Frontend Masters IE8 Ember Octane Sprout Core TypeScript ES6 Lodash Mocha Backstop.js Semver https://twitter.com/thefalken/status/1177483501777473537 Follow DevChatTV on Facebook and Twitter Picks Chris Ferdinandi: Vanilla JS Academy, get 30% off with code ‘jsjabber’ leanweb.dev Steve Emmerich: 123 Magic RGDK Aimee Knight: Recursion blog post Wholesome Provisions Protein Cereal AJ O’Neal: Carby V2 by Insurrection Industries GameCube Mods Charles Max Wood: Nikon D5600 Rode Newsshooter Viltrox light panel Quest Nutrition pumpkin bars Christopher Buecheler: Tool’s Fear Inoculum on Apple Music, Spotify, and Google Play Mike North: Github Universe Github Tracer Bench Follow Mike @mike-north on Github, @northm on LinkedIn, and @michaellnorth on Twitter

JSJ 395: The New Ember with Mike North

Play Episode Listen Later Sep 26, 2019 68:04

Mike North is the Ember guy at Frontend Masters and LinkedIn’s web developer trainer. Today the panel is talking about the upcoming Ember update, which Mike calls a total reinvention of the way you build with Ember. Finally, they are letting go of the cruft and stuff they had to hold on to in order to support IE8 and using modern interface The panel talks about some of the issues with IE8, and agree that the reason Ember felt its age because it was built for IE8. Ember 314 is moving from the past into the present, a sleek modern way to build apps. Mike talks about how easy the new Ember is to use. Mike talks about the excitement in the Ember community because the new build is focused on stability and seamlessness. Charles talks about his less seamless experience with the Angular community. For context, Mike North’s first frontend masters course was recorded in 2014, and he’s only had to change two lines of code. Ember is the only framework that has managed to go all the way from IE7/IE8 to today without a major gap,breaks, or rewrites. They transition to talking about what keeps Ember going. There is an effort to make sure things are decentralized and not tied to any specific company, although Apple, Netflix, Nasa, and PlaysStation all use it. LinkedIn has also been hiring Ember core member to continue working on it, and sponsoring open source work. Next, they talk about how Ember works with TypeScript. You can install an Ember add on with one terminal command that will enable TypeScript in an Ember app.There are some issues that could cause misalignment with JavaScript and TypeScript, but Ember has designed things around it. MIke talks about the major change in the learning curve with using Ember and how far Vanilla JS will take you. Overall, it is a lot more approachable than it used to be. They move on to talk about the availability of third party solutions with Ember. Mike assures them that Ember has add-ons, and parts of the framework are opening up to allow experimentation with components. There are lots of ways to make Ember your own without running the risk of diverging, giving more flexibility than ever while maintaining the happy path. Testing within Ember is also a priority, and they want the code to be as readable as possible. The last topic discussed in this show is the importance of developer education. LinkedIn looks at employment numbers and the rate at which new jobs open, and software engineering is growing like crazy and will likely continue to grow.The rate at which new people are graduating with computer science and programming degrees, as well as those from unconventional backgrounds, is not keeping up with the number of jobs. This means that there will be fewer senior people spread across bigger groups of developers with less experience. The panel agrees that it is the responsibility of people who have been around or learned something period to pass on the knowledge because the more knowledge is passed on, the more stable things will remain as seniors become more scarce. It is also important for companies to level up junior developers. They conclude by talking about tools available for people who want to learn more about Ember Octane, and Mike makes an open request to the JS community. Panelists Charles Max Wood Steve Emmerich Chris Ferdinandi Aimee Knight AJ O’Neal Christopher Buecheler With special guest: Mike North Sponsors React Native Radio Sentry use the code “devchat” for 2 months free on Sentry’s small plan Dev Ed Podcast Links Ember Frontend Masters IE8 Ember Octane Sprout Core TypeScript ES6 Lodash Mocha Backstop.js Semver https://twitter.com/thefalken/status/1177483501777473537 Follow DevChatTV on Facebook and Twitter Picks Chris Ferdinandi: Vanilla JS Academy, get 30% off with code ‘jsjabber’ leanweb.dev Steve Emmerich: 123 Magic RGDK Aimee Knight: Recursion blog post Wholesome Provisions Protein Cereal AJ O’Neal: Carby V2 by Insurrection Industries GameCube Mods Charles Max Wood: Nikon D5600 Rode Newsshooter Viltrox light panel Quest Nutrition pumpkin bars Christopher Buecheler: Tool’s Fear Inoculum on Apple Music, Spotify, and Google Play Mike North: Github Universe Github Tracer Bench Follow Mike @mike-north on Github, @northm on LinkedIn, and @michaellnorth on Twitter

JSJ 395: The New Ember with Mike North

Play Episode Listen Later Sep 26, 2019 68:04

Mike North is the Ember guy at Frontend Masters and LinkedIn’s web developer trainer. Today the panel is talking about the upcoming Ember update, which Mike calls a total reinvention of the way you build with Ember. Finally, they are letting go of the cruft and stuff they had to hold on to in order to support IE8 and using modern interface The panel talks about some of the issues with IE8, and agree that the reason Ember felt its age because it was built for IE8. Ember 314 is moving from the past into the present, a sleek modern way to build apps. Mike talks about how easy the new Ember is to use. Mike talks about the excitement in the Ember community because the new build is focused on stability and seamlessness. Charles talks about his less seamless experience with the Angular community. For context, Mike North’s first frontend masters course was recorded in 2014, and he’s only had to change two lines of code. Ember is the only framework that has managed to go all the way from IE7/IE8 to today without a major gap,breaks, or rewrites. They transition to talking about what keeps Ember going. There is an effort to make sure things are decentralized and not tied to any specific company, although Apple, Netflix, Nasa, and PlaysStation all use it. LinkedIn has also been hiring Ember core member to continue working on it, and sponsoring open source work. Next, they talk about how Ember works with TypeScript. You can install an Ember add on with one terminal command that will enable TypeScript in an Ember app.There are some issues that could cause misalignment with JavaScript and TypeScript, but Ember has designed things around it. MIke talks about the major change in the learning curve with using Ember and how far Vanilla JS will take you. Overall, it is a lot more approachable than it used to be. They move on to talk about the availability of third party solutions with Ember. Mike assures them that Ember has add-ons, and parts of the framework are opening up to allow experimentation with components. There are lots of ways to make Ember your own without running the risk of diverging, giving more flexibility than ever while maintaining the happy path. Testing within Ember is also a priority, and they want the code to be as readable as possible. The last topic discussed in this show is the importance of developer education. LinkedIn looks at employment numbers and the rate at which new jobs open, and software engineering is growing like crazy and will likely continue to grow.The rate at which new people are graduating with computer science and programming degrees, as well as those from unconventional backgrounds, is not keeping up with the number of jobs. This means that there will be fewer senior people spread across bigger groups of developers with less experience. The panel agrees that it is the responsibility of people who have been around or learned something period to pass on the knowledge because the more knowledge is passed on, the more stable things will remain as seniors become more scarce. It is also important for companies to level up junior developers. They conclude by talking about tools available for people who want to learn more about Ember Octane, and Mike makes an open request to the JS community. Panelists Charles Max Wood Steve Emmerich Chris Ferdinandi Aimee Knight AJ O’Neal Christopher Buecheler With special guest: Mike North Sponsors React Native Radio Sentry use the code “devchat” for 2 months free on Sentry’s small plan Dev Ed Podcast Links Ember Frontend Masters IE8 Ember Octane Sprout Core TypeScript ES6 Lodash Mocha Backstop.js Semver https://twitter.com/thefalken/status/1177483501777473537 Follow DevChatTV on Facebook and Twitter Picks Chris Ferdinandi: Vanilla JS Academy, get 30% off with code ‘jsjabber’ leanweb.dev Steve Emmerich: 123 Magic RGDK Aimee Knight: Recursion blog post Wholesome Provisions Protein Cereal AJ O’Neal: Carby V2 by Insurrection Industries GameCube Mods Charles Max Wood: Nikon D5600 Rode Newsshooter Viltrox light panel Quest Nutrition pumpkin bars Christopher Buecheler: Tool’s Fear Inoculum on Apple Music, Spotify, and Google Play Mike North: Github Universe Github Tracer Bench Follow Mike @mike-north on Github, @northm on LinkedIn, and @michaellnorth on Twitter

RRU 070: Drawing the Line Between 3rd Party and Custom Code with Glenn Reyes

React Round Up

Play Episode Listen Later Jul 16, 2019 43:57

Sponsors Netlify Sentry use the code “devchat” for 2 months free on Sentry’s small plan Triplebyte offers a $1000 signing bonus Panel Lucas Reis David Ceddia Leslie Cohn-Wein With special guest: Glenn Reyes Episode Summary Special guest Glenn is a software programmer based in Vienna, Austria and has been working in programming since 2013. He is the creator of the Graphpack library. Today the panel discusses how to choose between picking a 3rd party or handcraft component in React. They discuss the popular notion to avoid “reinventing the wheel” and always using 3rd party components. Glenn gives advice on approaching the decision between 3rd party components or making it yourself, including considering time constraints, risks of using premade components, and the popularity of the library and how up-to-date it is. It is also important to understand the big picture of your project and know what already exists that could be of use. The panel discusses different indicators of how well kept up a library is. Glenn talks about situations when his library Graphpack would come in handy. He advises listeners to always test software before purchasing it. The panel talks about the issue of being able to change a component later if it doesn’t work. They agree that it’s important to consider the end goal and what other people on the team need when choosing whether to use 3rd party or custom make your code. Some decision will be your companion for years and years, like what language your project is written in. Glenn suggests that when you are trying something new, try it out in a clear and isolated experiment, something React is very useful for. Last, it is important to leave notes for future developers as to why you made the decision you did Links Lodash Moment library Graphpack Elm Follow DevChat on Facebook and Twitter Picks David Ceddia: boringtechnology.club Leslie Cohn-Wein: The Ladybug Podcast Big Green Egg Lucas Reis: Top 20 CSS Navigation Menus Glenn Reyes: Lydia Hallie Instagram

code panel austria react reyes elm 3rdparty sentry drawing the line netlify big green egg triplebyte lodash devchattv lucas reis

RRU 070: Drawing the Line Between 3rd Party and Custom Code with Glenn Reyes

Syntax - Tasty Web Development Treats

Play Episode Listen Later Jul 16, 2019 43:57

Sponsors Netlify Sentry use the code “devchat” for 2 months free on Sentry’s small plan Triplebyte offers a $1000 signing bonus Panel Lucas Reis David Ceddia Leslie Cohn-Wein With special guest: Glenn Reyes Episode Summary Special guest Glenn is a software programmer based in Vienna, Austria and has been working in programming since 2013. He is the creator of the Graphpack library. Today the panel discusses how to choose between picking a 3rd party or handcraft component in React. They discuss the popular notion to avoid “reinventing the wheel” and always using 3rd party components. Glenn gives advice on approaching the decision between 3rd party components or making it yourself, including considering time constraints, risks of using premade components, and the popularity of the library and how up-to-date it is. It is also important to understand the big picture of your project and know what already exists that could be of use. The panel discusses different indicators of how well kept up a library is. Glenn talks about situations when his library Graphpack would come in handy. He advises listeners to always test software before purchasing it. The panel talks about the issue of being able to change a component later if it doesn’t work. They agree that it’s important to consider the end goal and what other people on the team need when choosing whether to use 3rd party or custom make your code. Some decision will be your companion for years and years, like what language your project is written in. Glenn suggests that when you are trying something new, try it out in a clear and isolated experiment, something React is very useful for. Last, it is important to leave notes for future developers as to why you made the decision you did Links Lodash Moment library Graphpack Elm Follow DevChat on Facebook and Twitter Picks David Ceddia: boringtechnology.club Leslie Cohn-Wein: The Ladybug Podcast Big Green Egg Lucas Reis: Top 20 CSS Navigation Menus Glenn Reyes: Lydia Hallie Instagram

code panel austria react reyes elm 3rdparty sentry drawing the line netlify big green egg triplebyte lodash devchattv lucas reis

Hasty Treat - Std Lib in JavaScript

Play Episode Listen Later Jun 10, 2019 18:35

In this Hasty Treat, Scott and Wes discuss the Javascript standard library proposal — what it is, how it could influence dev, and what they’d like to see. Sentry - Sponsor If you want to know what’s happening with your errors, track them with Sentry. Sentry is open-source error tracking that helps developers monitor and fix crashes in real time. Cut your time on error resolution from five hours to five minutes. It works with any language and integrates with dozens of other services. Syntax listeners can get two months for free by visiting Sentry.io and using the coupon code “tastytreat”. Show Notes 1:38 - What is a Standard Lib? Still experimental Built-in modules don’t have to be downloaded because they ship with the browser Not exposing built-in modules globally has a lot of advantages: They won’t add any overhead to starting up a new JavaScript runtime context (e.g. a new tab, worker, or service worker) They won’t consume any memory or CPU unless they’re actually imported They don’t run the risk of naming collisions with other variables defined in your code 6:47 - Key Value Storage is the first one: KV Storage: the Web’s First Built-in Module 8:36 - What do we want to see? Deep clone Basically all of Lodash util.isDeepScrictEqual Async json.parse() / json.stringify UUID URL Lib for building and parsing URLs Missing Array Methods Most of underscore JS 15:53 - International Currency Formatting Lists DateTimeFormat RelativeTimeFormat Links JavaScript Standard Library Proposal Add remaining Underscore / Lodash features JavaScript standard library contents Tweet us your tasty treats! Scott’s Instagram LevelUpTutorials Instagram Wes’ Instagram Wes’ Twitter Wes’ Facebook Scott’s Twitter Make sure to include @SyntaxFM in your tweets

deep built web treat javascript cpu module js sentry syntax hasty lodash

11 выпуск 07 сезона. Ruby 2.6.2, Rails 6.0.0.beta3, React Native 0.59, CKEditor 5 v12.0.0, Firefox Send и прочее

RWpod - подкаст про мир Ruby и Web технологии

Play Episode Listen Later Mar 17, 2019 38:45

Добрый день уважаемые слушатели. Представляем новый выпуск подкаста RWpod. В этом выпуске: Ruby Ruby 2.6.2 Released, Rails 4.2.11.1, 5.0.7.2, 5.1.6.2, 5.2.2.1, and 6.0.0.beta3 have been released!, Ruby 2.7 — Numbered Parameters, Rails 6 adds ActiveRecord::Relation#touch_all, Rails 6 adds delete_by and destroy_by as ActiveRecord::Relation methods и Upcoming Rails 6 Bulk insert/Upsert feature What causes Ruby memory bloat?, Phony - E164 international phone number normalizing, splitting, formatting, Shrine - file attachment toolkit for Ruby applications и Ruby Autoformatter Web Releasing React Native 0.59, CKEditor 5 v12.0.0 with inline widgets and distraction free editor released, Introducing Firefox Send, Providing Free File Transfers while Keeping your Personal Information Private, JS Foundation and Node.js Foundation join forces и KV Storage: the Web's First Built-in Module Why you shouldn't use Moment.js…, When “Zoë” !== “Zoë”. Or why you need to normalize Unicode strings и Promise-utils is a dependency-free JavaScript/TypeScript library that provides Lodash-like utility functions for dealing with native ES6 promises

foundation web released zo rails bulk shrine node react native unicode es6 firefox send ruby ruby lodash js foundation

Tendencias en el desarrollo web para el 2019 #RW86

República Web

Play Episode Listen Later Dec 21, 2018 42:37

Dedicamos el último episodio del año a tratar algunas de las tecnologías de la web y su proyección para el año 2019. Reunimos de varias fuentes el estado de lenguajes y herramientas usadas para el desarrollo web, con el ánimo de ofrecer las tendencias que marcarán el próximo año. Entre otras cosas hablamos de: - El dominio de JavaScript como lenguaje en la web. - El uso intensivo de React y Vue.js - Frameworks de back-end como Express o Meteor. - Lenguajes back-end como Python y PHP. - Librerías de utilidades como Lodash. Como tendencias y factores que serán noticia en el 2019, destacamos entre otras: - Incidentes de seguridad y privacidad. - WordPress y su cambio de modelo basado en bloques. - Tendencias en redes sociales y las integraciones con mensajería. - El cloud sigue imparable. - Todo es Chrome en navegadores. - Tendencia hacia la sencillez en el diseño web. Por supuesto es un pequeño esbozo de lo que puede venir. Comenta o aporta tus propias conclusiones. Muchas gracias por escuchar el episodio. Agradecimiento especial a la Escuela Idecrea de Valencia por su colaboración en este podcast. Han participado en el episodio: Javier Archeni y Andros Fenollosa. ¡Os deseamos felices fiestas y que vuestros proyectos del próximo año se cumplan!

Tendencias en el desarrollo web para el 2019 #RW86

República Web

Play Episode Listen Later Dec 21, 2018 42:37

Dedicamos el último episodio del año a tratar algunas de las tecnologías de la web y su proyección para el año 2019. Reunimos de varias fuentes el estado de lenguajes y herramientas usadas para el desarrollo web, con el ánimo de ofrecer las tendencias que marcarán el próximo año. Entre otras cosas hablamos de: - El dominio de JavaScript como lenguaje en la web. - El uso intensivo de React y Vue.js - Frameworks de back-end como Express o Meteor. - Lenguajes back-end como Python y PHP. - Librerías de utilidades como Lodash. Como tendencias y factores que serán noticia en el 2019, destacamos entre otras: - Incidentes de seguridad y privacidad. - WordPress y su cambio de modelo basado en bloques. - Tendencias en redes sociales y las integraciones con mensajería. - El cloud sigue imparable. - Todo es Chrome en navegadores. - Tendencia hacia la sencillez en el diseño web. Por supuesto es un pequeño esbozo de lo que puede venir. Comenta o aporta tus propias conclusiones. Muchas gracias por escuchar el episodio. Agradecimiento especial a la Escuela Idecrea de Valencia por su colaboración en este podcast. Han participado en el episodio: Javier Archeni y Andros Fenollosa. ¡Os deseamos felices fiestas y que vuestros proyectos del próximo año se cumplan!

Dev’s Log 005

Cyber Trek

Play Episode Listen Later Dec 10, 2018 3:40

Things are slowly getting more serious with Node, Express and Lodash. YouTube is a double edged sword and I decided I need to prevent future injuries.

express node lodash

Hasty Treat - Should you install a dependency or roll your own?

Syntax - Tasty Web Development Treats

Play Episode Listen Later Nov 26, 2018 19:15

In this Hasty Treat, Scott and Wes talk about installing dependencies vs rolling your own - the advantages and disadvantages, and how to know when to do either. LogRocket - Sponsor LogRocket lets you replay what users do on your site, helping you reproduce bugs and fix issues faster. It’s an exception tracker, a session replayer and a performance monitor. Get 14 days free over at https://logrocket.com/syntax. Show Notes 2:15 - Reasons To roll your own Learning Experience Fun Features Add your own features Lightweight - only use what you need 8:08 - Reasons not to roll your own Battle Tested Actually Tested Time Money Experience 11:27 - Fork Something needs extra features Upstream your changes 13:10 - Some Examples Fetch + function vs Axios Date functions vs Stack Overflow copy/paste Lodash vs your own - try it with map/reduce/filter first, but lots of cases need Lodash Links React PowerPlug Lodash Axios Stack Overflow Tweet us your tasty treats! Scott’s Instagram LevelUpTutorials Instagram Wes’ Instagram Wes’ Twitter Wes’ Facebook Scott’s Twitter Make sure to include @SyntaxFM in your tweets

treat install dependency lightweight upstream stack overflow hasty lodash

Math and Functional Programming Aren't Exclusive to Wizards with Brian Lonsdorf

egghead.io developer chats

Play Episode Listen Later Nov 2, 2018 30:52

Joel and Brian Lonsdorf discuss the pain and growth of learning, math as a source of truth, dispelling that idea that you need to be a wizard to enter the functional programming space, and finally how you can start including functional concepts in your day to day work.There's a reason that mathematicians tend to be the best functional programmers. The theories and patterns directly apply, it has truth and purity. It's powerful, almost powerful enough to describe everything, so what makes people turn away from it?Traditionally, math gets taught in a dry manner from a young age, tables are memorized, and facts get drilled. It isn't until much later that interesting concepts like set theory get introduced, and at that point, it's too late for many people.Material that's "dry" doesn't have to be taught that way. It's been three and a half years since Brian first put Professor's Frisby's guide up on Github and it brought light and friendly perspective to heavy material. It showed that the functional programming paradigm was learnable without requiring a deep dive into Haskell.The deep dive doesn't work for everyone. There's merit in starting with something like Gatsby and just getting something out there that you can play with immediately, and then later learn the fundamentals of Javascript. The same thing applies to learning functional programming. You can start composing with Lodash and ease into the deeper patterns and concepts.Transcript"Math and Functional Programming Aren't Exclusive to Wizards with Brian Lonsdorf" TranscriptResources:Professor Frisby's Mostly Adequate Guide to Functional ProgrammingProfessor Frisby Introduces Composable Functional JavaScriptFunctional Composition with LodashState Monad in JavaScriptBrian Lonsdorf:GithubTwitterMediumJoel Hooks:TwitterWebsite

learning education professor teaching exclusive math material programming wizards educating functional traditionally github javascript gatsby haskell frisby functional programming lodash mostly adequate guide brian lonsdorf professor frisby

113: There and Back Again: A Quest For Simplicity with Philip Poots

Play Episode Listen Later Oct 25, 2018 45:06

Guest: Philip Poots: GitHub | ClubCollect Previous Episode: 056: Ember vs. Elm: The Showdown with Philip Poots In this episode, Philip Poots joins the show again to talk about the beauty of simplicity, the simplicity and similarities between Elm and Ruby programming languages, whether Elixir is a distant cousin of the two, the complexity of Ember and JavaScript ecosystems (Ember helps, but is fighting a losing battle), static vs. dynamic, the ease of Rails (productivity), and the promise of Ember (productivity, convention). The panel also talks about the definition of "quality", making code long-term maintainable, and determining what is good vs. what is bad for your codebase. Resources: Michel Martens mote Learn the Elm Programming Language and Build Error-Free Apps with Richard Feldman Worse is Better: Richard P. Gabriel Gary Bernhardt's Destroy All Software Screencasts Zen and the Art of Motorcycle Maintenance: An Inquiry into Values The Calm Company It Doesn't Have to Be Crazy at Work This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. Transcript: CHARLES:: Hello, everybody and welcome to The Frontside Podcast, Episode 113. My name is Charles Lowell. I'm a developer here at the Frontside and with me today are Taras Mankovski and David Keathley. Hello? DAVID:: Hey, guys. TARAS: Hello, hello. CHARLES:: And we're going to be talking with a serial guest on our serial podcast, Mr Philip Poots, who is the VP of engineering at ClubCollect. Welcome, Philip. PHILIP: Hey, guys. Thanks for having me on. CHARLES:: Yeah. I'm actually excited to have you on. We've had you on a couple of times before. We've been trying to get you on the podcast, I think for about a year, to talk about I think what has kind of a unique story in programming these days. The prevailing narrative is that folks start off with some language that's dynamically typed and object oriented and then at some point, they discover functional programming and then at some point, they discover static programming and they march off into a promised land of Nirvana and no bugs ever, ever happening again. It seems like it's pretty much a straight line from that point to the next point and passing through those way stations. When I talk to you, I guess... Gosh, I think you were the first person that really introduced me to Elm back at Wicked Good Ember in 2016 and it seemed like you were kind of following that arc but actually, that was a bit deceptive because then the next time I talked to you, you were saying, "No, man. I'm really into Ruby and kind of diving in and trying to get into Ruby again," and I was kind of like, "Record scratch." You're kind of jumping around the points. You're not following the preordained story arc. What is going on here? I just kind of wanted to have a conversation about that and find out what the deal was and then, what's kind have guided your journey. PHILIP: There was one event and that was ElmConf Europe, which was a fantastic conference. Really, one of the best conferences I've been to, just because I guess with the nature of early language, small conference environment. There's just a lot of things happening. There's a lot of people. Evan was there, Richard Feldman was there, the leading lights of the Elm community were there and it was fantastic. But I guess, one thing that people have always said to me is the whole way track is the best track of the conference and it's not something I really appreciated before and during the breaks, I ended up talking to a guy called Michel Martens. He is the finder of a Redis sourcing company and I guess, this was just a revelation to me. He was interested in Elm. He was friends with the guys that organized the conference and we got talking and he was like, "I do this in Ruby. I do this in Ruby. I did this in Ruby," and I was like, "What?" and he was like, "Yeah, yeah, yeah." He's a really, really humble guy but as soon as I got home, I checked him out. His GitHub is 'soveran' and it turns out he's written... I don't know, how many gems in Ruby, all with really well-chosen names, very short, very clear, very detailed. The best thing about his libraries is you can print them out on paper. What I mean by that is they were tiny. They were so small and I guess, I just never seen that before. I go into Ruby on Rails -- that was my first exposure to programming, that was my first exposure to everything -- unlike with Rails, often when you hit problems, you'd start to dive a bit deeper and ultimately, you dive so deep that you sunk essentially and you just accepted, "Okay, I'm not going to bend the framework that way this time. Let's figure out how everyone else goes with the framework and do that." Then with Ember when I moved into frontend, that was a similar thing. There were so many layers of complexity that I never felt like had a real handle on it. I kind of just thought this was the way things were. I thought it's always going to be complex. That's just the nature of the problem. That's just the problem they're trying to solve. It's a complex problem and therefore, that complexity is necessary. But it was Elm that taught me, I think that choosing the right primitives and thinking very carefully about the problem can actually give you something that's quite simple but incredibly powerful. Not only something quite simple but something so simple that it can fit inside your head, like this concept of a program fitting inside your head and Rails, I don't know how many heads I need to fit Rails in or Ember for that matter and believe me, I tried it but with Elm, there was that simplicity. When I came across this Ruby, a language I was very familiar with but this Ruby that I had never seen before, a clear example was a templating library and he calls it 'mote' and it's including comments. It's under a hundred lines of code and it does everything you would need to. Sure, there were one or two edge cases that it doesn't cover but it's like, "Let's use the trade off." It almost feels like [inaudible] because he was always a big believer in "You ain't going to need it. Let's go for that 80% win with 20% effort," and this was like that taken to the extreme. CHARLES:: I'm just curious, just to kind of put a fine point on it, it sounds like there might be more in common, like a deeper camaraderie between this style of Ruby and the style encouraged by Elm, even though that on the surface, one is a dynamically typed object oriented language and the other is a statically typed functional language and yet, there's a deeper philosophical alignment that seems like it's invisible to 99% of the discussion that happens around these languages. PHILIP: Yeah, I think so. I think the categories we and this is something Richard Feldman talks. He's a member of the Elm community. He does a lot of talks and has a course also in Frontend Masters, which I highly recommend. But he often talks about the frame of the conversation is wrong because you have good statically typed languages and you have bad statically typed languages. You have good dynamic languages and you have bad dynamic languages. For all interpretations of good and bad, right? I don't want to start any wars here. I think one of the things that Elm and Ruby have in common is the creator. Matz designed Ruby because he wanted programming to be a joy, you know? And Evan created Elm because he wanted programming to be a delight. I think if you experience both of those, like developing in both of those languages, you gain a certain appreciation for what that means. It is almost undefinable, indistinguishable, although you can see the effects of it everywhere. In Ruby, everything is an object, including nil. In Elm, it's almost he's taken everything away. Evan's taken everything away that could potentially cause you to stumble. There's a lot to learn with Elm in terms of getting your head around functional mindset and also, working with types but as far as that goes, people often call it like the Haskell Light, which I think those are a disservice to Elm because it's got different goals. CHARLES:: Yeah, you can tell that. You know, my explorations with Elm, the personality of Elm is 100% different than the personality of Haskell, if that is even a programming term that you can apply. For example, the compiler has an identity. It always talks to you in the first person, "I saw that you did this, perhaps you meant this. You should look here or I couldn't understand what you were trying to tell me." Literally that's how the Elm compiler talks to you. It actually talks to you like a person and so, it's very... Sorry, go ahead. PHILIP: No, no, I think the corollary to that is the principle of the surprise in Ruby. You know, is there going to be a method that does this? You type it out and you're like, "Oh, yes it is," which is why things like inject and reduce are both methods in enumerable. You didn't choose one over the other. It was just like, "Let's make it easy for the person who's programming to use what they know best." I think as well, maybe people don't think about this as deeply but the level of thought that Evan has put into designing Elm is crazy, like he's thought this through. I'm not sure if I said this the last time but I went to a workshop in the early days in London, which is my kind of first real exposure to Elm and Evan was giving the workshop. Someone asked him, "Why didn't you do this?" and he was like, "Well, that might be okay for now but I'm not sure that would make so much sense in 10 years," and I was kind of like, "What?" Because JavaScript and that ecosystem is something which is changing like practically hourly and this is a guy that's thinking 10 years into the future. TARAS: You might have answered it already but I'm curious of what you think is the difference, maybe it just comes down to that long term thinking but we see this in JavaScript world a lot, which is this kind of almost indifference to APIs. It almost doesn't really matter what the API is for whatever reason, there seems to be a big correlation between the API that's exposed with the popularity of the tool. I think there are some patterns, like something that's really simple, like jQuery and React have become popular because of the simplicity of their APIs. What the flip side to that? What other ways can APIs be created that we see in JavaScript world. Because we're talking about this beautiful APIs and I can relate to some of the work that Charles has been doing and I've been doing microstates but I wonder like what would be just a brief alternative to that API, so it's kind of a beautiful API. PHILIP: I don't know if anyone is familiar with the series of essays 'Worse is Better' like East Coast versus West Coast, from Richard Gabriel. The problem is, I guess and maybe this is just my understanding over my paraphrase of it, I'm not too familiar with it but I think that good APIs take time and people don't have time. If someone launches a V1 at first and it kind of does the job, people will use that over nothing and then whenever they're happy with that, they'll continue to use it and develop it and ultimately, if she's market share and then that's just the thing everyone uses and the other guy's kind of left behind like, "This is so much better." I guess this is a question, I think it was after Wicked Good Ember, I happened to be on the same trend as Tom Dale on the way back to New York and we started talking about this. I think that's his big question. I think it's also a question that still has to be answered, which is, "Will Elm ever be mainstream? Will it be the most popular thing?" aside from the question of whether it has to be or not. For me, a good APIs good design comes from understanding the problem fully -- CHARLES:: And you can understand the problem fully without time. PHILIP: Exactly and often, what happens -- at least this is what happens in my experience with the production software that I've written -- is that you don't actually understand the problem until you've developed a solution for it. Then when you've developed a solution for it, often the pressures or the commercial pressures or an open source is [inaudible] the pressures of backwards compatibility, mean that you can never refactor your way to what you think the best solution is and often, you start from scratch and the reality is people are too far away with the stuff you wrote in the past about the thing you're writing now. Those are always kind of at odds. I think there are a lot of people that are annoyed with Elm because the updates are too slow, it relies on Evan and we want to have a pool request accepted. All of the things that they don't necessarily recognize like the absence of which make Elm an Elm, if you know what I mean. The very fact that Evan does set such a high standard and does want everything to go through his personal filters because otherwise, you wouldn't gain the benefits that Elm gives you. The attention is very real in terms of I want to shift my software now and it becomes easier then. I think to go to a language like JavaScript, which has all of the escape hatches that you need, to be able to chop and change, to edit, to do what you need to do to get the job done and let's be quite honest, I think, also with Elm, that's the challenge for someone who's not an expert level like me. Once you hit a roadblock, you'll say, "Where do I go from here?" I know if I was using JavaScript, I could just like hack it and then clients are happy and everything's fine and you know there's a bit of stuff in your code that you would rather wasn't but at the end of the day, you go home and the job's done. DAVID:: Have you had to teach Elm to other people? You and I did some work like I've seen you pair with someone and guide them through the work that they needs to get done. If you had a chance to do something like that with Elm and see how that actually happens, like how do developer's mind develops as they're working through in using the tool? PHILIP: Unfortunately not. I would actually love to go through that experience. I hope none of my developers are listening to this podcast but secretly, I want to push them in the direction of Elm on the frontend. But no, but I can at least make from my own perspective. I find it very challenging at first because for me, being a Ruby developer and also, I would never say that I understood JavaScript as much as I would have liked. Coming from dynamic language, no functional experience to functional language with types, it's almost like learning a couple of different things at the same time and that was challenging. I think if I were to take someone through it, I would maybe start with a functional aspects and then move on to the type aspects or vice versa, like try and clearly breakdown and it's difficult because those two are so intertwined at some level. Gary Bernhardt of Destroy All Software Screencast, I watch quite a bit of his stuff and I had sent him an email to ask him some questions about one of the episodes that he did and he told me that he done the programming languages course, I think it's on Coursera from Daniel Grossman, so [inaudible] ML which is kind of the father of all MLs like Haskell and also Elm. I find that really helpful because he broke it down on a very basic level and his goal wasn't to teach you ML. It was to teach you functional programming. It would be a very interesting exercise, I think. I think the benefit that Elm gave you is you get to experience that delight very quickly with, "Oh, it's broken. Here's a nice message. I fix the message. It compiles. Wow, it works," and then there's a very big jump whenever you start talking about the effects. Whenever you want to actually do something like HTTP calls or dealing with the time or I guess, the impure stuff you would call in the Haskell-land and that was also kind of a bit weird. CHARLES:: Also, there's been some churn around that, right? PHILIP: That's right. When I started learning, they had signals, then they kind of pushed that all behind the scenes and made it a lot more straightforward. Then I just mastered it and I was like, "Yes, I know it," and then I was like, "All right. I don't need to know it anymore." This is the interesting thing for me because at work, most of our work now is in Elixir and Phoenix. I'm kind of picking a little bit up as I work with them. I think Elm's architecture behind the scenes is kind of based, I believe on Erlang's process model, so the idea of a mailbox and sending messages and dealing with immutable state. CHARLES:: Which is kind of ironically is very object oriented in a way, right? It's functional but also the concept of mailboxes and sending messages and essentially, if you substitute object for process, you have these thousands and thousands of processes that are sending messages back and forth to each other. PHILIP: Yeah, that's right. It's like on a grand scale, on a distributed scale. Although I wouldn't say that I'm that far with Erlang, Elixir to appreciate the reality of that yet but that's what they say absolutely. CHARLES:: Now, Phoenix and Elixir is a dynamically typed functional language. does it share the simplicity? One of the criticisms you had of Rails was that you couldn't fit it in your head. It was very difficult. Is there anything different about Elixir that kind of makes it a spirit cousin of Elm and the simple Ruby? PHILIP: I think so, yes. Absolutely. I don't think it gets to the same level but I think it's in the right direction and specifically on the framework front, it was designed specifically... I mean, in a sense it's like the anti-type to Rails because it was born out of people's frustrations with Rails. José Valim was pretty much one of Rails top core committers. Basically, every Rails application I wrote at one period, at 80% of the code written by José Valim, if you included all the gems, the device and the resourceful and all the rest of it. Elixir in many ways was born out of the kind of limitations of Ruby with Rails and Phoenix was also born out of frustrations with the complexity of Rails. While it's not as simple as say, Michel Martens' Syro which is like his web framework, which is a successor to Cuba if people have heard of that, it is a step in the right direction. I don't understand it but I certainly feel like I could. They have plug which is kind of analogous but not identical to Rack but then the whole thing is built out of plugs. I remember Yehuda Katz give a presentation like 'The Next Five Years' and essentially about Rails 3.0. This is going way back and Phoenix is in some ways the manifestation of his desire to have like the Russian doll pattern, where you could nest applications inside applications and you could have them side by side and put them inside each other and things like that. Phoenix has this concept called umbrella applications which tells that, like Ecto is a really, really nice obstruction for working with the database. CHARLES:: I see. It feels like, as opposed to being functional or static versus dynamic, the question is how do you generate your complexity? How do you cope with complexity? Because I think you touched on it at the beginning of the conversation where you thought that my problems are complex so the systems that I work with to solve those problems must necessarily also be complex. I think one of the things that I've certainly realized, kind of in the later stages of my career is that first part is true. The problems that we encounter are extremely complex but you're much better served if you actually achieve that complexity by composing radically simple systems and recombining them. To the commonality of your system is going to determine how easy it's going to work with and how well it can cope with complexity. What really drives a good system is the quality of its primitives. PHILIP: Absolutely. After ElmConf, I actually invited Michel to come to my place in the Netherlands. He live in Paris but I think he grew up Buenos Aires in Argentina. To my amazement, he said, "Yes, okay," and we spent a couple of days together and there he talked to me about Christopher Alexander and the patterns book, where patterns and design patterns actually grew out of. One of his biggest things was the code is the easiest part, like you've got to spend 80% of your time thinking deeply about the problem, like literally go outside, take long looks. I'm not sure if this is what Rich Hickey means with Hammock Driven Development. I've never actually got around to watching the talk. CHARLES:: I think it's exactly what he means. PHILIP: And he said like once you get at, the code just comes. I think Michel's work, you should really check it out. I'll send you a link to put in the show notes but everything is built out of really small libraries that do one thing and do it really well. For example, he has a library like a Redis client but the Redis client also has something called Nest, which is a way to generate the keys for nested hashes. Because that's a well-designed, the Redis client is literally just a layer on top. If you understand the primitive then, you can use the library on top really well. You can embed Syro applications within Syro applications. I guess, there you also need the luxury of time and I think this is where maybe my role as VP of engineering, which is kind of my first role of that kind, comes in here which is when you're working on the commercial pressure, try to turn around to a business guy and say, "Yes, we'll solve this problem but can we take three weeks to think about it?" It's never going to happen -- CHARLES:: No. PHILIP: Absolutely, it will never going to happen. Although the small things that I tried to do day to day now is get away from the computer, write on paper, write out the problem as you understand it, attack it from different angles, think about different viewpoints, etcetera. CHARLES:: I think if you are able to quantify the cost of not thinking about it for three weeks, then the business person that you're going to talk to is their ears are going to perk up, right? But that's so hard to do. You know, I try and make like when we're saying like, "What technologies are you going to choose? What are the long term ramifications in terms of dollars or euros or whatever currency you happen to be in for making this decision?" I wish we had more support in thinking about that but it is kind of like a one-off every time. Anyway, I'm getting a little bit off track. PHILIP: No, not at all. This is a subject I love to talk about because we kind of had a few a bit of turbulence because we thought, maybe we should get product people in, maybe we should get them a product team going and what I find was -- and this is maybe unique to the size of the company -- that actually made things a lot more difficult because you got too many heads in many ways. Sometimes, it's better to give the developer all of the context so that he can think about it and come up with the best solution because ultimately, he's the only one who can understand. I wouldn't say understands the dollars and cents but he understands the cost implications of doing it in efficient ways, which often happens when you're working in larger teams. TARAS: One thing I find really interesting about this conversation is the definition of good is really complicated here. I've observed Charles work on microstates and I work with him, like I wrote a lot of the code and we got through like five or six iterations and at every point, he got better but it is so difficult to define that. Then when you start to that conversations outside of that code context and you start to introduce business into the mix, the definition of good becomes extremely complicated. What do you think about that? How do we define it in a way? Are there cultures or engineering cultures or societal cultures that have a better definition for good that is relevant to doing quality work of this? CHARLES:: That's a deep question. PHILIP: Wow. Yeah, a really, really deep question. I think often for business, like purely commercially-driven, money-oriented good is the cheapest thing that gets the job done and often that's very short term, I think. As you alluded to Charles, that people don't think about the cost of not doing the right things, so to speak in our eyes and also, there's a huge philosophical discussion whether our definition of good as programmers and people who care about our craft is even analogous to or equal to a good in a commercial context. CHARLES:: Yes, because ultimately and this is if you have read Zen in the Art of Motorcycle Maintenance, one of the things that Pirsig talks about is what is the definition of quality. How do we define something that's good or something that's bad? One of the definitions that gets put forward is how well something is fit to purpose. Unless you understand the purpose, then you can't determine quality because the purpose defines a very rich texture, a very rich surface and so, quality is going to be the object that maps very evenly and cleanly over that surface. When it comes to what people want in a program, they're going to want very different thing. A developer might need stimulation for this is something that's very new, this is something that's going to keep my interest or it's going to be keeping my CPU max and I'm going to be learning a whole lot. A solution that actually solves for that purpose is going to be a high quality solution. Also, this is going to be fast. We're going to be able to get to market very quickly. It might be one of the purposes and so, a solution that is fast and the purpose fits so it's going to be good. Also, I think developers are just self-indulgent and looking for the next best thing in something that's going to keep their interest, although we're all guilty of that. But at the same time, we're going to be the ones maintaining software, both in our current projects and collectively when we move to a new job and we're going to be responsible for someone else's code, then we're going to be paying the cost of those decisions. We both want to minimize the pain for ourselves and minimize the pain for others who are going to be coming and working in our code to make things long term maintainable. That's one axis of purpose and therefore, an axis of quality. I think in order to measure good and bad, you really have to have a good definition of what is the purpose of that surface is so rich but the more you can map it and find out where the contours lie, the more you're going to be able to determine what's good and what's bad. TARAS: It makes me think of like what is a good hammer. A sledgehammer is a really good hammer but it's not the right hammer for every job. CHARLES:: Right. TARAS: I think what you're saying is understanding what is it that you're actually doing and then matching your solution to what you're actually trying to accomplish. PHILIP: Yeah, absolutely and in my experience, we have a Ruby team building a Rails application. That's our monolith and then, we have a couple of Elixir teams with services that have been spun out of that. This isn't proven. This is just kind of gut feel right now and it is that Elixir is sometimes slower to develop the same feature or ship it but in the long term it's more maintainable. I haven't actually gotten dived into to React and all of the amazing frameworks that it has in terms of getting things up and running quickly but in terms of the full scale application, I still think 10, 11 years on, Rails has no equal in terms of proving a business case in the shortest time possible. CHARLES:: Yeah. I feel very similarly too but the question is does your development team approach the problem as proving a business case or do they approach the problem as I want to solve the set of features? PHILIP: Yes. Where I'm working at the moment, I started out just as a software developer. I guess, we would qualify for 37 signals or sorry... base camps definition of a calm company -- CHARLES:: Of a what company? PHILIP: A calm company. Sorry. They just released a new book and called 'The Calm Company' and 'It Doesn't Have to Be Crazy at Work.' I was given in my first couple of months, a problem. It was business oriented, it had to be solved but it had to be solved well from a technical perspective because we didn't want to have to return to it every time. It was standardizing the way that we exported data from the database to Excel. You know, I was amazed because it was literally, the first time that I'd been given the space to actually dive in on a technical level to do that kind of stuff. But I think even per feature, that varies and that sometimes challenging when handing the work on because you've got to say, "This fit. Literally, we're just trying to prove, whether if we have this feature, the people will use it?" versus, "This is a feature that's going to be used every day and therefore, needs to be at good, technical quality." Those are the tradeoffs that I guess, keep you in a job. Because if it was easy, then you would need anyone to figure it out but it's always a challenge. What I like is that our tools are actually getting better and I think, with Elm for example, it's kind of major selling point is maintainability and yet, with Elm, there haven't been that many companies with Elm over a period of years that exists, that can live to tell the tale. Whereas, we certainly know with Rails applications have done well like Basecamp and GitHub. For sure, they can be super maintainable but the fact that it took GitHub to just moved Elm to Rails 5.0, I belief, the fact that it took them years and years and they were running off at fork of Rails 2.3, I think it shows the scale of the problem in that way. You know, Phoenix also went through a few issues, kind of moving architectures from the classic Rails to a more demand driven design model. I think we're getting there slowly, zig-zagging towards a place where we better understand how to write software to solve business problems. I guess, I was really interested in microstates when you shared it at Wicked Good Ember because that to me was attacking the problem from the right perspective. It's like given the fact that the ecosystem is always changing. How can we extract the business logic such that these changes don't affect the logic of our application? CHARLES:: Man, we got a lot to show you. It has changed quite a bit in the last two years. Hopefully, for the better. TARAS: It's been reduced and it's almost a quarter of its size while maintaining the same feature set and it's faster, it's lazier, it's better in every respect. It's just the ideas have actually been fairly consistent. It's just the implementation that's evolved. CHARLES:: Yeah, it's been quite a journey. It parallels kind of the story that we're talking about here in the sense that it really has been a search for primitives and a search for simplification. One of the things that we've been talking about, having these Ruby gems that do one thing and do it very, very, very well or the way that Elixir being architected has some very, very good primitives or Elm, the same kind of thing being spiritually aligned, even though on the surface, it might share more in common with Haskell. There's actually a deep alignment with a thing like Ruby and that's a very surprising result. I think one of the things that appeals to me about the type of functional programming that is ironically, I guess not present in Elm, where you have the concept of these type classes but I actually think, I love them for their simplicity. I've kind of become disenchanted with things like Lodash, even though they're nominally functional. The fact that you don't have things like monoid and functors and stuff is kind of first class participants in the ecosystems, means you have to have a bunch of throwaway functions. Those API surface area is very large, whereas if you do account for those things, these kind of ways of combining data and that's how you achieve your complexity, is not by a bunch of one-off methods that are like in Lodash, they're all provided for you so you don't have or have to write them yourself. That is one level of convenience but having access to five primitives, I think that's the power of the kind of the deeper functional programming types. PHILIP: And Charles, do you think that that gives you the ability to think at a higher level, about the problems that you're solving? Would you make that link? CHARLES:: Absolutely. PHILIP: So, if we're not doing that, then we're actually doing ourselves a disservice? CHARLES:: I would say so. PHILIP: Because we're actually creating complexity, where it shouldn't exist? CHARLES:: Yeah, I think if you have a more powerful primitive, you can think of things like async functions and generator functions, there's a common thread between async functions, generator functions, promises arrays and they're all functors. For me, that's a very profound realization and there might be a deeper spiritual link between say, an async function and an array in the same way that there's a deep spiritual link between Ruby and Elm, that if you don't see that, then you're doing yourself a disservice and you're able to think at a higher level. Also, you have a smaller tool set where each tool is more powerful. PHILIP: You did a grit, I think it was a repository with a ReadMe, where you boiled down what people would term what I would term, the scary functional language down to a very simple JavaScript. Did you ever finish that? Did you get to the monads? CHARLES:: I did get to the monads, yeah. PHILIP: Okay. I need to check that out again. I find that really, really helpful because I think one of Evan's big things with Elm is he doesn't use those terms ever and he avoids them like the plague because I think he believes they come tinged with the negative experiences of people trying Haskell and essentially getting laughed at, right? CHARLES:: Yes. I think there's something to that. TARAS: But we're doing that in microstates as well, right? In microstates documentation, even though microstates are written completely with these functional primitives, on the outside, there's almost no mention of it. It's just that when you actually go to use it, if you have an idea, one of the thing that's really powerful with microstates is that this idea that you can return another microstate from a transition and what that will do is what you kind of like what a flat map would do, which is replace that particular node with the thing that you returned it with. For a lot of people, they might not know that that's like a flat map would do but a microstate will do exactly what they wanted to do when it didn't realize that's actually should just work like that. I think, a lot of the work that we've done recently is to package all things and it make it powerful and to access the concepts that it is very familiar, something you don't need to learn. You just use it and it just works for you. CHARLES:: Right but it is something that I feel like there's unharvested value for every programmer out there in these type classes: monads and monoids and functors and co-functors or covariant functors, contravariant functors, blah-blah-blah, that entire canon. I wish there was some way to reconcile the negative connotations and baggage that that has because we feel kind of the same way and I think that Evan's absolutely right. You do want to hide that or make it so that the technology is accessible without having to know those things. But in the same way, these concepts are so powerful, both in terms of just having to think less and having to write less code but also, as a tool to say, "I've got this process. Is there any way that could it be a functor? If I can find a way that this thing is a functor, I can just save myself so much time and take so many shortcuts with it." PHILIP: And in order to be able to communicate that, or at least communicate about that, you need to have terms to call these things, right? Because you can't always just refer to the code or the pattern. It's always good to have a name. I'm with you. I see value in both, like making it approachable, so the people who don't know the terms are not frightened away. But I also see value in using the terms that have always existed to refer to those things, so that things are clear and we can communicate about them. CHARLES:: Right. definitely, there's a tradeoff there. I don't know where exactly the line is but it would be nice to be able to have our cake and eat that one too. We didn't get really to talk about the type versus dynamic in the greater context of this whole conversation. We can explore that topic a little bit. PHILIP: Well, I can finish with, I think the future is typed Erlang. Maybe, that's Elm running on BEAM. CHARLES:: Whoa. What a take? Right there, folks. I love it. I love it but what makes you say that? Typed Erlang doesn't exist right now, right? PHILIP: Exactly. CHARLES:: And Elm definitely doesn't run on BEAM. PHILIP: I don't know if I'm allowed to say this. When I was at this workshop with Evan, he mentioned that and I'm not sure whether he mentioned it just as a throwaway comment or whether this is part of his 20-year plan but I think the very fact that Elm is designed around like Erlang, the signal stuff was designed around the way Erlang does communication and processes, it means I know at least he appreciates that model. From my point of view, with my experience with Elixir and Erlang in production usage, it's not huge scale but it's scale enough to need to start doing performance work on Rails and just to see how effortless things are with Elixir and with Erlang. I think Elm in the backend would be amazing but it would have to be a slightly different language, I think because the problems are different. We began this by saying that my story was a little different to the norm because I went back to the dynamic, at the dark side but for example in Elixir, I do miss types hugely. They kind of have a little bit of a hack with Erlang because they return a lot of tuples with OK and then the object. You know, it's almost like wrapping it up in a [inaudible]. There are little things and there's Dialyzer to kind of type check and I think there are a few projects which do add types to Erlang, etcetera. But I think something that works would need to be designed from the ground up to be typed and also run in the BEAM, rather than be like a squashed version of something else to fit somewhere else, if that makes sense. CHARLES:: It makes total sense. PHILIP: I think so. I recently read a book, just to finish which was 'FSharpForFunAndProfit' is his website, Scott Wlaschin, I think. It's written up with F# but it's about designing your program in a type functional language. Using the book, you could probably then just design your programs on paper and only commit to code at the end because you're thinking right down to the level of the types and the process and the pipelines, which to me sounds amazing because I could work outside. CHARLES:: Right. All right-y. I will go ahead and wrap it up. I would just like to say thank you so much, Philip for coming on and talking about your story, as unorthodox as it might be. PHILIP: Thank you. CHARLES:: Thank you, Taras. Thank you, David. TARAS: Thank you for having us. CHARLES:: That's it for Episode 113. We are the Frontside. This is The Frontside Podcast. We build applications that you can stake your future on. If that's something that you're interested in, please get in touch with us. If you have any ideas for a future podcast, things that you'd like to hear us discuss or any feedback on the things that you did here, please just let us know. Once again, thank you Mandy for putting together this wonderful podcast and now we will see you all next time.

new york art work russian record argentina quest llc netherlands cuba west coast east coast simplicity nest zen react excel nirvana buenos aires mls api ml github beam apis javascript rails basecamp cpu rack elixir elm coursera mandy moore haskell ruby on rails v1 matz jquery redis readme taras ecto motorcycle maintenance erlang christopher alexander be crazy poots pirsig syro frontside richard feldman yehuda katz rich hickey frontend masters gary bernhardt tom dale lodash richard gabriel charles lowell david have scott wlaschin taras mankovski dialyzer devreps

JSJ 328: Functional Programming with Ramda with Christine Legge

Play Episode Listen Later Aug 28, 2018 55:21

Panel: Joe Eames Aimee Knight AJ O'Neal Joe Eames Special Guests: Christine Legge In this episode, the JavaScript Jabber panel talks to Christine Legge about functional programming with Ramda. Christine is a front-end software engineer and just recently got a new job in New York working at Google. Ramda is a utility library in JavaScript that focuses on making it easier to write JavaScript code in a functional way. They talk about functional programming and what it is, using Ramda in Redux, and referential transparency. They also touch on why she first got into Ramda, compare Ramda to Lodash and Underscore, and more! In particular, we dive pretty deep on: Chirstine intro Works as a front-end software engineer What is Ramda? JavaScript Utility library like Lodash and Underscore Lodash and Underscore VS Ramda Functional programming Ramda and Functional programming as a mindset Ramda at ZenHub Ramda with Redux and React What is referential transparency? Why would you use Ramda VS Lodash or Underscore? Why she first got into Ramda Didn’t always want to be a programmer Background in Math Learning functional programming as a new programmer Erlang DrRacket and Java Ramda makes it easy to compose functions Creating clean and reusable code How do you start using Ramda? And much, much more! Links: Ramda Lodash Underscore ZenHub Redux React Erlang DrRacket @leggechr Chirstine’s GitHub Sponsors Kendo UI Sentry Digital Ocean Picks: Charles Home Depot Tool Rental Podcast Movement CES VRBO Aimee Apple Cider Vinegar Jeremy Fairbank Talk – Practical Functional Programming AJ Goat’s Milk Joe Topgolf Framework Summit Christine Dan Mangan Reply All Podcast

new york learning google goat math panel milk ces react special guests functional redux java github utility javascript podcast movement legge top golf vrbo sentry apple cider vinegar digital ocean underscore functional programming erlang dan mangan reply all podcast aimee knight javascript jabber lodash kendo ui zenhub joe eames framework summit home depot tool rental

JSJ 328: Functional Programming with Ramda with Christine Legge

Play Episode Listen Later Aug 28, 2018 55:21

Panel: Joe Eames Aimee Knight AJ O'Neal Joe Eames Special Guests: Christine Legge In this episode, the JavaScript Jabber panel talks to Christine Legge about functional programming with Ramda. Christine is a front-end software engineer and just recently got a new job in New York working at Google. Ramda is a utility library in JavaScript that focuses on making it easier to write JavaScript code in a functional way. They talk about functional programming and what it is, using Ramda in Redux, and referential transparency. They also touch on why she first got into Ramda, compare Ramda to Lodash and Underscore, and more! In particular, we dive pretty deep on: Chirstine intro Works as a front-end software engineer What is Ramda? JavaScript Utility library like Lodash and Underscore Lodash and Underscore VS Ramda Functional programming Ramda and Functional programming as a mindset Ramda at ZenHub Ramda with Redux and React What is referential transparency? Why would you use Ramda VS Lodash or Underscore? Why she first got into Ramda Didn’t always want to be a programmer Background in Math Learning functional programming as a new programmer Erlang DrRacket and Java Ramda makes it easy to compose functions Creating clean and reusable code How do you start using Ramda? And much, much more! Links: Ramda Lodash Underscore ZenHub Redux React Erlang DrRacket @leggechr Chirstine’s GitHub Sponsors Kendo UI Sentry Digital Ocean Picks: Charles Home Depot Tool Rental Podcast Movement CES VRBO Aimee Apple Cider Vinegar Jeremy Fairbank Talk – Practical Functional Programming AJ Goat’s Milk Joe Topgolf Framework Summit Christine Dan Mangan Reply All Podcast

new york learning google goat math panel milk ces react special guests functional redux java github utility javascript podcast movement legge top golf vrbo sentry apple cider vinegar digital ocean underscore functional programming erlang dan mangan reply all podcast aimee knight javascript jabber lodash kendo ui zenhub joe eames framework summit home depot tool rental

JSJ 328: Functional Programming with Ramda with Christine Legge

Play Episode Listen Later Aug 28, 2018 55:21

Panel: Joe Eames Aimee Knight AJ O'Neal Joe Eames Special Guests: Christine Legge In this episode, the JavaScript Jabber panel talks to Christine Legge about functional programming with Ramda. Christine is a front-end software engineer and just recently got a new job in New York working at Google. Ramda is a utility library in JavaScript that focuses on making it easier to write JavaScript code in a functional way. They talk about functional programming and what it is, using Ramda in Redux, and referential transparency. They also touch on why she first got into Ramda, compare Ramda to Lodash and Underscore, and more! In particular, we dive pretty deep on: Chirstine intro Works as a front-end software engineer What is Ramda? JavaScript Utility library like Lodash and Underscore Lodash and Underscore VS Ramda Functional programming Ramda and Functional programming as a mindset Ramda at ZenHub Ramda with Redux and React What is referential transparency? Why would you use Ramda VS Lodash or Underscore? Why she first got into Ramda Didn’t always want to be a programmer Background in Math Learning functional programming as a new programmer Erlang DrRacket and Java Ramda makes it easy to compose functions Creating clean and reusable code How do you start using Ramda? And much, much more! Links: Ramda Lodash Underscore ZenHub Redux React Erlang DrRacket @leggechr Chirstine’s GitHub Sponsors Kendo UI Sentry Digital Ocean Picks: Charles Home Depot Tool Rental Podcast Movement CES VRBO Aimee Apple Cider Vinegar Jeremy Fairbank Talk – Practical Functional Programming AJ Goat’s Milk Joe Topgolf Framework Summit Christine Dan Mangan Reply All Podcast

new york learning google goat math panel milk ces react special guests functional redux java github utility javascript podcast movement legge top golf vrbo sentry apple cider vinegar digital ocean underscore functional programming erlang dan mangan reply all podcast aimee knight javascript jabber lodash kendo ui zenhub joe eames framework summit home depot tool rental

Ep. 40 - The main pillars of learning programming - and why beginners should master them

The freeCodeCamp Podcast

Play Episode Listen Later Jul 30, 2018 10:42

Learning how to code can be overwhelming - especially if your intro course asks you to build a Facebook clone. But if you focus on the fundamentals, have the right guidance, and develop a strong inner motivation to succeed, you'll master the basics and be ready to move on. In this episode, you'll learn how to do just that. Written by Rainer Hahnekamp: https://twitter.com/rainerhahnekamp Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn Original article: https://fcc.im/2LOmUao Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript I have been programming for more than 20 years. During that time, I’ve had the pleasure to work with many people, from whom I learned a lot. I’ve also worked with many students, coming fresh from university, with whom I had to take on the role of a teacher or mentor. Lately, I have been involved as a trainer in a program that teaches coding to absolute beginners. Learning how to program is hard. I often find that university courses and bootcamps miss important aspects of programming and take poor approaches to teaching rookies. I want to share the five basic pillars I believe a successful programming course should build upon. As always, I am addressing the context of mainstream web applications. A rookie’s goal is to master the fundamentals of programming and to understand the importance of libraries and frameworks. Advanced topics such as the cloud, operations in general, or build tools should not be part of the curriculum. I am also skeptical when it comes to Design Patterns. They presume experience that beginners never have. So let’s look at where new programmers should start. Test-Driven Development (TDD) TDD brings a lot of benefits. Unfortunately, it is an advanced topic that beginners are not entirely ready for. Beginners shouldn’t write tests. This would be too much for their basic skill levels. Instead, they should learn how to use and work with tests. Each programming course should center around exercises. I extend my exercises with unit tests and provide the students an environment which is already setup for running those tests. All the students have to do is write their code and then watch the lights of the testrunner turning from red to green. The resulting gamification is a nice side effect. For example: If the selected technology is Spring, I provide the exercises and tests within a Spring project. The students don’t need to know anything about Spring. All they need to know is the location of the exercises and the button to trigger the tests. Additionally, students must know how to use a debugger and have a Read-Eval-Print Loop (REPL) handy. The ability to analyse code during runtime and to have a playground for small experiments is essential in TDD. The main point is to ensure students don’t have to learn basic TDD behaviours after they’ve acquired core programming skills. Changing habits later in the students’ career will be much harder than learning those habits now. That’s why they should live and breath unit tests from the beginning. Later in their professional life, they should have an antipathy for projects without unit tests. They should intuitively see the absence of unit tests as anti-pattern. Fundamentals First I hear very often that rookies should immediately start with a framework. This is like teaching people how to drive by placing them in a rally car and asking them to avoid oversteering. This simply ignores the fact that they still mistake the brake for the throttle. The same applies when we start students with a framework like Angular. Beginners need to understand the fundamentals of programming first. They need to be familiar with the basic elements and what it means to write code before they can use somebody else’s. The concept of a function, a variable, a condition, and a loop are completely alien to novices. These four elements build the foundations of programming. Everything a program is made of relies on them. Students are hearing these concepts for the very first time, but it is of the utmost importance that the students become proficient with them. If students do not master the fundamentals, everything that follows looks like magic and leads to confusion and frustration. Teachers should spend more time on these fundamentals. But, sadly, many move on far too quickly. The problem is that some teachers struggle to put themselves into the role of a student. They have been programming for ages and have forgotten what types of problems a beginner has to deal with. It is quite similar to a professional rally driver. He can’t imagine that somebody needs to think before braking. He just does it automatically. I design my exercises so that they are challenging but solvable in a reasonable amount of time by using a combination of the four main elements. A good example is a converter for Roman and Arabic numbers. This challenge requires patience from the students. Once they successfully apply the four elements to solve the challenge, they also get a big boost in motivation. Fundamentals are important. Don’t move on until they are settled. Libraries and Frameworks After students spend a lot of time coding, they must learn that most code already exists in the form of a library or a framework. This is more a mindset than a pattern. As I have written before: Modern developers know and pick the right library. They don’t spend hours writing a buggy version on their own. To make that mindset transition a success, the examples from the “fundamentals phase” should be solvable by using well-known libraries like Moment.js, Jackson, Lodash, or Apache Commons. This way, students will immediately understand the value of libraries. They crunched their heads around those complicated problems. Now they discover that a library solves the exercise in no time. Similar to TDD, students should become suspicious when colleagues brag about their self-made state management library that makes Redux unnecessary. When it comes to frameworks, students will have no problem understanding the importance once they understand the usefulness of libraries. Depending on the course’s timeframe, it may be hard to devote time to frameworks. But as I already pointed out, the most important aspect is shifting the mindset of the student away from programming everything from scratch to exploring and using libraries. I did not add tools to this pillar, since they are only of use to experienced developers. At this early stage, students do not need to learn how to integrate and configure tools. Master & Apprentice In my early 20s I wanted to learn to play the piano. I did not want a teacher, and thought I could learn it by myself. Five years later, I consulted a professional tutor. Well, what can I say? I’ve learned more in 1 month than during the five years before. My piano teacher pointed out errors in my playing I couldn’t hear and made me aware of interpretational things I never would have imagined. After all, she instilled in me the mindset for music and art, both of which were out of reach for me as a technical person. It is the same in programming. If somebody has no experience in programming, then self-study can be a bad idea. Although there are many success stories, I question the efficiency of doing it alone. Instead, there should be a “master & apprentice” relationship. In the beginning, the master gives rules the apprentice must follow — blindly! The master may explain the rules, but usually the reasoning is beyond the apprentice’s understanding. These internalised rules form a kind of safety net. If one gets lost, one always has some safe ground to return to. Teaching should not be a monologue. The master has to deal with each student individually. He should check how the students work, give advice, and adapt the speed of the course to their progress. Once the apprentices reach a certain level of mastery, they should be encouraged to explore new territory. The master evolves into a mentor who shares “wisdom” and is open for discussions. Challenge and Motivation “Let’s create a Facebook clone!” This doesn’t come from a CEO backed by a horde of senior software developers and a multi-million euro budget. It is an exercise from an introductory course for programmers. Such an undertaking is virtually impossible. Even worse, students are put into wonderland and deluded into believing they have skills that are truly beyond their reach. No doubt the teacher is aware of that, but creates such exercises for motivational reasons. The main goal of an exercise is not to entertain. It should be created around a particular technique and should help the students understand that technique. Motivation is good, but not at the sacrifice of content. Programming is not easy. If the students don’t have an intrinsic motivation, coding might not be the way to go. Newbies should experience what it means to be a professional developer. They should know what awaits them before they invest lots of hours. For example, many business applications center around complex forms and grids. Creating these is an important skill that exercises can impart. Building an application similar to Facebook might not be the best lesson for students to learn right away. Similarly, a non-programmer might be surprised at how few code lines a developer writes per day. There are even times where we remove code or achieve nothing. Why? Because things go wrong all the time. We spend endless hours fixing some extremely strange bugs that turn out to be a simple typo. Some tool might not be working just because a library got a minor version upgrade. Or the system crashes because somebody forgot to add a file to git. The list can go on and on. Students should enjoy these experiences. An exercise targeting an unknown library under time pressure might be exactly the right thing. ;) The sun isn’t always shining in real life. Beginners should be well-prepared for the reality of programming. Final Advice Last but not least: One cannot become a professional programmer in two weeks, two months or even a year. It takes time and patience. Trainers should not rush or make false promises. They should focus on whether students understand the concepts and not move on too fast.

099: Funcadelic with Taras Mankovski

Play Episode Listen Later Apr 12, 2018 43:08

Taras Mankovski: tarasm In this episode, Taras and Charles talk about a project that they work on together: Funcadelic - a Functional Programming and Category Theory for Everyday JavaScript Development. Funcadelic takes the simple idea that a single function can operate on many different data structures (typeclass oriented programming) and brings it to JavaScript. Yes, there are a lot of FP libraries out there, but this one is geared towards unlocking the magical powers of functional programming while always maintaining a tangible and accessible experience for JavaScript developers. Because if you're a JavaScript developer today, you're already using most of the structures in funcadelic! Transcript: CHARLES: Hello everybody and welcome to The Frontside Podcast Episode 99. My name is Charles Lowell, developer here at The Frontside and your podcast host-in-training. And with me today is Mr. Taras Mankovski. Welcome. TARAS: Thank you, Charles. It's a pleasure to be here. CHARLES: Yeah. So, you are ubiquitous in the JavaScript world. You do a lot of stuff with mentoring and you are involved in a bunch of different interesting projects. I think you're one of those developers who's difficult to classify, which is – that's definitely one of my favorite kind of developers. I wanted to have you on the show today because there's been a project that we've been collaborating on. And there have been some interesting ideas to come out of that and solidify through that project, at least in my head. And yeah, I thought we could maybe just talk about that a little bit. TARAS: Yeah, sounds good. It's going to be fun. : The thing that we are going to be talking about is a project called Funcadelic. It's more than really just a library, a JavaScript library on GitHub. It's kind of a different way of thinking about your code. And so, I know for me, where this really became part of my workflow was, when was it? It was about three months ago or something like that? Six months ago? TARAS: Oh, I think yeah, I think it's probably more six months ago. I think it's probably what, two months, I think probably December maybe? CHARLES: Okay. But it's hard now to imagine working without this tool on my workbench. It's been probably the biggest game-changer for me in the last, I don't know, definitely in the last several years. TARAS: Yeah, it's pretty impressive how little, how small of a library can have such a big impact in what we do day-to-day. Because it definitely makes me think differently about how I can solve problems that I solve on a daily basis when I work with React. So, it's been pretty interesting. I think for me, having worked with this library, I think what I'm getting is an understanding of how things work in a way, and a perspective on how React works, in a way that I don't think was available to [inaudible] Funcadelic. The funny thing is it's not a React library, right? It's not designed for React. It's just that… CHARLES: I don't even think that – it helps you think about React, but I don't even think it's the way that the React developers think about React, right? TARAS: Yeah, I don't think so, either. I think a lot of people are on the spectrum of understanding functional programming. And I think a lot of people use, people learn how to use React, but they don't really – I don't think a lot of people have traveled very far. I'm talking about general, majority. There's definitely people who know functional programming really well. And there's a lot of really good libraries in the JavaScript space for doing functional programming in JavaScript. But I don't think the general public, the general people that on a daily basis go into – write a render function and do ‘this.' or like ‘product.map' and then return an array of components. I don't think those people necessarily think about or get the context within which they use this tool. CHARLES: Right. And I think that's actually kind of one of the reasons I think a library like Funcadelic is so important and fills kind of a missing piece in the ecosystem, is because it really is predicated on the idea that programmers use these concepts all the time. They really are, they're foundational. But we only kind of see them out of the corner of our eye, in our peripheral vision, as being like a formal concept, like mapping. And giving a name to that. You know what I mean? Like you do the mapping, but you're not thinking about: how do I generalize over it? And I think that that for me, certainly in my journey with functional programming, I thought that it was mostly about functions. Not to say that it isn't, but that was kind of the end of the story. It's like, keep your functions pure so that the outputs are only dependent on the inputs. And away you go. And understand closures and higher-order functions, functions that return functions or take functions, and that's it. But I really feel that that's only half the story. TARAS: Part of it I think is that for people, even if you look at the kind of content that's available around functional programming, it tends to be – trying to kind of [reach] people into this idea of thinking of map, filter, reduce, kind of operations. And I think that's a place where everybody starts. But I think what happens is that you really are missing – and I think for most people. And it wasn't for me, it wasn't until you wrote the readme for Funcadelic and then I read it – up until that point I didn't really, I was also the same. I didn't know how these things were related to each other. Because there's this history and wealth of conceptual depth that connects all these things together. And these things are well-understood by people who don't – they're probably not writing JavaScript on a daily basis. They might be like Haskell programmers or Lisp programmers or ClojureScript or something like it. In other worlds, not JavaScript world. So there is all this understanding about how functional programming works but I don't think it's really leaked to the general masses of the JavaScript community. CHARLES: Yeah. TARAS: You know? And it wasn't until I started reading the readme – I'm like, “There's so many answered questions that I didn't even know these questions were asked.” You know? CHARLES: Yeah, yeah. Yeah, no. And I think you're absolutely right. It isn't accessible to the general JavaScript community. And part of that is because one person's – like when you read about these things, when I would go read about these kind of higher-order concepts, of basically classifying functions, not just of saying, “Yeah, what is the essence of a map operation? What's the essence of an apply operation?” you know, “What's the essence of concatenation?” things like that, I go read the documentation in Haskell or in Clojure. And first of all, it's hard to distinguish when you're not programming in those day-to-day, am I reading reference documentation or explanatory documentation? But even in the explanatory documentation, they're using what seems like incredibly self-referential and abstract examples. And I don't think that's necessarily a knock against those communities. I think what it is, is what's concrete to one person is abstract to another. And it's like, if you're working with those things, you're working with those sets of analogies, and then you're working with those abstractions every day, then they're concrete to you. In a sense that once it clicks in your mind and your mind kind of accepts it and rationalizes over it, then it moves from being, “Yes, it's an abstraction. But it's a concrete abstraction,” in the sense that you can have a conversation with somebody and use that abstraction as an example, as a counterpoint, and a method triangulate and reveal other abstractions. But if you're talking to somebody for whom those abstractions haven't clicked yet, then it's just, it's opaque. And it's not helpful. And so, I think that one of the things that I realized is like we are using these abstractions, we just don't have names for them. And so, I wanted to give them names and put them in the hands. And the names are weird, but they are really useful. And so yeah, maybe we could talk about some of those right now. Because I think that maybe now's a good time to actually introduce some of those abstractions. So for example, if you don't know what a functor is, it's worthless to talk about a monad, in my opinion. So, that was critical piece of information for me. Because that is like missing in every monad tutorial you ever read. At least, I must have read a thousand monad tutorials. And they kind of glossed over functor or didn't mention it. Whatever. Maybe they did but I wasn't looking. And that needs to be put front and center, that there is a natural sequence to these things. It's like, some of these abstractions are built on other abstractions and you have to – you can't skip to monad. You have to start with functor. Again, I realize that's probably gibberish gobbledy-goop to a lot of people. So really, this is what Funcadelic is about, what this conversation is about, is just saying – talking through it in real-world examples to make those abstractions concrete, so it doesn't feel strange anymore. TARAS: Yeah. It's definitely giving names to things. I think it's really helpful. One thing I really like about Funcadelic is that you're not giving names that you made up. These are names that existed for 50 years. They're historic. And so, when you talk to somebody who is familiar with functional programming and if you say ‘functor', all of a sudden, I feel much smarter. And we're actually referencing the same thing, because we are – because alternatively, you can say something like, “Something that is mappable,” right? Like a functor is essentially describing something that you can map over. CHARLES: Right. That's all it is. TARAS: Right. But you know, having a name for it, it allows you to just describe it exactly as it is. CHARLES: So yeah, there are tons of things that you can map over, right? Most of the time, we think about arrays as something that we can map over. TARAS: One thing I found really interesting in starting to use Funcadelic is that when you start thinking about things as they are like abilities – like you know with an array you can map over an array. It's something we've all been doing for a while – but then something that you end up doing a lot of. When you get familiar with an array, being able to use object map, mapping an object, becomes something you want to do at some point. Most of the time, what happens is that you're like, “Oh, I don't actually – well, I have to write this thing. How do I write this thing?” and then by the time you do this, you're like, “I'm just going to go to Lodash and I'll just get the map thing that will map an object.” At the end of the day, it doesn't quite necessarily feel right because a lot of these libraries – like, Lodash has map but it feels like there is always some kind of a compromise with how these things are implemented. It's not consistent. CHARLES: Right. TARAS: And I don't remember exactly what the problem with Lodash map was. I know for a fact there are, like there's different ways that you can map things. There are different functions available for mapping different things in Lodash. CHARLES: There's ‘map to' and ‘map in' and blah, blah, blah, blah, blah. TARAS: Yeah. All those different variations. But I think it's been really interesting. We've been using Funcadelic on a project we've been working on, on microstates. And just being able to use one function map that is going to map an array or is going to map an object and it's going to do it the same, use the same function, and it's going to do the same thing. CHARLES: Yeah. You have one function that maps over the values. And that's the thing, is you realize you can map over arrays. You can map over objects. You can map over observables. You can map over promises. You can map over trees. You can map – there's literally thousands of things that you can map over. And realizing that all of these fragmented interfaces can be coalesced into a single interface. And so, it really is, I think the biggest thing is like the power of polymorphism for a function. Because that's basically the problem that I think – it's not I want to say basically the problem. I think it is a problem that a lot of the functional programming libraries suffer from, is that the only polymorphism is object polymorphism, which is kind of the native polymorphism in JavaScript. Whereas in systems like Haskell and like Clojure, you can have a function be polymorphic. And so, one function can operate on many different kinds of data, provided it has an interface. So, when we're working in microstates, we use literally one function: map. The same, the actual same function, reference to the same function we use everywhere when we map. And we're just mapping a bunch of different things. So, I think that that's one of the reasons that I prefer Rambda, for example, over Lodash, is because it has a form of polymorphism. Most of the things like maps and lenses and applicatives and stuff, almost everything works on both objects and arrays. That's actually kind of nice. So, Rambda has a basic polymorphism. But I think one of the other things that is really empowering about Funcadelic is that it allows you to make the map function work on any data structure that you happen to come up with. Anything that you want. You can make it mappable and map will work on it. TARAS: Yeah. I think for people, it's probably quite abstract, what that actually looks like. I think one thing that's interesting is that – so for listeners, the way that would look is you have a class, you have an ES6 class, which gives name to a certain piece of data that you have in your application. And then what you can do with Funcadelic, you can then say, “This is how you would implement – if you were to map this kind of an object, if you had an instance of this object, if you wanted to map that object, you can specify: what is the function you would use?” So, even though you would use the same – you would import map from Funcadelic and you would use that map to map whatever that object is and whatever type it is, but there's a way for you to say, “For instances of this type, I would like to use this specific implementation of a map to map that object,” but use one function to do it. So, it's going to use one function that you call. But you can specify, under the hood it can specify how the actual, what is actually used to map that instance. CHARLES: Right. And then that's nice, because then you can – anything that uses a mappable object, there's a couple of reasons that that's nice. Any time you can have some sort of higher-order mechanism that just requires that something be mappable, that it be a functor. And then it's really nice because then you can have higher-order operations that they just need something that's mappable. But you don't have to use that one shot of actually having a map function as a property of the object. You can actually, you can kind of define wrapper classes or whatever, that then introduce a unique way that this object can be mapped. So, you can have the same structure and map it three different ways. Whereas you're kind of constrained by that using normal OO inheritance because you have to have a map property on your object. TARAS: Yeah. There's something else actually, when you start thinking about this. For me personally, I think the first step when we start working with objects, having mappable objects, it was the first thing that was really helpful. But then I think really quickly, right after that, I think my second thing that I started using and I think is probably my favorite feature now, is append. I think it's actually – yeah, so append is an implementation of a semigroup but I think it's simpler. A simplest metaphor would be something like object assign. So, object assign is an implementation of a semigroup, except that object assign mutates the object that you pass into it. Right? CHARLES: Right. TARAS: It doesn't create a new object for you. CHARLES: Right. So again, getting to this idea that there are some universal operations. Like there's this idea that you can take two things – I don't want to say object because that's an actual concrete type in JavaScript – two things and you can smoosh them together. And I think there was actually – wasn't there literally a big controversy about this? TARAS: Yes. CHARLES: About like, array smoosh? I think this is nice – smooshing, right? But you can smoosh things together. And with addition, I can smoosh two integers together or two numbers together and get a third number, right? Or with objects, I can take two objects and smoosh them together by merging their keys. Or I can take two strings and I can smoosh them together and I can end up with a string that's concatenated. Or I can take two arrays and smoosh them together and I've got now an array that's been concatenated. So, what's interesting is these are all very, very different types that I've just described. And yet, there is some fundamental operation about them. And I think this is actually something that's bad about JavaScript is there's five different names for all those operations that we talked about, but it's really one unifying concept. And that might seem like a small thing, but when you have five different interfaces for one fundamental construct, that leads to fragmentation and you can't treat that data uniformly. And it ends up like, paper cuts, paper cuts everywhere. Whereas if you can unify all of these into a small, one thing, which is like we can append two objects, and then we're going to have an implementation of append for array. And behind the scenes it's going to call smoosh. And we've got a universal – we've got an implementation of append for object, which is going to assign the keys in an immutable way and return a new object. Or we're going to have an implementation of append for string which is going to concatenate the strings. You might even, I don't know a hardcore FP nerd would have to probably correct me because this is just totally conjecture, although I know it's probably a solved problem – is maybe you could say we append two functions together. And that returns a function which is composed, right? That might be a way that you could say – what would it look like? Is function a semigroup? Can we append two functions together? And maybe you end up with like a pipe or a function composition or something like that. But I think that highlights, when you have these universal interfaces, because literally I feel like most of the stuff that we have been working with, there's literally five, there's like five interfaces. And everything is one of these five interfaces. And it kind of flips you on your head, because the classic programming wisdom that I have certainly have espoused for at least the last 10 years is that you don't want to race to find abstractions. That's dangerous. Because you can get locked into the wrong abstraction, right? Wait. Let the abstraction emerge. And I'm a lot less bullish on that concept now that I've discovered these things, because that wisdom is cultivated in a world where there are [billions] of abstractions, if you're giving unique names to everything and the combinations between them. But if you are coming up in a world where there's five basic abstractions, then it actually pays off to ask the question, “Is this thing a functor? Is it a semigroup? Is it a monad? What would that look like?” It's a nice thought experiment that doesn't require that much investment. You can think about it for a couple of minutes. And usually, you can come up and say, “Yes, yes. It totally is,” and I can start using it. And now I've introduced this really powerful abstraction. Or you say like, “No, no it's not.” And then that information is just as valuable. And so, it's very low-cost to experiment with abstractions. And so, I kind of think of it as – I know I'm on a little bit of a rant here but this has kind of been a major revelation for me – is that when you have very few abstractions which you compose in myriad ways versus having a whole bunch of abstractions that can't be composed very much, the cost for experimenting with abstraction and making the wrong abstraction is several orders of magnitude lower. And so, you don't have to be as cautious. And you can actually use trying on abstractions as a tool, rather than a very, very high risky undertaking. And just to kind of close that thought out, I think that – I don't know if anybody else but me remembers the world before we decided we were going to make all of our web services RESTful – like when people first started building all these web services, we were just going crazy with the endpoints. And there was no rhyme or reason. Kind of weird arbitrary levels of nesting. Sometimes, you'd throw in an ID as a query param, sometimes you'd throw it in as part of the path. And then I definitely remember, it was probably around, I don't know, 2010 for me where I listened to a podcast where James Edward Gray was talking about S3 and ‘Was it a RESTful interface?' and the O'Reilly book. And it really clicked for me. And realizing that if you constrain yourself to thinking about your API at least as these fundamental operation of manipulating resources, and you were constrained to four verbs and everything, you want to have ID-based URLs and resources and as flat as possible, those constraints actually are very enabling for consumers of your API and for actually authoring an API. And I think it's the same principle at work here. Anyway, so I'll end that rant. [Laughs] TARAS: Yeah. I think it's, I think people could probably, for those who haven't been in programming as long as Charles has been, it's probably easier – Charles I think people could probably relate to what's happening with components now, I'd imagine. Because having components essentially look the same across every framework, they all have props and they all render, return some DOM, or some variation of that. But it's kind of the same thing. You take some data and then you return something that is going to become DOM. And I think having that as a rule for what a component is, you can then make really complicated applications using these fundamental building blocks. And then you don't have to – there's not really much thinking on, “Well, how am I? What interface is this component going to have?” Okay, well you know it's going to accept props. And you know it's going to render some DOM when you actually render it, right? CHARLES: Right. TARAS: That simplicity I think is really helpful. And I think it's one of the things that – I think one of the things about Funcadelic that I really like is there's kind of a really small set of rules that are really helpful. And these rules are actually, they make it predictable. Because one thing that I find really challenging with using Lodash or using Rambda is that because there are so many functions, it's difficult to know what is actually going to happen when I do something. So, a good example would be like if you use omit from Lodash, Lodash omit will then, it will actually – one thing you can do is you can materialize your getters. So, if you have getters in your objects, those getters can become values on the new object that's created. So, that's one thing that could happen. Or if you use omit, your symbol, if you have values… CHARLES: What does omit do, by the way? I'm actually… TARAS: Omit is a pretty popular way to exclude functions. Basically like a filter equivalent for an object. It's usually used to remove some props that are coming into a component. But it can do some – it can actually change the type of the object. One thing you know for sure is if you use something like omit or if you use assign, if you have an instance of something, guaranteed, working with that object in a mutable way is going to cause some really strange things. I think with omit, if you were to have an instance, it would definitely not give you an instance of the same type, like an object of the same type. It will give you just a regular [inaudible]. And there is no real way – you could create an instance. I don't know what assign would do. I'm guessing that it would just take an instance and would put things on it. But it's really not – I think this kind of ambiguity doesn't work very well when you're trying to build something, when you really just need to know exactly how your tool behaves. I think that's one thing that with Funcadelic, because it's such a small API and because you know for a fact that the library is designed to be immutable and it's designed to preserve type information, then you know that if you use one of the operations, you will get most likely the same kind of object. And you're not – well, you will the same kind of object and it's not going to mutate that object. And so, there are some of these guarantees that are actually really helpful and [inaudible] is liberating, I think. CHARLES: Right. TARAS: Especially when you're trying to do more challenging things, not trivial, just copy some properties from one object to another. But when you're actually doing more sophisticated things, in those use cases, having these kind of rules is extremely powerful. CHARLES: Yeah. And I've definitely resisted and I think will continue to resist expanding the API surface area that much. Because it is, I think there's only five or six functions in there. But what you get for those functions is extremely powerful and extremely predictable. I think it might help to give a concrete example. Like when you were talking about object assignment. Like if you have a car class in your application and you want to do an immutable object assign, well the kind of stereotypical way to do that or the typical way to do that is you assign. You create an empty object and then you assign one car to it and then you assign the next car to it. And now you've merged these two car things, right? But then the problem is, you're going to get an object out of that, not a car. It's just going to be a vanilla object. Now, it's going to have all the properties of both, but it's not going to be a car. And that could be a problem if you've got any custom methods on the prototype, any computed properties on the prototype. It's going to be a problem. Whereas Funcadelic, you can append two cars together and you're going to know that it's going to have both of the properties. You're going to know that it's going to be of type car. And you don't have to worry about running the constructor or anything like that. It's just going to have – the properties are going to be carried over properly. If you're using a library like Lodash or Rambda or something that doesn't account for type, because in order to append two things or map something, the implementation actually lives with the type, not with the function. The function is polymorphic, but the implementation lives with the type. You can then actually, you can always return the proper type. Because it's ultimately – like if your map operation or your filter operation or your what have you operation doesn't take type into account, then there's no way to actually preserve type. But because we delegate in Funcadelic, it's core to the concept. And so, it's actually a very trivial thing to do, which is why you get that repeatability. TARAS: One of my favorite things about append and semigroup implementation for object is that you can overload getters on an existing instance. So, what you get is you get a new instance with the getter that you passed to append applied to that instance. And this is kind of trippy but it's actually really powerful because – so, let's say you have an instance of an object and that instance has some getters on it. And those getters use some properties of this object to compute their value. And so, when you want – if I need to create a copy of that object in such a way that the getters still continue to work properly but I need to override how one specific getter works for one specific instance, one specific scenario, one specific use case in my code, then I can just use append. So, the first argument is the original instance, second argument is an object that has the getters that I want that I want to overload the getters on the original object. And then append will squish those things together, smoosh those things together, and give me a new instance that has the getters that I passed in, in the second argument. And all the same things that the first object had. And that object will work. This new object will be a fully-functional object just like the original object that I still have a copy of, that I can use. But this is really interesting because one thing that I'm finding with having these kind of tools in my toolset is that I've had features that I needed to implement on a project. And the people that I work with are really technical. So, they know where problems are going to be. And so, the would write requirements for how something – for a feature that needs to be implemented. And knowing the problems, they're like, “Oh, by the way. You're going to have a problem in this area when implementing this kind of specific functionality.” And for me, I'm like, having this toolset, I'm like, “I don't see it as a problem at all.” It's so easy for me. Because I know that if I need to implement – so if I have something that has expected behavior, but I need to create something that behaves very similarly but slightly different in one particular use case, I can always just copy that object and then overload its behavior. And it's still going to be a fully-functional object. And I think that alone is just not something that you can do usually. It's not something that's available. CHARLES: Yeah. It's a technique that I think was discovered. Maybe it's not original to us. But it's just, the tools enabled it in the sense that it's like having a flashlight in a dark room. It's like, that technique was always there. It's just when it becomes so concise that it's so easy to just append one more computed property to a thing, then you just wouldn't have thought to do it otherwise. TARAS: What's interesting about this too, for me, is that – and this goes back to the context conversation that we had earlier – is that I think React brought into our lives functional programming kind of, in a big way. Because part of programming React applications is working with functional components and working with functional concepts. And a lot of the things, like Redux, a lot of these things are powered by functional programming. And they work together. They compose well together because they're all from the same paradigm. But the problem is that there are all these concepts developed together over time. And they've been tested together and they've been formulated together in languages like Haskell. But the ideas that make all of these stuff work really well together, they haven't really become available in the JavaScript community. And it feels like, it's like we're all using a language that we don't fully understand. And it's like we're all – a lot of people in the JavaScript world who works, when it comes to functional programming, it's kind of like having English as a second language. It's like, you can use the words but you don't understand the humor. And it's kind of like, you can't make a joke. It's kind of like that. You can't really express yourself correctly when you don't have full grasp of the language. And I feel like how we use functional programming in JavaScript is a little bit like that. And by starting to bring these ideas, moving the wealth of knowledge from the source into the realm where we actually need to use it now, we can actually start to take advantage – leverage all these insights that actually enables all of this. It's not like – so, the idea of how to write React and think in a reactive way or think in a functional way, those things are not just owned by the React core team or they're not owned by an elite group of developers who really understand how functional programming works. It's just available to everyone. And all you need to do is just learn some of these concepts that glue all these ideas together that are fundamental pieces of how functional programming works. CHARLES: Right. That's a great point. And it points back to kind of the original reason that I wrote Funcadelic and then started and then continued to work on it with you, is that it really was – it was actually meant as a – it started out as an educational exercise. What would these things look like if they were translated into JavaScript? And it turned out that it rapidly became core to my workflow and way of thinking. And so, it really is, there are weird names to these universal concepts. It is true. It is a foreign language. I really like that analogy. But foreign languages sound weird, and when people are talking in a foreign language, you can feel excluded. And the really, the reason that we wrote Funcadelic and the reason it's there is to make them accessible, these things accessible to you. So that those abstract foreign words can over time turn into concrete concepts that you're completely comfortable with, just like any word in any language. At some point, you approached it having no idea what that sound represented. And so, it really is trying to – the emphasis there is not to noodle about and dwell on the names of the concepts but to take the real things that you are actually doing, give them names and formalize them, to enable you to participate in this new functional world that you're describing. Because I love that sentiment. It does not belong to the React core team. It doesn't belong to an elite set of developers on this project or that project. It literally is a universal tool that is 100% achievable. And people don't even realize how close – if they've been working with JavaScript for a couple of years, how close they actually are. TARAS: Yeah. I think they're really – for most people, if they were to read the readme and then – well, I think one of the problems, it kind of works with the language metaphor, is that you need an immersion, right? I think one of the reasons why Funcadelic really stuck and functors and semigroups and [filterable] and all of these things really stuck for me, and I'm thinking about how using monads and monadic operations or applicatives and all that stuff – the reason why it all stuck for me is because I've been able to talk to you about it. And I think for people, finding a network that will allow them to practice immersively, to think about functional programming, not just occasionally – I mean, you could do it occasionally as well, it just takes much longer. But once you really, once you have a few conversations where you try to dissect a problem in a functional way and you think about what these pieces are made of, it becomes very natural, very quickly. CHARLES: Yeah. I think that's actually a really great point. And the thing is, you can immerse yourself incrementally. So you can just say, “You know what? I'm just going to start using append.” Anywhere that I would concat two strings or I concat two arrays or I would do object assign – screw that. You can even just say, “Instead of using object.assign, I'm going to use append,” and start there. Or to say, “I'm just going to start with mapping.” I think also the thing that's nice about it too, is the buy-in can be incremental. But you're right. You do need immersion. You do need practice. You need to actually use, you need to use the functions and you need to be able to use them one at a time, so that your mind can close over them. So then, you can kind of move onto the next one. TARAS: Yeah. CHARLES: So, that might be one way, is to say – because you know, I don't think I really understood. I was already using append and map ubiquitously before I really understand applicative/apply. So, you don't have to grok it all at once. You can definitely bite it in chunks. And the best way to do that is to start with one concept and really just attack it mercilessly. And then also understand that there's a natural sequence there. TARAS: I would add a little bit of a caveat to that. I think there's a thing about using – doing something for learning purposes and there's another thing about shipping things. What's interesting with Funcadelic and what's interesting about a lot of these ideas from functional programming is that I think they give you benefits that you might have not previously thought. Like for example, if you're going to concat two strings together, doing it with append is probably the most robust way of doing it, relative to just being able to use [inaudible]. CHARLES: Yeah, that's true. You wouldn't want to use a string [inaudible], wouldn't you? TARAS: Yeah. But there are areas when using – there are times when things are just not possible otherwise. Like for example, if you wanted to treat an instance of a class in an immutable way, this is simply not possible in any way. So, if you're going to say, “I'm going to work with a bunch of these instances of ES6. And I want to keep them as instances, because they have certain behaviors that I want to have. I want to have a getter, or I want to have a method on it. And I want to keep these things fully full instances, not broken, not be turned into objects. I want them to be normal instances but I want to work with them immutably. When I need to make a change, I want to get a new object and not modify that object.” So, if you set yourself that goal and you say, “This is what I'm going to do,” then you really are not left with very many options. You only really have, you have to use append from Funcadelic. And because alternatively, you're going to implement something yourself. You might as well just use append. And [I think] that's a good place. I think if you're starting to, if you need to make something lazy, if you need to delay an execution of something – so, instead of pushing that execution, instead of using object assign and then computing everything ahead of time, you can use append. And you can create a getter and you can delay the computation of that value until the point when the user actually reaches for that value. If you want to start doing that kind of stuff, you really are not left with very many options. And append is the way to do it. But that's the thing, is when you start to set these kinds of standards for yourself, you level up in a way that is very significant. I think it's like a natural progression of learning. You start off learning and anything goes, as long as you can make this website work, it's like, “I'm happy.” And then over time you get better and better at it. And then when you get good at building applications, your next step might be like, “What if I was stricter about it? What if I could actually – what would that open up for me? What would that allow me to do?” I personally think about it that way. CHARLES: Yeah. I think that's a good way to think about it. You mentioned having a network for discussing these concepts and trying to internalize them. Let me first and foremost offer myself as somebody. If this is a hill that you are interested in climbing, and I think it is a very worthwhile hill to climb because of the perspective that you will gain from its summit, please reach out to me. You can contact me at cowboyd on Twitter or cowboyd@frontside.io. I'd be happy to discuss these kinds of things, because I think that these tools are just incredibly powerful and will improve you. So, if folks want to get in touch with you, Taras, where would that be? TARAS: I'm tarasm@gmail.com and tarasm on Twitter. CHARLES: Alright. Well, thank you everybody for listening. And as always, if you want to get in contact with us at Frontside, you can just email us at contact@frontside.io or give us a shout on Twitter at @TheFrontside. Thanks everybody. We'll see you all next time for episode 100.

english id dom react api redux github javascript fp s3 urls haskell oo restful taras lisp functional programming clojure es6 frontside category theory clojurescript lodash charles lowell taras mankovski

091: RxJS with Ben Lesh and Tracy Lee

Play Episode Listen Later Dec 13, 2017 49:49

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.

netflix google man deep microsoft pennsylvania 3d pittsburgh cycle concept dom beta shared react iot api redux google maps chrome java technically ajax javascript minority report fp sql rx array scala vue flashing haskell angular les h toot arduino dmitri jquery taras w3c google home mini observable websockets angularjs alkali tracy lee modern web bluetooth low energy benis tc39 rxjs frontside ben it alex castillo elrick ben you learning team lodash jewelbots ben there ben oh ben lesh ben so jay phelps whatwg ben well charles lowell ben right this dot tracy you jen luker functor contributordays charles you angular material this dot media rxmarbles rx workshop ng cruise

090: Big Testing in JavaScript

Play Episode Listen Later Nov 30, 2017 35:56

How do we ensure a high level of quality and maximize the refactorability of our code? Frontsiders, Wil and Charles, talk about their battle tested techniques for testing web applications, not only in React JS, but in any JavaScript framework. Links Acceptance Testing Integration Testing jest Cypress.io Assertion Ember CLI Mirage mirage-server react-trigger-change Transcript CHARLES: Hello everybody and welcome to The Frontside Podcast, Episode 90. My name is Charles Lowell, a developer here at The Frontside and your podcast host-in-training. And with me today is Mr. Wil Wilsman. Wil, who just got back from Nodevember just walked straight into the office and is ready to podcast with us on a very, very, very interesting subject, I think, today. We're going to be talking about acceptance testing in JavaScript applications, especially some of the techniques that we've developed here around testing React applications based on the lessons that we learned from the Ember community. But really, more than just React applications. Really, testing any JavaScript application from the inside out, making acceptance tests for that. So, I think we're going to talk about some of the challenges that you encounter and some of the really novel solutions that are out there that we had nothing to do with. And I guess we really didn't have, just more of cobbling together of various techniques for a powerful witch's brew for acceptance testing. Anyway, so Wil, just to round out the problem space or explore the problem space, what are some of the challenges that you encounter with an acceptance test? Actually, let me back it up even further. What is an acceptance test in a JavaScript application compared to what people normally encounter? WIL: Acceptance testing or end-to-end testing is just a problem that every JavaScript app should face. Not everyone does, but they definitely should. And basically, it's how the user interacts with your app through the browser. And every part of that we want to test, from the browser triggering browser events, interacting with the app, not calling functions or clicking buttons, and we're pretending we're a user. CHARLES: Yeah. You know, I know that when we showed up in the React space, that was not really the way that most people tested their applications. WIL: No, not at all. they're all about unit testing. Make sure every small piece of your code works, and to some degree integration testing, making sure your components work with other components. But, nothing is out there really for those big acceptance tests that you want the user to click a button and expect them be brought to a page or these fields to be filled out, et cetera. CHARLES: Mmhmm. Yeah. And there certainly was a very high level of maturity around unit testing, like you said. There are tools like Enzyme and… WIL: Jest. CHARLES: Yeah, Jest. But I was actually shocked to find out that Jest didn't even run in the browser. WIL: Yeah, it's all virtual. CHARLES: It's all virtual. It's completely and totally simulated and stubbed. And that presents some problems. WIL: Yeah. The main problem is cross-browser testing. Some people might consider that to be separate from their acceptance testing but you should be able to just run your acceptance tests in multiple browsers and be able to also test cross-browser support. CHARLES: Mmhmm. Yeah. And so, if you're using something like Jest, you're never actually running the code inside Safari. You're never actually running it inside Internet Explorer. You're actually running it in NodeJS. WIL: And you know, your user is not going to run it in Node. [Laughter] WIL: They're going to use a browser. CHARLES: I don't know about your users. WIL: [Chuckles] CHARLES: [Laughs] You know, we like to stick to the pretty advanced. It's like, go to getNodeJSBrowser.com. WIL: [Laughs] CHARLES: Enough of this Firefox BS. But not seriously, it was certainly a problem. We were looking around, because we never like to build anything ourselves if we can avoid it. But it really just seemed like there was not an off-the-shelf solution for writing these big style acceptance tests in JavaScript. There are some services out there. There's a couple now. What was the… WIL: I think the main one here is Cypress. CHARLES: Cypress, yeah. So, there's Cypress now. I've watched the instructional videos but never actually tried to integrate it into my application. WIL: Yeah. I think at its core it takes the same approach that we've been doing with how we're interacting with our tests. CHARLES: Mmhmm. Okay. The main difference is, is it that it's a service? Like you have to edit your tests through… WIL: Yeah. CHARLES: Their web browser, their web interface, and use their assertion library? WIL: Yeah. I'm not sure about the editing part. But yeah, it's their assertion library. I'm pretty sure it's their test runner and it's their testing environment. Really, the only control through that is through their UI, or through settings, basically. And you're stuck with those. You can't use other… I don't think you can use Mocha with Cypress. CHARLES: Right. WIL: Although it's very much like Mocha… CHARLES: Right. WIL: It's not. CHARLES: Right, right. And I also noticed, we'll touch on this later, the assertions, most of the side effects that were happening were happening right there inline inside your assertions. And that might be an opaque statement, but we will actually get into that later. WIL: Yeah. And I think one of the things about their side effects so to speak is everything leading up to a side effect is a promise with Cypress. CHARLES: Mmhmm. WIL: So, when you select a button and click it, Cypress is going to wait for that button to actually exist before it clicks it. CHARLES: Right, right, which is actually pretty cool. So, that's actually a perfect into into one of the primary challenges with doing acceptance testing in general in a JavaScript application. This is a problem when you're doing it in Ember. It's a problem in React. It's really a problem anywhere. And that is, how do you know when the effects of a user's interaction have been realized? Right? WIL: Yeah. And in Ember you take advantage of the run loop. Once that action happens, you wait for the run loop to complete and then your tests run. CHARLES: Right. So, the idea is that I've clicked some button or I've typed some key or I've moved the mouse. And then I listen for the run loop and when it's “settled” then I can now run my assertions because I know that the side effects that I was looking for have now been realized. WIL: Yeah, hopefully, if you're... CHARLES: Hopefully. WIL: Writing your app right. [Chuckles] CHARLES: Right, right. But that actually presents some problems in itself because it requires visibility into the internals of the framework. WIL: Yeah, so Ember is built with testing in mind. CHARLES: Mmhmm. WIL: And other libraries like React just being a view library might not be built with testing in mind. So, we don't have those hooks to wait for this loop to complete, wait for all of these things to be rendered before you continue. CHARLES: Exactly. And so, this is, I think it's actually kind of both a blessing and a curse. Because there are such strong conventions in Ember, they were able to build this wonderful acceptance testing regimen from the get go. WIL: Yeah. CHARLES: But like you said, that doesn't exist at all in the React ecosystem. And so, what do you do? There's no run loop. You're cobbling together a bunch of different components. And maybe you're using Redux, maybe you're using MobX, maybe you're using… you're certainly using React. And all of these things have their own asynchronies built-in. And there's not one unifying abstraction that's keeping track of all the asynchrony in the system. And so that presents a challenge. So, the question is then, if you're trying to not actually check and observe the state of a system until the right moment, how do you know when that right moment is? WIL: Yeah. And in early testing of a side React project I had, I would basically wait for a state to be complete before I continued my ‘before each'. And in the testing we're doing now, it's essentially what we're doing except the state is what the browser sees, or what the user would see in the browser. CHARLES: So you were actually querying the... WIL: Yeah. So, I was using Redux. So, in my app I was saying, when the Redux app is done loading... CHARLES: Mmhmm. WIL: The instance is set to true or false, then continue the test. CHARLES: Mmhmm. And so, what that means, what we're doing, is doing the same thing except observing at the DOM... WIL: Yeah, exactly. CHARLES: Level. And what it means is we actually… I would love to set this up and have a big reveal but I guess we'll just have a big reveal, is that essentially what we do is polling. WIL: Yeah. CHARLES: Right? So, when we run an assertion, let's say you click a button and you want the button to become disabled, there's an inherent asynchrony there. But what we will do is we'll actually run the assertion to see if it's disabled not one time. We'll run it a thousand times. WIL: Yeah, as many times as needed until it passes. CHARLES: Right, exactly. As many times as needed until it passes. And I think that is, at least to most programmer instincts, an odious idea. WIL: Yeah. CHARLES: [Laughs] WIL: It's like, “Oh wait, you're just looping over every single assertion how many times?” CHARLES: Yeah, exactly. And it feels, yeah, it feels weird as an idea. But when you actually see the code that it produces, it just sweeps away so much complexity. WIL: Yeah. And… CHARLES: Because you don't worry about asynchrony at all. WIL: Yeah. And it's pretty genius. If I'm a user and I click a button, it's loading when I see that it's loading. So, our tests are going to wait until that button says it's loading. And then the test passes. CHARLES: Right. And so, what we do is we essentially, we use Mocha but you could do it with QUnit or anything else, is that when you run your assertion, you declare, you have an ‘it' block or I guess, what would it be in QUnit? WIL: A test? CHARLES: A test? WIL: I think it's just a test. CHARLES: You have your test block. And so that function that actually runs the assertion and checks the state will actually run, yeah it could run three times. It could run a thousand times. It's just sitting there waiting. And it will time out. And it will only fail if that assertion has failed a thousand times or it has failed through, I think two seconds is our default. WIL: Yeah, yeah. I think we default to the runner's default timeout. CHARLES: To the runner's default timeout, yeah. WIL: Yeah. Or you can set that yourself with how we have it set up. And the other thing that comes from that is if your tests are only failing when they time out, how do you know what's actually failing? And our solution to that was we catch the error every time it fails and right before the timeout actually happens we throw the real error. CHARLES: Yeah. Exactly. But the net effect is that you're able to write your assertions completely and totally oblivious of asynchrony. You don't, we don't have to worry about asynchrony pretty much at all. I mean, we do, and we'll get into that. So, I made a global statement and then immediately contradicted it. WIL: [Chuckles] CHARLES: But hey, you got to be controversial. But for the most part, asynchrony just disappears because asynchrony is baked into the fabric. So, rather than thinking about it as a one-off concern or a onesie-twosie, it's just every single assertion is just assumed to be asynchronous. And so, that actually means you don't have to deal with promises. You don't have to deal with run loops. You don't have to deal with anything. You just write your assertion and when it passes, it passes. And there are some really unique benefits for this. And there are some challenges. So, I think one of the first benefits is that it's actually way faster. WIL: Right. CHARLES: Which is counterintuitive. WIL: It's incredibly fast. CHARLES: It's very fast. WIL: Yeah, for all the loops that's happening you might think every loop is going to slow it down slightly. But it really doesn't. Our tests, each test, even though it asserts five or six times, it takes milliseconds. CHARLES: Mmhmm. WIL: The test itself might only loop twice. CHARLES: Right. Exactly. Whereas if you're waiting for a run loop to settle, you might have some… you click a button, it disables, it also fires off an Ajax request and does all this stuff. But if all my assertion wants to know is “Is this button disabled?” then I only need to assert until that has happened. I don't need to wait until all the side effects have settled... WIL: Mmhmm. CHARLES: And then do the assertion. I just know, “Hey, my assertion, the thing that I was waiting for - that happened. Let's move on.” Yeah. And so, it's so, so fast. And that was actually, I didn't predict that. But I was definitely pleasantly surprised. WIL: Yeah, that was a very nice surprise. And all of our tests ran so much quicker than they would have in a run loop environment with Ember or something. CHARLES: Right. Yeah, yeah. That was, we actually had just come off a project where we were having that thing, that exact problem, which was that yeah, our animations were slow. Or, the animations were fine. They were perfect. [Laughs] But there were slowing down the tests. WIL: Yes. I think in that project, it was like, 30-minute tests... CHARLES: Mmhmm WIL: For the whole suite to run. CHARLES: Yeah. To which I'll add a public service announcement. I think this is a conjecture but I do believe that animations are best applied not to individual components but by the thing that uses a component. So, I shouldn't have an animation that's like, implicit to a dialog. It should be the thing that's showing the dialog that gets to decide the animation to use. Anyway, just throwing that out there. WIL: [Laughs] CHARLES: Because animations are about context. And so, the context should provide the animation, not the individual atom. Anyway, moving on. WIL: Some other podcast. CHARLES: Yeah. [Laughter] CHARLES: That's another podcast right there. But there's also, this does present some challenges or requires code to be structured in a way that facilitates this. So, there are some challenges with this approach, some things you need to be aware of if you're using this kind of system. We've kind of settled on a name for what we call these types of assertions and these types of systems. WIL: Yeah. We call them convergent assertions, because you're converging on something to happen. It's going over and over until it happens. CHARLES: Right. WIL: And yeah, a lot of these challenges that we've come across are things that you might not think of, like there are a few instances of false positives... CHARLES: Mmhmm. WIL: That happen with these convergent assertions. CHARLES: Right. So, what would be an example there? WIL: So, the most common example that I'm seeing so far is when you're asserting that something didn't happen. CHARLES: Mm, right. WIL: That would immediately pass. But if it takes your app... CHARLES: [Laughs] WIL: A few seconds for it to actually happen, then you could still have an actual failure but your test passed immediately. CHARLES: Right, right. So, what's the countermeasure then? WIL: We invert our assertions. So, we make sure they fail for a certain amount of time. CHARLES: Right. So, the normal case where you just want to say, “I want to make sure that my state converges to this particular state.” WIL: Alright. I said fail at first. I meant, pass. We have to make sure it passes for a certain period of time. CHARLES: Right, exactly. WIL: So yeah, the normal way is it fails until it passes, and then it passes. When you invert one of these convergent assertions, you're just making sure it passes repeatedly and if it fails at any point, you throw a failure. CHARLES: Right, okay. And so, that's like, if I want to check that the button is not disabled, I need to check again and again and again and again. WIL: Until you're comfortable with saying, “Alright. It's probably not going to be disabled.” CHARLES: Yeah, exactly. And so there, it's kind of weird because it is dependent on a timeout. WIL: Mmhmm. CHARLES: You could go for two seconds and then at the very end it becomes disabled. So, you just kind of have to take that on faith. But... WIL: Yeah. CHARLES: In practice, I don't think that's been much of a problem. WIL: No. CHARLES: It's more indicative of, if your button disables after... WIL: A few seconds. CHARLES: A few seconds, what's up with your... WIL: Yeah, what's up with your app? CHARLES: Yeah, exactly. WIL: If you're waiting for an Ajax request or something, an example, then you should be using something like Mirage Server. CHARLES: Right. Which is, man, we got to get into that, too. There are a couple of other things that I wanted to talk about too, with these convergent assertions. And that is, typically when you look through the READMEs for most testing frameworks, you see the simple case of the entire test, the setup, the teardown, and the actual assertions, are in the actual test. WIL: Yeah. The ‘it' block in Mocha or the test block in QUnit. You click a button, and then make sure it's disabled, and it moves onto the next test. CHARLES: Mmhmm. WIL: Then you click a different button or the same button and you assert something else in the next test. CHARLES: Mmhmm. Right. WIL: And yeah, you can't do that with convergent assertions because they're looping. So, if you click a button in a loop it's going to keep clicking that button over and over and over again. CHARLES: Yeah. [Laughs] Right, right. So, it means that you need to be very conscientious about separating the parts of your tests that actually do the things that actually act the part of the user from the part of your test that's about observation. WIL: Yeah. So, our solution to that is we move out all of our things that have side effects like clicking a button or filling in a form, all that stuff happens in ‘before each's. And all of our actual assertions happen in these convergent ‘it' blocks that loop over and over again. So, our ‘before each' runs and clicks the button and then we have 10 or so tests that will loop and wait for various states to... CHARLES: Yeah. WIL: Be true. CHARLES: Right. That means that yeah, all these assertions do is they read state. And you just have to, you do have to be conscientious. You're not allowed to have any side effects inside your tests, your actual assertion blocks. WIL: Mmhmm. CHARLES: But that's actually, it's a good use case for the whole Act-Arrange-Assert, which has been around way, way, way before these techniques. But here, we're doing Act and Arrange in our ‘before each'... WIL: Mmhmm. CHARLES: And then we're doing Assert later. And I think it actually leads for more readable... WIL: Yeah, definitely. CHARLES: Things. WIL: And it also opens the door to something that we can't really take advantage of yet but if you have 10 assertions with one ‘before each' side effect, you could run all of those assertions in parallel. CHARLES: That's right. WIL: And your tests would be 10 times more faster. CHARLES: Mmhmm. Yeah, exactly. Or you could run them in parallel or you could just run them one after the other but you wouldn't have to run that ‘before each' 10 times. WIL: Yeah. But something with that, that I found, is if we move all of our side effects to ‘before' blocks instead of ‘before each' blocks, sometimes a test three tests down that's waiting for something to happen... CHARLES: Yeah. WIL: That thing might have already happened earlier... CHARLES: Yeah. WIL: And it already went away. A loading state is the best example of that. CHARLES: Mmhmm. WIL: You show the loading state, the loading state goes away. So, if you move that button click into a ‘before' and that loading state test is three tests in, that loading state is already going to be gone. CHARLES: Yeah, so I think the long story short is we've kind of come to the conclusion that we would have to write our own runner. WIL: Yeah. CHARLES: Essentially to take advantage of this. But that said, we've done some sketching about what we would gain by writing our own runner. And the speed, we're talking about exponential speedups. WIL: Yeah. CHARLES: Maybe taking an entire acceptance test suite and having it run in five or six seconds. WIL: Yeah. We're talking about these tests that are already extremely fast. CHARLES: Mmhmm. WIL: Each test takes a few milliseconds or tens of milliseconds to complete. But then if you can run all of those at the same time, all of your tests for that entire ‘describe' block just ran tens of milliseconds. CHARLES: Right. Yeah. So, it's really exciting and pretty tantalizing. And we would love to invest the time in that. I've always wanted to write our own test runner. But never had, [chuckles] never really had a reason. WIL: Yeah. CHARLES: Certainly not just for the sheer joy of it. Although I'm sure there is joy in writing it. But that, yeah, we'll have to wait on that. But I am actually really excited about the idea of being able to maybe bring this back to the Ember community. WIL: Yeah. CHARLES: Because acceptance tests getting out of control in terms of the speed is I think a problem with Ember applications. And I think this would do a lot to address that. WIL: Yeah. CHARLES: I think, how long, if we were just using a stock Ember acceptance testing setup for this, I think we have about 250 tests in this React app... WIL: Yeah. CHARLES: How long does it take to run? WIL: Right now I think our tests take something like 20 seconds. And that's also somewhat due to they have to print the tests on the screen on Travis so that takes a little time. In an Ember setup, that could maybe take a few minutes. I mean, that's not that big of a deal, a few minutes. CHARLES: Right. WIL: But compared to 20 seconds. CHARLES: Right. you're still talking about an order of magnitude... WIL: Yeah, exactly. CHARLES: Difference. And using this, I think you could get a 30-minute test suite... WIL: Yeah. CHARLES: Down to the order of 3 minutes. WIL: Now when we're talking about those times, we're talking about the tests themselves. Of course, the CI would have to download stuff and set up the [inaudible]. CHARLES: Mmhmm, right, right. WIL: And that of course all adds to the time. CHARLES: Yeah, mmhmm, yeah. Earlier you mentioned, we talked about Ember CLI Mirage. This is actually something that is having now been using it for what, 2 years or something like that, it's just… it's impossible... WIL: To go back, yeah. CHARLES: To go back. It is. It's like [chuckles] you come outside the Ember community and you're like, “How is anybody ever dealing without this?” WIL: Yeah. CHARLES: [Laughs] WIL: A lot of the mocks are usually mocking the function that makes the request and it returns it in that function. That's what's out there currently, minus the Mirage stuff. CHARLES: Mmhmm. WIL: But once you use Mirage, you're mocking the requests themselves. CHARLES: Yeah. And you've got such great support for the whole factories. I love factories. It's something that is very prevalent in the Ruby community, and maybe not so much elsewhere. But the ability to very, very quickly crank out high-fidelity production data... WIL: Yeah. And you don't have to have files upon files of fixtures. CHARLES: Yeah, exactly. And you can change, if something about your schema changes, you can change the factory and now your test data is up and running. So, Ember has this tool called Mirage which is just, like I said, it's so fantastic. Oh yeah, it's also go support for running your application. Not just in your tests, but you can actually run your application with Mirage on and... WIL: Oh right, yeah. CHARLES: And you've got now the most incredible rapid prototyping tool. WIL: Yeah. You don't need to connect to a server to see fake data. CHARLES: Right, right. And we were even talking about this yesterday to a potential client. they're trying to, they've got to present something to investors. And how wonderful is it to just be like, “You know what? We just don't want to invest in all, we don't want to move the inertia, invest the money to generate the force to move the inertia of a backend.” Especially in this particular use case, the backend was going to be really, really heavy. WIL: Yeah. And there were some questions about the backend that we couldn't address quite yet but we wanted to start working on something that we could show, something demo-able. CHARLES: Right, exactly. And so, Mirage is just so wonderful for that. But again, Mirage is, it's an Ember-specific project. WIL: Right. CHARLES: So, the question was, “How are we going to use that?” WIL: And you actually took this on yourself. CHARLES: Mmhmm. WIL: I just saw this pop-up one day and boom, you converted Ember Mirage to vanilla JavaScript. [Chuckles] CHARLES: So, I did extract it. But the lion's share of the credit goes to the developers of Mirage themselves. Sam Selikoff and the Mirage community, they built Mirage not using much of Ember. There were some utilities that they were using, but mainly things like string helpers to convert between camel-case and dash-case, and using a Broccoli build, or using an Ember CLI build. WIL: Yeah. That was one of the challenges that we came across using Mirage outside of Ember, was how do we autoload this Mirage folder with all this Mirage config and Mirage factories and models, et cetera. CHARLES: Right. The internals were all just straight up JavaScript classes, for the most part. And so, extracting it, it was a lot of work. But 90% of the work was already done. It only took three or four days to do it. WIL: Amazing. CHARLES: Yeah. So, it was actually a really pleasant experience. I was able to swap out all of the Ember string helpers for Lodash. So now, it's good to go. It shares a Git history with Ember CLI Mirage, so it's basically a fork. WIL: Mmhmm. CHARLES: Like, a very heavily patched Ember CLI Mirage. But I keep it up-to-date so that it doesn't... WIL: Good. [Inaudible] CHARLES: Yeah, so I think the last time I merged in from master was about a month ago, something like that. Because it's got all the features that we need but it's not a big deal to rebase or just to merge it on over in. Because yeah, it's a really straightforward set of patches. WIL: Was there any talk with the creators of Ember Mirage about getting this upstream? CHARLES: So, I've talked a little bit with Sam about it. And from what I can tell, his feeling on it is like, “Hey, my goal right now is to focus on this being the best testing and data stubbing platform for Ember. Anything that happens out there, outside of that scope, that's great. And I certainly won't get in the way of it. But I'm pretty maxed out in terms of the open source credits that I have to spend.” WIL: [Chuckles] CHARLES: And there hasn't been much motion there. I'm happy where it is right now. I would like to see it merged into upstream. I think it would be great to have basically this Mirage Server and then have Ember CLI bindings for it. WIL: Yeah, yeah. I was going to say, either another Ember CLI specific package for Mirage or maybe to make it a non-breaking change or something. CHARLES: Yeah. WIL: Just like an Ember-specific entry point. CHARLES: Right, exactly. And I think that's definitely doable, if someone wants to take it on. I will say, we have been using this extracted plain vanilla JavaScript Mirage Server now for what, almost six months? WIL: Yeah. CHARLES: And it really hasn't... WIL: Yeah, I don't think I ran into one issue with that. CHARLES: Yeah. It's solid. It's really, really good. So, kudos to the Mirage team for doing that. And if anybody is interested in using Mirage in their projects, it's definitely there and we'll put it in the show notes. WIL: Yeah. We call it Mirage Server. CHARLES: Mirage Server, yeah. So, I don't know. Maybe it's time to reopen that conversation. But it has become a very integral and critical piece of the way that we test our JavaScript applications now. So, what are the foundations of it? We've got, we're using Mirage. We're using these convergent assertions. We're using Mocha, although that's really... WIL: Yeah, we have jQuery and Chai jQuery just to help us out with interacting with the browser as a user would. And I think one of the big challenges with that actually, I just remembered, was triggering changes in React. CHARLES: Yeah. WIL: I think this is pretty specific to React. You might run into problems with the view. I don't know how to mess with view. But in React, at least I think 15 or React 16, one of them, they changed the descriptor of the value property on an element so that they can appropriately interact with it, make changes, watch for changes, et cetera. So, when you set this value property using jQuery or just straight up ‘.value()', that change event isn't triggered in React. Your on-change handlers are never called. CHARLES: Wait, they actually update the JavaScript property descriptor of the DOM element. WIL: Yes. CHARLES: Boo. WIL: Yeah. So, there's a nice little helper out there called React Trigger Change. I dug through it and I've stripped some of it down to just be for more modern browsers, more modern React. But there's a lot of good code in there. And basically, it just caches that descriptor, updates the value, triggers the change, and then adds the descriptor back. And that ends up triggering that React element. CHARLES: Okay. [Laughs] WIL: [Chuckles] Yeah, so that calls your handlers and that's how we get around that. CHARLES: Right. There's a few fun little hacks there. But I think it is good to tie that into a larger point, is that the amount of touch that you have with the framework is actually very low. WIL: Yeah. CHARLES: So, the amount of affordances that we've had to make just for React, there's that, that you just mentioned. And is there… there's not much else. We had to write a test harness to mount the app. But that's like... WIL: Yeah, yeah. Our describe application helper is pretty React-specific. CHARLES: Right. WIL: So, you'd have to render it and set up a Mirage server, et cetera. CHARLES: Right. But that's application-specific setup. WIL: Yeah, that's one file. CHARLES: Right. WIL: So, your goal for acceptance tests is you want to be able to have a refactor and your acceptance tests still pass. CHARLES: Right. WIL: So, what if that refactor involves switching libraries? CHARLES: Right. WIL: If you're writing Ember acceptance tests, you're going to have to rewrite all your acceptance tests. CHARLES: Right. WIL: That's a huge downside. CHARLES: Right. WIL: So, with this method of interacting with the actual library very little, we have that one file that sets up our app and then we have that one trigger change helper, we remove those, we can use whatever framework we want underneath this. And our tests would still work. CHARLES: Yeah, exactly. And I think that we actually could theoretically, and honestly I have enough confidence in this style that we're developing the tests now, we could refactor this application to Ember and not have to rewrite our tests. WIL: Yeah, exactly. CHARLES: In fact, the tests would be an aide to do that. WIL: Yeah, and the tests would be faster than Ember testing with that run loop problem. CHARLES: Yeah, exactly. that's really something to think about or to think on, is like, “Wow. You're really at this point completely, not completely, but very loosely coupled to the actual internal library code.” Which is one of the goals of a nice, big acceptance test, is to be able to make major changes, break big bones, and be able to set them and have your acceptance test suite be the bulwark that holds it all together. WIL: Yeah. CHARLES: So, I actually don't know what a bulwark is. WIL: [Laughs] CHARLES: I just know that it's a really strong thing. [Laughter] CHARLES: Maybe we could put that in the show notes. [Laughter] WIL: A link to what that is. CHARLES: [Laughs] So, alright. Well, I'm trying to think if there is anything else that we wanted to mention. Any challenges? Any next things? WIL: So, one of our next steps is something we mentioned that Cypress does, is they wait for elements to exist before they interact with them. And we're actually not doing that in our app currently. And we don't have helpers out there for it yet. CHARLES: Right. WIL: But that's very much the next step. When we go to click an element in our ‘before each', we have these describes that are nested. Say, you have nested describes and you get down three levels into a ‘before each' when you're clicking a button. That button might not exist yet. CHARLES: Right. WIL: And especially since we're using jQuery, if you trigger a change on an empty jQuery element, it's not going to throw an error. It's just not going to tell you that it triggered anything. CHARLES: Right. WIL: So, we get those skips where that button's not getting clicked and we should really be waiting for that button to exist. CHARLES: Right. So, what we've done right now is we're converging on our assertions at the backend of a test. But at the frontend of a test we need to also be converging at some state before we can actually interact with the application. WIL: Right, yeah. CHARLES: So yeah, so that part is missing. And that actually brings up, we are very slowly but nevertheless doing, we're collecting these convergent assertions and convergent helpers in a repository on our GitHub account. We're going to be adding these things so that you can either use them out of the box or use them to make your own testing library. WIL: Yeah. And one of the other next steps that goes along with waiting for the element to exist is when you need to chain convergences. Like, wait for this element to exist and then click it and then wait for this thing to happen before actually running a test. And that presents the problem of our convergences are waiting for that timeout and those timeouts will accumulate. So if you have three chained convergences, that's now a six thousand millisecond timeout as opposed to a two thousand millisecond timeout. CHARLES: Right. WIL: So, one of the next steps is getting that tracking under control so if you chain three convergences together, they're smart about it and they still fail under the two thousand millisecond timeout. CHARLES: Right, right. So yeah, so we're going to be collecting all this stuff that we're learning into some publicly available code. We have a repository set up. I don't know if I want to announce it just yet, because it's really early days. WIL: Yeah. CHARLES: But that definitely is the plan. And that way, whether you're using Mocha or whether you're using QUnit or whether you're using Chai or jQuery, you've got these underlying primitives that help you converge on a state, whether that state is to interact with some piece of the DOM or to just assert some observation is made about that state. We'll be continuing on that. But by all means, get in touch if this is something that is of interest to you. Let's make something happen, because it's something that we're pretty excited about. And honestly, it's pretty comfortable living inside the four walls of this test suite. WIL: Yeah. CHARLES: It feels pretty good. WIL: It does, yeah. They're very fast. And some places in the test might need a little reworking, but for the most part all of our tests are very well-written, very well-readable. And you can just open up a test and know exactly what's going on. CHARLES: Yeah. Alright. Well, I think that about does it for Episode 90. Wow, Episode 90. WIL: Man, coming up on that 100. CHARLES: Yeah. We're going to have to have a birthday cake or something. WIL: Do we celebrate Episode 100 or Episode 104? CHARLES: What's 104? WIL: 104 would be 2 years. CHARLES: Oh really? WIL: Well, I mean 2 years' worth of podcasts. CHARLES: Oh, right. 2 years' worth of podcasts. Yeah. WIL: Yeah, like if you go every week. CHARLES: Maybe we should celebrate a hundred hours or something like that. WIL: Oh yeah. CHARLES: We can add up the thing or celebrate… I don't know, be like, “You've literally wasted 2 years of your life.” WIL: [Laughs] CHARLES: “2 weeks of your life listening to the podcast.” Anyway, so that's it for Episode 90. and thank you so much, Wil. WIL: Thanks for having me. CHARLES: It's always a pleasure to talk about these topics with you. And as always, if you need to get in touch with us, please reach out to us on Twitter. We are @TheFrontside. Or you can send an email to contact@frontside.io.

testing act dom react redux safari ui wil github jest ajax mirage javascript broccoli chai node git cypress internet explorer mocha arrange enzyme jquery nodejs assert reactjs frontside mobx lodash charles lowell sam selikoff ember cli qunit nodevember charles you

JSJ 279: ES Modules in Node Today! with John-David Dalton

Play Episode Listen Later Sep 19, 2017 56:54

Tweet this Episode John-David Dalton is probably best known for the Lodash library. He's currently working at Microsoft on the Edge team. He makes sure that libraries and frameworks work well in Edge. The JavaScript Jabber panel discusses the ECMAScript module system port to Node.js. John wanted to ship the ES module system to Node.js for Lodash to increase speed and decrease the disk space that it takes up. This approach allows you to gzip the library and get it down to 90 kb. This episode dives in detail into: ES Modules, what they are and how they work The Node.js and NPM package delivery ecosystem Module loaders in Node.js Babel (and other compilers) versus ES Module Loader and much, much more... Links: Lodash ES Module Loader for Node Node CommonJS Babel TypeScript FlowType Microsoft ESM Blog Post Meteor Reify ESM Spec PhantomJS zlib module in Node AWS Lambda NPM Webpack Rollup John-David Dalton on Twitter Picks: Cory: Trending Developer Skills The Devops Handbook Aimee: Nodevember ES Modules in Node Today (blog post) Dating is Dead Aaron: Ready Player One trailer breakdown Jim Jefferies Show I Can't Make This Up by Kevin Hart Work with Aaron at SaltStack Chuck: Angular Dev Summit ZohoCRM Working on Cars - Therapeutic working with your hands doing physical work John: TC39 Proposal for Optional Chaining ToyBox 3D Printer

work dating microsoft dead babel kevin hart ready player one meteors module node roll up modules typescript npm jim jefferies make this up aws lambda webpack ecmascript saltstack javascript jabber commonjs lodash phantomjs reify nodevember angular dev summit john david dalton

JSJ 279: ES Modules in Node Today! with John-David Dalton

Play Episode Listen Later Sep 19, 2017 56:54

Tweet this Episode John-David Dalton is probably best known for the Lodash library. He's currently working at Microsoft on the Edge team. He makes sure that libraries and frameworks work well in Edge. The JavaScript Jabber panel discusses the ECMAScript module system port to Node.js. John wanted to ship the ES module system to Node.js for Lodash to increase speed and decrease the disk space that it takes up. This approach allows you to gzip the library and get it down to 90 kb. This episode dives in detail into: ES Modules, what they are and how they work The Node.js and NPM package delivery ecosystem Module loaders in Node.js Babel (and other compilers) versus ES Module Loader and much, much more... Links: Lodash ES Module Loader for Node Node CommonJS Babel TypeScript FlowType Microsoft ESM Blog Post Meteor Reify ESM Spec PhantomJS zlib module in Node AWS Lambda NPM Webpack Rollup John-David Dalton on Twitter Picks: Cory: Trending Developer Skills The Devops Handbook Aimee: Nodevember ES Modules in Node Today (blog post) Dating is Dead Aaron: Ready Player One trailer breakdown Jim Jefferies Show I Can't Make This Up by Kevin Hart Work with Aaron at SaltStack Chuck: Angular Dev Summit ZohoCRM Working on Cars - Therapeutic working with your hands doing physical work John: TC39 Proposal for Optional Chaining ToyBox 3D Printer

work dating microsoft dead babel kevin hart ready player one meteors module node roll up modules typescript npm jim jefferies make this up aws lambda webpack ecmascript saltstack javascript jabber commonjs lodash phantomjs reify nodevember angular dev summit john david dalton

JSJ 279: ES Modules in Node Today! with John-David Dalton

Play Episode Listen Later Sep 19, 2017 56:54

Tweet this Episode John-David Dalton is probably best known for the Lodash library. He's currently working at Microsoft on the Edge team. He makes sure that libraries and frameworks work well in Edge. The JavaScript Jabber panel discusses the ECMAScript module system port to Node.js. John wanted to ship the ES module system to Node.js for Lodash to increase speed and decrease the disk space that it takes up. This approach allows you to gzip the library and get it down to 90 kb. This episode dives in detail into: ES Modules, what they are and how they work The Node.js and NPM package delivery ecosystem Module loaders in Node.js Babel (and other compilers) versus ES Module Loader and much, much more... Links: Lodash ES Module Loader for Node Node CommonJS Babel TypeScript FlowType Microsoft ESM Blog Post Meteor Reify ESM Spec PhantomJS zlib module in Node AWS Lambda NPM Webpack Rollup John-David Dalton on Twitter Picks: Cory: Trending Developer Skills The Devops Handbook Aimee: Nodevember ES Modules in Node Today (blog post) Dating is Dead Aaron: Ready Player One trailer breakdown Jim Jefferies Show I Can't Make This Up by Kevin Hart Work with Aaron at SaltStack Chuck: Angular Dev Summit ZohoCRM Working on Cars - Therapeutic working with your hands doing physical work John: TC39 Proposal for Optional Chaining ToyBox 3D Printer

work dating microsoft dead babel kevin hart ready player one meteors module node roll up modules typescript npm jim jefferies make this up aws lambda webpack ecmascript saltstack javascript jabber commonjs lodash phantomjs reify nodevember angular dev summit john david dalton

MJS #034 John-David Dalton

Play Episode Listen Later Sep 13, 2017 48:30

Tweet this Episode MJS 034: John-David Dalton Today’s episode is a My JavaScript Story with John-David Dalton. JD talked about his contributions to the JavaScript community like Lo-Dash, Sandboxed Native, etc. Listen to learn more about JD! [01:15] – Introduction to JD JD has been on JavaScript Jabber. He talked about Lo-Dash. [02:00] – How did you get into programming? First website This was when JD was a junior in high school. Then, he got involved with a flight squadron for a World War 1 online game. They needed a website so he created a GeoCities website for them. That’s what got him into JavaScript. He’d have to enhance the page with mouseover effects - cursor trail, etc. JavaScript From there, JD started created a Dr. Wiley little-animated bot that would say random things in a little speech bubble with the HTML on your page like a widget. He also passed an assignment turning a web page into an English class paper. He used to spend his lunch breaks learning JavaScript and programming. He also created a little Mario game engine – Mario 1 with movable blocks that you could click and drag and Mario could jump over it. That was back with the document.layers and Netscape Navigator. Animation JD wanted to be an animator in animation so he started getting into macro media flash. That led him to ActionScript, which was another ECMAScript-based language. He took a break from JavaScript and did ActionScript and flash animations for a while as his day job too. PHP and JavaScript JD started learning PHP and they needed to create a web app that got him right back into JavaScript in 2005. That was when AJAX was coined and that’s when Prototype JS came up. He was reading AJAX blog posts back then because that was the place to find all of your JavaScript news. JS Specification JD remembers being really intimidated by JavaScript libraries so he started reading the JavaScript specification. It got him into a deeper understanding of why the language does what it does and realized that there’s actually a document that he could go to and look up exactly why things do what they do. [06:45] – What was it about JavaScript? JD has been tinkering with programming languages but what he liked about ActionScript at the time was it is so powerful. You could create games with it or you could script during animations. He eventually created a tool that was a Game Genie for flash games that you could get these decompilers that would show you the variables in the game, and then, you could use JavaScript to manipulate the variables in the flash game. He created a tool that could, for example, change your lives to infinite life, grow your character or access hidden characters that they don’t actually put in the game but they have the animations for it. JD was led to a page on the web archive called Layer 51 or Proto 51. That was a web page that had a lot of JavaScript or ActionScript snippets. There were things for extending the built-in prototypes - adding array methods or string methods or regex methods. That was how JavaScript became appealing to him. He has been doing JavaScript for almost 20 years. PHP also made him appreciate JavaScript more because, at the time, you couldn’t have that interface. [09:30] – Lo-Dash, Sandboxed Native, Microsoft Lo-Dash Eventually, JD grew to respect jQuery because I became a library author. jQuery is the example of how to create a successful library. It’s almost on 90% of the Internet. He likes that right now but before, he was a hardcore Prototype fanboy. He didn’t like new tools either. He liked augmenting prototypes but over time, he realized that augmenting prototypes wasn’t so great whenever you wanted to include other code on your page because it would have conflict and collisions. Later on, he took Prototype, forked it, and he made it faster and support more things, which is essentially what he did with Lo-Dash. Sandboxed Native JD created something called Sandboxed Native, which got him into talking on conferences. Sandboxed Native extends the prototypes for the built-ins for your current frame. It would import new built-ins so you got a new array constructor, a new date constructor, a new regex, or a new string. It wouldn’t collide or step on the built-ins of the current page. Microsoft After that, JD ended up transitioning to performance and benchmarking. That landed him his Microsoft job a couple years later. Picks John-David Dalton JS Foundation Sonarwhal Twitter / Github: @jdalton Charles Max Wood Aaron Walker Interview Valet

english internet microsoft jd animation world war wiley ajax layer javascript html prototype php proto aaron walker jquery interview valet geocities game genie ecmascript mjs netscape navigator actionscript charles max wood javascript jabber lodash js foundation my javascript story john david dalton

MJS #034 John-David Dalton

My JavaScript Story

Play Episode Listen Later Sep 13, 2017 48:30

Tweet this Episode MJS 034: John-David Dalton Today’s episode is a My JavaScript Story with John-David Dalton. JD talked about his contributions to the JavaScript community like Lo-Dash, Sandboxed Native, etc. Listen to learn more about JD! [01:15] – Introduction to JD JD has been on JavaScript Jabber. He talked about Lo-Dash. [02:00] – How did you get into programming? First website This was when JD was a junior in high school. Then, he got involved with a flight squadron for a World War 1 online game. They needed a website so he created a GeoCities website for them. That’s what got him into JavaScript. He’d have to enhance the page with mouseover effects - cursor trail, etc. JavaScript From there, JD started created a Dr. Wiley little-animated bot that would say random things in a little speech bubble with the HTML on your page like a widget. He also passed an assignment turning a web page into an English class paper. He used to spend his lunch breaks learning JavaScript and programming. He also created a little Mario game engine – Mario 1 with movable blocks that you could click and drag and Mario could jump over it. That was back with the document.layers and Netscape Navigator. Animation JD wanted to be an animator in animation so he started getting into macro media flash. That led him to ActionScript, which was another ECMAScript-based language. He took a break from JavaScript and did ActionScript and flash animations for a while as his day job too. PHP and JavaScript JD started learning PHP and they needed to create a web app that got him right back into JavaScript in 2005. That was when AJAX was coined and that’s when Prototype JS came up. He was reading AJAX blog posts back then because that was the place to find all of your JavaScript news. JS Specification JD remembers being really intimidated by JavaScript libraries so he started reading the JavaScript specification. It got him into a deeper understanding of why the language does what it does and realized that there’s actually a document that he could go to and look up exactly why things do what they do. [06:45] – What was it about JavaScript? JD has been tinkering with programming languages but what he liked about ActionScript at the time was it is so powerful. You could create games with it or you could script during animations. He eventually created a tool that was a Game Genie for flash games that you could get these decompilers that would show you the variables in the game, and then, you could use JavaScript to manipulate the variables in the flash game. He created a tool that could, for example, change your lives to infinite life, grow your character or access hidden characters that they don’t actually put in the game but they have the animations for it. JD was led to a page on the web archive called Layer 51 or Proto 51. That was a web page that had a lot of JavaScript or ActionScript snippets. There were things for extending the built-in prototypes - adding array methods or string methods or regex methods. That was how JavaScript became appealing to him. He has been doing JavaScript for almost 20 years. PHP also made him appreciate JavaScript more because, at the time, you couldn’t have that interface. [09:30] – Lo-Dash, Sandboxed Native, Microsoft Lo-Dash Eventually, JD grew to respect jQuery because I became a library author. jQuery is the example of how to create a successful library. It’s almost on 90% of the Internet. He likes that right now but before, he was a hardcore Prototype fanboy. He didn’t like new tools either. He liked augmenting prototypes but over time, he realized that augmenting prototypes wasn’t so great whenever you wanted to include other code on your page because it would have conflict and collisions. Later on, he took Prototype, forked it, and he made it faster and support more things, which is essentially what he did with Lo-Dash. Sandboxed Native JD created something called Sandboxed Native, which got him into talking on conferences. Sandboxed Native extends the prototypes for the built-ins for your current frame. It would import new built-ins so you got a new array constructor, a new date constructor, a new regex, or a new string. It wouldn’t collide or step on the built-ins of the current page. Microsoft After that, JD ended up transitioning to performance and benchmarking. That landed him his Microsoft job a couple years later. Picks John-David Dalton JS Foundation Sonarwhal Twitter / Github: @jdalton Charles Max Wood Aaron Walker Interview Valet

english internet microsoft jd animation world war wiley ajax layer javascript html prototype php proto aaron walker jquery interview valet geocities game genie ecmascript mjs netscape navigator actionscript charles max wood javascript jabber lodash js foundation my javascript story john david dalton

MJS #034 John-David Dalton

Working Draft » Podcast Feed

Play Episode Listen Later Sep 13, 2017 48:30

Tweet this Episode MJS 034: John-David Dalton Today’s episode is a My JavaScript Story with John-David Dalton. JD talked about his contributions to the JavaScript community like Lo-Dash, Sandboxed Native, etc. Listen to learn more about JD! [01:15] – Introduction to JD JD has been on JavaScript Jabber. He talked about Lo-Dash. [02:00] – How did you get into programming? First website This was when JD was a junior in high school. Then, he got involved with a flight squadron for a World War 1 online game. They needed a website so he created a GeoCities website for them. That’s what got him into JavaScript. He’d have to enhance the page with mouseover effects - cursor trail, etc. JavaScript From there, JD started created a Dr. Wiley little-animated bot that would say random things in a little speech bubble with the HTML on your page like a widget. He also passed an assignment turning a web page into an English class paper. He used to spend his lunch breaks learning JavaScript and programming. He also created a little Mario game engine – Mario 1 with movable blocks that you could click and drag and Mario could jump over it. That was back with the document.layers and Netscape Navigator. Animation JD wanted to be an animator in animation so he started getting into macro media flash. That led him to ActionScript, which was another ECMAScript-based language. He took a break from JavaScript and did ActionScript and flash animations for a while as his day job too. PHP and JavaScript JD started learning PHP and they needed to create a web app that got him right back into JavaScript in 2005. That was when AJAX was coined and that’s when Prototype JS came up. He was reading AJAX blog posts back then because that was the place to find all of your JavaScript news. JS Specification JD remembers being really intimidated by JavaScript libraries so he started reading the JavaScript specification. It got him into a deeper understanding of why the language does what it does and realized that there’s actually a document that he could go to and look up exactly why things do what they do. [06:45] – What was it about JavaScript? JD has been tinkering with programming languages but what he liked about ActionScript at the time was it is so powerful. You could create games with it or you could script during animations. He eventually created a tool that was a Game Genie for flash games that you could get these decompilers that would show you the variables in the game, and then, you could use JavaScript to manipulate the variables in the flash game. He created a tool that could, for example, change your lives to infinite life, grow your character or access hidden characters that they don’t actually put in the game but they have the animations for it. JD was led to a page on the web archive called Layer 51 or Proto 51. That was a web page that had a lot of JavaScript or ActionScript snippets. There were things for extending the built-in prototypes - adding array methods or string methods or regex methods. That was how JavaScript became appealing to him. He has been doing JavaScript for almost 20 years. PHP also made him appreciate JavaScript more because, at the time, you couldn’t have that interface. [09:30] – Lo-Dash, Sandboxed Native, Microsoft Lo-Dash Eventually, JD grew to respect jQuery because I became a library author. jQuery is the example of how to create a successful library. It’s almost on 90% of the Internet. He likes that right now but before, he was a hardcore Prototype fanboy. He didn’t like new tools either. He liked augmenting prototypes but over time, he realized that augmenting prototypes wasn’t so great whenever you wanted to include other code on your page because it would have conflict and collisions. Later on, he took Prototype, forked it, and he made it faster and support more things, which is essentially what he did with Lo-Dash. Sandboxed Native JD created something called Sandboxed Native, which got him into talking on conferences. Sandboxed Native extends the prototypes for the built-ins for your current frame. It would import new built-ins so you got a new array constructor, a new date constructor, a new regex, or a new string. It wouldn’t collide or step on the built-ins of the current page. Microsoft After that, JD ended up transitioning to performance and benchmarking. That landed him his Microsoft job a couple years later. Picks John-David Dalton JS Foundation Sonarwhal Twitter / Github: @jdalton Charles Max Wood Aaron Walker Interview Valet

english internet microsoft jd animation world war wiley ajax layer javascript html prototype php proto aaron walker jquery interview valet geocities game genie ecmascript mjs netscape navigator actionscript charles max wood javascript jabber lodash js foundation my javascript story john david dalton

Revision 309: Kein Thema

Play Episode Listen Later Sep 2, 2017 62:48

Themen? Wer braucht denn schon Themen! Schaunotizen [00:00:20] Kein Thema Stefan, Schepp und (vor allem) Peter geben sich der freien Webtech-Assoziation hin und fordern allerlei. Unter anderem wünschen wir uns Ersatz für allerlei etablierte Tools, DOM-Diffing jenseits des Main-Threads und vieles andere. Zur Sprache kommen außerdem die ausgetüftelten Performance-Optimierungen von Lo-Dash

tools unter revision ersatz kein thema zur sprache themen wer lodash

JSJ 272: Functional Programming and ClojureScript with Eric Normand

Play Episode Listen Later Aug 1, 2017 48:24

JSJ 272: Functional Programming and ClojureScript with Eric Normand This episode of JavaScript Jabber features panelists Aimee Knight and Charles Max Wood. Special guest Eric Normand is here to talk about functional programming and ClojureScript. Tune in to learn more! [00:1:14] Introduction to Eric Normand Eric works for purelyfunctional.tv. The main target market for his company is those people who want to transition into functional programming from their current job. He offers them support, shows them where to find jobs, and gives them the skills they need to do well. [00:02:22] Address that quickly Functional programming is used at big companies such as Wal-Mart, Amazon, EBay, Paypal, and banks. They all have Clojure but it is not used at the scale of Java or Ruby. So yes, people are using it and it is influencing the mainstream programming industry. [00:3:48] How do you build an application? A common question Eric gets is, “How do I structure my application?” People are used to using frameworks. Most start from an existing app. People want a process to figure out how to take a set of features and turn it into code. Most that get into functional programming have development experience. The attitude in functional programming is that they do not want a framework. Clojure needs to be more beginner friendly. His talk is a four-step process on how to turn into code. [00:05:56] Can you expand on that a little? There are four steps to the process of structuring an application. Develop a metaphor for what you are trying to do. Developing the first implementation. How would you build it if you didn’t have code? Develop the operations. What are their properties? Example: will have to sort records chronological. Develop relationships between the operations. Run tests and refactor the program. Once you have that, you can write the prototype. [00:13:13] Why can’t you always make the code better? Rules can’t be refactored into new concepts. They have to be thrown away and started completely over. The most important step is to think before beginning to write code. It may be the hardest part of the process, but it will make the implementation easier. [00:17:20] What are your thoughts on when people take it too far and it makes the code harder to read? He personally has written many bad abstractions. Writing bad things is how you get better as a programmer. The ones that go too far are the ones that don’t have any basis or are making something new up. They are trying to be too big and use no math to back up their code. [00:20:05] Is the hammock time when you decide if you want to make something abstract or should you wait until you see patterns develop? He thinks people should think about it before, although always be making experiments that do not touch production. [00:23:33] Is there a trade off between using ClojureScript and functional JavaScript? In terms of functional programming in JavaScript don’t have some of the niceties that there are in Clojure script. Clojure Script has a large standard library. JavaScript is not as well polished for functional programming; it is a lot of work to do functional programming it and not as much support. [00:27:00:] Dave Thomas believes that the future of software is functional programming. Do you agree? Eric thinks that it seems optimistic. He doesn’t see functional programming take over the world but does think that it has a lot to teach. The main reason to learn functional programming is to have more tools in your toolbox. [00:31:40] If this is a better way to solve these problems, why aren’t people using it? There is a prejudice against functional programming. When Eric was first getting into it, people would ask why he was wasting his time. Believes that people are jaded. Functional programming feels foreign because people are used to a familiar way of programming; they usually start with a language and get comfortable. [00:40:58] If people want to get started with it, is there an easy way in? Lodash is great to start replacing for loops. It will clean up code. There are other languages that compile to JavaScript. For example, Elm is getting a lot of attention right now. It is a Haskell like syntax. If you want more of a heavyweight language, use TypeScript or PureScript. ClojureScript is into live programming. You are able to type, save, and see results of the code immediately on the screen in front of you. Picks Aimee: The Hidden Cost of Abstraction What Functional Language Should I Learn Eric Steven King, On Writing Youtube Channel: Tested Charles Ionic Framework Links Purely Functional TV Blog Building Composable Abstractions

JSJ 272: Functional Programming and ClojureScript with Eric Normand

Play Episode Listen Later Aug 1, 2017 48:24

JSJ 272: Functional Programming and ClojureScript with Eric Normand This episode of JavaScript Jabber features panelists Aimee Knight and Charles Max Wood. Special guest Eric Normand is here to talk about functional programming and ClojureScript. Tune in to learn more! [00:1:14] Introduction to Eric Normand Eric works for purelyfunctional.tv. The main target market for his company is those people who want to transition into functional programming from their current job. He offers them support, shows them where to find jobs, and gives them the skills they need to do well. [00:02:22] Address that quickly Functional programming is used at big companies such as Wal-Mart, Amazon, EBay, Paypal, and banks. They all have Clojure but it is not used at the scale of Java or Ruby. So yes, people are using it and it is influencing the mainstream programming industry. [00:3:48] How do you build an application? A common question Eric gets is, “How do I structure my application?” People are used to using frameworks. Most start from an existing app. People want a process to figure out how to take a set of features and turn it into code. Most that get into functional programming have development experience. The attitude in functional programming is that they do not want a framework. Clojure needs to be more beginner friendly. His talk is a four-step process on how to turn into code. [00:05:56] Can you expand on that a little? There are four steps to the process of structuring an application. Develop a metaphor for what you are trying to do. Developing the first implementation. How would you build it if you didn’t have code? Develop the operations. What are their properties? Example: will have to sort records chronological. Develop relationships between the operations. Run tests and refactor the program. Once you have that, you can write the prototype. [00:13:13] Why can’t you always make the code better? Rules can’t be refactored into new concepts. They have to be thrown away and started completely over. The most important step is to think before beginning to write code. It may be the hardest part of the process, but it will make the implementation easier. [00:17:20] What are your thoughts on when people take it too far and it makes the code harder to read? He personally has written many bad abstractions. Writing bad things is how you get better as a programmer. The ones that go too far are the ones that don’t have any basis or are making something new up. They are trying to be too big and use no math to back up their code. [00:20:05] Is the hammock time when you decide if you want to make something abstract or should you wait until you see patterns develop? He thinks people should think about it before, although always be making experiments that do not touch production. [00:23:33] Is there a trade off between using ClojureScript and functional JavaScript? In terms of functional programming in JavaScript don’t have some of the niceties that there are in Clojure script. Clojure Script has a large standard library. JavaScript is not as well polished for functional programming; it is a lot of work to do functional programming it and not as much support. [00:27:00:] Dave Thomas believes that the future of software is functional programming. Do you agree? Eric thinks that it seems optimistic. He doesn’t see functional programming take over the world but does think that it has a lot to teach. The main reason to learn functional programming is to have more tools in your toolbox. [00:31:40] If this is a better way to solve these problems, why aren’t people using it? There is a prejudice against functional programming. When Eric was first getting into it, people would ask why he was wasting his time. Believes that people are jaded. Functional programming feels foreign because people are used to a familiar way of programming; they usually start with a language and get comfortable. [00:40:58] If people want to get started with it, is there an easy way in? Lodash is great to start replacing for loops. It will clean up code. There are other languages that compile to JavaScript. For example, Elm is getting a lot of attention right now. It is a Haskell like syntax. If you want more of a heavyweight language, use TypeScript or PureScript. ClojureScript is into live programming. You are able to type, save, and see results of the code immediately on the screen in front of you. Picks Aimee: The Hidden Cost of Abstraction What Functional Language Should I Learn Eric Steven King, On Writing Youtube Channel: Tested Charles Ionic Framework Links Purely Functional TV Blog Building Composable Abstractions

JSJ 272: Functional Programming and ClojureScript with Eric Normand

RWpod - подкаст про мир Ruby и Web технологии

Play Episode Listen Later Aug 1, 2017 48:24

JSJ 272: Functional Programming and ClojureScript with Eric Normand This episode of JavaScript Jabber features panelists Aimee Knight and Charles Max Wood. Special guest Eric Normand is here to talk about functional programming and ClojureScript. Tune in to learn more! [00:1:14] Introduction to Eric Normand Eric works for purelyfunctional.tv. The main target market for his company is those people who want to transition into functional programming from their current job. He offers them support, shows them where to find jobs, and gives them the skills they need to do well. [00:02:22] Address that quickly Functional programming is used at big companies such as Wal-Mart, Amazon, EBay, Paypal, and banks. They all have Clojure but it is not used at the scale of Java or Ruby. So yes, people are using it and it is influencing the mainstream programming industry. [00:3:48] How do you build an application? A common question Eric gets is, “How do I structure my application?” People are used to using frameworks. Most start from an existing app. People want a process to figure out how to take a set of features and turn it into code. Most that get into functional programming have development experience. The attitude in functional programming is that they do not want a framework. Clojure needs to be more beginner friendly. His talk is a four-step process on how to turn into code. [00:05:56] Can you expand on that a little? There are four steps to the process of structuring an application. Develop a metaphor for what you are trying to do. Developing the first implementation. How would you build it if you didn’t have code? Develop the operations. What are their properties? Example: will have to sort records chronological. Develop relationships between the operations. Run tests and refactor the program. Once you have that, you can write the prototype. [00:13:13] Why can’t you always make the code better? Rules can’t be refactored into new concepts. They have to be thrown away and started completely over. The most important step is to think before beginning to write code. It may be the hardest part of the process, but it will make the implementation easier. [00:17:20] What are your thoughts on when people take it too far and it makes the code harder to read? He personally has written many bad abstractions. Writing bad things is how you get better as a programmer. The ones that go too far are the ones that don’t have any basis or are making something new up. They are trying to be too big and use no math to back up their code. [00:20:05] Is the hammock time when you decide if you want to make something abstract or should you wait until you see patterns develop? He thinks people should think about it before, although always be making experiments that do not touch production. [00:23:33] Is there a trade off between using ClojureScript and functional JavaScript? In terms of functional programming in JavaScript don’t have some of the niceties that there are in Clojure script. Clojure Script has a large standard library. JavaScript is not as well polished for functional programming; it is a lot of work to do functional programming it and not as much support. [00:27:00:] Dave Thomas believes that the future of software is functional programming. Do you agree? Eric thinks that it seems optimistic. He doesn’t see functional programming take over the world but does think that it has a lot to teach. The main reason to learn functional programming is to have more tools in your toolbox. [00:31:40] If this is a better way to solve these problems, why aren’t people using it? There is a prejudice against functional programming. When Eric was first getting into it, people would ask why he was wasting his time. Believes that people are jaded. Functional programming feels foreign because people are used to a familiar way of programming; they usually start with a language and get comfortable. [00:40:58] If people want to get started with it, is there an easy way in? Lodash is great to start replacing for loops. It will clean up code. There are other languages that compile to JavaScript. For example, Elm is getting a lot of attention right now. It is a Haskell like syntax. If you want more of a heavyweight language, use TypeScript or PureScript. ClojureScript is into live programming. You are able to type, save, and see results of the code immediately on the screen in front of you. Picks Aimee: The Hidden Cost of Abstraction What Functional Language Should I Learn Eric Steven King, On Writing Youtube Channel: Tested Charles Ionic Framework Links Purely Functional TV Blog Building Composable Abstractions

24 выпуск 05 сезона. MJIT, Atom 1.18, From Rails to Hanami, Full Stack Automation with Ruby, Spected и прочее

Play Episode Listen Later Jun 18, 2017 35:27

Добрый день уважаемые слушатели. Представляем новый выпуск подкаста RWpod. В этом выпуске: Ruby Ruby 2.4 added Hash#transform_values and its destructive version from Active Support, Ruby 2.4 allows to customize suffix of the rotated log files, Ruby 2.4 has deprecated toplevel constants TRUE, FALSE and NIL и MJIT - ~3x faster Ruby via JIT and a richer intermediate representation (IR) From Rails to Hanami: Views, Rails to Hanami и Common Table Expressions in ActiveRecord: A Case Study of Quantiles Full Stack Automation with Ruby, GoF design patterns in Ruby, Laser - another Search Engine for Ruby и Demystifying Rails (book) JavaScript Atom 1.18, Angular 1.0 Turns Five Years Old и An Introduction to the ‘fr' CSS unit How to track changes in the DOM using Mutation Observer, Five ES6 features to make your life easier и Lodash is not (only) for list manipulation Grab Front End Guide, Spellbook of Modern Web Dev, Spected - a low level validation library for validating objects against defined validation rules и Highlight Within Textarea Conferences Elixir Club 7

false automation dom laser atom rails search engines css hash angular fullstack jit hanami gof spellbook ruby ruby lodash

055: Redux and Ember with Toran Billups

tooling optimizations lodash

Play Episode Listen Later Jan 26, 2017 56:03

Toran Billups @toranb | GitHub | Blog Show Notes: 02:23 - Ember 2.0; Data Down, Actions Up 08:28 - redux and State 16:39 - Dispatching Actions/Patterns 24:00 - Components and Routing 31:00 - ember-redux and Cloning the react-redux API 35:22 - Hot Reloading 41:22 - Audience 47:02 - Motivation 50:25 - Building Component Trees Resources: Toran Billups: Test-Driven Development By Example @ EmberConf 2015 Dan Abramov: Live React: Hot Reloading with Time Travel @ react-europe 2015 react-redux Charles Lowell: Immutability is for UI, You and I @ EmberConf 2016 redux-thunk Ryan Toronto: Safety of the herd EmberMap: Component side effects Functional Programming Browserify More Toran Billups Talks Transcript: CHARLES: Hello everybody. Welcome to The Frontside Podcast. This is Episode 55. We're broadcasting and everybody's here in Austin, although we're still remote. I am here with a really special panel today. There's me, which makes it special by default. My name is Charles Lowell. I'm a developer here at The Frontside. I'm also here with Robert De Luca, who also develops JavaScript codes at The Frontside and we have today [drum roll sound] -- I'm really, really going to work that drumroll -- Toran Billups. What's up, man? TORAN: Hey, man. Thanks for having me. I'm really excited to be here. CHARLES: Toran is with us today and he's going to be talking about a lot of things. He's going to be talking about today mostly about Redux and his efforts to meld Redux and make it useful within the Ember community. But first, if you have not heard of Toran, I think the first time we'd interacted over email, Slack briefly but then when I really, really saw you for the first time was at EmberConf, I think in 2015 and he just gave the most amazing talk on Test Driven Development and really kind of the focus on you can set up your acceptance tests from the outside into really define that behavior and set out that firm shell and then actually build your application from the outside in. You've really kind of been talking about that message. We like to have people on here who all about walking the walk. That's certainly the first thing that I've noticed that you were doing in the community but then more recently, you've been playing with Redux. Not playing with Redux, actually making a concerted effort to bring this kind of pattern into Ember. I just wanted to start out, how did you jump onto that track? TORAN: Some months after EmberConf in 2015, as you mentioned that talk was not only, probably the most well-rehearsed talk I've ever given but definitely the most well-received. I got a lot of people excited and really gave me a lot of opportunities that weren't there before that was also believe in that keynote in 2015 as when Ember 2.0 was announced. The interesting part of Ember 2.0, of course was we were using it, and it was called Ember 1.13, which actually made it really great. At the time, I was very much excited about the stability that offered. Other folks were not as much as interested in that idea or those values, in the JavaScript community so it's really exciting. Yet at the same time, there was this new mantra that was being talked about more that I knew nothing about. It was this 'data down, actions up' idea. I still remember as much as the stability was awesome, I also started to doubt not Ember core in particular but the ideas that were being espoused by other folks around the Ember core team because I didn't really understand the value. For instance, if I had the tree of components back then in early Ember 1.13 or 2.0 days and I had an Ember model or some kind of Ember object at the bottom of this tree, why would I not just do Ember.set. I remember, actually you may recall conversations you had with people at EmberConf around that time but there was actually varying definitions of what 'data down, actions up' meant to different people and actually never met the same thing to anyone. It was funny enough. Because of that, it sort of drove this fear in me that I didn't know what I was talking about. I was consulting at the time so I wanted to sound like I knew what I was talking about as you probably should. You guys are in that business so you know what I mean. Because of that doubt, eventually I sort of become apathetic to really trying to understand better what 'data down, actions up' meant or how components should be constructed and really what the wider impacts of Ember 2.0 meant. Because of that, I just found myself, not really loving learning. I felt like everything else in learning was a hyped up thing that would never happen or a hyped up thing that I didn't really understand or didn't make sense in the context of Ember at that time so I just kind of floated by. Everybody has their ebb and flows in the journey of excitement or not. For me, this was just the down moment. One of the things, like an analogy to this is when you lose your hunger in real life, you'd be very much like losing your hunger for learning. There's this interesting hormone that your body produces when you're actually physically hungry that kind of gives you the physical symptoms like your stomach cramps that tells your brain probably should eat somewhere. When those things aren't happening or that hormones not being produced, it's often because you've quit eating yourself. If you've ever gone on a fast or something weird like that on day three, your body quits secreting this hormone so you just sort of or not hungry at all, which is kind of weird. The same sort of thing was happening to me. If you ask a doctor or a physician, "What's the first thing I should do? I'm not hungry anymore." They'll tell you, "You just start eating." But I'm not hungry now so the same thing applied in my life and I think the first step really is just eat anyway. In this case, it was just learn something anyway even if you're not in love with learning right now. Eventually, your body will start producing this hormone, in the hunger example and for me, I just sort of got back in the flow and what came from this was a routine, which is really the second part of how you get your hunger back, not just eating once a day. I was eating three meals a day or more, especially if you haven't been eating. For me, I just set aside an hour a day, in addition to consulting work and things that would get me interested in loving learning again. The third component to this was trying something different. At the time, of course I was just doing Ember, I pretty much had done Ember since 2012 like some of you guys and I feel like there wasn't a lot of new. There was patterns and ideas but there was anything really challenging me. That's when I sort of looked around at the React community and I had done some React in the early days when I was super hyped up but I still feel vaguely different. Not that it's jQuery or any way but I didn't feel like this fully encompass single page out framework. The reasons I got into Ember very early on were that I wanted to build rich single page apps. If you guys remember from the early React days, that also wasn't really the messaging with React and maybe today with View. In fact, that's kind of one of the benefits or they speak to in those communities about why you use React because you don't have to use it for your whole app. You could kind of piecemeal it in, which totally cool. You got to see it out with Ember too. But in my mind, I just wanted to build a rich JavaScript lines that could compete with the iPhone or the iPhone apps that were popular in that day. Through this process, I started looking at React and really just kind of get back into it again, get going again. I wasn't really in love with it but I needed to try something outside of the realm I was used to. As part of that, I noticed there was this talk by Dan Abramov, I think he works for Facebook now, big in the React community, of course and he gave this talk at a conference in Europe that introduced Redux. What's funny, if you find out or dive deeper into that story is he actually pitched the talk, not really having built any of this and just thought, "This sounds like a great idea," and then of course the talk was accepted. Like most, he delivered on that promise and made a great talk. There are definitely courage folks to check out and I should link it to you here. We can show noted that, I'm sure. That talk make me excited mostly because there was a lot of whiz-bang. If you guys remember any great talk you've ever seen, the talk even that I gave at EmberConf that you mentioned, Charles the thing that blew people away was this very end moment that, of course I had produced to be a great moment. In the same way, Dan during this talk introduced some new ideas or new to the JavaScript community. One of those was the tooling that can change when the state doesn't change in your application. That got me sort of piqued my interest, in part because I was actually big test driven guy and I thought, "I won't use any of this stuff. It just seems cool. It's a gimmick. Tester development is how you really build app." If anything I thought to disprove it by getting involved and learning a little bit more but what I instantly found was the simplicity of data changes rerender. That sounds very high level, of course but it was almost just that simple, instead of being like how does this change to an object in my array, bubble out through notifications on the Ember side and notify the Ember change detection to rerender. Well, I'm not entirely sure so when I was start debugging that, I noticed a lot of framework code between me and the rerender. It's that's how Ember is, right? When I boiled that down in jQuery with vanilla Redux, not even using React at all, I was like, "Wow, there's just a call back. I wonder why I haven't been doing this." CHARLES: As a single callback for a global state? TORAN: Correct. CHARLES: So there's no call back for every single path in your tree. You just used that one call back? TORAN: I'll fill in for Rob here. I know he's jumping at it. You should probably define a Redux is. He's really good at asking that question. Redux in this case, for me is just a global JavaScript object to use to hydrate your templates. They'll give you some big spiel about state container, if you go check out the website. But for me and in this context of being on an Ember-centric sort of podcast, we already use this idea in Ember today. If you're just feeding your templates from some high level service, it's a very similar idea in that Redux is just a single service. In the Ember case, especially you can talk about the add-on, I maintain later, but really it's just a service with a single object that will help you populate all of your components. ROBERT: Yeah, I love Redux. I actually sort of coming into the Redux world, probably to about six to eight months ago and it was around the same thing like exploring React stuff. I share similar opinions to you as nobody really can define 'data down, actions up'. I also think that 'data down, actions up' cannot just live in the component. In a lot of the Ember apps I worked on, there's times where I'll be looking up to get a new state and it comes in from the side and something's mutating, something that I have no idea why and where it was mutated and Redux does a really good job at helping you manage what changes and why it changed. CHARLES: I have a question too. When you're actually using Redux, you said you got a single tree that you used to hydrate your templates. In the context of Ember, where do you maintain that single object? I assume you have one store, one instance of your Redux state per application? TORAN: Correct. There's just a service like you imagine in the Ember data service and that holds on to really just an identity map or a single graph object that will let you pass or pull that in by injecting the service into your components if you want to do that or your route then just asking for that state. CHARLES: Because I think that for a lot of people in the Ember community certainly, when I was kind of grappling with these ideas, the idea of having a single global object as your state seems so counterintuitive, so going to go against everything that we learned, that you have to decompose a problem into its component parts. Obviously, Redux has an answer for that so how does that work? How do you decompose that state into saying, "I'm just interested in this kind of local state." How does local state work in Redux? TORAN: I should define local state is state specific to the component. It doesn't need to bleed up and has no value at the global level. CHARLES: Usually, I got two components. Let's say, I want to store both of their states in the Redux store. Obviously, component one is not interested in seeing any state that's not related to it so it's only interested in its own state and it's not interested in any of the surrounding context. How does that work? How do you connect a single component or connect a route to the store? TORAN: There's really just a simple method on Redux -- the Redux store itself, which it says, "Give me the state." What may not sound great at first is that it say, "I will give you all the state and that is your job to pull from that or map three attributes from that whole tree into my component." Then by side effect if you're using our add-on or if you don't React-Redux, you actually subscribe then to call backs on any of those changes so if something were to be bumped, then your component is given the opportunity to rerender during that call back. CHARLES: Now, in terms of Ember-Redux, that kind plumbing is hidden from you. You don't actually have to explicitly map that state. You can say, "I want to connect this component into the Redux store," and you're just off to the races. ROBERT: Is there a mapStateToProps or... I don't know what that would be called in Ember-land. TORAN: That brings about interesting point. I literally copied this API that you guys are probably looked at from the readme from this very popular project in React called React-Redux. The word that you're using, Charles is this word connect. Actually, I like that word because that's how I think about it. I want to connect the components to the single source of truth and then respond by rerendering when something changes. The API is actually very similar on what you said, Rob. In fact, the set of mapStateToProps is just map states to computed, which is very much the same idea so instead of really defining the component like you might normally, this is where it gets a little weird for your classic Ember developer, you actually just write two functions and really only one is require. The first one is what you're hinting at Charles, which is I want to pull from the state a set of properties and as you mentioned, the plumbing is sort of hidden, magically those are actually created as CPs or Computed Properties on your component so you can go to your HPS file, your handlebars template and say, "Oh, I took number from the global state and I'm just going to map it in this function and now I can go to my handlebars template and number," and there it is. Every time you bump number up or down, you'll get a rerun in your callback and the HPS will update. The other function, as sort of glossed over is really just for your closure actions. If you would like to ask the store to do something and saying, "I would actually like to increment the number," then you can fire an action and the second block just does also additional magic, which just maps a closure action by letting you get this dispatched keyword. Dispatch in a Redux context is just, "I'm going to send an action," and you can think of it almost in vanilla JavaScript terms as, "I have an event. Someone will handle this event and I'm just going to throw it up." ROBERT: It makes its way to reducer then from there, right? TORAN: Correct. We haven't talked too much about that process. The reducer really says, "I'm going to be given a state or the initial state, if you haven't done this yet," which would be maybe in the number scenario. I'm going to start with zero as a sensible default and then I'm going to have an action, whether that's add or subtract in this simple example and in add, I'm just going to take the state coming in, even if it starts out at zero and then do something, transform it to a new state. Actually the important word here is that -- I know you guys are big in the functional world, functional programming and that's the word actually got me interested and really excited about programming again as well, in the most perfect sense -- a pure function, which just means that there are no side effects. There's no mutation or changing of the state that comes in when you do it correctly. In this case, actually instead of mutating something I'm actually returning to number two or to number one and you're like, "Now, we have both zero and one in kind of a timeline." If you think about this almost as the realistic stories, we're just kind of kicking a pointer to a new block of state. Every single time you come to reducer, we still have the old state and we can still walk backwards, which is how the time travel debugging works as we just flip the pointer back in time. As you guys have talked about and I think, Charles you mentioned last year in EmberConf, the immutability story has of course a whole slew of great properties that come with it and those we haven't even obviously talked about. But hopefully I gave people a broad overview of what the reducer does. In its most simplest form, state comes and action returns a new state. ROBERT: Yeah, in Charles's talk and his research, I got to sit next to him and watched him do that actually kind of shaped a lot of my thinking and hunger, if we want to keep that going towards doing like something that's immutable and state management in Ember. I would like to thank you, Toran for building that add-on and spearheading Redux because Redux is pretty awesome for state management. CHARLES: By the way, you did in that call out the analogy for hunger. I really, really, really like that. It's an important tidbit not to miss is that when you are feeling those kind of doldrums of development. I know I was actually ironically feeling that about the same time in 2015, feeling of in a funk because I feel like there was a lot of stuff coming down the pipe like with 'data down, actions up' but no good examples of where we've actually seen this in practice. I think Redux is an actual implementation of 'data down, actions up' so I think it's fantastic that you were able to go and seek inspiration there like, "We've got this message of the way things that ought to be doing with the applications ought to be built." But we don't actually have any concrete examples that we can look to. I think the Redux actually is almost the most pure version of that 'data down, actions up'. I guess my next question is given that you've got this global store, you've got a way to connect components. I assume there are other ways to dispatch actions from within your Ember application like what are the patterns that you're seeing emerge around this? We've talked about how you would use them in components. Suppose my tree of components gets pretty complex, how do I manage that to kind of the passing of data down? Do parent components play any role in the data that their subcomponents see? Is each component connecting directly to the store? I'm just kind of curious where that balance lies and how things are kind of playing out? TORAN: There's really two points in your bigger question. One that I was going to try out of you but then you kept going. That was really around side effects. How do you actually dispatch or make changes, requests changes and see the flow and we could talk about that really starts out briefly with a Promise based approach. With Redux, most people don't know but it's basically like asynchronous flow. Dispatch would normally be like asynchronous action where you're sort of blocking and then doing, transform and getting it back. In the simplest ways, you see there is this tool or this add-on, Redux-thunk, which you can use Promises now and async will still work as if it were synchronous essentially by firing dispatch up and letting your reducer do the work. I think that is a great introductory because especially as Ember developers, we've got a lot of experience with Promises so this is just the same thing. In most of the demos I've done and if you check out the read me, there's like a full Yelp Clone example. It's using this approach because it's a little bit more familiar to most folks. CHARLES: Just to clarify what would happen there is you're essentially getting a new state transition when every Promise resolves or rejects. If it's rejects, that's a state transition. If it resolves, that's a state transition. The next Promise that resolves is another state transition. Is that fair to say? TORAN: Assuming you want to alter and use that top level state, of course you could reject or resolve and just not even bother with the top level store. We kind of skipped over some of the benefits and we could just roll back to that briefly. Why would you use top level stores at all? You mentioned earlier and it kind of seems counterintuitive. This is basic global variable. That's what we're talking about. In the Ember example, I think it's actually sort of not weird because if you guys, your Ember data in its earlier form or even today, it really very much is that. We have this one cache of objects related or otherwise and we pass those around. They are a global object or almost like a global variable. The downside of that in my experience has been that is truly mutable and actually everything is driven by mutating those and then having callbacks or denotify property change drive your template updates. That is not the process with Redux, of course. It feels more explicit, where I can actually go look up kind of a tree or look up table of actions and see exactly what's going to happen. Then also to your second half of the question, which is like how was the components wired up? How do they map? I actually uses an interesting pattern which isn't specific to Ember-Redux or Redux, which is to create a seam in my components now where I have truly HTML CSS components. Separating those from the components and know about the data and the closure action story. Forgetting Redux for a moment and all of this actually made my regular Ember much better because I started to produce this component that would connect to a Ember data store, provide closure actions to send up in the most pure 'data down, actions up' sense and then I would connect it using the yield block, which credits to you and other folks at EmberConf that you, Charles kind of talked me into this because I was a espousing this idea but I didn't really understand that I would actually nest within this parent, the HTML component that would just be handed the properties to render. When we do this, again it still is I think a better pattern even if you're not using Redux but when we did it and I when I started with Redux, the only thing that really gets me in hot water is when people see this and they're like, "Oh, so this is the first thing that comes down from the routed controllers template. Then there's always this brief moment of like, "I'm not sure what to say. I don't want to predict the future and I'm not trying to be Mr Routable Components here." But for me, most of my controller templates are just a landing page for the component tree to begin. Again, that's not me trying to hacking the route or anything to say, "I want to use this controller as a routed to component. I think eventually when that RFC lands, this will look different, anyway so I'm not trying to have people do things really outside of the Ember ecosystem or outside of the norm." But from there, I feel like still just landing into a component, allows you this composition which is supposed is the real value of the components structure. They are too primitive to build pages and then eventually full apps. ROBERT: So if we want to drop parallel, it's container versus presentation components, right? TORAN: Yes and that of course, again stolen from, not me probably stolen from someone else in the 70s. But you know, Dan Abramov is accredited to bringing that idea about in React. Actually I like the idea because let's pretend I had done this pattern in 2013. Now, it's using Ember data or simple store or Erik Bryn's Ember model, something like that. Then eventually, the community start shifting to something else. It could be MobX, it could be Redux and whatever the case, I could just very easily swap out those connected components that have no HTML CSS. The data source changes and all the presentation components do not know. They do not change. There is actually an iterable story to refactor through, an update like that normally is kind of a [inaudible]. If you have ever done PHP in the early days or at least my PHP experience in 1999 -- no offense to PHP today -- was that everything was so stuck together or so couple that I could never refactor anything out of it. Of course, you probably do this in a consulting space as I have, where he first thing on a messy project is actually making those scenes in the application anyway to allow you to upgrade incrementally. This process is just more of an upfront thought and I don't think it's really taken hold than it needs to in the Ember community. It's just something I was experimenting with and I'm finding a lot of value because I think the connection of the data source is a different activity than HTML. ROBERT: I think it also holds a lot of value. CHARLES: I think it holds a lot of value. I think there's a dawning awareness of this. In your comment, I actually thought of two blog posts for EmberMap, which I was just reading this morning. One was talking about kind of the safety of the herd and don't worry so much about controllers versus radical components like use your controllers, use your components. Don't worry about it too much. It'll get sorted out. I definitely agree with that. Although, you definitely want to experiment when you're experiencing particular pain around something. But then, the next thing which I think came out yesterday was talking about basically components for managing side effects, which I think is an unfortunate name because I think side effects is a tainted word. But basically, the idea is having presentation components and container components and the container components are responsible for managing the state. I think that idea is valuable in of itself and I hope that it takes root. I think that's something that you're doing, something that we're doing and as people kind of realize it, it does take root, just kind of by virtue of its own value. Let me summarize if I understand it correctly. As part of these job, you've got these container components and their job is, I like the term that you used, creating a seam. Their job in the Redux world is to take a slice of that global state. You have these components whose responsibility is taking a slice of that global state and presenting that global state to HTML CSS aka presentation components that lie underneath them. Is that a fair assessment? Then if that's so, I've got a second part to that. I just want to make sure I'm understanding it correctly. For components that are further downstream on that tree, do you ever switch back to data containers like you switch between data components and presentation components and then back to data components and then to presentation components and kind of back and forth and back and forth on down the tree? Or do you mostly see it as one-kind of container component on top and then presentation components all the way down? TORAN: It's a great question. I think that still needs a fair bit of experience in the Ember community because the patterns I pulled from the source code I read a lot is mostly from the React ecosystem. Because of that, there's a very split view or a different view in that community on routing. We may share some of those views in Ember but I think for the most part, we assume routing actually and that's one of the tricky part to answer your question. This is a broad statement so I'm likely wrong in every context but I don't love to be creating these data components that don't get routed to if I can help it. I'm sure there are situations that have been really complex, places where you just have to make, no route here because I don't want change the URL for instance and I'm just going to make this thing like a routed to component with no URL to get me here. But for the most part, I treat the entry point to this route and when I land on this route at this time, it's appropriate to ask for the data likely coming from the model hook in the route. In fact, all that's still the same. That's also where it's a little weird. If you've ever seen a full component tree in a React app, they may not have a router at all. In that situation I think, Redux was in particular even better because you don't have to pass from the top app component, the same props or the same data all the way down that tree. In fact, if you read documentation about why Redux in the React ecosystem they'll say, "It gives you this place where we can create a little shim and then ask for the data down here in the [inaudible] mode. You don't have to pass it from the app to that, to that." I see those benefits but in Ember we don't really get as much from that. In fact, they still tell people who challenged the global state idea that not everything maybe should be a global state but you give up some things by doing that. The first one I would say, which I think is the most valuable for anyone doing vanilla Ember with Ember data or someone experimenting with React or Redux. Or the case I'm most interested in, the audience I'm after which is Redux in Ember, which is do you actually need to have that state in one place. The prime example of this that is the greatest use case is master detail. What I mean by that is you have a list of things and when someone drills into one of those, you can also see that at the same time. There's really two choices you can make here. One is I'm going to have two separate data sources to feed two separate components so the list will go get its data and then the detail won't even use that data at all. Just go get its own data. In that case, you may up against a problem where you need to synchronize at some point and here's the tradeoff. Either synchronize the two separate states or you have a single source of truth. That's a real benefit I think of Redux for the most part. It's like the broad, "Do I want deterministic rendering?" We've all heard the joke about the Facebook nav bar that's like, "You have one message," and you're like, "No, I just answered it down here." Well, that's a different component so the joke is like, "Oh, Redux must be working. We have one up here but I've already read the message." You know? Someone obviously is in charge of synchronizing in those sort of examples. Maybe not just doing it well or they run up against an issue synchronizing that. My experience doing back end development, colors this for me. What I rather have three databases and they kind of synchronize the state across them or I rather have the one postgres or SQL server database that is the source of truth so that when I render something to a customer, I can guarantee that it's not in a transition to be synchronized. It is the source of truth. CHARLES: Right, I really like that and I think the point that I take from that is that, and again this speaks to people who might be internally reacting to this idea of a global state is that you actually do have a global state always in your UI, whether you acknowledge it or not. It's composed of all the other distributed states that are sprinkled around your application so if you take an approach like Redux, you're kind of acknowledging that upfront that at any given time, I do in fact have a global state. I might as well deal with that explicitly. That's kind of a key innovation. I also like what you said too about kind of treating the router in Ember really leaning on the router as a good way to partition your data or drill down into a sub-piece of that global state. Inside Ember-Redux, are there explicit hooks for dealing with the Redux store inside your routes? TORAN: Yeah, that's that one that gets me the most trouble. When I see a blog post and memes that are all about the herd lately, can't help but feel like they're pointed directly at me because of some of these new ideas. CHARLES: Toran, I'm just telling you. This is a safe space. We believe in innovation here. You're okay. TORAN: Yeah. CHARLES: Let me add-on that. I didn't mean that as a knock to you. I do think they call this out of the end of the blog post. I think acting in concert with the community for the most part, actually fosters innovations and an innovative journeys like the one on which you're currently embarked because you don't have to worry about CLI tools and you don't have to worry about this. You can focus on the problem of like how does an Ember application work with a global atom as its state. TORAN: That is the idea. I mean the route is interesting. I have a little helper to your point, Charles if you've seen some of the docs or any of the examples. There is a little helper for routes and all it really does is provide dispatch as an argument. For instance, a lot of times I just want a model to be a regular function and dispatch to be an argument so I can return a Promise or do some Generator stuff as a side effect. In that way, I sort of create a shorthand which is just really simple. It allows me to say [inaudible] model and then have dispatch as an argument and run my code then just providing that to this special little helper. It's a functional type helper called route and what it does behind the scenes is it injects the Redux service for me, which is again something you can do by hand. If you really just don't like that or you want to be more in the herd, you can just have a regular route, inject the service and then get dispatched from that service and use it. ROBERT: It looks like you just dropped the version 2.0, like three hours ago. I would like to ask, we heard about your journey like you were feeling like you weren't hungry for learning. I want to know more about where you actually sat down and wanted to write this add-on on and why you chose to clone the React-Redux API and what took you on that path? TORAN: Yeah, that's a good question. Back to benefits or the reasons I got excited about, of course I mentioned during the talk that Dan Abramov did. There was some interesting dev tools. First of which was this thing Time Travel Debugging which it allows you to sort of move backwards in time and pretend as if actions and mutations or what looked like mutations that never occurred. That was very interesting. I wasn't really sure of the value, especially at the time. I told you guys around 2015, I was consulting which lucky me, I was doing Greenfield. Thankfully, I was working with a really great team and some great people, built an amazing product. I don't really understand the pain of this. For the most part Ember-set was doing its job and I didn't really have a lot of interest in learning this. But as I got more into it, also started a full time job last year, I pretty much just fix bugs for a year. Anyone who's been on one side of the fence or the other knows that the bug fixing side will sort of expose, maybe the weaknesses of the application or patterns or choices made. For me, that was really mutation or shared mutable stake aka the root of all evil. If you've ever looked at your Elm ClojureScript, Elm next is the same vein where immutability is very much there. Charles, of course gave his talk on immutability and trying to get people interested in that or more interested in the Ember community. That was really all I wanted to do to your point, Rob was provide really an outlet for people to use this and I wanted to keep the messaging away from the things I didn't like, which I think was actually something I screwed up to be fair early on. I think I was very vocal in the microcosm that I would talk to people about like, "These are the things I don't like about Ember," or I would use the word 'Ember the good parts' plus 'Ember the bad parts' and I was told not to say that anymore on the Slack channel. Once I started getting too much needed feedback -- I don't want to be negative about it -- I changed my messaging and as part of that, you mentioned Rob I basically cargo-culted or copied this API from React-Redux called connect and excluding the brief route helper that I mentioned, Charles a minute ago, the real idea here is you just call disconnect function with two other functions: mapping state and closure actions. Everything else becomes then vanilla JavaScript in this reducer function we talked about briefly where I have state coming in and I need to transform it into a new state. One interesting benefit of that -- I wasn't overly critical about until I really saw the difference is that -- I'm no longer using the Ember object. I'm not doing Ember.get and set, which immediately start to open the door some time last year for TypeScripts interest. I'm actually not a super type friendly person. I sort of left Objective C and C# and Java in my background and have like this Vietnam experience when people ask me about types. But I do understand one very critical fact that I can't dispute about types is that there are more information for the next programmer than you have without them. Again, my experience this last 12 months has been, as a maintenance programmer, I need more information. Tests are great when they're there but they also don't provide the interface or all the information about those and certainly the compiler may help as well. I don't know yet. I'm not doing any TypeScript. What I started notice is also more functional programming and maybe just not in our core yet but also things I wanted to steal from other ecosystems because I also found is very interesting. I started to study functional programming. I know like nothing about it, of course. I don't think anyone does because I can't describe a monad without getting in trouble or being wrong. For me, the real value is the separation of the data structure and the function. I'm preaching to the choir here but that was so much like an interesting idea to me and actually spurred on some of the further patterns or adoption of those in my work in Ember-Redux because this presentation and container component idea was really that I was separating the data structure from the function of the view. I think you mentioned this in your talk at EmberConf where the actual HTMLbars template is really just a function that has data in, HTML out. I started to internalize that and think about that and what were the properties I got from that, as well as I enjoyed functional programming. Some other great benefits that we've already touched on briefly are just how much more of this I felt explicit, not that Ember-set is inherently implicit but when you do a Ember-set for mutation to chase down every single place in a complex system to determine why they something render this way? It does feel a little more implicit than something like React-Redux with this connect function where I was like, "Wow," when I was doing React. Especially, I was like, "I bet I could just put a breakpoint at every connection so when that callback happens, I can know exactly what action spurred on this new callback to rerender," and that was something that was very new and interesting. Then of course, falling out of all this was another hyped tooling thing that I thought was really cool, not explicit to Redux, again but it got me interested because that's hot reloading. All hot reloading of CSS and Ember CLI, which I've never done design work which I'm not good at. But I do write some CSS or hack-on it when friends show me what to write. Then writing HTML was a separate experience. Once you wrote the CSS, you would hot reload in that course, what do you do every time you change CSS, you also change HTML, which would incur a full-page reload with a live reload tool, if you're familiar with that in Ember CLI. This tooling allowed the Redux store itself because it's stored the state, allow me to really throw the component away in the page without refreshing it and then providing a new one and just go rerender because the state was instantly mapped in and then rerendered. I actually did a demo sometime last year and like, "I'm going to build a star rating component and here it is with live reload. Here it is with hot reload. I'm not going to make a decision about which one is better. You decide," and overwhelmingly people were like, "This is a much nicer feedback loop to make HTML and CSS changes in real time." ROBERT: Agreed. Let's pedal back the hot module reloading because that is pure awesomeness. But that has a little bit of setup they have to do and changing your application. I remember we were talking about this. When you did that demo, I remember this. But there's a little bit they have to do to make your components stateless. They have to come down from the Redux store. TORAN: Correct and this actually still applies if you are, I think using Ember data as well, as you just can't pull the state to reload it anything local, which may go against what you're trying to do with your component. ROBERT: Right. That's cool but I do want to highlight a little bit something that was cool about the Redux dev tools as with all the state that you have since it's in a centrally managed place, you can take your state and then play it back over the top of something like if it did live reload and it'll just pop you right back down to where you were when you were debugging. When that page refresh happens, if you're not doing hot module reloading, you still won't lose all your state which is really cool. You just play it right back down on top and you're exactly where you were before. It's almost like you would throw a specific test that puts you into that state that you're trying to debug. TORAN: Yes, it's like git rebase. It lets me pull off my state, replay the new component function and then drop my changes on top of it and see it all viewed together. ROBERT: Yeah, I think that's massively powerful. CHARLES: Yeah, it is fantastic and that's where you get into that power. I can get on my immutability soapbox. But it turns out that as programmers, we deal in information and not throwing information away, not just flushing it down the toilet is hugely powerful. I think the thing that's so fantastic is that Redux takes this concept and then all of the tools to leverage it are there for you. I think that it is something that is missing from the Ember development story and people don't realize that it's missing, that we have all these wonderful tools, we have this conventional way of building our applications, of deploying our applications, of rendering our applications, of marshalling the data in our applications in the form of routes. But what we're lacking is this unified atomically based state management solution. I think that, Toran it's been fantastic that you have pioneered this and trying to bring what I see as a glaring gap in the developer experience to the community. I'm curious then to ask you what do you see as the future. You know, 2.0 just dropped and there's this need. I feel very strongly that Ember 3.0, 4.0 or Ember 'dot future' at some point should have a unified state management solution. How do you see the road that you're on intersecting with that future if it does in fact exist? ROBERT: Also how can I help or how can we help? TORAN: Just real brief before I dive into some of those questions. I just want to mention that 2.0, as awesome as that sounds, of course I dropped that this morning just so we could say that on podcast, really. We've had a beta in the works for Ember. The only change really, if you're like, "I just got into an Ember-Redux last week. Is it all garbage?" No, this isn't Ryan Florence 2.0 -- it was a joke for any [inaudible] router folks in here. Actually, just us removing Browserify because if you are familiar with Browserify in the Ember ecosystem, talk to Robert Jackson or Stef Penner, folks familiar with that in Broccoli, they'll tell you that one of the harder things to optimize and although, it created a great entry point to how do I use Redux? Boom! Ember Browserify, install Redux, I'm done. If you've ever seen an [inaudible] in Ember that has 'npm:', you're using Ember Browserify to pull in, either a common JS module or some kind of node module and use that in the Ember ecosystem without an additional shim. Now, what we found or learned was that bigger teams that are using this, paid a little bit of a cost and not just cold rebuilds. I'm talking hot rebuilds because Browserify just isn't friendly to get those to be optimized, I guess is the word, so we removed it completely or just use some smaller simpler shims. You actually get the performance improvements hopefully -- ROBERT: That is awesome. TORAN: -- Which is big win. Back to your question, Charles. The audience that's intended, of course is a little different than most people like me to talk about. In fact, the API itself, I think was a bit rejected. You're sort of asking like, "What does this mean in the future?" I don't really feel that the traditional Ember audience has picked up around with it because of something that's missing. You said the 'C word' earlier so convention is certainly still missing from this and even in the React ecosystem, they're just barely thinking about, "Look at all this great stuff we can do with one-way data flow and immutability and functional programming," but guess what we're giving up. No one's really come around with this perfect pattern and conventionalized it as Ember did in its early days so there's a lot of churn, I wouldn't say overly so much that you're not going to getting work done but more than the average Ember developer is aware of. My audience is actually not the average Ember developer, which may be bad for what you're asking about, Charles. Instead, it's actually the person who maybe has done React and maybe Redux or Backbone in the last two years. They love some of those patterns. They're not in love with the Ember-object because of getting set. Maybe they love TypeScript and they say, "I want to use this in Ember." They joined a new company that's a little larger than the startup they'd been on the last two years and they are using Ember. They love a lot of Ember but they would also like to use some of the predictable state patterns that you get with Redux. As well as maybe the dev tooling, things like that so they have adopted this. I feel like that really is the new audience that I aim to please or I'm falling in line with, which is a little bit outside. I feel like there's room for some fragmentation and a good beat up on me for that because when the realities of this herd conversation that we're kind of talking around a little bit is that the herd is great until something innovative needs to happen. Innovation, obviously takes some risk and I feel like that's sort of what I did last year and said, "Here's some interesting ideas. I have not shipped Facebook with it yet so let's just check this out." Of course, Ember add-ons are a great way to enable someone to try a new idea. But I think most people got into it, saw this funky connect thing and they're like, "What the heck is this?" It's a function and returns a component. All right, that's not doing that so most people bailed out. But I do hope people still and I know great folks at LinkedIn, Chris [inaudible], of course. We chat occasionally. Mostly he just tells me what I'm doing wrong. Shout out for Chris. But he knows a lot more about some of the stuff than I do and I think he is fully aware of the values that are in Redux that are great and then working hard, of course during his full time gig to apply these to Ember data and hopefully these do make their way in naturally. I just wanted to be a bit more radical. I don't want to wait around and I wasn't really involved in the Ember data project. My own fault there but I think if nothing else, the ideas will come out of it because the developers want this. Whether you're the audience I'm talking about, which is a React developer from two years ago, you're in Ember, you're eventually going to really understand and want this and then those 'data down, action up' ideas that were pretty unclear to me in 2015, will be very clear. In fact, if anyone seen or heard of this Project MobX, which is like an alternative in a way, popularity-wise to React ecosystem. It kind of looks like Ember in a way where you get sort of some more magic and what I found quickly in playing around MobX is that you can very much fall into the shared mutable state problems. The interesting part about MobX is you can opt into a strict 'data down, actions up' approach. But if you don't have the Ember battle scars like we do, you're just going to come in and say, "What's less work?" Just like in Ember when I can do a set in the [inaudible] node, why would I do 'data down, actions up' and that's the transition I want to see folks make. Hopefully they learn something from that. CHARLES: Right, I agree with you. Although, I think the time has definitely come, I think the term 'herd-mentality' is an unfortunate one. I prefer to think of it as like a pack. If you travel as a pack, you can bring down moose that are bigger than you are individually. But every once in a while, like a gigantic moose with laser horns shows up and then what are you going to do? If you're hunting as a pack, you have to introduce new things because I like that analogy a little bit better than a herd because the job of the herd is just to not get eaten, where is the pack has this idea of these entities that have to stick together. They're hunting and they're tackling different problems as they come but sharing in the benefits. But I think that there has to be room for innovation inside that herd/pack-mentality, whatever you choose. I do think this idea needs to be introduced so what I would say is that if you're listening to this podcast, you should actually go and you should try and use Toran's add-on and you should try and build something with it so that if you have opinions about how it should fit into Ember, then we can hear them. It sounds like you're taking a minimalist approach, you're emulating patterns that are proven to work in the React community so kind of enabling that seed cross-pollination right there. I would say go build something with it, experience what it's like to have your state as a single atom, experience what it's like to have incredible development tools that come along with that. I think that if you're in the Ember community today, you need to go build something with React, you need to go build something with Redux and you actually have made it one step easier to do. You don't even have to leave Ember to do that. You can build something of node with production quality code using Redux and you can experience what it's like. That's my challenge, I think to the Ember community. Go try it, go experience it because you'll come back, I think like I did. You'll come back with superpowers just from having tried that. ROBERT: Managing state becomes so easy. TORAN: Yes. I want to jump in briefly and just cover one point that we haven't talked about that's very controversial so why not drop it at the end here. I think, Rob you might have asked about it earlier and I just didn't feel brave enough to talk about it at that time. But you guys keep going back to this idea and I have to talk about a little bit too. One of the motivations is I live in Iowa. I work in Texas. Thankfully, this great company, Q2 employs me and I don't know why I'm being paid. I'm lucky to be writing JavaScript for money, probably we all are. But in the Ember local community that I'm in, a very little folks writing Ember and that was even years ago. I was like the only voice in the middle of the Midwest screaming and then folks in Minnesota would tell me that wasn't true so I went up there and did a conference as well. But for the most part, I looked around the job market too and thought, "It be really great if I understand some of the more JavaScript-centric parts of building web apps today," and when I looked at Redux functional programming, the way the reducer worked and structured, the way to React-Redux project was structured and thought, "I bet I could emulate that an Ember," such that I could actually and I believe this is to be true, that if you were in a React-Redux project or even an Angular like ‘ngRedux', which is a very similar connect binding, you could copy a whole directory of your reducer code, which is all vanilla JavaScript. If you're doing generators, which we didn't talk about but if you're doing you know any additional side effects, you copy all that vanilla JavaScript, drop it into your Ember app and it all works because it doesn't matter if it's in React or Ember or even Angular, even View if View has some connect API like this. We all share this common API that is just give me the functions that enumerate over the data and return new states of the data and call back to rerender. There's something really powerful about that but the tradeoff being there are not a lot of strong conventions, Charles that I have adopted. That's kind of what I'm cautioning here a little bit is that I'm still also just watching the other communities to see what eventually turns out not. This is going to be am Ember add-on and I don't care what everyone else is doing. This is my vision because really my vision was to make a drop in for anyone already doing Redux on any platform. CHARLES: You know, to the point, there's a pack that extends beyond the Ember community and it sounds like you're also leveraging and being a part of that. TORAN: There's an interesting idea about the hunger thing, which just tied us in and there's where the fourth thing that a doctor will tell you to get your hunger back is go experience eating with other people. There's actually a statistic that when you sit down to eat with someone else or many people, you're likely going to eat 44% more food than you did on your own. That's just, I guess a statistic that's true. I just made it up for this podcast. No, I think it's true. If that is the case, then I think that very much translates to programming as well where when I'm developing code with other folks and I'm on like the React channel and we're just talking about vanilla JavaScript, it doesn't have to be me being an Ember developer anymore, which has been a large part of what's blocked me from being, I think an asset in my local community in the broader JavaScript community. At large is every time I get a conversation it's like, "I have to do it the Ember way," and that's changing actually. The Ember has credit a lot of deprecation if you guys have seen or follow the RCs and other just Ember upgrade deprecation. We're kind of getting away from being Ember and writing just more JavaScript and even maybe sometime this year beginning ES6 classes, instead of Ember object extend. I think Ember is heading in that direction. I just went there, rather rapidly because I also was again experiencing vanilla JavaScript with other communities, View and React. ROBERT: I think we're walking on this very similar path. I'm following your footsteps right now, it sounds like. TORAN: My last point which was that third bullet about building component trees, it didn't sound like either of you guys really contest that and I'm friends with, obviously Chris Freeman, formerly The Frontside and Chris tells me, "You're trying to build full component trees once you're injected at the route level and you're not doing like a ton of HTML in your controller HPS files." Is that true? CHARLES: We treat our controller basically as a component. Sometimes, we'll be like, "This is the controller and if we ever use it in more than one place, we'll take out its component." We're not super dogmatic but we definitely see the clear separation of the route is for maintaining the data and everything else is just one tree of components just below that. ROBERT: The more I think about it though, I'm so conflicted because I really like routes in Ember and they do a lot for you. I like having the data be maintained in one spot but I don't know a single store with Redux maintaining that and using like Redux-thunk or Redux-saga. I got some exploring to do. CHARLES: I don't think those are mutually exclusive propositions. That's what you were saying at the beginning, right Toran? You still do all of your data munching in the route. There's two kind of subjects that I wanted to broach briefly, although I don't think brief is possible with them is actions, like how we talked about data down, we talked about where you draw the seams in your application, where you're loading your data, where you're mapping it to your components and having that separation into your presentation components. We didn't get to talk about reducers so much and how you map. You touched on it like the mechanics but suppose I have a to-do list and I want to delete an item and I've got some button to delete an item, that's down my component tree. How do I map that action back up to the store? I don't know if we actually have time to cover that because it is meaty-meaty subject. ROBERT: Redux part two? TORAN: Yeah, we have to follow up because really that is a little bit more of an advanced segment not that folks shouldn't hear about it. But one thing that's a radical shift, Charles that we would have to go into and talk about, which is controversial as well as most folks want to operate in one structure, one dictionary not in the array. Then immediately, everything flips to being a Lodash operation. I didn't really use Lodash at all until I got into this. You guys probably actually are smart folks to do. But for me, this store is not in array now. When I'm doing array operations like remove or filter, I'm actually operating with Lodash on an object to produce those new states and most of it is just learning the Lodash operators because I didn't actually know them so the Yelp Clone that I have out there is a very simplistic look at using Lodash with Ember. But it accomplishes some of that. Then also, the secondary piece that would also consume a ton of time that we should go into but maybe not today is switching from Thunk to Generators with Saga and then maybe even observables with RxJS, which seems like possibly the future. Those all sounds cool but I think they're going to blow the heck out of scope on this thing. CHARLES: All right. Well, thank you so much for coming by Toran. As always, our conversations are too big to fit into a single podcast. I really want to have you on again. There are so many things that we haven't even touched on. We haven't touched on the subtleties of how action dispatching works. We haven't touched on using Ember-data -- I'm just [inaudible] out there and say it. With Redux, we haven't open that can of worms and who doesn't want to just sift through a can of worms on a podcast? We are going to have you on again. I am positive of that. ROBERT: We're going to paint that bike shed. CHARLES: Yeah, we're going to paint that bike shed. It's a bike shed that needs to be painted. It's something that the community, I think needs to face head on. Thank you so much for coming by and talking with us about Ember-Redux. Everybody, go and check it out. Toran, you've got some talks coming up, if you want to mention those real quick. TORAN: Yeah, I just wanted to plug. There's possibly going to be a talk, we're still lining up the official date with the Washington DC Ember Meetup sometime in April. I planning out to fly out there actually and give this talk on Ember-Redux. I want to thank just publicly the RSA team for kind of helping sponsor me to fly out and check it out. As well as give a more in-depth talk on Ember-Redux in the Meetup setting. CHARLES: Fantastic. If you're in the area, be sure to go check that out. If not, watch it on video and then unrelated Ember-Redux, if you haven't watched Toran's EmberConf talk on Outside-In development. TORAN: That's out actually global Ember Meetup, I think. CHARLES: Okay, that one. Actually, just go watch all Toran's talks. The thing that I didn't mention at the beginning of the podcast is that you do a lot of live coding, which is just makes my bowels freeze when I think about doing it. You just pull it off so effortlessly so it's definitely, definitely worth a watch. With that we, will take it out. We'll see you guys later. That's it from The Frontside. Remember to get in touch with us at Frontside.io. If you're interested in UI, that's engineered to make UX dreams come true.

texas europe innovation minnesota iphone iowa vietnam boom promises midwest saga tests react slack time travel ux api redux meetup ui separating java components javascript html generator backbone dispatch broccoli css cps php tester greenfield cloning sql rsa elm js generators angular rcs typescript cli jquery rfc billups objective c hps test driven development robert jackson thunk es6 html css toran chris freeman dan abramov rxjs frontside mobx react redux ryan florence lodash browserify emberconf charles lowell robert it ember cli robert so charles you

Lodash Tooling and Optimizations

3 Minutes with Kent

Play Episode Listen Later Jul 13, 2016 2:58

My co-worker asked me about why the babel-plugin-lodash (https://github.com/lodash/babel-plugin-lodash) module is useful and I explain that and the lodash-webpack-plugin (https://www.npmjs.com/package/lodash-webpack-plugin) too :-)

Episode 10 – Continued Part 2: awesome-sec-talks, jstips, chakra, jquery, openshot, redux, lodash 4

Open Source System

Play Episode Listen Later Feb 2, 2016 34:50

Notes: http://opensourcesystempodcast.vf.io/2016/02/02/episode-10 This is part 2 of the a long episode. We suggest you listen to part 1 (episode 9) before you listen to this one. Thanks! Projects https://github.com/loverajoel/jstips JS https://github.com/PaulSec/awesome-sec-talks – Text News https://blogs.windows.com/msedgedev/2016/01/13/chakracore-now-open/ nodejs/node#4765 http://blog.jquery.com/2016/01/14/jquery-3-0-beta-released/ http://www.openshotvideo.com/2016/01/openshot-20-beta-released.html https://github.com/lodash/lodash/wiki/Changelog#v400 https://egghead.io/series/getting-started-with-redux Podcast Hosts Vlad – https://twitter.com/vladikoff Kyle – https://twitter.com/shamakry Mike – https://twitter.com/miketaylr Alex – https://twitter.com/slexaxton

projects redux chakra js jquery changelog openshot lodash

Episode 64: Touchscreen UI events, Sprite and checkbox animation, Lo-Dash

The Treehouse Show (2012 - 2015)

Play Episode Listen Later Nov 5, 2013 12:34

In this episode of The Treehouse Show, Nick Pettit (@nickrp) and Jason Seifer (@jseifer) talk about the latest in web design, web development, HTML5, front end development, and more.

events animation sprite html5 touchscreens checkbox lodash nick pettit jason seifer treehouse show

Episode 64: Touchscreen UI events, Sprite and checkbox animation, Lo-Dash

The Treehouse Show (2012 - 2015) (HD)

Play Episode Listen Later Nov 5, 2013 12:34

In this episode of The Treehouse Show, Nick Pettit (@nickrp) and Jason Seifer (@jseifer) talk about the latest in web design, web development, HTML5, front end development, and more.

events animation sprite html5 touchscreens checkbox lodash nick pettit jason seifer treehouse show

079 Lo-Dash with John-David Dalton

Play Episode Listen Later Oct 11, 2013 64:41

The gang talks to Lo-Dash maintainer John-David Dalton about open source software, performant Javascript, Lo-Dash and Underscore

javascript underscore lodash john david dalton

079 Lo-Dash with John-David Dalton

Play Episode Listen Later Oct 11, 2013 64:41

The gang talks to Lo-Dash maintainer John-David Dalton about open source software, performant Javascript, Lo-Dash and Underscore

javascript underscore lodash john david dalton

079 Lo-Dash with John-David Dalton