On today's episode, Charles Max Wood shares My JS Story Isaac Schlueter. Isaac is the co-founder and chief executive officer at NPM. Listen to his interesting javascript story, and learn how you can connect with him!

On today's episode, Charles Max Wood, Joe Eames, and Aimee Knight discuss Loading and Optimizing Web Applications with Sam Saccone and Jeff Cross. Tune in to their interesting talk, and learn how you can improve user experience and performance with better loading!

On today's JavaScript Jabber Show, Aimee Knight and Charles Max Wood discuss Contributor Days with Tracy Lee. Tracy is a Google Developer Expert and a co-founder of This Dot Media and This Dot Labs. She's passionately into helping startups create a connection with investors. Part of what she's been up to lately is what this episode is about. Tune in to learn about it!

On today's episode, Charles, Joe, and Cory discuss Practical JavaScript with Gordon Zhu. Gordon is the founder of Watch and Code, and teaches the Practical JavaScript online course. His mission is to help beginners become developers through tutorials. Tune in!

JSJ 269 Reusable React and JavaScript Components with Cory House

On today’s episode of JavaScript Jabber, we have panelists Joe Eames, Aimee Knight, Charles Max Wood, and playing the part of both host and guest, Cory House. Encourage your team to investigate reusable components, whether that’d be React, Angular, Vue, or Ember. Tune in!

[00:01:35] – Overview

We can finally write reusable components that it is really lightweight. It doesn’t take much framework-specific code to get things done.

Around 3 years ago, the idea of web component standard was all front-end developers could share our components with each other whether someone is in Angular or React. Web components continue to be an interesting standard but people continue to reach for JavaScript libraries instead – React, Angular, Vue. 

[00:04:50] – Browser support issue

The story in JavaScript libraries is easier. You have more power, more flexibility, more choices, and get superior performance, in certain cases, by choosing a JavaScript library over the standard right now. If you try to use the web components standard, you have to Polyfill-in some features so you can run things across browser. You also won’t get JavaScript features like intelligently splitting bundles and lazy load different components.

Whether you’re in Angular or React, you have this model of putting your data in your curly braces. That setup is non-existent in standardized web components. You have to play the game of putting and pulling data into and out the DOM using DOM selectors. You actually take a step backward in developer ergonomics when you choose to leverage the platform instead.

[00:07:50] – Polymer

The reason that Polymer is useful is it adds some goodness on top of web components. One of those things is that it makes it easier to bind in data and not having to do things like writing a DOM query to be able to get your hands on this div and put this text inside of it. With Polymer, you can do something that feels more like Angular, where you can put in your curly braces and just bind in some data into that place. Polymer ends up adding some nice syntactic sugar on top of the web components standard just to make it easier to create web components. Polymer is also used to bundle in Polyfill for the features across browser.   

[00:14:20] – Standards are dead

No. The standard itself has been embraced at different levels by different libraries. What you can see for the near future is popular libraries leveraging pieces of the web components platform to do things in a standard-spaced way. Effectively, Angular, Vue, Aurelia, are going to be abstractions over the web components standard. Arguably the most popular way to do components today is React. But React completely ignores the web components standard. When you look at React, you can’t see what piece of the web components standard would fundamentally make React a better component library.

Cory can’t seem to run to anybody that is actually using the standard in production to build real applications. People continue to reach for the popular JavaScript libraries that we so often hear about.

[00:17:05] – Libraries making reusable components

There is a risk that it would have been a waste for people writing components on Angular, for React, for Vue. But it’s not necessarily safer writing on the web component standard when you have so few people leveraging that standard. There’s always the risk that that standard may shift as well.

As an example, Cory’s team created approximately 100 reusable components in React. If they end up moving to a hot new library, the components are really just functions that take parameters and contain HTML. There is little there

[00:21:20] – Why opt for reusable components

Reusable components are inherently useful in a situation where you’re going to be doing something more than once. If you think about any work that you do as a software developer, we’d like to think that we’re coming in and creating new things but often it is groundhogs day. There are all sorts of opportunities for reuse.

As a company, we want to encapsulate our forms in reusable components so it’s literally impossible for our software developers to do something that goes against our standard. That’s the power of reusable components.  

[00:31:20] – Rigid component vs. flexible component

As component developers, if we try to create a reusable component in a vacuum, bad things happen. If you’re going to do a reusable component, start by solving a specific problem on a given application. If we think that a component’s going to be useful in multiple places, we put it in a folder called reusable right there in our application source folder.

We try to follow that rule of three as well. If we’ve taken that component and used it in 3 places, that’s a good sign that we should extract it out, put it in our NPM package, that way, everybody has this centralized component to utilize. At that point, it has been tested. It’s been through the fire. People have used it in the real world in a few places so we can be confident that the API is truly flexible enough.

Be as rigid as you can upfront. Once you add features, it’s really hard to take features away. But it’s quite easy to add features later. If you start with something rigid, it’s easier to understand. It’s easier to maintain and you can always add a few more switches later.

[00:36:00] – Reusable components

The reason that we can’t reuse code is every time a new project comes up, people are spending up their own ideas rather than leveraging standards that should have been put in place previously.

We’ve had the technical ability to do this for a long time. We just haven’t been around long enough for consolidation to happen, for standardization to happen. You look at how quickly things are changing in our industry. For instance, a couple of years ago, everybody had pretty much decided that two-way binding was the way to build web applications. And then, React came along and shook that up. So today, you have different ways of thinking about that issue.

[00:42:45] – Component development on teams

Aimee’s team has component development and they’re using Angular 1.6. All of our base components are sitting in a seed application. We just go in when we want to create a new property and we just extend all of those components with specific functionalities that we need.

[00:47:45] – Mobile to web crossover

Cory’s team is creating React components but it’s not leveraged on a mobile application. But people use React Native components on the web. And in fact, if you use create-react-app today, you can do that right now. It’s wired up to work in React Native components. In that way, you can literally have these same components running on your Native mobile apps as you do on your web application.

[00:50:00] – Challenge

Cory’s challenge for everybody listening is sit down with your team and have a quick conversation about whether you think components make sense. Look back at the last few months of development and say, "if we have a reusable component library, what would be in it? How often have we found ourselves copying and pasting code between different projects? How much benefit would we get out of this story?"

Once you’ve realized the benefits of the component model, both in the way that makes you think about your application, in a way that it helps you move faster and faster over time, I really think you won’t go back to the old model. I’d encourage people to investigate reusable components, whether that’d be React, Angular, Vue or Ember.

Picks

Cory House

• Creating Reusable React Components on Pluralsight
• Ted Talk: Why You Should Define your Fears Instead of Your Goals by Tim Ferriss

Joe Eames

• UI-Router
• Persistence

Aimee Knight

• Ask HN: People who completed a boot camp 3+ years ago, what are you doing now?
• NgAtlanta

Charles Max Wood

• Upwork.com

JSJ 269 Reusable React and JavaScript Components with Cory House

On today’s episode of JavaScript Jabber, we have panelists Joe Eames, Aimee Knight, Charles Max Wood, and playing the part of both host and guest, Cory House. Encourage your team to investigate reusable components, whether that’d be React, Angular, Vue, or Ember. Tune in!

[00:01:35] – Overview

We can finally write reusable components that it is really lightweight. It doesn’t take much framework-specific code to get things done.

Around 3 years ago, the idea of web component standard was all front-end developers could share our components with each other whether someone is in Angular or React. Web components continue to be an interesting standard but people continue to reach for JavaScript libraries instead – React, Angular, Vue. 

[00:04:50] – Browser support issue

The story in JavaScript libraries is easier. You have more power, more flexibility, more choices, and get superior performance, in certain cases, by choosing a JavaScript library over the standard right now. If you try to use the web components standard, you have to Polyfill-in some features so you can run things across browser. You also won’t get JavaScript features like intelligently splitting bundles and lazy load different components.

Whether you’re in Angular or React, you have this model of putting your data in your curly braces. That setup is non-existent in standardized web components. You have to play the game of putting and pulling data into and out the DOM using DOM selectors. You actually take a step backward in developer ergonomics when you choose to leverage the platform instead.

[00:07:50] – Polymer

The reason that Polymer is useful is it adds some goodness on top of web components. One of those things is that it makes it easier to bind in data and not having to do things like writing a DOM query to be able to get your hands on this div and put this text inside of it. With Polymer, you can do something that feels more like Angular, where you can put in your curly braces and just bind in some data into that place. Polymer ends up adding some nice syntactic sugar on top of the web components standard just to make it easier to create web components. Polymer is also used to bundle in Polyfill for the features across browser.   

[00:14:20] – Standards are dead

No. The standard itself has been embraced at different levels by different libraries. What you can see for the near future is popular libraries leveraging pieces of the web components platform to do things in a standard-spaced way. Effectively, Angular, Vue, Aurelia, are going to be abstractions over the web components standard. Arguably the most popular way to do components today is React. But React completely ignores the web components standard. When you look at React, you can’t see what piece of the web components standard would fundamentally make React a better component library.

Cory can’t seem to run to anybody that is actually using the standard in production to build real applications. People continue to reach for the popular JavaScript libraries that we so often hear about.

[00:17:05] – Libraries making reusable components

There is a risk that it would have been a waste for people writing components on Angular, for React, for Vue. But it’s not necessarily safer writing on the web component standard when you have so few people leveraging that standard. There’s always the risk that that standard may shift as well.

As an example, Cory’s team created approximately 100 reusable components in React. If they end up moving to a hot new library, the components are really just functions that take parameters and contain HTML. There is little there

[00:21:20] – Why opt for reusable components

Reusable components are inherently useful in a situation where you’re going to be doing something more than once. If you think about any work that you do as a software developer, we’d like to think that we’re coming in and creating new things but often it is groundhogs day. There are all sorts of opportunities for reuse.

As a company, we want to encapsulate our forms in reusable components so it’s literally impossible for our software developers to do something that goes against our standard. That’s the power of reusable components.  

[00:31:20] – Rigid component vs. flexible component

As component developers, if we try to create a reusable component in a vacuum, bad things happen. If you’re going to do a reusable component, start by solving a specific problem on a given application. If we think that a component’s going to be useful in multiple places, we put it in a folder called reusable right there in our application source folder.

We try to follow that rule of three as well. If we’ve taken that component and used it in 3 places, that’s a good sign that we should extract it out, put it in our NPM package, that way, everybody has this centralized component to utilize. At that point, it has been tested. It’s been through the fire. People have used it in the real world in a few places so we can be confident that the API is truly flexible enough.

Be as rigid as you can upfront. Once you add features, it’s really hard to take features away. But it’s quite easy to add features later. If you start with something rigid, it’s easier to understand. It’s easier to maintain and you can always add a few more switches later.

[00:36:00] – Reusable components

The reason that we can’t reuse code is every time a new project comes up, people are spending up their own ideas rather than leveraging standards that should have been put in place previously.

We’ve had the technical ability to do this for a long time. We just haven’t been around long enough for consolidation to happen, for standardization to happen. You look at how quickly things are changing in our industry. For instance, a couple of years ago, everybody had pretty much decided that two-way binding was the way to build web applications. And then, React came along and shook that up. So today, you have different ways of thinking about that issue.

[00:42:45] – Component development on teams

Aimee’s team has component development and they’re using Angular 1.6. All of our base components are sitting in a seed application. We just go in when we want to create a new property and we just extend all of those components with specific functionalities that we need.

[00:47:45] – Mobile to web crossover

Cory’s team is creating React components but it’s not leveraged on a mobile application. But people use React Native components on the web. And in fact, if you use create-react-app today, you can do that right now. It’s wired up to work in React Native components. In that way, you can literally have these same components running on your Native mobile apps as you do on your web application.

[00:50:00] – Challenge

Cory’s challenge for everybody listening is sit down with your team and have a quick conversation about whether you think components make sense. Look back at the last few months of development and say, "if we have a reusable component library, what would be in it? How often have we found ourselves copying and pasting code between different projects? How much benefit would we get out of this story?"

Once you’ve realized the benefits of the component model, both in the way that makes you think about your application, in a way that it helps you move faster and faster over time, I really think you won’t go back to the old model. I’d encourage people to investigate reusable components, whether that’d be React, Angular, Vue or Ember.

Picks

Cory House

• Creating Reusable React Components on Pluralsight
• Ted Talk: Why You Should Define your Fears Instead of Your Goals by Tim Ferriss

Joe Eames

• UI-Router
• Persistence

Aimee Knight

• Ask HN: People who completed a boot camp 3+ years ago, what are you doing now?
• NgAtlanta

Charles Max Wood

• Upwork.com

MJS 028 Zach Kessin

In this episode we have another JavaScript Story, this time our guest is Zach Kessin. Zach is a Developer and consultant. On the server side he works with Erlang and Elixir. On the front end he works on Elm. He also also written a few books for O’Reilly and a video course for Manning available sometime in the fall. He was a guest on episode 57 and is here with us today to tell us his story. Stay tuned!

[2:48] How did you get into programming.

Zack tells the story about how when he was 7 he asked his mother for a computer. She agreed that if he paid for half of it somehow, then she would help him get it. He Gathered his half by calling relatives and gathering funds. His mom taught him Basic and Logo. He also learned Pascal. While in University he picked up the book Structure and Interpretation of Computer Programs and loved it. He talks about remembering writing a HTML forum but not knowing how to submit entries. After college he started working.

[4:38] Resources then vs now.

Charles adds that if you’re tenacious enough to call your family members to find funding to buy a computer to learn, then you probably have the drive it takes to be a programmer. Charles and Zack talk about how in the 80s it was rare to have access to a computer, and now homes have multiple computers throughout. The resources are more readily available now with the internet. If you’re looking to get into development, there are plenty of great resources.

[7:45] How did you get into JavaScript and Erlang?

Zach starts explaining by telling how he get into JavaScript before the internet really existed. His first JavaScript program exposure was a loan calculator at a bank. Early on the only thing you could do was validate forms, but over time it grew. He started working for a company writing php. He felt like it wasn’t as functional or elegant as he was hoping for. He found various languages and landed on Erlang. Erland was designed to work for programming telephone switches. Due to phone services nature, It handles high scale, high reliability, has to be upgraded on the fly, etc. Zach talks about how server programming looks very similar to phone line programming. Zach adds that a few years ago he wanted work on some front end and after looking around finally he learned about Elm. He says that he is always looking for what’s new and useful.

[14:26] Programming Languages Change the Way We Think

Charles points out that it’s very interesting out about how functional programming has played out. He mentions that many JavaScript programmers use functional style programming to help with speed or efficiency. He adds that a fully functional programming language is very interesting and could be helpful. Zach talks about how learning new languages helps adjust the way we think.

[16:45] How have you contributed to the development community?

Charles starts off with mentioning Zach’s podcast that was called Mostly Erlang. Zach adds that he has wrote two books for O’ Reilly, one on HTML5 and Erlang. He has done some blogging and is creating a video course called Startup Elm. He mentions that he spends most of his time teaching. He admires people who write libraries and sustains them over years, but it isn’t something he sees himself getting into. He adds that having the libraries are useless unless you have someone to communicate about it and teach it. Charles mentions that contributions come in various ways and the community needs those sort of teachers. Zach mentions that he often speaks at conferences and meet ups. Public speaking can be a great way to progress your career. Charles brings up the idea of “Sweeping the dojo floor”. He was introduced to this idea by Dave Hoover. Sweeping the dojo floor means that you’ve got enough experience to talk about the topic, but maybe not fully contribute and so you do things like document code, or write articles and outreach for the topic. Talks can lead to work. You can easily find research papers and do talks on that. Zach adds that sometimes in a community, you see the same speakers over and over and new speakers are needed. Zach also mentions that there are plenty of opportunities to do talks in something other than english.

[26:36] What are you working on now?

Zach talks about the list of things he is working on. Starting with Startup Elm and it’s live course that will be happening in October. He is also working on a SaSS product for Instagram marketers called SquareTarget. He adds that he has a day job as well.

Picks

Zach

Intrepid Large Format Camera Kickstarter

Charles

Toast Masters
Zapier
Javascriptjabber.com/slack

Tweet this Episode

Tyler Renelle is a contractor and developer who has worked in various web technologies like Node, Angular, Rails, and much more. He's also build machine learning backends in Python (Flask), Tensorflow, and Neural Networks.

The JavaScript Jabber panel dives into Machine Learning with Tyler Renelle. Specifically, they go into what is emerging in machine learning and artificial intelligence and what that means for programmers and programming jobs.

This episode dives into:

• Whether machine learning will replace programming jobs
• Economic automation
• Which platforms and languages to use to get into machine learning
• and much, much more...

Links:

• Raspberry Pi
• Arduino
• Hacker News
• Neural Networks (wikipedia)
• Deep Mind
• Shallow Algorithms
• Genetic Algorithms
• Crisper gene editing
• Wix
• thegrid.io
• Codeschool
• Codecademy
• Tensorflow
• Keras
• Machine Learning Guide
• Andrew Ng Coursera Course
• Python
• R
• Java
• Torch
• PyTorch
• Caffe
• Scikit learn
• Tensorfire
• DeepLearn.js
• The Singularity is Near by Ray Kurzweil
• Tensorforce
• Super Intelligence by Nick Bostrom

Picks:

Aimee

• Include media
• Nodevember
• Phone cases

AJ

• Data Skeptic
• Ready Player One

Joe

• Everybody Lies

Tyler

• Ex Machina
• Philosophy of Mind: Brains, Consciousness, and Thinking Machines

Panel:

Joe 

Amy 

Charles 

Special Guests: 

Eric Simmons 

Albert Pai

In this episode, JavaScript Jabbers talk to Eric Simmons and Albert Pai, the co-founder of thinkster.io, where their team teaches the bleeding edge of javascript technology’s various frameworks and backend. Also, with the recent creation of Stalkblitz, which is the center topic of today discussion. 

Stackblitz it an online VS Code IDE for Angular, React, and a few more others are supported. This is designed to run web pack and vs code inside your browser at blazing fast speeds. Eric and Albert dive into the many different advantages and services available by StackBlitz and thinker.io. 

In particular, we dive pretty deep on:

• Similarities  and differences to Heroku 
• System JS 
• Stacklets  
• Testing and creating an in-browser system file system
• Creating a type of VS Code experience, Working Off Line 
• Updating of the Stacklets
• Deployment tools or exporting 
• Hot Reloading
• Integrated terminals
• Monaco
• Language Services 
• How do you architect this implementation 
• The innovation of browsers
• Guy Bedford 
• Financing vs. Chipotle Burritos 
• Will this product in the future cost money

Links

• thinkster.io
• https://medium.com/@ericsimons/stackblitz-online-vs-code-ide-for-angular-react-7d09348497f4
• @stackblitz 
• stackblitz.com

Picks

Amy

• Promises Series by Andrew Del Prete
• Crossfit 

Joe

• Wholesome Meme
• Sara Cooper

Charles

• Pivotal Tracker 
• MatterMost 
• asana.com
• Zapier

Eric 

• realworld.io 
• David East 

Albert 

• thinkster.io
• Thing Explainer

Panel: 

Charles Max Wood

Special Guests: Nishant Thacker

In this episode, JavaScript Jabber speaks with Nishant Thacker. Nishant is the technical product manager for all things big data at Microsoft. Nishant mentions the many new technologies and announcements he is in-charge of at Microsoft.

Nishant is on the show to talk about Big Data and gives advice on how to process data and acquire deep insight of your customers. This is a great episode to understand the development of data systems that are the backbone of some marketing tools.

In particular, we dive pretty deep on:

• Processing Metrics
• Processing into report and usable information
• Data lake
• Collecting data points
• Creating and maintaining the data lake in its raw form
• Scale up engines and limits
• Commodity machines and leverage
• Big data means to scale out
• Specialized engines for audio and video files
• How to have a cohesive report?
• Writing and Querying across data
• Storing raw data and retrieve data
• Data cluster
• What does the data box look like?
• And much more!

Links:

• https://www.linkedin.com/in/nishantthacker
• @nishantthacker

Picks:

Nishant

• Robot I

Charles

• Zoom H6
• Shure SM 58
• Lavalier Mics

Panel: 

Charles Max Wood

Cory House

Joe Eames

Aimee Knight

Special Guests: Azat Mardan

In this episode, JavaScript Jabber panelist speak with Azat Mardan. Azat is a return guest, previously on JSJ Episode 230. Azat is an author of 14 books on Node JS, JavaScript, and React JS. Azat works at Capital One on the technology team. Azat is the founder and creator of Node University.

Azat is on the show to talk about changes in React and licensing. Some of the topics cover Facebook,  licensing with React, using the wrong version of React, patent wars, and much more in-depth information on current events in React.

In particular, we dive pretty deep on:

• Facebook - Licensing with React
• Using the Wrong version of React in some companies
• BSD licensing
• Patent wars
• Facebook developing React
• Difference in Preact and Inferno
• Rewriting applications
• What did Capital One do about the changes?
• React 16
• Pure React
• Was the BSD patents - Med and Sm Companies
• Patents explained
• React Developers at Facebook
• Fiber - New Core Architecture
• And much more!

Links:

• http://azat.co
• https://node.university
• https://devchat.tv/js-jabber/230-jsj-node-at-capital-one-with-azat-mardan

Picks:

Cory

• Axel Rauschmayer post
• Prettier

Charles

• Indiegogo for Dev Chat
• forum.devchat.tv

Aimee

• Dev Tees
• Hacker News - Question on Stack Exchange and Estimates 

Joe

• Heroku 
• El Camino Christmas

Azat

• PMP 
• Azat - Short Lecture

Panel: 

Charles Max Wood

Aimee Knight

Corey House

AJ O'Neal

Special Guests: Ben Coe, Aaron Abramov, and Issac Schleuter

In this episode, the JavaScript Jabber panelists talk with Ben Coe, Aaron Abramov, and Issac Schleuter about test coverage and testing tools. They talk about the different tools and libraries that they have contributed to the coding community, such as NYC, conf, and Jest. They also discuss what test coverage is actually about and when using test coverage tools is necessary.

In particular, we dive pretty deep on:

• What have you contributed to the testing tools community?
• npm
• NYC tool and instanbul project
• conf
• Jest
• These libraries were developed to be easy and have “batteries included”
• False positives with test coverage
• Encourage testing practices that don’t practice in a superficial way
• Test coverage is about making sure you test every state a public API can get into
• Think through the test you’re writing first
• Barriers against testing
• Don’t spike the code too quickly
• Provides guardrails for newer developers to contribute to open source projects
• Use tests to understand the system
• How to spend your time better
• When you need tests
• Value is very short term
• TDD
• And much, much more!

Links:

• @BenjaminCoe
• @AaronAbramov_
• Issac’s GitHub

Picks:

Charles

• React Roundup
• Views on Vue
• Adventures in Angular
• React Dev Summit 2018

Aimee

• Galentine’s Day
• Dnote CLI

AJ

• The Hero of Ages by Brandon Sanderson

Corey

• We are hive project guidelines
• Tip: You can install node as a dependency on your project

Ben

• Hack Illinois 2018
• C8

Aaron

• Reason

Issac

• The Tap 100
• Krypton App
• Friendly Fire Podcasts

Panel:

• Charles Max Wood
• Aimee Knight
• Joe Eames
• Cory House
• AJ O'Neal

Special Guests: None

In this episode, the JavaScript Jabber panelists talk about React: The Big Picture, Cory’s course on Pluralsight and what React is all about. They discuss both the pros and cons when it comes to using React and when it would be the best to use this library. They also encourage programmers to use React in a more consistent way so that people can share components.

In particular, we dive pretty deep on:

• What is React: The Big Picture course?
• React
• The frameworks work with each other
• Reason and Elm
• How to decide when using React is the best option?
• React tradeoffs
• JavaScript
• React expects you to do a little more typing and work
• React is very close to JavaScript
• React pushes you towards a single file per component
• React Round Up
• Are the Code Mods as wonderful as they sound?
• Angular
• Create React App
• What are Code Mods?
• Lack of opinionated approach in React
• Using React in a more consistent way
• MobX and Redux
• Start off using just plain React
• When wouldn’t you want to use React?
• And much, much more!

Links:

• React: The Big Picture
• Cory’s Pluralsight
• Reason
• Elm
• React
• JavaScript
• React Round Up
• Create React App
• Angular
• MobX
• Redux
• Framework Summit 2018
• Angular: The Big Picture
• React Dev Summit

Picks:

Charles

• Hunting Hitler
• The Greatest Showman: Sing-a-long

Aimee

• “Why being a perfectionist is an obstacle (and how to beat it)” by Gui Fradin
• “How to understand the large codebase of an open-source project?” blog post

Joe

• Marital Bliss Card Game

AJ

• Pplwink.com

Panel: Charles Max Wood

Guest: Zachary Kessin

This week on My JavaScript Story, Charles speaks with Zachary Kessin. Zach is a web developer who has written Programming HTML5 Applications and Building Web Applications with Erlang. Currently, he works a lot with functional programming. He first got into programming because his mother used to write in Lisp and he earned his first computer by begging his relatives to help pitch in to get him one when he was seven. They talk about what led him to Erlang and Elm, why he wanted to be a programmer from a young age, and what he is most proud of in his career.

In particular, we dive pretty deep on:

• JavaScript Jabber Episode 57
• JavaScript Jabber Episode 169
• Zach intro
• Elm and Erlang
• How did you first get into programming?
• Mother was writing Lisp when he was a kid
• RadioShack color computer
• Mother taught him Basic
• Pascal and AP Computer Science
• Studied CS originally in college and then switches to Physics
• First web app written in Pearl 4
• Did PHP for a living for a while and hated it
• Elm saves him time and effort
• What was it that made you want to program from a young age?
• Don’t be afraid to jump into programming at a late age
• Elm error messages
• Writes fewer tests in Elm code that JS code
• What are you most proud of?
• Loves mentoring
• Making a difference in the community
• It’s not just about the code, it’s about the people
• What are you doing now?
• And much, much more!

Links:

• JavaScript Jabber Episode 57
• JavaScript Jabber Episode 169
• Programming HTML5 Applications
• Building Web Applications with Erlang
• Elm
• Erlang
• Lisp
• Zach’s GitHub
• @zkessin
• Zach’s YouTube
• Zach’s LinkedIn

Picks

Charles

• Masterbuilt Smoker
• Crock-Pot

Zach

• If you like a book, tell the author!
• How to Get a Meeting with Anyone by Stu Heinecke
• 1177 B.C.: The Year Civilization Collapsed by Eric Cline

Panel:

• Charles Max Wood

Special Guests: Rachel MacFarlane and Matt Bierner

In this episode, the JavaScript Jabber panelists discuss Visual Studio Code with Rachel MacFarlane and Matt Bierner, who are both developers on Visual Studio Code. They talk about what the workflow at Visual Studio Code looks like, what people can look forward to coming out soon,  and how people can follow along the VS Code improvements on GitHub and Twitter. They also touch on their favorite extensions, like the Docker extension and the Azure extension and their favorite VS Code features.

In particular, we dive pretty deep on:

• Rachel and Matt intro
• Month to month workflow of Visual Studio Code
• VS Code JavaScript, TypeScript, and Mark Down support
• Working on GitHub and within the community
• Check out new features incrementally with insiders
• Community driven work
• What is coming out in Visual Studio Code?
• GitHub helps to determine what they work on
• Working on Grid View
• Improved settings UI
• Highlighting unused variables in your code
• Improvements with JS Docs
• Dart
• Visual Studio Extension API
• How do people follow along with the VS Code improvements?
• Follow along on GitHub and Twitter
• Download VS Code Insiders
• Have a general road map of what the plan is for the year
• Technical debt week
• What do you wish people knew about VS Code?
• Favorite extensions
• Docker extension and Azure extension
• And much, much more!

Links:

• Visual Studio Code
• JavaScript
• TypeScript
• Dart
• VS Code GitHub
• @Code
• VS Code Insiders
• Docker extension
• Azure extension
• Rachel’s GitHub
• Matt’s GitHub
• MattBierner.com
• @mattbierner

Sponsors

• Kendo UI
• Linode
• FreshBooks

Picks:

Charles

• Orphan Black
• Avengers: Infinity War
• Fishing

Rachel

• GitLens

Matt

• The Bronx Warriors

Panel: Charles Max Wood

Guest: Tracy Lee

This week on My Angular Story, Charles speaks with Tracy Lee. Tracy is the co-founder This Dot and her goal with it is to bring the JavaScript community together. She first got into programming when she tried to build websites for people and then was interested in learning JavaScript and really fell in love with the community. She really stayed with Angular because of the community she found there, the size of the community, and the fact that it gave her the ability to have a voice.

In particular, We dive pretty deep on:

• This Dot
• ContributorDays.com
• How did you first get into programming?
• Really loves community
• Angular community being so welcoming
• What made you pick the Angular community?
• Ember originally
• Loves how big the Angular community is
• Business background
• Loves the challenge of trying to create things
• On the RxJS Core team
• This Dot Media
• This Dot Labs
• Loves to builds brands and consult
• The importance of mentors
• Starting an apprentice program
• She loves being able to help others
• People underestimate the impact they have on the world
• AngularAir and JavaScript Air
• And much, much more!

Links:

• This Dot
• ContributorDays.com
• JavaScript
• Angular
• Ember
• RxJS Core Team
• This Dot Media
• This Dot Labs
• AngularAir
• JavaScriptAir
• Tracy’s Medium
• @LadyLeet
• LadyLeet.com
• DevChat.tv Youtube
• This Dot Media Youtube

Picks:

Charles

• Ready Player One by Ernest Cline
• Bad Lip Reading YouTube

Tracy

• Mermaid Tail Makeup Brushes
• Beauty Fix Box

Panel:

• Charles Max Wood
• Alyssa Nicholl
• Ward Bell

Special Guests: David Cramer

In this episode, the JavaScript Jabber panelists talk to David Cramer about error tracking and troubleshooting workflows. David is the founder and CEO of Sentry, and is a software engineer by trade. He started this project about a decade ago and it was created because he had customers telling him that things were broken and it was hard to help them fix it. They talk about what Sentry is, errors, workflow management, and more!

In particular, we dive pretty deep on:

• David intro
• Founder and CEO of Sentry
• What is Sentry?
• Working with PHP
• De-bugger for production
• Focus on workflow
• Goal of Sentry
• Triaging the problem
• Workflow management
• Sentry started off as an open-source side project
• Instrumentation for JavaScript
• Ember, Angular, and npm
• Got their start in Python
• Logs
• Totally open-source
• Most compatible with run-time
• Can work with any language
• Deep contexts
• Determining the root cause
• And much, much more!

Links:

• Sentry
• JavaScript
• Ember
• Angular
• npm
• Python
• Sentry’s GitHub
• @getsentry
• David’s GitHub
• David’s Website
• @zeeg

Sponsors

• Kendo UI
• FreshBooks
• Loot Crate

Picks:

Charles

• Socks as Swag

David

• VS Code
• Kubernetes

Panel:

• Charles Max Wood
• AJ ONeal

Special Guests: Kurt Mackey

In this episode, the JavaScript Jabber panel talks to Kurt Mackey about Fly.io. At Fly.io, they are "building a JavaScript platform that gives you the power to build your own CDN." They talk about how Fly.io came to fruition, how CDN caching works, and what happens when you deploy a Fly app. They also touch on resizing images with Fly, how you actually build JavaScript platforms using Fly, and more!

In particular, we dive pretty deep on:

• Fly.io
• Building a programmable CDN
• High level overview of Fly.io
• How did this project come together?
• CDNs didn’t work with dynamic applications
• Has been working on this since 2008
• Extend application logic to the “edge”
• Putting burden of JavaScript “nastiest” onto the web server
• Fly is the proxy layer
• Getting things closer to visitors and users
• CDN caching
• Cache APIs
• Writing logic to improve your lighthouse score
• Have you built in resizing images into Fly?
• Managing assets closer to the user
• Can you modify your own JavaScript files?
• What happens when you deploy a Fly app
• Having more application logic
• DOM within the proxy
• Ghost
• React and Gatsby
• Intelligently loading client JavaScript
• How do you build the JavaScript platform?
• And much, much more!

Links:

• Fly.io
• JavaScript
• Ghost
• Gatsby
• React
• @flydotio
• @mrkurt
• Kurt at ARS Technica
• Kurt’s GitHub

Sponsors

• Kendo UI
• Sentry
• Digital Ocean

Picks:

Charles

• GitLab

AJ

• Gitea
• Black Panther

Kurt

• Packet.net
• The Three-Body Problem by Cixin Liu

Panel:

• Aimee Knight
• Joe Eames
• AJ ONeal

Special Guests: Jeremy Fairbank

In this episode, the JavaScript Jabber panel talks to Jeremy Fairbank about his talk Practical Functional Programming. Jeremy is a remote software developer and consultant for Test Double. They talk about what Test Double is and what they do there and the 6 things he touched on in his talk, such as hard to follow code, function composition, and mutable vs immutable data. They also touch on the theory of unit testing, if functional programming is the solution, and more!

In particular, we dive pretty deep on:

• Jeremy intro
• Works for Test Double
• What he means by “remote”
• What is Test Double?
• They believe software is broken and they are there to fix it
• His talk - Practical Functional Programming
• The 6 things he talked about in his talk
• Practical aspects that any software engineer is going to deal with
• Purity and the side effects of programming in general
• Hard to follow code
• Imperative VS declarative code
• Code breaking unexpectedly
• Mutable data VS immutable data
• The idea of too much code
• Combining multiple functions together to make more complex functions
• Function composition
• Elm, Elixir, and F#
• Pipe operator
• Scary to refactor code
• Static types
• The idea of null
• The theory of unit testing
• Is functional programming the solution?
• His approach from the talk
• And much, much more!

Links:

• Test Double
• His talk - Practical Functional Programming
• Elm
• Elixir
• F#
• @elpapapollo
• jeremyfairbank.com
• Jeremy’s GitHub
• Jeremy’s YouTube

Sponsors

• Kendo UI
• Sentry
• Digital Ocean

Picks:

Aimee

• American Dollar
• Force with lease

AJ

• Superfight

Joe

• The 2018 Web Developer Roadmap by Brandon Morelli
• Svelte

Jeremy

• Programming Elm
• The Secrets of Consulting by Gerald M. Weinberg
• Connect.Tech

Panel:

• AJ O’Neal
• Joe Eames
• Jesse Sanders

Special Guest: Sean Hunter

In this episode, the panel talks with Sean Hunter who is a software developer, speaker, rock climber, and author of “Aurelia in Action” published by Manning Publications! Today, the panelists and Sean talk about Aurelia and other frameworks. Check it out!

Show Topics:

0:00 – Advertisement: KENDO UI

0:38 – Joe: Hello! Our panelists are AJ, Jesse, myself, and our special guest is Sean Hunter (from Australia)! What have you been doing with your life and what is your favorite movie?

1:45 – Guest talks about Vegemite!

2:20 – Guest: I was in the UK and started using Aurelia, which I will talk about today. I have done some talks throughout UK about Aurelia. Also, the past year moved back to Australia had a baby son and it’s been a busy year. Writing a book and being a new parent has been hard.

3:22 – Panel: Tell us the history of Aurelia, please?

3:31 – Panel: Is it like jQuery, React, Vue or what?

3:44 – Guest: Elevator pitch – Aurelia is a single-page app framework! It’s most similar to Vue out of those frameworks; also, similarities to Ember.js.

4:30 – Guest goes into detail about Aurelia.

6:15 – Panel: It sounds like convention over configuration.

6:42 – Guest: Yes that is correct.

7:21 – Panel: Sounds like there is a build-step to it.

7:39 – Guest: There is a build-step you are correct. You will use Webpack in the background.

9:57 – The guest talks about data binding among other things.

10:30 – Guest: You will have your app component and other levels, too.

10:37 – Panel: I am new to Aurelia and so I’m fresh to this. Why Aurelia over the other frameworks? Is there a CLI to help?

11:29 – Guest: Let me start with WHY Aurelia and not the other frameworks. The style that you are using when building the applications is important for your needs. In terms of bundling there is a CUI and that is a way that I prefer to start my projects. Do you want to use CSS or Webpack or...? It’s almost a wizard process! You guys have any questions about the CLI?

14:43 – Panel: Thanks! I was wondering what is actually occurring there?

15:25 – Guest: Good question. Basically it’s that Aurelia has some built-in conventions. Looking at the convention tells Aurelia to pick the Vue model by name. If I need to tell the framework more information then...

17:46 – Panel: I think that for people who are familiar with one or more framework then where on that spectrum would Aurelia fall?

18:20 – Guest: It’s not that opinionated as Ember.js.

19:09 – Panel: Talking about being opinionated – what are some good examples of the choices that you have and how that leads you down a certain path? Any more examples that you can give us? 

19:38 – Guest: The main conventions are what I’ve talked about already. I can’t think of more conventions off the top of my head. There are more examples in my book.

20:02 – Panel: Your book?

20:10 – Guest: Yep.

20:13 – Panel.

20:20 – Guest. 

21:58 – Panel: Why would I NOT pick Aurelia?

22:19 – Guest: If you are from a React world and you like having things contained in a single-file then Aurelia would fight you. If you want a big company backing then Aurelia isn’t for you.

The guest goes into more reasons why or why not one would or wouldn’t want to use Aurelia.

24:24 – Panel: I think the best sell point is the downplay!

24:34 – Guest: Good point. What does the roadmap look like for Aurelia’s team?

25:00 – Guest: Typically, what happens in the Aurelia framework is that data binding (or router) gets pushed by the core team. They are the ones that produce the roadmap and look forward to the framework. The core team is working on the NEXT version of the framework, which is lighter, easier to use, and additional features. It’s proposed to be out for release next year.

26:36 – Advertisement – Sentry.io

27:34 – Panel: I am going to take down the CLI down and see what it does. I am looking at it and seeing how to teach someone to use it. I am using AU, new command, and it says no Aurelia found. I am stuck.

28:06 – Guest: What you would do is specify the project name that you are trying to create and that should create it for you. 

28:40 – Panel.

28:45 – Panel.

28:50 – Panel: Stand up on your desk and say: does anyone know anything about computers?!

29:05 – Panelists go back-and-forth.

29:13 – Panel: What frameworks have you used in the past?

29:17 – Guest: I was using single-paged apps back in 2010.

31:10 – Panel: Tell us about the performance of Aurelia?

31:17 – Guest: I was looking at the benchmarks all the time. Last time I looked the performance was comparable. Performances can me measured in a number of different of ways.

The guest talks about a dashboard screen that 20 charts or something like that. He didn’t notice any delays getting to the client.

33:29 – Panel: I heard you say the word “observables.”

33:39 – Guest answers the question.

35:30 – Guest: I am not a Redux expert, so I really can’t say. It has similar actions like Redux but the differences I really can’t say.

36:11 – Panel: We really want experts in everything! (Laughs.)

36:25 – Panelist talks about a colleagues’ talk at a conference. He says that he things are doing too much with SPAs. They have their place but we are trying to bundle 8-9 different applications but instead look at them as...

What are your thoughts of having multiple SPAs?

37:17 – Guest.

39:08 – Guest: I wonder what your opinions are? What about the splitting approach?

39:22 – Panel: I haven’t looked at it, yet. I am curious, though. I have been developing in GO lately.

40:20 – Guest: I think people can go too far and making it too complex. You don’t want to make the code that complex.

40:45 – Panel: Yeah when the code is “clean” but difficult to discover that’s not good.

41:15 – Guest: I agree when you start repeating yourself then it makes it more difficult.

41:35 – Panel: Chris and I are anti-framework. We prefer to start from a fresh palette and see if a framework can fit into that fresh palette. When you start with a certain framework you are starting with certain configurations set-in-place. 

42:48 – Joe: I like my frameworks and I think you are crazy!

43:05 – Panel.

43:11 – Joe: I have a love affair with all frameworks.

43:19 – Panel: I think I am somewhere in the middle.

43:49 – Panel: I don’t think frameworks are all bad but I want to say that it’s smart to not make it too complex upfront. Learn and grow.

44:28 – Guest: I think a good example of that is jQuery, right?

45:10 – Panelist talks about C++, jQuery, among other things.

45:34 – Guest: Frameworks kind of push the limits.

46:08 – Panelist talks about JavaScript, frameworks, and others.

47:04 – Panel: It seems simple to setup routes – anything to help with the lazy way to setup?

47:35 – Guest answers question.

48:37 – Panel: How do we manage complexity and how does messaging work between components?

48:54 – Guest: The simple scenario is that you can follow a simple pattern, which is (came out of Ember community) and that is...Data Down & Actions Up!

50:45 – Guest mentions that Aurelia website!

51:00 – Panel: That sounds great! Sounds like the pattern can be plugged in easily into Aurelia.

51:17 – Picks!

51:20 – Advertisement: Get A Coder Job!

END – Advertisement: CacheFly!

Links:

• JavaScript
• React
• Redux
• Webpack
• Elixir
• Ember.js
• Vue
• GO
• jQuery
• Node.js
• Puppeteer
• Cypress
• Utah JS 2018 – Justin McMurdie’s Talk
• Aurelia
• Sean Hunter’s Book!
• Sean Hunter’s Twitter
• Sean Hunter’s Website
• Sean Hunter’s GitHub

Sponsors:

• Kendo UI
• Sentry
• CacheFly

Picks:

Joe

• React Conf.
• Endless Quest

AJ

• Extreme Ownership
• GO Language
• Harry’s and Flamingo

Jesse Sanders

• The Miracle Morning
• React Hooks
• Apple Products

Sean

• Doesn’t Have to Be Crazy at Work
• Discount Code for Aurelia in Action -  hunterpc (40% off Aurelia in Action, all formats)
• Apple Watch

Sponsors

• KendoUI

• Sentry use the code “devchat” for $100 credit

• Clubhouse

Panel

• AJ O’Neal

• Chris Ferdinandi

• Charles Max Wood

Joined by special guest: Phil Hawksworth and Divya Sasidharan

Episode Summary

This episode features special guests Philip Hawksworth and Divya Sasidharan. Phil lives just outside of London and Divya lives in Chicago, and both of them work for Netlify. Divya is also a regular on the Devchat show Views on Vue. The panelists begin by discussing what JAMstack is. JAM stands for JavaScript, API, and Markup. It used to be known as the new name for static sites, but it’s much more than that. Phil talks about how dynamic ‘static’ sites really are. JAMstack sites range from very simple to very complex, Static is actually a misnomer. JAMstack makes making, deploying, and publishing as simple as possible.

The panelists discuss the differences between building your own API and JAMstack and how JavaScript fits into the JAMstack ecosystem. They talk about keys and secrets in APIs and the best way to handle credentials in a static site. There are multiple ways to handle it, but Netlify has some built in solutions. All you have to do is write your logic for what you want your function to do and what packages you want included in it, they do all the rest. Every deployment you make stays there, so you can always roll back to a previous version.

Charles asks about how to convert a website that’s built on a CMS to a static site and some of the tools available on Netlify. They finish by discussing different hangups on migrating platforms for things like Devchat (which is built on WordPress) and the benefits of switching servers.

Links

• API

• React

• JAMstack

• CMS (content management system)

• CDM (Customer Data Management)

• Markup

• UI (User Interface)

• Jekyll

• Progressive Enhancement

• 11ty

• Hugo

• React Static

• Gatsby

• Vue

• AWS

• AWS Lambda

• Azure

• Markdown

• WordPress

• Zapier

• Stefan Baumgartner article

• RSS feed

Picks

AJ O’Neal:

• Prince Ali Ababwa (Aladdin)

• Node v.10.12

Chris Ferdinandi:

• Bouncer

• Philip Morgan Consulting

• Jonathan Stark Consulting

Charles Max Wood:

• Mastadon Social

• Thanksgiving turkey

Phil Hawksworth:

• Dripping (solidified meat drippings spread on toast)

• They Shall Not Grow Old

Divya Sasidharan:

• Fear, Trust, and JavaScript

• Women’s Pockets Are Inferior

• Debt: A Love Story

Sponsors

• KendoUI
• Sentry use the code "devchat" for $100 credit
• Clubhouse
• CacheFly

Panel

Aimee Knight

Aaron Frost

Chris Ferdinandi

Joe Eames

Special Guest: Ryan Duffy 

In this episode of JavaScript Jabber, the panelists talk with Ryan Duffy who works on the EnactJS framework at LG Electronics. Ryan explains the framework in depth and answers all the questions about its design and implementation from the panelists and discusses some challenges faced along the way. Check it out!

Show Notes:

00:28 – Advertisement - KendoUI

1:08 - Ryan introduces himself and explains a bit about the EnactJS framework. While giving some background, he says that it is the 3rd generation of web frameworks that supports apps on webOS and they started building Enact on top of React about two years ago.

2:00 - Aimee asks what exactly does webOS mean. Ryan answers that webOS was created by Palm for phones and related devices and it has several instances of chromium running on device with some service layer stuff.

2:36 - Aaron mentions that webOS was big when other operating systems were still coming up, and Ryan agrees saying that it didn’t get the adoption needed to make it successful later.

3:00 - Ryan says that he always loved building apps for webOS phones given the flexibility and ease coming from a web development background.

3:53 - Aaron asks on which other applications is webOS running other than TV. Ryan answers that TV is one of the major consumptions, and it also runs on certain robots such as the concierge ones, watches to some extent and a lot of projects internally, not yet released in the market.

4:50 - Aaron asks if the Enact framework is big internally at LG. Ryan replies that it is the primary framework used for apps running on webOS.

5:03 - Aaron enquires about the nature of adoption of Enact for third party or non-LG people, to which Ryan states that Enact remains the standard framework for people who are building apps.

5:32 - Joe joins in the conversation.

6:25 - Aaron remarks that given that webOS is used in latest robots, televisions, watches and other such apps, it sounds like they are heavily investing into it. Ryan affirms by saying that the webOS journey goes from Palm phones to HP tablets to finally coming to LG. He goes on to explain their team structure, stating that there are two major teams in play right now - the R&D team is in the US and the implementation team is in Korea.

8:00 - Aaron asks about the role their team plays in the app development. Ryan replies that his team is the stack team that forms the foundation for the apps and they take decisions on what the components should look like and similar tasks. The app teams based in Korea decide their menu based on those decisions.

8:35 - Aaron asks what exactly is meant by the Blink team. Ryan answers that the it’s the team that works with an LG customized version of chromium.

9:10 – Aaron then asks about his individual role in the team. Ryan says that he is one of the managers of the stack team and he’s been on the team for little more than 4 years.

9:30 - Aaron asks about the evolution of the framework over time. Ryan describes the historical background by saying that in the initial Enyo design the team built, was component based, and every tool needed to build single page apps had to be developed from scratch. He says that they felt the need to move on to an improved framework as they wanted to take advantage of the robust ecosystem that existed, so they ported component libraries of Enyo using the React toolset to form Enact.

11:43 - Aaron asks if Enyo then ceased to exist to which Ryan states that it is still around to some extent.

12:20 - Aaron asks if the team has something like “create Enact app” to create a new app internally, like React. Ryan mentions that Jason - a tooling and automation expert from their team has built a feature called V8 snapshot - which loads JavaScript into memory and takes a snapshot - can in turn be loaded by the TV to launch the app in order to achieve a faster load time. He says that their long-term goal is to increase compatibility with the ecosystem.

14:40 - Aaron asks if he can use the React CLI to create something for TV as a third-party developer. Ryan elaborates that CLI can be used to build, compile and bundle apps and there is another tool- SDK to bundle it for delivery to the TV. The app is tested fully in chrome, bundled and deployed to the TV.

15:25 - Aaron asks if choosing React was a natural decision for the team. Ryan explains that they researched on some component-based frameworks that were available at that time and found that React was the best choice.

17:30 - Aimee asks the reason for open sourcing the framework. Ryan mentions that Enyo always has been open source. He also remarks that the team does not get a lot of input from the community and would like to get more information about what’s working and what’s not and how they can contribute back.

19:40 - Aaron asks about the kind of apps can be built by using Enact except for TV. Ryan says that any kind can be built but the hesitation is that the UI library is specially designed for TV, so they may look different for other spaces like phones or other devices.

20:35 – Advertisement – Sentry – Use the code “devchat” to get two months free on Sentry’s small plan.

21:30 - Aaron asks what decisions around making apps are made by Enact for the developers. Ryan explains that the architectural pattern they have chosen is higher order components, and there is a lot of attention on render props that can be easily plugged into the apps.

22:48 - Aaron asks if the state part was built by the team on their own. Ryan answers in affirmative that everything in Enact is completely built by the team, no external states are used within the framework. No decisions are made in the data space yet. He mentions that they had tried to limit their Enact development effort in cases where the solution was already available unless they had a new perspective on the problem.

24:30 - Aaron remarks the idea of Enact being something like a webpack is becoming clearer for him and asks Ryan if his team is spending most of their time in building component libraries. Ryan affirms by explaining that Enact is designed in layers. He goes on to explain that focus management is a difficult problem to solve where the ability to navigate an application intuitively such as in the case of remote control is handled by a certain component. Also, as LG ships TVs all over the world, there are significant internationalization requirements. He then elucidates the TV centric moonstone library in detail and states that they took all the base capabilities from it and formed a UI layer.

27:26 - Aaron asks if moonstone is theme-able. Ryan says that it’s not and the UI layer in not styled.

28:40 - Chris asks, as someone who manages open source projects and builds tools, about the process of making decisions on the kind of components to include and challenges Ryan and his team faced in the open source space.

29:45 – Ryan says that they haven’t had the ideal open source experience yet. They do have a lot of discussions on API design and components but it’s a struggle to what to include and what to not.

31:25 - Chris shares his own experience while stating that finding a common ground is always hard especially when there is internal resistance in convincing people to use new software. Ryan says that internally their biggest struggle is that a group of people use the Qt platform and there is chunk of webOS that is built on it and not on Enact. Trying to convince people to do the migration from Enyo to Enact was difficult but they have had most success in trying to eliminate friction and it was easier in the sense that there weren’t any required parameters for things.

36:05 – Aaron states that all his questions are answered and his understanding of Enact is clear.

36:21 – Advertisement  - Clubhouse

37:10 – Picks!

43:41- END – Advertisement - CacheFly!

Picks

Joe

• Monsters of Feyland

Chris

• Presentation by Eric Bailey on Accessibility - If its interactive, it needs a focus style
• Jimu Robots
• Wall-E

Aimee

• Coworkers at NPM

Aaron

• Pierogi
• The Cursed Child

Ryan

• EnactJS
• Thinking, Fast and Slow
• Firefox DevTools

Sponsors

• Triplebyte
• Sentry use the code “devchat” for $100 credit
• Clubhouse
• CacheFly

Panel

• Aaron Frost
• AJ O’Neal
• Chris Ferdinandi
• Joe Eames
• Aimee Knight
• Charles Max Wood

Joined by special guests: Hillel Wayne and Richard Feldman

Episode Summary

In this episode of JavaScript Jabber, Hillel Wayne kicks off the podcast by giving a short background about his work, explains the concepts of formal methods and the popular npm package - event-stream, in brief. The panelists then dive into the recent event-stream attack and discuss it at length, focusing on different package managers and their vulnerabilities, as well as the security issues associated with them. They debate on whether paying open source developers for their work, thereby leading to an increase in contribution, would eventually help in improving security or not. They finally talk about what can be done to fix certain dependencies and susceptibilities to prevent further attacks and if there are any solutions that can make things both convenient and secure for users.

Links

• STAMP model in accident investigation
• Hillel’s Twitter
• Hillel’s website
• Richard’s Twitter
• Stamping on Event-Stream

Picks

Joe Eames:

• Stuffed Fables

Aimee Knight:

• SRE book - Google
• Lululemon leggings
• DVSR - Band

Aaron Frost:

• JSConf US

Chris Ferdinandi:

• Paws New England
• Vanilla JS Guides

Charles Max Wood:

• Sony Noise Cancelling Headphones
• KSL Classifieds
• Upwork

Richard Feldman:

• Elm in Action
• Sentinels of the Multiverse

Hillel Wayne:

• Elm in the Spring
• Practical TLA+
• Nina Chicago - Knitting
• Tomb Trader

Sponsors

• Sentry use the code “devchat” for 2 months free on Sentry small plan
• CacheFly 

Host: Charles Max Wood

Special Guest: Isaac Schlueter

Episode Summary

In this episode of My JavaScript Story, Charles Max Wood hosts Isaac Schlueter, co-founder and Chief Product Officer at NPM.

Listen to Isaac’s journey as a developer on the podcast My Java Story on this episode and on the podcast My Angular Story on this episode.

Isaac recently switched roles from Chief Executive Officer to Chief Product Officer, he explains the reasoning behind this switch. He talks about NPM Enterprise and its value proposition. He talks about projects he is working on currently and also the future of NPM. He also talks about the current available positions at NPM, both in Oakland, CA and remote.

Links

• My JavaScript Story Isaac Schlueter
• My Angular Story Isaac Schlueter
• JavaScript Jabber Node & NPM with Isaac Schlueter
• Isaac's Twitter
• NPM's Twitter
• NPM's blog
• NPM website
• https://devchat.tv/my-javascript-story/

Picks

Isaac Schlueter:

• Ink
• Umbrella Academy Netflix
• I Love Hue
• Do By Friday

Charles Max Wood:

• The Expanse (TV Series)
• The Travelers (TV Series)
• Podfest Multimedia Expo
• Netlify
• Eleventy
• We're Alive
• Charles’ Personal Blog
•  

Sponsors

• Sentry use code “devchat” for 2 months free

• Triplebyte $1000 signing bonus

Panel

• Charles Max Wood

• Aimee Knight

• Chris Ferdinandi

• AJ O’Neal

• Joe Eames

Joined by Special Guest: Chris DeMars

Episode Summary

Special guest Chris DeMars is from Detroit, MI. Currently, he works for Tuft and Needle and is an international speaker, Google developer expert, Microsoft mvp, and web accessibility specialist. He comes from a varied work background, including truck driving and other non-tech jobs.

Today the panel discusses web accessibility for people with disabilities. According to a study done by WebAIM, 97.8% of homepages tested had detectable WCAG 2 failures. The panel discusses why web accessibility is doing so poorly. Chris talks about some of the biggest mistakes he sees and some very simple fixes to make sites more accessible. Chris talks about the importance of manual testing on screen readers and emphasizes that it is important to cover the screen to make sure that it really works with a screen reader. Chris talks about some of the resources available for those who wish to increase accessibility on their sites.

The team discusses tactics for prioritizing accessibility and if there is a moral obligation to make sites accessible to those with disabilities. Chris talks about his experience making accessibility a priority for one of the companies he worked for in the past. They discuss the futue of legal ramifications for sites that do not incorporate accessibility, and what responsibility falls on the shoulders of people who regularly use assistive devices to notify companies of issues. They finish the show with resources available to people who want to learn more.

Links

• The DOM

• Semantic markup writings

• Alt attribute

• Axe by DeQue

• Bootstrap

• Aria lable

• WebAim study

Follow DevChat on Facebook and Twitter

Picks

Charles Max Wood:

• LootCrate

Aimee Knight:

• Implementing Git in Python tutorial

Chris Ferdinandi:

• "Fighting Uphill" by Eric Bailey

• “The Web We Broke” by Ethan Marcotte

• AllBirds sneakers

• Newsletter

AJ O’Neal:

• Golang Channel vs Mutex vs WaitGroup

• Nobuo Uematsu

• The Best Way to Tin Enameled Wire

Joe Eames:

• Gizmos board game

• Thinkster.io accessibility course (not released yet)

Chris DeMars:

• Dixxon Flannel Company

• Aquis.com accessibility simulator

• Refactr accessibility workshop in June

• Follow Chris

Sponsors

• Triplebyte offers a $1000 signing bonus
• Sentry use the code “devchat” for $100 credit
• Linode
• CacheFly

Panel

• Charles Max Wood
• Aimee Knight
• AJ O’Neal
• Aaron Frost
• Joe Eames

Joined by Special Guest: Gareth McCumskey

Summary

Gareth McCumskey introduces JAMstack and serverless. He goes into great detail on how it works. Aimee Knight and Aaron Frost voice their concerns about going serverless. Aimee thinks it feels dirty. Aaron has concerns about the code, is it actually easier, what use cases would he use it for, and does it actually save money. Gareth addresses these concerns and the rest of the panel considers the positive and negatives of using JAMstack and serverless. Charles Max Wood asks for specific use cases; Gareth supplies many uses cases and the benefits that each of these cases.

Links

• http://herodev.com/
• https://thinkster.io/
• https://jamstack.org/
• https://www.mongodb.com/cloud/stitch
• https://expatexplore.com/
• https://serverless.com/
• https://www.cloud66.com/
• https://aws.amazon.com/dynamodb/
• https://twitter.com/garethmcc
• https://www.facebook.com/javascriptjabber
• https://twitter.com/JSJabber

Picks

Charles Max Wood:

• Join the mailing list
• Watch out for new podcasts
• Send me defunct podcasts you love chuck@devchat.tv

Aimee Knight:

• Productivity Isn’t About Time Management. It’s About Attention Management.
• Quest Nutrition Protein Bars

AJ O’Neal:

• Distant Worlds: Music from Final Fantasy by Nobuo Uematsu
• Legend Of Zelda Concert 2018 Original Soundtrack by Never Land Orchestra  
• How to Diagnose and Fix Everything Electronic by Michael Jay Geier  

Aaron Frost:

• The Go-Giver, Expanded Edition: A Little Story About a Powerful Business Idea

Gareth McCumskey:

• https://www.finalfantasyxiv.com/
• Steam Play on Linux

Joe Eames:

• Expanding your horizons
• Seven Languages in Seven Weeks: A Pragmatic Guide to Learning Programming Languages
• Seven More Languages in Seven Weeks: Languages That Are Shaping the Future
• https://elm-lang.org/

Episode Summary

Rachel Roumeliotis and Roger Magoulas from O'Reilly Media join Charles Max Wood at OSCON to talk about the process of content development for OSCON. Rachel is the Vice President of Content Strategy at O'Reilly and Roger is Vice President of Radar at O'Reilly.

Rachel and Roger talk about the history of OSCON Conference as well as the key technologies they wanted to cover this year such as Artificial Intelligence, Machine Learning and Cloud-Native applications.

They then talk about the future of OSCON and the highlights they wat to cover next year such as security.

Sponsors

• Sentry use the code “devchat” for 2 months free on Sentry small plan

• Adventures in DevOps

• Adventures in Blockchain

• CacheFly

Host: Charles Max Wood

Joined by Special Guests: Rachel Roumeliotis and Roger Magoulas

Links

• Rachel's LinkedIn

• Roger's LinkedIn

• Open Source & Software Development| O'Reilly OSCON

• O'Reilly Radar

• O'Reilly Media - Technology and Business Training

   

Charles Max Wood talks to Filipa Lacerda in this week's My JavaScript Story. Filipa has been working as a front end engineer since 2011 and she currently works at GitLab.

Filipa originally wanted to study Economy but when she got to university she decided to major in Communications thinking it would be a lot more about communication and not as much about coding. At first she really didn't like the coding aspect of it but then as time went by she actually started to enjoy coding.

When she first started working she started out on the User Experience side, but then she wanted to switch to building stuff with code because she wanted to see results really fast and enjoyed that aspect of coding.

Charles asks why she stuck with that degree instead of switching it and Filipa explains that at first because she didn't want to go back and re - take the exams and also decided that this degree offered many job opportunities in many different industries and now she can't imagine herself doing anything else.

Filipa then talks about why she is working with Vue and all the different kind of projects she has done using Vue as well as what working for GitLab looks like on a day to day basis.

Host: Charles Max Wood

Joined by Special Guest:  Filipa Lacerda

Links

• https://devchat.tv/views-on-vue/vov-025-gitlabs-journey-with-vue-with-filipa-lacerda-and-jacob-schatz/

• https://devchat.tv/views-on-vue/vov-009-building-modal-component-with-filipa-lacerda/

• https://filipa.gitlab.io/

• https://twitter.com/FilipaLacerda

Sponsors

• Sentry use the code “devchat” for 2 months free on Sentry small plan

• Adventures in .NET

• Elixir Mix

• CacheFly

Picks

Filipa Lacerda:

• Why We Sleep by Walker PhD, Matthew

Charles Max Wood:

• RxJS Live: Conference

• Nikon D5600 Camera

• RØDE Microphones

Gant Laborde is the Chief Innovation Officer of Infinite Red who is working on a course for beginners on machine learning. There is a lot of gatekeeping with machine learning, and this attitude that only people with PhDs should touch it. In spite of this, Gant thinks that in the next 5 years everyone will be using machine learning, and that it will be pioneered by web developers. One of the strong points of the web is experimentation, and Gant contrasts this to the academic approach. 

They conversation turns to Gant’s course on machine learning and how it is structured. He stresses the importance of understanding unicode, assembly, and other higher concepts. In his course he gives you the resources to go deeper and talks about libraries and frameworks available that can get you started right away. His first lesson is a splashdown into the jargon of machine learning, which he maps over into developer terms. After a little JavaScript kung fu, he takes some tools that are already out there and converts it into a website.

Chris and Gant discuss some different uses for machine learning and how it can improve development. One of the biggest applications they see is to train the computers to figure monotonous tasks out while the human beings focus on other projects, such as watching security camera footage and identifying images. Gant restates his belief that in the next 5 years, AI will be everywhere. People will grab the boring things first, then they will go for the exciting things. Gant talks about his creation NSFW.js, an open source train model to help you catch indecent content. He and Chris discuss different applications for this technology.

Next, the panel discusses where machine learning can be seen in everyday life, especially in big companies such as Google. They cite completing your sentences in an email for you as an example of machine learning. They talk about the ethics of machine learning, especially concerning security and personal data. They anticipate that the next problem is edge devices for AI, and this is where JavaScript really comes in, because security and privacy concerns require a developer mindset. They also believe that personal assistant devices, like those from Amazon and Google, will become even more personal through machine learning. They talk about some of the ways that personal assistant devices will improve through machine learning, such as recognizing your voice or understanding your accent. 

Their next topic of discussion is authenticity, and how computers are actually incredibly good at finding deep fakes. They discuss the practice of placing passed away people into movies as one of the applications of machine learning, and the ethics surrounding that. Since developers tend to be worried about inclusions, ethics, and the implications of things, Gant believes that these are the people he wants to have control over what AI is going to do to help build a more conscious data set. 

The show concludes with Gant talking about the resources to help you get started with machine learning. He is a panelist on upcoming DevChat show, Adventures in Machine Learning. He has worked with people with all kinds of skill sets and has found that it doesn’t matter how much you know, it matters how interested and passionate you are about learning. If you’re willing to put the pedal to the metal for at least a month, you can come out with a basic understanding. Chris and Gant talk about Tensorflow, which helps you take care of machine learning at a higher level for fast operations without calculus. Gant is working on putting together a course on Tensorflow. If you’re interested in machine learning, go to academy.infinite.red to sign up for Gant’s course. He also announces that they will be having a sale on Black Friday and Cyber Monday.

Panelists

• Christopher Buecheler

With special guest: Gant Laborde

Sponsors

• React Round Up

• Sentry use the code “devchat” for 2 months free on Sentry’s small plan

• Adventures in Angular

Links

• Machine Learning: How To go from Zero to Hero

• NSFW.js

• Tensorflow.js

• PyTorch

• Keras

• Academy.infinite.red

• Gantlaborde.com 

Follow DevChatTV on Facebook and Twitter

Picks

Christopher Buecheler:

• Next.js

• Big Wreck, But For The Sun

Gant Laborde: 

• Nicornot.com

Free 5 day mini course on academy.infinite.red

Dean is a developer from Chicago and was previously on React Round Up 083. Today he has come over to JavaScript Jabber to talk about reactive programming and Storybook. Reactive programming is the opposite of imperative programming, where it will change exactly when needed instead of change only when told to. Reactivity existed long before React, and Dean talks about his history with reactive programming. He illustrates this difference by talking about Trello and Jira. In Trello, as you move cards from swimlane to another swimlane, everyone on the board sees those changes right away. In Jira,  if you have 11 tabs open, and you update data in one tab, probably 10 of your tabs are stale now and you might have to refresh. Reactive programming is the difference between Trello and Jira.

The panel discusses why reactive JavaScript is not more widely used. People now tend to look for more focused tools to solve a particular part of the problem than an all in one tool like Meteor.js. Dean talks about the problems that Storybook solves. Storybook has hot reloading environments in frontend components, so you don’t need the backend to run. Storybook also allows you to create a catalogue of UI states. JC and Dean talk about how Storybook could create opportunities for collaboration between engineers and designers. They discuss some causes of breakage that automation could help solve, such as styles not being applied properly and internationalization issues. Dean shares how to solve some network issues, such as having operators in RxJs. RxJs is useful for overlapping calls because it was built with cancelability from the beginning. 

Dean talks about his tool Storybook Animate, which allows you to see what the user sees. Storybook is an actively updated product, and Dean talks about how to get started with it. The show concludes with Dean talking about some things coming down the pipe and how he is actively involved in looking for good general solutions to help people write bulletproof code. 

Panelists

• JC Hiatt

With special guest: Dean Radcliffe

Sponsors

• Hasura, Inc.

• Sentry use the code “devchat” for 2 months free on Sentry’s small plan

• Adventures in Angular

________________________________________________________________________________________________________________________

"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

• RRU 083

• Knockout.js 

• Node.js

• Meteor.js

• RXJS

• Storybook Animate

• RX Helper library

Follow DevChatTV on Facebook and Twitter

Picks

JC Hiatt:

• Joker

• DevLifts

Dean Radcliffe: 

• Twitter @deaniusol and Github @deanius

• The Keyframers

• Action for Healthy Kids

Martin, Benjamin F., 1947-

MacFadyen, David, 1964-

Moon, Krystyn R., 1974-

Kaminsky, Joel S., 1960-

Konicek-Moran, Richard

Sachdev, Perminder

Betts, Dion E. (Dion Emile), 1963-

Kennedy, Theodore R., 1936-

Schwedt, Rachel E., 1944-

Flowers, Sarah, 1952-

Barrett, Paul W

Browne, Naima

Ellwanger, Steven J., 1971-

Florescu, Liviu C

Grinyer, Anne, 1950-

Ribbens McCarthy, Jane

Young, Vershawn Ashanti

Vitale, Joe, 1953-