Podcasts about AngularJS

Seekord on külas Dmitri Gostev, Askend senior front-end arendaja ja arendustiimi juht, kellega räägime tema kogemusest kahe projekti kolimisel AngularJS pealt Angular viimasele versioonile. Tuleb välja, et esmapilgul õige lähenemine ei pruugi üldse kõige lihtsam või efektiivsem olla.-----Episoodis mainitud ng-zorro Angular komponendid: https://ng.ant.design/Konveyor Kai AI põhine rakenduste moderniseerimine: https://github.com/konveyor/kaiJaga meile enda jaoks olulisimat mõtet episoodist meie Discord kanalis: https://discord.gg/8X5JTkDxccEpisoodi veavad Priit Liivak ja Marin KappAlgorütmi toetavad Patchstack https://patchstack.comNortal https://nortal.com/Veriff https://www.veriff.com/

Alex is accompanied by the wonderful CJ Reynolds in this episode of DejaVue. The Senior Creator at Syntax.fm brings not only Vue experience but also a history of Angular JS and React, as well as various other technologies.The two content creators talk about how CJ became a senior creator at the well-known Syntax.fm podcast and how it is different from Streaming on Twitch and his previous content creation processes. Further, CJ gives insights on how the Denver Vue meetup evolved (now the DenverScript meetup) and shares some hopes when it comes to the meetup scene.Alex and CJ then discuss more technical topics - for example why CJ never fully switched over to Vue but still writes it a lot. The discussion eventually goes into comparisons between Vue and React, highlighting what Vue does "better" than React and how the Vue ecosystem shapes the web development work.Enjoy the episode!Our GuestCJ ReynoldsOwn WebsiteSyntax WebsiteTwitchYouTube (Coding Carden)YouTube (Syntax.fm)BlueSkyTwitterChapters(00:00) - Welcome to DejaVue (00:47) - How CJ joined the podcast (01:38) - How did you become the Senior Creator at Syntax.fm do? (06:00) - Differences to previous gigs and streaming (12:17) - From starting with web development to Vue.js (15:54) - Running the Vue Denver meetup (19:25) - Is the meetup scene growing again? (21:13) - Why didn't you switch fully to React? (23:49) - What Vue does "better" than React (27:01) - Two-way data binding (31:35) - How opinionated is Vue (32:58) - Vue without a build step (35:01) - Does Vue "seem" too magical? (36:07) - "Needing" a meta framework? (38:50) - Nuxt and the UnJS packages (41:01) - Frameworks converging (41:55) - Vue did Signals "first" (42:58) - Is Vue bad at marketing? (44:40) - Vue Job market (45:40) - Vue and Innovation (46:59) - Vue being left out of the conversation (50:52) - What stops from switching to Vue? (53:52) - The change to Vue 3 and the Composition API (01:02:38) - VueUse as a good example (01:03:26) - Composition API without script setup (01:05:56) - Where people can follow CJ (01:06:34) - Wrapping up Links and ResourcesGet 15% OFF for your Vue Toronto ticket with code DEJAVUE *Syntax PodcastDenverScriptimmerImmutable.jspetite-vueEpisode 16 - The Future of Vue.js (with Evan You)vinxiEpisode 30 - Pinia and Data Loaders (with Eduardo San Martin Morote)Vue Data LoadersNitroInterview with Evan You about VoidZeroSyntax Video Series -  React vs VueHeadless UIFormKitOrganizing Code when using the Composition APIYour HostAlexander LichterBlueSkyTwitterYouTubeTwitchWebsite---Links marked with * are affiliate links. We get a small commission when you register for the service through our link. This helps us to keep the podcast running. We only include affiliate links for services mentioned in the episode or that we use ourselves.

React a 10 ans. 10 Ans de Révolution dans le Développement Web avec Amélie Benoît (@AmelieBenoit33) et Manuel Cartier (@neolectron). Enregistré le 04 mars 2024 Téléchargement de l'épisode LesCastCodeurs-Episode-309.mp3 React a 10 ans, longue vie à React ! Dans cet épisode, nous avons comme invités Amelie Benoît et Manuel Cartier. Les deux explorent l'évolution de React au cours de la dernière décennie, mettant en lumière ses principaux principes et son impact sur le développement web. Amélie et Manuel discutent des caractéristiques fondamentales de React, comme la composition des composants et l'utilisation de la virtual DOM, ainsi que des tendances émergentes telles que l'adoption de React Hooks, et les React Server Components. Enfin, nous avons ses conclusions sur l'avenir de React et son rôle continu dans le paysage du développement web. Amélie Benoît Amélie Benoit est une développeuse web avec une expérience d'environ 10 ans dans le domaine. Son expertise se concentre principalement sur React et React Native, qu'elle maîtrise tant en JavaScript qu'en TypeScript. En plus de son travail de développement, Amélie est une entrepreneuse communautaire active. Elle a fondé deux Meetups, dont l'un est dédié à React & React Native, démontrant ainsi son engagement envers la diffusion des connaissances et le développement de la communauté. Elle a également organisé des conférences, notamment lors de l'événement BDX I/O. Elle a aussi été oratrice a Devoxx France parmi d'autres conférences. Actuellement, Amélie occupe le poste de tech lead manager chez Busbud, une scale-up canadienne spécialisée dans la comparaison et la vente de billets de bus inter-cités en ligne. Son rôle en tant que leader technique et manager la place au cœur des opérations de développement et de gestion de projet au sein de l'entreprise. Grâce à son expertise technique, son engagement communautaire et son leadership, Amélie Benoit apporte une contribution significative au monde du développement web et de la technologie. Manuel Cartier Manuel est un développeur passionné, initié à l'art du code dès l'âge de 13 ans. Animé par cette passion précoce, il entreprend des études en développement de logiciels et gestion de projets, couronnées par l'obtention d'un BTS. Son parcours exceptionnel le conduit à se distinguer dès 2015 à l'école “42” de Paris, où il se classe premier parmi tous les candidats. Avec une solide expertise en C++, Manuel s'investit dans l'encodage vidéo et audio chez Ateme, contribuant ainsi à un transcodeur utilisant des bibliothèques faites maison, équivalentes à x264. Passionné par la diffusion en direct, il partage régulièrement ses connaissances en informatique et donne des cours de développement web sur Twitch et YouTube. Toujours avide d'apprendre et de repousser ses limites, Manuel se lance actuellement dans l'exploration de Rust, encouragé par la migration des projets C++ vers Rust chez Facebook. Parallèlement, il explore le développement d'applications mobiles avec Ionic Framework et AngularJS, expérience acquise lors de la création d'une start-up en 2015. Son dernier rôle en tant que développeur Fullstack chez SigFox lui permet d'approfondir sa compréhension des mécanismes de l'IoT. Aujourd'hui, son attention se porte sur l'écosystème JavaScript et l'amélioration de l'expérience utilisateur, ainsi que sur le rendu 3D sur le web avec des technologies innovantes telles que Three.js et React-Three-Fiber. Nous contacter Pour réagir à cet épisode, venez discuter sur le groupe Google https://groups.google.com/group/lescastcodeurs Contactez-nous via twitter https://twitter.com/lescastcodeurs Faire un crowdcast ou une crowdquestion Soutenez Les Cast Codeurs sur Patreon https://www.patreon.com/LesCastCodeurs Tous les épisodes et toutes les infos sur https://lescastcodeurs.com/

W najnowszym odcinku mojego podcastu zagłębiam się w fascynujący świat full stack developerów, omawiając ich ewolucję, wyzwania i wpływ nowych technologii na ich pracę. Rozpoczynam od historii roli full stack developera, eksplorując, jak zmieniały się oczekiwania i potrzeby rynku. Następnie przechodzę do analizy szerokiego zakresu umiejętności wymaganych od współczesnych developerów, włączając w to zarówno front-end, back-end, jak i zrozumienie baz danych. Na koniec omawiam rewolucyjny wpływ AI i innych nowych technologii, które transformują sposób, w jaki deweloperzy podchodzą do tworzenia i utrzymania aplikacji webowych.

EPISODE DESCRIPTION:Angular or React? Wait, why should you have to choose? How about both! In this Dev Life edition of the Angular Plus Show we're talking all about bridging the gap between angular and react. Frontend expert and trainer Tomasz Ducin explores the benefits of diversifying your frontend skills and then shares similarities between the two frameworks, highlighting their component-based architecture and how understanding these similarities can ease the transition between the two. We then get into challenges and strategies for moving between frontend frameworks and take a look at tooling and other tech that can help you along the way. Also along the way you may encounter some bison and salt. ANd that's exactly why this is… The Dev Life!LINKS:https://twitter.com/tomasz_ducinhttps://ducin.dev/https://www.linkedin.com/in/tomasz-ducin-82234a4b/https://architekturanafroncie.pl/https://angular-techradar.dev/CONNECT WITH US:Tomasz Ducin - @tomasz_ducinBrooke Avery - @jediBraveryPreston Lamb - @prestonjlamb

The Elixir Wizards Podcast is back with Season 12 Office Hours, where we talk with the internal SmartLogic team about the stages of the software development lifecycle. For the season premiere, "Testing 1, 2, 3," Joel Meador and Charles Suggs join us to discuss the nuances of software testing. In this episode, we discuss everything from testing philosophies to test driven development (TDD), integration, and end-user testing. Our guests share real-world experiences that highlight the benefits of thorough testing, challenges like test maintenance, and problem-solving for complex production environments. Key topics discussed in this episode: How to find a balance that's cost-effective and practical while testing Balancing test coverage and development speed The importance of clear test plans and goals So many tests: Unit testing, integration testing, acceptance testing, penetration testing, automated vs. manual testing Agile vs. Waterfall methodologies Writing readable and maintainable tests Testing edge cases and unexpected scenarios Testing as a form of documentation and communication Advice for developers looking to improve testing practices Continuous integration and deployment Links mentioned: https://smartlogic.io/ Watch this episode on YouTube! youtu.be/unx5AIvSdc Bob Martin “Clean Code” videos - “Uncle Bob”: http://cleancoder.com/ JUnit 5 Testing for Java and the JVM https://junit.org/junit5/ ExUnit Testing for Elixir https://hexdocs.pm/exunit/ExUnit.html Code-Level Testing of Smalltalk Applications https://www.cs.ubc.ca/~murphy/stworkshop/28-7.html Agile Manifesto https://agilemanifesto.org/ Old Man Yells at Cloud https://i.kym-cdn.com/entries/icons/original/000/019/304/old.jpg TDD: Test Driven Development https://www.agilealliance.org/glossary/tdd/ Perl Programming Language https://www.perl.org/ Protractor Test Framework for Angular and AngularJS protractortest.org/#/ Waterfall Project Management https://business.adobe.com/blog/basics/waterfall CodeSync Leveling up at Bleacher Report A cautionary tale - PETER HASTIE https://www.youtube.com/watch?v=P4SzZCwB8B4 Mix ecto.dump https://hexdocs.pm/ectosql/Mix.Tasks.Ecto.Dump.html Apache JMeter Load Testing in Java https://jmeter.apache.org/ Pentest Tools Collection - Penetration Testing https://github.com/arch3rPro/PentestTools The Road to 2 Million Websocket Connections in Phoenix https://www.phoenixframework.org/blog/the-road-to-2-million-websocket-connections Donate to Miami Indians of Indiana https://www.miamiindians.org/take-action Joel Meador on Tumblr https://joelmeador.tumblr.com/ Special Guests: Charles Suggs and Joel Meador.

Fredrik is joined by Emil Privér and Leandro Ostera for a discussion of the OCaml ecosystem, and making it Saas-ready by building Riot. First of all: OCaml. What is the thing with the language, and how you might get into it coming from other languages? The OCaml community is nice, interested in getting new people in, and pragmatic. And it has a nice mix of research and industry as well. Then, Leandro tells us about Riot - an experiment in bringing everything good about the Erlang and Elixir ecosystems into OCaml. The goal? Make OCaml saas-ready. Riot is not 1.0 just yet, but an impressive amount has been built in just five(!) months. Emil moves the discussion over to the mindset of shipping, and of finding and understanding good ideas in other places and picking them up rather than reinventing the wheel. Leandro highly recommends reading the code of other projects. Read and understand the code and solutions others have written, re-use good ideas and don’t reinvent the wheel more often than you really have to. Last, but by no means least, shoutouts to some of the great people building the OCaml community, and a bit about Emil’s project DBCaml. Thank you Cloudnet for sponsoring our VPS! Comments, questions or tips? We a re @kodsnack, @tobiashieta, @oferlund and @bjoreman on Twitter, have a page on Facebook and can be emailed at info@kodsnack.se if you want to write longer. We read everything we receive. If you enjoy Kodsnack we would love a review in iTunes! You can also support the podcast by buying us a coffee (or two!) through Ko-fi. Links Emil Leo Leo on Twitch Previous Kodsnack appearances by Emil Riot Sinatra Backbone.js Ember.js Angularjs React Erlang Tarides - where Leandro currently works OCaml Robin Milner - designer of ML Caml Javacaml F# Imperative programming Object-oriented programming Pure functions and side effects Monads The OCaml compiler Reason - the language built by Jordan Walke, the creator of React Standard ML React was prototyped in Standard ML Melange - OCaml compiler backend producing Javascript OCaml by example The OCaml Discord The Reason Discord Rescript Jane street High-frequency trading The Dune build system Erlang process trees Caramel - earlier experiment of Leandro’s Louis Pilfold Gleam Algebraic effects Continuations Pool - Emil’s project Gluon Bytestring Atacama - connection pool inspired by Thousand island Nomad - inspired by Bandit Trail - middleware inspired by Plug Sidewinder - Livewire-like Saas - software as a service DBCaml Johan Öbrink Ecto Mint tea - inspired by Bubble tea Autobahn|Testsuite - test suite for specification compliance Serde - Rust and OCaml serialization framework S-expressions TOML Dillon Mulroy Metame - community kindness pillar welltypedwitch Sabine maintains ocaml.org OCaml playground OCaml cookbook - in beta, sort of teej_dv ocaml.org Pool party Drizzle SQLX SQL Join types (left, inner, and so on) dbca.ml internet.bs The Caravan Essentials of compilation Reading rainbow Titles Few people can have a massive impact Impact has been an important thing for me It’s a language out there A very long lineage of thinking about programming languages Programs that never fail The functional version of Rust Melange is amazing This is not a toy project Yes, constraints! Wonders in community growth Arrow pointing toward growth Programs that don’t crash A very different schoold of reliability Invert the arrow Very easy on the whiteboard Multicore for free An entire stack from scratch Built for the builders A massive tree of things Make OCaml saas-ready Leo is a shipper Standing on the shoulders of many, many giants Learn from other people I exude OCaml these days Sitting down and building against the spec You just give it something Your own inner join We build everything in public The gospel of the dunes

In this conversation from the All Things Open Conference, Miško Hevery, known as the creator of Angular and currently the CTO at Builder.io, explains what Builder.io does and the role of the Qwik JavaScript framework in web development. He describes how Builder.io enhances existing infrastructures with a drag-and-drop capability using Qwik and Qwik's performance-oriented features.  00:00 Introduction and Guest Background 00:15 Understanding Builder.io 02:09 Exploring Qwik 02:51 The Problem of Hydration in Web Development 03:36 How Qwik Addresses Hydration and Performance Issues 04:07 The Importance of Lazy Loading 13:04 The Role of AI in Web Development 16:11 The Qwik Community and Its Evolution 17:40 Advice for Potential Qwik Users 19:13 Preview of AllThingsOpen Talk 20:47 Conclusion and Final Thoughts Resources: Qwik Documentation Guest: As CTO, Miško Hevery oversees the technology division that powers the Builder.io applications and software. Before joining Builder.io, he created Open Source platforms for Google, including Angular, AngularJS and was co-creator of Karma. While at Google, he focused on improving testing culture and than transitioned to focusing on improving the web. Miško started his career designing digital circuits and moved to databases, full-stack development and finally, front-end frameworks, giving him a unique perspective. He understands all of the layers from the web down to a transistor. In addition to Google, he worked for tech powerhouses Adobe Systems and Sun Microsystems. He holds an MS/BS from Rochester Institute of Technology and an MBA from Santa Clara University.

Kent C. Dodds, a JavaScript engineer and teacher known for Epic Web Dev and the Remix web framework, reflects on his journey in tech, including his tenure at PayPal and his transition to full-time teaching. Kent's passion for teaching is a constant theme throughout. He transitioned from corporate roles to full-time education, capitalizing on his ability to explain complex concepts in an accessible manner. This transition was marked by the creation of successful online courses like "Testing JavaScript and Epic React," which have significantly influenced the web development community. An interesting aspect of Kent's career is his involvement with Remix, including his decision to leave Shopify (which acquired Remix) to return to teaching, which led to the development of his latest project, Epic Web Dev, an extensive and innovative web development course. This interview provides a comprehensive view of Kent C. Dodds's life and career, showcasing his professional achievements in web development and teaching, his personal life as a family man, and his unique upbringing in a large family. Epic Web (https://www.epicweb.dev/) Remix (https://remix.run/) Follow Kent C. Dodds on LinkedIn (https://www.linkedin.com/in/kentcdodds/) or X (https://twitter.com/kentcdodds). Visit his website at kentcdodds.com (https://kentcdodds.com/). Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Transcript: WILL: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. And with me today is Kent C. Dodds. Kent is a JavaScript engineer and teacher. He has recently released a massive workshop called epicweb.dev. And he is the father of four kids. Kent, thank you for joining me. KENT: Thank you so much for having me. It's an honor to be here. WILL: Yeah. And it's an honor for me to have you. I am a huge fan. I think you're the one that taught me how to write tests and the importance of it. So, I'm excited to talk to you and just pick your brain and learn more about you. KENT: Oh, thank you. WILL: Yeah. So, I just want to start off just: who is Kent? What do you like to do? Tell us about your family, your hobbies, and things like that. KENT: Yeah, sure. So, you mentioned I'm the father of four kids. That is true. We are actually expecting our fifth child any day now. So, we are really excited to have our growing family. And when I'm not developing software or material for people to learn how to develop software, I'm spending time with my family. I do have some other hobbies and things, but I try to share those with my family as much as I can. So, it's starting to snow around here in Utah. And so, the mountains are starting to get white, and I look forward to going up there with my family to go skiing and snowboarding this season. During the summertime, I spend a lot of time on my one-wheel just riding around town and bring my kids with me when I can to ride bikes and stuff, too. So, that's sort of the personal side of my life. And then, professionally, I have been in this industry developing for the web professionally for over a decade. Yeah, web development has just worked out super well for me. I kind of focused in on JavaScript primarily. And when I graduated with a master's degree in Information Systems at Brigham Young University, I started working in the industry. I bounced around to a couple of different companies, most of them you don't know, but you'd probably be familiar with PayPal. I was there for a couple of years and then decided to go full-time on teaching, which I had been doing as, like, a part-time thing, or, like, on the side all those years. And yeah, when teaching was able to sustain my family's needs, then I just switched full-time. So, that was a couple of years ago that I did that. I think like, 2018 is when I did that. I took a 10-month break to help Remix get off the ground, the Remix web framework. They got acquired by Shopify. And so, I went back to full-time teaching, not that I don't like Shopify, but I felt like my work was done, and I could go back to teaching. So, that's what I'm doing now, full-time teacher. WILL: Wow. Yes, I definitely have questions around that. KENT: [laughs] Okay. WILL: So many. But I want to start back...you were saying you have four kids. What are their ages? KENT: Yeah, my oldest is 11, youngest right now is 6, and then we'll have our fifth one. So, all four of the kids are pretty close in age. And then my wife and I thought we were done. And then last December, we kind of decided, you know what? I don't think we're done. I kind of think we want to do another. So, here we go. We've got a larger gap between my youngest and the next child than we have between my oldest and the youngest child. WILL: [chuckles] KENT: So, we're, like, starting a new family, or [laughs] something. WILL: Yeah [laughs]. I just want to congratulate you on your fifth child. That's amazing. KENT: Thank you. WILL: Yeah. How are you feeling about that gap? KENT: Yeah, we were pretty intentional about having our kids close together because when you do that, they have built-in friends that are always around. And as they grow older, you can do the same sorts of things with them. So, like, earlier this year, we went to Disneyland, and they all had a great time. They're all at the good age for that. And so, they actually will remember things and everything. Yeah, we were pretty certain that four is a good number for us and everything. But yeah, we just started getting this nagging feeling we wanted another one. So, like, the fact that there's a big gap was definitely not in the plan. But I know a lot of people have big gaps in their families, and it's just fine. So, we're going to be okay; just it's going to change the dynamic and change some plans for us. But we're just super excited to have this next one. WILL: I totally understand what you mean by having them close together. So, I have three little ones, and my oldest and my youngest share the same exact birthday, so they're exactly three years apart. KENT: Oh, wow. Yeah, that's actually...that's fun. My current youngest and his next oldest brother are exactly two years apart. They share the same birthday, too [laughs]. WILL: Wow. You're the first one I've heard that their kids share a birthday. KENT: Yeah, I've got a sister who shares a birthday with her son. And I think we've got a couple of birthdays that are shared, but I also have 11 brothers and sisters [laughs]. And so, I have got a big family, lots of opportunity for shared birthdays in my family. WILL: Yeah, I was actually going to ask you about that. How was it? I think you're the 11th. So, you're the youngest of 11? KENT: I'm the second youngest. So, there are 12 of us total. I'm number 11. WILL: Okay, how was that growing up with that many siblings? KENT: I loved it. Being one of the youngest I didn't really...my experience was very different from my older siblings. Where my older siblings probably ended up doing a fair bit of babysitting and helping around the house in that way, I was the one being babysat. And so, like, by the time I got to be, like, a preteen, or whatever, lots of my siblings had already moved out. I was already an uncle by the time I was six. I vaguely remember all 12 of us being together, but most of my growing up was just every other year; I'd have another sibling move out of the house, which was kind of sad. But they'd always come back and visit. And now I just have an awesome relationship with every one of my family members. And I have something, like, 55 nieces and nephews or more. Yeah, getting all of us together every couple of years for reunions is really a special experience. It's a lot of fun. WILL: Yeah. My mom, she had 12 brothers and sisters. KENT: Whoa. WILL: And I honestly miss it because we used to get together all the time. I used to live a lot closer. Most of them are in Louisiana or around that area, and now I'm in South Florida, so I don't get to see them as often. But yeah, I used to love getting together. I had so many cousins, and we got in so much trouble...and it was -- KENT: [laughs] WILL: We loved it [laughs]. KENT: Yeah, that's wonderful. I love that. WILL: Yeah. Well, I want to start here, like, how did you get your start? Because I know...I was doing some research, and I saw that, at one point, you were an AV tech. You were a computer technician. You even did maintenance. Like, what was the early start of your career like, and how did you get into web dev? KENT: I've always been very interested in computers, my interest was largely video games. So, when I was younger, I had a friend who was a computer programmer or, like, would program stuff. We had visions of...I don't know if you're familiar with RuneScape, but it's this game that he used to play, and I would play a little bit. It was just a massive online multiplayer game. And so, we had visions of building one of those and having it just running in the background, making us money, as if that's how that works [laughter]. But he tried to teach me programming, and I just could not get it at all. And so I realized at some point that playing video games all the time wasn't the most productive use of my time on computers, and if I wanted my parents to allow me to be on computers, I needed to demonstrate that I could be productive in learning, and making things, and stuff. So, I started blogging and making videos and just, like, music videos. My friend, who was the programmer, he was into anime, or anime, as people incorrectly pronounce it. And [laughs] there was this website called amv.com or .org or something. It's Anime Music Videos. And so, we would watch these music videos. And I'd say, "I want to make a music video with Naruto." And so, I would make a bunch of music videos from the Naruto videos I downloaded, and that was a lot of fun. I also ran around with a camera to do that. And then, with the blog, I wrote a blog about Google and the stuff that Google was, like, doing because I just thought it was a fascinating company. I always wanted to work at Google. In the process of, like, writing the blog, I got exposed to CSS and HTML, but I really didn't do a whole lot of programming. I also did a little bit of Google Docs. Spreadsheets had some JavaScript macros-type things that you could do. So, I did a little bit of that, but I never really got too far into programming. Then I go to college, I'm thinking, you know what? I think I want to be a video editor. I really enjoy that. And so, my brother, who at the time was working at Micron, he did quality assurance on the memory they were making. So, he would build test automation, software and hardware for testing the memory they build. And so, he recommended that I go into electrical engineering. Because what he would say is, "If you understand computers at that foundational level, you can do anything with computers." And I'd say, "Well, I like computers. And if I go into video editing, I'm going to need to understand computers, too. So yeah, sure, let's let's do that." I was also kind of interested in 3D animation and stuff like that, too. Like, I wasn't very good at it, but I was kind of interested in that, too. So, I thought, like, having a really good foundation on computers would be a good thing for me. Well, I was only at school for a semester when I took a break to go on a mission for my church [inaudible 09:42] mission. And when I got back and started getting back into things, I took a math refresher course. That was, like, a half a credit. It wasn't really a big thing, but I did terrible in it. I did so bad. And it was about that time that I realized, you know what? I've been thinking my whole life that I'm good at math. And just thinking back, I have no idea why or any justification for why I thought I was good at math because in high school, I always struggled with it. I spent so much time with it. And in fact, my senior year, I somehow ended up with a free period of nothing else to do. I don't know how this happened. But, I used that free period to go to an extra edition of my calculus class. So, I was going to twice as much calculus working, like, crazy hard and thinking that I was good at this, and I superduper was not [laughter]. And so, after getting back from my mission and taking that refresher course, I was like, you know what? Math is a really important part of engineering, and I'm not good at it at all, obviously. And so, I've got to pivot to something else. Well, before my mission, as part of the engineering major, you needed to take some programming classes. So, there was a Java programming class that I took and a computer systems class that included a lot of programming. The computer systems was very low level, so we were doing zeros and ones. And I wrote a program in zeros and ones. All that it did was it would take input from the keyboard, and then spit that back out to you as output. That was what it did. But still, you know, many lines of zeros and ones and just, like, still, I can't believe I did that [laughter]. And then we upgraded from that to Assembly, and what a godsend that was [laughs], how wonderful Assembly was after working in machine code. But then we upgraded from that to C, and that's as far as that class went. And then, yeah, my Java class, we did a bunch of stuff. And I just remember thinking or really struggling to find any practicality to what we were doing. Like, in the Java class, we were implementing the link to list data structure. And I was like, I do not care about this. This does not make any sense. Why should I care? We were doing these transistor diagrams in the computer systems class. And why do I care about that? I do not care about this at all. Like, this is not an interesting thing for me. So, I was convinced computer programming was definitely not what I wanted to do. So, when I'm switching from electrical engineering, I'm thinking, well, what do I do? And my dad convinced me to try accounting. That was his profession. He was a certified public accountant. And so, I said, "Okay, I'll try that." I liked the first class, and so I switched my major to go into the business school for accounting. I needed to take the next accounting class, and I hated that so much. It was just dull and boring. And I'm so glad that I got out of that because [laughs] I can't imagine doing anything like that. WILL: [laughs] KENT: But as part of switching over to business school, I discovered information systems. What's really cool about that is that we were doing Excel spreadsheets and building web pages. But it was all, like, with a practical application of business and, like, solving business problems. And then, I was like, oh, okay, so I can do stuff with computers in a practical setting, and that's what got me really interested. So, I switched, finally, to information systems–made it into that program. And I was still not convinced I wanted to do programming. I just wanted to work with computers. What ended up happening is the same time I got into the information systems program, I got married to my wife, and then I got this part-time job at a company called the More Good Foundation. It's a non-profit organization. And one of my jobs was to rip DVDs and upload those videos to YouTube, and then also download videos from one site and upload those to YouTube as well. And so, I was doing a lot of stuff with YouTube and video stuff. And as part of my information systems class, I was taking another Java class. At that same time, I was like, you know, what I'm doing at work is super boring. Like, can you imagine your job is to put in a [inaudible 13:45] and then click a couple of buttons? And, like, it was so boring and error-prone, too. Like, okay, now I've got to type this out and, you know, I got to make sure it's the same, try and copy-paste as much as I can. And it was not fun. And so, I thought, well, I'm pretty sure there are pieces of this that I could automate. And so, with the knowledge that I was getting in my information systems programming class, that was another Java class, I decided to write a program that automated a bunch of my stuff. And so, I asked my boss, like, "Can I automate this with writing software?" And I'm so glad that they said I could. WILL: [laughs] KENT: Because by the end of it, I had built software that allowed me to do way more than I ever could have before. I ended up uploading thousands of videos to their YouTube channels, which would have taken years to do. And they ended up actually being so happy with me. They had me present to the board of directors when they were asking for more money [laughs] and stuff. And it was really awesome. But still, I was not interested in being a programmer. Programming, to me, was just a means to an end. WILL: Oh, wow. KENT: Yeah, I guess there was just something in me that was like, I am not a programmer. So, anyway, further into the program of information systems, I interned as a business intelligence engineer over that next summer, and I ended up staying on there. And while I was supposed to be a business intelligence engineer, I did learn a lot about SQL, and star schema, and denormalized databases to optimize for read speed and everything. I learned a lot about that. But I just kept finding myself in positions where I would use my programming experience to automate things that were problematic for us in the business realm. And this was all still Java. It was there that I finally realized, you know what? I think I actually do want to be a programmer. I actually really do enjoy this. And I like that it's practical, and it makes sense for me, so… WILL: What year was that? KENT: That would have been 2012. Then I got a new job where my job was actually to be a programmer at a company called Domo, where they do business intelligence, actually. So, it got my foot in the door a little bit since I was a business intelligence engineer already. I got hired on, actually, as a QA engineer doing automated testing, but I never really got into that. And they shifted me over pretty quick into helping with the web app. And that is when I discovered JavaScript, and the whole, like, everything flooded out from there. I was like, wow, I thought I liked programming, but I had no idea how fun it could be. Because I felt like the chains had been broken. I no longer have to write Java. I can write JavaScript, and this was just so much better. WILL: [laughs] KENT: And so, yeah, I was there for a year and a half before I finally graduated. And I took a little break to work at USAA for a summer internship. And when I came back, I had another year and then converted to full-time. And so, yeah, there's my more detail than you were probably looking for, story of how I got into programming [laughs]. WILL: No, I actually love it because like I said, I've used your software, your teachings, all that. And it's amazing to hear the story of how you got there. Because I feel like a lot of times, we just see the end result, but we don't know the struggle that you went through of even trying to find your way through what your purpose was, what you're trying to do. Because, at one point, you said you were trying to do accounting, then you were trying to do something else. So, it's amazing to see, like, when it clicked for you when you got into JavaScript, so that's amazing. KENT: Yeah, it is kind of funny to think, like, some people have the story of, like, I knew I wanted to be a programmer from the very beginning, and it's just kind of funny for me to think back and, like, I was pretty certain I didn't want to be a programmer. WILL: [laughs] KENT: Like, not only did I, like, lots of people will say, "I never really thought about it, and then I saw it, and it was great." But I had thought about it. And I saw it, and I thought it was awful [laughter]. And so, yeah, I'm really glad that it worked out the way it did, though, because programming has just been a really fun thing. Like, I feel so blessed to be doing something that I actually enjoy doing. Like so many of our ancestors, they would go to work because they cared about their family and they just wanted to feed their family. I'm so grateful to them for doing that. I am so lucky that I get to go to work to take care of my family, but also, I just love doing it. WILL: Yeah, I feel the same way, so yeah, totally agree. After you found out about JavaScript, when did you figure out that you want to teach JavaScript? What was that transition like? KENT: I've been teaching for my whole life. It's ingrained in my religion. Even as a kid, you know, I'd prepare a talk, a five-minute talk, and stand up in front of 30 of my peers. And even when you're an early teenager, you get into speaking in front of the entire congregation. It took a while before I got good enough at something, enough hubris to think that people would care about what I have to say -- WILL: [laughs] KENT: Outside of my religion where, like, they're sitting there, and I've been asked to speak, and so they're going to listen to me. And so, when I started getting pretty good at programming, I decided, hey, I want to teach this stuff that I'm learning. And so, when I was still at school and working at Domo, the business intelligence company, one of our co-workers, Dave Geddes, he put together a workshop to teach AngularJS because we were migrating from Backbone to Angular. And I asked him if I could use his workshop material to teach my classmates. This was, like, soon after ng-conf, the first ng-conf, which my co-workers at Domo actually put on. So, I wasn't involved in the organization, but I was very much present when it was being organized. I attended there and developed a relationship with Firebase with the people there. I was actually...they had a developer evangelist program, which they called Torchbearers or something. And actually, that was my idea to call them Torchbearers. I think they wanted to call us torches, and I'm like, that just doesn't make sense. WILL: [laughs] KENT: I developed a relationship with them. And I asked them, "Hey, I want to teach my classmates AngularJS. Would you be interested in sponsoring some pizza and stuff?" And they said, "Yeah, we'll send you stickers, and hot sauce, and [laughs] a bunch of..." Like, they sent us, like, headphones [laughs] and stuff. So, I was like, sweet. I taught my classmates AngularJS in a workshop, brought a bunch of pizza, and it was, you know, just an extracurricular thing. And actually, the recording is still on my YouTube channel, so if you want to go look at one of my early YouTube videos. I was very into publishing video online. So, if you are diligent, you'll be able to find some of my very early [laughter] videos from my teenage years. But anyway, so, yes, I've been teaching since the very beginning. As soon as I graduated from college, I started speaking at meetups. I'd never been to a meetup before, and I just saw, oh, they want a speaker. I can talk about something. WILL: Wow. KENT: And not realizing that, like, meetups are literally always looking for speakers. This wasn't some special occasion. WILL: [laughs] KENT: And one of the meetups I spoke at was recorded and put on YouTube. And the guy who started Egghead io, John Lindquist, he is local here in Utah. And he saw that I spoke at that meetup, but he wasn't able to attend. So, he watched the recording, and he thought it was pretty good. He thought I would do a good job turning that into a video course. And that first video course paid my mortgage. WILL: Wow. KENT: And I was blown away. This thing that I had been doing just kind of for fun speaking at meetups, and I realized, oh, I can actually, like, make some legit good money out of this. From there, I just started making more courses on the side after I put the kids to bed. My wife is like, "Hey, I love you, but I want you to stay away for now because I've just been with these tiny babies all day. WILL: [laughs] KENT: And I just need some alone time." WILL: Yes. KENT: And so, I was like, okay. WILL: [laughs] KENT: I'll just go and work on some courses. And so, I spent a lot of time for the next couple of years doing course material on the side. I reached out to Frontend Masters and just told them, "Hey, I've been doing courses for Egghead." I actually met Marc Grabanski at a conference a couple of years before. And so, we established a little bit of relationship. And I just said, "Hey, I want to come and teach there." So, I taught at Frontend Masters. I started putting on my own workshops at conferences. In fact, just a few months after graduating, I got accepted to speak at a conference. And only after I was accepted did I realize it was in Sweden [laughter]. I didn't think to look where in the world this conference was. So, that was my first international trip, actually, and I ended up speaking there. I gave, actually, two talks. One of them was a three-hour talk. WILL: Whoa. KENT: Which was, yeah, that was wild. WILL: [laughs] KENT: And then, yeah, I gave a two-day workshop for them. And then, I flew straight from there to Amsterdam to give another talk and also do a live in-person podcast, which I'd been running called ngAir, an Angular podcast. It just kept on building from there until finally, I created testingjavascript.com. And that was when I realized, oh, okay, so this isn't just a thing I can use to pay my mortgage, and that's nice. This is, like, a thing I can do full-time. Because I made more with Testing JavaScript than I made from my PayPal salary. WILL: Oh wow. KENT: I was like, oh, I don't need both of these things. I would rather work half as much one full-time job; that's what I want, one full-time job and make enough to take care of my family. And I prefer teaching. So, that's when I left PayPal was when I released Testing JavaScript. WILL: Wow. So, for me, I think so many times the imposter syndrome comes up whenever I want to teach or do things at the level you're saying you're doing. Because I love teaching. I love mentoring. I remember when I came into development, it was hard. I had to find the right person to help me mentor. So now, I almost made a vow to myself that if someone wants to learn and they're willing to put in the energy, I'm going to sit down however long it takes to help them because I remember how hard it was for me whenever I was doing it. So, you said in 2014, you were only a couple years doing development. How did you overcome impostor syndrome to stand in front of people, teach, go around the world, and give talks and podcasts? Like, how did you do that portion? KENT: Part of it is a certain level of hubris like I said. Like, you just have to be willing to believe that somebody's going to care. You know, the other part of it is, it's a secret to getting really, really good at something. They sometimes will say, like, those who can't do teach. That's total baloney because it requires a lot of being able to do to get you in a position where you can teach effectively. But the process of teaching makes you better at the process of doing as well. It's how you solidify your experience as a whatever. So, if you're a cook, you're really good at that; you will get better by teaching other people how to cook. There's an element of selfishness in what I do. I just want to get really, really good at this, and so I'm going to teach people so that I can. So yeah, I think there's got to be also, like, a little bit of thick skin, too, because people are going to maybe not like what you have to share or think that you're posing or whatever. Learn how to let that slide off you a little bit. But another thing is, like, as far as that's concerned, just being really honest about what your skill set is. So, if somebody asks me a question about GraphQL, I'm going to tell them, "Well, I did use GraphQL at PayPal, but I was pretty limited. And so, I don't have a lot of experience with that," and then I'll answer their question. And so, like, communicating your limitations of knowledge effectively and being okay being judged by people because they're going to judge you. It just is the way it is. So, you just have to learn how to cope well with that. There are definitely some times where I felt like I was in over my head on some subjects or I was involved in a conversation I had no business being there. I actually felt that a lot when I was sent as PayPal's delegate to the TC39 meetings. Wow, what am I doing here? I've only been in the industry for, like, two or three years at [laughter] that point. It takes a certain level of confidence in your own abilities. But also, like, being realistic about your inexperience as well, I think, is important too. WILL: Yeah, I know that you had a lot of success, and I want to cover that next. But were there any failures when you were doing those teaching moments? KENT: Years ago, Babel was still a new thing that everybody was using to compile their JavaScript with new syntax features down to JavaScript that the browser could run. There was ES Modules that was introduced, and lots of us were doing global window object stuff. And then we moved to, like, defining your dependencies with r.js or RequireJS. And then, there was CommonJS, and Universal Module Definition, and that sort of thing. So, ECMAScript modules were very exciting. Like, people were really interested in that. And so, Babel added support to it. It would compile from the module syntax down to whatever you wanted: CommonJS or...well, I'm pretty sure it could compile to RequireJS, but I compiled it to CommonJS. And so, there was a...yeah, I would say it's a bug in Babel at that time, where it would allow you to write your ES modules in a way that was not actually spec-compliant. It was incorrect. So, I would say export default some object, and then in another module, I would say import. And then, I'd select properties off of the object that I exported, that default I exported. That was allowed by Babel, but it is superduper, not how ECMAScript modules work. Well, the problem is that I taught, like, a ton of people how to use ECMAScript modules this way. And when I realized that I was mistaken, it was just, like, a knife to the heart because I was, like, I taught so many people this wrong thing. And so, I wrote a blog post about it. I gave a big, long talk titled “More Than You Want to Know About ECMAScript Modules,” where I talk about that with many other things as well. And so, yeah, just trying to do my part to make up for the mistake that I made. So yes, I definitely have had mistakes like that. There's also, like, the aspect that technology moves at a rapid pace. And so, I have old things that I would show people how to do, which they still work just as well as they worked back then. But I wouldn't recommend doing it that way because we have better ways now. For some people, the old way to do it is the only way they can do it based on the constraints they have and the tools that they're using and stuff. And so, it's not, like, it's not valuable at all. But it is a struggle to make sure that people understand that, like, this is the way that you do it if you have to do it this way, but, like, we've got better ways. WILL: I'm glad you shared that because it helps. And I love how you say it: when I make a mistake, I own up to it and let everyone know, "Hey, I made a mistake. Let's correct it and move on." So, I really like that. KENT: Yeah, 100%. MID-ROLL AD: Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features? We know maintaining your own servers can be costly and that it's easy for spending creep to sneak in when your team isn't looking. By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer. Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops. WILL: I want to go back to what you were saying. When you left PayPal, you released Testing JavaScript. How did you come up with the idea to write a Testing JavaScript course? And, two, how long did it take to take off and be successful? KENT: That was a pretty special thing, honestly. In 2018, I had put together a bunch of workshops related to testing. There was this conference called Assert(js) that invited me to come, taught them. In the year prior, I went to Midwest JS and taught how to test React. I had this material about testing. I'd gotten into testing just because of open-source stuff. I didn't want to have to manually go through all my stuff again every time I wanted to check for breakages and stuff, so that got me into testing. And whatever I'm into is what I'm going to teach. So, I started teaching that testing. And then my friend, Ryan Florence, put together...he separated from Michael Jackson with React Training, and built his own thing called Workshop.me. He asked me to join up with him. And he would, like, put together these workshops for me, and I would just...my job was just to show up and teach. And so, I did that. I have a picture, actually, in this blog post, The 2010s Decade in Review, of me in front of 60 people at a two-day workshop at Trulia in San Francisco. WILL: Oh, wow. KENT: And this is where I was teaching my testing workshop. Well, what's interesting about that photo is that two weeks before that, I had gotten really frustrated with the tool that everybody uses or used at the time for testing React, and that was Enzyme. And so I was preparing this workshop or working on it. I had already delivered it a number of times, but I was working on it, improving it, as I always do [laughs] when I'm preparing. WILL: [laughs] KENT: I can never give the same workshop twice, I guess. And I was just so frustrated that Enzyme was so difficult to work with. And, like, I was going to prepare this document that said, "Here are all the things you should never do with Enzyme. Like, Enzyme encourages you to do these things; you should not do these things. And let me explain why." And I just hated that I needed a document like that. And so, I tweeted, "I'm seriously starting to think that I should make my own very small testing lib and drop Enzyme entirely. Most of Enzyme's features are not at all useful and many damaging to my test bases. I'd rather have something smaller that encourages better practices." And so, I tweeted that March 15th, 2018. I did that. I did exactly that. What I often do in my workshops is I try to build the abstraction that we're going to use so that you can use it better. So, I was, like, building Enzyme, and I realized the jump between what I had built, the little utilities that I had built as part of the workshop, from that to Enzyme was just a huge leap. And so, I thought, you know what? These utilities that I have built to teach Enzyme are actually really good. What if I just turned that into a testing utility? And that became Testing Library, which, fast forward to today, is the number one testing library for React. And it's recommended for testing React, and Vue, and Angular. The ideas that are in Testing Library got adopted by Playwright. If you're writing tests for anything in the browser, you are very likely using something that was either originally developed by me or inspired by the work that I did. And it all came from that testing workshop that I was working on. So, with that, I had not only that testing workshop; I had a number of other workshops around testing. And so I approached Joel Hooks from Egghead.io. I say, "Hey, I'm getting ready to record a bunch of Egghead courses. I've got, like, six or seven courses I want to do." And he'd seen my work before, you know, I was a very productive course creator. And he said, "Hey, how about we, you know, we've been thinking about doing this special thing. How about we make a website just dedicated to your courses?" And I said, "That sounds great." I was a little bit apprehensive because I knew that putting stuff on Egghead meant that I had, like, a built-in audience and everything that was on Egghead, so this would be really the first time of me just branching out with video material on my own. Because, otherwise, if it wasn't Egghead, it was Frontend Masters, and there was the built-in audience there. But yeah, we decided to go for it. And we released it in, I think, November. And it was that first week...which is always when you make the most is during the launch period. But that launch week, I made more than my PayPal salary for the entire year. And so, that was when I realized, oh, yeah, okay, let's go full-time on this because I don't need two PayPal salaries. I just need one. And then I can spend more time with my family and stuff. And especially as the kids are getting older, they're staying up later, and I want to hang out with them instead of with my computer at night [laughter], and so... WILL: I love how you explain that because I came in around 2018, 2019. And I remember Enzyme, and it was so confusing, so hard to work with, especially for, you know, a junior dev that's just trying to figure it out. And I remember Testing JavaScript and then using that library, and it was just so much easier to, like, grab whatever you needed to grab. Those utils made the biggest difference, and still today, they make a huge difference. So yes, I just resonate with what you're saying. That's amazing. KENT: Aw, thank you so much. WILL: Yeah. You did Testing JavaScript. And then what was your next course that you did? KENT: I quit PayPal, go full-time teaching. That first year, I actually did an update to Testing JavaScript. There were a couple of changes in Testing Library and other things that I needed to update it for. And then I started working on Epic React. So, while I was doing all this testing stuff, I was also very into React, creating a bunch of workshops around that. I was invited to speak all over the world to talk about React. And I had a couple of workshops already for React. So, I was invited to give workshops at these conferences about React. And so, I thought, you know, let's do this again, and we'll do it with React this time. The other thing was, I'd never really planned on being the testing guy. It just kind of happened, and I actually didn't really like it either. I wanted to be more broad than just testing. So, that kind of motivated me to say, hey, let's do something with React to be a little bit more broad. Yeah, so I worked on putting those workshops together and delivered them remotely. And then, yeah, COVID hit, and just really messed everything up [laughs] really bad. So, I had everything done on my end for Epic React by March of 2020, which is, like, immediately after COVID got started, in the U.S. at least. And so, yeah, then we actually didn't end up releasing Epic React until October that year, which, honestly [laughs], was a little bit frustrating for me because I was like, "Hey, guys, I have recorded all the videos and everything. Can we get this released?" But, like, that just was a really rough year for everybody. But yeah, so Egghead got the site put together. I did a bunch of interviews and stuff. And then we launched in October of 2020. That was way bigger than Testing JavaScript because Testing JavaScript was still very informed by my experience as an Egghead instructor, which, typically, the Egghead courses are, like, a video where watch me do this thing, and then you'll learn something and go apply it to your own stuff. And that's kind of what Testing JavaScript was built as. But as part of the update of Testing JavaScript in 2019, I added another workshop module called Testing Node Applications. And in that one, I decided, hey, typically, I would have a workshop version of my material and a course version. The workshop version had like instructions and exercises. And the course version was no instructions or anything. It was just, like, watch these videos. And it was just me doing the exercises. And with the update of Testing JavaScript, I added that Testing Node workshop, and I said, hey, what if we just, like, embrace the fact that these are exercises, and it's just, like, me recording the workshop? How I would deliver the workshop? And so, I tested that out, and that went really well. And so, I doubled down on that with Epic React. And I said, okay, now, this isn't just, like, watch these videos. This is a do the exercise and then watch me do the exercise. So, Epic React was not only a lot more material but the format of the material was more geared for retention and true practice and learning. And so, Epic React ended up doing much better than Testing JavaScript, and even still, is still doing a remarkable job as far as course material is concerned. And, like, so many people are getting a lot of really great knowledge from Epic React. So yeah, very gratifying to have that. WILL: Once again, I've used Epic React. It's taught me so many...stretched me. And I do like the format, so yes, I totally agree with that, yeah. The next thing, Remix, correct? KENT: Yeah. So, how I got into Remix, around the same time we finished recording Epic React videos, I was doing some other stuff kind of to keep content going and stuff while we were waiting to launch Epic React. And around that same time, my friend Ryan Florence and Michael Jackson––they were doing the React training thing. And so, we were technically competitors. Like I said, Ryan and I kind of joined forces temporarily for his Workshop Me thing, but that didn't end up working out very well. And Michael really wanted Ryan back, and so they got back together. And their React training business went way better than it had before. They were hiring people and all sorts of stuff. And then, a training business that focuses on in-person training just doesn't do very well when COVID comes around. And so, they ended up having to lay off everybody and tried to figure out, okay, now what are we going to do? Our income has gone overnight. This is a bit of a simplification. But they decided to build software and get paid for it like one does. So, they started building Remix. Ryan, actually, around that time, moved back to Utah. He and I would hang out sometimes, and he would share what he was working on with Michael. We would do, like, Zoom calls and stuff, too. I just got really excited about what they were working on. I could see the foundation was really solid, and I thought it was awesome. But I was still working on Epic React. I end up launching Epic React. He launches Remix the very next month as a developer preview thing. Yeah, it definitely...it looked a lot like current Remix in some ways but very, very different in lots of others. But I was super hooked on that. And so, I paid for the developer preview and started developing my website with it. And around the next year in August, I was getting close to finishing my website. My website is, like, pretty legit. If you haven't gone to kentcdodds.com. Yet, it is cooler than you think it is. There's a lot that goes into that website. So, I had a team help me with the product planning and getting illustrations and had somebody help me implement the designs and all that stuff. It was a pretty big project. And then, by August of 2021, Ryan and I were talking, and I said, "Hey, listen, I want to update Epic React to use Remix because I just think that is the best way to build React applications. But I have this little problem where Remix is a paid framework. That's just going to really reduce the number of people who are interested in learning what I have to teach. And on top of that, like, it just makes it difficult for people to test things out." And so, he, around that time, was like, "Hey, just hold off a little bit. We've got some announcements." And so, I think it was September when they announced that they'd raised VC money and they were going to make Remix open source. That was when Ryan said, "Hey, listen, Kent, I think that it's awesome you want to update Epic React to use Remix. But the problem is that Remix isn't even 1.0 yet. The community is super small. It needs a lot of help. If you release a course on Remix right now, then you're not going to get any attention because, like, nobody even knows what it is." So, part of me is like, yeah, that's true. But also, the other part of me is like, how do people find out what it is [laughs] unless there's, like, material about it? But he was right. And he said, "Listen, we've got a bunch of VC money. I've always wanted to work with you. How about we just hire you? And you can be a full-time teacher about Remix. But you don't have to charge anything. You just, like, make a bunch of stuff for free about Remix." I said, "That sounds great. But, you know, to make that worth my while because I'm really happy with what I'm doing with this teaching thing, like, I'm going to need a lot of Remix." And so, Michael Jackson was like, "How about we just make you a co-founder, and we give you a lot of Remix?" And I said, "Okay, let's do this." And so I jumped on board with them as a year-delayed co-founder. I guess that's pretty common. But, like, that felt kind of weird to me [laughs] to be called a co-founder. But yeah, so I joined up with them. I worked on documentation a little bit, mostly community building. I ran Remix Conf. Shopify was interested in what we were doing. And we were interested in what Shopify was doing because, at the time, they were working on Hydrogen, which was one of the early adopters of React Server Components. And, of course, everybody was interested in whether Remix was going to be adding support for server components. And Ryan put together a couple of experiments and found out that server components were nowhere near ready. And we could do better than server components could as of, you know, the time that he wrote the blog posts, like, two years ago. So, Hydrogen was working with server components. And I put us in touch with the Hydrogen team—I think it was me—to, like, talk with the Hydrogen team about, like, "Hey, how about instead of spending all this time building your own framework, you just build on top of Remix then you can, you know, make your Shopify starter projects just, like, a really thin layer on top of Remix and people will love it? And this is very important to us because we need to get users, especially really big and high profile users, so people will take us seriously." And so, we have this meeting. They fly a bunch of their people out to Salt Lake. They're asking us questions. We're asking them questions and saying, "Hey, listen, this is why server components are just not going to work out for you." Well, apparently, they didn't listen to us. It felt like they were just like, "No, we're highly invested in this. We've already sunk all this cost into this, but we're going to keep going." And they did end up shipping Hydrogen version 1 on top of server components, which I just thought was a big mistake. And it wasn't too long after that they came back and said, "Hey, we're kind of interested in having you guys join Shopify." So, right after Remix Conf, I go up into Michael's room at the hotel with Ryan. And they say, "Hey, listen, Kent, we're talking with Shopify about selling Remix and joining Shopify," and kind of bounced back and forth on whether we wanted to do it. All of us were just not sure. Because when I joined Remix, I was thinking, okay, we're going to build something, and it's going to be huge. This is going to be bigger than Vercel, like multibillion-dollar company. So, I really kind of struggled with thinking, hey, we're selling out. Like, we're just getting started here. So, Ryan and I ended up at RenderATL in Atlanta at that conference. We were both speaking there. And Ryan didn't fill out the right form. So, he actually didn't have a hotel room [laughs], and so he ended up staying in my room. I intentionally always get a double bedroom just in case somebody needs to stay with me because somebody did that for me once, and I just...it was really nice of them. So, I've always done that since. And so, I said, "Yeah, Ryan, you can stay with me." And so, we spent just a ton of time together. And this was all while we were trying to decide what to do with Shopify. And we had a lot of conversations about, like, what do we want for Remix in the future? And it was there that I realized, oh if I want to take this to, like, multi-billion dollar valuation, I've got to do things that I am not at all interested in doing. Like, you've got to build a business that is worth that much money and do business-related things. On top of all of that, to get any money out of it...because I just had a percentage of the company, not actually any money. There was no stock. So, the only way you can get money out of a situation like that is if you have a liquidation event like an IPO, which sounds, like, awful—I [laughs] would hate to go through an IP0—or you have to be bought. And if you're worth $2 billion, or 3, or whatever, who can buy you? There's almost nobody who can buy you at that valuation. Do you really want to outprice anybody that could possibly buy you? And then, on top of that, to get there, that's, like, a decade worth of your life of working really superduper hard to get to that point, and there's no guarantee. Ryan would always say a bird in the hand is worth two in the bush. He was saying Shopify is a bird in the hand, and we do not know what the future holds. And so, we were all finally convinced that, yeah, we want to sell, and so we decided, yeah, let's sell. And as the sale date grew closer, I was getting excited because I was like, oh, I can be back on the TC39 because Shopify is, like, I don't know if they're actually sending delegates to the TC39, but I'm sure that they would be interested if I ask them to, like, "Hey, let's be involved in the evolution of JavaScript." And I know they're on the Web Working Group. Like, they're on a bunch of different committees and stuff. And I just thought it'd be really cool to get involved in the web platform again. And then, on top of that, I just thought, you know what? I'll just spend all my time teaching Shopify developers how to use Remix. That sounds like a lot of fun. As things drew closer, I got more and more uneasy about that. And I thought, you know, I could probably do just as well for myself by going full-time teacher again. I've done this thing before. I just really like being a teacher and, like, having total control over everything that I do. And if I work at Shopify, they're going to tell me, "Hey, you need to, like, do this, and that, and the other." And I don't know if I want to go back to that. And so, I decided, this is awesome. Super, super good job, folks. I think I've done everything for you that you need me to do. I'm going to bail out. And so, yeah, Shopify wasn't super jazzed about that. But the deal went through anyway. And that's how I ended my time at Shopify. WILL: I love it. It's lining up perfectly because you say you left Shopify to go back doing more teaching. And then you released another course; that's Epic Web, correct? KENT: Right. That was the reason I left Shopify or I didn't join up with Shopify is because I wanted to work on Epic Web. In this 2010s blog post, one of the last things that I mention...toward the bottom, there's a section, KCD EDU, which is basically, like, I wanted to help someone go from zero to my level as an engineer in a single place where I teach just all of the things that I can teach to get somebody there. And so I wanted to call it KCD EDU, but I guess you have to be an accredited university to get that domain or something. But that was the idea. Erin Fox, back in 2020 she said, "I'm expecting you to announce your online Kent C. Dodds engineering bootcamp." And I replied, "I'm planning on doing this, no joke." So, I've been wanting to do this for a really long time. And so, leaving Remix was like, yeah, this is what I'm going to go do. I'm going to go build KCD EDU. And I was talking with Ryan at some point about, like, what I was planning on doing in the future. And something he said or something I said in that conversation made me realize, oh, shoot, I want to build Epic Web Dev. So, I've got Epic React. I don't want Epic Remix. I want people to, like, be web developers. Remix is just, like, an implementation detail. And so, I went and I was relieved to find that the domain was still available: epicweb.dev, and so I bought that. And so, I was always planning on, like, even while I was at Remix, eventually, I would leave Remix and go build Epic Web Dev. So, that's what I did. Starting in August, I decided, okay, how about this: I will build a legit real-world web application, and then I will use that to teach people how to build legit real-world web applications from start to finish. If it's included as, like, knowledge you would need to build this web app, then that's knowledge you need to be able to build a full-stack application. That was the idea. So, I started live streaming in, like, August or September, and I would live stream almost everyday development of this web app. So, people can go and watch those on my YouTube channel. I would livestream for, like, sometimes six hours at a time with breaks every 45 minutes. So, I'd just put it on a break slide, go for a quick walk, or take a drink, whatever, and then I would come back. And I would just, like, so much development and live streaming for a long time. Once I got, like, in a pretty good place with that, the app I was building was called Rocket Rental. It's like Airbnb for rocket ships. So, you could rent, like, your own rocket ship to other people to fly. So, it had to be, like, realistic enough that, like, you could relate it to whatever you were building but not realistic enough that people would actually think it was a real product [laughs]. I worked with Egghead again. They actually have a sister company now called Skill Recordings that's responsible for these types of products. And so, I was working with Skill Recordings on, like, they would get me designs. And then I would, like, work with other people to help implement some of those designs. And then, I started working on turning this stuff into workshops. And with Epic React, we have this workshop app that you run locally so that you can work in your own editor, in your own environment, and with your own editor plugins and all that stuff. I want you to practice the way that you're going to actually exercise that practice when you're done––when you're working at work. And so we have this workshop app with Epic React. Well, that was built with Create React app, very limited on what you could do. And so, I started working on a new workshop app that I just called KCD Shop, that was built with Remix. And so, now we've got a bunch of server-side stuff we can do. And this server side is running on your machine. And so, so much stuff that I can do with this thing. One of the big challenges with Epic React was that the video you watch is on epicreact.dev, but the exercises you run are on localhost. And so, you have to keep those things in sync. You'd see, okay, I'm in exercise one on the videos. Let me go find exercise one in the app and then find the file exercise one. So, you've got, like, three different things you've got to keep in sync. And so, with the workshop app for Epic Web, I said, how about we make it so that we can embed the video into the app? And so, you just have localhost running, and you see the video right above the instructions for the exercise. And so, you watch the video that kind of introduces the problem that you're going to be doing, and then you read the instructions. And then we can also make it so that we have links you can click or buttons you can click in the app that will open your editor exactly where you're supposed to go. So you don't have to keep anything in sync. You go to the app, and you watch the video. You read the instructions. You click this button. It opens your editor. And so, that's exactly what I did. And it's an amazing experience. It is phenomenal, not just for the workshop learners but for me, as a workshop developer, like, creating the workshop––it's just been phenomenal. Because, like, we also have this diff view where you can see the difference between your work in progress and the solution. So, if you get stuck, then it's very easy to see where you went wrong. It also means that we can build even very large applications as part of our workshop and our exercise where there are dozens or hundreds of files. And you don't have to worry about finding them because it'll tell you exactly which ones you need to be working in, so all sorts of really, really cool things. So, this workshop app––actually, took a lot of time and effort to build. But now that it's done, like, people are going through it now, and they're just loving it. So, I built the workshop app, I put the first workshop of Rocket Rental into this workshop app, and I delivered it. And I found out very quickly that a full application with all the bells and whistles you'd expect, like, tons of different routes and stuff, was just too much. Even with the workshop app, it was just really pretty difficult for people to gain enough context around what they were building to be effective. So, I was concerned about that. But then, around the same time, I started realizing that I had a marketing problem. And that is that with Testing JavaScript, people know that they're customers because they're like, I'm a JavaScript developer, and I know how to test––boom. I'm a Testing JavaScript customer. With Epic React, I join this company; they're using React; I need to know React, boom. I'm a customer of Epic React. But with something like Epic Web, it's just so broad that, like, yeah, I am a web developer. I just don't know if I'm a customer to Epic Web. Like, is Epic Web for only really advanced people, or is it only for really beginner people? Or is it only for people who are using this set of tools or... Like, it's just a very difficult thing to, like, identify with. And so I wanted to de-emphasize the fact that we used Remix because the fact is that you can walk away from this material and work in a Next.js app or a SvelteKit app and still use so much of the knowledge that you gained in that environment. So, I didn't want to focus on the fact that we're using any particular set of tools because the tools themselves I select them, not only because I think that they are really great tools but also because the knowledge you gain from these tools is very transferable. And I'm going to teach it in a way that's very transferable. That was the plan. But I still had this issue, like, I need people to be able to identify themselves as customers of this thing. So, what I decided to do through some, like, hints and inspiration from other people was how about I turn Rocket Rental into a much simpler app and make that a project starter? And while I was at Remix, actually, I directed the creation of this feature called Remix Stacks. It's basically the CLI allows you to create a Remix app based on a template. I said I can make a Remix Stack out of this, and I called it the Epic Stack. And so, just took all of the concepts that came from Rocket Rental; applied it to a much simpler app. It's just a note-taking app, but it has, like, all of the features that you would need to build in a typical application. So, it's got a database. It's got deployment, GitHub integration. So, you have GitHub Actions to run tests and stuff. It has the tests. It has authentication already implemented, and even two-factor auth, and third-party auth, and file upload, and, like, just tons and tons of stuff built in. And so, people can start a new project and ship that and have a lot of success, like, skip all the basic stuff. So, I presented that at Remix Conf. I wasn't working at Remix anymore, but they asked me to run Remix Conf again, so I did. And I told them, "If I'm running it this year, I'm going to select myself to speak." And I spoke and introduced the Epic Stack there. And then that was when I started to create the workshops based on the Epic Stack. And so, now it was no longer we're going to have workshops to build Rocket Rental; it was we're going to have workshops to build the Epic Stack, with the idea being that if you build the thing, you are able to use it better, like, still following the same pattern I did with Testing JavaScript where we build a framework first. Like, before you start using Jest, we're building Jest and same with Testing Library. We do the same thing with React. Before we bring in React, I teach you how to create DOM nodes yourself and render those to the page and all of that. And so, here with Epic Web, I'm going to teach you how to build the framework that you can use to build applications. So, that is what Epic Web is, it's effectively we're building the Epic Stack. In the process, you learn all about really basic things, like, how do you get styles onto the page all the way to really complex things like, how do you validate a user's email? Or how do you implement two-factor auth? Or how do you create a test database? So, you don't have to mock out the database, but you can still run your test in isolation. Around this time was when my wife and I were trying to become pregnant. And we got the news that we were expecting, and we were super excited. And so, I'm thinking, okay, I've got to ship this thing before the baby comes. Because who knows what happens after this baby comes? So, I am talking with Skill Recordings. I'm saying, "We've got to get this done by October." I think it was May. And so, I was thinking like, okay, I've probably got, like, maybe eight days worth of workshops here. And so, kind of outlined all of the workshops. Like, I know what needs to be included. I know what the end looks like because I've got the Epic Stack. The end is the Epic Stack. The beginning is, like, a brand new create Remix app creation right there. So, I know what the start and the end looks like. I kind of can figure out how much time I need to teach all of that. And I said, "Let's do eight days." And so, we got that scheduled and started selling tickets. And we sold out 30 tickets in just a couple of days, and that's what we originally planned for. I'm like, well, gosh, I can handle 80 people in a workshop. I've done that before, but that's about as far as I go. I don't really like going that much. In fact, online, especially, I only like to go up to, like, 40. But we said, "Hey, let's knock this out of the park." So, we doubled it, and we sold another 30 seats. And so, it was sold out before even the early bird sale was over. So, that was pretty encouraging. The problem was that I hadn't actually developed this material. I'd already given one workshop about testing with Rocket Rental, and I'd given one workshop about the fundamentals with Rocket Rental. But I hadn't done anything of the authentication or, the forms, or data modeling. Also, like, Epic Notes app is different from Rocket Rental. So, I got to rebuild those workshops. Like, the first workshop was going to start in, like, two weeks, maybe three weeks. And so, I'm working on these workshops. And I'm like, I've finished the first workshop, which was going to be a two-day workshop, and so I get that done. And so, that next week, I'm getting close to finished on the forms workshop, and then I start the workshops. And that was when I started to realize, oh, shoot, I am in huge trouble because I have to not only deliver two workshops a week, so that's two days a week that I'm not able to work on the workshops, really. And then also develop the material as I go, which I don't normally do this at all because I just don't like stressing myself out so much. But, like, I'd had this timeline put together, and I'm like, I need to ship this by October. For about five weeks, I worked 80 to 100 hours a week, maybe more, in a row to get those workshops created [laughs]. And I do not recommend this, and I will never do it again. I can tell you this now. I didn't tell anybody at the time because I was worried that people would think, well, geez, is that the type of product you create, like, you're just rushing through this stuff? But I can tell you this safely now because the results speak for themselves. Like, these people loved this stuff. They ate it up. It was so good. I won't do this again. It's not something that I typically do. But it worked. And, like, I put in a crazy amount of work to make this work. People loved it. And yeah, I'm really, really happy with that. The next step, though, so it was eight days' worth of workshops in four weeks. And I realized, as I almost always realize when I'm presenting workshops, that, like, oh my gosh, I have way more material than I have time for. So, by

(Video Podcast available on Spotify and Youtube) In Episode 4, we dive deep with Miško Hevery, the mind behind AngularJS / Angular and Qwik, as he takes us on a journey from his early days in computer engineering to his impactful years at Google. Miško is one of the few to transition from hardware design all the way to frontend development. We go over the significance of testing in software development, the birth and philosophy of AngularJS, scalability, and code performance. Get a unique view into the evolution of frameworks and web tools from both hardware and software perspectives in this interview with Misko! Check out Miško's Frontend Masters courses online here: https://frontendmasters.com/teachers/misko-hevery/ Follow and connect with all things @frontendmasters across social media: Twitter: https://twitter.com/FrontendMasters LinkedIn: https://www.linkedin.com/company/frontend-masters/ Facebook: https://www.facebook.com/FrontendMasters Instagram: https://instagram.com/FrontendMasters Youtube: https://www.youtube.com/@FrontendMasters About Us: Advance your skills with in-depth, modern front-end engineering courses — our 150+ high-quality courses and 18 curated learning paths will guide you from mid-level to senior developer! https://frontendmasters.com/

In this episode, hosts Rob Ocel and Tracy Lee are joined by Chuck Carpenter and Robbie Wagner from the Whiskey Web and Whatnot podcast. They discuss the future of web development, highlighting the industry's shift towards performance-focused development over flashy animations. They explore the longevity of jQuery, the use cases of frameworks like AngularJS and Ember, and the potential for combining components of Ember with Astro. The hosts also touch on the challenges of convincing stakeholders about performance and the need for developers to prioritize foundational web skills. Throughout, Robbie and Chuck share insights from The Whiskey Web and Whatnot podcast, celebrating its 100th episode. Sponsored by This Dot Labs.

Moimi rozmówcami byli Tomek Świstak występujący w roli specjalisty React oraz Dawid Perdek w roli specjalisty Angular. Podczas nagrania staraliśmy się przybliżyć Wam ideę state managmentu w aplikacjach frontowych. Dyskutowaliśmy, czy state management ma w ogóle sens oraz jak zrobić to w taki sposób, by całość była spójna i umożliwiała skalowanie aplikacji. Jeżeli zastanawialiście się, czy global state management jest potrzebny, czy wrzucenie stanu routera do reduxa jest dobrym pomysłem albo jak współdzielić stan aplikacji w przypadku lazy loadingu, zapraszam do wysłuchania odcinka - znajdziecie w nim odpowiedzi na wymienione pytania. Tomek Świstak Senior JavaScript Developer i architekt rozwiązań frontendowych w Synergy Codes. Zaczynał od backendów w .NET, ale szybko przeszedł na frontend, z czasem na Full-Stack JS. Startował z jQuery i AngularJS, aby od 2017 roku pracować głównie z React, z krótkimi przerwami na projekty w Angular, Vue i vanilla JS. W ramach zespołu R&D nadzoruje start nowych projektów. Chętnie dzieli się wiedzą, m.in. na swoim blogu, gdzie porusza tematy algorytmiki i teorii informatyki. Dawid Perdek Principal Developer w Synergy Codes. Większość czasu pracował z Angular'em, ale realizował też projekty z wykorzystaniem React'a i Electron'a. Poza pisaniem kodu prowadzi Gildię Software Delivery, w ramach której badane i udoskonalane są firmowe procesy dotyczące rozwijania oprogramowania. Inicjator. Lubi pracę z ludźmi. Chętnie dzieli się wiedzą zarówno w firmie, jak i poza nią. Ostatnio intensywnie rozwija się w kierunku modelowania i architektury oprogramowania. Linki: Component Store: https://ngrx.io/guide/component-store Introduction to Component Store Part 1:    • Introduction to NgRx Component Store ...   Introduction to Component Store Part 2:    • Introduction to NgRx Component Store ...   State Management in Twitter: https://nicolasgallagher.com/redux-mo... Events/Commands different types: https://blog.nrwl.io/ngrx-patterns-an... NX (different library/project types): https://nx.dev/more-concepts/library-... push vs. pull:    • Async JS - Push czy Pull? - Dwa podej...   blog Tomka: https://swistak.codes Synergy Codes: https://synergycodes.com

Chatting With It Analyst In F1RST, The Technology Branch Of Santander Group, Focused On Front End Architecture And Angular.Js, Software Developer - Jessica Felix (Jesslyneh) from São Paulo, BRAZIL- Jessica Felix said about her work and answered some of my questions. more info- https://www.smartcherrysthoughts.com

On this weeks bug bounty podcast we take a look at a few interesting issues. While they are all patched, there is reason to believe they'd all creep up in other applications too. First up is an RCE due to nested use of an escaped string. Second a fgets loop that doesn't account for long lines. A XML signature verification tool with a deceptive interface, and last a look at how Bash's privileged mode can backfire. Links and vulnerability summaries for this episode are available at: https://dayzerosec.com/podcast/207.html [00:00:00] Introduction [00:00:31] Analysis of Pre-Auth RCE in Sophos Web Appliance [CVE-2023-1671] [00:07:16] Git Arbitrary Configuration Injection [CVE-2023-29007] [00:11:41] Redash SAML Authentication Bypass [00:18:51] Bash Privileged-Mode Vulnerabilities in Parallels Desktop and CDPATH Handling in MacOS [00:29:38] Ambushed by AngularJS: a hidden CSP bypass in Piwik PRO [00:34:37] [cPanel] Finding XSS in a million websites [CVE-2023-29489] [00:35:20] Stored XSS on Snyk Advisor service can allow full fabrication of npm packages health score [CVE-2023-1767] The DAY[0] Podcast episodes are streamed live on Twitch twice a week: -- Mondays at 3:00pm Eastern (Boston) we focus on web and more bug bounty style vulnerabilities -- Tuesdays at 7:00pm Eastern (Boston) we focus on lower-level vulnerabilities and exploits. We are also available on the usual podcast platforms: -- Apple Podcasts: https://podcasts.apple.com/us/podcast/id1484046063 -- Spotify: https://open.spotify.com/show/4NKCxk8aPEuEFuHsEQ9Tdt -- Google Podcasts: https://www.google.com/podcasts?feed=aHR0cHM6Ly9hbmNob3IuZm0vcy9hMTIxYTI0L3BvZGNhc3QvcnNz -- Other audio platforms can be found at https://anchor.fm/dayzerosec You can also join our discord: https://discord.gg/daTxTK9

Today's guest is Sachin Namjoshi, ServiceNow MVP 2018-2023 & ServiceNow SME at GoDaddy. Founded in 1997, GoDaddy is the world's largest services platform for entrepreneurs around the globe.  GoDaddy is the place folks come to name their idea, create a compelling brand and a great looking website, attract customers with digital and social marketing, and manage their work. They are on a mission to empower their worldwide community of over 20 million customers and entrepreneurs by giving them all the help and tools they need to grow online. Sachin is a Senior Consultant with more than 15 years of experience in BSM for implementation, integration, customization and upgrade projects on ServiceNow and bmc remedy platforms across life sciences, BFSI, Manufacturing, Retail and banking customers. He joined GoDaddy in 2020 and has developed a Service Portal for HR application using Angular JS, Bootstrap for the company, as well as implementing HR Service Delivery across the enterprise, implementing Employee Document Management and more. In the episode, Sachin talks about: Adding value in the ServiceNow community, Day-to-day role with GoDaddy implementing ServiceNow, How he sees the ServiceNow platform evolving, Managing his time between work and community, Advice to people for getting involved in the ServiceNow community

This week we're talking fresh, faster, and new web frameworks by way of JS Party. Yes, today's show is a web framework sampler because a new batch of web frameworks have emerged. There's always something new happening in the front-end world and JS Party does an amazing job of keeping us up to date. So…what's fresh, faster, and new? The first segment of the show focuses on Deno's Fresh new web framework. Luca Casonato joins Jerod & Feross to talk about Fresh – a next generation web framework, built for speed, reliability, and simplicity. In segment two, AngularJS creator Miško Hevery joins Jerod and KBall to talk about Qwik. He says Qwik is a fundamental rethinking of how a web application should work. And he's attempting to convince Jerod & KBall that the implications of that are BIG. In the last segment, Amal talks with Fred Schott about Astro 1.0. They go deep on how Astro is built to pull content from anywhere and serve it fast with their next-gen island architecture. Plus there's an 8 minute bonus for our ++ subscribers (changelog.com/++). Fred Schott explains Astro Islands and how Astro extracts your UI into smaller, isolated components on the page, and the unused JavaScript gets replaced with lightweight HTML — leading to faster loads and time-to-interactive.

This week we're talking fresh, faster, and new web frameworks by way of JS Party. Yes, today's show is a web framework sampler because a new batch of web frameworks have emerged. There's always something new happening in the front-end world and JS Party does an amazing job of keeping us up to date. So…what's fresh, faster, and new? The first segment of the show focuses on Deno's Fresh new web framework. Luca Casonato joins Jerod & Feross to talk about Fresh – a next generation web framework, built for speed, reliability, and simplicity. In segment two, AngularJS creator Miško Hevery joins Jerod and KBall to talk about Qwik. He says Qwik is a fundamental rethinking of how a web application should work. And he's attempting to convince Jerod & KBall that the implications of that are BIG. In the last segment, Amal talks with Fred Schott about Astro 1.0. They go deep on how Astro is built to pull content from anywhere and serve it fast with their next-gen island architecture. Plus there's an 8 minute bonus for our ++ subscribers (changelog.com/++). Fred Schott explains Astro Islands and how Astro extracts your UI into smaller, isolated components on the page, and the unused JavaScript gets replaced with lightweight HTML — leading to faster loads and time-to-interactive.

Protractor was created in 2013 when AngularJS was the most popular web framework. Back then Protractor was the most visible option for writing E2E automation tests for AngularJS Applications. The ecosystem around JavaScript technologies has been changing continuously, with new tools emerging that afford automation testers with more modern options for writing tests. In this podcast, we'll give you reasons and ways to migrate from Protractor to Cypress since it's one of the best alternatives for E2E testing. Host: Chamal Perera, Senior QA Lead, 99x Speakers: Dilusha Rasangi Kumarage, Senior Lead - Software Quality Engineering, 99x Roshika Gunarathne, Associate Quality Assurance Lead, 99x

AngularJS creator Miško Hevery has a new web framework he wants to tell us about, but he's not pitching just another framework, but with different DX. He says that Qwik is a fundamental rethinking of how a web application should work. And he's here to convince Jerod & KBall that the implications of that are BIG.

AngularJS creator Miško Hevery has a new web framework he wants to tell us about, but he's not pitching just another framework, but with different DX. He says that Qwik is a fundamental rethinking of how a web application should work. And he's here to convince Jerod & KBall that the implications of that are BIG.

Alex Kehaya is a technical entrepreneur capable of developing high level product strategy and communicating technical requirements to engineering teams and key stakeholders. He is Founder at NFT MarketPlace HolaPlex and a Member of the Solana Blockchain. Alex is currently working in the blockchain space and has spent the past several years working as a consultant and entrepreneur with Fortune 500's and startups to accelerate the development of new software products and go-to-market strategies. His work has been featured in Entrepreneur, Forbes, FastCompany, Product Hunt, Pando.com, and several large Medium publications. Core Skills: Market Validation: Leading Fortune 500 companies and startup teams through a data driven customer discovery process to accelerate development of new business models. Working with stakeholders and engineering teams to take products from concept to prototype Marketing and Sales: 8 years of sales experience, and proficiency in Business Development, Facebook Advertising, Content Marketing, Viral Marketing, Influencer Marketing, and PR Full Stack Developer: Proficient in Ruby on Rails, JavaScript, HTML, CSS, and Bootstrap. Experience working with AngularJS, Ionic, and Agile Development. Currently learning Smart Contract Development, Python and ReactJS --- Support this podcast: https://anchor.fm/crypto-hipster-podcast/support

Today Jack and TJ talk with Adam Berg, VP of Engineering at Dubsado.  We discuss an article he wrote based on lessons learned while his place of work was transitioning from AngularJS to React, called starting with How to Set Up Server Side Rendering (SSR) With React, express.js, and esbuild.  We also discuss several of his other articles, including Hey Siri, We're Breaking Up, and 3 Lines of Code Shouldn't Take All Day. Sponsors Top End Devs Raygun | Click here to get started on your free 14-day trial Coaching | Top End Devs Links How to Set Up Server Side Rendering (SSR) With React, express.js, and esbuild | dev/tails dev / tails How to Replace Webpack in Create React App With esbuild  Hey Siri, We're Breaking Up Taking Flight Without a Smart Phone 3 Lines of Code Shouldn't Take All Day Home Twitter: @devtails GitHub: adamjberg Picks Adam- Upload - Season 1 Jack- Micro State Management with React Hooks: Explore custom hooks libraries like Zustand, Jotai, and Valtio to manage global states TJ- Netlify Functions

Alex Kehaya is a technical entrepreneur capable of developing high level product strategy and communicating technical requirements to engineering teams and key stakeholders. He is Founder at NFT MarketPlace HolaPlex and a Member of the Solana Blockchain. Alex is currently working in the blockchain space and has spent the past several years working as a consultant and entrepreneur with Fortune 500's and startups to accelerate the development of new software products and go-to-market strategies. His work has been featured in Entrepreneur, Forbes, FastCompany, Product Hunt, Pando.com, and several large Medium publications. Core Skills: Market Validation: Leading Fortune 500 companies and startup teams through a data driven customer discovery process to accelerate development of new business models. Working with stakeholders and engineering teams to take products from concept to prototype Marketing and Sales: 8 years of sales experience, and proficiency in Business Development, Facebook Advertising, Content Marketing, Viral Marketing, Influencer Marketing, and PR Full Stack Developer: Proficient in Ruby on Rails, JavaScript, HTML, CSS, and Bootstrap. Experience working with AngularJS, Ionic, and Agile Development. Currently learning Smart Contract Development, Python and ReactJS --- Support this podcast: https://anchor.fm/crypto-hipster-podcast/support

How to implement automation in finance. View the full video interview here. Igor Vainberg is Chief Technology Officer at Tipalti. He has been programming professionally since the age of 15. He has worked in many different fields in the industry, from programming embedded systems for fire alarms to writing mobile apps and AngularJS applications. Before Tipalti, Igor worked at mobile chat and communications provider Fring, where he helped develop the server side architecture for a VOIP and video call system to handle communications for millions of users. Before that, he was a developer/architect and team leader in the IDF's intelligence corps. Igor holds a B.Sc. in Software Engineering from the Technion, Israel Institute of Technology.

Alex Kehaya is a technical entrepreneur capable of developing high level product strategy and communicating technical requirements to engineering teams and key stakeholders. He is Founder at NFT MarketPlace HolaPlex and an Advisor for the Solana Blockchain. Alex is currently working in the blockchain space and has spent the past several years working as a consultant and entrepreneur with Fortune 500's and startups to accelerate the development of new software products and go-to-market strategies. His work has been featured in Entrepreneur, Forbes, FastCompany, Product Hunt, Pando.com, and several large Medium publications. Core Skills: Market Validation: Leading Fortune 500 companies and startup teams through a data driven customer discovery process to accelerate development of new business models. Working with stakeholders and engineering teams to take products from concept to prototype Marketing and Sales: 8 years of sales experience, and proficiency in Business Development, Facebook Advertising, Content Marketing, Viral Marketing, Influencer Marketing, and PR Full Stack Developer: Proficient in Ruby on Rails, JavaScript, HTML, CSS, and Bootstrap. Experience working with AngularJS, Ionic, and Agile Development. Currently learning Smart Contract Development, Python and ReactJS Jamil Hasan is a crypto and blockchain focused podcast host at the Irish Tech News and spearheads our weekend content “The Crypto Corner” where he interviews founders, entrepreneurs and global thought leaders. Prior to his endeavors into the crypto-verse in July 2017, Jamil built an impressive career as a data, operations, financial, technology and business analyst and manager in Corporate America, including twelve years at American International Group and its related companies. Since entering the crypto universe, Jamil has been an advisor, entrepreneur, investor and author. His books “Blockchain Ethics: A Bridge to Abundance” (2018) and “Re-Generation X” (2020) not only discuss the benefits of blockchain technology, but also capture Jamil's experience on how he has transitioned from being a loyal yet downsized former corporate employee to a self sovereign individual. With over one hundred podcasts under his belt since he joined our team in February 2021, and with four years of experience both managing his own crypto portfolio and providing crypto guidance and counsel to select clients, Jamil continues to seek opportunities to help others navigate this still nascent industry. Jamil's primary focus outside of podcast hosting is helping former corporate employees gain the necessary skills and vision to build their own crypto portfolios and create wealth for the long-term.

Hossein Mousavi shares his methodology to angular form by presenting his template driven approach vs. reactive form approach. They also discuss the differences between form control, form group, and form array, and how you can build upon the elements within Angular through modular patterns and object-oriented project paradigms. Finally, they discuss how the Angie directive allows you to create web applications by routing requests to controllers and directives and referencing data models in a fashion similar to how you would use AngularJS. Sponsors Top End Devs (https://topenddevs.com/) Raygun | Click here to get started on your free 14-day trial (https://raygun.com/?utm_medium=podcast&utm_source=adventuresangular&utm_campaign=devchat&utm_content=homepage) Coaching | Top End Devs (https://topenddevs.com/coaching) Links Hossein Mousavi (https://www.hmousavi.dev/) Picks Charles – GamePigeon (https://apps.apple.com/us/app/gamepigeon/id1124197642) Charles – Digital Ocean (https://www.digitalocean.com/) Hossein – Clusterduck (https://play.google.com/store/apps/details?id=com.pikpok.wtd.play&hl=en_US&gl=US) Hossein – Netlify (https://www.netlify.com/) Special Guest: Hossein Mousavi .

Hossein Mousavi shares his methodology to angular form by presenting his template driven approach vs. reactive form approach. They also discuss the differences between form control, form group, and form array, and how you can build upon the elements within Angular through modular patterns and object-oriented project paradigms. Finally, they discuss how the Angie directive allows you to create web applications by routing requests to controllers and directives and referencing data models in a fashion similar to how you would use AngularJS. Sponsors Top End Devs (https://topenddevs.com/) Raygun | Click here to get started on your free 14-day trial (https://raygun.com/?utm_medium=podcast&utm_source=adventuresangular&utm_campaign=devchat&utm_content=homepage) Coaching | Top End Devs (https://topenddevs.com/coaching) Links Hossein Mousavi (https://www.hmousavi.dev/) Picks Charles – GamePigeon (https://apps.apple.com/us/app/gamepigeon/id1124197642) Charles – Digital Ocean (https://www.digitalocean.com/) Hossein – Clusterduck (https://play.google.com/store/apps/details?id=com.pikpok.wtd.play&hl=en_US&gl=US) Hossein – Netlify (https://www.netlify.com/) Special Guest: Hossein Mousavi .

44bits 팟캐스트 139번째 로그에서는 44bits 운영, faker-js 이슈, AngularJS 지원 종료에 대해서 이야기를 나누었습니다.

44bits 팟캐스트 139번째 로그에서는 44bits 운영, faker-js 이슈, AngularJS 지원 종료에 대해서 이야기를 나누었습니다. 참가자: @raccoonyy, @outsideris, @nacyo_t, @seapy 정기 후원 - 44bits podcast are creating 프로그래머들의 팟캐스트 녹음일 2022년 1월 21일, 공개일 2022년 3월 13일 쇼노트: https://stdout.fm/139/ 주제별 바로 듣기 00:00 시작

Our guest today didn't start out passionate about office space and property, but he did have a passion for solving problems by building startups. The problem he discovered was that office space is filling wildly different roles in our lives today and that people need flexibility and choice when it comes to hybrid work. So he decided to build a platform to solve it (originally written in AngularJS, if you can believe that). In this episode, we interview Forbes 30 Under 30 Tom Watson, Co-Founder & former CTO at Hubble and Mentor at Seedcamp, about his first startup, why he encourages founders to tinker, and his future plans. Join us as we discuss: - How Tom discovered a passion for the office space marketplace - What landing the Series A was like - His time as CTO and why he's former CTO now - The details of how he built what became the Hubble platform - Why Tom would probably start a bakery before working for Google Keep connected with The Agile CTO at Apple Podcasts, Spotify, or our website. Listening on a desktop & can't see the links? Just search for The Agile CTO in your favorite podcast player.

For last 8-years, Ben Nadel has poured his heart and soul into InVision, a product that drives design collaboration. During this period, his area of expertise has focused on the (now named) "legacy" platform - the ColdFusion and AngularJS monolith that has built the business into what it is today. Soon, however, the "legacy" platform will be wholly subsumed by the "modern" platform - a distributed, microservices architecture built on Go, Node.js, and React.In today's episode, Ben opens up about the emotional struggle that he's facing as his role on the legacy platform comes to a end. He wonders what it's going to be like to start over; to go from a big fish in a CFML pond to a novice in a Go ocean; and, to find a way to not feel like a complete failure when his productivity drops significantly.One of the scariest things for Ben is that he's not sure if he'll be able to trust his gut. While the fundamentals of programming will certainly transfer from the legacy platform over to the modern platform, it's hard to know if future "feelings" will be true indicators of potential problems. Or, if it's just a byproduct of his lack of familiarity with the new architecture and language constructs.Only time will tell. And, until then, he intends to grind hard and deliver as much value as he possibly can on the legacy platform while he still has time and the skills necessary to get the job done.ASIDE: While not mentioned by name in the show, Travis Heinström - the SVP of Engineering at InVision - is the person who wanted to make sure that Ben has all the room he needs to "feel his feelings" when the legacy platform is shut down. This is perhaps one of the most emotionally-intelligent things that Ben has ever heard a manager ask about.Notes & LinksFollow the show! Our website is workingcode.dev and we're @WorkingCodePod on Twitter and Instagram. Or, leave us a message at (512) 253-2633‬ (that's 512-253-CODE). New episodes drop weekly on Wednesday.And, if you're feeling the love, support us on Patreon.With audio editing and engineering by ZCross Media.

This week, the crew talks about Clean Code: A Handbook of Agile Software Craftsmanship by Robert Martin (aka, "Uncle Bob"). Recommended to us by friend-of-the-show Adam Cameron, this book outlines a series of "best practices" that programmers can use in order to create applications that are easy to understand and easy to maintain. Just imagine if applications became easier to understand over time - not harder; that is the goal of this book.A lot of the approaches feel obvious once you see them articulated. However, they're not always easy to apply in your own applications. And, some of the practices feel at odds with each other. For example, sometimes we want small, reusable classes that "do only one thing"; and, sometimes, we want a large mama-jama class that has 2,000 lines of code in it because it's the very collocation of the logic that makes that class maintainable.And, of course, we don't all agree on all the concepts. But, that's what makes the discussion so much fun!Triumphs & FailuresAdam's Triumph - Adam's son broke both of his wrists (what the doctors refer to a "bilateral ouchie") while playing on the monkey-bars. Thankfully, his family has great insurance and lives very close to one of best children's hospitals in the country: the Children's Hospital of Philadelphia. So, while it has been (and will likely be) a rough recovery period, Adam feels like he has much to be thankful for.Ben's Triumph - His big hairy goal for 2021 was supposed to be learning about "Design Systems". But, in the first 4-months of the year, he didn't follow-through on that goal in any way whatsoever However, in just the last few weeks, he's finally started to piece together some reusable components for his AngularJS application. Eventually, he might move to something like Google's Material Design; but, he feels like he needs to "fail first" before he can truly understand the problem that robust Design Systems are solving.Carol's Failure - Despite what felt like an effortless start in her adventure with Amazon AWS, Carol hit a brick-wall while trying to get AWS Lambda to communicate with GMail. After struggling for 3-days to no avail, she finally got in touch with her Google Cloud Account support; and, not even they can figure out why it's not working.Tim's Triumph - While reading Clean Code in preparation for this episode, he's already feeling more cognizant of the way that he's writing his applications. And, things are feeling pretty, pretty, pretty clean.Follow the show! Our website is workingcode.dev and we're @WorkingCodePod on Twitter and Instagram. Or, leave us a message at (512) 253-2633‬ (that's 512-253-CODE). New episodes drop weekly on Wednesday.And, if you're feeling the love, support us on Patreon.

I spoke with Joe Eames. Joe is an educator with over 20 courses published on Pluralsight. When you look at his courses, you will quickly realize that Joe focus a lot on Test Driven Development and Angular. He has also acquired Thinkster a few years back, which is a learning site with courses on front-end development. Joe loves putting together tech events and he is one of the original ng-conf organizers. ng-conf is the most well-known Angular Conference and at the time there was no conference like that in the Angular space. We have explored a bit the challenges of putting together an event like that. Joe also mentioned that nowadays he is a sales engineer as part of a new venture with a friend. They are helping clients with extended support for an older version of Angular called AngularJS. All-in-all, I just had a great time talking to the super nice Joe Eames. Listen to this conversation to understand why Joe says that the things that you don't get paid for are the ones most valuable to you. Enjoy the chat! Full show notes and links: https://SoloCoder.com/82

Angular is a feature-rich and opinionated framework. Opinionated, for example, in terms of fetching data via XHR. Most, and perhaps all, Angular developers reach for the HttpClientModule. Most of us don't have to even think about that decision. While the debate will likely never end over JavaScript frameworks, Angular developers may never end their debate over what forms implementation to use. Do you use reactive forms (which are arguably not really reactive) or template-driven forms? The Angular show panelists want to take you on a learning journey into the depths of this debate in a healthy, fun, and educational way.If you read the Angular documentation you might be inclined to believe that Angular's template-driven forms approach is where you start, but real Angular devs use reactive forms. I mean, the name reactive is hip. And template-driven forms, that's so AngularJS-y. Why would I want to use template-driven forms?We have the perfect guest to answer that question for you. Ward Bell, a Google Developer Expert in Angular and President/Co-Founder at IdeaBlade, has put template-driven forms through its paces for many years, and in our opinion, is one of the foremost experts on using template-driven forms in Angular. Grab your kombucha, coffee, running shoes, or really whatever you want, and join us as we learn from the master on template-driven forms. By the end of the show, you might be asking yourself why you aren't already using template-driven forms in your Angular applications.Bonus notes from Ward after the show:I talked through a couple of approaches during the show but I didn't have an actual sample to refer to... I just updated the StackBlitz sample with an example of both approaches. Color me “obsessive”.https://stackblitz.com/edit/angular-kkatri?file=src%2Fapp%2Fhero-form%2Fhero-form.component.htmlThe hero now has both a “Power” and a “Power Qualifier” (category and subcategory). Both are required. You pick a power and the list of qualifiers changes accordingly. A special “Select a power qualifier” appears until you pick a qualifier. This demonstrates the “disabled control” approach.One of the selectable powers is “Other”. It has no pre-defined qualifiers. Instead, you must enter a free-form description of the “other power”; what you enter is bound to the hero's qualifier field.When you pick “Other”, the “Power Qualifier” selector is removed from the form and a required free-form input control takes its place. This is the alternative “ngIf” approach that I mentioned.Click the “New” button to see how it works when Hero has no power.Show NotesAbstractControl: https://angular.io/api/forms/AbstractControlConnect with us:Aaron Frost - @aaronfrostJennifer Wadella - @likeOMGitsFEDAYBrian Love - @brian_loveWard Bell - @wardbell

Te explico lo fundamental de Angular Framework. Este framework de JavaScript te permite desarrollar aplicaciones web, mobiles, nativas, reactivas y dinámicas. Te hablo de la velocidad, el rendimiento, la escalabilidad y todas las herramientas utilizadas con Angular 11. Explico un poco de su historia y sus partes: módulos, directivas, componentes, data binding, servicios, pipes, routing, y testing.

Buckle your seatbelt folks, this is going to be one heck of a ride. Get ready for episode one of a six-part series on State Management in Angular. That's right, there was no way we could fit the topic into a single episode. Panelists Aaron Frost, Brian Love, and Jennifer Wadella start with defining what exactly is "state" in a client application and why it matters. We then jump into a time machine and travel back to the (good?) ole' days of state management in AngularJS. Remember $scope? What about those long digest cycles? But, have no fear, we'll then race forward in time to the pending release of the modern-framework that is Angular (version 2+).The panelists then welcome Googler Alex Rickabaugh to share how he made his way onto the Angular Team through an internal data fetching/caching project called Streamy. His experience with building Streamy led to working on a PoC Angular project, "Tactical", in an attempt to provide Angular with a State Management+ solution. Tactical aimed to manage data flow, offline, validation, caching, conflicts, and more. While Tactical was never released as an official part of the Angular platform, Alex shares insight into the complexities of state management and building abstract tools to solve the oft-encountered programming problem.But wait, wait... there's more. The panelists then scrub forward in time to hearing about state management evolutions in other frameworks, such as Flux and then Redux. Then, zooming forward even more into the land of Promises and then the revelation (and struggle) of Observables. With all that history and information, you definitely don't want to miss this episode! Come join us on the journey, and definitely don't forget to subscribe to stay caught up on all our future episodes as well!Alex Rickabaugh: @synalx

Well, everyone else is doing a decade in review, so why not Bob & Kevin! Be sure to like, follow, subscribe or whatever the heck you need to do on your podcast listening platform of choice! Help us kick this show into high gear. Follow us on twitter at https://twitter.com/bobandkevinshow and enjoy the show transcript below from our friends at https://otter.ai/ Kevin 0:00 So we're back Holy crap, it's the year 2020 Bob 0:05 I have so much disappointment about the statement of year 2020 I just can't even not really about the year itself or anything that it may or may not bring but you know there's just a lot of bullshit flying around right now about not just New Year new me. new decade new me whatever they're saying. I have no idea. Kevin 0:24 Yeah, this is the time of year when you start thinking, Man, maybe I should lose some weight. And of course, you know, even if you do lose weight, it finds you because the only thing that really works is changing the whole lifestyle thing like I don't know living to a state with mountains and hiking all the time. Hey, let me tell you that doesn't take off wait either, by the way, damn it. Oh, that stinks. So according to Back to the Future to in 1989 in the year 2015. Not only will the Cubs win the World Series, which was almost accurate as off by like one year, but we'd be flying around in our automobiles, Bob, are we there yet? Bob 1:05 Well, depends which call flying around. Yeah, we have some autonomous features and functionality in some of our vehicles. We even kind of have hovery skate boardy things. Not really though. Kevin 1:23 I don't know. So it's been a few weeks since we had a pod. We've had a few holidays. Today, as I saw on the internet is the Monday-ist Thursday of the entire year, and it certainly felt that way. Bob 1:37 This whole holiday break has been the shittiest shitty of anything. You could just fill in the blank Monday, Tuesday, Wednesday, Kevin 1:45 but did you acquire or partake in anything? especially notable over the holidays? Bob 1:54 I had two have my three kids home so that was kind of cool. would have been nice to be 3-for-3 Um, didn't really get any tech related gifts were really minimizing the whole Christmas thing. got this cool piece of artwork though, that I was looking at and my kids noticed that I was looking at it and they bought it for me Kevin 2:12 so awesome. So is it hanging in said, domicile, Bob 2:18 it is prominently displayed in the dining area. It is a collection of hand crafted pine trees they are I think they're created with a arc welder to actually cut out the metal and then uses some kind of patina technique to give them a cool bluish green tint. They're pretty awesome. How Kevin 2:42 about you? Um, yeah, so we are highly evolved. People as a couple my wife and I that is we don't buy each other gifts so usually tend to buy the kids some gifts. We've decided to go on a vacation few weeks after the holiday so that was part of their gift and then The fun thing I got to play with over the last week or so is a vinyl cutter that was not a part of Christmas. It was just one of those things sitting in a box that nobody Bob 3:08 I can't believe you had one of those and no one was using it. That's crazy. Kevin 3:12 Well, my wife's very into scrapbooking and she actually bought it for herself. And then once I learned we had set thing in our possession, boom, started using it and I've already made some stickers and tried screen printing with making it a laser cut stencils, some really cool things you can do. Bob 3:32 So I've seen pictures and some of this stuff looks pretty big. What's that? Like? I don't really know much about vinyl cutters and maybe some of our listeners don't. What? Yeah, but I saw his and hers above your bathroom. That's pretty big. Kevin 3:47 Yeah, so out of the box, so I have the cricket or we have I like it's mine now. Okay, we've got That's beautiful. Yeah, we've got the Cricut Explore air. I'm looking at it here it is on my desk. So possession is nine tenths of the law. So, out of the box, it cuts a 12 by 12 piece of vinyl if you want, and then it goes up to 12 by 24. If you buy a optional mat, which I've totally bought, and then really the sky's the limit because if you need something bigger than that, and you're using cricket, he just basically print it in sections and you put it together. Bob 4:26 So you tile it out. Hmm, Kevin 4:27 yeah, so the his and hers that you can find on my Instagram and or my Twitter account. Yeah. You probably won't go look for it. But I'm just saying the his and hers are one piece each and they are fairly large or like, Bob 4:41 Oh, those are 1pm or one piece each. Yep. So they worked probably on the 12 by 24. Kevin 4:46 Yes, that is correct. And I've since printed, some stickers, some JavaScript stickers. It's great for like laptop stuff. I'm showing Bob here some stickers to the camera. I've made one here for one of my kids. gran starion Yep, and I made him a white and black version. I made a an airborne patch because I was in airborne in the army here this is gonna go to my car and if you notice, what Bob can see is that you can have multiple colors which is really cool. You just layer them on there you cut them in you cut you know one color then you cut the other color then you put them on top of each other. It's pretty cool. Bob 5:23 Is any of this computer driven or is this all manual? Kevin 5:27 Well, the cutting in the designing is all computer driven. Bob 5:46 how much is a cricket runya Kevin 5:48 that's a 200 bucks and there's different versions like version one back in the day you got like Nintendo cartridges. were basically you know you had to buy this cartridge from the local craft store. Plug it in like a video game. Then you get to choose, you know, from an enumerated list of things and is kind of shitty after a while because you're like, but I want to print this custom thing. Oh, here comes version two points version 2.0 is like, hey, we've got this app. And all you basically need is a transparent background. png file. And there we go. And then there's a ton of videos on YouTube to kind of get you going. And holy crap. I'm like, pretty excited. I'm not gonna lie. You appear to be having Bob 6:30 fun with it, because I see lots of pictures. And sorry, you answer you said you're integrating that with your screen printing as well. Kevin 6:37 So yeah, I guess I guess I haven't really talked about screen printing on the show. So I do screen printing. It's kind of like my analog hobby when I just want to get away from the digital world. And so there's many ways to screen printing Bobby, you said you use the screen for maybe you still do, but not still, but used to that there's three primary ways and the first way I I learned was you buy this thing called an emulsion sheet which is pre coated and it's sensitive to sunlight. You print something on a transparency, plop it on top, go out in the sun for a minute, and then you wash it out. And it works actually really well. One drawback there is you can't keep tension on it. So you know, it's guys drawbacks, but it's very easy to burn. The second is the traditional way, which is you, you. Grape, I guess is the right or you go a screen, a traditional screen squeegee the screen. Well, Bob 7:33 now before you get to the squeegee, you kind of said that most of you put the emotion on the squeegee to so Kevin 7:39 well that's the thing I've got. It's like it's called a scoop coder. So you scoop code it and then that's like a Bob 7:45 net sloshing around. Kevin 7:46 You've got to do it in a dark room. So I've had to put together a makeshift dark room and a half and I had to buy red lights and everything. And then I had to build and I'm going to show Bob this. I don't know if you can see it right at the end of my desk here right radio. I know right? The end of my desk is it Hey, this houses my undeveloped screens because it's light sensitive. And so I turn all the lights out usually at night time and then I expose them with UV light. So that's method to method three to bring it back to the cricket is to vinyl cut something and then just apply it right to the screen but you do it in reverse and put it on the bottom side. And then you just squeegee it through. Now I think that's brilliant. Now each way actually has their pros and cons. Do you think that the vinyl cut way is like well, why wouldn't you always do that just less mess easy. The drawback is if you have very fine detail, the vinyl cutter isn't the best solution for that. Really? Yes, you'll want to go traditional in the ocean with the UV light or the or the first method. Bob 8:45 Did I see that you did our logo as a final cut as well did and that turned out Kevin 8:49 really freakin well. So if you want like a car sticker. Oh, that's great. Yes. Bob 8:54 Oh shit. Yeah. Did you remake the did you make the audio waves or was that right from the logo? That Kevin 8:59 is right. Right from the audio, I did not remake anything. Bob 9:02 Damn, that did look good. I'm actually if anyone's interested in checking that out. Did you share that on the show Tweeter, Kevin 9:09 I you know, I have no idea anymore. We have so many accounts, both personal and professional podcasting accounts that it's Bob 9:17 really hard to keep track of super, super professional podcasting accounts. So, um, before we get into the meat of the show, this is kind of like a little transitional thing. Speaking of the show social media. One of the show New Year's resolutions that I've made for myself is to try to be more engaged in the marketing of the show. So I want to share with listeners since we're less than 10 minutes in and maybe most of you are still here, our primary platform appears to be looking back at the 2019 stats, Spotify. So if you are on Spotify, please I think they have a follow button and using that follow button actually subscribe to the podcast but then also helps Spotify algorithm determine where to show our podcast is recommended to some folks that may not have heard us in the past couple years. So that's pretty Kevin 10:12 good do that. That'd be very that's a great resolution. I have traditionally stayed away from resolutions but I did give myself some. So a little more personal info about me. I am a arms dealer of Lego so Bob 10:28 You scared the shit out of me for a second. Kevin 10:31 I buy sell Lego and that's kind of a finicky thing because you know, you just got to pick out the right one then you basically turn around keep them for a while and you sell them but what I learned with that experiences Wow, it is really awesome to make money while you sleep. And I've tried six ways from Sunday to to make money in software like an open source projects making this little library that is that is a tough business. So selling frickin Legos has made Like a million times more money than any software gig I've tried to do on the side, just putting that out there. So the problem with Lego is, is, well, eventually you run out of the good stuff. So I've been into woodworking slash screen printing for the last four or five, six months. And that's where my future efforts are going to continue. And I'm going to open up an Etsy store and I'm going to sell a bunch of woodworking stuff. And I like to really bore the shit out of people by posting all my projects that I have on Instagram often Bob 11:35 No, I love it because I'm not as artistic as I used to be. And it's cool to see you making stuff. I mean, I'm, I'm super engaged with all of my friends that do creative things outside of code. Because I don't do that much creatively outside of code. Well, except maybe podcast. Kevin 11:54 I've definitely I'm at peace with the idea that I'm a creative person, but I don't necessarily have to do In the digital realm, and so I really really, really like balancing my digital creativity with analog creativity. So I played music play guitar, I Bob 12:10 I draw I you know, I fabric Kevin does all the show artwork in case anybody didn't know that. Yes, Kevin 12:16 stick figure art is harder than it looks. Bob 12:21 Especially when you have an annoying co host. It's like, Can you make it look like this? Kevin 12:25 Yes. So yeah, the creativity thing. That's kind of my resolution thing, but in so expect more show swag. Bob and Kevin show branded show swag that you probably can't buy because you probably don't want to buy it. But Bob 12:41 I might have but if you're good listeners and drop us some lines on social media, maybe you'll just could Kevin 12:47 Yeah, Bob 12:48 possibly get some and then Kevin 12:50 I've done a lot of signs that. So confession time Kevin really likes Pinterest and from what I understand That's that's, you know, takes a lot of courage sticks, you know, to say that so I really like Pinterest and I steal all my great woodworking ideas from there. There I said it. Bob 13:10 You use it as your creative Muse you don't steal? Yeah, Kevin 13:13 I liked you could be my marketing manager if this ever goes anywhere. Bob 13:18 I like it. I don't think you're going to need one. I think the shop speaks for itself. Well, alright, so we've talked a little bit about some resolutions. And I think that it's a very popular, hip trendy thing for shows like ours to take a look back at the prior year and technology or whatever the topic of conversation is, but since we did turn that big decade clock, I think we turned the decade clock. I think there's debate on that as well. But everyone's saying we turn the decade clock. So I think we're going to take a little bit of a look back at the the decade in tech. Kevin 13:56 Does that sound about right? Yeah. So the other day, I think we'd agreed upon some ground rules on what should we freakin talk about in our New Year's episode? And you didn't follow any of the ground rules? Oh, we'll see. We'll see. So the rules were that we had to come up with the 10 best and 10 worst things and or releases or objects tech related in the last decade. Right. That was kind of the right rules. Bob 14:22 Yeah. And a little glimpse behind the curtain for those of you who listen, and we probably mentioned this before, this show is not highly scripted at all. And when we do come up with topics like this, we don't share like our our conversations during the day get very awkward because we want to talk about this stuff, but we can't. So I have no idea what Kevin's top 10 and top 10 lists are and he has no idea what mine are. But I'm actually pretty excited to see if there's any overlap at all. In which would be even the most entertaining is if I have something on the good list. He has it on the bad. Or vice versa. Like, Kevin 15:03 it's like the naughty and nice list. Bob 15:05 Yes. So So where do we want to start? Let's hear let's just so I did rank Where did you rank yours? I don't know how heavy my writer rank in descending order from 10 to one, I have two honorable mentions in each category. All right, Kevin 15:19 very good. Let's just give me your 10th best technology of the 2010s. Bob 15:25 What should I do my honorable mentions first because they're outside the top 10? Kevin 15:31 Uh, no. Give me Bob 15:33 the Oh, we're going to close out with those after we get the number one. Yes. So we're doing the positive ones first. Kevin 15:39 Let's go back and forth. So we'll do a best one will do this one and then so Okay. Bob 15:45 All right. So this one is going to be my number 10 of the most positive things and tech from the last decade. For me, I said the rise of music subscription services and the end of the CD and Digital piracy era I key cuz full disclosure, I used to sometimes stumble across music that I didn't own prior to the 2010s Kevin 16:11 that's, that's interesting because look, are you including or maybe you don't want to tell me streaming video as well Bob 16:20 and this this is specifically to get it so so I was kind of looking at personal things so as well as like big industries the Kevin 16:28 streaming is huge and it's such a strange concept to no longer have a tangible piece of music like an album if you are does an album even exist anymore. Bob 16:41 Yeah, actually really cool. hipsters will release their albums on vinyl on very limited release, although it has been increasing in popularity again. But this has been a very big conversation in our house over the holidays to with the digital music, because nobody actually owns the music anymore. So David, for the most part, David Neil Kevin 17:00 Also known as at Reverend geek, he was on one of the early Bob and Kevin show, YouTube additions. He tweeted the other day is like, hey, CDs, it's kind of like an offline version of Spotify just laughed my ass off. So, Bob 17:16 but it's not, though, because the CD doesn't know what you want to hear next. Kevin 17:20 There's no algorithm, Bob 17:22 right? There's no algorithm on the disk. Okay, Kevin 17:25 well, you can burn your own playlist. So I guess there's, there's some in there, Bob 17:29 I know. But think about it. So we went through that evolution where you had a bunch of CDs that you purchased at the store, then you digitize those CDs. And then you took those CDs in major own mix CDs. So think about how much waste we've, Kevin 17:46 I don't know, not prevented, but ceased to create because of this movement, but that or do we just move it because now everything's streamed and you have to create the energy to move the bits each and every time Bob 18:00 Yeah, but the internet was gonna do that anyway. But it Kevin 18:03 didn't need to do this. Pick a song over and over and over and over and over and over again and it never downloads anyway, Bob 18:10 that's what bandwidth is about. Alright, so let me throw that was my number 10. What was yours? Kevin 18:15 My number 10 Best thing was the iPad slash smartphone. So I realized that's a very broad category. Bob 18:23 I like where you're going with that though, because phones have basically become iPads lately. Kevin 18:26 Well, the iPad was released in 2010. And full disclosure, I made a lot of fun of it at the time because I'm like, this is stupid. This will never work. There's no keyboard oh my gosh, why would she do there's no apps you know, live to do them. I was wrong. I am raising my hand for the camera here. I was wrong. And then smartphones themselves I worked at a wireless carrier, a Verizon Wireless carrier, and I was a part of the retail side of moving a bunch of smartphones to the public. I realized the iPhone was invested in 2007. But I really don't think it took off until Android was released, which was in that neighborhood. I'd have to have the internet we don't have and can't afford look that up. But I do remember at the time blackberry happened to be king, Bob 19:17 right? Hey, oh, god, you're gonna laugh so hard. This is the best radio ever got. I can't wait, keep going. Kevin 19:23 Well, I was just gonna mention Whatever happened to hard Qwerty keyboards on the phones. Well, they lost to the soft screen. So what do you think? Bob 19:33 Well, I think that that's a great number 10 for the positives. Do you want to hear my number 10 for the negative laid on me. Listeners at home, this is not scripted by number 10 for some of the downside things, I guess this actually could be spent as a positive people who should not have been making phones like Facebook, Amazon, BlackBerry, and Windows Phone Those are all really bad smartphones of the 20. Kevin 20:04 Well, I allow me to split hairs. blackberry was the jam. So if you want a corporate email on your phone, Blackberry was it. I mean, even President Obama was like, give me my crackberry Bob 20:19 it was, but very early on in the 2010s. blackberry was already in the throes of like the death throes the last twitches of life where they came out with their tablet. I can't remember what they called it, but it was you know, they were trying to revive their, their smartphone presence and they just couldn't do it. So I totally Kevin 20:41 missed by I totally missed Windows Phone but I wouldn't say I missed it. Or do miss it. Blackberry. I think they tried to come out with a soft screen again. Bob, Bob's holding up his Bob 20:54 apparently I my windows 8.1 phone that I still have because it runs like a beat Kevin 21:00 So in Facebook, do they actually have a smartphone? Bob 21:04 So Facebook was toying with the idea of a smartphone and what they did instead of making the hardware, they came out with a basically a flavor of Android that they tried to distribute on pre made devices and, like a lot of Facebook things it didn't. Kevin 21:21 While we're talking Facebook up a quick reminder that my particular version of Android cannot uninstall Facebook. I can only disable it. Thanks, Mark, because I didn't need that 300 mega space on my phone anyway, right. Bob 21:36 I'm gonna make a quick prediction here that Facebook is going to come up in this conversation more than what can I do my Kevin 21:41 number 10 then Hell yeah. Number 10. Worst thing the bad thing was the bad yeah, bad things. Facebook acquires Instagram in 2012 Bob 21:53 Wow, that was still that was wet number 10. For you. Wow. It's it's in this list is gonna get into Kevin 22:00 Yeah the list is young. So yeah so in in 2012 I don't know that any of us including the FTC, or whatever government agency overlords you know, mergers and stuff like that. I don't think they necessarily saw future things like surveillance state 2016 election, Cambridge Analytica, yada yada yada in 2012. So yeah, sure, why not? You got money, they, you can buy them great. And nobody really understood how the filter bubbles and how speech was going to be shaped in 2019 2020. Well, pick a year. Bob 22:38 So you're so funny. God, this is the best. I knew this was going to be great. Kevin 22:42 So what do you think? hasman number 10. Bob 22:46 Number. Yeah, that's very interesting that that's your number 10 because you kind of bit off a lot there. So I'm very curious to hear what 931 are for the bad. Well, Kevin 22:57 yeah, I may have tipped my hand a little bit. But let's let's go with your number nine, what's your number nine. Bob 23:02 Okay thing. So number nine positives. It's funny that you said iPad was your number 10. Number nine for me was the Microsoft Surface Book. Because in the surface the surface line of products from Microsoft, very much along the same lines, full functional computing with detachable screens in still very pop powerful graphics processing and overall CPU not just the GPU so I love my Surface Book. I have one personally and one professionally, and they're talking about getting new machines at work. Luckily, we've already run the disclaimer If not, I'll drop it in here as well. But I don't want a new one. I don't want a new machine. I like my surface. Wow. So Microsoft for as much as they struggle. I feel like in various consumer based hardwares and software's windows 10 and Surface line we're pretty big in the 2010s for me so I think so Kevin 24:04 I've never had a surface but here's what grinds my gears with when with with Microsoft Surface before the Microsoft Surface that you're talking about debuted Microsoft had another surface Do you remember that at all? Bob 24:19 Well, I think they have the I would guess they call it the they don't call it the plain vanilla but they do have just the surface period. And it you know, has a type of cover and Nope, nope, nope. Kevin 24:30 Other surface so in 2011 I went to Indianapolis, Indiana to the Gen Con board game convention. Yeah, nerd alert. Bob 24:40 Right. So we need to alert nerd alert drop right. Kevin 24:44 So back then Microsoft had a product called surface but it was a table that was so thick of the screen is the table top and you can put things on it and it would you know like capacitive touch, you would know what's on it and then they would it was really good. Cool, but they totally went away from that. So, Bob 25:03 yeah, I wish I wish they would go back. Maybe they'll bring it back maybe. All right. Are you ready? So that was my nine, number nine positive. So your number nine positive is Kevin 25:12 Azure, AWS slash cloud, the cloud, all the things now this is cloud computing, cloud computing, right? And this is very near and dear to my like, daily professional life, because one of the worst things that I can imagine as a web developer is on premise hosting. You know, yeah, on one hand, you're like, yeah, I have control the box, I can do whatever. But with AWS and Azure, there's this concept of server less, which, by the way, it's still Bob 25:42 a real server, right? It's in a box, which Kevin 25:44 it's terrible naming when they say server lists it, explaining it to non tech people. Oh, so there's no server. No, there is a server, it's just virtualized. Anyway, I digress. So but it's really changed my day to day job. It's really enabled this thing called DevOps automation, and it's really changed. Like the landscape of everyone because it what it does, what it does is it lowers the bar, you know, expose the CD ends to Joe developer, Jane developer. It does all these things. So you mentioned earlier music streaming, I humbly think that the cloud revolution helped enable the streaming revolution. What do you think? Bob 26:23 Oh, I think so much of that is dead on, you know, physical boxes. Don't really, I mean, I'm sure they exist. I'm sure there's tons of them out there still. But yeah, that platform, the whole idea of that distributed computing that is easily accessible and the, you know, the front end that they've given all that stuff with the front end tool, so it's not all command line stuff. Yeah. It's pretty amazing. Kevin 26:50 Yeah. And AWS started because they basically had an internal need and then they just said, Hey, wouldn't be cool if we just sold some of our capacity. I don't know. Azure has a similar history but I thought that is some of the best ways to create tech you know, create a business which is solve a real problem and then see if you can make it generic and or you know, you know, abstracted if you will, so that was mine. Which guy Bob 27:19 so, we're on so my it's my number nine bad one, right? Yes. Okay, so I kind of went off the beaten path a little bit on this one. This is kind of more of a pet peeve than a so my number nine is bad Kickstarter tech launches. And the one that really comes to mind from the 2010s is the the coolest cooler, which was the cooler that was just trying to be way too many things than just a cooler. I think it had streamable music it had multiple USB chargers speakers on board. It had everything Swiss Army knife Kevin 27:58 or cooler Right. Bob 27:59 Yeah. But for a fucking cooler so I think that paved the way for a bunch of people to be like, Hey, I know this crazy thing that's a bunch of things taper to other things and let's start a Kickstarter for it. And that got really annoying. So Kevin 28:15 full disclosure, I think in 2013 or 14 I was part of a Kickstarter campaign totally failed. But that reminds me because this isn't on any of my list. I'm glad you brought this one up. Because Patreon, Kickstarter, Indiegogo, GoFundMe. Those are the ones just off the top my head. Everyone in their brother and sister are holding their hand out going Hey, give me money. Why? Because of an idea. Okay, well, Bob 28:48 or I can't make rent. here's the kicker. Here's a good one for I can't make rent this month. Yeah. Kevin 28:54 Yeah. So I still like being, you know, contributing when I can can do a charity I'm mostly I can contribute my time not so much money. Every time I see a Patreon for somebody I know, we call it the Tupperware problems, like, I gotta buy at least two bowls, you know, a salad bowl with the leg, make sure you get the lids, otherwise, you know, he's gonna be pissed. And you know, I want to be friends still. And so we call it the Tupperware party, Bob and I do and it's really hard because you look, as a creator, we're Bob and I are both creators, we look and go, I look at all these great, you know, people doing great things and getting Patreon. But then it's like the top 1% It feels like that's, that's actually getting somewhere on these platforms. And then there's everyone else. So Kickstarter sells you this dream and with the 1% actually doing it and they collect, you know, the funds underneath as a fee. So I really look at that stuff and go on. That's just, I don't even know what to call it's not really snake oil, but it's definitely like Same shit different, you know method here where, hey, we're just trying to separate people from money, right? Bob 30:06 Well, my boys bless their hearts. They're both big fans of Kickstarter type projects. And they are just now receiving stuff that they invested in when they were in their mid teens. And they're both in their 20s Kevin 30:23 man, also not a super long game. I guess I won't tell you what's not on my list just in case it's still on your list. All right, let me go with my number nine and you'll be like we're What? The Video Game fortnight This is on my negative list. Bob 30:38 Oh, that's so funny. Kevin 30:42 Video Game my mind. So go ahead. So I put fortnite on there. Mostly Bob 30:46 for shit. No, I did put a video game on mine. Well, I'm Kevin 30:51 so fortnite just the way it affects all the kids. All the children in my orbit. my nieces, my nephews, my own kids. These people are dicted listen Like a real drug and on top of that, it pretty much shut down every other video game except for maybe Minecraft and untitled goose game. Alright, so there's like three video games left in the world because of fortnight has just totally come in steamrolled everything. And they have this concept of V bucks, where, you know, the kids are like, Hey, can we get or can we get a gift card for Microsoft so we can apply it to our Xbox so we can basically just give it away. I'm like, Oh my god, this is this is life. And then there's like this internal gambling addiction that they all have, because you can get these llamas and these crates and you get this random thing that comes out. And while I'm on the gambling thing, my girls who don't play fortnight as much they do play fortnight. They have toys like lol dolls are familiar lol dolls. It so so. So if you go to Walmart or any retailer, they'll have them so it's a sealed box opaque. You can't see what's in it. The whole idea is you got to buy it to see what's in it and it plays on these like human emotions. curiosity. Anyway, so number nine is fortnight for me What am I? Bob 32:08 Oh, that is a great so now we're to my number eight. Kevin 32:13 Number eight positive Bob 32:14 number eight positive and I lied and I want to stress again this is not scripted, we did not see each other's list. My number eight positive tech from the 2010s is Minecraft because it's a family focused gaming adventure and you can play it with your kids and actually with my kids, I taught them how to manage their own minecraft server so they weren't out there messing around with the general public so taught them how to give server line commands basically through the through the Minecraft thing so this is so funny that you were fortnight and now I'm on Minecraft so Kevin 32:56 okay so interesting sacred you're picking Minecraft Yes, Minecraft Bob 33:02 positive. Oh, okay. Kevin 33:03 Yeah so Minecraft I think has replaced Lego and a lot of housecalls for sure yeah Bob 33:09 digital Lego without a doubt yeah and when I again Kevin 33:12 another thing I was totally wrong on with Minecraft cuz I see it I'm like what the hell is this shit The graphics are terrible right you know it's very blocky no kids gonna like this right they're just gonna be like oh well you know give me like Call of Duty or something with high end graphics but actually I kind of like Minecraft because it It stimulates creativity and building and whatnot. Bob 33:38 Yep, that's pretty much why I was coming in at number eight for me of the 2010 Alright, so Kevin 33:42 my number eight you'll probably snicker a little bit is crypto slash blockchain. Bob 33:51 So this is your number eight positive Oh, Kevin 33:53 oh, I'm sorry. This is my negative shoot. Bob 33:58 No, that's why Kevin 34:00 I totally messed up. So all right, I'm gonna I'll come back to my number eight positive because I've already tipped my hand. So my number eight negative is crypto blockchain because as of right now, I don't think crypto blockchain has changed the world because that's basically what all the crypto slash blockchain people are saying, Oh, we got a blockchain all the thing it will change the face of insert industry, crypto currency, it will change the face of whatever. I'm still waiting for it to change any part of my life. Bob, what part of your life has it changed? Bob 34:35 Um, I think the only thing that it's really affected is our podcasting because of the Libra kinds of Libra crypto trying to desperately make its way to market. We did do that experiment a couple years back with investing in crypto and tracking the markets. So but that was more just fun. And I Still have not recouped from where we invested. Kevin 35:03 Yeah, you and I totally hit the apex of crypto hey look at all this great stuff happening in crypto let's invest and the good thing I sold out right, I am out for save whatever 15 bucks a Bitcoin was worth a few months ago. Bob 35:19 Yeah, I'm still in. I'm still in. Kevin 35:22 Yeah, we're such suckers, man. Such suckers. Alright, so that was my number eight negative. Do you want me to catch up and just do my number eight positive and then we'll Yeah, we'll just flip it so you do your number a positive so my number eight positive is SpaceX reusable rockets. Wow. So you and I had a live stream of the Falcon Heavy launch which highlighted the landing of the booster rockets and that was in 2017. We had my kids. Bob 35:56 They got two out of three on that one, right? Kevin 35:59 Something like that. But it looked like a frickin science fiction alien invasion movie, which was awesome. Bob 36:07 Suit I got choked up. Kevin 36:09 Oh, me too. And to this day every time they stick the landing, which is it pretty much every Bob 36:14 time now it's regular now. Yeah, Kevin 36:16 that's, that's awesome. I think one of the rockets that went up recently was like its fourth or fifth flight. And that's gotta save money somewhere. And I've heard a lot of people say, Oh, it won't be financially feasible still, you just gotta throw those away and start over. But I think they're starting to prove that wrong. What do you think? Bob 36:35 Yeah, no, I think they're getting financial benefit with the multi launch multi land for sure. That's how they're able to really kind of like supplement the starlink programs. So yeah, the reusable rockets. That's brilliant. Yeah. So and for the most part right now, those are 100%. unmanned trips, right? Kevin 36:55 Yeah. They are testing the ability to send up manned crew and they've had some success recently, because right now we're actually dependent on Russia of all people to send people up the space station. And I will be in Florida in a couple months and trying to catch a falcon nine launch for the starlink program but that's about like thread that needle at this point. Bob 37:21 Right You showed me the schedule it looks like it's not going to happen while you're there. Kevin 37:25 You know, I don't know the schedule enough to know that maybe I'm just looking too far out and they're just gonna fill the schedule or or what have you, but I'm excited. My kids are too They want to see it. Bob 37:35 That would be awesome. Kevin 37:36 Yes. All right. We're up to your number eight. Worst, my number. My number eight bad. Yes. Bob 37:44 This could be a trip down memory lane for some not a positive one. Kevin, did you ever hear of the lytro camera back in the 2010 never heard of it. It is a light Field Camera. And it was supposed to revolutionized digital photography. And it looked like a rectangular tube. But what the camera did it was supposed to capture the infinity of the light that created an image. So you could capture that photograph doing air quotes. And then you could do it ever you wanted to with after that, because it had infinite resolution. That's interesting. So, Kevin 38:28 yeah, it failed, by the way. So have you ever been in photography? Bob 38:33 I yeah, I actually do love photography. And I should love to Kevin 38:37 talk. So when you focus on a certain spot it becomes or there's a certain spot of moving the focal length and you'll hit what's called the hyper focal distance. And everything beyond that point is in focus. It's just like, we can take a picture of a mountain range and it's like, why is that always in vice, the background noise and focus because you've got the focal length, that's the hyperfocal distance, anything in front of You start getting the beaucaire or Boca or however you want to pronounce it. I don't even know what the real word way of pronouncing that is. Bob 39:07 But it's I'm not that big in photography, Kevin 39:09 but to get the subject in focus in the background out of focus. So anyway, blah, blah, blah, blah. Sounds interesting. But you said it totally failed. Bob 39:17 Yeah, first of all, they were super expensive. And the UX, the form factor for the device itself was just very clunky. So, but it was something at the time, I was very into photography and spending money on lenses and things like that, and was very excited about but there was no way I could afford it. When it came out. They came up with a better form factor, but it was still like over 1600 dollars. I think at the time, well, Kevin 39:47 you know what, there's a there's a thing called the iPhone 11. That's got about three cameras on it, and it's a little less than that. So Bob 39:54 right and you can totally adjust that bootcut whatever it is, too. So yeah. Kevin 39:59 Interesting. Bob 40:01 All right, but yeah, so that was yet some of these are very personal to me. So this is pretty fun. Kevin 40:07 I'm glad I didn't bet money if what your number eight was eight would be all right, my number seven positive is 3d printing slash CNC slash vinyl cutting. Bob 40:22 Man, I'm so glad you hit that market too. Kevin 40:24 So 3d printing for me it's very cool. I've seen people make just some ridiculously cool things are basically like hey, yeah, we'll take one of those it's sort of like the the real life replicator from Star Trek shout out to start a supplemental. We need a nice here we need to eventually do this crossover episode Bob 40:43 crossover coming soon. Kevin 40:44 Yes. So that's what I think a 3d printer does. My vinyl cutter is that 2d printer very cool. In I've also seen that they can 3d print organs now which is like totally mind blowing like, hey, can 3d print a new heart and stuff They're printing. Bob 41:00 Yeah, they're printing meat too, which is really weird. Kevin 41:04 So I think 3d printing is still early, but I think it has a lot of promise. I've seen 3d printed houses out of concrete, you know, for in developing countries, just they can just set up a machine and it prints overnight. Yeah, just mind boggling. So what do you think? Bob 41:21 Yeah, I think that that's a really good one. I actually did not touch upon 3d printing. But it's funny that you brought it up because my wife the other day was asking if 3d printers were getting cheaper, and so I thought that was really like that was a bizarre, surreal moment in the baby bar household that she was even considering 3d 3d printing. I like the aspect of 3d printing as well as like printing pieces or tools to do things without having to go to the store to purchase tools. I think that's pretty cool as well. Kevin 41:54 Yeah. Yeah. I played the game civilization quite often. And one of the technologies that you can unlock is called replaceable parts, you know, like preceeds. Like, it's like Civil War era type thing where you could start, you know, fixing things rather than just having to craft it from A to Z every time well give me a couple of these parts, and then we're back to New. So I see the 3d printer is an extension of replaceable parts. And not that I think a hardware store is going to go out of business anytime soon. But when 3d printers become more ubiquitous, that might change. Bob 42:30 Well didn't one of the like space shuttle missions or some space mission space station, maybe even they were able to 3d print a wrench that helped them out in a situation or something like that Kevin 42:42 sounds familiar, but I can't recall the exact one. All right, we got anyway. Yeah, that's a great, well gotta move on. I say what's your number seven positive Bob 42:51 by number seven positive is pretty interesting because I think you've already alluded to this, but number seven positive was cable cutting with streaming services like Sling TV. And we've talked about this on the show several times where I think in the early 2010s when this started to happen, it was meant to be a very positive thing. But now with every service jumping on the streaming subscription bandwagon, really if you add them all back together, it probably costs more than traditional cable Kevin 43:22 and it has the side effect of putting us into an additional filter bubble. We haven't really talked about filter bubbles on this episode just yet, but you know, you're in your platform, you're in your channels and you're you know, you're on Netflix. I cord cut in 2012 off of DirecTV and my wife was pissed she's like, I want my whatever that we remember DVR. I mean, back then, you had to DVR things now. Everything's on demand. I mean, just the world has changed so much. Bob 43:51 Yeah, we need my family off. DVR was a very interesting experience to the cord cutting. So Kevin 43:56 yeah, I like it. I guess now we can transition to My number seven worst and it is crisper. Are you familiar with crisper? Bob 44:07 The DNA editor Kevin 44:08 so I would like to bundle this with DNA testing as well. So there's a Netflix series I forget what it's called, but it follows how crisper works and things like that. And I don't even want to you know, it's not a religious thing and nothing like that. I just think it's a bad idea to fuck with nature, Bob 44:26 right? Oh, I think gene editing is a terrible idea. Kevin 44:29 Yeah, um, the The one thing I think is is way more acceptable is GMOs. You know, if we can make corn feed us more and you know, whatever, that's fine but trying to alter somebody's intellect I color you know, the frick people aren't frickin ecommerce items. I mean, I guess you are in some countries, which is very sad. But so, you know, you don't order your children often many right? Bob 44:57 Yeah, and I can really can't imagine a society where you Would I mean, that's definitely a black mirror up. So Kevin 45:02 for sure, well, I mean, I could definitely, you know, play antagonistic to myself. People would say, Well, Kevin, we can eliminate cancer, we can eliminate whatever, whatever. But you and I are coders what happens when we fix bugs Bob? Bob 45:17 New bugs have Thank you. Kevin 45:20 cancer, but you're gonna create God knows what literally God knows wouldn't be the only one who knows what. And maybe that wipes this all out. Period. Bob 45:28 Right. It's just a cascade of it's just a bit. It's a cascade of bad consequences. Kevin 45:33 Yeah, so. All right, well, so I think the pendulum has now swung your number six. Bob 45:41 Good. Now I think we're on my saddle bag. Right. Kevin 45:44 Say it's good thing. We should call it a good thing. We're calling this out because I can't even count the 10 apparently. Bob 45:49 That's okay. Number seven bad is Google in perpetual beta throughout the 20 times, and then the ultimate bait and switch where free services no longer We're free services. That one's pretty self explanatory. I think we hate all the big tech giants with equal Kevin 46:07 disregard. So I'm familiar with the website, killed by Google. com. Bob 46:14 I'm pretty sure we brought it up. And when you're talking about all the companies Kevin 46:16 are also actually brought this up just for this episode. And I did not know two things on here are actually already scheduled for the X number one is Angular JS be one that is no longer supported, as of one year from now, so in one year for using Angular one dot, whatever, and I realized that's very nerdy and very like specific to coding and I am trying not to go down specific things here. But Angular JS is an older but super popular thing that we used Bob 46:49 to go super stable. Kevin 46:50 Yes, absolutely. I Bob 46:51 don't know why they fucked with the law. Kevin 46:53 Well, reasons right. Then here's the one that I was like. Are you kidding me? Google Hangouts is being Bob 47:01 I did hear that they were sundowning that, but I think they're just giving it a different name to be on it. Kevin 47:06 Yeah, apparently it's going to be called shit. I don't sit here, it's gonna be part of the G Suite. So maybe it's just, they're just not making direct money on because people just use hangouts for random garden variety shit. And that probably costs money. Right? Bob 47:22 Right. And they want to bring it into G Suite because G Suite is not one of their paid things. Yeah, so that's Kevin 47:27 kind of another 12 months according to kill by Google, but killed by Google is kind of a fun website because he just I mean, it's a lot of scrolling a lot of vertical scrolling of Holy shit. All of that is now dead. And while the lay person could probably care less than we do, but Bob and I, you know, when when we're asked to integrate with service x, I don't know about you, Bob. But when it's owned by Google, I go, Oh, well, how long do we even have left with whatever this is, Bob 47:58 right. It's a Total question mark for sure. Kevin 48:01 hate it. And I, you mentioned google maps that totally did a bait and switch on that. I'm trying to get Google out of my life, if you will. I'm actually using DuckDuckGo lot more. And if you do like a search on DuckDuckGo, and like directions, it's actually powered by Apple Maps, which is kind of an interesting twist on things. Oh, boy. Apparently, I don't know if I like that. I haven't really used Apple Maps. I heard it was really bad. And they've made improvements and I'm know apple. Bob 48:36 I think they bought ways one of them bought ways Google or Apple to go. Okay, Google that. Okay. Yeah, Kevin 48:41 that was unceremoniously explained to me the other day when I was like, why is Google Maps and way so similar? Whatever ignorant thing I said. Okay, so, so your number six positive, that's what we're up to. And then I know this is gonna be real nerdy, so I'll try to keep up light for the general listener. hub picks the number one spot over there the decade to become the go to place to dump your source code. Bob 49:08 Now, I think that's a good one. Kevin 49:10 Now, why does that matter? Well, I can tell you it prior to the 2010s. Source Control was very optional. And a lot of people may say, Yeah, right, not where we work. But let me tell you, I worked a lot of places, and it was copy paste, and you do control C, Control V, that's your backup. And they said, you know, it just put the little numbers that Windows does, you know, 123 as you control C, Control V. So GitHub really changed it. There was a bunch of competitors, and there still are subversion, whatnot, and then Microsoft bought them. So that was kind of a big deal that happened recently. And why does this matter? Well, GitHub is very known for open source and basically, the open source revolution. I'm going to try to put that in here as well. It's a big deal for both programmers and non programmers why is it important for non programmers? Because the programmers can bring you things that they couldn't before. What do you think? Bob 50:08 Yeah, and I think it's a great learning tool opportunity for developers and non developers alike. If you're interested in getting into code. GitHub being basically the open source, you know, realm, you can, you can just pick up a lot of great grades. I'm sure you can pick up a lot of garbage too, but there's a lot of good stuff out there. Kevin 50:27 So okay, where does that leave us? Which list are you on? Remember now? Bob 50:32 That was your number six positive so it's time for my number six positive and I think this one will be brief. I think slack is my number six positive and its ability to kind of almost fulfill the Facebook mission of bringing people together without necessarily all the ads in bullshit stuff that I'm sure we'll talk about a little later. Kevin 50:58 So yeah, slack is my number six. Good. So when I worked at the first agency I worked at we were an early adopter of slack. So slack was created in 2012. We start using in 2013. And, and at at the time, it's like, yes, it's cool, but I thought it was just yet another thing that you know, was out there. But it's really changed things because it's dead simple. It's web based. It pretty much killed off things. And it'll probably laugh AOL Instant Messenger, Yahoo Messenger, remember, I mean, you'd have to have all of those installed. Because depending on who you want to talk to, right? Bob 51:34 Yes. Do you remember that one that pulled them all together? I can't think of the name of it now. But there was like a universal chat app that you basically registered all your other accounts through and you could use it Damn it. I can't remember it was called Kevin 51:46 it sounds sketchy price stores your password. Bob 51:49 Yeah, there was all kinds of shitty stuff with that, but it was a trillion trillion Pro. I love to trillion. Alright, so let's see. Where's an hour back to the bad? Right? Okay, so Kevin 52:03 so my number six, and this is going to be specific. But Oracle sued Google because of Android, the API's and aerosol. Yeah. And that's still being litigated. And it's for like billions of dollars and Oracle is one the initial judgment, and Google's appealing. But the real trouble with this isn't the money that's changing hands, because you and I wouldn't say it anyway. It's doesn't have anything to do with us. But it set the precedent that the API signatures I believe, is, and I could have this totally wrong, but the API signature think of the interfaces as copyrightable. Not the implementation, but just having a method named void save or something. Bob 52:42 Yeah, see, that's crap. That's like, I don't know. That's like trademarking toilet paper. Yeah. Kevin 52:48 So, speaking of frivolous patents, I should maybe I put that in that maybe that's the overarching theme here. somebody tried to claim that the shaft car was their patented invention and in fact, I believe they actually got the patent, and Newegg contested it because this guy is like hey, Newegg. And if you're not familiar Newegg. They're like a computer retailer. You owe us a bunch of money because you have a shopping cart completely like was like, you know, you can't patent the mouse click. The shopping cart is obvious. So, patent trolls and whatnot. I just hate that kind of stuff. So we put that in there too. What do you think? Bob 53:29 Well, I think that's great. I yeah, there's so many shitty things that apparently happened in 2010. Kevin 53:34 And we're only halfway done. Bob 53:37 So my number six is going to be super quick because we've already touched on it. My number six of the not so great tech would be the crypto craze. Bitcoin was pre 2010. But a theorem kind of brought wallet, online trading all that kind of good stuff to the forefront because it was something other than just Bitcoin. It's a mess. Kevin 53:57 So that's a good one. I'll just quickly transition to my number five positive and I'll just throw it out there as the gig economy so if you're a god damn magician, car driver whatnot the power is is did you Bob 54:17 say magician? Yeah Kevin 54:18 because the reason I said I'm watching on Netflix it's Bob 54:22 Oh my son watches that one the magician's right Kevin 54:24 well, there's a button no not not that one's on CW but there was one on Netflix. It's called, like, magic for humans or something. And it's like he actually mentioned in there the gig economy, you can basically get anyone to do anything on the internet these days. Whether it's, you know, back in the day when you're growing up, it's like, you can hire a band, you know, you have this like sketchy part of Craigslist. Well, that's come out and they're their apps. I mean, when I was at your there's an app for that when I was at your place, you had like three or four options of people who will bring you food to your house. Yeah, guess how many cats Has well we still have pizza hut and Papa John's that's about it and I don't think this qualifies gig economy, right? Bob 55:07 Nope, not so. Alright, so that was your number five good? Yes. My number five good basically encompasses a lot of stuff we talked about today 4g LTE networks that came of age in the 2000s which made a lot of this digital communication streaming from your phones possible so Kevin 55:30 that figure that was a really big that might be on my list that might be on my list of the a quick one. Okay, so 4g definitely did change it and I'm patiently frickin waiting for 5g because while sometimes I will use my 4g hotspot do work and or do a podcast with you. 5g is where I think I need to be for the whole house because I don't think my 4g phones gonna handle that. Bob 55:57 So now melted. Kevin 55:59 Yes. So that's good. Alright, moving along here. Bob 56:03 Number five bad or five bad net Kevin 56:05 neutrality. So good one net neutrality for the lay person is a topic that came up a couple of years ago, basically the current administration, FCC head said, you know, what, no longer are these protections in place? What protections were they? You say, Kevin? Well, what they are is let's say your internet provider wanted to throttle slow down your Netflix, because you're doing a lot of binge watching or whatever, Bob 56:36 before net neutrality, or because large corporate interest, wanted more bandwidth and paid for it. That's yourself. Kevin 56:42 That's it. So So net neutrality protected us. But those rules got rescinded. And now it is possible that you can be throttled unless you pay to play right. Bob 56:56 Yeah, tinfoil hat guy and me says we've always been throttled. Kevin 56:59 Yeah. How do you check that right? Bob 57:02 Yeah, exactly. All right. I think we're back to the positives. Nope. My number five negative. You've just got the ping pong game all wrong. My number five negative. You've already brought it up. Mine was DNA kits for the masses. Yeah, so don't do it. We don't we Yeah, we don't need to be testing our DNA, who who cares? Who cares where we're from? Who cares what we might die? Well, Kevin 57:24 it's a pseudoscience really Anyway, I've read so many articles were there. Who knows if what the information they're giving you is any were true because you can be, say Jewish as a race or a Jewish as a religion. You can be from the Middle East, but your skin color you know, I mean, there's just so many combinations and it's just doesn't make sense. Plus, the Pentagon just recently put out a warning saying, hey, if your God member you shouldn't be submitting these DNA tests for for security reasons. Bob 57:59 That's got to be One of the biggest red flags I've ever seen it's just such a data grab so gross right all right, all right, so your number four good one he might Kevin 58:09 crap your parents, but I'm gonna loop in AI ml and neural nets. Oh wait Bob 58:16 as a good one Kevin 58:17 toes you're gonna crap your pants. So actually, this one kind of rides the line for me between good and bad and I've got a few of those. So I was watching the YouTube series that I pass along you which is only three to three episodes before YouTube Bob 58:33 I was gonna say it's paywalls right only Kevin 58:35 the first three episodes are free but after that they want money and sorry YouTube, you've already you're already profiting off me somehow someway. But fucking drug dealers. One of the cool things in there was a guy a former Tennessee Titan football player had ALS or has ALS and they use speech recognition type things to help learn how he talks now. Excuse me versus how he used to talk Like press conferences and things like that. And now they can translate him very well. And I was like, that's what ml Bob 59:07 is. Wait, so they can translate him in his own voice basically. Yes. Kevin 59:11 So he's very well, that's beautiful. That's cool. He's very difficult to understand in real life now. But they can, they can go both ways they can, okay, he can say something now, and it can just do text, or they can also replay in his own voice, which is amazing. That's pretty awesome. They also have it where somebody has lost a limb and they have the Luke Skywalker hand where you know, you move these things in your arm and it knows then it learns you as a person on how to move it. Because previous attempts at like limbs, specially hands hands are very complicated is well how do we make this work for everyone? Well, you don't that's the problem. Everyone is wired kind of a little bit differently. And if you leverage machine learning, to kind of figure out you know, the nuances A few and hey, that work that didn't and adjust on the fly. That's great. And so that's where I think it's super. That's great noble, where I'm not so hot on AI and machine learning is like self driving cars. I really think that's just you know, I know. That's just a waste of time. You know, we're, you know, I just read the other day, Tesla hat was involved in another autopilot death, you know, where the car was an autopilot and killed some people. So, of course, yeah, Bob 1:00:30 but still, they've got like, hundreds of thousands to go before that's really an issue. Kevin 1:00:35 Right? I mean, the the easy defense of that is Yeah, and so and so died from dear, you know, crashes and that's human control. So what's your point carry Bob 1:00:46 on? Yeah, on that same day, 3000 people probably got killed by regular people driving. So Kevin 1:00:53 what I'm getting at is, I don't put auto or self driving cars at the top of the machine learning like to do list I put right mbts I put people who have medical, I put that high up. So that's why when I, when I see like, hey, there's this new self driving car and it's blah, blah, blah. I'm like, that's great and all but is that changing humanity? I mean, getting rid of effect. Yes. We're saving you from the tyranny of driving a car. Ooh, you know, that's, that's really not high on my list of things we need. Bob 1:01:26 I'm telling you though, next year when I get my cyber truck, I'm getting it with the autonomous mode. Alright, moving on. That is an upgrade. Kevin 1:01:35 Alright, so we are on Bob's number four positive, Bob 1:01:39 right my number four positive also spooky. You already had it ride sharing gig economy apps, basically, where's my number four. So Oh, the ability to have a system in your pocket where there's thousands of participants where you can pretty much good anything you need on because they're volunteering to be in the system. So Kevin 1:01:58 the only notable thing there is With the gig economy comes the obvious potential exploitation by the overlords running the apps. Yes. Lyft Uber, I think are the two that are considering unionizing or you know, there's there's issues there. And then the other one is with YouTube, YouTube's not really a gig economy unless you look at it through the lens of Well, I'm a performer Raiders Bob 1:02:21 kind of our Yeah, Kevin 1:02:22 so yeah, so there's exploitation potential there. But Bob 1:02:28 what I think the technology to make that open for pretty much anyone to participate in that economy is the bonus part. Maybe the way it's executed is not but the ability the technology is open that door. Kevin 1:02:42 I think that's pretty Yeah. And let me tell you, Airbnb if we're considering that also a gig economy that is a huge huge plus thing I'm, I'm going to Disney World for the second time, or third time with an Airbnb because it's just way better than doing a hotel. So Bob 1:02:58 we always look for the Yes, Airbnb places to quirkier the quirkier the better. Alright, so your to your number four bad Kevin 1:03:09 Cambridge Analytica. That's my number four. Bob 1:03:12 Wow, that's really far out. We thought it'd be higher up. I thought it'd be closer number one Kevin 1:03:20 yeah, it gets pretty crowded here. So Cambridge analytic if you're not very up on that there's a Netflix documentary called I think it's the great hack if I'm, Bob 1:03:31 yeah, okay, I did an episode I Kevin 1:03:32 did an episode on it. And basically, we're all suckers and it will be a component of one of my to a component of two of my top three negatives here in a bit. But Cambridge Analytica basically exposed how much data is the new oil. I'm channeling my inner Bob Baty buyer right there. Bob 1:03:56 That's his data is the new oil that is trading. That's right. Kevin 1:04:00 So I'll just leave it there. I don't have time to explain Cambridge Analytica, I, I don't think you would disagree with you. Maybe you went to high No, Bob 1:04:07 not at all. No, my it's actually higher up on my list, but I don't disagree at all. My number four bad is an old guy rant. It's Instagram, Snapchat and tick tock. I just can't keep up with all this shit anymore. Like I was very active technology dad, and introduce my kids to Facebook and Twitter and kind of introduced them to Instagram and then Snapchat and tick tock all kind of blossomed on the scene in the 2010s. And I just can't keep up with all the different interfaces and what's the expectation how the content supposed to be formulated and delivered. It's just it's too hard. So that was my number four bad. It's just the rise of all these little micro networks. I still don't understand Instagram Stories dependent and people have explained it to me over and over and over. I just don't get it. I consume them pretty regularly because I think they're a good think they're good platform for consumption. But to have to make an Instagram story I struggle. Yeah, the struggle is real as the kids. Kevin 1:05:07 Alright, we're back to the positive right? Bob 1:05:09 Number Three positive for you, Kevin. Number three. Kevin 1:05:13 Actually, this one's a mixed bag too. But it's gonna be like, Oh, I guess that is the thing, hashtags and the like button. Bob 1:05:21 So Oh, that's a continuation of my old guy ran. Yeah. So Kevin 1:05:24 hashtag, you would think that non tech users getting the them to use hashtag would be really difficult. But humans seem to know how to use hashtags nowadays. And the like button while it's positive is is it's a quick feedback. What I don't like about it is the ambiguity of not pushing the button. Does that mean people don't like the post? Or does that mean people haven't seen the post? And that ambiguity is by design, right where it's like, well It's not that people don't like it. Maybe they didn't see it or whatever. What do you think? Bob 1:06:04 Yeah. Well, that I think that not seeing it, especially with all the stupid algorithms that these different networks have. I think that's a big possibility. I'm always, like perplexed by someone will post something that, especially on Twitter, actually Instagram too. So they'll post something that is actually kind of sad and not positive. But you want to show that you support them somehow. But your only option is to like the fact that they put something really sad there. Yeah. So I do like that Facebook has a little bit more wider range of things. But yeah, I do struggle with that a little bit. Kevin 1:06:43 Yeah. Do you think Twitter Instagram will adopt the multiple emoji reaction? Bob 1:06:50 I don't know. Would Facebook come out and say against Twitter like No, we've patented that. Kevin 1:06:56 We've patented the for emoji response or whatever it is now. Bob 1:07:00 That's interesting. And then you'd have to remember what the equivalency is between the platforms. See, that part just pisses me off. Kevin 1:07:06 There's there'll be an app for that. Don't worry, old guy rant continues. All right, your number three positive, Bob 1:07:13 my number three positive. Actually, I struggled putting this as low as number three, I wanted it to be closer to one. But there's so many, I guess I didn't have so many good things. My number three positive was the Apple Watch and fitness trackers in general. Apple Watch kind of came to the largest prominence early in the 2010s. Wit

What does it take to move away from AngularJS? Carl and Richard talk to Jennifer Wadella about so-called legacy Angular apps, that is, web apps built using Angular 1.x - known as AngularJS. The discussion calls back to the issues around AngularJS, that its flexibility led to a huge array of programming approaches, making it difficult to manage projects in the long term. The opinionated approach of Angular from version 2 dealt with that issue, at the price of making upgrading hard - but today the change shows its value in a huge ecosystem that makes modernizing worthwhile!Support this podcast at — https://redcircle.com/net-rocks/donations

What does it take to move away from AngularJS? Carl and Richard talk to Jennifer Wadella about so-called legacy Angular apps, that is, web apps built using Angular 1.x - known as AngularJS. The discussion calls back to the issues around AngularJS, that its flexibility led to a huge array of programming approaches, making it difficult to manage projects in the long term. The opinionated approach of Angular from version 2 dealt with that issue, at the price of making upgrading hard - but today the change shows its value in a huge ecosystem that makes modernizing worthwhile!Support this podcast at — https://redcircle.com/net-rocks/donations

Guest: Dillon Kearns: @dillontkearns | GitHub | Incremental Elm In this episode, Dillon Kearns joins the show to talk about techniques for experimentation with Elm, making those experiments safe, the concept of mob programming, why you would want to experiment with Elm in the first place, and how you too can begin to experiment with Elm. Resources: Grant Maki's talk on experimenting in your team "Types Without Borders" by Dillon Kearns @ Elm Conf 2018 Dillon's Elm GraphQL library How Elm Code Tends Towards Simplicity by Dillon Kearns The CSS as ByteCode Talk by Richard Feldman This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. Transcript: CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode 114. My name is Charles Lowell. I'm a developer here at the Frontside. With me today as co-host on the show is David. Hello, David. DAVID: Hey, guys. CHARLES: David is also a developer here at Frontside and we are going to be talking about something that we've been talking, I guess a lot about recently and we're talking about Elm. I think we first started talking about this several years ago and then it kind of simmer down a little bit but recently, it's been top of tongue. With us to talk about Elm today is Dillon Kearns. Welcome Dillon. DILLON: Thank you so much for having me. CHARLES: I understand that you are a full time Elm consultant. You have a background as a Lean and Agile coach but have recently transitioned to doing Elm consulting full time. Now, what exactly does that mean in 2018 to be an Elm consultant. DILLON: Actually a lot of my motivation for getting into Elm consulting in the first place is I kind of realize that Elm to me is just an extension of the things that I was passionate about with Agile and software craftsmanship. I'm trying to help teams have a better experience with their code, make it more maintainable, make it easier to change, make it easier to drive things based on customer feedback and I really believe that Elm helps people do that. I used a lot of the background and experiences that I've had with Agile and Lean coaching and a lot of those same skills, in order to help organizations adopt Elm. One thing I've seen a lot of teams struggling with is trying out a lot of different frameworks. I've encountered teams that have spent months, very painfully trying out different frontend frameworks and having trouble coming to consensus about that. One of the things that I think really helps address that is having an experimental and iterative approach, that you can really use the scientific method to focus on learning, rather than getting it right the first time. I think that there's really a need to help teams through that process of introducing a new frontend framework like Elm, so that that's why I've gone into full time Elm consulting. CHARLES: That's an interesting process. It sounds like you really need to be constantly sending out spikes, doing research on whether it's Elm or some other technology to help you kind of bridge the chasm to the next generation. How do you actually do that as an organization? My guess, this kind of a question independent of Elm but maybe we can talk about how you see that play out in the context of Elm. DILLON: Right and actually, for any listeners interested in that question, I would really highly recommend Grant Maki's ElmConf talk from this year. He spoke about exactly that topic and it was at ElmConf that it's relevant whether your team is considering Elm or looking at other frameworks. I think that the key is you need to get good at experimenting in a way that's low risk and in a way that you can be constantly learning and seeing how these different technologies fit in your codebase and fit for your team. There's a quote that I really like from Woody Zuill. Have you guys heard of mob programming before? CHARLES: I heard of mob programming from a paper by Richard Garfield a long, long time ago, almost 20... I don't know if it's the same concept. DILLON: Yes. It gained a lot of momentum these days. Mob programming is essentially pair programming but with more people involved. I've really enjoyed that process actually. I think it's actually a great way to experiment with different technologies because you get all of the minds together and it's a very good way to kind of transfer knowledge and explore things together but Woody Zuill talks about mob programming and he likes to ask the question, "Why did we begin doing mob programming for the team at Hunter Industries that originally started mob programming?" People would give answers like, "Because it cuts out code review from the process because you have lots of eyeballs on it in real time," or, "Because it reduces bugs," or, "Because it gives you better quality code. It gives all the best ideas into the product in real time," and all those things are valid points that are really good benefits of mob programming. But he says those things may be true but actually, they're not why we tried mob programming. The reason we tried mob programming was because the team wanted to try it. That's a really important point. The team needs to be experimenting with things that they're passionate about and they need to be exploring things on their own terms. But with that said, another lesson from that story of kind of his team at Hunter Industries discovering mob programming is that the team didn't discover mob programming in a vacuum. Really, the team discovered mob programming because the team became really excellent at experimenting and evaluating those experiments and then, they like to talk about this phrase that Kent Beck coined, 'turn up the good.' When something is working well, we often focus on the negative things and trying to eliminate those things but what happens if we take the things that are working well and 'turn that dial up to 11.' CHARLES: Yeah, I love that. I remember in the kind of the original layout of extreme programming, talking about how I really just wanted to turn up all the things that were working for 11 or to 11, so testing, refactoring, incremental releases and things like that. DILLON: Exactly. CHARLES: I actually had one question that's maybe a little bit of a diversion. This is actually the first time I've heard of mob programming. It's definitely not the same sort of mob programming I learned about in Richard Garfield's paper. I think it was more referring to massively distributed open source in the form which is really kind of commonplace now that happens on GitHub. I think it's maybe, an obsolete definition of mob programming but how many people would be in a mob like two, three, four, five, six, seven, 10? DILLON: That's a great question. Really, the answer is of course, it depends. That's a consultant's favorite answer but it really does. My rule of thumb is I find it usually three people is a very nice size for a mob. I find that mobs tend towards around three or four people but that being said, it's important to note that mob programming is all about this idea that what is the true cost of programming. I think that often we look at programming as the act of writing code, initially and that's a very limited way of looking at coding. Because of course, 90% of our effort is spent maintaining code, making decisions around code, reproducing bugs, fixing bugs, communicating with customers about bugs -- bugs are extremely expensive -- the farther out they get, until eventually they get to the point of a customer discovering them, bugs are in extremely expensive part of software. If we can minimize bugs, that's very valuable. When you look at programming on this bigger scale and look at the bigger picture of programming, then you realize that you may be able to get one person to write the code faster but then, that person needs to code review it. That person needs to go and ask somebody question down the line when they don't have context because they weren't involved in the decision making. For example, maybe there's a UX person who doesn't have context on certain choices that were made, so there's a lot of churn, so you can kind of eliminate that churn by getting all the relevant people involved right away and that's the idea. In my experience with mob programming, it works really well to keep kind of a core of around three people. Sometimes, somebody goes up to have a conversation with somebody, take a break or answer somebody's question, maybe somebody from another team has a question that type of thing and so, the team can keep coding as a pair or whatever. But ultimately, the idea is that you get faster because you're building up this shared context and you're not spending as much time down the line answering questions, doing code reviews and things like that. CHARLES: Right. I see. DAVID: That kind of matches with my experience. Mob programming on previous teams, the way we had it set up is there was a regular mob programming chat session that the whole team was invited to but it was optional. You can just show up if you wanted to and really, that sort of made it so that there was a set of people who regularly attend -- three to five people in a session -- and they were the core group, essentially. DILLON: Right. That's another great point. Invitation is a powerful technique. If you're kind of mandating the people try an experiment or work in a certain way, ultimately it's much more powerful to let the team experiment on their own and follow their passion and they'll discover great things. It's about experimenting, rather than choosing specific experiments. While we're on this topic of kind of the real cost of coding, I think this is a good point to talk about this quality in Elm because, I think that this is one of the things that really motivates me to use Elm myself and introduce it to others is that, I think that Elm really get something about programming where there's a sort of superficial ease of certain techniques that Elm kind of goes beyond and says, "Actually, let's optimize for a different set of things that we think make code more maintainable and more delightful to work with in the long run." CHARLES: I wanted to also transition between, we were on a little diversions on mob programming but do you use mob programming as explicit technique for introducing Elm when a team is considering adopting it? DILLON: That's a fantastic question. I absolutely do. Of course, I honor the ways of working in a particular organization or team. I think that's important to do but I do strongly encourage using mobbing as a technique for knowledge sharing and when I'm on-site with a client, I find it extremely powerful as a technique for knowledge sharing and also, let's say you do an experiment, somebody is off in a corner and they're trying out Vue.js or they're trying out Elm or they're trying a particular coding technique. Then they come back to their team and they say, "Hey everybody, I tried this great thing," and now they have to spend this time convincing everybody and saying like, "Wait a minute. You didn't try this, you didn't try it that way. It wouldn't actually work in our context because of this." I think that it's very powerful to have everybody kind of involved in that process so that you can evaluate it together as a team. CHARLES: Because the thing is like, when you experience win or you experience fail, it's a very visceral feeling and that's the thing that sells you or turns you away. You can argue until you're blue in the face but words have a very limited capacity to convince, especially when compared with like physical and emotional feeling. It sounds like you can get everybody to have that shared experience, whether for the good or for the bad, you're going to arrive at a decision, orders of magnitude more quickly. They have to rely in conviction of that decision spread around the team. DILLON: Exactly. I think that hits the nail on the head and you say that we have this sort of skepticism of arguments from theoretical conversations, rather than 'show me the money,' but it's actually, try solving a real problem in this and that's exactly as it should be. I think that's one of the big antidote from this problem that I've seen in a lot of environments, where there's this analysis paralysis, especially with the state of the JavaScript ecosystem these days. I think that one of the keys to improving that situation is to get good at trying things, rather than theorizing about things. We have a tendency to want to theorize and when we do that, then we say, "Can it solve this problem? Can it solve this problem? Can it solve that problem?" You can talk about that until the cows come home but it doesn't get you anywhere and it doesn't really convince anybody of anything. The key is to find very small experiments and what I really recommend and what I'm dead focused on when I'm initially working with a client is getting something into production. Now, that doesn't mean that you need to have a road map for turning your entire application into Elm. In fact that's the whole point, is that you're not trying to do that. The point is you're trying to get as realistic of an experience as possible for what problems might occur if we do this? Will the team enjoy working with this language? Will it work well with our built pipeline? Will there be any unforeseen issues? You don't know until you actually try it, so you've got to try it and you've got to try it in tiny, tiny steps and low risk experiments. CHARLES: Right but you've got to try it for real. You don't want to try it with a TodoMVC. DILLON: Exactly. It needs to be meaningful, to really have a good understanding of what it's going to be like. CHARLES: I would say that I tend to agree but I've definitely encountered the counterargument and I also think this counterargument makes sense or perhaps where the pushback lies is if I'm constantly experimenting, then what I'm doing is I'm internally fragmenting my ecosystem and there is power in similarity. Any time you introduce something different, any time you introduce one fragment, you're introducing complexity -- a mental complexity -- like maybe I have to maintain my Elm app and I also have to have my Legacy... Or not Legacy, I've got my other JavaScript tool kit that does it in one way. Maybe I've got a couple of more because I've run these other experiments. I'm not saying that there is one way but there is power in uniformity. There is power in diversity. Where do you find the balance? DILLON: Those are all excellent points. To me, I think really the key is it's about the scientific method, you could say. The thing with the scientific method is that we often forget the last part. We get really good at hypothesizing about things. Sometimes people leave it at that, which we kind of just discussed. Sometimes, people go past the hypothesizing stage and they actually run the experiment and that's great. But then, the majority of people, if they get to that point, will forget to do the last step which is to evaluate the results. I think the key here is you need to be experimenting and this is what it means for it to be a low risk experiment. It means that you're not setting yourself off in a direction where you can't turn back. You want to set it up in such a way that you can turn away from it with minimal cost. One of the things that is really helpful for that is if you build a tiny, independent, little widget in your application, try building that in Elm. Some people will do that with a little sort of login badge in the corner of their application. One of the teams where I've introduced Elm at a Fortune 10 company, actually where we introduced Elm, we started out with just a tiny little table in one page and if we wanted to back that out, it would have been trivially easy but we decided that we wanted to go in further and invest more. CHARLES: That makes a lot of sense. Effectively, you need to have a Plan B. Don't sync all of the available time that you have to invest in an experiment. Make sure that you have a Plan B and if you need to do this widget or this table in Angular or React or Ember or whatever, you are thinking about that -- how would that work. DILLON: Exactly and the thing with experiments is the purpose of an experiment is not to build something. It's to learn. I really like this kind of ethos of lean startup, which I think is really getting much more into the mainstream in the software industry, which is a wonderful thing. The idea of lean startup, the kind of core concept is this idea of validated learning. Basically, in an environment where there's uncertainty, which is pretty much most of the things you're doing in software, the main goal is you're not shipping a product like you would be if you're trying to manufacture cars as quickly as possible. The main thing that you're producing is what they call 'validated learning' and so, you want to minimize the amount of time it takes to validate or invalidate your assumptions about something and then, you want to make it as cheap as possible to move on from that. CHARLES: I like that. So if you're going to organize your development process around this principle or maybe not organize it but integrate it into development process, how do you know that you're conducting a healthy number of experiments, versus I may be conducting too many experiments? Is there a metric that you can look at? We need to have this many experiments running at all times or this is just too many or something else. DILLON: That's a really interesting question. I think I would tend to think about that more again, as looking at the way the experiments are run, rather than 'are there too many experiments?' That's just not a problem that I've seen there being too many experiments. The pain that we tend to really see in environments where experiments are hurting teams is the way the experiments are being done. It's hard to backtrack from those experiments and as you were saying before, you kind of put yourself down this path where you can't walk it back and you create this sort of rift in the way the code is being written, which makes it more difficult to work in that codebase. The thing with experiments is they can have really big payoff. Now, you want to make sure that you're not just going in and picking up every shiny object that you see. One thing that can keep you honest with that is if you're kind of coming up with a hypothesis before you start. If you're saying, "This is the value to our business and to our team if we attempt this thing and this is what will prove that it seems to have that value and this is what will tell us, 'Actually, it doesn't have that value and we should drop it and cut our losses.'" CHARLES: That's a great heuristic. As you're saying and imagining how that might have saved my bacon in the past because I've definitely made the mistake of playing with too many shiny objects and picking things because I didn't fully evaluate what I thought the value. I was explicit with myself about what is the value that is going to bring to this project or this business. I have a theory about it but I am not thinking what is my hypothesis and how am I going to validate or invalidate? I'm thinking, I've got a short term pain that I'm experiencing and I'm grasping for this thing, which I think will solve it and I'm not properly evaluating how it's going to affect me long term. DILLON: Right and that could be a great team practice to play around with is often, teams will kind of come up with action items out of retrospectives. One thing that I think can be really beneficial for teams is to kind of flip that notion of doing action items which again, it's really just doing the middle part of the experiment where you're conducting the test but you cut out the hypothesis part and the evaluation part. Try to bring that into your team's retrospective and try to have explicit hypotheses in the retrospectives and then, in the next retrospective, evaluate the results. CHARLES: All right. I will definitely keep that in mind but this feels like a fresh take on kind of how you manage software development that I haven't encountered too much, being more scientific about it. It sounds like science-oriented development. DILLON: Right. DAVID: I like that. DILLON: There are a lot of buzzwords these days in software development, in general and it's really becoming a problem, I think in the Agile community but really, what it boils down to is these basic elements and basing decisions on feedback is one of those fundamental unit. You can call the scientific method, you can call it lean startup and validated learning, you can call it agile, you can call it whatever you want but ultimately, you need to be basing things on feedback. I think of it almost like our nerves. There's actually a disorder that some people have, which can be fatal, which is that their nerves don't tell them when they're feeling pain. I think this is a great analogy for software because that can happen to companies too. They don't feel the pain of certain decisions not landing well. Because they're not getting feedback from users, they're not getting feedback from metrics and recording, they're not getting feedback from doing that final evaluation step of their experiments, so when you fall on the ground, a small cut could be extremely harmful because you don't know the damage it's doing to you. CHARLES: I think that is a good analogy. One of the things that I'm curious about is we've been discussing a lot of techniques for experimentation and how you can integrate that into your process and how you can make your experiments safe, so let's talk a little bit about -- first of all, two things -- why would I want to experiment with Elm in the first place? Because ultimately, that's why we're here and why we're having this conversation. What's compelling about it that would make me want to experiment? And then how can I begin to experiment with Elm? DILLON: I actually just published a blog post yesterday. It's called 'How Elm Code Tends Towards Simplicity.' To your question of why would a team consider Elm, I kind of talk a little bit in this blog post about a case study at a Fortune 10 company where I introduced Elm to a few of the teams there. One of the teams there, we had actually seen an Angular project that they had worked on and often, in an enterprise environment, you have projects moving from one team to another. I actually had my hands on this Angular project. It kind of moved over to another team and we were experiencing some major pain trying to make changes in this codebase. Even making the simplest change, we were finding that there were a lot of bugs that would be introduced because there's some global variable. There's some implicit state. Sometimes, it was even reaching in and tweaking the DOM and really, the topic of conversation at our team lunches was how afraid we were to touch this codebase. Fast forward a few months and this team was asking my advice on picking a new frontend framework and I introduced them to Elm. They took a run with it and it was pretty remarkable to see this same team that had really struggled with AngularJS and they didn't really have a strong sense of what were the best practices. They weren't getting any guidance from the framework itself and the tooling around it and they actually loved the experience of working with Elm because they were saying, "This is amazing. Maybe it takes a little time to figure out how to solve a particular problem on Elm but once we do, we know that we've done it in a solid way." One of the things that I think is most powerful about Elm is that it keeps you from shooting yourself in the foot. I think that's a really good headline kind of summary of what I love about Elm. For example, tweaking the DOM. Now, it might seem like a pretty obvious thing that we just won't tweak the DOM and that's fair enough. That might not be a problem for a lot of teams. People wouldn't even reach for that technique because they're disciplined about it. But at a certain point, you start taking on enough things and then go from kind of those basic things that are going to make your code more unreliable and unsafe like tweaking the DOM and you start getting into the realm of best practices. There's so much discussion these days in the JavaScript community about best practices, which is great. It's great to discuss that but my concern is that there's a new best practice each week and the team has to agree on it, you have to find techniques for enforcing it, people have to make sure that these best practices are being followed in code reviews. Then when you look at a given piece of code, you have to trust that those best practices are being followed, so it requires a lot of work to make sure, in your reducers, in redux that you are not mutating anything. With Elm, data is just immutable. That's just how it is. There are a lot of these kind of things that are baked into the language and the expressivity of the type system allows you to bake in your own constraints. One of the things that I find really compelling about Elm is its design really prevents you from shooting yourself in the foot and it gives you tools for making sure that you take it even a step further and it helps you enforce these best practices at a compiler level. CHARLES: Now what's interesting here is it's almost like the opposite tension of experimentation is a work, right? like here, we have an example of uniformity being the more powerful track but then inside the actual macroscopic process, you want a lot of experimentation and diversity. But at the microscopic level, inside your application, it sounds like you want less experimentation and you derive a lot of strength from that but -- DILLON: That's a great point. CHARLES: -- Experiments that are possible, yeah. DILLON: I think that there is a lot of pain these days in the JavaScript community. We hear people talking often about JavaScript fatigue and it's a real thing. It takes a lot of work to stay on top of the latest best practices and frameworks and that can be a lot of fun. I love learning about the latest new frameworks and tooling but ultimately as you're saying, we don't want that experimentation so much about the fundamentals. We want some dependable, solid fundamentals and then we want the experimentation to happen within there. I think that's exactly what we see in the Elm ecosystem. We have a single kind of data store or way of managing state in Elm. It's called the Elm Architecture. In fact, it's what Redux is based on and it worked extremely well and you don't have to experiment with different data stores in Elm because that's just what Elm code looks like. Now, if you want to experiment in Elm, then there is a lot of innovation happening. One of my favorite things about Elm is that the compiler and its expressiveness has sparked a lot of creativity. One of my favorite things about Elm is the library called Elm UI. Actually, a client that I'm working with right now, it's a really interesting case study. They are kind of a very small startup. They just kind of branched off of a larger startup. They're building some tooling for this ecosystem. They were engineers at a company called Procore that does cloud document management for construction companies. They wanted to get a product-ready for a big conference for their potential clients. The reason they brought me in to help them was because they wanted to reach this ambitious target of being able to do a demo of this brand new product at this conference and they wanted to iterate very quickly. One of the things that really drew them into Elm in the first place is this library Elm UI. Elm UI essentially, Richard Feldman gives a talk on it, where he uses the analogy of it being treating CSS and HTML as bytecode for your views. I think that's a really apt way to put it. If you break down this idea of CSS -- Cascading Style Sheets, it removes the cascading part of CSS and it removes the sheets part of CSS. What you're left with is a way of expressing style and it's a way of expressing style that is able to part ways with all of the baggage of the entire history of backwards compatible decisions that CSS has ever made. If you want to vertically aligned something, then you just say, "Align vertically," you know, center vertically. If you want to center something horizontally, you say center X. It creates a high level language for expressing views. My experience with Elm UI, this may not be the right choice for every team but I love it. I use it on all of the projects that I maintain personally. I love using it because it gives you that same sense of invincibility refactoring that you get with Elm, which is remarkable that you could have that feeling with managing views. CHARLES: It's definitely something that feels like a dark art and it can't be called science. It's an art. It's a science for some people but it's historically been a dark art and something fiddly to work with. In terms of being able to make the experiment with Elm, when we talked a little bit about why you might want to experiment with it in the first place, what the business case is, I guess my next question is or a question that immediately comes to mind is supposing that we have decided to experiment with this, how do you mitigate that experiment? We talked about lowering the cost, having a way to turn away from it, having a way to make it inexpensive. For example, one of the things that I think of when evaluating a new technology is how well can I use it with old technologies. I have a lot about best practices in my tool bag. We all do. We got our all favorite libraries and pathways that are just familiar to us. One of the things that I've noticed is when adopting a new technology, one of the things that makes it easy to experiment with is how well it works with the existing technologies. I know that, we talked about Elm UI, kind of rethinking style in CSS and your views and Elm itself as a completely different language within JavaScript, that can be both liberating but it can also be limiting in the sense that I can't reach back for my existing tool if no tool exists in this new space. The kind of experience that I've had where this is really worked is systems like JRuby or Clojure, where there's a very clear pathway to be able to use Java libraries from those environments, so you always have kind of an escape hatch. What's that like in Elm? DILLON: This is a really interesting conversation because it highlights, in some ways some of the most defining features of Elm. In terms of how do you kind of pull Elm into an existing application, there are a lot of different techniques for that. It's pretty straightforward to create a little Elm app. We usually don't call them components for reasons that we can get into if we want to but that's a whole can of worms. But if you've got a little Elm application that you want to use to render a widget on your page, then it's as simple as just calling Elm.yourmodule.init and rendering it onto the page there. That's quite straightforward and if you want to interface with your existing code there are several ways to do that. There's something called port in Elm, which is how you kind of communicate by sending these messages and data back and forth between your Elm app and JavaScript. Now, this is one of the decisions, I think that defines Elm as the language and the reason this is important is because Elm decided not to make the choice that a lot of other compile to JS languages do. For example, if you look at ReasonML or PureScript or a more extreme example, TypeScript. TypeScript is a superset of JavaScript, so it's trying to allow you to gradually introduce this to get some incremental improvements for your JavaScript code, so it's extremely easy to experiment with it, which we've talked about the importance of experimentation. Now, the challenge with this technique, the tradeoff here is it's great, that it then becomes very easy to transition into it and that's an excellent strategy for the goals of TypeScript. Elm has a different set of goals, so the things that elm is focused on giving you is a truly type-safe experience. When you're working with Elm, if your Elm code says that this data is a float, then it is a float. Either, it is a float or that code is not being run and so, that's very different than the experience in TypeScript where you have these escape hatches. This is an inevitable choice for any compiled to JS language. Are you going to have escape hatches or not? Elm is really the only language out there, I think that chooses not to have escape hatches and that is actually the thing that that I love about the language because that's the only way you can truly have guarantees, rather than, "Yeah, I'm pretty sure that these type guarantees hold." DAVID: Yeah, wishes and dreams. DILLON: Yeah. CHARLES: What does it mean to have no escape hatches? because you talked about ports. Does it mean like it's impossible to use an external JavaScript library? DILLON: That's an excellent question. You absolutely can use JavaScript libraries. It means that it's being explicit and upfront about the fact that there's uncertainty in these areas. That's what it comes down to. Take for example dealing with JSON. In a JavaScript application, what we get when we're dealing with JSON is you make a request up to the server, you have some callback that passes in the data you get back and then you start pulling bits and pieces off of it and you say 'response.users subzero.firstname' and you hope that none of those things are null, none of those types are different than what you expected. In a way, it's kind of letting you pretend that you have certainty there when in fact, you don't and with Elm, the approach is quite different. You have to explicitly say, "I expect my response to have this shape. I expect it to be a list of things, which have a first name and last name which are strings," and then Elm says, "Okay, great. I'm going to check your assumptions," and if you're right, then here you go and you're in a well typed-space where you know exactly what the types are and if you're wrong, then that's just another type of data, so it's just a case statement where you say, "If my assumptions were correct, then do something and if my assumptions were incorrect, then you decide what to do from there." CHARLES: Right. For me, it sounds like there is some way because ultimately, I'm going to be getting unstructured but I'm going to be getting JSON back from the server and maybe, I have some library that's going to be doing that for me and enhancing it and adding value to that JSON in some way. But then at some point, I can present it to Elm but what you just saying is I need to be complete in making sure that I handle each case. I need to do or handle the case. Explicit about saying if the assumptions that Elm wants to make, turn out to not be true, Elm is going to make me handle the case where those assumptions were not true. DILLON: Exactly. I think that TypeScript of any type is the perfect illustration of the difference. TypeScript of any type is sort of allowing you to say, "Don't type check this. Trust me here," and Elm's approach is more kind of just be explicit about what you want me to do if your assumptions are incorrect. It doesn't let you kind of come in and say, "No, I know I'm going to be right here." CHARLES: Right but there is a way to pass data structures back and forth. DILLON: There absolutely is and actually, there's a technique that's starting to gain some traction now, which I'm really excited about, which is rather than using this sort of JavaScript interrupt technique we talked about, which is again, it's very much like communicating with a server where you're kind of sending messages and getting data back -- getting these messages with data back. But there's an alternative to that which is using web components. Actually, there's quite good support for assuming that you don't need to be compatible with Internet Explorer. Basically in a nutshell, if you can wrap a sort of declarative web component around anything, it could be a Google Maps API, it could be a syntax highlighting JavaScript library, something that you don't have an Elm library for but you want to use this JavaScript library, it's actually quite a nice experience. You just render that custom element using your Elm code just as you would any other HTML in Elm. CHARLES: Yeah I like that, so the HTML becomes the canvas or composition with other JavaScript and the semantics are very well-defined and that interface is actually pretty thin. DILLON: Exactly and the key again is that you wanted to find a declarative interface, rather than an imperative one where you're kind of just doing a series of statements where you say, "Do this and then set this value and then call this and then set this call back." Instead, you're saying, "Render this Google Maps custom element," which is centered around these coordinates and has this zoom level on. You declaratively give it the bit of information that it needs to render a particular view. CHARLES: Okay. Then I guess the final question that I have around this area is about being able to integrate existing tools and functions inside of an Elm application. Because it sounds like you could theoretically develop large parts of your application, is there a way that you can actually have other areas of your application that are not currently invested in Elm still benefit from it, in the sense for kind of need of JavaScript APIs that Elm can make available. DILLON: Right, so you're kind of talking about the reverse of that Elm reaching out to JavaScript. You're asking about, can JavaScript reach out to Elm and benefit from some of its ecosystem? CHARLES: Exactly. I say that is that another potential vector for experimentation. DILLON: It's a really interesting thought. I haven't given it too much thought, to be honest but I actually have heard it come up before and my gut feeling is that it's probably more fruitful to explore the inverse, reaching out to JavaScript from Elm and the reason is kind of the main appeal of Elm is that when you're operating within Elm, you have this sense that if it compiles, it works. Because again, this central decision to not allow escape hatches is what allows you to have that sort of robustness, so you have this feeling of bullet proof refactorings and adding new features seamlessly where you change your data modeling to say, "Here's this other case that can be represented," and then suddenly, the Elm compiler says, "Tell me what to do here, tell me what to do here and tell me what to do there," and you do it and your app is working. That's the real appeal of Elm, I think and you don't really get much of that by just calling out to an Elm library from within JavaScript. That's my gut feeling on it. CHARLES: Okay, that's fair enough. On the subject of interrupt and using tools like JSON, you actually maintain a GraphQL library for Elm. You probably have a lot of experience on this. Maybe we can talk about that as a concrete case that highlights the examples. DILLON: Yeah. I think to me this is one of the things that really highlights the power of Elm, to give you a really amazing refactoring and kind of feature creating experience. A lot of Elm libraries are prefaced by the author name, so it's still DillonKearns/ElmGraphQL. I spoke about it this year at ElmConf. In a nutshell, what it does is it actually generates code based on your GraphQL schema. For anyone who doesn't know, GraphQL is just kind of a language for expressing the shape of your API and what types of data can return. What DillonKearns on GraphQL does is it looks at your GraphQL schema and it generates an API that allows you to query that API. using this library, you can actually guarantee that you're making a valid query to your server. Again, you get this bulletproof experience of refactoring in Elm where you can do something like make a change in your API and recompile your Elm code and see whether you've made a backwards incompatible change. All of this effort of doing sort of this JSON decoding I was talking about earlier where you kind of have to explicitly say, "These are my assumptions about the shape of the JSON that I'm getting back." When you're using this library, you no longer need to make any assumptions because you're able to rely on this sort of schema of your API and so you know when you're requesting this data, you don't have to run it, see if it works and then tweak it and run it again -- this sort of cycle of checking your assumptions at runtime. It moves those assumptions that you're making from runtime to compile time and it can tell you when you compile your application, it can say, "Actually, this data you're requesting, it doesn't exist," or, "It's actually called this," or, "This is actually the type of the data." CHARLES: Right. I love that. How do you do that? Because it seems like you've got a little bit of a chicken and the egg problem because the schema is defined outside of Elm, so you have to be able to parse and understand the schema in order to generate the Elm types to be able to compile Elm code against them. Maybe I'm not -- DILLON: That's exactly right. That's exactly what it does. Now, the nice thing is that GraphQL is really designed for these types of use cases. It supports them in a first class way. If you have a GraphQL API, that means you have built into it whether you know about it or not, a way to introspect the schema. All of the queries for kind of interrogating that GraphQL server and asking what types of data does this return, what are all your queries that I can run, it's built into it by the framework, so that comes for free. Getting up and running with this package I built is as simple as running a little npm CLI, pointing it to either your URL for your server or the JSON form of your schema, if you prefer and then, it generates the code for you. CHARLES: Wow, that sounds fantastic. This is the exact kind of thing that feels like it would be cool if I could just start using this library to manage the GraphQL of my application but I'm consuming that GraphQL from other JavaScript but it's the Elm code that's managing it. Do you see what I mean? DILLON: I hadn't considered that. I guess you could. You're right. Maybe I'm so smitten with Elm that it's hard to see an in-between but I guess, you could get some benefits from that approach. CHARLES: Right and as an experiment of course. DILLON: There you go. There you go. CHARLES: All right. With that, I think we'll wrap it up. Thank you so much, Dillon for coming on and talking with us on the podcast. DILLON: My pleasure. I really enjoyed the conversation. CHARLES: I actually got so many great tidbits from so many different areas of software development in Elm but also, just in kind of other things that I'm interested in trying. It was a really great conversation. DILLON: I had a lot of fun and I love discussing these things. For any listeners who are interested in this stuff, feel free to reach out to me on the Elm Slack or on Twitter. I'm at @DillonTKearns. I'm also offering a free intro Elm talk for any companies that are kind of entertaining the idea of doing an experiment with Elm. If you go to IncrementalElm.com/Intro, you can find out about some of the talks that I'm offering. CHARLES: All right. Well, thank you very much and we, as always are the Frontside. We build software that you can stake your future on and you can get in touch with us at @TheFrontside on Twitter or Contact@Frontside.io on email. Please send us any questions you might have, any topics that you'd like to hear about and we look forward to hearing from you and we will see you next week.

In part I of The Frontside's microstates series, Charles Lowell, Taras Mankovski, and David Keathley talk about state management that's easy and fun and transactionality. This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. Upcoming Conference Talks: Toronto.js - July 30th (Taras) Manhattan.js - August 8th (Taras) ReactJS Austin August 6th (Charles) Transcript: CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode 106. My name is Charles Lowell, a developer here at Frontside and I'm going to be hosting today's episode and we're going to be talking about microstates with fellow Frontside developers, David Keathley and Taras Mankovski. Welcome you all. DAVID: Hello. TARAS: Hello, hello. CHARLES: I'm really, really excited that we finally get to talk about this but before we jump into this, just wanted to let everybody know that last week, we published our roadmap for Big Test, which is a JavaScript acceptance testing framework that we've been building right here, in-house at Frontside, which can work with both Ember applications and React applications, Vue applications. It's in alpha phase and we're looking for feedback but we're really excited about it, so we're going to leave a link to that in the show notes and please go check it out. All right. Finally, the moment has come that we actually get to talk about this publicly. We've been publishing things about microstates for a while now but we feel that it's ready to share with the world and that's really, really exciting. We should probably like wind the clock back a few years because that's about how long we've been working on this and talk about, kind of the why and the what of what microstates are. It's kind of a weird word. What are we doing here? TARAS: Yes. That's interesting question because we were working for so long and after all this time, what is this specifically we're working on. I can speak personally from my personal motivations because we have conversations over the last two years to why we were doing this and I think for me personally, it's always been that I've been mentoring building complex applications for almost five years now and one of the things that I find consistently is that there are patterns for how to build complex stateful UIs that the required solutions, that are fairly reliably consistent. I can teach people certain patterns and then they can use patterns to build complex applications and those patterns scale really well, the challenge is that, there's not an easy way to express them and it's different for every framework. The way that I would teach somebody how to do it, for example in Ember versus how they would do it in React, even though the pattern itself is the same but the implementation of the pattern is different but it's different in such a way that it's very difficult to see where the consistency is, what is the same about these two patterns. It shows me that there is room for improvement. In the same way that if there is an opportunity that in the future, components will get unified under one umbrella or what component spec. The fact that we do states differently across every implementation, across every opinion, it suggests that what we might be missing is something that would unify across frameworks, how we actually do statement management. CHARLES: Yeah, that makes sense because as much as people try to buck the trend of MVC, it can't keep coming back in the rear view. Hopefully, not like a horror villain but like a caring friend, like a reliable pattern. I remember when I was in writing Java applications back in the day, the most important thing when you were writing a swing application was making sure that you had your models right. If you were modeling either a form or a dialogue or a set of pages, the most important thing was to have those models. Back in the day, we modeled those things with event listeners, very similar to where the way like a Backbone application used to work or if you're familiar with Ember Object, the way that it worked basically, adding observers to some model so that when that model change, you were able to react to that. Your representation was able to be 100% dependent on this model. That was like a Java Swing Application, which was then inherited from this pattern from Smalltalk but we keep on seeing this again and again and again. There is this piece, this state, that if you're going to be representing something, then you need to be able to get at the meat of it. That's ultimately what the model is in the MVC pattern. I remember when React first came out, everybody was like, "Oh, MVC is dead," but now in terms of state management and all of the state management solutions that we see, what that really is, is the model trying to reassert itself. Because it's such an important piece of your application, it's going to rear its head and you cannot escape it. I make it sound like a problem. I guess, it is a problem but there's a proliferation of solutions out there that are attacking the problem in order to represent something you have to know what that something is. DAVID: I think when you only work with the one framework, your perspective might be very much shaded by your experience. If you're really good at building React applications and you have subscribed to POJO is king and you don't need anything beyond that, then you're going to get good at handling POJOs and you might not realize that there is actually limitations to what you're doing. I think the same applies to people who use Ember and they're using Ember Object and they have computer properties and now, in Angular, there is observables and subscribing to streams. What was really interesting with the work that we've been doing with microstates is that and one of things that have notice with other state management solutions is that a lot of them emerge as, "Oh, I had this insight. I spend a couple of days working on it. Here's my proposal, in a way, for managing state." I think that's great because insight and understanding is really important but sometimes, taking the time to design something can be really helpful. I think that one of the things that are really interesting with microstates is that because we've been iterating on it for so long, they've been testing it for so long, we've been able to do something in microstates that's really difficult to do when you have a production application that you're like, "I want something different. Something is not enough but I don't have the time to really make it better," or, "I have an idea. I want to release this thing but I don't have any other collaborators that I can talk to and really flush out these ideas," so what you get is a solution but it doesn't always touch on a lot of the angles that you want to touch on. It's really interesting when you think about -- CHARLES: I'd say, we should talk about those angles, like what are some of those angles? DAVID: Yes. You could think about this from a few different perspectives. I would say, from Ember perspective because that's been my personal starting point. For anyone who was listening. Ember and Vue, for all intents and purposes, in this scenario are very similar because they have the same primitive, which is the computer property. The computer property in Ember, the computer property in Vue is almost identical from the way that you actually consume. In Ember, you would use computer properties and in Vue, it's just computer properties to create derived state from data that's passed into the component and then, you would use is derived state to basically, decorate information that comes with the props, so you could present it in your component. This pattern is very nice. This pattern is being used to build LinkedIn, to build applications at Apple. There are huge implications being built by Ember community using this patterns and I'm sure something similar has happening now with Vue but this pattern doesn't really exist in React in the same way. You might opt in to start using this pattern if you start using [inaudible] but it's not quite the same. Writing computer properties in Ember and in Vue is essentially free because it's so effortless, where in React, if you're using [inaudible] to create cache computer properties and memorize computer properties, you are really opting into doing a particular way of computing this properties and writing selectors that's not trivial. I think that's one thing that is available in Vue and Ember and it's a really effective pattern and you can do it in React but it's actually not possible in Angular, unless you're using, I'm guessing something like ngrx, where you can do similar things to what you would do if with redux in React. Creating derived state that you can consume in your component is one of the things that is possible but it's not possible consistently across all frameworks. That's just one of the things. CHARLES: I agree. I think that was one of the things that drew me to Ember at first coming from Backbone as I did and honestly, from the models in Java was that, in order to compute anything, you had to install a listener and then eagerly make that computation and store it somewhere, where as those frameworks, it made you feel effortless where you can just decorate some state and derive it and the information is there, the computation is there when you need to reach for it but you don't have to do expend any extra effort aside from say, "This state is derived off this other state." I think another case that I came across was immutability. Immutability is a means but the end is to have consistency inside your application. I first really started running up against this when I was working with forms and since then, I've realized that actually, a lot of the pain that I was feeling was because things were not being immutable but this is where the fact that things weren't immutable ended up causing me a lot of pain and headaches and I was having the code into being a lot more complex. Essentially, when I wanted to make something transactional if you're editing a form or something like that, then you need to essentially store off a copy of your current state. If you're editing some object, I want to say, open up a dialogue and I'm going to edit it and then I'm going to commit the changes back to that dialogue. What I'm modeling there is a transaction so I kind of need to shave off a copy or make a Xerox copy of the object and then make the changes inside to that object and then somehow, try and merge those changes upstream and then, get them back into the main lines. Really, like a very Git-like operation. It wasn't just at the object level. When you're doing things like dirty checking, you need to make what is the original value of a field versus what does the input currently have. I might be doing any number of transformations in between the actual physical representation of the field, maybe it's a date but the user interacts with it in as a string, so there has to be this kind of parsing serialize thing sitting in between that value and you need to basically, keep a copy of that field as a mini transaction within your macro transaction because you want to say like, "Is it dirty? is it really the same object?" because if you can just do an object comparison, you have to get into all that hairy like equality checking and it gets really complex really fast but it turns out that a very clean solution to this is if you just never actually make the changes in place and whenever you are making changes, you're generating new information without destroying the old information because when a form is the case where we really come up against this, where we're modeling the same object over time, so a form explicitly models the change of an object. Change is part of what it is and so, the definition of change is being able to compare something in its prior state to be able to compare it to its current state. If you're making that change by destroying the prior state, then you're going to run into a lot of trouble. It just turns out that when you're working with forms and it turns out there are a lot of use cases like this but this was the one where I first really just couldn't even... Without immutability, you want to model your change as always rolling forward and not ever destroying prior states but being able to pick and choose and can always be able to look back to where you were and compare where you are now to where you were. That's where immutability comes when you're modeling change. It's actually much easier to model change when you have explicit states that represents what was and what is. But when you start doing that, then things get a little bit messy. You have to do the compromise. There's a tradeoff, like when I say, "Set this property on this object," that is easy and that's something that I think that we can all understand. We're not idiots. That's why immutable models are very conceptually easy to grasp, to wrap your head around. If I'm modeling myself and I'm saying, "Set hand position two feet up in the air and now I'm raising my hand." That's easy to understand and it turns out that when you're changing a data structure immutably, then you have to, for example model a simple set operation as duplicate and swap. Or if say like you're swapping out one property in an array, you actually model that as a map, where you swap out the one element at that index, rather than just saying, "Just set the thing at that index," or if I'm changing a property of an object, I want to copy over all the fields except for that one which I'm going to change. If you start to do that then, you realize the benefit of always being able to look backwards but you've now introduced overhead and complexity in your code, so you've made a tradeoff. I think that's a lot of people look at saying, "I want this to be immutable," then they actually have to come to the grips with the complexity that's going to introduce. There are libraries like Immutable.js that do make that a lot better but even they have the problems. I can talk about those but one of the cases is like being able to reason about a series of states for your object, rather than just only having one copy of it ever and being stuck with having to deal with it as it is. DAVID: Yeah and I think that really important too is being able to mentally track where you've been because in my experience on other large Ember applications, I've run into so many different bugs that I could really track down to people or rather, places in the code where things are just reaching in and mutating your model, where it wouldn't make sense, so as you're writing your code, you're in a completely different state than you might have expected. CHARLES: Yes and it's easy, right? But essentially, when you have some model, you've basically got a global object. There's a lot of recomputations that needs to happen when those things change. As a result, if you look at the actual code that supports computer properties in Ember and I'm sure other frameworks as well, some of the most hairy and complex. If you look at the chain watchers and the chain nodes and all the stuff that's required to support things like computer properties, it's amazing that it works as well as it does. I've tried to actually open that up and understand that code on a number of occasions and every single time, I had to walk away in defeat. TARAS: This problem exists in React applications and Angular applications because if you think of the challenges of working with set state, I think one of the problems with working with set state in React is that your complexity increases very quickly. It starts off kind of simple when you're using immutability with set state in React. They're kind of very light and then, as you start to add features, your complexity starts to grow very quickly in a way that you really start to run into limitations. You start to confront your personal limitations of your abilities to work with immutability, so you're limited to doing immutable structures that only a few levels deep because your ability to use destructuring to create new immutable object is limited by expressiveness of JavaScript. It's gotten a lot better with the destructuring but if you do it a few levels deep, I think everybody's familiar with what happens. It starts to get really hairy. You kind of loose track of where you are. CHARLES: Yeah. The signal-to-noise ratio increases because after probably, two or three levels, the majority of your code has to do with destructuring and restructuring and very little of the actual change that you want to make. TARAS: And this is kind of interesting because people talk about declarativeness versus imperativeness but at certain point when you have a complex immutable state change, if you're doing with destructuring your code, even though it looks declarative but there is so much processing that you're doing, it's actually kind of losing the benefit of its declarativeness. It's actually starts to look more like imperative code than it does what you would expect a declarative system to look like. I think this touches on the other aspect. It kind of compromise that when you work immutably, when it compromises, you make a serialization. Your ability to represent your state as a POJO becomes restricted by the fact that you have this complex system that's wired together and you have systems like zones in Angular and in Ember Object that are able to keep track of changes in these objects but you don't have a way to restore those objects. You don't have a way to do more sophisticated things that you might want to do, especially in situations where if a service feeding you, what do UIs going to look like. In that situation, it's really helpful to be able to say, "Here's a POJO that I got from the server. I'm going to use this POJO to build this component tree that the user is going to interact with and then, as the user interacts with it, I'm going to then, capture that state, serialize it and put it back in the server." When you're using something like Ember Object or if you're doing this kind of stuff in Angular or even if you're doing this stuff with React but without using something like redux, you essentially end up doing so much wiring to accomplish that. By the time you finished writing your application, you've written a ton of code just to handle this particular use case and if you have to do this again in another application, you just rewritten that kind of code in a new application as well. CHARLES: It reminds me of the concept of a Smalltalk image, like there's no way to really get at the state of a Smalltalk thing. It's almost like you're dealing in docker containers and not actually being able to write that state down into JSON or something like that. I'm trying to casting about for an appropriate analogy. Maybe that's not a good one but what's actually happening cannot be made orthogonal. It can only exist in that one run time that you're currently running. If something wrong manifests itself, reproducing it can be extraordinarily difficult, right? TARAS: Yeah. CHARLES: Imagine if there's some render cycle that's making a bunch of mutations and there's this process that you stood up and it runs in completion, some signal comes in and those effects are like ripple through the system, there's no way at any point to have any other representation of that system than the running system itself. TARAS: There's another element to this, which I find really interesting. When you're thinking about how to architect complex UIs, it's actually helpful to get really clear about what kind of changes are happening. A lot of times when I want to see beginners are writing, especially if you task someone who is a fairly junior at building a single page applications, a lot of times what will happen is because they don't have a clear mental model of what is going on in regards to state. They end up setting a lot of properties. Every operation, every time you have an event handler because they don't have a clear model of what's going on, they end up setting like five or six or seven properties. That kind of signals that they don't have a clear picture but what that also does is a lot of times, they usually comes together with cascading state changes. Usually they're not representing a single operation as a single state change because there might actually be a bunch of things that are happening because what they're doing is they're massaging the system into submission. Not like they're not in control of the state transitions, so they use, essentially time and their dedication to kind of sort it out and make it work and eventually, would that ends up looking like that if it works for most of the cases that they are able to test for or that they able to manually see. But then they AR, not accounting for problems that they're not able to understand right now, they become discovered by users when users start to interact with the system and with the components or with that application and the application is there to get into some funky states. The tools that we have, they don't prevent that from happening. They just -- CHARLES: Right. They don't force you. I think what you're saying is that ideally, you want to model your UI as a set of transactions on your state, that you want transactionality to your state so that I basically am saying, "I'm not going around and setting seven properties in reaction to this one event." I'm saying, "This event triggers this transaction and that transaction clearly bundles up every single operation that needs to happen and the tools don't enforce that." Is that a fair --? TARAS: Yeah and then, the problem is we're working with component trees. You start off with having a set of requirements and over time, the requirements change. As the business unit understands your application better, they give you more direction of how accounting should work and then you find out that there's more interconnect at stake but then what's happening now is that the cost of refactoring those state that spread throughout the components, whether that be with set state, whether that be with the actions in Ember or even in Angular. What you end up doing is you start to change the system but change is not trivial because the actual process of changing where that state lives is not linear. It depends on the complexity of the code that you wrote and it just gets really hairy very quickly. That's where companies end up losing a lot of time. A developer could start off with a requirement, you build something and then a new requirement comes in and instead of it being a simple change, it turns into a week or two weeks refactor because you now understand the state ownership should be different. The state that you have should be in a different place. You have to manually make that change. You have no obstruction to help you express that in an easy way. CHARLES: Another thing, because we are doing a kind of a roundup of all the things that you need to account for when you actually embark on managing your state. Another is actually constraining the amount of computation that happens. If your system is based on listeners and large chain reactions of things where it's like, "This property changes so I need to notify these other 10 dependent properties that change." You can do a lot of unnecessary computation, especially if nobody is going to render. That's kind of the thing that you have to do if you're going to be immutable. You have to eagerly walk those change to see which objects are affected so that you can then invalidate those caches. A system like Ember Object, I don't know exactly how Vue works, it mitigates this somewhat by the fact that the computer properties are lazy but you still have to walk all of those chains. That can actually get out of hand. They're eager, not lazy. Then the other concern that you have, where you normally have to make a trade off around is around composability. One of the things that's really nice about immutable systems is they're very composable. If I've got some object that does one thing, I can then just set that object onto another object just by mutating one of its properties and I've effectively composed them. I can then install listeners onto that thing or I can compute properties off of that property and they can post pretty well. That's something that you get but then of course, you're losing all of the benefits of immutability, so things like Immutable.js don't really compose very well or redux doesn't really compose very well. The concept of taking a redux store and embedding it into another redux store, you just don't see that. I would never distribute and I think ultimately, the litmus test there is would I be able to share it on something like npm. Nobody shares an npm package that's just a redux store that you can dispatch actions to and observe and use it with your other redux stores. When it comes to a system like Immutable.js, that does make transitions a little bit easier over lists and arrays and maps but you still run into the exact same set of problems that you have when you have lists of maps of records and you don't really get any help there, so you have to make this tradeoff between immutability and composability, whereas a system like MobX or Ember object actually quite composable. Before we start talking about microstates, I want to say that you just throw those in there because there is just a lot of concerns out there, a lot of edge cases that actually build up but through the course of a real application, you will encounter them all. You might be making tradeoffs at the beginning that you're not realizing that you're going to need or are going to get you into trouble later on. DAVID: This actually happens in the Angular community as well because there's something really great that's happening with observables in the Angular community. I think everyone's embracing them wholeheartedly and I think that's really been pretty great to see but observable streams of composable, but objects that have on them observable stream providers of some kind, like if you have something that you can subscribe to and that is part of a property in a class, composing multiple classes together and consuming properties from those classes, there is no mechanism for composing that. That kind of composition has to be done manually. Again, you're kind of manually wiring together a bunch of objects and the big challenge is that you are manually subscribing to all those streams and unlike what you have with components. Components have lifecycle hooks. When your components is being torn down, you know you can perform some operations. If you need to remove an event listener, you have a hook where you can do that when you have a class instances like JavaScript class instances that have on them properties that have observables that you subscribe to. There are no tear down hooks for class instances, so there are no obstructions from managing unsubscribing from those streams. You essentially end up having the foundation that you can use to build complex reactive systems and you can subscribe in there really fast but wiring those things together at a bigger scale is simply not there. It's something that you have to create and enforce yourself. CHARLES: Right and I think that's probably a perfect segue into talking about microstates, which is the project that we've been alluding to for the past 30 minutes, that is I think in attempts to solve these problems and make sure that you don't actually have to compromise on those things, so you can reason about things locally but have those things be composed into a greater state. But also have them be immutable so that you can look at past states and reason over a data structure over time as opposed to just in one instance. Also, have an intuitive interface that when you're making these changes, doesn't look like half of your code is unpacking some data structure, flipping some bit in it and then repackaging it back up again. That's the context. Should we start talking about what microstates is and how it addresses those? TARAS: That's a good next step and when I start working in the ReadMe, I end up actually, I think I wrote about 40 pages. One thing that's interesting about microstates is that and this was part of the design of microstates from the work that we've done is that we intentionally wanted to make the number of ideas that you haven't microstates very little, so when you use microstates, the number of concepts that you need to remember in your mind is very few. It is a conceptually a different way of thinking about organizing your state in the same way that shifting from managing DOM elements directly to having an obstruction like component that declaratively applies changes to your DOM tree. In a same way, microstates is kind of an abstraction that allows you to declaratively describe how your state will change and it will manage the transitions for you and allows you to give the state transitions names and it allows you to give your states names as well, so you can actually name things. You don't get a POJO that has a shape but has no name. You actually get to give things names. CHARLES: So, why don't we start? I have a list in my mind. I should probably write it down of the things that we just talked about but I think the things that we talked about are ease of representation, like conceptually easy, transactional, basically serializable and immutable, lazy and composable. Those are like five or six things. But I think there are kind of aligning principle around which we gathers that the state management should feel easy. It should feel fun. One of the things that is awesome about working with components, whether you're using web components or React components or Ember components is when you get it right, you're just snapping these things to feel together and it feels great. It's like I'm just passing properties and render blocks down the tree and the framework is just doing all of the grunt work for me and I'm just operating at a very high level. That's what organizing principle with microstates as it needs to feel easy. Maybe we should start there and just say, how does that easy and fun line up with each one of those kind of unique problems around which we typically have to make tradeoffs? We could start with the interface of making a change. TARAS: I'll go back to the starting point. I remember what got me first interested in microstates is Charles, when you said that, when you have a number, there are certain operations that a number can do. We really don't need to be writing an increment operation for every... Like if you a have a number, you can increment it and decrement it. CHARLES: Honestly, every time I see state management tutorial and they tell you how to increment and decrement a number with it and you write the increment code and you track the thing and you store it back into the store, at this point I'm still annoyed with those tutorials because I'm like, "It's a number. We know we can increment it. Just show me where to plug in the code. I should not have to be writing an increment method." TARAS: Yes. And that's the kind of starting point. There are certain operations that you can perform with the primitive types. If you need to add a number or if you increment a number, we already know how to increment the number. It's part of microstates. But that in itself is nice but that's not that important. I think what's really important is that when you need to put a number into another data structure, let's say you have a nap and you're like, "I need to..." I don't know -- CHARLES: Let's say, like a click tracker that has a number of clicks. TARAS: Right. By itself, you can increment the click tracker but if you need to put a quick tracker into another app, essentially you can compose it in and you don't need to figure out how to wire the actual mechanism of how to make sure that you can update the property, like it's part of another class, for example, you don't need the way you would increment the number. When it's a part of another class versus how you would do it when you're working with it by itself is an approximately the same. The amount of work that you need to do to actually perform that operation is the same. Your complexity doesn't increase as you compose one data structure into another. CHARLES: Right. You can just say, "This is an app. It's got a click tracker and this property is a click tracker and I have to do nothing else. I can register clicks on that thing. It doesn't increase the complexity of application at all." TARAS: There's no wiring. Now, you added some new state, that state is very explicit and it's really clear that it is not impacting other parts of the state. You can operate with this thing. If you change it, it's going to work properly with all the other things that are in the type that you are adding this counter to. Those things are just going to fit well together and it's not going to break if you need to transition one more thing. All of the other transitions will work the same way. I think that kind of consistency is really meaningful, over time especially when you start to increase the amount of state that you manage in your application. CHARLES: Just the ability to work with types and just have kind of those implicit operations and have those things compose, kind of indefinitely. Moving down, we talked about easy and the other thing I would put on that is that the way in which you express those transitions, for example if microstates comes bundled with numbers and Booleans and strings and arrays and objects and kind of the stable of types that you would expect in any JavaScript application but those types are expressed using this way for expressing types, essentially. When you actually do make a transition, it feels very object-oriented, I would say, even though it's not. It feels like you're mutating but you're actually doing a transition. Does that make sense? TARAS: I think for anyone who is familiar with what it's like to write queries for GraphQL, if you're not familiar with it, it's fine. You can get a sense of that from microstates but if you're familiar with the ease of just writing a query and if your backend knows how to retrieve the data, then your queries will just give you the data that you want. That feeling is really powerful and just being able to write the query and just gives you what you want. Microstates is kind of like that. Actually, the inspiration came from experiences with GraphQL, which is that sense of ease is what we wanted to have in microstates and so you get that seems sense of like, "I can just do what I want and it just going to work and with this other thing and it just going to work," and you're just like flying through, like adding states to your application and it's just working for you and working for you and working for you and you don't have to do monkey work like gluing things together. It'll change how you are working before because you have a way of opt working with these things at a higher level. CHARLES: Right. Let's talk about transactionally or should we talk about immutability? How does this make immutability easy and fun? TARAS: I think one thing is that you don't have to write reducers and you don't have to do destructuring by hand. I think you have a way of expressing. Thinking about this, if you have a component tree and let's say you have redux and then a bunch of components like your parent component, your root component has some state using sets date and then components further down the tree also have state. You could actually express that as a microstate. What you would do is, essentially the parent component state would be the root and then the children's component states would be composed into it. The nice things about doing that is that at the root level, you have access to transition state of the children declaratively. You know where the states for those children is on the route type and you can write transitions that are going to declaratively perform multiple operations on the children state and I suppose it'll restructure to what happens with components but if you don't use this, you might have multiple sets date operations. The process of wiring data from the root down to the children is kind of complicated, where here, you have a way to represent that and perform a lot of transitions in the way that is going to be just easy at whatever level you need to operate at. CHARLES: Right. I think, for people familiar with redux, in redux you act globally and then you react locally, if that makes sense, so you dispatch an action to the entire store and every single reducer can see that action. There's ways to manage that but effectively, you have this one atom and then you have the reducers that kind of act on local state, whereas with microstates, you're basically acting locally. You're reacting locally but the effect is global. TARAS: You're participating globally. CHARLES: Yeah, participating globally but you never have to consider the context that is above your own, so you never have to be mindful or cognizant of the context in which you're enclosed because from your perspective, it just doesn't exist. DAVID: Every microstate has a set transition which is the basic transition that you can invoke, essentially in any type, so what's interesting is that it's amazing how powerful -- CHARLES: So, we should break it down really simple. Basically, when you create a microstate, with a type, you say like, "I want to create a number with the value five," and then I can just say, "That returns a microstate," and I can say, "microstate.set 10," and that will return a new microstate who's also a number but the value is 10 and that's available on all microstates. DAVID: Yes. If you have a tree of components and your state is presented by a microstate at the root level, then what you can do is you can invoke the transitions on any part of the microstate and it will just know how to properly create the next microstate for you. The example that Charles you gave of one number so that number can be inside of a class that represents state for a particular component and then that can be a part of another class or represents a state for another component but then, when you invoke a transition on one of the leaf nodes, an equal sets state on one of the leaf nodes or equal set on one leaf nodes, it will respond locally but it will actually reflect the changes globally. At the root level you're going to get a new object that causes the components to update. CHARLES: You know what? I have another concern that actually just popped into my head, which is something that I've certainly struggled with in every single application of notable complexity is stability of value. We should put that on the list. We're almost out of time to talk about this. We spend too much time... Well, not too much time, of the issues of state management, which I think you can't spend enough time talking about but I did want to pile one more on there is when you're making that transition, where you're acting locally but you're participating globally. For things that are unaffected by your action, remain unchanged. That is a super power. It's actually very hard to do with a lot of state management, especially when you're cloning a bunch of stuff, being very judicious about what you don't want to clone. Where this really comes into play is if I want to re-render something. A lot of times you have to jump through a bunch of hoops to tell, did my model really change or did only referentially change? With microstates, when you make that local change, if you're embedded in a very large graph of objects, obviously all of the objects above you are going to be changed but what about things that are off to the side of your siblings. They're outside of that scope of that change. They shouldn't be cloned. They shouldn't be copied over. They should remain the same. If you're doing a re-rendering based on the changes that are happening, that's going to be a key feature because you're not going to have to write, basically any hooks to say, should I have to re-render my component. You can always rely on triple equals. DAVID: This quality is going to describe the structural sharing and some of the other tools that are available but I think that's how it's accomplished. I think one thing that's a little bit different with microstates is that when it comes to structural sharing, it's not that difficult to do if you just do structural sharing and value. Meaning that you can do structural sharing on a value using something like lenses and not a lot of people are familiar with lenses in JavaScript but it's actually only three functions that you can use and it can give structural sharing on complex POJOs. It's pretty easy to use relative to how little people know about it but what that doesn't do is it doesn't allow you to graph of objects that have their own operation that you can invoke and that will perform structural sharing. That part, I know that is not available in any solution, I think at the level of completeness and luxury that microstate provides when you write things. CHARLES: Right because every piece of the tree kind of comes bundled with its own things that you can do with it. DAVID: I don't think you should jam everything into this podcast because there's a lot to talk about it. I think one of the things and we've talked about this a lot, which what we want to do is create an implementation for an idea of what it would look like. What would it be like if we had a composable state primitive that we could use to describe state and share state solutions in the same way that we share components like react-virtualized or whatever your particular frameworks or popular component may be. What it would look like if we had solutions to state problems that we could share and we could -- CHARLES: I think the litmus test of an awesome solution is like you look at this current crop of MVC frameworks and what's so awesome about it is they're sharing. That can happen, right? If I'm writing a React component, I can publish it on npm and other people can use it. If I have an Ember add-on, I can publish it and people can use it. They can consume those components. That's awesome and I think it's the hallmark of a great system. What would it look like if I wrote just the state piece of a file upload and I could publish it npm and then anybody, in any framework, could actually use it with their framework without paying any penalty. What would it look like if there was some transactional data store that could be built and shared and the hooks into any framework were minimal. The possibilities are really exciting around that idea, whether it is realizes microstates or not. But clearly, we feel this is something you should be able to do. DAVID: I'll add one more use kind of use case that I personally find really motivating is that there's a lot of companies that are investing into building single page applications and a lot of times, what you see happening is they're building a very similar application to what they had before because their business hasn't changed. The technology has moved on so solutions have improved. The demands for better user experience have increased but the actual business and how the things that people have to do on day to day within their company hasn't changed. What we're seeing right now is we're seeing the same, like whatever was written before in jQuery or an AngularJS is now being rewritten in React or Angular or whatever you might Choose. But whatever you like to see is it has a situation where the domain specific logic of your business is represented as a data structure that knows how to, potentially, in the future talk to the server and retrieve data from the API because that's likely not going to change. But you can use that like that's been tested and published as an npm module within your enterprise and then you can then consumed that in any framework and it's actually easier to do it this way, than to implement it in a framework-specific version of their state management. That's the part that I find the most exciting. I think one of the things, just to connect to the goal is that, we would like to keep this conversation going. If you're interested and I think this is a kind of a call to our audience that if you're interested in this, we would love to have in our podcast to talk about these things because I think there's a lot of things that microstates really is a beginning of a conversation. It's not meant to be a statement. It's meant to be a proposal that we can just talk about this. CHARLES: I agree and that's one of the reasons we're keeping it very small at this point. The core library of microstates is not setting out to accomplish too much. In the core library, there aren't even any side effects. It's actually impossible to have side effects. It means that it cannot be used for anything except for the model but that's very liberating and it let us focus on what would a system like this actually look like. DAVID: It's really exciting because this has been the biggest metric but we have microstates in the JavaScript weekly and that was great and then it got circled around when people know and it's like 800 stars now, which is not a really big deal. It's funny because somebody commented like, "How can you put something in production that only had 100 stars?" CHARLES: I think it's just important to realize that this really is the beginning of a conversation. There's a really exciting set of things to come. We haven't even talked about how we're going to model side effects, although we're going to use microstates to do it. We haven't even talked about what the various framework integrations will look like and what are the best practices for using this to organize state in your application. We've had some lively discussions internally about what that looks like. There's still a lot of questions but it's going to be a really, really exciting and edifying experience to get to answer them. DAVID: Yeah, it's pretty exciting. I'm excited too. There's been a lot of interest from people in microstates, so it's going to really great. I'm looking forward to meeting people and having conversations about how we can use microstates because I'd love to have someone create a really great solution that I could just take off the shelf and just use and not have to implement them myself. CHARLES: All right. Well, I think we could talk about microstates for at least the next three hours but we have to give everybody an opportunity to, at least like go to the bathroom or something. Microstates will return but if you're interested in learning more about microstates and you happen to be in one of the many places on which we're going to be presenting on microstates in the future, who knows? Maybe you can come in and join the conversation in person. Taras is going to be speaking at Toronto.js on July 30th. He's also going to be presenting at Manhattan.js on August 8th and then, yours truly will be presenting on microstates at React.js Austin on the 6th of August. Come out and see us. We'll drop those in the show notes and it's guaranteed to be a good time and we'll have that conversation. Until then, we are the Frontside. We lead with the why, the how and then the what, if you're interested in working with us and that helps us that we guarantee the lowest total cost of ownership for your application. We're always looking for feedback. If you have news items that you'd like to see at the head of the show or just any feedback or questions, we would be happy to answer them. Thanks today to Mandy Moore for producing our show and next time, we'll be talking with Kristian Freeman about what it's like to run an online conference with Twitch, so I'll be looking forward to that. Bye David. Bye Taras. DAVID: Yeah, thanks for having us. TARAS: Bye. CHARLES: Yup, and bye everybody. See you next time. Next Time: Running An Online-Only, Free Conference on Twitch with Kristian Freeman

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.

Summary This week the crew is joined by Lars Knudsen (@denladeside) and Kenneth Christiansen (@kennethrohde) to talk about the recent Polymer Summit and all of the awesome stuff revealed there. Are web components really ready? Who is using web components? Answers to these questions and more on this week's episode of the Web Platform Podcast. This Week in Web News YouTube has just had a new UI released which is written in Polymer Stenciljs, “The magical, reusable web component generator.” announced at the Polymer Summit appears to be making waves in the Web Component community and we've just scheduled a podcast episode with the developers which should be released in the next couple of weeks! Node.js has been forked again over complaints of unresponsive leadership. The new project is called Ayo and is already available on GitHub: Google has just released a preview for ARCore and WebARCore for AR development on Android and on the web Apple has published guidelines for building Augmented Reality Interfaces to aid developers using ARKit Since last week four more frameworks have been added to custom-elements-everywhere, a website which scores JavaScript frameworks on their compatibility with Custom Elements. The frameworks what have been added include AngularJS 1.x, CanJS and Dojo 2 Resources User interface components for web apps All Polymer Summit 2017 talks Guests Lars Knudsen (@denladeside) Kenneth Christiansen (@kennethrohde) Panel Danny Blue (@dee_bloo) Leon Revill (@revillweb) Amal Hussein (@nomadtechie)   Follow The Web Platform podcast on Twitter for regular updates @TheWebPlatform.

What does it take to keep AngularJS moving forward? Carl and Richard talk to Jules Kremer about her work as the head of Angular Developer Relations at Google. Angular started out as an internal library at Google and is widely used all over the organization. But as it's popularity grew, the outside world became interested in it also. Jules talks about learning how the rest of the world uses Angular and the role that played in the significant shift that happened in Angular 2, including the move to TypeScript, becoming more opinionated, and so on. The conversation also goes to the future of Angular, including the focus on Progressive Web Apps and a great set of docs. Oh, and we give away $5000 worth of technology to one lucky member of the .NET Rocks fan club!Support this podcast at — https://redcircle.com/net-rocks/donations

So what JavaScript libraries are you focused on today? Scott Allen is back to talk about the latest bits he's excited about, including Rob Eisenberg's Aurelia! The conversation starts out focused on the on-going evolution of Javascript, with ECMA 6 and 7 picking up more and more features of modern programming languages - it's not the JavaScript you remember from the old days! This also impacts JavaScript libraries and opens the door for the on-going evolution of those libraries. Some change radically like AngularJS and some stick with their patterns so that new tools can get built, like Aurelia. While it's still early days for Aurelia, Scott is so keen that he's dived in as a contributor to the open source product. You should check it out!Support this podcast at — https://redcircle.com/net-rocks/donations

Are you building in WPF? Are you using PRISM? Carl and Richard talk to Brian Noyes and Brian Lagunas about the PRISM project, which is a set of tools for building WPF apps. As Brian Noyes says, PRISM is the AngularJS of WPF! The conversation dives into the on-going evolution of PRISM, including support for Windows Phone and Universal Apps. The point of PRISM is composability, helping you to organize the elements of your application into something more maintainable, easier to test and continue to evolve. Brian and Brian also announce that they are running the PRISM project now and have moved it to GitHub - they will take your pull requests!Support this podcast at — https://redcircle.com/net-rocks/donations

So what comes after Durandal? Rob Eisenberg talks to Carl and Richard about Aurelia! The conversation starts out focused on AngularJS and Rob's role with the open source project and ultimate departure. But that was back in November 2014 - what happens next? Aurelia is Rob's vision of what web developers need to build effective browser-based client applications. Rob talks about implementing Aurelia to utilize ECMAScript 6 and 7 while still polyfilling back to ES5 - the Javascript you recognize. This leads to a whole discussion on transpiling and how its possible to move a language forward without breaking backward compatibility, even a language as diverse as Javascript!Support this podcast at — https://redcircle.com/net-rocks/donations

Ready to think beyond the SPA? John Papa talks about the continuing evolution of HTML 5. Carl and Richard chat with John about web components, an evolving standard to make JavaScript libraries more extensible and organized. AngularJS comes out in the conversation as well, especially version 2 with its breaking changes - but you don't need to migrate if you don't want to. V1 will continue development. John also digs into his current suite of tools for building, deploying, and debugging web pages. The technology is maturing, and that means better tools!Support this podcast at — https://redcircle.com/net-rocks/donations