Podcasts about react redux

All JavaScript Podcasts by Devchat.tv

Play Episode Listen Later Feb 4, 2020 43:52

My JavaScript Story this week welcomes Paul Cowan. Paul works as a consultant in front end development. He learned how to program at a really early age but didn't own an email address until he was 30 years old. When he was 30 years old he wanted to change his lifestyle and attended a course in London and took a job as a software developer. Paul was interested in React because, for him, much of programming didn’t make a whole lot of sense until he read about the flux model and React Redux was one of the few frameworks that followed the flux model. Spending most of his life outside of the programming world has granted him a unique perspective framework like React. Host: Charles Max Wood Joined By Special Guest: Paul Cowan Sponsors G2i CacheFly ______________________________________ "The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today! ______________________________________ Links RRU 088: Frustrations with React Hooks with Paul Cowan Paul's Twitter Paul's Blog Picks Paul Cowan: https://blog.logrocket.com/ Fitness and MMA Fight Charles Max Wood: "#100daysofvue" Vue Learning Challenge @ Devchat.tv YouTube Channel https://www.youtube.com/channel/UCABJEQ57MIn6X3TIHIebJUw/videos Devchat.tv Upcoming Workshops: "How To Stay Current" "How to Find Your Dream Developer Job" "How to Start a Podcast" Sign up for the newsletter @ https://devchat.tv/subscribe/ to receive information about our upcoming workshops

amazon fitness blog spending react frustrations mma fight cachefly devchat react hooks charles max wood paul cowan react redux react native radio finding your dream developer job maxcoders guide rru my javascript story

MJS 135: Paul Cowan

Play Episode Listen Later Feb 4, 2020 43:52

My JavaScript Story this week welcomes Paul Cowan. Paul works as a consultant in front end development. He learned how to program at a really early age but didn't own an email address until he was 30 years old. When he was 30 years old he wanted to change his lifestyle and attended a course in London and took a job as a software developer. Paul was interested in React because, for him, much of programming didn’t make a whole lot of sense until he read about the flux model and React Redux was one of the few frameworks that followed the flux model. Spending most of his life outside of the programming world has granted him a unique perspective framework like React. Host: Charles Max Wood Joined By Special Guest: Paul Cowan Sponsors G2i CacheFly ______________________________________ "The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today! ______________________________________ Links RRU 088: Frustrations with React Hooks with Paul Cowan Paul's Twitter Paul's Blog Picks Paul Cowan: https://blog.logrocket.com/ Fitness and MMA Fight Charles Max Wood: "#100daysofvue" Vue Learning Challenge @ Devchat.tv YouTube Channel https://www.youtube.com/channel/UCABJEQ57MIn6X3TIHIebJUw/videos Devchat.tv Upcoming Workshops: "How To Stay Current" "How to Find Your Dream Developer Job" "How to Start a Podcast" Sign up for the newsletter @ https://devchat.tv/subscribe/ to receive information about our upcoming workshops

amazon fitness blog spending react frustrations mma fight cachefly devchat react hooks charles max wood paul cowan react redux react native radio finding your dream developer job maxcoders guide rru my javascript story

MJS 135: Paul Cowan

My JavaScript Story

Play Episode Listen Later Feb 4, 2020 43:52

My JavaScript Story this week welcomes Paul Cowan. Paul works as a consultant in front end development. He learned how to program at a really early age but didn't own an email address until he was 30 years old. When he was 30 years old he wanted to change his lifestyle and attended a course in London and took a job as a software developer. Paul was interested in React because, for him, much of programming didn’t make a whole lot of sense until he read about the flux model and React Redux was one of the few frameworks that followed the flux model. Spending most of his life outside of the programming world has granted him a unique perspective framework like React. Host: Charles Max Wood Joined By Special Guest: Paul Cowan Sponsors G2i CacheFly ______________________________________ "The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today! ______________________________________ Links RRU 088: Frustrations with React Hooks with Paul Cowan Paul's Twitter Paul's Blog Picks Paul Cowan: https://blog.logrocket.com/ Fitness and MMA Fight Charles Max Wood: "#100daysofvue" Vue Learning Challenge @ Devchat.tv YouTube Channel https://www.youtube.com/channel/UCABJEQ57MIn6X3TIHIebJUw/videos Devchat.tv Upcoming Workshops: "How To Stay Current" "How to Find Your Dream Developer Job" "How to Start a Podcast" Sign up for the newsletter @ https://devchat.tv/subscribe/ to receive information about our upcoming workshops

amazon fitness blog spending react frustrations mma fight cachefly devchat react hooks charles max wood paul cowan react redux react native radio finding your dream developer job maxcoders guide rru my javascript story

RRU 088: Frustrations with React Hooks with Paul Cowan

Play Episode Listen Later Nov 19, 2019 66:50

Paul Cowan was a painter and decorator for 30 years until he switched to front end development. He got into React because for him, much of programming didn’t make a whole lot of sense until he read about the flux model, and React Redux was one of the few frameworks that followed the flux model. Spending most of his life outside of the programming world has granted him a unique perspective frameworks like React. He talks about some of his frustrations with React hooks. Hooks can be frustrating because it’s a new paradigm to learn JS, the dependencies array can get bungled, React relies on the order in which hooks are called, and closures can be difficult. Overall, hooks come off at deceptively simple. Paul believes that we shouldn’t need external tooling to keep the dependency array on the right track. To avoid these frustrations, Paul reminds listeners that hooks have to be called in the same order each time at the beginning of your functional components. You also cannot have a hook in an if statement or event handler. It’s also important to remember the declarative nature of React. In production code, updating states is the best way to go. The panel agrees that it’s good that react has clarified their position on what hooks are supposed to be used for, and how we are beginning to see the limitations of React hooks. They discuss unit testing with hooks and how to determine when the React framework becomes too big. They talk about some of the new features that are coming out and how they benefit new developers. When mistakes do happen, Paul talks about how he determines what went wrong. If you want to get advice from other humans, they suggest consulting StackOverflow, ReactiveFlux, and IRC chat. When you do consult these sources, it’s important that your problem is reproducible so that it’s easier for people to help you out. It’s also important that you learn how to ask questions. The show finishes with them discussing how they handle changes in the industry. They have found that reusing components is difficult across Angular and React. They talk about the positive ways that React went version to version. They discuss complexity management in apps. The panel talks about some ways to do things in React without hooks, but also caution that avoiding the popular thing can also get you into trouble. Panelists Thomas Aylott Charles Max Wood Chris Reyes Guest Paul Cowan Sponsors Nrwl | Nx.Dev/React Sentry | Use the code “devchat” for $100 credit _______________________________________________________ "The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood will be out on November 20th on Amazon. Get your copy on that date only for $1. _______________________________________________________ Links Flux model React Redux useReducer Frustrations with React Hooks Solutions to Frustrations with React Hooks ESLint Next.js Relay Selenium StackOverflow ReactiveFlux Picks Thomas Aylott Shada Charles Max Wood The MaxCoders Guide to Finding Your Dream Developer Job It’s A Wonderful Life Mr. Kreuger’s Christmas Chris Reyes Netlify React Hooks deep dive AirPods Pro Paul Cowan Solutions to Frustrations with React Hooks Stay fit

christmas amazon spending react banner wonderful life frustrations flux panelists hooks relay js irc angular sentry stack overflow nx selenium shada kreuger eslint react hooks charles max wood paul cowan react redux finding your dream developer job maxcoders guide nrwl

RRU 088: Frustrations with React Hooks with Paul Cowan

Working Draft » Podcast Feed

Play Episode Listen Later Nov 19, 2019 66:50

Paul Cowan was a painter and decorator for 30 years until he switched to front end development. He got into React because for him, much of programming didn’t make a whole lot of sense until he read about the flux model, and React Redux was one of the few frameworks that followed the flux model. Spending most of his life outside of the programming world has granted him a unique perspective frameworks like React. He talks about some of his frustrations with React hooks. Hooks can be frustrating because it’s a new paradigm to learn JS, the dependencies array can get bungled, React relies on the order in which hooks are called, and closures can be difficult. Overall, hooks come off at deceptively simple. Paul believes that we shouldn’t need external tooling to keep the dependency array on the right track. To avoid these frustrations, Paul reminds listeners that hooks have to be called in the same order each time at the beginning of your functional components. You also cannot have a hook in an if statement or event handler. It’s also important to remember the declarative nature of React. In production code, updating states is the best way to go. The panel agrees that it’s good that react has clarified their position on what hooks are supposed to be used for, and how we are beginning to see the limitations of React hooks. They discuss unit testing with hooks and how to determine when the React framework becomes too big. They talk about some of the new features that are coming out and how they benefit new developers. When mistakes do happen, Paul talks about how he determines what went wrong. If you want to get advice from other humans, they suggest consulting StackOverflow, ReactiveFlux, and IRC chat. When you do consult these sources, it’s important that your problem is reproducible so that it’s easier for people to help you out. It’s also important that you learn how to ask questions. The show finishes with them discussing how they handle changes in the industry. They have found that reusing components is difficult across Angular and React. They talk about the positive ways that React went version to version. They discuss complexity management in apps. The panel talks about some ways to do things in React without hooks, but also caution that avoiding the popular thing can also get you into trouble. Panelists Thomas Aylott Charles Max Wood Chris Reyes Guest Paul Cowan Sponsors Nrwl | Nx.Dev/React Sentry | Use the code “devchat” for $100 credit _______________________________________________________ "The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood will be out on November 20th on Amazon. Get your copy on that date only for $1. _______________________________________________________ Links Flux model React Redux useReducer Frustrations with React Hooks Solutions to Frustrations with React Hooks ESLint Next.js Relay Selenium StackOverflow ReactiveFlux Picks Thomas Aylott Shada Charles Max Wood The MaxCoders Guide to Finding Your Dream Developer Job It’s A Wonderful Life Mr. Kreuger’s Christmas Chris Reyes Netlify React Hooks deep dive AirPods Pro Paul Cowan Solutions to Frustrations with React Hooks Stay fit

christmas amazon spending react banner wonderful life frustrations flux panelists hooks relay js irc angular sentry stack overflow nx selenium shada kreuger eslint react hooks charles max wood paul cowan react redux finding your dream developer job maxcoders guide nrwl

Revision 401: React, Redux, Hooks und HOCs

Play Episode Listen Later Nov 6, 2019

Hans und Peter diskutieren über Patterns in React! SCHAUNOTIZEN [00:01:25] REACT, REDUX, HOOKS UND HOCS Redux-Hooks werden ein offizielles Feature, was Hans und Peter zu einer Grundsatzdiskussion …

patterns hans feature react redux revision hooks react redux

Revision 401: React, Redux, Hooks und HOCs

Working Draft » Podcast Feed

Play Episode Listen Later Nov 6, 2019 54:51

Hans und Peter diskutieren über Patterns in React! Schaunotizen [00:01:25] React, Redux, Hooks und HOCs Redux-Hooks werden ein offizielles Feature, was Hans und Peter zu einer Grundsatzdiskussion über Patterns in React verleitet. Hooks (siehe Revision 385) wurden vor nicht allzulanger Zeit in React eingeführt und haben sich seither in diversen Code Bases breit gemacht – nach […]

patterns hans feature react redux revision hooks react redux

RRU 082: Progressive SSR with Dinesh Pandiyan

Play Episode Listen Later Oct 8, 2019 50:20

Dinesh Pandiyan is a developer from India. He started as a backend engineer and then moved to frontend. Currently he is working for ThinkMill in Sidney, Australia. Today Dinesh and the panel are talking about devtools and progressive SSR. Dinesh got started with React Redux. The panelists talk about their experiences using primarily Redux for projects. Dinesh talks about his transition from backend to frontend and how it’s a totally different world. On the backend he was working in Java and it ran on a server, but on the frontend, code runs in a browser and the browser is very different for each user. Frontend development is tricky because you don’t know where your code is going to run. One of the trickiest parts of frontend development is debugging something in production. Unless you have good logging tools, you won’t know what’s going on. Debugging this stuff when it’s running on client browsers is hard, but when you’re in development mode your own browser you’ve got handy tools. They talk about some of the tools in React, and agree that console.log is the greatest debugging tool of all time. Dinesh talks about some of the most surprising features about React dev tools. You can benchmark your preferences and identify weaklings in your project, which are things that slow down your application or things that might slow it down. On an application level, you have to build a mental model of how the data flows from the top, where things change, etc, and dev tools can help you build that pretty easily. They talk about how things had to be done before great React tools. In fact, Dinesh chose React just for the devtools. They talk about how the dev tools for React compare to Java. The most important thing is that you have a good debugger that can stop where you want it to. They transition to talking about the differences between SSR and progressive SSR For SSR (Server Side Rendering), rendering happens on the server and you send it to the client. CSSR (Client Server Side Rendering) is when all the rendering happens on the client’s side. PSSR (Progressive Server Side Rendering) is where you render small chunks on the server and then send it to the client bit by bit. They talk about how this has been occurring from the beginning of the internet. This concept is similar to microfrontends. Dinesh gives advice on how to implement PSSR. He says that when you surver render, it loads on differently. Your framework has to do one complete pass of the histiema, so this means you cannot send things to the client until the whole histema is designated. To beat this they’ve been doing a mix of SSR and CSR, with the header, body, and non critical content rendering on the client side. PSSR bridges the gap between SSR and CSSR. How do we make it real and how do we use it? The panel discusses ways to make PSSR a reality. Dinesh has been experimenting with it with extra services, and he gives his method for doing it, emphasizing the importance of where you divide your code is very important, it has to be in sequence. CSS Grid solves this problem, so you could render things out of order and the browser puts it in the right spot. They talk about other ways to get around it. Lucas shares some of the difficulties he’s encountered with streaming and rendering. They talk about the new feature for the Phoenix framework for Elixir, Live View Now. For this feature, you don’t need client side frameworks to generate dynamic content and it enables two way streaming. However, it does not scale well for extremely large apps. They talk about some of the tradeoffs for using this feature. They conclude by discussing the gap between website optimization and device performance. Panelists Thomas Aylott Dave Ceddia Lucas Reis With special guest: Dinesh Pandiyan Sponsors Progress KendoReact | Try now for FREE: kendoreact.com/reactroundup Sentry use the code “devchat” for 2 months free on Sentry’s small plan My JavaScript Story Links React Redux Console.log Puppeteer Webpack Datadog CSS Grid Transport headers Phoenix Elixir Follow DevChatTV on Facebook and Twitter Picks Lucas Reis: Ben Hoyt Wholesome Learning Elm Cast iron skillet Thomas Aylott: 6 Lessons Children Need to Learn Dinesh Pandiyan: To-Do List app David Ceddia: On the Utility of Phoenix Live View

australia progressive react transport redux java console sidney utility panelists csr elixir to do list frontend sentry puppeteers debugging datadog ssr webpack css grids cssr react redux devchattv lucas reis my javascript story

RRU 082: Progressive SSR with Dinesh Pandiyan

All JavaScript Podcasts by Devchat.tv

Play Episode Listen Later Oct 8, 2019 50:20

Dinesh Pandiyan is a developer from India. He started as a backend engineer and then moved to frontend. Currently he is working for ThinkMill in Sidney, Australia. Today Dinesh and the panel are talking about devtools and progressive SSR. Dinesh got started with React Redux. The panelists talk about their experiences using primarily Redux for projects. Dinesh talks about his transition from backend to frontend and how it’s a totally different world. On the backend he was working in Java and it ran on a server, but on the frontend, code runs in a browser and the browser is very different for each user. Frontend development is tricky because you don’t know where your code is going to run. One of the trickiest parts of frontend development is debugging something in production. Unless you have good logging tools, you won’t know what’s going on. Debugging this stuff when it’s running on client browsers is hard, but when you’re in development mode your own browser you’ve got handy tools. They talk about some of the tools in React, and agree that console.log is the greatest debugging tool of all time. Dinesh talks about some of the most surprising features about React dev tools. You can benchmark your preferences and identify weaklings in your project, which are things that slow down your application or things that might slow it down. On an application level, you have to build a mental model of how the data flows from the top, where things change, etc, and dev tools can help you build that pretty easily. They talk about how things had to be done before great React tools. In fact, Dinesh chose React just for the devtools. They talk about how the dev tools for React compare to Java. The most important thing is that you have a good debugger that can stop where you want it to. They transition to talking about the differences between SSR and progressive SSR For SSR (Server Side Rendering), rendering happens on the server and you send it to the client. CSSR (Client Server Side Rendering) is when all the rendering happens on the client’s side. PSSR (Progressive Server Side Rendering) is where you render small chunks on the server and then send it to the client bit by bit. They talk about how this has been occurring from the beginning of the internet. This concept is similar to microfrontends. Dinesh gives advice on how to implement PSSR. He says that when you surver render, it loads on differently. Your framework has to do one complete pass of the histiema, so this means you cannot send things to the client until the whole histema is designated. To beat this they’ve been doing a mix of SSR and CSR, with the header, body, and non critical content rendering on the client side. PSSR bridges the gap between SSR and CSSR. How do we make it real and how do we use it? The panel discusses ways to make PSSR a reality. Dinesh has been experimenting with it with extra services, and he gives his method for doing it, emphasizing the importance of where you divide your code is very important, it has to be in sequence. CSS Grid solves this problem, so you could render things out of order and the browser puts it in the right spot. They talk about other ways to get around it. Lucas shares some of the difficulties he’s encountered with streaming and rendering. They talk about the new feature for the Phoenix framework for Elixir, Live View Now. For this feature, you don’t need client side frameworks to generate dynamic content and it enables two way streaming. However, it does not scale well for extremely large apps. They talk about some of the tradeoffs for using this feature. They conclude by discussing the gap between website optimization and device performance. Panelists Thomas Aylott Dave Ceddia Lucas Reis With special guest: Dinesh Pandiyan Sponsors Progress KendoReact | Try now for FREE: kendoreact.com/reactroundup Sentry use the code “devchat” for 2 months free on Sentry’s small plan My JavaScript Story Links React Redux Console.log Puppeteer Webpack Datadog CSS Grid Transport headers Phoenix Elixir Follow DevChatTV on Facebook and Twitter Picks Lucas Reis: Ben Hoyt Wholesome Learning Elm Cast iron skillet Thomas Aylott: 6 Lessons Children Need to Learn Dinesh Pandiyan: To-Do List app David Ceddia: On the Utility of Phoenix Live View

australia progressive react transport redux java console sidney utility panelists csr elixir to do list frontend sentry puppeteers debugging datadog ssr webpack css grids cssr react redux devchattv lucas reis my javascript story

JSJ 390: Transposit with Adam Leventhal

Play Episode Listen Later Sep 10, 2019 46:32

Episode Summary Adam Leventhal is the CEO and cofounder of Transposit. Transposit was born from the desire to build a way for developers to work with lots of different APIs, take authentication and pagination off the table, and let developers focus on the problems they’re trying to solve. Transposit is a serverless platform that’s free and gives you a combination of SQL or JavaScript to start playing with your API. Since interacting with API data securely can be difficult, the panel discusses how Transposit might replace the personally built tools and how does it compare to JAMstack. They talk about some common things that people do wrong with security. Transposit is often used as the full backend, and Adam shares how that works. There is a list of APIs that Transposit can talk to, and you can build your own connector. You can also work with JavaScript and SQL simultaneously. Chris Ferdinandi asks some more specific questions about how Transposit can work with email lists. Adam clarifies the difference between connectors and apps in Transposit. He delves into more detail on what makes it work under the hood. There are some 450,000 Stack applications but the majority have one user because they built it to communicate specifically with their API. The panel discusses how Transposit can help with this. Since Transposit is still in startup mode, it is free for now, and can connect to any public facing API. Adam talks about their decision not to make it open source and gives more details on where the authentications occur. The show wraps up with the panel talking about the pros of going serverless Panelists Chris Ferdinandi Christopher Buecheler With special guest: Adam Leventhal Sponsors Adventures in .NET Sentry use the code “devchat” for 2 months free on Sentry’s small plan Elixer Mix Links Transposit SQL JAMstack OpenAPI Swagger YAML MailChimp React Redux Converting a string into Markup with Vanilla JS How to create a map of DOM nodes with Vanilla JS Custom events in Internet Explorer with Vanilla JS DOM diffing with Vanilla JS part 1 DOM diffing with Vanilla JS part 2 Follow DevChat on Facebook and Twitter Picks Christopher Buecheler: Manchester Orchestra Chris Ferdinandi: Reef Elizabeth Warren Adam Leventhal: Hamilton the biography Antler Follow Adam on Twitter @ahl

JSJ 390: Transposit with Adam Leventhal

JavaScript Jabber

Play Episode Listen Later Sep 10, 2019 46:32

Episode Summary Adam Leventhal is the CEO and cofounder of Transposit. Transposit was born from the desire to build a way for developers to work with lots of different APIs, take authentication and pagination off the table, and let developers focus on the problems they’re trying to solve. Transposit is a serverless platform that’s free and gives you a combination of SQL or JavaScript to start playing with your API. Since interacting with API data securely can be difficult, the panel discusses how Transposit might replace the personally built tools and how does it compare to JAMstack. They talk about some common things that people do wrong with security. Transposit is often used as the full backend, and Adam shares how that works. There is a list of APIs that Transposit can talk to, and you can build your own connector. You can also work with JavaScript and SQL simultaneously. Chris Ferdinandi asks some more specific questions about how Transposit can work with email lists. Adam clarifies the difference between connectors and apps in Transposit. He delves into more detail on what makes it work under the hood. There are some 450,000 Stack applications but the majority have one user because they built it to communicate specifically with their API. The panel discusses how Transposit can help with this. Since Transposit is still in startup mode, it is free for now, and can connect to any public facing API. Adam talks about their decision not to make it open source and gives more details on where the authentications occur. The show wraps up with the panel talking about the pros of going serverless Panelists Chris Ferdinandi Christopher Buecheler With special guest: Adam Leventhal Sponsors Adventures in .NET Sentry use the code “devchat” for 2 months free on Sentry’s small plan Elixer Mix Links Transposit SQL JAMstack OpenAPI Swagger YAML MailChimp React Redux Converting a string into Markup with Vanilla JS How to create a map of DOM nodes with Vanilla JS Custom events in Internet Explorer with Vanilla JS DOM diffing with Vanilla JS part 1 DOM diffing with Vanilla JS part 2 Follow DevChat on Facebook and Twitter Picks Christopher Buecheler: Manchester Orchestra Chris Ferdinandi: Reef Elizabeth Warren Adam Leventhal: Hamilton the biography Antler Follow Adam on Twitter @ahl

JSJ 390: Transposit with Adam Leventhal

Play Episode Listen Later Sep 10, 2019 46:32

Episode Summary Adam Leventhal is the CEO and cofounder of Transposit. Transposit was born from the desire to build a way for developers to work with lots of different APIs, take authentication and pagination off the table, and let developers focus on the problems they’re trying to solve. Transposit is a serverless platform that’s free and gives you a combination of SQL or JavaScript to start playing with your API. Since interacting with API data securely can be difficult, the panel discusses how Transposit might replace the personally built tools and how does it compare to JAMstack. They talk about some common things that people do wrong with security. Transposit is often used as the full backend, and Adam shares how that works. There is a list of APIs that Transposit can talk to, and you can build your own connector. You can also work with JavaScript and SQL simultaneously. Chris Ferdinandi asks some more specific questions about how Transposit can work with email lists. Adam clarifies the difference between connectors and apps in Transposit. He delves into more detail on what makes it work under the hood. There are some 450,000 Stack applications but the majority have one user because they built it to communicate specifically with their API. The panel discusses how Transposit can help with this. Since Transposit is still in startup mode, it is free for now, and can connect to any public facing API. Adam talks about their decision not to make it open source and gives more details on where the authentications occur. The show wraps up with the panel talking about the pros of going serverless Panelists Chris Ferdinandi Christopher Buecheler With special guest: Adam Leventhal Sponsors Adventures in .NET Sentry use the code “devchat” for 2 months free on Sentry’s small plan Elixer Mix Links Transposit SQL JAMstack OpenAPI Swagger YAML MailChimp React Redux Converting a string into Markup with Vanilla JS How to create a map of DOM nodes with Vanilla JS Custom events in Internet Explorer with Vanilla JS DOM diffing with Vanilla JS part 1 DOM diffing with Vanilla JS part 2 Follow DevChat on Facebook and Twitter Picks Christopher Buecheler: Manchester Orchestra Chris Ferdinandi: Reef Elizabeth Warren Adam Leventhal: Hamilton the biography Antler Follow Adam on Twitter @ahl

RRU 076: Ignite and the React Community with Jamon Holmgren

Play Episode Listen Later Aug 27, 2019 54:21

Sponsors React Native Radio Sentry use the code “devchat” for 2 months free on Sentry’s small plan GitLab | Get 30% off tickets with the promo code: DEVCHATCOMMIT Panel David Ceddia Lucas Reis With special guest: Jamon Holmgren Episode Summary Today’s guest is Jamon Holmgren from Oregon. Jamon is the the CTO for Infinite Red, a consultancy that designs and builds mobile apps. The show starts with Jamon talking about his background in coding, which goes all the way back to when he was 12 years old. The panel brings up his React Finland presentation on building a community around Ignite. Ignite is a plugins and boilerplate maker for React that can speed up app creation. Jamon talks about how it works and how it came about. The panel believes this to be an excellent product that will contribute to code quality and doesn’t contribute to the jumble of boilerplates out there. Since Infinite Red engineers work on both web and mobile applications, Jamon talks about how they navigate the differences between the two platforms. Their primary tool for doing this is MobX, and Jamon expounds on how it works. The panel discusses situations where using React Hooks and React Context are too low level for a state management solution for a big application, and thus where tools like MobX become necessary. The conversation turns to the React Core team and how they view the community coming up with their own solutions. The panel discusses the lack of executive decisions in React and compare it to other languages like Ruby, and how it affects the longevity of a language. They weigh the benefits of a core team that makes executive decisions and causes conflict versus one that doesn’t and the chaos that ensues. They discuss the benefits of standardization, but ultimately agree that collaboration almost always comes up with the best solution. Links Infinite Red Building a Community Around Ignite Ignite Boilerplate MobX State Tree MobX React MobX Emer React Redux React Context React Hooks Apollo Elm Prettier @jevakallio Tweet Follow DevChat on Facebook and Twitter Picks David Ceddia: Devurls.com Reducing Motion to Improve Accessibility Lucas Reis: CSS Grid like you are Jan Tschichold Jamon Holmgren: React Node GUI

community building oregon panel apollo cto react ignite elm gitlab mike holmgren sentry emer prettier jamon boilerplate css grids react hooks mobx infinite red react redux react native radio devchattv jamon holmgren lucas reis react core react finland

RRU 076: Ignite and the React Community with Jamon Holmgren

Play Episode Listen Later Aug 27, 2019 54:21

Sponsors React Native Radio Sentry use the code “devchat” for 2 months free on Sentry’s small plan GitLab | Get 30% off tickets with the promo code: DEVCHATCOMMIT Panel David Ceddia Lucas Reis With special guest: Jamon Holmgren Episode Summary Today’s guest is Jamon Holmgren from Oregon. Jamon is the the CTO for Infinite Red, a consultancy that designs and builds mobile apps. The show starts with Jamon talking about his background in coding, which goes all the way back to when he was 12 years old. The panel brings up his React Finland presentation on building a community around Ignite. Ignite is a plugins and boilerplate maker for React that can speed up app creation. Jamon talks about how it works and how it came about. The panel believes this to be an excellent product that will contribute to code quality and doesn’t contribute to the jumble of boilerplates out there. Since Infinite Red engineers work on both web and mobile applications, Jamon talks about how they navigate the differences between the two platforms. Their primary tool for doing this is MobX, and Jamon expounds on how it works. The panel discusses situations where using React Hooks and React Context are too low level for a state management solution for a big application, and thus where tools like MobX become necessary. The conversation turns to the React Core team and how they view the community coming up with their own solutions. The panel discusses the lack of executive decisions in React and compare it to other languages like Ruby, and how it affects the longevity of a language. They weigh the benefits of a core team that makes executive decisions and causes conflict versus one that doesn’t and the chaos that ensues. They discuss the benefits of standardization, but ultimately agree that collaboration almost always comes up with the best solution. Links Infinite Red Building a Community Around Ignite Ignite Boilerplate MobX State Tree MobX React MobX Emer React Redux React Context React Hooks Apollo Elm Prettier @jevakallio Tweet Follow DevChat on Facebook and Twitter Picks David Ceddia: Devurls.com Reducing Motion to Improve Accessibility Lucas Reis: CSS Grid like you are Jan Tschichold Jamon Holmgren: React Node GUI

community building oregon panel apollo cto react ignite elm gitlab mike holmgren sentry emer prettier jamon boilerplate css grids react hooks mobx infinite red react redux react native radio devchattv jamon holmgren lucas reis react core react finland

RRU 072: React Hooks for Global State and More Custom Hooks with Daishi Kato

Play Episode Listen Later Jul 30, 2019 51:54

Sponsors Netlify Sentry use the code “devchat” for 2 months free on Sentry’s small plan Triplebyte offers a $1000 signing bonus Panel Thomas Aylott David Ceddia Lucas Reis With special guest: Daishi Kato Episode Summary Todays guest Daishi Kato is a freelance programmer and has many open source libraries. He starts off by talking about how he got from tail call optimization to Redux and global state. Daishi talks about his definition of global state, how it differs from a regular state, and why it is a problem with the current context implementation. Thomas talks about his work with Android and how React has helped solved some of the problems they encountered. They talk about when different rendering issues they’ve encountered. Daishi shares his unique approach to solving rendering issues and how it applies to his libraries. His solution is to combine the system in React with proxy based tracking to solve issues with rendering. Daishi explains why this works and the importance of benchmarking. Daishi’s solution is designed as a same use state API, so someone can drop this in and see if it works. Daishi talks about his definition of proxies and how it triggers the rerender. He also talks about how it handles conditional reads. This tracking happens every render and it doesn’t have the same limitations as hooks. The panel talks about the new version of React Redux library implementation and how it compares to Daishi’s. Daishi’s approach is useful for people earning Redux because the used tracked state gives you all the benefits without a lot of the complexity. Daishi talks about how it deals with deeply nested pieces of code. The panel discusses the delicate balance of optimizing, but not doing it too soon, but to also remember how vital it is to maintain the performance of your app. Daishi’s work with Reactive React Redux to make sure things perform from the beginning is really important. It’s also important to understand how your product works so that when things do go wrong, you know how to fix it. Daisho talks about his other library React Tract for people who don’t like to use Redux. Links Mobex GraphQL Proc SQL React-Tracked Immer Reactive React Redux React Redux Follow DevChat on Facebook and Twitter Picks David Ceddia: A Compiler From Scratch video Verbal Expressions Thomas Aylott: The Making of a Manager by Julie Zhou Thomas’ Youtube channel Lucas Reis: Shun knives Daishi Kato: Remote Faces

android panel immer react api redux kato sentry shun graphql netlify global state react hooks triplebyte react redux devchattv daishi lucas reis daisho

RRU 072: React Hooks for Global State and More Custom Hooks with Daishi Kato

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

Play Episode Listen Later Jul 30, 2019 51:54

Sponsors Netlify Sentry use the code “devchat” for 2 months free on Sentry’s small plan Triplebyte offers a $1000 signing bonus Panel Thomas Aylott David Ceddia Lucas Reis With special guest: Daishi Kato Episode Summary Todays guest Daishi Kato is a freelance programmer and has many open source libraries. He starts off by talking about how he got from tail call optimization to Redux and global state. Daishi talks about his definition of global state, how it differs from a regular state, and why it is a problem with the current context implementation. Thomas talks about his work with Android and how React has helped solved some of the problems they encountered. They talk about when different rendering issues they’ve encountered. Daishi shares his unique approach to solving rendering issues and how it applies to his libraries. His solution is to combine the system in React with proxy based tracking to solve issues with rendering. Daishi explains why this works and the importance of benchmarking. Daishi’s solution is designed as a same use state API, so someone can drop this in and see if it works. Daishi talks about his definition of proxies and how it triggers the rerender. He also talks about how it handles conditional reads. This tracking happens every render and it doesn’t have the same limitations as hooks. The panel talks about the new version of React Redux library implementation and how it compares to Daishi’s. Daishi’s approach is useful for people earning Redux because the used tracked state gives you all the benefits without a lot of the complexity. Daishi talks about how it deals with deeply nested pieces of code. The panel discusses the delicate balance of optimizing, but not doing it too soon, but to also remember how vital it is to maintain the performance of your app. Daishi’s work with Reactive React Redux to make sure things perform from the beginning is really important. It’s also important to understand how your product works so that when things do go wrong, you know how to fix it. Daisho talks about his other library React Tract for people who don’t like to use Redux. Links Mobex GraphQL Proc SQL React-Tracked Immer Reactive React Redux React Redux Follow DevChat on Facebook and Twitter Picks David Ceddia: A Compiler From Scratch video Verbal Expressions Thomas Aylott: The Making of a Manager by Julie Zhou Thomas’ Youtube channel Lucas Reis: Shun knives Daishi Kato: Remote Faces

android panel immer react api redux kato sentry shun graphql netlify global state react hooks triplebyte react redux devchattv daishi lucas reis daisho

12 выпуск 07 сезона. React Router v5, React-Redux v7.0.0-beta.0, Cables vs. malloc_trim, Helix, Lamby, Flexulator, DropCSS и прочее

Play Episode Listen Later Mar 25, 2019 39:01

Добрый день уважаемые слушатели. Представляем новый выпуск подкаста RWpod. В этом выпуске: Ruby Rails 6 adds ActiveModel::Errors#slice!, Rails 6 raises ActiveModel::MissingAttributeError when update_columns is used with non-existing attribute и Cables vs. malloc_trim, or yet another Ruby memory usage benchmark An RSpec time issue (and it's not due to timezones), An Deep Dive into TensorStream и A scary side of ActiveRecord's find Helix: Improve the Performance of Rails with Rust и Lamby - simple Rails & AWS Lambda integration using Rack Web React Router v5, React-Redux v7.0.0-beta.0 и «Пора валить из фронтенда»: Андрей Ситник о стагнации сообщества, опенсорсе и не только Advanced Map Shading и React State: Choose Wisely Announcing fromfrom, Flexulator, CrumbsJS - a lightweight, intuitive, vanilla ES6 fueled JS cookie and local storage library и DropCSS - a simple, thorough and fast unused-CSS cleaner

performance deep dive beta rails css trim js helix cables aws lambda es6 lamby activerecord rspec react redux react router ruby rails

40: Lift as you Climb with Cassidy Williams. On React, Redux, and GraphQL at CodePen, teaching, @smkmeetup, following your dreams (literally), and building your dream network.

React Podcast

Play Episode Listen Later Mar 21, 2019 46:12

Cassidy Williams is a Senior Software Engineer CodePen in Seattle — using React, Redux, GraphQL, and Apollo Client to build the frontend of CodePen and CodePen Projects. Chantastic asks about building a startup on a plane, maximizing side hustle effort, the importance of networking, and what it's like to meet your heroes. They discuss tips for getting great advice from smart people, building passive income, finding safe workplaces, and what it looks like to lift as you climb.

teaching seattle lift react climb redux following your dreams graphql codepen cassidy williams react redux dream network apollo client

4 - Hooks Day Coming, React as a UI Runtime, React-Redux Roadmap

This Week in /r/reactjs

Play Episode Listen Later Feb 11, 2019 9:35

Discussions React 16.8 (The One Hopefully with Hooks) planned for Feb 4 Weekend Reads: React Docs on Hooks React as a UI Runtime React-Redux Roadmap: v6, Context, Subscriptions, and Hooks Projects Nice and smooth! I’ve created a collection of animated burgers (HTML/CSS + React) Fully functional WhatsApp Clone using React (Hooks+Suspense), GraphQL, Apollo, TypeScript and PostgreSQL /dondonleroy’s personal site I had a real nostalgic attack so I created this library Introducing react-movable: Drag and drop for your lists and tables. 3.5kB gzipped. Accessible. Announcing Overmind, reducing the pain of state management Road to React with Firebase Listen til the end for a easter egg!

context apollo drag roadmap react accessible subscriptions hooks runtime typescript graphql postgresql react redux

012. React + Redux によるウェブフロントエンドの実装/より良いキーボードを求めて

NDS FM

Play Episode Listen Later Jan 5, 2019 59:56

第12回NDSFMはマツイさん(circled9) をゲストにお迎えして、ウォーターセル株式会社のサービス「アグリノート」のウェブフロントエンドについて聞きました。アグリノートでは早くから Web UI に React + Redux を使用しており、TypeScript や Flow を利用しているそうです。TypeScript や Flow の使い分けや React + Redux で良かったことや辛いことなどを話してくれました。また、キーボードにこだわりがあるとのことで Happy Hacking Keyboard や RealForce、Ergodox の使用感について教えていただきました。

python react redux

012. React + Redux によるウェブフロントエンドの実装/より良いキーボードを求めて

NDS FM

Play Episode Listen Later Jan 5, 2019 59:56

第12回NDSFMはマツイさん(circled9) をゲストにお迎えして、ウォーターセル株式会社のサービス「アグリノート」のウェブフロントエンドについて聞きました。アグリノートでは早くから Web UI に React + Redux を使用しており、TypeScript や Flow を利用しているそうです。TypeScript や Flow の使い分けや React + Redux で良かったことや辛いことなどを話してくれました。また、キーボードにこだわりがあるとのことで Happy Hacking Keyboard や RealForce、Ergodox の使用感について教えていただきました。

react redux

Episode 124: Pair Programming Pain and Side Hustle CEO

Soft Skills Engineering

Play Episode Listen Later Sep 17, 2018 32:12

In this episode, Dave and Jamison answer these questions: I joined a new team that has a different way of working, which has exposed a lot of my shortcomings. On my previous team, collaboration was limited to discussions around architecture and strategy; after reaching consensus, we’d implement the components independently. I was very comfortable with this because I don’t have good intuition for how to interact with others. On the new team, we pair-program. Teammates have pointed out mistakes I’ve made while pairing, such as trying to control the mouse when they are in the middle of doing something or investigating something on my own computer without communicating what I’m doing. On this team, we are also expected to be much more engaged in group decision-making. As a result, I’ve made tons of mistakes in how or when I pose questions. Each time I make a mistake, it increases my self-loathing. I tried telling myself that I didn’t have bad intent when I made the mistake and the only way to grow is to make mistakes. I also told myself that this self-loathing doesn’t do anything for the team. I also do a personal post-mortem on each of my mistakes because I thought that would help me move on. These approaches didn’t work and my confidence has dropped substantially. I know it’s essential for me to learn how to work effectively with others instead of staying in my comfort zone of heads-down coding. Do you have suggestions for how to get through this learning process without letting it affect my self esteem and motivation? Hey Soft Skills Engineering, Love the podcast! You’ve helped me understand so much about the software engineering career field that I probably would have otherwise learned the hard way. I’ve been working at my current job for almost 4 years. The pay is very much below market (it’s a non-profit), the work is too easy, I can finish any task in a couple of hours, but we are given an automatic 1 week+ deadline to finish anything, and I’m much more technical than any of my co-workers, to the point where I can’t even have nerdy conversations with anyone at work. However, I’ve stuck around because the job is pretty much stress-free, I don’t have to think about work at all outside of work hours, and all the free time allows me to take on side-projects and learn new technologies, including every level of software development. With all this free time, I’ve started a company. In the last few months, I’ve managed developers, designed a system using blockchain tech, designed and implemented a database, learned the ins and outs of AWS management and server-less development, built a REST API from scratch, developed a full front-end in React/Redux, and learned a ton of other things. Since I’m in the prototype phase, my startup hasn’t gotten any revenue, and I’m aware it might take awhile to get any revenue if it ever does. I need to pay bills, and I need to start thinking about my financial stability. So I think it’s time to get a new job, even if it means not having as much freedom to work on the startup. I’m not sure on how to approach my next step. I want to continue working on the startup after I get a new job, but I’m aware that employers might not be fond of “CEO” on my resume when there’s no end-date on the position, because I might leave at any time if my company grows. If I don’t put anything about my company on my resume, then it seems like I have nothing to show for all the technical skills I claim I have (since all the learning, management and implementation has all been for my company). Do I put anything about the startup I’m working on in my resume? If not, then how would I showcase all the experience and skills I’ve gained by beginning this startup? Should I just keep getting by paycheck to paycheck while I build the company? Thanks

love ceo pain side hustles aws teammates rest apis pair programming react redux

109: What Do You Need in a JavaScript Framework?

The Frontside Podcast

Play Episode Listen Later Aug 23, 2018 57:26

Guests: Brandon Hays: @tehviking | Blog Chris Freeman: @15lettermax In this episode, former Fronsiders, Brandon Hays and Chris Freeman join Charles and Taras to talk about the difference between a framework and a library, whether or not React + Redux a framework in itself, red flags to signal that you're actually building a framework, attributes of a good framework, how can you tell if you created a bad framework, and how you can make a bad framework better. Resources: Test Sizes by Simon Stewart This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. ** Transcript:** CHARLES: Hello everybody and welcome to The Frontside Podcast. My name is Charles. I'm a developer here at Frontside and today, we're going to be talking about the things that go into making a JavaScript framework. Because, hey, there's not enough of those in the world today, so we're going to talk about that and with me is Taras. TARAS: Hello, hello. CHARLES: And we've got two very special guests, who have a lot of experience with this topic. Mr Chris Freeman and Brandon Hays. Hey, guys. CHRIS: Hi, there. BRANDON: Hi, there. We're talking about the poofberry framework, right? CHARLES: What's a poofberry? BRANDON: There's a tweet that's going around right now that one of them says, "I don't know what I should be doing," and the next person says, "Oh, just use poofberry." What is that? It's like fluffnuts but the [inaudible]. Hey, dot, dot, dot. Then, it integrates with log bungler. CHARLES: There's a reason that I'm dying laughing. BRANDON: It's so true. CHARLES: It's so true, laugh, cry, laugh, cry. Let's start with kind of a very basic assessment here. Because there's a lot of different things that you can use to compose the applications that you build but for some reason, some of these things are grouped and considered as libraries and some of them are considered frameworks. I don't know that the boundary is very clear like I'll know it when I see it type thing. Maybe, we can start with what is the difference between a framework and a library? CHRIS: I have some thoughts of these. I feel like this is one of those questions that could easily just turn into an infinite bike-shed but I remember reading something a while ago that stuck with me for a long time. I'm pretty sure it's related to Java but that makes sense because if anyone is going to talking about frameworks, it's Java developers. But it was saying that the difference between a library and a framework is inversion of control and the idea is a thing that's a library is a thing where you are in control. You bring the library code into your code and it's up to you what you do with it. In a framework, the framework code calls you as I think what it said. It's like, you call the library code, the framework code calls you and -- CHARLES: In Soviet framework. CHRIS: Yeah, exactly. A framework says, "Here are a bunch of open spaces for you to put your code in and I will take care of the rest," versus a library is just like... I don't know, "Here's some things that you can use. It's up to you. What do you want to do with them?" CHARLES: Right, so in kind of like [inaudible], that would be basically, a framework would be the thing that's got the main method. I think the same thing in JavaScript and when you call it, does it actually implement the main method. In JavaScript, it'll probably like in node. Under that definition, it would be like, "Are you the main scripts when you invoke node? Do you control the main script?" If you were doing your own command line parsing, for example, you're looking at the process.rb and pulling off the command lines and doing all the things but even if you're using something like Yargs or option parser in Ruby, that's more of like a framework. I guess Yargs is a library because you're still implementing the script. You're instantiating the Yargs thing. TARAS: React calls render to figure out what to convert to DOM. Does that make React the framework? CHARLES: I think React as a library. That's a good question. What's the equivalent of the main method on the web? CHRIS: I think there's a very clear distinction, especially if you look at React versus something like Ember and I'm sure Angular does this as well. In React, by default, to build a React thing, you're going to pull in React, you may write some components, you may import them elsewhere but the main method is that you have an index.html with some div in it and you are the one that has to call ReactDOM.render and you pass it like document.query selector or whatever and then, your top level component and that can be as simple as complicated as you like or you can have a webpack plugin do it or whatever else. But the onus is on you to actually take that React app and get it starting up on the page versus Ember, it's like, "There's an index.html. It's fully wired up." There is one point where you sit down and say, "Start my program here," like Ember abstracted all that away. To me, that's the main method for a frontend application. CHARLES: Right and if you actually look at something that Ember generates, then look at index.html, they generate a script tag for you that instantiate your application and mounts it on an element. If you want to change that element, that's actually a configuration option that you can change but it still a configuration option that's consumed by the framework. In that sense, there is that inversion of control. I see what you mean like in React, you're the one who flicks off the first domino, like who's the prime mover. Is it you or is it the framework that knocks over the first domino? BRANDON: I like Chris's explanation and I think it's elegant to say because I was thinking in terms of structure. If it imposes a structure on you but really, the structure is there, it's like one of those Ikea shelf systems for you to put stuff into. If you're trying to solve a problem, here's a shelving system for you to put stuff into, whereas a library is just the tool that you might get out to put something together. Something that's multi-purpose but doesn't impose any structure on you or a ton of structure on you. My question is what's the usefulness of distinguishing between the two? TARAS: I think what's interesting and I had experienced this in a last couple of projects is that people, especially React when they kind of assume, because a lot of people entering to React not understanding the context within which React emerged and so, they're getting into React assuming that it has everything you need to build application that you need to build. A lot of them haven't necessarily built a single page application from scratch before and so, the jump into building something with React and then, it takes about a year for them to realize the full scope of all of the features that their application actually has and then, they kind of take a retroactive look and look like, "Okay, what do I have now?" and what emerges is that they've actually over the last year, they may be creating a framework without realizing that this is actually happening. CHARLES: They've imposed the structure of saying, "Here's the shelving system. Books about geography go here. Books on English literature go there and so on and so forth." BRANDON: But when you rolled your own framework, that's not how it goes. It's like, "You have to launch this balloon into the stratosphere to put a book on the shelf from geology." Taras, to your point, it sounds like the importance is setting expectations properly for people, so that they know what they're in for because kind of calling back to Ryan Florence's post a few years ago, you can't not have a framework. At some point, you will have a framework in order to ship something. I would actually take it one step further. My friend, Kyle talks about this that library is the smallest unit that you're working within a framework but that still doesn't take your code to production and put it in a debugable state. You need a platform. It's arguable, if you're handling deployment tasks and debugging tasks and operating software in production, you now have a platform and it's fair to say that Rails crossed that threshold at one point. It's fair to say that Ember has probably crossed that threshold, if you combine Ember with CLI deploy and the CLI tooling and all of that stuff. This almost like acts as a platform if you're owning and maintaining the software in production. CHARLES: Now, can I play devil's advocate here and say, the platform, is that necessarily predicated on a framework? Is there a pyramid where it goes library, framework, platform and one is built on top of the other? Why couldn't I have a library? Because what I'm hearing is the scope of concerns is just rendering HTML based on a state is a very small chunk. The actual scope of things that you need to do to get that code in production and have it be reliable and do all of the features that you want to do is just massive but why is that predicated on a framework? For example, one thing you have is a bunch of libraries out there, like routing for managing the title tag, managing all these things that you have to do for managing deployment, for building your application, for compressing it. There's all these different libraries out there. What if there was one massive library that just picked a bunch of other libraries but I was still in control? TARAS: I've actually seen this happen in the last of the projects. When people jump into building, they will eventually realize that they're building a platform but what happens before that is that they take user's requirements and they break those up by sections and then they assign them to a bunch of development teams who go and actually start to build. On one platform, they end up building five or six or 10 of siloed, packaged applications that have, in some cases, have their own dependencies, they have similar architecture, might not have similar architecture. Each team kind of implements thing differently and there's an expectation that once you package these things as npm and then you install them into one package, to one application when you run build, it's just going to work together. That's where I think, with the framework, it does create a foundation for these verticals to be implemented using kind of common foundation. This is what a lot of times that as if you don't realize that what you're trying to set out to build, the way that the projects get managed quite often, especially for big applications, for big platforms is that, it creates this period of about two years, where there's a lot of confusion and there's a lot of duplication and then, you end up seeing code that it's hard to put in production. CHARLES: Yeah, I agree. I'm curious then, because we'd started out talking about library and framework and talked about it takes two years to recognize that you're building a framework or you're building not a framework but a platform. Brandon, you said something very interesting. Rails for example, crossed the threshold of being more than a framework and actually, being a platform. What are the concerns of a platform that are beyond a framework? We talked about and using the kind of loose definition of a framework as being something where the framework create spaces for your code, to run your code so you can just take little dollops of code and they have one concern but the framework manages the coordination of the concerns but what's the next level? BRANDON: For the purposes of this conversation, I may have muddied the waters a little bit because I think it's more interesting to talk about the transition and the level of which you've crossed the threshold from being a library or using libraries or collecting libraries, into maintaining a framework because it's where you're going to experience more pain more than likely, than to me, the idea from works on my machine, to deployed and supported across a lot of users, it sounds like it's more interesting but it's not where we experience most of our pain actually. From my experience, maintaining frontend single page applications most of the pain is actually getting the damn thing to work on your machine and getting the libraries to collectively work together and then, getting that to production, it kind of enters back into an area of more known unknowns. I think that's a surprisingly a more mature ecosystem, still getting from this thing works on my machine to getting it out the door. That wasn't true when Rails was invented and so, Rails had to invent a lot of its own ecosystem around this stuff. Like I said, I don't want to muddy the waters too much. I think to me, the interesting question is how do you know you've crossed this threshold? What pain points are exposed when you start crossing that threshold or when you're pushing the boundaries of that threshold? Because you should not be using a framework if you're using React to do a select dropdown. I think of it as, if you're using it the way to replace something you might do with a jQuery plugin five or 10 years ago, you're using React like it's a library. One of the questions that you brought up was is the combination of React and Redux is a framework and I would argue that it is but I kind of want to throw that out -- CHRIS: Oh, interesting. CHARLES: I would say, it's two libraries stuck together to make a bigger library. It's like a monolithic library. BRANDON: But by the time you're actually using that to do anything, maybe the third thing in there is like transitioning states when you transition routes. At what point is that threshold crossed? I didn't build most of the software that led me to some of the opinions that I have about this. This was actually Chris Freeman's, though. I may defer to you on this. CHRIS: I think React + Redux constitutes if you look at what it does. You have like this view layer and this state layer. There's a set of opinions on there that is useful and there is the foundation for doing quite a bit but in my experience, you've already kind of alluded to this a little bit. I don't think it's a framework because as soon as you start using those two things, suddenly the next thing you hit is, "Wait. How do I handle asynchronous things?" There's a lot of different options for that. "Oh, now, I need to do routing. How do I incorporate routing into my React app but also in a way, that is amenable to state transitions in Redux but also, that is aware of the async stuff that I'm doing, that is going to possibly be triggered by my routes and by my Redux actions or by some other side of things?" Suddenly, you are very quickly pulling out a bunch of other libraries but also, probably starting to build abstractions on top of them because you're already finding a lot of common patterns that you're repeating over and over as you incorporate more and more pieces of the stack and then, you're writing a lot of glue code. I think that's the point where suddenly, you look back and behind you is the footsteps of this framework that's been walking alongside you the whole time. BRANDON: That is where I carried you, then dropped you, then sort of drowned you. CHRIS: Yeah. CHARLES: And then, kicked your core. TARAS: I'd like to suggest a way to think about this. As you guys are talking about, it kind of occurred to me is that it seems to me that libraries concentrate on how and frameworks focus on the 'what.' CHRIS: Oh, I love that. TARAS: Because if you think about for example, React is how geostack efficiently update DOM, then Redux is how do you wire together state across multiple components that might be in different parts of state tree and if you look at, for example, a React router or a kind of a routing component is how do you choose which components you want to render when you navigates specific URL. Because those things by themselves are not a complete solution but when you combine them together, what you get is you have a way of saying, "When I navigate to specific URL, I'm going to load specific data, provide that data to components and then, I would have a way to navigate through a different URL when you click on a link." From that, I think what happens when you get to the framework level is you actually have a kind of a bigger umbrella and under that umbrella, you have ways to address problems that you did not have previously. I think that's what framework does it is over time, it's a way of addressing concerns that cannot be addressed with a solution. They have to address with a collection of solutions and then, they provide a specific solution. I don't know if that's -- CHARLES: That actually sparked off a train of thought in my mind that perhaps what you really want to do is say, "I'm going to go a little bit like Lisp on you all," in the sense of every code at some point is data, that maybe every library, at some point is a framework. It's just that you can look and say, "What is the scope of the 'what' that I'm tackling." For some point, you can say like React is a framework. It creates this space where I can put my JSx, AKA the render function and I'm basically inverting control and so, what it is, it is a framework for efficiently rendering HTML or efficiently mapping an object to a fragment of DOM and then the DOM that gets generated from your render function, patching that into the HTML. You don't have to worry about that. There's that inversion of control. It creates that space but that's the only space that it creates. From that perspective, React is a framework for generating HTML but that's all it is but it is a library for constructing applications. Does that make any sense? I think as you layer on concerns, your framework create spaces for you. You use your library code to put stuff in and so, in the same way, I think one of the key realizations, I'm going to call up like BigTest and I'm not going to take credit for this, which is actually a blog post that I read at Google. I can't remember what it is but we'll link to it in the show notes where he said, "There are no such thing as unit tests. There are no such thing as acceptance tests. There are just tests of varying scope." They're all acceptance tests. To use that one thing, they're all experiments. It's just what is the scope of the test that you're trying to accomplish and his argument was we want to make that scope as big as possible by default and then, where appropriate, you narrow down. Maybe, the framework library distinction is a little bit constructed, kind of a construction of our own minds and what really is there, there's just frameworks of varying scope. BRANDON: Agreeing on a shared scope is actually probably the most important part of this conversation. We're referring to building end-to-end an application from data access to rendering to testing -- CHARLES: To deployment to routing. BRANDON: Yeah. CHARLES: To one day accessibility. BRANDON: Yeah. Adding that into the discussion is like a baseline of what constitutes an application. It's the percentage of people that are able to actually use it, the people that are locked out from using it by ability. That's a very useful frame for the discussion. Let's agree on the scope of what an application is and then, coming back to what Taras was saying is basically, when you're talking about the 'how,' that's a decision point. You hear a lot of people talk about decision fatigue in JavaScript and it's almost a played out trope at this point but it hasn't gone away as a problem, so what frameworks are doing is they're making a series of decisions for you that allow you to basically connect the pieces from end to end. Basically, somebody threw a rope bridge across the canyon and it doesn't have to be the best solution to get end to end but we have to solve the problem end to end. If we agree on the places end to end and the problem is when you're building your own series of libraries, you're like, "I'm going to choose best in class of A, best in class of B, best in class of C," and that sounds really good but if you're trying to build a bridge across a canyon and you're building in 10 best of class sections, for the type of connection we're trying to make here in the middle, we're going to use the best in class here. The weak point is in the connections, so you had better be the world's foremost engineer if you're going to be the person connecting all these disparate pieces that are each best in class, in order to bridge this canyon. That's the thing that's interesting to me and it's not even agreed in our industry that JavaScript-based web applications are a good thing or that the browser is web application runtime, those are things that are up for debate. But I think if we make that assumption, this is sort of the founding principle of where Ember came from and it executed to the best of its ability at the time and that philosophy is, I think you can prove it out in terms of results based on if you have two different applications, one of them is built by somebody trying to jam together best in class components and the other person is starting with an end to end solution with a community of people rallied around that solution. It's been interesting to watch those approaches play out over time. I know Chris has a very specific hands-on experience of having done both of these. I'm curious to get your hot take. CHRIS: There's actually a concept that I think about a lot in relation to this question. It's something that I actually heard come up again recently so the timing was great but it's called hypocognition. The idea is hypocognition is when you either just like can't see or can't understand some kind of cognitive representation of something because you don't have the words for it. An example is in Western cultures, especially like in English speaking cultures, there are not that many words for the color blue but in a lot of other cultures, they have many, many words for the color blue. After doing a big study they found that these English speakers actually have a harder time recognizing different shades of blue, like more of them just look the same versus other cultures where their brains are actually wired to see all this variety because they actually have the linguistic representations for these ideas already. When you were talking about maybe a library is a framework at some point, I think that's right on. I think one of the things that I think about a lot when talking about frameworks and seeing these debates happen on the internet about, "What is a framework?" but also like, "Do you even need a framework?" is obviously, there's a lot of people who absolutely... Like Ryan Florence. Ryan Florence clearly knows what a framework is. He knows what it takes to build a web application and he does not lack the words to define a framework versus a library. He's just made that choice and it's a very informed choice but I wonder if there's also a lot of people who are getting into web development for the first time and they look at something like a framework and it seems just absurd to anyone would want all of the things that like in Ember or in Angular is talking about, when they can make a basic UI with React and it's easy and fun and really cool. But then this two-year path happens and they look back and they've learned a whole bunch and now it's like, "Ooh, you couldn't even have explained this to me before," because all of the words would have fallen on deaf ears but now suddenly, it makes a staggering amount of sense. CHARLES: Right. I love that. BRANDON: You have to make a bad one. CHARLES: Just so that you can inherit the vocabulary to understand why you made a bad one. Now, you guys actually have some experience with this. Brandon, you gave a talk about it, which I think you should give more widely because it's fantastic but for those folks who may or may not be aware that they are walking this to your path, I want to talk first about what are the signs that you're walking along this path and then two, what are the consequences in terms of the cost you're paying for walking this path. Let's start with that first thing. What are the signs? How can you tell that I am building a framework? CHRIS: I think one of the telltale signs and one of the biggest red flags that caused me and Brandon to have a very serious heart to heart about our own personal framework was when we hit the point where you could look at a set of tickets for features and all you saw was 'framework features' that you needed to write before you could build the feature itself. You know like, "Oh, we have basic routing setting and we have it set up so that if you have a route transition and you would like a data request to happen when a certain route transition happens, that will happen," but then someone would like infinite scroll and we want to use a query param. When a query param changes, I want to update the query and fetch more records, except that the glue code that we wrote to tie our router to our redux async stuff is not aware of query params. It has no concept of what a query param is or what to do when it changes. Also, it has no concept of refetching the data without a full route transition, so what do we do, this person wants infinite scroll but I first have to implement several layers of framework code before I build the UI feature that you want? CHARLES: The basic heuristic there is ratio of direct feature code to code that supports the direct feature code and code that supports the code that supports direct feature code. It's anytime you're anywhere above that first layer on the stack. CHRIS: Yeah, I think Taras nailed it like what's the 'what' versus the 'how.' If you're asked a question that is concerned with the 'what' and you spend more time focused on the 'how,' then you might have a framework. BRANDON: I think people will think of building an application like a recipe. If you think of it in those terms, people think of frameworks as very restrictive but I'm a big fan of Blue Apron, a sponsor of this podcast. Thank you. They pre-select the ingredients and they give you the instructions and you know what to do, you still have to do the effort but you know if you connect these pieces together properly that you're going to wind up having a good experience and then, it gives you a lot of freedom to experiment and be creative beyond that, should you choose to. I think one of the signs that you've done a crummy job is that you're staring down, like Chris Freeman said, you actually starting to restrict your choices like, "I can't actually build you that feature because we don't have time to take on the amount of work necessary to build the support structure, to build you that feature," or if you find yourself writing a test framework. CHRIS: Oh, yeah we did that too. BRANDON: You know, we were real deep in this. There are developers that are like, "I really want to feel like I'm walking into a grocery store and selecting all the things necessary for my recipe," and so it really depends on what the problem actually is. If you're working at a giant megacorp and you have a two-year timeline to deliver something and their goals are not about delivering stuff on a tight turnaround, that's usually a recipe for a software failure anyway but let's say, that you're in the 5% of those types of projects that's going to succeed, that might be a good place where you can say, "What we're trying to do here is so custom and we have such a long lead time and a long leash and such a high level of internal expertise here that we should be shopping in the grocery store and we should be selecting all these things and we should be solving these problems." Basically, when is it time to use a framework? Well, when you don't have 10 times the time you think you do, when you don't have the ability to spend 80% to 90% of your time in the first three to four months of your project, maybe six months, debugging you're glue code in between the different libraries that you're gluing together and then coming back and realizing that you've painted yourself into a corner and you have to re-architect your whole framework, then you could be so proud of this baby, 18 months to two years from now, when you actually have delivered both a framework that took about 70% of your time and an application that took 25% or 30% of your time. CHARLES: Yeah. I think it's important to realize that people think we'll do it and we'll build it as we go but I want to call out right there, you will be spending 80% of your time and you have to be upfront about it. Of this two years, 18 months of it is going to be spent building this framework and six months of it is going to be spent actually writing the feature code and you have to be 75% of your tickets or your issues, whoever track the work, 75% of that has to be dedicated to the framework. BRANDON: If you're going to bake in that kind of overhead purely for the satisfaction of a single or one or two developers that like inventing things, that is literally the worst possible reason you could do that. That is almost like a guaranteed recipe for failure. It has to be for some other business reason like, "We want to be the company that owns this." There has to be business value attached in making that kind of investment. If you can't justify that at the outset, then you should probably just go ahead and lean on an existing framework and join a community of people. CHARLES: Yeah and I think one good litmus test for that is, "Is this a 'what' for which there is currently no 'how?' One of the reasons we're writing BigTest is because for the general JavaScript community, there are a number of acceptance test frameworks out there but the market is very, very limited. When we look to actually acceptance tests, our React application, this thing does not exist. Now, we had experience with something that was very like Ember specific and so, we kind of knew what the 'what' was, we experienced the 'what' but there was no 'how' for our current situation. That's like a place where you might be called upon where makes business sense to actually invest in a framework. I'll tell you another thing too is if you have made the decision to kind of follow the beaten path on the other areas, then when a framework is called for, you have the bandwidth. You've allowed for the buffer, for the margin, for you to write in with that framework, whereas if you're already just by default, maintaining all the glue code in every single thing, then if some unique 'what' comes along, for which there is no 'how,' you're not going to have a bandwidth to tackle it. BRANDON: Yeah. That's a real bad situation to be in. TARAS: There's something else that I find interesting is because there's a certain point, like this two-year mark where everyone's like, "We want to fix this now." I think what is interesting what comes next which is the three years of undoing all the stuff that you made because the biggest challenge, especially in really big projects. When your projects has to borderline into platforms and a platform threshold is when you have a multiple teams working separately to write separate modules that run, maybe in a separate Git repo and maybe, packaged in separate npm package and assembled together. Then what happens at that point, the question arises like how do you actually make this changes in this environment. Answering that question is actually really difficult. I think if you look at frameworks like Ember, Ember has made it their business to figure out exactly how to make this happen and I think they've done it really well but it's a really challenging endeavor, especially in incorporate environments where they don't have an update. You have like upgrades are like a curse. It's like a thing that you don't really want to ever do and because most quite often, they don't have the right testing habits in place to be able to support the change if necessary. I think what a lot of times happens is that the team that made the framework in the first place, they end up trying to maintain a fort but you won't have like 10 people and they only have machetes, you know? All you can do is run around and try to chop down little twigs but at the end of day, the trees is still going to keep growing. I think that's the really challenging part of being two years into a project, where you realize that you actually need something much more comprehensive than initially thought you needed. CHARLES: On that, assuming that you have decided that you are going to make a framework, it's a good business decision for you. Based on the criteria of this discussion, how can you assess whether it's good? Chris, you talked about needing to integrate query params with routing and asynchronous data loading and making sure all of that coordination happened and worked together easily. What's the difference between your framework just missing features kind of having holes in it that can be filled in, versus something that's not good and it's going to cost you lots of money down the road. CHRIS: Yeah. TARAS: One thing, if you look at what makes a good library of any kind, it tends to be like how effectively and how much words to take the address the use cases that you need. The problem is that to build a good framework, you need to understand the use cases. This is what usually happens over time. Two years in, you've actually understood the use cases and now, it's time to change and so, I think if you want to build a good framework, you actually need to understand those use cases quite early on or account for understanding use cases over time and that's a big question -- how do you figure out how to know what you don't know. CHRIS: Yeah, I think that's exactly right. I think about what you were just saying Charles and Taras like one of the things that I think has a big impact on and what this process looks like is the completeness of vision for what's your project actually is. If you have a very, very clear idea of what the entire product you're building is going to be or, at least what the key money-making feature is going to be and you can understand the ins and outs of that, then I think that's the point where you can look at what you have and say, "Have I created a good or bad framework? Does this framework have the ability to solve this one very important thing that I have to be able to do? If the framework doesn't do it, then I need to build my own but I now know what very important features I need to front load my framework with." I kind of think of it as imagine that you're like Jeremiah Johnson, the Reverend Jeremiah Johnson and you're going to go trekking through the woods for some unknown amount of time and you have no idea yet. You don't actually know where you're going. You don't know what you're going to see. You don't even know what's out there because you haven't done the research or whatever and you need to be prepared for anything, so you bring just a hodgepodge of stuff. If that's you at the beginning of your company or the beginning of your product and yours is kind of like... I don't know, we got to get product market fit and that means that we may have to kind of pivot once or twice or we need to be very flexible, then I would think long and hard before you commit to writing your own framework because you don't even know what framework to build and you might as well take a broad array of tools and use what you need. There will be times where that's frustrating and there won't be exactly the right tool for the job but 80% of the time, it's going to do just fine but if you know you have to do this one very special thing and you know that a framework is going to give you a lot of stuff that you won't need and it doesn't really excel at the one thing you do need, then don't force the framework. There may be time to build your own but just know that you need to go in with a very clear idea of what you're doing before you start building the abstractions that constitute a framework, rather than just like a constellation of libraries. CHARLES: I have a question on that then. Going back to one of the things we were talking about like React plus Redux. Your opinion, Chris that it is not a framework, so the question is does a framework actually exist for React? CHRIS: My guess is that many frameworks exist for React. CHARLES: Is there a public framework? TARAS: There is one called Fusion but it's [inaudible] what you would have imagine. It is essentially Redux and React together conventionalized. They addressed a bunch of concerns around service rendering and such but it does exist. CHRIS: How about Next? Next.js? TARAS: I'm not familiar with its features from a single page application perspective. CHARLES: I think it does have a router. It does bundle with Redux and this is one of the things that when you first started using Redux, it's like, "How do I even get my store to my components?" Yes, I can connect them but there's actually a lot of stuff that you have to do. First, you have to say, "I'm going to put my reducers here and then when I create my store, I'm going to fold all my reducers. If I've got a whole bunch of reducers in my application, I've got to fold them all together. I've got to pass them off to the store. When I create the store, I have to inject the middleware and then, everybody else just imports my store and then, I have to put in a provider and then, I can connect my components." That's actually a lot of stuff that you have to do and I think that, for example, Fusion just says, "Put your reducers here and we'll take care of all that process," and so it makes that decision for you, right? It says, "For state management, you're going to use Redux. For your reducers, they're going to go here. For your actions, they're going to go here." I don't know exactly how it's laid out but I remember reading the ReadMe, it was basically layering conventions over that. That's definitely going into framework territory but that's the only one that I know of, which is really, really odd. TARAS: There's something interesting that's happening also and this goes to what Brandon was saying earlier is that choosing the best in class, there's this 10 things but then, what if one of the best in class stops being the best in class. The fact that the creators of Redux was essentially saying that we needed to basically provide a way to do Flux that was better than 10 different options that were available, so here's Redux. We've created Redux but we don't really think it's ultimately the solution. We need to have something else in React that provides a foundation for us to be able to deliver a better state management than what Redux is, so what happens when one of the best in class is no longer the best in class? The bridge is already standing. There's people walking across the bridge already. How do you replace one of the chains in it? CHRIS: Over the course of six months while you figure out the differences in API between Flux and Redux and all the custom route transition data loading stuff you did with your Ajax library in your state management software that you put in a case statement inside there that you now have to change over. It's easy. It's no big deal. Don't worry about it. BRANDON: Just a simple matter of programming. TARAS: At least 25 years of collective frontend development experience is laughing like hyenas about the simplicity of building a -- BRANDON: Yeah, I'm actually looking at some of the old code that Chris wrote for trying to glue together, Redux Saga. I've been out of the game long enough to not know whether that's been superseded by some new or best in class piece of technology and even then, it was really challenging. This is true for frameworks too, is they don't really optimize for best in class. They optimize, hopefully for best fit for purpose but the world has moved on since Ember launched obviously. A lot of things have changed and it's, at least as difficult to try to keep that up to date with evolving trends and technologies and updates for a core team at a framework level as it is for you, as an engineer on the team. The difference is you get to outsource that work to a core team for a framework. Ember has not done a fantastic job in keeping up with. They've done a good job and they've tried their best but if there were more people working on it or if there was more effort applied to it or if it was a higher priority, you would see Ember being a more up-to-date framework using more modern tools. As a framework author, if you stay too close to the bleeding edge, all you're going to do is change out your build system. You're going to replace a Broccoli with webpack, with Rollup, whatever's after that. What's new in Packer? CHRIS: Parcel? CHARLES: Parcel. BRANDON: Parcel. You should immediately go build your framework with that and have fun. I am excited by the new and interesting stuff that's happening in these ecosystems and I think it's important not to get lulled into the siren song if your goal is to actually ship a piece of software on a timetable or a budget. TARAS: One thing, if it's a red flag, if you think this is easy, if you think your decisions can be made in this isolation without talking to somebody else and actually kind of flashing it out, then you're probably doing something wrong because a lot of these things are not trivial. There's a lot of thought, there's a lot of considerations used to go into decisions that you make, especially when you're creating something that is going to be used by more than a few people. I think that's really one of those things where it's hard to know what you don't know but if you think you know and you haven't done this before, you haven't done this a few times before, you're probably missing some pieces. BRANDON: Yeah, I agree with that. CHRIS: I think one of the things that's really enticing about React and Taras, you just hit on it but I've never felt as clever as when I was writing a React app. If I'm clever, I mean, clever in the same way that I felt really clever when I wrote some unbelievably convoluted Scala one-liner that six months later, neither me nor anyone else could decipher what it meant but at that time, I felt like a god of programming. That's how it felt like, "Well, a lot of the React stuff is addicting." It felt so much fun. It was so much fun until I really had to do something and it mattered for my job and there was a deadline and people were depending on me and I've realized that the clever thing I had done a month later was not the right clever thing but I can see how, if you're like what Taras was saying, where you are at the point where these decisions are easy. These decisions make sense. We're going to be fine and you haven't done it enough to kind of like know where all of the pitfalls are. That cleverness that you feel is fantastic and I can see why it takes two years before you look back and if the cleverness was finally worn off and then, you're just mortified at what you've done. CHARLES: Pride cometh before the fall. CHRIS: Yeah. BRANDON: It's like being a dungeon master in Dungeons and Dragons, where you're like, "Oh, look at this fiendish world." All right, cool. Now, you actually live there though. I have to move into an apartment on Mordor. TARAS: You know what's the funny flipside to that is that coming from Ember world where it's so normal to leverage the work of other clever people, like really smart people who've invested a lot of time to solve a particular problem, is that there's no stronger sense of being dumb than having to write it from scratch in React. That first feeling of like, "I've actually never had to implement this from scratch," and I feel like a bunch of applications before but because I've leaned on for accessibility, I've leaned on something that someone else has done and it worked really well for me and it was perfect. But now, I need to implement autocomplete from scratch in React and I have no support. I'm basically learning as I'm going on this and it's that sense of discomfort that you get from having to do it from scratch and then, comes the euphoria of having to figure it out. But if you figured it out, you figured it out in the last month. You've written it for the first time in the last month and you now understand what all the things that the Ember implementation does for you. It's an interesting psychology of doing this -- CHARLES: Yeah, it gives you a lot of perspective but you have to ask as a business owner, who may or may not be technical and this is the hardest thing for technical people who are business owners is to be able to not see things through a tactical lens. Is what you really want to pay for is to basically give your programmers this kind of a-ha moment of their own shortcomings because that what you want to be buying. BRANDON: Yeah, you want to maximize leverage. Your goal with technology is to maximize leverage. It's like being hired as a chef and you walk in and then you're like, "I'm a terrific chef. I worked in these fancy kitchens in New York and I'm known as a great chef," and they're like, "Okay, cool. Here's some flint and steel and a spear." CHARLES: Go hunt. BRANDON: You're like, "Wait, what?" Yeah, yeah, yeah. Show me what you can do. TARAS: We had a conversation in one of the previous podcast with Michael Jackson and we asked him, "What is the one thing you wish like React community would do more of?" and he's like, "I really wish React community have more conventions." All of this is to kind of say as like, there is a place for frameworks in React world. There's a very strong place for it. The question is how and what it said and how do you actually build it and when do you --? BRANDON: So we need a framework for making framework. TARAS: Getting really meta here. BRANDON: I totally agree with that and that's a great observation and that was actually the point of my talk as well, which is if I could convince people just to use Ember and improve Ember, that would be great because I think it's a really great starting point. But the React community is much larger because it had such a great adoption story. The adoption of Ember was very difficult and the adoption of React was very easy and it expanded to include the scope of full end to end applications in terms of what people thought the problem spaces they were thinking of with React. Ember was built to solve that but it was hard to get into. React was really easy to get into but it's actually hard to build applications with. I would love to see a dedicated subset of the React community, except the idea of shared solutions and the philosophies that made Ember into sort of a powerhouse of value delivery but built out of tools that satisfy the React community and a little more modular and a little more available for people to customize and built in that ecosystem. I'd really love to see that that included all of the main components of what we accept as, "This is an application framework. It handles testing. It handles accessibility. It handles data loading," and it doesn't have to be best in class in every scenario but it does have to be a reasonable bridge across that chasm and have a group of people look at this the same way. I would love to see a collective subset of the React community dedicate themselves to this idea. I don't know if that's too culturally opposed or even orthogonal to what the value system inside the React community. I haven't been able to fish that out but I would really love to see that emerge. this is something I would love to push for and I'd love to see other people jump in and push for as like, "What if 20 of us got together and decided we're all building our applications in similar ways, instead of one person saying, 'I'm going to use --'" Even create React app is kind of a Band-Aid on that, it isn't useful past a certain stage of life. I would love to see a group of people, though, get together that are sort of like-minded like that, the Michael Jacksons and maybe even Dan Abramov or a group of people that shared that set of values or came into React from the Ember community. That's actually one piece of advice I would give to people. You said, "How do you convince this engineer that they've built a bad framework?" Use a decent one. That's the biggest guide. Use a decent one. Build something in Ember and ship it to production and go, "Oh, I get it." If you've used a good framework, you can't go back to rolling a crappy one. Your standards have been ratcheted up. CHRIS: I wholeheartedly agree that you should try something else and Ember is a great option but I don't want to dismiss just like, "React is cool as hell," and there's a lot of stuff in React that's really, really awesome and things that I wish that will show up in Ember and they are starting to show up in Ember but they're taking a while and it'll be nice in there but who knows when that will be but I would encourage even more so is both sides, like Ember folks who are listening to this podcast, if you have never messed around with React because you feel some kind of tribal affiliation that you can't betray, please set that aside and go do something in React because you will learn a lot about why Ember does what it does and you will see a lot of really interesting things that will probably jostle some ideas loose in your brain. The same thing goes for React developers. You, 100% should spend a weekend building something in Ember and nothing about that means that you have to switch or it's going to change the path that you're going on at work but I guarantee you, you will go back to your React application with some new and fair useful perspective that you didn't have before and that's okay. That's great. There's no identity crisis that will come about as a result of that. CHARLES: That is a fantastic advice, Chris. It will only stretch you. CHRIS: Yeah. BRANDON: I think developers have been sold this idea of a competitive landscape by authors of these frameworks because it helps sell the framework. You can build and strengthen a community by leaning into the tribalism that can surround the usage of a tool. The older I've gotten as a person who was deeply tribalistic about Ruby on Rails when I got into it and Ember when I got into it, because I love tribes, I think tribes are awesome and it's a way to make friends but when you really lean into that, the costs are too high and experimenting with other technologies and noticing flaws in your own technology is not only not a betrayal, it's actually critical to your growth as a developer. The more people that do that, like Chris was saying, the better both of those ecosystems will get. CHARLES: Absolutely because having spent as much time in React as I have, I really appreciate the precious things about Ember. It will make you appreciate the things that you hold dear. It will make you appreciate the really, really, really special things about the tool that you're using and at the same time, it will highlight the weaknesses which you can immediately use to feedback and make your tool better. It really is a win-win situation. TARAS: I just want to do a little plug before we close up. I think the feels of working with Ember is actually gone into microstates and we're still getting our things together to make microstates look accessible and usable by everyone but that feeling of pleasure that you get from working with Ember and just things just being there for you, like we really want to reproduce that and make that available in React community and the stuff that we do in microstates is actually really designed for that. CHRIS: Yeah, I see that in BigTest too as well. That's definitely another place where it's like, "These people definitely used to spend time in Ember and they're now in React-land." It's cool to see that stuff getting ported over. CHARLES: Absolutely because it fundamentally changes your taste. Working with an application that doesn't have like a bolted on testing framework is like eating water soup. You just can't enjoy your life. It really is flavored everything that we do. On that note, we can go ahead and wrap up. There actually is some pretty exciting news. We're actually going to be launching a BigTest launcher. Up until this point, you kind of had to roll your own using BigTest for your assertions but using something like Karma to actually launch the browsers and we're actually launching our own launcher. I guess we've written our own launcher and we're going to be pushing it to NDM, not to overload the word launch. You can look for that in the next couple of weeks. There's going to be a CLI that ships with BigTest to help you do even more set up, to make it so that you can just drop BigTest right into your application, whether it's jQuery, React, Ember, you name it. That should be really, really fun. Be looking for that and with that, if anybody has any other remarks... BRANDON: If people are coming through RubyConf this year, I'll be there talking about management stuff. That's my only near-future conference stuff coming up. Hope to see some of the more Ruby-flavored folks out there. CHARLES: All right-y. Definitely, go to every single talk that Brandon ever gives. You won't regret it. I can base that on very dear personal experience. You won't be disappointed. You know, not to put the pressure on or anything like that but you could never put any more pressure on Brandon than he puts on himself. With that, we will say good bye. Bye Chris, bye Brandon. Thank you so much. This is a great conversation. It certainly clarified a lot in my mind -- TARAS: Yes, same here. CHARLES: -- About these problems. With that, we will say goodbye. Thank you for listening The Frontside Podcast. Please get in touch with us at @TheFrontside on Twitter or contact at Frontside.io on email. We do a range of custom services from full stack project development to JavaScript mentoring, to as you go JavaScript help desks kind of stuff. If you need to reach out to an expert, please get in touch. Our podcast as always is produced by the inimitable, Mandy Moore. Thank you very much and we'll see you all next time.

RRU 016: React, Redux, and JavaScript Architecture with James Sinclair

Play Episode Listen Later Jun 19, 2018 54:00

Panel: Charles Max Wood Sia Karamalegos Nader Dabit Special Guests: Jared Palmer In this episode of React Round Up, the panel discusses the article React, Redux, and JavaScript Architecture with the author James Sinclair. James is a web developer in Australia and he works at Squiz were he focuses on building a digital web place. They talk about his article and why he chose to write it, where he falls on the whole Redux debate, how to convince people to come to Redux, and much more! In particular, we dive pretty deep on: James intro React, Redux, and JavaScript Architecture Why were the people you are working with wary of leaving JavaScript? jQuery Great article on explaining why we use React Why React can be fast Is your team now moving to React or have they already moved over? Where do you fall on the Redux debate? Redux’s “disadvantages” are actually advantages What is your current stack of choice? Downshift Conditioner.js Most React tutorials assume you’re working on a single-page web app Sprinkles of jQuery Learning Redux helps to learn in a more functional way Functional programming as an influence to learn Redux Managing state How do you convince someone to learn Redux? Thoughts on GraphQL Apollo Server and Prisma Stimulus Apollo Link State And much, much more! Links: React, Redux, and JavaScript Architecture Squiz JavaScript jQuery React Redux Downshift Conditioner.js GraphQL Apollo Server Prisma Stimulus Apollo Link State jrsinclair.com @jrsinclair James’ LinkedIn James’ GitHub Sponsors Kendo UI Loot Crate FreshBooks Picks: Charles Being around family and friends Spend your life doing the things that really matter Sia Artificial Intelligence Machine Learning Nader React Native Training YouTube Channel Nader’s YouTube James Highland.js Functional Programming

RRU 016: React, Redux, and JavaScript Architecture with James Sinclair

Play Episode Listen Later Jun 19, 2018 54:00

Panel: Charles Max Wood Sia Karamalegos Nader Dabit Special Guests: Jared Palmer In this episode of React Round Up, the panel discusses the article React, Redux, and JavaScript Architecture with the author James Sinclair. James is a web developer in Australia and he works at Squiz were he focuses on building a digital web place. They talk about his article and why he chose to write it, where he falls on the whole Redux debate, how to convince people to come to Redux, and much more! In particular, we dive pretty deep on: James intro React, Redux, and JavaScript Architecture Why were the people you are working with wary of leaving JavaScript? jQuery Great article on explaining why we use React Why React can be fast Is your team now moving to React or have they already moved over? Where do you fall on the Redux debate? Redux’s “disadvantages” are actually advantages What is your current stack of choice? Downshift Conditioner.js Most React tutorials assume you’re working on a single-page web app Sprinkles of jQuery Learning Redux helps to learn in a more functional way Functional programming as an influence to learn Redux Managing state How do you convince someone to learn Redux? Thoughts on GraphQL Apollo Server and Prisma Stimulus Apollo Link State And much, much more! Links: React, Redux, and JavaScript Architecture Squiz JavaScript jQuery React Redux Downshift Conditioner.js GraphQL Apollo Server Prisma Stimulus Apollo Link State jrsinclair.com @jrsinclair James’ LinkedIn James’ GitHub Sponsors Kendo UI Loot Crate FreshBooks Picks: Charles Being around family and friends Spend your life doing the things that really matter Sia Artificial Intelligence Machine Learning Nader React Native Training YouTube Channel Nader’s YouTube James Highland.js Functional Programming

RRU 007: Breaking up with Higher Order Components with David Atchley

Play Episode Listen Later Apr 17, 2018 68:24

Panel: Charles Max Wood Nader Dabit Cory House Kent C Dodds Special Guests: David Atchley In this episode of React Round Up, the panel discuss breaking up with higher-order components with David Atchley. David has been doing software development for 24 years now and has worked mostly in web development. He has worked at many places from start-ups to large companies and does client work currently for Tandem.ly. They talk about what higher-order components and render props are and when you would want to use them to help you in your code. They also touch on overuse and misuse of applications and coding tools and the difference between using render props and HOCs. In particular, we dive pretty deep on: David intro What are higher-order components? What are render props? Higher-order components are patterned after higher-order functions Connect from React Redux React What are the use cases for higher-order components? Redux Would you suggest writing a render prop instead in certain situations? Deciding to use a HOC or a render prop depends on the situation Think critically about the applications you are using Kent’s Advanced React Component Patterns Egghead Course Difference between render props and HOCs Build an HOC out of a render prop if you want to share code Context API from React Concern with new Context API Problem with overuse How do you help people avoid overuse and misuse? Unstated library by James Kyle Start developing code at the local level React Native And much, much more! Links: Tandem.ly React Redux Kent’s Egghead Course Context API from React Unstated library by James Kyle React Native David’s GitHub @Tuxz0r Tandem.ly Medium Picks: Charles I’d Pay You $500,000 a Year, but You Can’t Do the Work by Shelly Palmer Liars by Glenn Beck Cory CodeSandbox Live Babel repl React Cheat Sheet Fluent Conf Nader Shoe Dog by Phil Knight Nader’s Blog Post Kent Answers to common questions about render props blog post React’s new Context API blog post React Composer Brandon Sanderson CodeSandbox Live David React, Inline Functions, and Performance by Ryan Florence Build Better Products by Laura Klein

work performance medium concerns panel kent deciding react special guests babel redux github liars breaking up components blog post tandem nader glenn beck brandon sanderson phil knight shoe dog react native hoc higher order kent c dodds atchley nader dabit shelly palmer laura klein charles max wood shoe dog memoir creator nike pay you react redux build better products ryan florence james kyle react round up cory house unstated fluent conf context api

RRU 007: Breaking up with Higher Order Components with David Atchley

Passion and Purpose with Josh Moxey

Play Episode Listen Later Apr 17, 2018 68:24

Panel: Charles Max Wood Nader Dabit Cory House Kent C Dodds Special Guests: David Atchley In this episode of React Round Up, the panel discuss breaking up with higher-order components with David Atchley. David has been doing software development for 24 years now and has worked mostly in web development. He has worked at many places from start-ups to large companies and does client work currently for Tandem.ly. They talk about what higher-order components and render props are and when you would want to use them to help you in your code. They also touch on overuse and misuse of applications and coding tools and the difference between using render props and HOCs. In particular, we dive pretty deep on: David intro What are higher-order components? What are render props? Higher-order components are patterned after higher-order functions Connect from React Redux React What are the use cases for higher-order components? Redux Would you suggest writing a render prop instead in certain situations? Deciding to use a HOC or a render prop depends on the situation Think critically about the applications you are using Kent’s Advanced React Component Patterns Egghead Course Difference between render props and HOCs Build an HOC out of a render prop if you want to share code Context API from React Concern with new Context API Problem with overuse How do you help people avoid overuse and misuse? Unstated library by James Kyle Start developing code at the local level React Native And much, much more! Links: Tandem.ly React Redux Kent’s Egghead Course Context API from React Unstated library by James Kyle React Native David’s GitHub @Tuxz0r Tandem.ly Medium Picks: Charles I’d Pay You $500,000 a Year, but You Can’t Do the Work by Shelly Palmer Liars by Glenn Beck Cory CodeSandbox Live Babel repl React Cheat Sheet Fluent Conf Nader Shoe Dog by Phil Knight Nader’s Blog Post Kent Answers to common questions about render props blog post React’s new Context API blog post React Composer Brandon Sanderson CodeSandbox Live David React, Inline Functions, and Performance by Ryan Florence Build Better Products by Laura Klein

work performance medium concerns panel kent deciding react special guests babel redux github liars breaking up components blog post tandem nader glenn beck brandon sanderson phil knight shoe dog react native hoc higher order kent c dodds atchley nader dabit shelly palmer laura klein charles max wood shoe dog memoir creator nike pay you react redux build better products ryan florence james kyle react round up cory house unstated fluent conf context api

Be a Rookie

Play Episode Listen Later Mar 17, 2018 2:55

Many times I get caught up in trying to be great, and I forget that I must be a rookie first in order to be great. It hurts the ego, but fuck the ego. Here's my experience from December, in my first stages of learning React/Redux on my own. -- My links: Website: https://joshmoxey.com Instagram https://instagram.com/joshmoxey Facebook https://facebook.com/joshmoxey YouTube https://joshmoxey.com/yt Snapchat https://snapchat.com/add/moxeyjosh Twitter https://twitter.com/joshmoxey Intro/outro music: trfk - monday https://soundcloud.com/trfkmusic/monday

entrepreneur mindset designers snapchat rookies developers vlog gary vee web design web development web developers audio journal react redux

#32 – Андрей Смирнов о том, как появился Frontend Weekend и как из разработчика стать руководителем

Frontend Weekend

Play Episode Listen Later Dec 17, 2017 47:11

Андрей Смирнов, ведущий подкаста Frontend Weekend, отвечает на вопросы Дмитрия Ковальчука и Николая Чернобаева из LoftBlog. Хочешь поддержать Frontend Weekend, переходи на http://frontendweekend.ml ;) - Как театральная деятельность повлияла на жизнь и работу? 00:37 - Выбирал ли между театром и IT-сферой исходя из денежного вопроса? 04:22 - Растет ли сейчас потребность в подобного рода специалистах (с софт скиллами)? 08:14 - Похоже ли это на Developer Relationship и могут ли разработчики стать руководителями? 10:40 - Где работал до Rambler&Co и каков был весь этот путь? 12:28 - Три компании в Москве, где, по мнению Андрея, классно работать 15:55 - Насколько предан Рамблеру и переехал бы за границу? 17:26 - Почему программисты так часто меняют места работы? 20:16 - Как появился подкаст Frontend Weekend (идея, цель и первые проблемы)? 24:09 - Думал ли закрывать подкаст, когда Артем уехал в Амстердам? 30:02 - Почему не продолжил писать подкаст удаленно с Артемом, когда он уехал? 32:23 - Какая на самом деле цель у подкаста и помогает ли он продвигаться по карьерной лестнице? 33:41 - Появится ли когда-то в подкасте реклама или почему Андрею стыдно собирать донаты? 34:38 - Три программы, которые Андрей использует каждый день (Telegram, Sublime, Zeplin) 39:07 - Технологии, которые стоит изучить (React/Redux, Java, криптовалюты) 43:31 - P.S. Почему такой внешний вид? 45:57 Ссылки по теме: 1) Доклад Андрея на MoscowCSS – https://youtu.be/o39tg3BgABw 2) Тот самый розыгрыш на 500 подписчиков – https://youtu.be/o39tg3BgABw 3) Frontend Weekend Patreon – https://patreon.com/frontendweekend

telegram java sublime rambler zeplin react redux loftblog frontend weekend

#32 – Андрей Смирнов о том, как появился Frontend Weekend и как из разработчика стать руководителем

Frontend Weekend

Play Episode Listen Later Dec 17, 2017 47:11

Андрей Смирнов, ведущий подкаста Frontend Weekend, отвечает на вопросы Дмитрия Ковальчука и Николая Чернобаева из LoftBlog. Хочешь поддержать Frontend Weekend, переходи на http://frontendweekend.ml ;) - Как театральная деятельность повлияла на жизнь и работу? 00:37 - Выбирал ли между театром и IT-сферой исходя из денежного вопроса? 04:22 - Растет ли сейчас потребность в подобного рода специалистах (с софт скиллами)? 08:14 - Похоже ли это на Developer Relationship и могут ли разработчики стать руководителями? 10:40 - Где работал до Rambler&Co и каков был весь этот путь? 12:28 - Три компании в Москве, где, по мнению Андрея, классно работать 15:55 - Насколько предан Рамблеру и переехал бы за границу? 17:26 - Почему программисты так часто меняют места работы? 20:16 - Как появился подкаст Frontend Weekend (идея, цель и первые проблемы)? 24:09 - Думал ли закрывать подкаст, когда Артем уехал в Амстердам? 30:02 - Почему не продолжил писать подкаст удаленно с Артемом, когда он уехал? 32:23 - Какая на самом деле цель у подкаста и помогает ли он продвигаться по карьерной лестнице? 33:41 - Появится ли когда-то в подкасте реклама или почему Андрею стыдно собирать донаты? 34:38 - Три программы, которые Андрей использует каждый день (Telegram, Sublime, Zeplin) 39:07 - Технологии, которые стоит изучить (React/Redux, Java, криптовалюты) 43:31 - P.S. Почему такой внешний вид? 45:57 Ссылки по теме: 1) Доклад Андрея на MoscowCSS – https://youtu.be/o39tg3BgABw 2) Тот самый розыгрыш на 500 подписчиков – https://youtu.be/o39tg3BgABw 3) Frontend Weekend Patreon – https://patreon.com/frontendweekend

telegram java sublime rambler zeplin react redux loftblog frontend weekend

React Redux and Retrospectives

Eat Sleep Code Podcast

Play Episode Listen Later Oct 5, 2017 69:20

On this episode of Eat Sleep Code, guest Margaret James shares her retrospective of web technologies leading up to modern front-end development using React. Margaret talks about her experience as a developer joining the industry two years ago and what it's like to look back on previous generations of JavaScript technology.

development code software mobile programming react javascript retrospectives react redux

128: Catching up with Mr. Hart

Three Devs and a Maybe

Play Episode Listen Later May 17, 2017 47:42

In this weeks episode we are joined by fellow co-host Fraser Hart. We start off by discussing what he has been upto since his last podcast appearance - ranging from completing an Ironman, to promotions at work. From here we highlight how he balances development with his new project managerial role, how his company has started to adopt React/Redux and moving over to Webpack 2. Finally, we delve into the different server stacks we are using, and how the KISS design-principle plays a key-role.

kiss iron man catching up hart webpack react redux

060: Ember and Fastboot with Jonathan Jackson

The Frontside Podcast

Play Episode Listen Later Mar 3, 2017 38:53

Jonathan Jackson: @rondale_sc | Ember Weekend | 201 Created Show Notes: 01:01 - 201 Created 03:09 - 2017 Ember Community Survey 14:06 - Handling Changes and Churn 27:53 - FastBoot Resources: Boots and Shoeboxes [SlideShare] Typeform EmberConf JSX Isomorphic JavaScript Ember Weekend Episode #66: Bug Integrat (with Charles Lowell) Transcript: CHARLES: Hello, everybody. Welcome to The Frontside Podcast Episode 60. My name is Charles Lowell. I'm a developer here at The Frontside. With me is Robert De Luca, also a developer. Hello, Robert. ROBERT: Hello, hello. CHARLES: Today, we actually have a meeting of the podcast minds. We have with us a very special guest, Jonathan Jackson. You probably know him from the Ember Weekend Podcast. If that's your thing, it's a great podcast. I listen to it, you should definitely check it out. Hello, Jonathan. JONATHAN: Hey, how are you doing? I'm really excited to be on the podcast. I am an occasional listener. It's similar to my own podcast where if I don't edit it, I tend not to listen to it. It's when I have long trips you guys are number one, number two right behind The Adventure Zone which is a D&D podcast. CHARLES: You worked at 201 Created. Why don't you tell us a little bit about that? It's an interesting company. JONATHAN: Actually, when we book to this podcast, I was not at 201 Created. This is a very new thing for me. I think I started right around the time of Ember Conference out in San Diego and I'm just realizing that this is not exclusively an Ember podcast. This is the first podcast I've been on where I can't just assume blanket knowledge of Ember stuff. But it's an Ember conference out in San Diego. I actually gave a talk there about FastBoot which is a server side rendering technology. Right after that, the entire 201 company which I think is four. It's very small. The entire thing, the whole crew went to do a company event and basically camped out in the mountains for a few days, which was really, really fun. But I started working there and 201 is a consultancy based out of New York but I think it's more than half is remote. I think Matt's on the West Coast, two of them are in New York and I'm in Jacksonville right now. We do a lot of really cool stuff. We worked in a lot of different companies. You can actually see the website at 201-Created.com and you can see the different clientele we worked with. But we specialized in consulting, training as well. As well as a couple of other services that we offer. It's been a real great experience. It's been very fun and also I'm learning a ton which is really cool to be in a different environment. I have done consulting for a little over four years, previously at Hashrocket. I got to tell you, consulting will get your wheels turning. It's been nice to see how different consultancy takes a stab at things. It's been super fun. CHARLES: Yeah, it's a fantastic company. I've definitely known them for a while, certainly through my involvement in the Ember community and one of the things that always struck me is just how seriously they take the community aspect of it. We were talking about just a little bit ago, it was 201 that sponsors -- well, sponsor isn't really the right word for it. It does the Ember Community Survey which I think is a practice that we're now used to in the Ember community but I think it's something that I would love to see wider communities do. Maybe you could talk a little bit about that and explain what this community survey is, why it exists and what's the knowledge that's derived from it and how do we take action on that? JONATHAN: 201 also does contribute workshops and things like that. The idea is to make Ember a more inclusive space, a place where people feel comfortable being a part of our community and a big part of that is self-reflection and realizing where you have weak points and how you can actually mend areas that are being neglected or whatever. Basically, shining a light to figure out where we need to improve and a big part of that is the community survey so figuring out what technologies are being used, figuring out what demographics are represented or under-represented and trying to figure that out. It's actually been really cool. I think this is the third community survey and it's live right now. I feel like we could probably shed a little bit about some of the questions. This year, they did a really cool thing where they actually put all of the questions before they put the survey up live. They actually asked for a comment period which is very, very Ember thing to do. CHARLES: Because I was actually going to ask about that. Who is the final arbiter of the questions that get in because part of the survey is determining you're trying to get hard metrics on a set of questions but it's the questions that you don't know that you should be asking which are really the tricky ones. JONATHAN: It was really interesting to watch the document change over time. There was a committee discussion between some of the people in core team and Matt Beale and Tom Zalman who's been doing the organizational stuff as an intern at 201 and he's been doing a fantastic job of really staying on top of it. It's a surprising amount of work to get a survey together, especially when you have a comment period so there's tons of little adjustments here and there need to be made, to wording and phrasing and also like responses. Surprisingly enough, you can actually have biases in your questions based off of the responses that are allowed because multiple choice. It's been a really interesting effort and I think trying to weigh and balance that side of things, where you want things to be worded in a way to where people can answer more honestly and without a bias coming into the question. Because the questions change year over year, trying to get data that is historically relevant so we can see what versions were being used last year and versus this year, what was your experience level with Ember last year and this year. But still make those changes that are recommended. It's an interesting balancing act. I was very interested in the process. I was trying to stay as involved as possible but I think also, Isaac was working on that as well. It's been a team effort. The survey is a very interesting aspect of the Ember community and it's only been three years but it feels like longer. CHARLES: What I love is the work. Once you actually get the survey up, the work has just begun, which clearly a lot of thought went into it, not just the questions that is very beautifully presented -- ROBERT: But the survey, what's the software that you're using to do that? JONATHAN: I think Typeform is the thing that they're using. I feel like it actually works on mobile and I have a great analytics tools. If you're doing a survey, you should come talk to me. ROBERT: Does that like track people that half-fill out a survey and exit? JONATHAN: Yeah, it does. It actually does track like -- what's the word for that -- there's a word for that. Basically, the main metric that we're looking for is people who open the form then complete it and the percentage there, that's the respondent percentage. I've actually haven't seen the metrics yet. I think I might just wait until the conference. You're exactly right, this is only the first step so once everyone fills it out, then there's a bunch of data extraction because some of these questions are open-ended and allow users to directly input their own feedback and trying to sort that and make that useful information as a lot of work and a lot of effort. It's interesting to see, of course there's some obvious graphs that are going to happen like we see transitions. It's easy to graph out the number of people using things on a time axes or the X-axis or whatever. There's some kind that are obvious but I'm actually looking forward to seeing the results. I was only really involved in the actual administration of the survey in as far as I provided some feedback before the main feedback period. But it's been really a community effort which is great because it's a community survey. That's pretty neat. CHARLES: One of the questions that I have is how do you ensure, because the only people who hear about the survey are the people who are already involved. In order to get -- I don't want to say statistically valid -- a broad and more informative data set, how do you try and balance the concern of we want to make, maybe half people exposed to this who aren't inside my community or maybe sitting on the boundary somewhere or slightly over somewhere versus at some point, if someone's an attorney for example, then we don't really care if they hear about or participate in the survey. Certainly within the developer community, which is ill defined to begin with, how do you try and draw those lines to make sure that you get the best knowledgeable dataset possible? JONATHAN: You know, I don't really know. I guess, it's the meta point that I should probably make but it will prevent me from giving my opinion. Basically, I think that since this is a community survey, it makes quite a bit of sense for the community avenues for learning about Ember to be used to actually distribute the survey itself. For instance, these podcasts, like my podcast as mentioned in the survey and now, this podcast is going to mention in the survey. I want to say, "It's going to be in Ember Weekly." That's just a guess, I don't know. But there's really avenues: Reddit, Twitter, etcetera and then the Ember blog itself. Those are the means for dispersal within the Ember community. The one metric that we get from that is what can we reach or who can we reach? How many people can be reached through the normal means? That in itself a metrics. But I think it's kind of valuable to test that every once in a while. I believe over the first two, we saw 100% increase in respondents from Year 1 to Year 2 so it'll be interesting to see from two to three to see if that number continues to increase at a really rapid clip or if we're seeing some other trend there. It is an Ember survey so we are going to assume a lot of Ember-related things. We're trying to gain insight into the Ember community so it's probably not great to put it on JavaScript Weekly, for instance and get a bunch of React developers in that. They're going to be like, "I don't use this." Why are you using Redux, they don't understand. Oh, wait, Ember Redux, what's that? That sounds up my alley. ROBERT: I did feel that form out at the survey with my experience that I've had with React recently, things that I would like to see come over to Ember. I don't know... That'd be interesting to see or I wouldn't want them to fill it out because they would, obviously ruin the data set but I think another survey with more information from other communities to see like, "What's preventing you from utilizing Ember or what are the barriers to learning it?" Maybe from other communities might be interesting. That would be cool to do cross-pollinated surveys where you can be like, "We'll do it, if you do it and then React can provide us something and vice versa. I feel like the word homogenization is bad, usually but sharing ideas is good, I think. CHARLES: If you've never experienced this in your development community, the amount of work that goes into actually analyzing the survey and trying to draw and make inferences from it is just astounding. Who does that? Is that like Matt sitting up in an ivory tower? That's was just the wrong term. Basically, he can sequester himself for a month and put on his thinking cap and just come out with these mind-blowing deductions? JONATHAN: To be honest, I wasn't here last year at 201. My suspicion is that Tom will do quite a bit of the data munging, I think is the word. Then we'll go through phases where I think Isaac and Matt are working pretty closely with the survey stuff so they'll probably do feedback loops, then eventually before anything happens, I think with EmberConf, there's usually a survey blog that comes right alongside the EmberConf thing, where you share some of the results. I think that those things will go out to core and then core will start to pick it apart, toss that around exactly and then come back and basically, you're going to try to get as many people who are pretty smart, looking at it and trying to make sure the data makes sense and honest and doing the right things the survey needs to do, in relevant, I guess is the other metric. CHARLES: Now, as part of the survey, one of the things that you mentioned was the purpose is to surface weaknesses and gaps that need to be filled. When you think about your experience and the way that you filled out the survey, obviously it's anonymous, share what you're comfortable sharing but what were some of the things that you perceived as maybe holes that need to be filled and you're hoping that the survey will bring to light. JONATHAN: That's a very interesting question. I think, the thing that I'm interested in seeing is maybe different than what I've seen. One of the things I'd really like to see the survey that bring to light -- it's probably the most important metric in my mind -- is where people are at in the upgrade process because the cadence of releases an Ember is such a big facet of what makes Ember really powerful, especially for large companies and stuff like that. But I've personally seen people get stranded in certain spaces. Usually by the time they call a consultant to help them get un-stranded, they're at a point where they're going to try to work towards pushing past it. I think this is felt primarily around the 1.13 switch. People did get stranded there and some people are still working on very large apps to push past that and I would really like to see just where the community is at right now, in general. Especially as a consultant because you come into a project and I don't necessarily know what to expect. I think on certain teams, I am always shocked I see like, "Oh, you're using beta and everything. You guys are on top of this. That's really cool. Let's do some feature [inaudible]," and you're really excited. But then other times, you get called in and they're like, "We're still using 1.13 and we have bind others in our source and could you please help us?" CHARLES: Right and it's just that mountain is just too big to cross. That's something that you see in software development as the tools that you use tend to change and for lack of a better word, rot over time. In comparison to what's more newly available, it's the phenomenon of JavaScript churn, which is known in the community at large, scope down to just one framework where you've got different versions of the framework and you've got this churn. It's been somatic for Ember to try and it has been very aggressive attacking this problem and yet still, it manages to happen. How does that work, just given the amount of attention? JONATHAN: Ember, hands down handles this better than most other JavaScript projects that I've seen. I've gone to old backbone apps throughout my career and knock out in Angular one, etcetera. I've seen the rot that we're talking about here and usually, once it gets too bad, the authors of the JavaScript libraries are unable to push it forward at all. Either band in it or end of life it and you're going to have to invest your own time to get pushed past this point. In Ember, it really strenuously disagrees with that philosophy. They try super hard. All the people in core and really the community at large, the philosophy is like, "No, we're not going to break Ember. Ember is very serious here. We're not going to leave people stranded," yet it still happens. The reason I'm curious about seeing it is really about how do we make that story like a solved problem. Is it possible to do? Is it possible for us to basically make it to where the Ember community can very honestly say, "If you choose us if you choose this framework, it will be around. There will be a path forward for you for five to ten years and that's not something you can get a promise from anywhere else." I just want to see what are the ways that we can make that promise more strong. I think, the LTS was a big step in that direction. I think that was actually last EmberConf which the LTS was announced? ROBERT: Yeah, absolutely. Definitely all of our clients have moved to LTS as rather than trying to do every six weeks because they find that much easier to upgrade in between and they're more stable. JONATHAN: They're more stable and I think it's such an easier sell like if you actually start talking about going up the pipeline and you're like, "I have to talk to my boss and my boss just to clear money. We have to clear time, etcetera." We're going to put a [inaudible] aside every six weeks to upgrade seems a little untenable for a lot of companies. I think for larger companies, it's sometimes okay because they're actually utilizing some of the edge features which is cool and I think that's a big thing. I feel like I have no real insight here but I feel like that's what LinkedIn kind of does, where they're usually pushing the boundaries because they're utilizing features like engines were first brought into LinkedIn. I think it kind of pushing it at the edge. ROBERT: If you have the new LinkedIn Ember app, if you will crack open the inspector, when I last looked, I think the beginning of this week, they had two beta versions deployed. The Ember data version, that was beta and actual Ember, it was beta. CHARLES: Usually large companies are associated with big lumbering end piece that are in terrible condition. That's actually a breath of fresh air. Shout out to LinkedIn. ROBERT: Ember Data is 2.12 canary and Ember is 2.10 Beta 2 patch so it looks like they have a patch version. JONATHAN: It doesn't surprise me that Data is being pushed. I think last I spoke to [inaudible] right around December, he was doing a lot of perf work on there so I think he's really pushing that pretty hard. There's a lot of really cool stuff like that and I feel like it kind of runs the game. You see the smaller teams who choose Ember for stability, they sometimes get stranded so I want to see if some survey data can probably correlate. You could correlate the size of your company to the version of Ember you're on. Maybe, we'll see some trends around if it does it mean that smaller companies have more difficult time pushing forward. That would actually be a little counterintuitive. I would expect that smaller companies would be able to push forward at a faster clip because they usually have to support fewer browsers, etcetera. It'd be interesting to see information like that because I think that promise for ease of upgrade and there will be a path forward, that's a big part of what makes Ember really appealing to me. Especially as a consultant for four years, you see so many projects. I don't ever really want to advocate a rewrite but we're going to have to spend a significant amount of time fixing this and it's because you went with Mootools or something. Everybody guess Mootools wasn't so bad. CHARLES: But the point is that you didn't go with a holistic solution so you basically had to write your own framework. JONATHAN: Yeah. ROBERT: Yeah, in Ember, it is a feature that you will not be left behind and you can upgrade. That is something that is really nice. I have upgraded a lot of Ember apps. JONATHAN: I think Mike North calls that the patchwork app application. It's not just like React apps where you have React-Redux and Preact and all of this other stuff that you kind of piece together and make your own little quilt and that's your application. But this also happened in Backbone. It happened in jQuery before that and it was just like take this thing, take that thing, then I have this custom quilt, which is not bad. There are some advantages -- pros and cons. CHARLES: Ember is giving you a blanket. JONATHAN: And it's going to be a comforter. It's going to probably all look the same and be right. ROBERT: My experience is I love Ember and I love the convention over configuration but whenever you hit that wall of the convention is actually getting in the way now, that is a very tall wall to scale in Ember. CHARLES: Yeah, I think the flip side of it is like you say, Rob because everything does have to mesh, because that blanket has to be one solid weave, it means that you've got a hole in the blanket, the surgery required to excise that hole and then patch it -- ROBERT: I love his metaphor. His metaphor is -- [Laughter] ROBERT: It's so good. CHARLES: It takes a lot of effort. ROBERT: Today, I'm quilting daily. CHARLES: That's right. Next topic, crochet. [Laughter] CHARLES: But, yeah in order to make that surgery on the blanket to mix metaphors, which I love to do so freely, you have to make that cut and then make sure that the weave is again, seamless. I think that takes a lot of thought, it takes a lot of effort and it takes a lot of time. It means that there are shiny things out there that you might not be able to have. I think, one of the ways that the community and the technology is mitigated is with the add-on ecosystem, which is very, very strong and allows you to riff and experiment and push those boundaries. But there are core pieces, things like the rendering engine, which can't really be modified or hooked with an add-on. They can but not in deeply fundamental ways or the templating. We saw that happened. There was a big kind of shift from first, the old handlebars to -- ROBERT: HTMLbars? CHARLES: HTMLbars and then Glimmer 2, which there's been a flurry of activity around there but that was definitely one area where there was a hard wall right now. I feel like for me it's around the handlebars itself. I would like to see that environment become more powerful because certainly, with the React Native work that we've been doing around here, you get to see just how simple like the JSX model is, React aside because like Vue, you can do with JSX. I think JSX is a separate technology. It's certainly integral to React but there are a lot of other frameworks now that are using just the JSX part for the templating. Seeing that there is real power in being able to have the functional programming aspects of JavaScript right there inside your templates. From my perspective, I think that in Ember, there's a wall there that needs to be scaled. ROBERT: To be clear to the Ember developers that are listening like us kind of advocating JSX, if you are having like, "No, that's a terrible idea. I hate JSX," I had that very exact reaction about a year and a half ago. If you go look at my Twitter feed, you would see me ranting about how much JSX is a bad idea. After I actually played with it, I'm on the opposite side. I think JSX is really awesome and I think there are things to learn from it. CHARLES: I definitely love having templates. I love having the separation. I like having it in a different file but at the same time, I don't want to lose sacrifice the power that comes. I think that for people who are kind of sitting on the fence or have played with it, if you actually are strict about not having side effects and things in your templates, it really is a great experience. I think there's a lot of people who have scars from doing ERB or liquid templates, where you can have all kinds of crazy side effects -- ROBERT: That's where my scars came from -- ERB. CHARLES: Yeah, I can show. I can roll up my sleeves. I will be like, "You see this? I got that back in aught-seven with an ERB app, where they were calling out to a service from inside the template." ROBERT: Setting the variable and modifying everything. CHARLES: Yeah. There's definitely that tradeoff. One of the things that is great about the Ember community in particular is when there is, it takes a while to generate the will to recognize that this is a major problem but then the solution that you do get does, eventually match the weave of the entire blanket, which is really, really nice. But it can be frustrating when you have those core pieces of infrastructure that are presenting those walls to you. ROBERT: I'm excited for Angle Bracket components because that's actually a lot of the gripes that I had with handlebars. Whenever I got a bunch of the curlies next to each other, like a bunch of components around each other, they all kind of just mold together and seeing the brackets and just looking like HTML, it makes it so much easier to grip. CHARLES: Yeah, it's weird because you think that small things won't have big impact and you think that big changes ought to have a big impact. An example of this, I was kind of derisive of the whole Angle Brackets syntax. I was like, "Urgh! Angle Brackets, dah-dah-dah..." Then we started doing more JSX and you start seeing like, "I want to have my templating construct separate from my JavaScript and scripting constructs," and it actually makes a huge difference in clarity there. Obviously, the change to make all that happen is big but it's a small difference in the syntax. Tiny but I think it has a huge impact in the readability and the clarity of the templates and by the same token, all the performance increases. At this point, I couldn't even give a flip. It's nice. It's great but there's a barrier, there's a threshold that has been crossed, actually some time ago. Performance of rendering is -- I can't even remember the last time it was a problem. What about you? Have you run up against performance issues in your Ember apps? JONATHAN: Some performance issues but usually, they're a result of some rather inefficient rendering. Basically, a combination between user and keyboard or whatever. I wrote something really bad. It's not Ember getting in my way. I don't particularly mind the curly braces within my template but I think a big part of that is just editor choice. If your editor syntax highlights then it also knows how to indent handlebars correctly, that makes a huge difference. ROBERT: Are we about to start an Emacs versus Vim war here? [Laughter] JONATHAN: No, as a matter of fact, I suspect you would win that when the Vim -- there's no good solution for indentation in handlebar templates that I found in Vim. If anyone knows that [inaudible], "Oh, there's one plugin," please ping me on Twitter because that would be nice. CHARLES: Well, yeah. It's true. I can deal with it. I don't think it bothers me quite as much as it does Rob but I think what has been interesting is in our hypothetical code, you always like pay snippets in Slack. We started using Angle Bracket syntax just because it's so much clearer. Even though, none of us actually use it in any of our apps, when we're actually exchanging ideas, that's what we use. JONATHAN: Yeah, there's some cool things that come with Angle Brackets that aren't just aesthetic. The container element is like you don't have to deal with the tag lists stuff anymore. I feel like there's a few tradeoffs that are going to be really interesting to see when those start becoming the norm. CHARLES: Yeah, I like also the separation of what they did from JavaScript attributes to HTML attributes. It's really clear. JONATHAN: Totally. I think it's [inaudible] cool stuff. CHARLES: It's exciting. I remember being derisive of it -- not divisive, that's not the right word -- but I'm thinking like, "Why are they spending so much time on this," but I actually think it is going to have a big impact, small change. JONATHAN: Totally. CHARLES: No dis to the people who are working on it. I know it doesn't feel like a small change at all. ROBERT: Yeah, it only took a year and a lot of really hard work. [Laughter] ROBERT: Like I peek in there and I'm like, "Hmmm... Nope, not smart enough yet." CHARLES: One of the things that I want to ask you, you mentioned that at SO Ember, you gave a talk on FastBoot. You've actually got a lot of experience around the subject so I'm just curious. First of all, what were you talking about? JONATHAN: I think my talk was actually called Boots and Shoeboxes, which there's a little library function into the FastBoot suite called the Shoebox where you can communicate between node and the browser. It's not like well-known enough to where that title resonated with people. I got up on stage and I was like, "You know, we don't have any descriptions on the speaker note like website. He just talks about FastBoot. I hope that I don't disappoint you," because they had no idea what I was talking about. Actually, I feel like the problem that's the FastBoot solves is a persistent thorn in people sides. CHARLES: So what is the problem just to give full context? I think is it called like Isomorphic JavaScript for something -- JONATHAN: Yeah, I don't like using that word. CHARLES: Yeah, there's like server side, SSR -- JONATHAN: Yeah, SSR, you'll see that a lot. CHARLES: I guess the question is why would you even? JONATHAN: That's a multi-faceted question. I think the first section of it would be what's the problem? I think for a lot of people, the biggest problem is SEO. A lot of JavaScript frameworks are not search engine friendly, then that affects a lot of different things. It means that they're not archivable either so it's not like you can have this on archive. They're not very crawable. This is becoming less of an issue because Google Crawler, for instance will actually parse JavaScript now. But I feel like that's still limited. Also you have to then think about how the Crawler is going to like actually execute your JavaScript. You're like, "Wait a second, so now I have to have a compatibility table for Google Crawler? That sounds madness." I think that's a big component. There's also the idea of speed downloading as low as poor connectivity devices or locations, I guess. Having to download all the JavaScript before you see the first meaningful thing is not a very good experience. Especially for a huge swaths of different types of sites like Discourse, I think is a big Ember forum software. Forums are mostly just static text, like you just want to read the text so time in First Meaningful Paint could be like as soon as you get text onto the page, that's could be really fast. Some sites that doesn't make sense for it like if you're posting a video game or something like that, like you need interaction for that site to be meaningful. There's still tradeoffs there but there's a whole host so I guess that's the need. Then the solution for a lot of people is to start rendering JavaScript on their backend software and presenting full HTML along with a JavaScript source tag so that you get a Meaningful Paint first and then you get the JavaScript a little afterwards. The whole point of my talk, which I was basically like -- CHARLES: That's a hard problem. JONATHAN: Oh, it's a very difficult problem. CHARLES: Unlike anyone who says they have a solution, you should look at them with extreme mistrust. JONATHAN: Yeah and there's a whole bunch of different solutions that people have tried. You could actually have prerender.io, I think is the service that will actually render it for you and you put it in front of your CDN and they'll actually do that and create static files for you, which is a solution or no script tags. You basically render all of your stuff as much as you can on the server side and you put everything into no script tags and that will presents its own problems. There's a bunch of different solutions that people have tried. In FastBoot, the solution that Ember went with and I think that it's really cool because server side rendering and this is the big reveal of my talk. I think it's recorded so you can check it out. But the bigger reveal is that the server side rendering is not just about rendering. It's also about routing and data fetching and authentication and etcetera. There's a whole bevy of things that you also have to handle very well. It's not just taking a component, the view layer to component and rendering it to HTML and then serving that. It's much more than that. You want your app to basically run in node. FastBoot does that remarkably well. There are some spots where it's a little fuzzy but does it remarkably well. CHARLES: What's an example of how you would might need to handle authentication? That sounds terrible. ROBERT: One of the problems for a lot -- JONATHAN: That's exactly the problem. You actually have access to headers and stuff and FastBoot land so you can do authentication by using traditional token off, which is pretty cool. There's a lot of really cool things and routing is obviously handled quite well so the request comes in and it does the normal Ember router. The Ember app instance itself is running in node so all of the things you expect to work in the browser, work in Ember and node, with the exception of any time you need to access the DOM because the DOM is expensive like very, very, very oddly expensive. Like JSDOM is just expensive and unreliable, then you have to deal with compatibility tables for that. Anyone who has written tests for Phantom and tried to bind a function or something, they know the pain. I think it's fix now but I was always bitten by that so many times. It doesn't even give you the right error. Forget about it. CHARLES: You have all these things. It's basically authentication. It's data. It's making sure that you have in your, so to speak, headless environment as an authentic replica of your application running in the user's browser, as you can possibly retain. JONATHAN: Yeah. CHARLES: How feasible is that? Like what you're saying is that Ember takes that whole approach and says, "Okay, we're going to make sure we handle all of these cases?" JONATHAN: Yeah, I think Ember has done a phenomenal job of this. It's still alpha software, although I believe that the path to 1.0 is basically paved. It just needs some documentation. I think FastBoot hits the nail right on the head and gets a lot of the stuff really in a good place. It's also a big part of FastBoot's call to action where this stuff is possible elsewhere. You can do all of these things. You can make all of the stuff work in the React ecosystem or Vue ecosystem, etcetera. But in Ember, it's Ember install, Ember FastBoot, I think or Ember CLI FastBoot which is a really compelling sell because I've looked at some of the alternative approaches and in other ecosystems, they're very complicated. It's not possible. It's just their ad hoc -- ROBERT: And it's usually a 10,000 line medium posts that you have to follow line by line -- [Laughter] CHARLES: Right so instead of giving you actually a working code, what you get is a treasure map. JONATHAN: Yeah, exactly. It's like you just shop at Ikea. Here you go, build it. There's some really cool stuff that it unlocks and the fact that it's so low-hanging fruit, for instance Ember Weekend, which by all accounts does not need to be on FastBoot, isn't on FastBoot because it's ostensibly free and it's a good testing ground for me to learn about FastBoot. But the future -- ROBERT: It's interesting in handling audio on a FastBoot, how was that? JONATHAN: Since the user doesn't actually can't listen in node land, the user can only listen in a browser, we don't do anything with the player in FastBoot land, which is fine. There are some weird things like you have to basically have guards around like key events, for instance. Because Mousetrap relies on, I believe in jQuery to bind its events, you have to basically say, "In node land, we're not going to bind any of these Mousetrap events because they will not work," but there are some things you have to learn about the ecosystem but by and large, it's a solution that you just drop in and you just get for free. I think that's a huge sell. That's another thing with the convention over configuration argument, the model is that eventually, once the solution arrives, most of the people who are using Ember can just use it right away. It really does help with [inaudible] activity devices. There are some really interesting things about how time to first paint, I think Martin [inaudible] just released an add-on that basically says, "I'm going to take all of your JavaScript files and mark them as async and then when you download, the time to first paint becomes almost immediate," because it's just going to say, "I have HTML. Here's the HTML and serve it." Then in the background, because of script tags or whatever, it just goes and fetches the stuff in the background and you end up like time to First Meaningful Paint is really cool so it'll perform software that is super neat. If Discourse wanted to say, "Here's the stuff and we're going to make it work later," like as soon as the JavaScript has download, that's a really cool sell too. There's a lot of weird edge cases and describing the interactions is I think the hardest part about FastBoot. It's just like describing why this might be really good for you is the hardest part because a lot of people don't have these problems. If you're doing a marketing site, you're probably going to use Squarespace or something. ROBERT: Yeah, like a static site generator or something? JONATHAN: Yeah, exactly. ROBERT: Something that will give you great SEO results. JONATHAN: Exactly. ROBERT: You want to play around with that. JONATHAN: This dovetails into something Edward Faulkner was talking about eight or nine months ago when he was working on the inline content editor for Ember. It's really, really neat. I actually like to see where that's at now. I think it was Cardstack that funded a lot of the stuff for it. But if you combine things like that, then also FastBoot, you're starting to talk about something that could do what WordPress does, which is a really interesting thing like the really, really low hanging fruit. Type these few commands and you're point clicking your way to a website which is really, really cool. CHARLES: All right everybody, thank you so much for listening. Thank you, Jonathan for coming on by and talking with us today. JONATHAN: Yeah, thank you so much for having me on. This podcast is super awesome. I'm really excited to actually be able to be a part of it. I feel like you are at Ember Weekend that one time and you were in Norway? CHARLES: Finland. JONATHAN: Yeah, Finland and we weren't able to actually have a video open at the same time because of the data problem. It's been actually kind of cool to actually have a real conversation. That's been really great. CHARLES: Yeah, that has been awesome. That was a good conversation and that, your podcast obviously is EmberWeekend.com. Everybody go and check it out. Thanks for listening.

new york performance data san diego created reddit seo west coast norway finland dom ikea beta jacksonville phantom react slack wordpress boots redux discourse hmmm javascript html backbone squarespace forums cdn vue glimmer angular mousetrap vim jquery react native ssr adventure zone shoebox typeform crawler erb lts emacs jonathan jackson urgh mike north jsx preact frontside shoeboxes react redux emberconf jonathan yeah charles lowell robert it robert you jonathan that fastboot isomorphic javascript charles you ember fastboot hashrocket

Refactoring Code and Team with Ryan Stelly

Play Episode Listen Later Mar 2, 2017 52:14

How do you evolve your team when it triples in size? Carl and Richard talk to Ryan Stelly about his experiences working at Rally Health when an acquisition grew the development team from eight people to 30. The conversation begins with a look at where they came from, building ASP.NET MVC apps. The new team used Scala and Angular together - how do you move forward? Cross team training, exploring new technologies and a lot of fun leads to React/Redux, a new DevOps stack and a culture that you'd want to be a part of!Support this podcast at — https://redcircle.com/net-rocks/donations

cross microsoft code studio visual vista devops scala orcas angular asp vb refactoring react redux rally health

Refactoring Code and Team with Ryan Stelly

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

Play Episode Listen Later Mar 2, 2017 52:13

How do you evolve your team when it triples in size? Carl and Richard talk to Ryan Stelly about his experiences working at Rally Health when an acquisition grew the development team from eight people to 30. The conversation begins with a look at where they came from, building ASP.NET MVC apps. The new team used Scala and Angular together - how do you move forward? Cross team training, exploring new technologies and a lot of fun leads to React/Redux, a new DevOps stack and a culture that you'd want to be a part of!Support this podcast at — https://redcircle.com/net-rocks/donations

cross code devops scala angular asp refactoring react redux rally health

055: Redux and Ember with Toran Billups

The Frontside Podcast

Play Episode Listen Later Jan 26, 2017 56:03

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

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

48 выпуск 04 сезона. Ruby 2.4.0-rc1, Rake without Rails, ReadSource, Angular 4.0, React-Redux 5.0.0, Vuetify, Voca и прочее

Play Episode Listen Later Dec 18, 2016 34:40

Добрый день уважаемые слушатели. Представляем новый выпуск подкаста RWpod. В этом выпуске: Ruby Ruby 2.4.0-rc1 Released и Ruby 2.4 adds Comparable#clamp method Real-time Audio Processing with Ruby и Rake without Rails Design Patterns in Ruby, Practical Natural Language Processing done in Ruby и ReadSource - open any Ruby method right into your VIM editor JavaScript Ok… let me explain: it's going to be Angular 4.0, or just Angular, React-Redux 5.0.0 released и Ember 2.10 and Glimmer 2 performance improvements Browser Resource Hinting with Prefetch, Preconnect, and Prerender, Prefer DEFER Over ASYNC и Who said javascript was easy ? Vuetify - a component framework for Vue.js 2, Voca - the ultimate JavaScript string library, Learning Progressive Web App и Zooming - image zoom that makes sense

real javascript rails rake vue glimmer angular voca vim comparable ruby ruby react redux vuetify

JavaScriptServices with Steve Sanderson

Play Episode Listen Later Nov 15, 2016 55:32

How do you get to coding quickly with the new web development frameworks? Carl and Richard talk to Steve Sanderson about JavaScriptServices, which is actually a set of templates for helping you set up your development environment for Angular, Knockout, React and/or React-Redux. Steve talks about all the bits and pieces necessary to actually get to your code-run-debug cycle of development. Along the way he mentions a number of tools involved to make life easier, including Yeoman and WebPack. The conversation also turns to this diversity of client development stacks and the philosophy behind them - more great thinking by a web leader!Support this podcast at — https://redcircle.com/net-rocks/donations

microsoft studio visual react vista knockout orcas angular asp vb yeoman webpack react redux steve sanderson

JavaScriptServices with Steve Sanderson