Stay current on the latest innovations and technologies in the React community by listening to our panel of React and Web Development Experts.
Similar Podcasts
Flutter 101 Podcast
Weekly podcast focusing on software development with Flutter and Dart. Hosted by Vince Varga.
Views on Vue
Vue is a growing front-end framework for web developments. Hear experts cover technologies and movements within the Vue community by talking to members of the open source and development community.
The QA Lead Podcast
Discover with us how to lead QA teams and do web and software QA better. We’re a QA community exploring the latest and best quality assurance approaches to help you with DevOps, Agile, Automation, Performance, API, Mobile, Analytics, RPA, AIOps, Shift-Left and right. Find the tips, tricks, how-to guides, and tools you need to build your QA team, and banish the bugs! Hosted by CTO of Digital Assured, President of Vivit-Worldwide, and Tedx Speaker Jonathon Wright.
RRU 092: The Future of APIs, GraphQL, and Developer Tooling with Sean Grove
Today the panel and Sean Grove are talking about the future of programming with GraphQL. GraphQL is a new way of building APIs that is more product and frontend focused. All of the panelists agree that it is easy to get exactly what they need with ease when using GraphQL. There are also benefits for backend developers too, since GraphQL lets you see exactly what fields your clients are using. You can also reach out to specific clients who have accessed specific fields before. This is possible because every GraphQL server is introspectable by a computer, and Sean explains how it works. This introspectivity is the basis for an idea he has that allows users to generate realistic fake data before signing up so they know exactly how their application will work before committing, and gives some examples of how it can be used. They all agree that GraphQL is very well formatted and that it provides solutions to real world problems, The conversation turns to the article How OneGraph Onboards Users Who are New to GraphQL. In particular, they discuss how the GraphiQL Explorer works versus OneGraph. GraphiQL Explorer is an extension that will look at your operations and generate a full React or Bash app from them. Sean talks about the different kinds of operations and how naming them can help you track their performance more easily. There is even a code generator that will flag unnamed queries to help you learn best practices, but won’t stop you from running your code. They talk about the benefits of using OneGraph, a single graphQL endpoint through which you can get all your data from other apps. By wrapping all the APIs in GraphQL, you get access to all the nice GraphQL tooling. They talk about how it works and some of the benefits it can have, such as helping you stay under rate limits. They talk about other interesting tools available for GraphQL and what the explosion of tools means for the GraphQL community. They talk more about how GraphQL fits into the React environment and what they think the future holds. Panelists Thomas Aylott Charles Max Wood Guest Sean Grove Sponsors NxPlaybook.com - Use code ‘NXDEVCHAT’ for 50% off the official https://nx.dev/React Advanced Workspaces course! Sentry | Use the code “devchat” for $100 credit Links GraphQL JS CodeShift Comby How OneGraph Onboards Users That Are New To GraphQL GrapiQL Excel GraphiQL Explorer Bash OneGraph Hasura Framer Swift.ui Picks Thomas Aylott Framer Famous Charles Max Wood Stop-motion animation Christmas movies (like Rudolph the Red-Nosed Reindeer) A Christmas Story Sean Grove Moon Highway Draftbit SuperMario Land 2 Exploration Special Guest: Sean Grove.
RRU 091: React Best Practices
In this week’s episode of React Round Up the panel works their way through a blog post outlining best practices for React. The first is “keeping components small and function-specific”. The panel discusses the pros of using this best practice and how it relates to the single responsibility principle. This best practice also helps with the next, “reusability is important”. The panel considers this second best practice and points out some of its flaws. It recommends avoiding the creation of new components. The panel explains that by avoiding creating new components it saves time but can also cause problems as you adapt components to fit more projects. The next best practice is “consolidate duplicate code”, the panel shares their philosophies on dry code and when to consolidate. The fourth best practice is comment only when necessary, Charles explains how he uses comments to help him keep track of things inside his code and the panel warns against using too many comments as it may clog up your code making it hard to read. The fifth best practice is, “name the component after the function”. The panel explains how it is an art finding a name that is not too generic but is not overly specific; mastering the art of naming is something that will benefit everyone. Naming relates to the sixth best practice as well. “Use capitals when naming components”. The panel explains the need for convention and advises developers not to go off-book as this will slow down others. The last six best practices are all self-explanatory says the panel. “Separate stateful aspects from rendering” is nothing new. “Code should execute as expected and be testable”, the panel explains how this allows for trust between developers. “All files relating to a single component should be in the same folder”, this makes everything easy to find when necessary. “Use tools like Bit”, while the panel doesn’t use Bit, they share tool recommendations. They also comment on the progress being made it tooling and the future of automated tools. “Use snippet libraries”, the panel discusses favorite libraries and building their own libraries. The final best practice is “Follow linting rules”. Panelists Charles Wood Christopher Reyes Thomas Aylott Sponsors NxPlaybook.com - Use code ‘NXDEVCHAT’ for 50% off the official https://nx.dev/React Advanced Workspaces course! Sentry– use the code “devchat” for two months free on Sentry’s small plan CacheFly Links https://teachablemachine.withgoogle.com/ Practical React Hooks: How to refactor your app to use Hooks 12 React Best Practices You Need to Follow in 2020 https://github.com/nadeesha/saul https://www.facebook.com/React-Round-Up https://twitter.com/reactroundup Picks Charles Wood: White Christmas Holiday Inn The MaxCoders Guide To Finding Your Dream Developer Job Christopher Reyes: https://github.com/microsoft/vscode-eslint https://www.playingwithfire.co/ Thomas Aylott: test && commit || revert
RRU 090: How Do I Introduce New Tech at Work?
Today the panel is discussing how to introduce new tech at work. They agree that it’s important to get input from all teams on the decision, although it will primarily affect the development team. One should also consider the different ways people make decisions, such as through discussion or quiet thinking, and give everyone time to come to a decision. The panel talks about positive and negative examples of how to introduce new tech at work. Thomas believes that it is important to acknowledge your own biases in decision making and to try to avoid them. The React experts discuss the significance of the team dynamic and the necessity of different roles in decision making or if it is better to have an organic discovery phase. This relates to Thomas’ point about personal biases, and he believes that it is important to put people in roles that are opposite of their personality. When making decisions about new technology, it is also important to note that not all decisions require the same amount of input, and they discuss how to measure how much input is required for a decision. The discussion turns to methods for introducing testing, and the panelists talk about their experiences. The rule of thumb for introducing testing is to start simple, have an expected behavior, and test the output to see if it matches. Some other aspects of this discussion to consider are that introducing React Hooks could be considered introducing tech, testing is just a new process, introducing new tools, and budget concerns. Charles shares experience convincing his boss to introduce Agile practices which shows the importance of getting management to see the benefits of the new tech or strategy for themselves. The show concludes with the panel acknowledging that other than introducing tech, introducing philosophies on how to organize your code follows the same patterns as introducing technology. Panelists Thomas Aylott Charles Max Wood Chris Reyes Sponsors NxPlaybook.com - Use code ‘NXDEVCHAT’ for 50% off the official https://nx.dev/React Advanced Workspaces course! Sentry | Use the code “devchat” for $100 credit Links Vue 12 React Best Practices You Need to Follow in 2019 Saul Test && commit || revert VS Code ESLint Picks Thomas Aylott Teachable Machine Charles Max Wood White Christmas Holiday Inn Chris Reyes Practical React Hooks
RRU 089: Progressive Enhancements with Ire Aderinokun
In this episode of React Round Up Charles Max Wood interviews Ire Aderinokun at JAMstack conf 2019. Ire works for Buycoins, a cryptocurrency exchange for Africa. She gave a lightning talk, “Headless Chrome & Cloudinary for progressively enhanced dynamic content on the web”. After giving a brief overview of her talk to Charles, Ire defines progressive enhancement for the listeners. Walking through how progressive enhancement works, she explains how Headless Chrome and Cloudinary helped her with the project she shared in the talk. Ire and Charles consider the blindspot that developers experience because they work on high-end devices and how using progressive enhancement helps those who use lower-end devices. Ire shares her experience with JAMstack and explains how progressive enhancement works with JAMstack. Charles shares his experience using JAMstack. The episode ends with Ire giving advice and resources to help get started with progressive enhancement. Panelists Charles Wood Guest: Ire Aderinokun Sponsors Nrwl | Nx.Dev/React Sentry– use the code “devchat” for two months free on Sentry’s small plan CacheFly Links https://buycoins.africa/ Headless Chrome & Cloudinary for progressively enhanced dynamic content https://github.com/ireade/caniuse-embed https://ireaderinokun.com/ https://twitter.com/ireaderinokun https://github.com/ireade https://www.facebook.com/React-Round-Up https://twitter.com/reactroundup Special Guest: Ire Aderinokun.
The MaxCoders Guide To Finding Your Dream Developer Job
"The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is available on Amazon. Get your copy here today only for $2.99!
RRU 088: Frustrations with React Hooks with Paul Cowan
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 Special Guest: Paul Cowan.
RRU 087: The why-did-you-render Library and React Performance with Vitali Zaidman
Vitali Zaidman works for the WellDone Software consultancy. He has worked with a lot of different technologies, but currently works with React. In a recent React meetup, he talked about React performance. When someone says that React is not performant, Vitali disagrees and says that it is very performant unless you do certain things. If your React application is slow, it’s down to the tools you use. The panelists all agree that premature optimization is the root of all evil. The difference between premature optimization and good architecture comes down to experience. It is important to be data driven and consider performance a business environment. Vitali believes that performance is a feature and should be treated like any other. The panel discusses accessibility versus internationalization. Launching to one language is different than launching to one set of abilities. While you don’t need to internationalize on day one, don’t make it impossible to internationalize. They talk about how creating a timeline of changes in your project can help you pinpoint where your performance issues came from. It is also important to remember that developers have strong computers, while users generally do not. As you build, check your product on slower devices to make sure that it works for your users. Vitali talks about his tool why-did-you-render, which will notify you of avoidable re-renders. He also talks about considering why you are choosing to use React and whether or not is the correct choice for your project. The panel discusses their feelings on pure components. They talk about the importance of code review and manual QA since not everything can be automated, again suggesting having a slow computer or phone in the office to test as you go. They also agree that it is important to understand how your library works. They talk about the huge amount of work that is required to maintain an open source project, and how development is a team effort if you want to create sustainable software. The show concludes with Vitali talking about a performance issue he encountered and how he recognized it, diagnosed the problem, and fixed it. Panelists Thomas Aylott Lucas Reis With special guest: Vitali Zaidman Sponsors Nrwl | Nx.Dev/React Sentry use the code “devchat” for 2 months free on Sentry’s small plan Ruby Rogues Links Knockout Why did you render Fusion.js: A Plugin-based Universal Web Framework - Leo Horie React Element's 'Parent' vs Rendered By How To Reduce Unnecessary Re-Renders Why Performance Matters Performance Impact Calculator Welldone Software Follow DevChatTV on Facebook and Twitter Picks Thomas Aylott: Face-API.js React force graph React 3 Fiber Lucas Reis: Opendoodles.com Adopting Optimizely at Compass Vitali Zaidman: JSJ 402: SEO for Developers with Vitali Zaidman Special Guest: Vitali Zaidman.
RRU 086: Gatsby Themes with Chris Biscardi
In this episode of React Round Up the panel interviews Chris Biscardi. Chris is now working with Gatsby. He shares a bit about his background and how he got into programming. Chris explains his move from Kubernetes and Docker over to Gatsby. His overall drive is to increase leverage for other people and what drew him to these projects. Chirs explains what Gatsby is and what it has to offer to React developers. Gatsby is like a creat react app which is attached to a static site generator that has an API that allows you to pull in data from anywhere. Also, by using Gatsby developers do not have to operate alone, they get the whole Gatsby ecosystem to help them. The panel considers Gatsby and if it would be a good way for developers to learn React. Chris explains with Gatsby’s documentation it would be great for learning React. The panel believes it would be a good place to learn because of the hands-on goal-oriented work engaged in when using Gatsby. Chris shares what developers get when using Gatsby and why it appeals to programmers today. Chris explains what Gatsby themes are and how they are more powerful than CSS themes. The panel discusses how to use themes and how to write them. ThemeUI library is shared and Chris explains how it works. They consider what is next for both Gatsby and React. Panelists Lucas Reis Charles Wood Thomas Aylott Guest: Chris Biscardi Sponsors Nrwl | Nx.Dev/React Sentry– use the code “devchat” for two months free on Sentry’s small plan Adventures in Angular CacheFly Links JSJ 386: Gatsby.js with Chris Biscardi https://www.gatsbyjs.org/ https://www.christopherbiscardi.com/ Views on Vue https://vuejs.org/ https://www.facebook.com/React-Round-Up https://twitter.com/reactroundup Picks Lucas Reis: Don’t procrastinate Charles Wood: Find solid people in your life Get away Chris Biscardi: Chris's Discord Thomas Aylott: Real relationships with real people outside of work.
RRU 085: Building Resilient Architecture with Monica Lent
Monica Lent has been interested in software from a very young age, and made her first domain name when she was 9 years old. She studied legacy languages Latin and Ancient Greek in university, but ended up keeping her college development job and going into software. She recently left her job and founded a startup, analytic tool designed for bloggers designed around affiliate marketing. She talks about some of the lessons she’s learned, including how to sift through data and how to make it useful for people. Monica gave a talk at React Finland and she first applies some of her principles from that talk to what she’s learned founding a startup. One of the main differences she’s found is a small startup has different needs and levels of stability than a business. In early stage business, you have to decide where you want to invest in quality and where you shouldn’t be investing. For example, her primary focus is on her algorithm that runs the tool, and UI is less of a priority. In a large company, this might be structured differently. The panel discusses how to distill the priorities from the project manager so you know where to spend your time, something that takes a lot of experience and failure. They agree that if something is business critical and will cause the business to lose money if it fails, those things should be a top priority. Second, the panel discusses the merits of different practices such as whether or not to deploy on Friday and having engineers on call. In Monica’s React Finland talk, she talks about the importance of constraints, which can help with these kinds of decisions. She explains that instead of thinking of architecture as something super abstract, think of it as enabling constraints, as picking ways to do less and end up with code that is safer to run, longer lasting, and has fewer bugs. Thomas shares how he used to oppose constraints and architecture, and how he changed his mind. They discuss the importance of automation over documentation for building sustainable code. Third, Monica explains her opinion on how copying and pasting code instead of adding dependencies is a positive constraint. She prefers this method most of the time but not in all cases because it keeps your code flexible and avoids unnecessary specialization. However she is not advocating for copy/paste over dependencies in every situation : rather the point comes down to using copy/paste instead of inappropriate coupling. Sometimes, when you create an abstraction and combine two pieces of code, this new combination makes code more brittle than it would be otherwise Components put in the shared folder almost never leave. This causes the component to become very specialized and not work in all scenarios. The panel discusses where this method may not work. Thomas talks about some of his favorite tools for simplifying complexity, React Hooks and Relay. Monica and the panelists discuss the merits of using TypeScript and proper methods for coupling code. Fourth, the panel discusses how so much of programming is dealing with other people and the importance of keeping your ego out of it when designing constraints, especially since developers hate other developer’s abstractions. They debate whether pride is a characteristic of junior or senior developers. They note that it is easier to get prideful and opinionated when you’re not working on a team. Thomas believes that if you aren’t working on a big team, you should force yourself to talk to people with opposing positions. The show concludes with the panelists agreeing that it all comes down to the balance between priorities and making things work. Sometimes we can get so focused on making something work that we lose sight of what actually matters. They agree that collaboration generally yields better results than leaving it to one person. Monica talks about the importance of senior developers nurturing their team by leading from behind to help people come up with their own solutions. The panelists talk about different methods they’ve seen for doing this. Panelists Leslie Cohn-Wein Thomas Aylott Lucas Reis With special guest: Monica Lent Sponsors Progress KendoReact | Try now for FREE: kendoreact.com/reactroundup Sentry use the code “devchat” for 2 months free on Sentry’s small plan Views on Vue Links Monica's React Finland talk Narcissistic design talk A Philosophy of Software Design React Hooks Relay TypeScript Webpack gRPC Prettier 7 Absolute Truths I Unlearned as a Junior Developer Follow DevChatTV on Facebook and Twitter Picks Leslie Cohn-Wein: Xochimilco, Mexico City, Mexico List of CSS mistakes Thomas Aylott: Get the Truth book Lucas Reis: Lovevery Zero Fasting app Monica Lent: The Mom Test by Rob Fitzpatrick Special Guest: Monica Lent.
RRU 084: What Makes a 10x Engineer?
In today’s show, Chuck talks about the recent Twitter thread about 10x engineers. He goes through each of the points in the tweet and talks about each of them in turn. There are only two points he sort of agrees with, and believes the rest to be absolute garbage. One of the issues with this tweet is that it doesn’t define what a 10x engineer is. Defining a 10x engineer is difficult because it is also impossible to measure a truly average engineer because there are many factors that play into measuring productivity. Chuck turns the discussion to what a 10x engineer is to him and how to find one. A 10x engineer is dependent on the organization that they are a part of, because they are not simply found, they are made. When a 10x engineer is added to a team, the productivity of the entire team increases. Employers have to consider firstly what you need in your team and how a person would fit in. You want to avoid changing the entire culture of your organization. Consider also that a 10x engineer may be hired as a 2x engineer, but it is the employer that turns them into a 10x engineer. Overall, Chuck believes these tweets are asinine because it’s impossible to measure what makes a 10x engineer in the first place, and hiring a person that fits the attributes in the list would be toxic to your company. Panelists Charles Max Wood Sponsors Progress KendoReact | Try now for FREE: kendoreact.com/reactroundup Sentry use the code “devchat” for 2 months free on Sentry’s small plan iPhreaks Links 10x engineer Twitter thread Follow DevChat on Facebook and Twitter Picks Charles Max Wood: Copyhackers.com Good to Great by Jim Collins Keto diet Podcast Movement
RRU 083: Reactive Programming with Storybook with Dean Radcliffe
Dean Radcliffe has been web developing since the table tag was the new hotness. His interests include his wife and two kids, music, sports, and he likes to say he helps people make whatever they can dream of. Since starting to move towards the frontend, React has been his weapon of choice, which he got started with in 2014. Dean works at G2.com, a software review site. They are developing a review form, which requires the code to react to events. For example, a person’s position in the company would affect what questions they see, so the form needs to react to which box is checked. Dean talks about the use cases for building a reactive form and what kind of things are going to happen when you fill in an input. For his form, the input will be remembered, and they want to increase the user’s involvement with the form through incentives. To accomplish this, Dean uses component driven development with Storybook. Storybook is a tool available for React and other frameworks, which lets you jump directly to each state you want to view instead of having to go through them all one by one. Basically, it gives you shortcuts directly to the visual states of your components. These states facilitate development and the feedback cycle going back to the designers, allowing them to see more than just the finished application and enabling them to circumvent mistakes. Storybook relates to reactive programming because component driven development lets you discover the API and what sets of props are necessary to put this component into each possible state that can be displayed. Dean does not use it as a test environment on his team, but it does help them write unit tests. It has an addon that lets you write unit tests in Storybook, but he hasn’t used it. Dean compares where reactivity and Storybook come together by comparing it to a thermometer.A thermometer will get readings over time of discrete values, and that timing is how people experience your components. You can create an observable of those states, and Storybook Animate ties them together. Your components, however, are still your responsibility. Dean talks about how he creates the observables. The observables are hardcoded, but the great thing is you don’t need to know where it came from. Dean describes how the observables are connected to the components. Dean feels that having this dynamic feed cycle makes it kind of fun to write tests. There is also a function called After which creates a set time out, which creates an observable of that value over time. Dean talks about his other tool, RX Helper. RX Helper provides an ‘after’ abstraction, and an event oriented layer in React. RX helper allows you to listen for custom events raised from the individual components of a form, and you respond to those events with observables, and the observables produce values over time.The goal of RX Helper provides some transparency and makes it easier to try out concurrency designs. The show concludes with Dean talking about some of the changes he’s made to his tools and how he came up with the idea. Panelists Charles Max Wood With special guest: Dean Radcliffe 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 Knockout.js G2.com Storybook StorybookAnimate RX Helper Meteor JS Follow DevChatTV on Facebook and Twitter Picks Dean Radcliffe: Follow him on Github and Twitter Kent C. Dodds @davidkpiano XState Gangstagrass Charles Max Wood: St. George Marathon The 360 Degree Leader Special Guest: Dean Radcliffe.
RRU 082: Progressive SSR with Dinesh Pandiyan
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 Special Guest: Dinesh Pandiyan.
RRU 081: NX and Monorepos with Jeffrey Cross and Victor Savkin
Jeffrey Cross and Victor Savkin are the cofounders of NRWL. They used to work together at Google on the Angular team and started NRWL so that people could use Angular 2 well. Victor talks about NRWL’s tool NX, which came from the desire to help people develop like the tech giants. Companies like Google and Facebook develop in the same repository so that people can collaborate. NX is an open source tool for this collaborative development, known as a monorepo. Monorepo style development is a way to develop applications such that you develop multiple projects in the same repository and you use tooling to orchestrate development. The tooling connects everything, makes the experience coherent, and ultimately makes the monorepo style work. The benefits of monorepo development are that the tool chain enables you to interact with different projects in the same fashion, collaboration is more effective, and multiple apps can be refactored at once. The panel discusses what situations are appropriate for a monorepo and which are not. Victor believes that any company with more than one large product would benefit from a monorepo, but it would not benefit a company that wants to keep their teams distinct from one another. The hosts express some concerns about implementation, such as scaling and creating the infrastructure. Victor assures them that a monorepo is inherently scalable, and most tools will work for years and years. As for the infrastructure, companies like NRWL specialize in helping companies set up monorepos, and NX provides many of the necessary tools for a monorepo. A monorepo can be tailor-made to fit any size of company, and can even be created for already established projects. If you wanted to start your own monorepo, you can start by taking a project or handful of projects and moving them to the same place. As you develop, pull pieces of your applications out and put them into packages. Victor cautions that monorepos tend towards a single version policy, so you’ll want to get on the same version as your third party dependencies before you move your next application in. You can move things in and temporarily have different versions, but plan to make them the same version eventually. Victor talks about how the CI in a monorepo setup looks different, because you run tests against everything that might be broken by that change, not just the project its in. So, when you change something in your code, you need to consider what other pieces of code need to be taken into account. A monorepo does make dependencies more explicit, and when you have good tooling it’s easier to see the effect the changes you make have. This is where NX excels. One of the big advantages of NX is that it allows you to partition your application into packages with a well defined API, and prevents the project from becoming one giant node. You can then interact with those packages, and see what happens when you change something. You have a lot more clarity of how your app is partitioned and what the restraints are. NX allows you to share stuff between the front and backend. The show concludes with the conversation turning to Jeffrey and Victor’s consulting work. They talk about some of the interesting features that are happening outside of React that we are missing out on. Victor is very impressed with tooling in the Angular community. He talks about a tool called Console for NX. They end by talking about the schematic powered migrations in Angular. Panelists Leslie Cohn-Wein Dave Ceddia Lucas Reis With special guest: Jeffrey Cross and Victor Savkin Sponsors Sustain Our Software Sentry use the code “devchat” for 2 months free on Sentry’s small plan My JavaScript Story Links NRWL Angular NX Building Fullstack React Applications in Monorepo Angular CLI Follow DevChatTV on Facebook and Twitter Picks Lucas Reis: Dear Startup Cryptocurrencies video by 1Blue1Brown Dave Ceddia: Help, I’ve Fallen (into code) and I Can’t Get Up! Code maps frontend Victor Savkin: Ember Mug Heal the Internet Jeffrey Cross: lululemon Commission pant Leslie Cohn-Wein Why I’m No Longer Talking to White People Everylayout.dev Special Guests: Jeff Cross and Victor Savkin.
RRU 080: Navigating React Navigation with Zain Sajjad
Zain Sajjad is a frontend developer at his company Peekaboo Guru, an app built in React. The show begins with Zain explaining why he chose to build Peekaboo Guru in React. Ultimately, he chose React for its composability and reusability. He talks about how much data is shared between his React and React Native applications. Zain explains what he means by a container since he is not talking about Docker, and how he has the app organized. He talks about the differences between routing and navigation between React and React Native. When approaching these differences, he breaks things down into components, containers, and platform, paying careful attention to how they work together. This differentiation can actually help a lot with testing as well. The panel asks Zain about choosing between React navigation and React Native navigation, but Peekaboo Guru uses both React navigation and React Native navigation, but on different platforms. They use each on different platforms because React Native doesn’t let you configure it with existing native apps. He talks about the pros and cons of each, but prefers React Native navigation. They decided to use both because Peekaboo Guru is based in a region where there aren’t many users with high end devices, so this decision was made to accommodate them. They then discuss how to approach making important software decisions with a team and how to make an objective decision away from your bias against old or new technology. Zain believes that you have to step out of your comfort zone and think of the team rather than yourself. They talk about the thought process of making these decisions, especially concerning who is going to do the maintenance. They talk about ways to give good feedback even when the maintenance is not going to be your responsibility and the importance of staying humble. Making decisions like this can be tricky because it is where hard skills and soft skills intersect. The panel moves on to talking about machine learning, and Zain talks about his experience using it to screen comments on Peekaboo Guru. Machine learning is getting more and more common, with giants like Snapchat and Facebook doing it as well. There is also a lot of machine learning on our phones that we don’t think about. Zain gives advice for those who want to start learning about machine learning. He advises people to think of it in two parts, preparing a model and using a model. Thomas feels that machine learning is more approachable than it first appears to be, though it is always related to how good the abstraction is. They compare machine learning to AI and a database to assist with understanding. If you want to play around with AI, Zain counsels that programming has the addiction of success. Keep your tasks small to keep getting those tastes of success. He advises that it is best to start by using the inference part and then make a model. He talks about different tools to help with the math. The show concludes with the panel agreeing to his counsel and reminding listeners that failure is trying to go from 0 to perfect in one step. Panelists Thomas Aylott Lucas Reis With special guest: Zain Sajjad Sponsors Adventures in Blockchain Sentry use the code “devchat” for 2 months free on Sentry’s small plan My Angular Story Links Peekaboo Guru React React Native React Native Navigation React Navigation SQL TensorFlow Fun Fun Function Immer.js Follow DevChatTV on Facebook and Twitter Picks Lucas Reis: Ember.js 3Blue1Brown Thomas Aylott: Rite in the Rain notepad Special Guest: Zain Sajjad.
RRU 079: State Machines and State Charts with Farzad Yousef Zadeh
Episode Summary Today’s guest is Farzad Yousef Zadeh, a developer from Iran with a unique path into computer programming. He started by studying astrophysics and aerospace engineering in college, then dropped out in his last semester because it wasn’t the right path. He then taught himself to code, working mostly in web programming and frontend development. Despite his change in course, Farzad remains passionate about observing the night sky. Farzad is here today to talk about the ideas in his talk Explicitness and Consistency in UI, where he talks about the difficulties of developing a user interface and how the experience can be improved by using state machines and state charts. He talks about his inspiration for the talk and how he has implemented state machines and state charts into his work. The panel backtracks and talks about the definition of state machines and state charts. A state machine, from an academic background, is a model for computing something. It's for managing and controlling, taking over branching and managing a finite amount of state declaratively. State machines are not so much about sharing or reusing, but about how your communicate a certain behavior. Despite the fact that event driven programming permeates the programming consciousness, thinking about state charts and state machines is actually more natural than it first appears. The panel explains how it’s the same principle as whiteboarding to solve a problem. Lucas asks how state charts are different from pure React. Farzad talks about how it’s important not to just treat your static states as first class, but also the transitions between them. Otherwise, you would end up with something that looks like a map with cities and towns, but no roads. Using statecharts and state machines makes testing an application much easier, and in some ways you let the machine test itself. The machine will know what to do with your states because you define the path, and the machine will take the path for you. They again talk about the difference between state machines and state charts. A state machine defines a finite set of states and defining the events that the machine can take and respond to when transitioning from state A to B. If you use only this, you will encounter a snag called ‘state explosion’ because not non-concrete things cannot be modeled. So, state charts were invented to compensate for this. A state chart brings the idea of an extended state, or the context and data you need to hold and reason from. Farzad talks about other types of machines and supports that exist for branching, entry actions, and exit actions. This is similar to the use effect hook in React. He gives examples of where you would use this logic and how it would be worked into frameworks. Farzad talks about how your machine is just a definition, a declarative model of how something is supposed to behave, and how having that separation between the definition of the logic and behavior vs the implementation of API has given us so much more freedom and portability The panel talks about how using state machines and charts is an investment in the long term maintainability of your code. They agree that using state machines and charts makes it easier to communicate with other developers, new team members, and even non developers. They talk about Cerebral.js and its contributions and model. As with everything in programming, state machines are not a silver bullet and don’t work in every situation. Farzad talks about situations where state machines can be unhelpful. It is still valuable to consider state machines and charts because it forces you to dedicate time thinking and organizing your thoughts so that you can build something maintainable that won’t just be thrown away. The panel discusses how thinking things out before starting to code can be beneficial. They finish by talking about how React Hooks has started them on the path to implement state machines and charts into their code. Panelists David Ceddia Lucas Reis Leslie Cohn-Wein Thomas Aylott With special guest: Farzad Yousef Zadeh Sponsors Sustain Our Software Sentry use the code “devchat” for 2 months free on Sentry’s small plan My Angular Story Links Explicitness and Consistency in UI David Khourshid xstate library RRU 069: The State Machines in React with David Khourshid State machine State chart Cerebral JS Origami by Facebook Elm The GaryVee Content Model Overmind JS Follow DevChatTV on Facebook and Twitter Picks David Ceddia: Reverse Interview Thomas Aylott: Machine Learning Zero to Hero TensorFlow at Google I/O 2019 channel Lucas Reis: How to Learn D3.js Leslie Cohn-Wein: Write Fewer Tests! From Automation to Autogeneration by David Khourshid Farzad Yousef Zadeh: Don’t Let Architecture Astronauts Scare You Special Guest: Farzad Yousef Zadeh.