Graham Conzett's guest appearances

Graham Conzett

Ruby Rogues

Devchat.tv Episode Roundup

Devon Estes

Sarah Mei

Michael Orr

Elia Schito

Michele Titolo

Thom Parkin

Sean Griffin

Adam Keys

Joseph Wilk

Julian Fahrer

Alessandro Desantis

Tinco Andringa

Hongli Lai

Kenneth Kalmer

Dan Luu

OwlTail

Graham Conzett has been a developer for 12 years. He has worked with Ruby and Rails for half of that, and currently works for a company that does large format touchscreens. Graham gave a talk at RailsConf 2018 called “Old School JavaScript and Rails” where he talks about the experience of JavaScript fatigue. The world of JavaScript changes very quickly, and sometimes it feels like there’s a new framework every week. Because there is no clear winner among these frameworks, many Rails developers feel compelled to reach for something like React. However, there are many strategies for doing JavaScript in Ruby and in Rails that existed before these frameworks, so you can accomplish what you want to get done without bringing one in. Remember that all of them can coexist side by side, so you don’t have to pick one strategy. The panel discusses the effect that adopting a new technology can have on the team, such as the learning curve and hiring people that specialize in it. To illustrate this, Graham talks about the company he works for. Their app is a 90% is a Rails app, and one component has a lot of React. He talks about how they came up with that strategy and how they have kept React isolated to that page. It’s crept into some other little places, but there is a document in the team charter that defines where and why they use certain things, and that has kept it limited.Graham talks about the tradeoffs between choosing to stay in Rails or introduce React. If you bring in React, you have to bring in a different testing framework. React also has a bigger learning curve than standard HTML or CSS. There are far less conventions around React than Rails, so you have to spend time coming to a consensus as a team. Webpacker helps with this to a degree, but it also pulls in a bunch of third party plugins, so Rails is no longer writing the rules and you may have to debug random plugins.If you want to avoid adding a framework like React, consider using ujs, or Unobtrusive JavaScript. These are JavaScript ‘helpers’ included in the Rails bundle that you can add to various buttons that help you decorate and enhance. You don’t have to change much of your HTML frontend code but it makes it more interactive. Graham talks about he uses them and why he likes them. The panel compares using ujs to other strategies like using Stimulus or ‘sprinkles’ of JavaScript. For small JS sprinkles, Graham advises to keep that focused on a single HTML element and bound to a single event handler. Ujs works best when you piggyback off of that Rails/Rest related stuff, and Stimulus is more about manipulating parts on the page that don’t have a need for asynchronous request. You can really use ujs everywhere, so the three techniques are not mutually exclusive.Graham gives advice to developers considering pulling in a frontend framework. He says to start with minimal JS and then talk to your team about when it feels right to do it, because that’s a tricky conversation to know what your expectations are and problems you’re trying to solve. Sometimes things will force the issue and make you want to explore using frontend frameworks. When it’s a time saver, it makes your team scale better, or when you have something you just can’t do without it, then that might be the right time to use React.The show concludes with the panel discussing their experiences with different compiling languages like TypeScript. They talk about what influences the tools people choose. They agree that the most important thing is getting working code out there, it doesn’t really matter how it’s written, but to only pull things in when you know you need it.Panelists Charles Max Wood Andrew Mason David Kimura Nate Hopkins With special guest: Graham ConzettSponsors  Sentry use the code “devchat” for 2 months free on Sentry’s small plan   Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE &amp; get $66 free credits with promo code RubyRogues  Adventures in Angular Links Old School JavaScript and Rails at RailsConf 2018 React React Native React Native Web Jest Capybara Webpacker Rails-ujs Turbolinks Stimulus Stimulus Reflex Babel TypeScript Actionview components Angular  Follow DevChatTV on Facebook and Twitter PicksCharles Max Wood: St. George Marathon OBS David Kimura: WeDo 2.0 by Lego Workflow Automation Self Hosted Andrew Mason: Publish to Github action JustDunning.com Nate Hopkins: Company of One by Paul Jarvis IndieHackers Graham Conzett: Basecamp’s Shape Up  Pigeonforteachers.com   IKE Smart City  Follow Graham @gconzett on Twitter and GithubSpecial Guest: Graham Conzett.

Graham Conzett has been a developer for 12 years. He has worked with Ruby and Rails for half of that, and currently works for a company that does large format touchscreens. Graham gave a talk at RailsConf 2018 called “Old School JavaScript and Rails” where he talks about the experience of JavaScript fatigue. The world of JavaScript changes very quickly, and sometimes it feels like there’s a new framework every week. Because there is no clear winner among these frameworks, many Rails developers feel compelled to reach for something like React. However, there are many strategies for doing JavaScript in Ruby and in Rails that existed before these frameworks, so you can accomplish what you want to get done without bringing one in. Remember that all of them can coexist side by side, so you don’t have to pick one strategy. The panel discusses the effect that adopting a new technology can have on the team, such as the learning curve and hiring people that specialize in it. To illustrate this, Graham talks about the company he works for. Their app is a 90% is a Rails app, and one component has a lot of React. He talks about how they came up with that strategy and how they have kept React isolated to that page. It’s crept into some other little places, but there is a document in the team charter that defines where and why they use certain things, and that has kept it limited.Graham talks about the tradeoffs between choosing to stay in Rails or introduce React. If you bring in React, you have to bring in a different testing framework. React also has a bigger learning curve than standard HTML or CSS. There are far less conventions around React than Rails, so you have to spend time coming to a consensus as a team. Webpacker helps with this to a degree, but it also pulls in a bunch of third party plugins, so Rails is no longer writing the rules and you may have to debug random plugins.If you want to avoid adding a framework like React, consider using ujs, or Unobtrusive JavaScript. These are JavaScript ‘helpers’ included in the Rails bundle that you can add to various buttons that help you decorate and enhance. You don’t have to change much of your HTML frontend code but it makes it more interactive. Graham talks about he uses them and why he likes them. The panel compares using ujs to other strategies like using Stimulus or ‘sprinkles’ of JavaScript. For small JS sprinkles, Graham advises to keep that focused on a single HTML element and bound to a single event handler. Ujs works best when you piggyback off of that Rails/Rest related stuff, and Stimulus is more about manipulating parts on the page that don’t have a need for asynchronous request. You can really use ujs everywhere, so the three techniques are not mutually exclusive.Graham gives advice to developers considering pulling in a frontend framework. He says to start with minimal JS and then talk to your team about when it feels right to do it, because that’s a tricky conversation to know what your expectations are and problems you’re trying to solve. Sometimes things will force the issue and make you want to explore using frontend frameworks. When it’s a time saver, it makes your team scale better, or when you have something you just can’t do without it, then that might be the right time to use React.The show concludes with the panel discussing their experiences with different compiling languages like TypeScript. They talk about what influences the tools people choose. They agree that the most important thing is getting working code out there, it doesn’t really matter how it’s written, but to only pull things in when you know you need it.Panelists<ul> <li>Charles Max Wood</li> <li>Andrew Mason</li> <li>David Kimura</li> <li>Nate Hopkins</li> </ul>With special guest: Graham ConzettSponsors<ul> <li> <a href="http://sentry.io/" rel="nofollow" target="_blank">Sentry</a> use the code “devchat” for 2 months free on Sentry’s small plan </li> <li> <a href="https://cloud66.com/rails?utm_source=-&amp;utm_medium=-&amp;utm_campaign=ruby-rogues" rel="nofollow" target="_blank">Cloud 66 - Pain Free Rails Deployments</a> Try Cloud 66 Rails for FREE &amp; get $66 free credits with promo code RubyRogues </li> <li><a href="https://devchat.tv/adv-in-angular/" rel="nofollow" target="_blank">Adventures in Angular</a></li> </ul>Links<ul> <li><a href="https://www.youtube.com/watch?v=lh5qfV2iP80" rel="nofollow" target="_blank">Old School JavaScript and Rails at RailsConf 2018</a></li> <li><a href="https://reactjs.org/" rel="nofollow" target="_blank">React</a></li> <li><a href="http://www.reactnative.com/" rel="nofollow" target="_blank">React Native</a></li> <li><a href="https://github.com/necolas/react-native-web" rel="nofollow" target="_blank">React Native Web</a></li> <li><a href="https://jestjs.io/" rel="nofollow" target="_blank">Jest</a></li> <li><a href="https://github.com/teamcapybara/capybara" rel="nofollow" target="_blank">Capybara</a></li> <li><a href="https://github.com/rails/webpacker" rel="nofollow" target="_blank">Webpacker</a></li> <li><a href="https://github.com/rails/rails-ujs" rel="nofollow" target="_blank">Rails-ujs</a></li> <li><a href="https://github.com/turbolinks/turbolinks" rel="nofollow" target="_blank">Turbolinks</a></li> <li><a href="https://stimulusjs.org/" rel="nofollow" target="_blank">Stimulus</a></li> <li><a href="https://github.com/hopsoft/stimulus_reflex" rel="nofollow" target="_blank">Stimulus Reflex</a></li> <li><a href="https://babeljs.io/" rel="nofollow" target="_blank">Babel</a></li> <li><a href="https://www.typescriptlang.org/" rel="nofollow" target="_blank">TypeScript</a></li> <li><a href="https://github.com/github/actionview-component" rel="nofollow" target="_blank">Actionview components</a></li> <li><a href="https://angular.io/" rel="nofollow" target="_blank">Angular</a></li> </ul> Follow DevChatTV on <a href="https://www.facebook.com/DevChattv/?__tn__=%2Cd%2CP-R&amp;eid=ARDBDrBnK71PDmx_8gE_IeIEo5SnM7cyzylVBjAwfaOo1ck_6q3GXuRBfaUQZaWVvFGyEVjrhDwnS_tV" rel="nofollow" target="_blank">Facebook</a> and <a href="https://twitter.com/devchattv?lang=en" rel="nofollow" target="_blank">Twitter</a> PicksCharles Max Wood:<ul> <li><a href="https://www.stgeorgemarathon.com/" rel="nofollow" target="_blank">St. George Marathon</a></li> <li><a href="https://obsproject.com/" rel="nofollow" target="_blank">OBS</a></li> </ul>David Kimura:<ul> <li><a href="https://education.lego.com/en-us/elementary/intro/wedo2" rel="nofollow" target="_blank">WeDo 2.0 by Lego</a></li> <li><a href="https://github.com/n8n-io/n8n" rel="nofollow" target="_blank">Workflow Automation Self Hosted</a></li> </ul>Andrew Mason:<ul> <li><a href="https://github.com/mikeal/publish-to-github-action" rel="nofollow" target="_blank">Publish to Github action</a></li> <li><a href="https://www.justdunning.com/" rel="nofollow" target="_blank">JustDunning.com</a></li> </ul>Nate Hopkins:<ul> <li><a href="https://www.goodreads.com/book/show/37570605-company-of-one" rel="nofollow" target="_blank">Company of One by Paul Jarvis</a></li> <li><a href="https://www.indiehackers.com" rel="nofollow" target="_blank">IndieHackers</a></li> </ul>Graham Conzett:<ul> <li><a href="https://basecamp.com/shapeup" rel="nofollow" target="_blank">Basecamp’s Shape Up</a></li> <li> <a href="https://pigeonforteachers.com/" rel="nofollow" target="_blank">Pigeonforteachers.com</a> </li> <li><a href="https://www.ikesmartcity.com/" rel="nofollow" target="_blank">IKE Smart City</a></li> </ul> Follow Graham <a href="https://twitter.com/gconzett?lang=en" rel="nofollow" target="_blank">@gconzett</a> on Twitter and <a href="https://github.com/conzett" rel="nofollow" target="_blank">Github</a> Special Guest: Graham Conzett.

RR 435: Alternatives to Adding React with Graham Conzett

Graham Conzett has been a developer for 12 years. He has worked with Ruby and Rails for half of that, and currently works for a company that does large format touchscreens. Graham gave a talk at RailsConf 2018 called “Old School JavaScript and Rails” where he talks about the experience of JavaScript fatigue. The world of JavaScript changes very quickly, and sometimes it feels like there’s a new framework every week. Because there is no clear winner among these frameworks, many Rails developers feel compelled to reach for something like React. However, there are many strategies for doing JavaScript in Ruby and in Rails that existed before these frameworks, so you can accomplish what you want to get done without bringing one in. Remember that all of them can coexist side by side, so you don’t have to pick one strategy. The panel discusses the effect that adopting a new technology can have on the team, such as the learning curve and hiring people that specialize in it. To illustrate this, Graham talks about the company he works for. Their app is a 90% is a Rails app, and one component has a lot of React. He talks about how they came up with that strategy and how they have kept React isolated to that page. It’s crept into some other little places, but there is a document in the team charter that defines where and why they use certain things, and that has kept it limited.Graham talks about the tradeoffs between choosing to stay in Rails or introduce React. If you bring in React, you have to bring in a different testing framework. React also has a bigger learning curve than standard HTML or CSS. There are far less conventions around React than Rails, so you have to spend time coming to a consensus as a team. Webpacker helps with this to a degree, but it also pulls in a bunch of third party plugins, so Rails is no longer writing the rules and you may have to debug random plugins.If you want to avoid adding a framework like React, consider using ujs, or Unobtrusive JavaScript. These are JavaScript ‘helpers’ included in the Rails bundle that you can add to various buttons that help you decorate and enhance. You don’t have to change much of your HTML frontend code but it makes it more interactive. Graham talks about he uses them and why he likes them. The panel compares using ujs to other strategies like using Stimulus or ‘sprinkles’ of JavaScript. For small JS sprinkles, Graham advises to keep that focused on a single HTML element and bound to a single event handler. Ujs works best when you piggyback off of that Rails/Rest related stuff, and Stimulus is more about manipulating parts on the page that don’t have a need for asynchronous request. You can really use ujs everywhere, so the three techniques are not mutually exclusive.Graham gives advice to developers considering pulling in a frontend framework. He says to start with minimal JS and then talk to your team about when it feels right to do it, because that’s a tricky conversation to know what your expectations are and problems you’re trying to solve. Sometimes things will force the issue and make you want to explore using frontend frameworks. When it’s a time saver, it makes your team scale better, or when you have something you just can’t do without it, then that might be the right time to use React.The show concludes with the panel discussing their experiences with different compiling languages like TypeScript. They talk about what influences the tools people choose. They agree that the most important thing is getting working code out there, it doesn’t really matter how it’s written, but to only pull things in when you know you need it.Panelists Charles Max Wood Andrew Mason David Kimura Nate Hopkins With special guest: Graham ConzettSponsors  Sentry use the code “devchat” for 2 months free on Sentry’s small plan   Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE &amp; get $66 free credits with promo code RubyRogues  Adventures in Angular Links Old School JavaScript and Rails at RailsConf 2018 React React Native React Native Web Jest Capybara Webpacker Rails-ujs Turbolinks Stimulus Stimulus Reflex Babel TypeScript Actionview components Angular  Follow DevChatTV on Facebook and Twitter PicksCharles Max Wood: St. George Marathon OBS David Kimura: WeDo 2.0 by Lego Workflow Automation Self Hosted Andrew Mason: Publish to Github action JustDunning.com Nate Hopkins: Company of One by Paul Jarvis IndieHackers Graham Conzett: Basecamp’s Shape Up  Pigeonforteachers.com   IKE Smart City  Follow Graham @gconzett on Twitter and Github Special Guest: Graham Conzett.   Advertising Inquiries: https://redcircle.com/brandsPrivacy &amp; Opt-Out: https://redcircle.com/privacy

Graham Conzett has been a developer for 12 years. He has worked with Ruby and Rails for half of that, and currently works for a company that does large format touchscreens. Graham gave a talk at RailsConf 2018 called “Old School JavaScript and Rails” where he talks about the experience of JavaScript fatigue. The world of JavaScript changes very quickly, and sometimes it feels like there’s a new framework every week. Because there is no clear winner among these frameworks, many Rails developers feel compelled to reach for something like React. However, there are many strategies for doing JavaScript in Ruby and in Rails that existed before these frameworks, so you can accomplish what you want to get done without bringing one in. Remember that all of them can coexist side by side, so you don’t have to pick one strategy. The panel discusses the effect that adopting a new technology can have on the team, such as the learning curve and hiring people that specialize in it. To illustrate this, Graham talks about the company he works for. Their app is a 90% is a Rails app, and one component has a lot of React. He talks about how they came up with that strategy and how they have kept React isolated to that page. It’s crept into some other little places, but there is a document in the team charter that defines where and why they use certain things, and that has kept it limited.Graham talks about the tradeoffs between choosing to stay in Rails or introduce React. If you bring in React, you have to bring in a different testing framework. React also has a bigger learning curve than standard HTML or CSS. There are far less conventions around React than Rails, so you have to spend time coming to a consensus as a team. Webpacker helps with this to a degree, but it also pulls in a bunch of third party plugins, so Rails is no longer writing the rules and you may have to debug random plugins.If you want to avoid adding a framework like React, consider using ujs, or Unobtrusive JavaScript. These are JavaScript ‘helpers’ included in the Rails bundle that you can add to various buttons that help you decorate and enhance. You don’t have to change much of your HTML frontend code but it makes it more interactive. Graham talks about he uses them and why he likes them. The panel compares using ujs to other strategies like using Stimulus or ‘sprinkles’ of JavaScript. For small JS sprinkles, Graham advises to keep that focused on a single HTML element and bound to a single event handler. Ujs works best when you piggyback off of that Rails/Rest related stuff, and Stimulus is more about manipulating parts on the page that don’t have a need for asynchronous request. You can really use ujs everywhere, so the three techniques are not mutually exclusive.Graham gives advice to developers considering pulling in a frontend framework. He says to start with minimal JS and then talk to your team about when it feels right to do it, because that’s a tricky conversation to know what your expectations are and problems you’re trying to solve. Sometimes things will force the issue and make you want to explore using frontend frameworks. When it’s a time saver, it makes your team scale better, or when you have something you just can’t do without it, then that might be the right time to use React.The show concludes with the panel discussing their experiences with different compiling languages like TypeScript. They talk about what influences the tools people choose. They agree that the most important thing is getting working code out there, it doesn’t really matter how it’s written, but to only pull things in when you know you need it.Panelists<ul> <li>Charles Max Wood</li> <li>Andrew Mason</li> <li>David Kimura</li> <li>Nate Hopkins</li> </ul>With special guest: Graham ConzettSponsors<ul> <li> <a href="http://sentry.io/" rel="nofollow" target="_blank">Sentry</a> use the code “devchat” for 2 months free on Sentry’s small plan </li> <li> <a href="https://cloud66.com/rails?utm_campaign=ruby-rogues&amp;utm_medium=-&amp;utm_source=-" rel="nofollow" target="_blank">Cloud 66 - Pain Free Rails Deployments</a> Try Cloud 66 Rails for FREE &amp; get $66 free credits with promo code RubyRogues </li> <li><a href="https://devchat.tv/adv-in-angular/" rel="nofollow" target="_blank">Adventures in Angular</a></li> </ul>Links<ul> <li><a href="https://www.youtube.com/watch?v=lh5qfV2iP80" rel="nofollow" target="_blank">Old School JavaScript and Rails at RailsConf 2018</a></li> <li><a href="https://reactjs.org/" rel="nofollow" target="_blank">React</a></li> <li><a href="http://www.reactnative.com/" rel="nofollow" target="_blank">React Native</a></li> <li><a href="https://github.com/necolas/react-native-web" rel="nofollow" target="_blank">React Native Web</a></li> <li><a href="https://jestjs.io/" rel="nofollow" target="_blank">Jest</a></li> <li><a href="https://github.com/teamcapybara/capybara" rel="nofollow" target="_blank">Capybara</a></li> <li><a href="https://github.com/rails/webpacker" rel="nofollow" target="_blank">Webpacker</a></li> <li><a href="https://github.com/rails/rails-ujs" rel="nofollow" target="_blank">Rails-ujs</a></li> <li><a href="https://github.com/turbolinks/turbolinks" rel="nofollow" target="_blank">Turbolinks</a></li> <li><a href="https://stimulusjs.org/" rel="nofollow" target="_blank">Stimulus</a></li> <li><a href="https://github.com/hopsoft/stimulus_reflex" rel="nofollow" target="_blank">Stimulus Reflex</a></li> <li><a href="https://babeljs.io/" rel="nofollow" target="_blank">Babel</a></li> <li><a href="https://www.typescriptlang.org/" rel="nofollow" target="_blank">TypeScript</a></li> <li><a href="https://github.com/github/actionview-component" rel="nofollow" target="_blank">Actionview components</a></li> <li><a href="https://angular.io/" rel="nofollow" target="_blank">Angular</a></li> </ul> Follow DevChatTV on <a href="https://www.facebook.com/DevChattv/?__tn__=%2Cd%2CP-R&amp;eid=ARDBDrBnK71PDmx_8gE_IeIEo5SnM7cyzylVBjAwfaOo1ck_6q3GXuRBfaUQZaWVvFGyEVjrhDwnS_tV" rel="nofollow" target="_blank">Facebook</a> and <a href="https://twitter.com/devchattv?lang=en" rel="nofollow" target="_blank">Twitter</a> PicksCharles Max Wood:<ul> <li><a href="https://www.stgeorgemarathon.com/" rel="nofollow" target="_blank">St. George Marathon</a></li> <li><a href="https://obsproject.com/" rel="nofollow" target="_blank">OBS</a></li> </ul>David Kimura:<ul> <li><a href="https://education.lego.com/en-us/elementary/intro/wedo2" rel="nofollow" target="_blank">WeDo 2.0 by Lego</a></li> <li><a href="https://github.com/n8n-io/n8n" rel="nofollow" target="_blank">Workflow Automation Self Hosted</a></li> </ul>Andrew Mason:<ul> <li><a href="https://github.com/mikeal/publish-to-github-action" rel="nofollow" target="_blank">Publish to Github action</a></li> <li><a href="https://www.justdunning.com/" rel="nofollow" target="_blank">JustDunning.com</a></li> </ul>Nate Hopkins:<ul> <li><a href="https://www.goodreads.com/book/show/37570605-company-of-one" rel="nofollow" target="_blank">Company of One by Paul Jarvis</a></li> <li><a href="https://www.indiehackers.com" rel="nofollow" target="_blank">IndieHackers</a></li> </ul>Graham Conzett:<ul> <li><a href="https://basecamp.com/shapeup" rel="nofollow" target="_blank">Basecamp’s Shape Up</a></li> <li> <a href="https://pigeonforteachers.com/" rel="nofollow" target="_blank">Pigeonforteachers.com</a> </li> <li><a href="https://www.ikesmartcity.com/" rel="nofollow" target="_blank">IKE Smart City</a></li> </ul> Follow Graham <a href="https://twitter.com/gconzett?lang=en" rel="nofollow" target="_blank">@gconzett</a> on Twitter and <a href="https://github.com/conzett" rel="nofollow" target="_blank">Github</a> Special Guest: Graham Conzett. Advertising Inquiries: <a href="https://redcircle.com/brands" rel="nofollow" target="_blank">https://redcircle.com/brands</a> Privacy &amp; Opt-Out: <a href="https://redcircle.com/privacy" rel="nofollow" target="_blank">https://redcircle.com/privacy</a>

Graham Conzett has been a developer for 12 years. He has worked with Ruby and Rails for half of that, and currently works for a company that does large format touchscreens. Graham gave a talk at RailsConf 2018 called “Old School JavaScript and Rails” where he talks about the experience of JavaScript fatigue. The world of JavaScript changes very quickly, and sometimes it feels like there’s a new framework every week. Because there is no clear winner among these frameworks, many Rails developers feel compelled to reach for something like React. However, there are many strategies for doing JavaScript in Ruby and in Rails that existed before these frameworks, so you can accomplish what you want to get done without bringing one in. Remember that all of them can coexist side by side, so you don’t have to pick one strategy. The panel discusses the effect that adopting a new technology can have on the team, such as the learning curve and hiring people that specialize in it.  To illustrate this, Graham talks about the company he works for. Their app is a 90% is a Rails app, and one component has a lot of React. He talks about how they came up with that strategy and how they have kept React isolated to that page. It’s crept into some other little places, but there is a document in the team charter that defines where and why they use certain things, and that has kept it limited. Graham talks about the tradeoffs between choosing to stay in Rails or introduce React. If you bring in React, you have to bring in a different testing framework. React also has a bigger learning curve than standard HTML or CSS. There are far less conventions around React than Rails, so you have to spend time coming to a consensus as a team. Webpacker helps with this to a degree, but it also pulls in a bunch of third party plugins, so Rails is no longer writing the rules and you may have to debug random plugins. If you want to avoid adding a framework like React, consider using ujs, or Unobtrusive JavaScript. These are JavaScript ‘helpers’ included in the Rails bundle that you can add to various buttons that help you decorate and enhance. You don’t have to change much of your HTML frontend code but it makes it more interactive. Graham talks about he uses them and why he likes them. The panel compares using ujs to other strategies like using Stimulus or ‘sprinkles’ of JavaScript. For small JS sprinkles, Graham advises to keep that focused on a single HTML element and bound to a single event handler. Ujs works best when you piggyback off of that Rails/Rest related stuff, and Stimulus is more about manipulating parts on the page that don’t have a need for asynchronous request. You can really use ujs everywhere, so the three techniques are not mutually exclusive. Graham gives advice to developers considering pulling in a frontend framework. He says to start with minimal JS and then talk to your team about when it feels right to do it, because that’s a tricky conversation to know what your expectations are and problems you’re trying to solve. Sometimes things will force the issue and make you want to explore using frontend frameworks. When it’s a time saver, it makes your team scale better, or when you have something you just can’t do without it, then that might be the right time to use React. The show concludes with the panel discussing their experiences with different compiling languages like TypeScript. They talk about what influences the tools people choose. They agree that the most important thing is getting working code out there, it doesn’t really matter how it’s written, but to only pull things in when you know you need it. Panelists   Charles Max Wood   Andrew Mason   David Kimura   Nate Hopkins   With special guest: Graham Conzett Sponsors   Sentry use the code “devchat” for 2 months free on Sentry’s small plan   Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE &amp; get $66 free credits with promo code RubyRogues   Adventures in Angular   Links   Old School JavaScript and Rails at RailsConf 2018   React   React Native   React Native Web   Jest   Capybara   Webpacker   Rails-ujs   Turbolinks   Stimulus   Stimulus Reflex   Babel   TypeScript   Actionview components   Angular   Follow DevChatTV on Facebook and Twitter Picks Charles Max Wood:   St. George Marathon   OBS   David Kimura:   WeDo 2.0 by Lego   Workflow Automation Self Hosted   Andrew Mason:   Publish to Github action   JustDunning.com   Nate Hopkins:   Company of One by Paul Jarvis   IndieHackers   Graham Conzett:   Basecamp’s Shape Up   Pigeonforteachers.com    IKE Smart City   Follow Graham @gconzett on Twitter and Github

Graham Conzett has been a developer for 12 years. He has worked with Ruby and Rails for half of that, and currently works for a company that does large format touchscreens. Graham gave a talk at RailsConf 2018 called “Old School JavaScript and Rails” where he talks about the experience of JavaScript fatigue. The world of JavaScript changes very quickly, and sometimes it feels like there’s a new framework every week. Because there is no clear winner among these frameworks, many Rails developers feel compelled to reach for something like React. However, there are many strategies for doing JavaScript in Ruby and in Rails that existed before these frameworks, so you can accomplish what you want to get done without bringing one in. Remember that all of them can coexist side by side, so you don’t have to pick one strategy. The panel discusses the effect that adopting a new technology can have on the team, such as the learning curve and hiring people that specialize in it.  To illustrate this, Graham talks about the company he works for. Their app is a 90% is a Rails app, and one component has a lot of React. He talks about how they came up with that strategy and how they have kept React isolated to that page. It’s crept into some other little places, but there is a document in the team charter that defines where and why they use certain things, and that has kept it limited. Graham talks about the tradeoffs between choosing to stay in Rails or introduce React. If you bring in React, you have to bring in a different testing framework. React also has a bigger learning curve than standard HTML or CSS. There are far less conventions around React than Rails, so you have to spend time coming to a consensus as a team. Webpacker helps with this to a degree, but it also pulls in a bunch of third party plugins, so Rails is no longer writing the rules and you may have to debug random plugins. If you want to avoid adding a framework like React, consider using ujs, or Unobtrusive JavaScript. These are JavaScript ‘helpers’ included in the Rails bundle that you can add to various buttons that help you decorate and enhance. You don’t have to change much of your HTML frontend code but it makes it more interactive. Graham talks about he uses them and why he likes them. The panel compares using ujs to other strategies like using Stimulus or ‘sprinkles’ of JavaScript. For small JS sprinkles, Graham advises to keep that focused on a single HTML element and bound to a single event handler. Ujs works best when you piggyback off of that Rails/Rest related stuff, and Stimulus is more about manipulating parts on the page that don’t have a need for asynchronous request. You can really use ujs everywhere, so the three techniques are not mutually exclusive. Graham gives advice to developers considering pulling in a frontend framework. He says to start with minimal JS and then talk to your team about when it feels right to do it, because that’s a tricky conversation to know what your expectations are and problems you’re trying to solve. Sometimes things will force the issue and make you want to explore using frontend frameworks. When it’s a time saver, it makes your team scale better, or when you have something you just can’t do without it, then that might be the right time to use React. The show concludes with the panel discussing their experiences with different compiling languages like TypeScript. They talk about what influences the tools people choose. They agree that the most important thing is getting working code out there, it doesn’t really matter how it’s written, but to only pull things in when you know you need it. <h3>Panelists</h3> <ul> <li> Charles Max Wood </li> <li> Andrew Mason </li> <li> David Kimura </li> <li> Nate Hopkins </li> </ul> With special guest: Graham Conzett <h2>Sponsors</h2> <ul> <li> <a href="http://sentry.io/" rel="nofollow" target="_blank">Sentry</a> use the code “devchat” for 2 months free on Sentry’s small plan </li> <li> <a href="https://cloud66.com/rails?utm_source=-&amp;utm_medium=-&amp;utm_campaign=ruby-rogues" rel="nofollow" target="_blank">Cloud 66 - Pain Free Rails Deployments</a> Try Cloud 66 Rails for FREE &amp; get $66 free credits with promo code RubyRogues </li> <li> <a href="https://devchat.tv/adv-in-angular/" rel="nofollow" target="_blank">Adventures in Angular</a> </li> </ul> Links <ul> <li> <a href="https://www.youtube.com/watch?v=lh5qfV2iP80" rel="nofollow" target="_blank">Old School JavaScript and Rails at RailsConf 2018</a> </li> <li> <a href="https://reactjs.org/" rel="nofollow" target="_blank">React</a> </li> <li> <a href="http://www.reactnative.com/" rel="nofollow" target="_blank">React Native</a> </li> <li> <a href="https://github.com/necolas/react-native-web" rel="nofollow" target="_blank">React Native Web</a> </li> <li> <a href="https://jestjs.io/" rel="nofollow" target="_blank">Jest</a> </li> <li> <a href="https://github.com/teamcapybara/capybara" rel="nofollow" target="_blank">Capybara</a> </li> <li> <a href="https://github.com/rails/webpacker" rel="nofollow" target="_blank">Webpacker</a> </li> <li> <a href="https://github.com/rails/rails-ujs" rel="nofollow" target="_blank">Rails-ujs</a> </li> <li> <a href="https://github.com/turbolinks/turbolinks" rel="nofollow" target="_blank">Turbolinks</a> </li> <li> <a href="https://stimulusjs.org/" rel="nofollow" target="_blank">Stimulus</a> </li> <li> <a href="https://github.com/hopsoft/stimulus_reflex" rel="nofollow" target="_blank">Stimulus Reflex</a> </li> <li> <a href="https://babeljs.io/" rel="nofollow" target="_blank">Babel</a> </li> <li> <a href="https://www.typescriptlang.org/" rel="nofollow" target="_blank">TypeScript</a> </li> <li> <a href="https://github.com/github/actionview-component" rel="nofollow" target="_blank">Actionview components</a> </li> <li> <a href="https://angular.io/" rel="nofollow" target="_blank">Angular</a> </li> </ul> Follow DevChatTV on <a href="https://www.facebook.com/DevChattv/?__tn__=%2Cd%2CP-R&amp;eid=ARDBDrBnK71PDmx_8gE_IeIEo5SnM7cyzylVBjAwfaOo1ck_6q3GXuRBfaUQZaWVvFGyEVjrhDwnS_tV" rel="nofollow" target="_blank">Facebook</a> and <a href="https://twitter.com/devchattv?lang=en" rel="nofollow" target="_blank">Twitter</a> <h3>Picks</h3> Charles Max Wood: <ul> <li> <a href="https://www.stgeorgemarathon.com/" rel="nofollow" target="_blank">St. George Marathon</a> </li> <li> <a href="https://obsproject.com/" rel="nofollow" target="_blank">OBS</a> </li> </ul> David Kimura: <ul> <li> <a href="https://education.lego.com/en-us/elementary/intro/wedo2" rel="nofollow" target="_blank">WeDo 2.0 by Lego</a> </li> <li> <a href="https://github.com/n8n-io/n8n" rel="nofollow" target="_blank">Workflow Automation Self Hosted</a> </li> </ul> Andrew Mason: <ul> <li> <a href="https://github.com/mikeal/publish-to-github-action" rel="nofollow" target="_blank">Publish to Github action</a> </li> <li> <a href="https://www.justdunning.com/" rel="nofollow" target="_blank">JustDunning.com</a> </li> </ul> Nate Hopkins: <ul> <li> <a href="https://www.goodreads.com/book/show/37570605-company-of-one" rel="nofollow" target="_blank">Company of One by Paul Jarvis</a> </li> <li> <a href="https://www.indiehackers.com" rel="nofollow" target="_blank">IndieHackers</a> </li> </ul> Graham Conzett: <ul> <li> <a href="https://basecamp.com/shapeup" rel="nofollow" target="_blank">Basecamp’s Shape Up</a> </li> <li> <a href="https://pigeonforteachers.com/" rel="nofollow" target="_blank">Pigeonforteachers.com</a> </li> <li> <a href="https://www.ikesmartcity.com/" rel="nofollow" target="_blank">IKE Smart City</a> </li> </ul> Follow Graham <a href="https://twitter.com/gconzett?lang=en" rel="nofollow" target="_blank">@gconzett</a> on Twitter and <a href="https://github.com/conzett" rel="nofollow" target="_blank">Github</a>