Cover image of All JavaScript Podcasts by Devchat.tv
(225)

Rank #14 in Technology category

Technology
Software How-To
Tech News

All JavaScript Podcasts by Devchat.tv

Updated 13 days ago

Rank #14 in Technology category

Technology
Software How-To
Tech News
Read more

All JavaScript podcasts produced by Devchat.tv: - JavaScript Jabber - My JS Story - JS Rants

Read more

All JavaScript podcasts produced by Devchat.tv: - JavaScript Jabber - My JS Story - JS Rants

iTunes Ratings

225 Ratings
Average Ratings
145
65
5
3
7

Just shooting the breeze?

By Montaz Meah II - May 05 2018
Read more
I stopped after hearing 10 minutes of small talk which is really unhelpful to me.

Poorly executed

By Dig dog doo - Jan 10 2018
Read more
Came back to this show only to discover that is hardly has anything to do with JavaScript anymore, it features unvetted fake experts, and the host constantly interjects with stories about him. Also, the ads are prerecorded, you DO have a chance to edit them just a bit. The host is too lazy to edit the ads and fix misspoken words, then that says something about quality.

iTunes Ratings

225 Ratings
Average Ratings
145
65
5
3
7

Just shooting the breeze?

By Montaz Meah II - May 05 2018
Read more
I stopped after hearing 10 minutes of small talk which is really unhelpful to me.

Poorly executed

By Dig dog doo - Jan 10 2018
Read more
Came back to this show only to discover that is hardly has anything to do with JavaScript anymore, it features unvetted fake experts, and the host constantly interjects with stories about him. Also, the ads are prerecorded, you DO have a chance to edit them just a bit. The host is too lazy to edit the ads and fix misspoken words, then that says something about quality.
Cover image of All JavaScript Podcasts by Devchat.tv

All JavaScript Podcasts by Devchat.tv

Updated 13 days ago

Rank #14 in Technology category

Read more

All JavaScript podcasts produced by Devchat.tv: - JavaScript Jabber - My JS Story - JS Rants

Rank #1: JSJ 381: Building a Personal Brand with John Sonmez

Podcast cover
Read more

Sponsors

Panel

  • Charles Max Wood

  • Christopher Beucheler

  • AJ O’Neal

With Special Guest: John Somnez

Episode Summary

John is the founder of Bulldog Mindset andSimple Programmer, which teaches software developers soft skills, and the author of a couple books. He specializes in creating a personal brand and marketing. He addresses the rumors of him leaving software development and gives an introduction to marketing yourself as a software developer and its importance. The panel discusses their experience with consulting and how marketing themselves has paid off. John talks about the importance of having soft skills. In his opinion, the most important soft skills for programmers are communication, persuasion and influence, people skills and charisma. He talks about highlight those soft skills. The truth is, more and more people are hiring for people skills rather than technical skills. The panel discusses more about the importance of people skills.

John talks about ways to build your personal brand. One of the easiest ways is blogging but he talks about other methods like podcasts YouTube, writing books, and others. A key to building a personal brand is choosing something that you can become the best at, no matter how small it is. The panel shares their experiences of what things have gotten them attention and notoriety and talk about how other influential programmers got famous. They talk about interacting with central platforms like Medium and Github. Building a personal brand for software developers is the same as any other personal brand, such as having a consistent message, consistent logos and color schemes, and repeated exposure). Most people in the software world aren’t willing to do what’s necessary to build a personal brand, so it makes you stand out when you do it. John talks about the importance of controlling your image so that companies want to hire you. John gives a brief overview of his course How to Market Yourself as a Software Developer. 

Click here to cast your vote NOW for JavaScript Jabber - Best Dev Podcast Award

Links

Picks

Charles Max Wood:

John Somnez:

Christopher Beucheler:

AJ O’Neal

Aug 08 2019
1 hour 8 mins
Play

Rank #2: JSJ 270 The Complete Software Developers Career Guide with John Sonmez

Podcast cover
Read more

JSJ 270 The Complete Software Developers Career Guide with John Sonmez

This episode features a panel of Joe Eames, AJ O’Neal, as well as host Charles Maxwell. Special guest John Sonmez runs the website SimpleProgrammer.com that is focused on personal development for software developers. He works on career development and improving the non-technical life aspects of software developers. Today’s episode focuses on John’s new book The Complete Software Developers Career Guide.

Did the book start out being 700 pages?

No. My goal was 200,000 words. During the editing process a lot of questions came up, so pages were added. There were side sections called “Hey John” to answer questions that added 150 pages.

Is this book aimed at beginners?

It should be valuable for three types of software developers: beginner, intermediate, and senior developers looking to advance their career. The book is broken up into five sections, which build upon each other. These sections are: - How to get started as a software developer - How to get a job and negotiate salary - The technical skills needed to know to be a software developer - How to work as a software developer - How to advance in career

Is it more a reference book, not intended to read front to back?

The book could be read either way. It is written in small chapters. Most people will read it start to finish, but it is written so that you can pick what you’re interested in and each chapter still makes sense by itself.

Where did you come up with the idea for the book?

It was a combination of things. At the time I wanted new blog posts, a new product, and a new book. So I thought, “What if I wrote a book that could release chapters as blog posts and could be a product later on?” I also wanted to capture everything I learned about software development and put it on paper so that didn’t lose it.

What did people feel like they were missing (from Soft Skills) that you made sure went into this book?

All the questions that people would ask were about career advice. People would ask things regarding: - How do I learn programming? - What programming language should I learn? - Problems with co-workers and boss - Dress code

What do you think is the most practical advice from the book for someone just getting started?

John thinks that the most important thing to tell people is to come up with a plan on how you’re going to become educated in software development. And then to decide what you’re going to pursue. People need to define what they want to be. After that is done, go backwards and come up with a plan in order to get there. If you set a plan, you’ll learn faster and become a valuable asset to a team. Charles agrees that this is how to stay current in the job force.

What skills do you actually need to have as a developer?

Section 3 of the book answers this question. There was some frustration when beginning as a software developer, so put this list together in the book. - Programming language that you know - Source control understanding - Basic testing - Continuous integration and build systems - What kinds of development (web, mobile, back end) - Databases - Sequel

Were any of those surprises to you?

Maybe DevOps because today’s software developers need to, but I didn’t need to starting out. We weren’t involved in production. Today’s software developers need to understand it because they will be involved in those steps.

What do you think is the importance of learning build tools and frameworks, etc. verses learning the basics?

Build tools and frameworks need to be understood in order to understand how your piece fits into the bigger picture. It is important to understand as much as you can of what’s out there. The basics aren’t going to change so you should have an in depth knowledge of them. Problems will always be solved the same way. John wants people to have as few “unknown unknowns” as possible. That way they won’t be lost and can focus on more timeless things.

What do you think about the virtues of self-taught verses boot camp verses University?

This is the first question many developers have so it is addressed it in the book. If you can find a good coding boot camp, John personally thinks that’s the best way. He would spend money on boot camp because it is a full immersion. But while there, you need to work as hard as possible to soak up knowledge. After a boot camp, then you can go back and fill in your computer science knowledge. This could be through part time college classes or even by self-teaching.

Is the classic computer science stuff important?

John was mostly self-taught; he only went to college for a year. He realized that he needed to go back and learn computer science stuff. Doesn’t think that there is a need to have background in computer science, but that it can be a time saver.

A lot of people get into web development and learn React or Angular but don’t learn fundamentals of JavaScript. Is that a big mistake?

John believes that it is a mistake to not fully understand what you’re doing. Knowing the function first, knowing React, is a good approach. Then you can go back and learn JavaScript and understand more. He states that if you don’t learn the basics, you will be stunted and possibly solve things wrong. Joe agrees with JavaScript, but not so much with things algorithms. He states that it never helped him once he went back and learned it. John suggests the book Algorithms to Live By – teaches how to apply algorithms to real life.

Is there one question you get asked more than anything else you have the answer to in the book?

The most interesting question is regarding contract verses salary employment and how to compare them. It should all be evaluated based on monetary value. Salary jobs look good because of benefits. But when looking at pay divided by the hours of work, usually a salary job is lower paid. This is because people usually work longer hours at salary jobs without being paid for it.

What’s the best place for people to pick up the book?

simpleprogrammer.com/careerguide and it will be sold on Amazon. The book will be 99 cents on kindle – want it to be the best selling software development book ever.

Picks

Joe

Wonder Woman

AJ

The Alchemist

Charles

Artificial Intelligence with Python

John

Algorithms to Live by: The Computer Science of Human Decisions Apple Airpods

Links

Simple Programmer Youtube

Jul 18 2017
1 hour
Play

Rank #3: 159 JSJ Why JavaScript Is Hard

Podcast cover
Read more

02:54 - Everyone Gets It But Me

04:06 - Tools You “Need” to Know

06:29 - Clojures

07:39 - JavaScript as “Object-Oriented” vs “Event-Oriented”

09:30 - Code That Can’t Be Serialized or Deserialized

10:49 - Clojures (Cont’d)

14:32 - The DOM (Document Object Model)

19:52 - Math Is Hard

  • IEEE754 (Floating-Point Arithmetic)

22:39 - Prototypes

25:43 - Asynchronous Programming

32:23 - Browser Environments

34:48 - Keeping Up with JavaScript

35:46 - Node

  • Nesting
  • Context Switching

42:48 - UTF-8 Conversion

44:56 - Jamison’s Stack

Check out and sign up to get new on React Rally: A community React conference on August 24th and 25th in Salt Lake City, Utah!

Picks

Jason Orendorff: ES6 In Depth (Aimee)
Cat Strollers (Aimee)
Stephano Legacy of the Void (Joe)
A Gentleman's Guide to Love and Murder (Joe)
Gregor Hohpe: Your Coffee Shop Doesn’t Use Two-Phase Commit  (AJ)
Firefox OS (AJ)
Flame (AJ)
OpenWest 2015 (AJ)
801 Labs Hackerspace (AJ)
Stack Overflow Careers (AJ)
Dota 2 (Jamison)
Beats, Rye & Types Podcast (Jamison)
JS Remote Conf Talks (Chuck)
Workflowy (Chuck)

May 13 2015
58 mins
Play

Rank #4: JSJ 276: Vue.js with Maximilian Schwarzmüller

Podcast cover
Read more

JSJ 276: Vue.js with Maximilian Schwarzmüller         

This episode of JavaScript Jabber features panelists AJ O’Neal, Aimee Knight, and Charles Max Wood. They talk with special guest Maximilian Schwarzmüller about Vue.js. Tune in to find out more!

[00:02:21] Introduction to Maximilian

Maximilian lives in Germany and is a self-taught web developer. He mostly teaches web development on Udemy and his YouTube channel. Vue.js is just one topic that he teaches. He enjoys teaching and passing on information to other web developers: he believes it is the best thing you can do.

[00:03:10] What other courses do you teach?

He tries to cover basic web development topics. On Udemy Maximilian teaches Angular and generic JavaScript courses. He also teaches courses on Angular and Node.js. On his YouTube channel he teaches more back-end development and Node.js courses.

[00:04:00] Elevator Pitch for Vue.js

Vue.js is a new framework that is popular because it is similar to React but also has Angular features. It is easier to learn than React: not everything is in JavaScript and JXS is not included. It is more also flexible and has better performance than Angular 1. Vue.js is easier than Angular 2 both to learn and master. It is still a JavaScript framework, where developers build single page applications or drop in existing applications to enhance views, control parts of a page with JavaScript, get rid of jQuery, and have an easier time creating applications.

[00:05:10] What are some challenges people run into as they learn it?

If developers are brand new to Vue.js, getting started is easy. It has one thing that a lot of frameworks lack which is awesome documentation. Vuejs.org has a comprehension guide that makes getting started simple. There is a general idea that developers still need to learn of how to structure the app, which is similar to React. Developers have to learn how to build components which is used to build the application. The build template is where everything is controlled with Vue.js. JavaScript code is used as well as template syntax.

[00:06:27] So you build the template and then tell it how each part is supposed to behave with JavaScript?

Yes. To get started use Vue instances, which are JavaScript objects, control parts of the page and it is marked by an id on an HTML element. Then, write a Vue template, which is basically HTML code where extra features can be used to easily output a variable. It makes it much easier to control via Vue instance. Then add a code, add a method which changes the property of Vue instance. It works together and is easy to build up templates and control your page with Vue.

[00:11:12] Vue’s Advantages

That depends on the application. Vue.js is easier to learn, which is an advantage when trying to get new developers. The documentation on the website is excellent, which helps when learning the language. Vue also has it’s own single team that develops it’s products, such as the Vue Router and Vue X. It has better performance, but for extremely big projects Angular 4 may be better.

[00:13:38] Does Vue have routing in it?

Vue.js has its own router. The core Vue team develops it, which is a different package that is downloaded separately. The advantage to this is that if you don’t need the router, then you don’t have it in your bundle but can easily add it. Once it is added it integrates nicely.

[00:14:16] How does the Vue router compare to the React router?

The Vue router offers the same features as the React router: nested routes, passing parameters, route guards, etc. The Vue router integrates nicely into the Vue package. It also injects into every component you have and is very simple. All that has to be done is just to execute one line of code and then the router is in the project.

[00:17:10] How often is Vue.js upgraded and how hard is it to keep up?

Vue.js only has two versions. Upgrading from Vue 1 to Vue 2 is easy. The base syntax and framework is still the same, you just need to adjust and move on. Since Vue 2 they released bigger upgrades. There so far haven’t been any issues upgrading, they have added new features, and still use the old code.

[00:19:09] What is the feature with Vue as far as adoption goes?

It is hard to predict but there are indicators that Vue.js has a good future. Vue.js probably will not overtake Angular but it is becoming important for companies in Asia, which is an important market. They have developed an Ionic version of Vue.js. There has also been an ongoing trend on GitHub.

[00:21:20] Why do we keep having new frameworks and versions?

The language of JavaScript itself is seeing rapid development. New features have been added, new web technologies developed, etc. One reason is that developers do more on the web. They want easier ways of building applications. There is no perfect framework so there has to be tradeoffs between the frameworks. There is no perfect solution for every application so need a framework for every application.

[00:23:16] What is left undone in Vue.js?

It is complete as far as something can be complete. Developers are working on service rendering to improve search engine optimization and initial rendering performance. They are also working on progress web app support.

[00:28:02] What drives the way that Vue grows?

There is simplicity in their documentation. While the documentation is simple, the framework is also easy to learn. Maximilian believes that the reason Vue.js took off is because the documentation and framework work together nicely.

[00:31:19] What is going to keep Vue around?

The support is not based on corporation, but there is an Asian company that is developing a framework that uses Vue to with their own product. Because of this, can draw an assumption that they will keep Vue.js around. Vue.js also has a strong community and core team, giving it a good support system.

[00:34:15] What are people using if they want to use Native Apps but they want to use Vue?

They are having a hard time right now. Frameworks for Quasar and Weex are in the early stages. A Vue.js app needs to be built but there are packages that are working in that direction.

[00:37:25] How do you structure your Udemy courses and what do you think of that as a whole?

Maximilian started teaching Udemy courses about one and a half years ago. He really enjoys teaching. Each course follows a similar pattern. He starts with a rough topic, researches the topic to see what is in demand, and builds a course around projects. He then fits all the things he wants to teach into the project, plans the course curriculum, records and edits the lecture videos, and then finally releases the course.

[00:39:22] What do you get the most questions about with your Vue course?

Questions are mixed. Students dive into the course quickly but then pause. Most questions are about the basics. They usually have something to do with the first few sections of the course or setup problems.

Picks         

AJ:

Aimee:

Charles:

Max:

Links

Aug 29 2017
50 mins
Play

Rank #5: JSJ 269 Reusable React and JavaScript Components with Cory House

Podcast cover
Read more

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

Joe Eames

Aimee Knight

Charles Max Wood

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

Joe Eames

Aimee Knight

Charles Max Wood

Jul 11 2017
57 mins
Play

Rank #6: 225 JSJ Functional Programming with John A. De Goes

Podcast cover
Read more

03:08 - John A. De Goes Introduction

04:07 - PureScript

JavaScript Jabber Episode #189: PureScript with John A. De Goes and Phil Freeman

04:58 - “Purely Functional”

09:18 - Weaknesses With Functional Programming

14:36 - Organizing a FP Codebase

17:54 - Beginners and Functional Programming; Getting Started

  • Learning About the History of Functional Programming
  • Hiring Junior Devs to do FP

28:20 - The Rise of Functional Programming in JavaScript-land

32:08 - Handling Existing Applications

36:03 - Complexity Argument

41:53 - Weighing Language Tradeoffs; Alt.js


Picks

Aug 17 2016
56 mins
Play

Rank #7: JSJ 329: Promises, Promise.finally(), and Async/await with Valeri Karpov

Podcast cover
Read more

Panel:

  • Charles Max Wood
  • AJ O’Neal
  • Aimee Knight

Special Guests: Valeri Karpov 

In this episode, the panel talks with programmer, Valerie Karpov from Miami, Florida. He is quite knowledgeable with many different programs, but today’s episode they talk specifically about Async/Await and Promise Generators. Val is constantly busy through his different endeavors and recently finished his e-book, “Mastering Async/Await.” Check-out Val’s social media profiles through LinkedIn, GitHub, Twitter, and more.

Show Topics:

1:20 – Val has been on previous episodes back in 2013 & 2016.

1:37 – Val’s background. He is very involved with multiple companies. Go checkout his new book!

2:39 – Promises generators. Understand Promises and how things sync with Promises. Val suggests that listeners have an integrated understanding of issues like error handling.

3:57 – Chuck asks a question.

6:25 – Aimee’s asks a question: “Can you speak to why someone would want to use Async/Await?”

8:53 – AJ makes comments.

10:09 – “What makes an Async/Await not functional?” – Val

10:59 – “What’s wrong with Promises or Async/Await that people don’t like it?” - AJ

11:25 – Val states that he doesn’t think there really is anything wrong with these programs it just depends on what you need it for. He thinks that having both gives the user great power.

12:21 – AJ’s background is with Node and the Python among other programs.

12:55 – Implementing Complex Business Logic.

15:50 – Val discusses his new e-book.

17:08 – Question from Aimee.

17:16 – AJ answers question. Promises should have been primitive when it was designed or somewhat event handling.

17:46 – The panel agrees that anything is better than Call Backs.

18:18 – Aimee makes comments about Async/Await.

20:08 – “What are the core principles of your new e-book?” – Chuck

20:17 – There are 4 chapters and Val discusses, in detail, what’s in each chapter.

22:40 – There could be some confusion from JavaScript for someone where this is their first language. Does Async/Await have any affect on the way you program or does anything make it less or more confusing in the background changes?

24:30 – Val answers the before-mentioned question. Async/Await does not have anyway to help with this (data changes in the background).

25:36 – “My procedural code, I know that things won’t change on me because it is procedural code. Is it hard to adjust to that?” – AJ

26:01 – Val answers the question.

26:32 – Building a webserver with Python

27:31 – Aimee asks a question: “Do you think that there are cases in code base, where I would want to use Promises? Not from a user’s perspective, but what our preferences are, but actual performance. Is there a reason why I would want to use both or be consistent across the board?”

28:17 – Val asks for some clarification to Aimee’s question.

29:14 – Aimee: “My own personal preference is consistency. Would I want to use Promises in ‘x’ scenario and/or use Async/Await in another situation?”

32:28 – Val and AJ are discussing and problem solving different situations that these programs

33:05 – “When would you not want to use Async/Await?” – AJ

33:25 – Val goes through the different situations when he would not use Async/Await. 

33:44 – Chuck is curious about other features of Async/Await and asks Val.

36:40 – Facebook’s Regenerator

37:11 – AJ: “Back in the day, people would be really concerned with JavaScript’s performance even with Chrome.” He continues his thoughts on this topic.

38:11 – Val answers the AJ’s question.

39:10 – Duck JS probably won’t include generators.

41:18 – Val: “Have anyone used Engine Script before?” The rest of the panel had never heard of this before.

42:09 – Windows Scripting Host

42:56 – Val used Rhino in the past.

43:40 – Val: “Going back to the web performance question...”

47:08 – “Where do you see using Async/Await the most?” – Chuck

47:55 – Val uses Async/Await for everything on the backend because it has made everything so easy for him.

48:23 – “So this is why you really haven’t used Web Pack?” – AJ

49:20 – Let’s go to Aimee’s Picks!

50:18 – AJ’s story, first, before we get to Promises.

54:44 – Let’s transition to Promises Finally.

54:53 – Val talks about Promises Finally.

59:20 – Picks

Links:

Sponsors:

Picks:

Charles

Aimee

AJ

Val

Sep 04 2018
1 hour 8 mins
Play

Rank #8: JSJ 304: React: The Big Picture

Podcast cover
Read more

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:

Picks:

Charles

Aimee

Joe

AJ

Mar 13 2018
51 mins
Play

Rank #9: JSJ 291: Serverless For JavaScript with Gareth McCumskey

Podcast cover
Read more

Panel:

Charles Max Wood 

Aimee Knight

AJ O’Neal

Joe Eames 

Special Guests: Gareth McCumskey

In this episode, JavaScript Jabber speaks with Gareth McCumskey about Serverless For JavaScript. Gareth leads the dev team at Expat Explore in Cape Town, South Africa. Gareth and this team specialize in exploring the Serverless realm in JavaScript. The JavaScript Jabbers panel and Gareth discuss the many different types of serverless systems, and when to implement them, how serverless system work, and when to go in the direction of using Serverless. 

In particular, we dive pretty deep on:

  • What does it mean to be Serverless? 
  • Since platform as a service.
  • Microservice on Docker 
  • Firebase
  • “no backend” 
  • Backend systems 
  • Cloud functions and failure in systems 
  • How do you start to think about a serverless system? 
  • How do decide what to do?
  • AWS Lambda 
  • Working in a different vendor
  • Node 4 
  • Programming JS to deploy 
  • Using libraries for NPM
  • How is works with AWS Lambda
  • Where is the database?
  • More point of failure? 
  • Calls to Slack?
  • Authentication
  • Micro Services
  • Elastic Bean Stalk
  • Static Assets, S3, Managing
  • Testing the services 
  • Integration testing
  • And much more! 

Links:

Picks:

Aimee

AJ

Charles

Gareth

Joe 

Dec 12 2017
54 mins
Play

Rank #10: JSJ 315: The effects of JS on CSS with Greg Whitworth

Podcast cover
Read more

Panel:

  • AJ O’Neal
  • Aimee Knight

Special Guests: Greg Whitworth

In this episode, the JavaScript Jabber panelists discuss the effects of JavaScript on CSS with Greg Whitworth. Greg works on Microsoft EdgeHTML, specifically working on the Microsoft Layout team, is on the CSS working group, and is involved with the Houdini task force. They talk about JS engines and rendering engines, what the CSSOM is, why it is important to understand the rendering engine, and much more!

In particular, we dive pretty deep on:

  • Greg intro
  • What is the Houdini task force?
  • Extensible web manifesto
  • DOM (Document Object Model)
  • Layout API
  • Parser API
  • Babel
  • jQuery
  • Back to basics
  • JavaScript engine and rendering engine
  • What is the CSSOM?
  • Every browser has its separate JS engine
  • Browsers perspective
  • Aimee ShopTalk Podcast Episode
  • Why is it important to understand how the rendering engine is working?
  • Making wise decisions
  • Give control back to browser if possible
  • When you would want to use JavaScript or CSS
  • Hard to make a hard or fast rule
  • CSS is more performant
  • Overview of steps
  • And much, much more!

Links:

Sponsors

Picks:

AJ

Aimee

Greg

May 30 2018
53 mins
Play

Rank #11: 179 JSJ redux and React with Dan Abramov

Podcast cover
Read more

02:25 - Dan Abramov Introduction

02:43 - Dan’s Background and Journey Into Building Stuff with React

05:48 - redux and React    

10:07- The Elm Programming Language

12:19 - Reducers

14:04 - Hot Reloading

17:50 - “React makes you a better JavaScript developer.”

22:10 - Time Travel

28:26 - Storing Data and Managing State

34:43 - [Patreon] Support Dan Abramov Creating Redux and React Hot Loader

36:24 - react-transform

41:34 - Using redux outside React

43:52 - Editors and Programmer Productivity

45:35 - Future Plans

Picks

The OAuth2 RFC (Aimee)
Michael Ries: Hiring Apprentices (Jamison)
@sebmck: "Sometimes having email history isn't always a good thing..." (Jamison)
Metal Gear Solid 5: The Phantom Pain (Jamison)
Firefly (Joe)
The Elm Programming Language (Joe)
Google Keep (Dave)
15 Minute Podcast Listener chat with Charles Wood (Chuck)
Pebble Time (Chuck)
100 Days of Burpees (Chuck)
Broad City (Dan)
Jamie xx: In Colour (Dan)
Cycle.js (Dan)

Sep 30 2015
1 hour 1 min
Play

Rank #12: JSJ 267 Node 8 with Mikeal Rogers, Arunesh Chandra, and Anna Henningsen

Podcast cover
Read more

JSJ 267 Node 8 with Mikeal Rogers, Arunesh Chandra, and Anna Henningsen

On today’s episode of JavaScript Jabber we have panelists Joe Eames, AJ O’Neil, Amiee Knight and Charles Max Wood and we are talking about Node 8. To help us we have special guests Mikeal Rodgers, Arunesh Chandra, and Anna Henningsen. It’s going to be a great show. Tune in.

[1:56] Is Node 8 just an update or is there more?
  • More than just an update
  • Two main points:
  • Improved Prana support
  • Native API
  • Native APIs are helpful for Native Add-ons. For both the consumer and the developer side.
  • Prior to update these Node Native modules ran in C++ and bound to specific to Node 8 APIs.
  • Causes these modules to be updated or reconciled every time these modules are rereleased.
  • Creates burden for module maintainers.
  • Creates friction in upgrading Node versions in production departments.
  • If you have a deployment depending on a certain Native module, some of the modules may not get updated in time when updating your Node versions. Keeping people from updating Node.
  • Creates compatibility issues with Node users not using Node 8
  • Experimental support for a Native layer in Node 8 to eliminate these issues as much as possible.
  • Important milestone for the module ecosystem.
  • You can write extensions for Node in C++ and it decouples V8 so you can use something else on the front.
  • Modules takes dependency on V8 API specific to a particular version. So if V8 changes your module will be extracted from that.
  • As a side benefit, you can have another VM to take advantage of that.
  • Major version upgrades mean updating Native modules and usually some of those modules haven’t updated to the newest version of Node and be complicated.
  • Deep dependency wise, about 30% depends on a Native module somewhere
  • In the future, with the Native API, you’ll be able to update Node without breaking modules.
[5:51] What kind of work went into this?
  • Most of the work was in C++
  • First thing that was done was, they looked at the top dependent Native modules in the ecosystem.
  • Looked for what kind of V8 exposure they had and cataloged it
  • Looked at how these APIs and what their purposes were
  • Looked for a way to extract them so that they are part of Node Core
  • Created neutral APIs, now part of the Node core.
  • All C APIs
  • Also has a C++ wrapper to improves usability of the API.
[7:17] What’s an example of what you can do with these APIs?
  • Native modules allows for tighter integration and better module performance
  • Specific APIs that you can use in V8 that isn’t available through JavaScript
  • If you have a C++ variable code and you want to expose a variable into JavaScript, that is V8 API note a Node 8 API
  • Having it bound directly to the VM was something they wanted for a long time
  • Google controls V8 and they bind to V8
  • Created a better relationship with Google starting in IOJS
  • Also worked with Microsoft with their Node Shocker work.
  • Same with SpiderMonkey
  • SpiderNode is in the works
[9:23] Have you guys done any testing for performance?
  • Some. There is a performance working group.
  • There is a need to stay on top of V8
  • V8 team has focused on new language features
  • Many features have been added over the years
  • Many didn’t come in optimized
  • The performance profile has changed with these features
  • If you’re using new language features, you will see a performance boost
  • In core, still tracking down code that was specific to the old optimizer and rewriting i to work the new optimizer
  • Turbo C compiler hasn’t landed yet, but is to come.
  • Will have a completely different performance profile
  • In most real world applications it will be faster
  • Waiting on the release to take a version of V8 to make it easier to upgrade features in the future
[11:28] Are the new features picked up from V8 or implemented in Node?
  • It’s all in V8
  • Better longterm support
  • Promises are made better in Node as a platform
  • Added new method called util.promisify()
  • Implementation comes from V8
  • Allows for more optimization for promises in Node core
  • Promise support for the one-deprecated domains module.
[13:02] Is there anything more than NMP 5?
  • First off, delete your NMP cache.
  • It’s in your home directory usually with a .npm extension
[14:09] What are the new features in V8?
  • Unlimited heap sizes, previously had a 4gb limit. No fixed limit.
[14:09] Will you see things like chakra come out tuned for servers?
  • Profiles of a server for application process are getting smaller
  • Getting cut into containers and VMs and micro services
  • Vms that have cold boot time and run quickly in a strained environment is looking more like what we will see in the future
  • Yes, especially if you’re using cloud functions
  • V8 is optimized for phones, but Chakra is even more so
  • Looking for opportunities for VMs can be solely optimized for a device target
  • Node take advantage of that VM
  • VM neutrality is an interesting concept
  • VM Vendors trying to optimize it based on workloads of a server
  • Opens opportunities for Node
  • Node Chakra has been proved to iOS. You can cut off jitting off which was a requirement to be able to be in the Apple App Store
  • Node is not just for servers anymore
  • Node doesn’t take a long time configuring it
  • When a developer runs code on an IoT or a mobile app they don’t control the VM that is bundled, they run it on top of Node and it just works.
  • VM neutrality gives a new vector, so you can swam a whole different VM
[18:44] When running different engines like iOS vs Android, does the profile change?
  • What it comes down to is if it’s eventive programming
  • The browser is an eventive environment, is very efficient waiting for things to happen before it does something
  • The way that we program servers and nodes are the same as well
  • the basics are the same generally
  • environmental differences exist but the programming model is usually the same
  • What does impact it is memory and processor and hardware and things like that
  • That is where tuning the VM comes into play
[20:29] What is the new Async Hooks API used for?
  • Node has been lacking for automated inspection of Async Hook
  • No way for Node to tell you when scheduling and beginning of an Async operation. Hook helps with that
  • it’s a way for developers to write debugging features
  • Node tells the application that it’s working with Asynchronous way.
  • The embedded inspector has been embedded since Node 6
  • Now has a JavaScript API to use it
  • You can use things like Chrome debugger inside the running node process
  • Old debugging protocol has been removed
  • VM.run is still there but in the process of being deprecated
[22:34] How like is the experimental Node API will change?
  • Marked as experimental because it’s the first time in the open
  • Hopefully out of experimental soon
  • Soon can port API to the existing LTS
  • Looking for more people to participate with the new API and give feedback
  • Fix any concerns before it goes to LTS
  • Some other experimental things are in the works like ASync Hooks and how it interacts with promises
  • Renaming some features
  • Another new feature - serializer and deserializer that comes with V8
  • experimental but will most likely stay
[25:31] what is your standard for going to LTS?
  • Major releases every 6 months
  • Next Oct Node 9 will come out and then Node 8 will be LTS
  • Documentation, updates, additions etc will be ready then
  • Plan to do it for 2.5 years
  • Every even releases come out to LTS as the odd release comes out
  • Helps keeps a current line while having something new in the release line
  • Node 6 is the current LTS version
[27:26] What are you taking out or deprecating in Node 8?
  • Use the word deprecate sparingly
  • If many people use features, it’s hard to get rid of
  • Security issue with Buffer, constructor argument was ambiguous
  • Had added APIs that were more explicit over time and pushed those
  • Now it will be deprecated
[28:43] 21% - 33% Performance increase with some Node updates
  • Someone online updated their React app to Node 8 and found an 21% - 33% increase
  • Benchmarking group tests to make sure things are getting faster
  • V8 is always getting faster as well
  • Code changes fast and so there is a chance performance slows down so they have people to check
  • Benchmark test are all automated by a team
[30:47] Is it safe to just switch to Node 8?
  • For front-end, yes
  • clear your NPM cache
  • Back use cases will usually wait until LTS
[31:28] Where any of the features hard to implement?
  • The API work took about a year
  • It was a collaboration which made it interesting
  • IBM, Intel, Google were involved
  • The collaboration took a while
  • Also Async hooks took at least a year.
  • Async hooks used to be called async wraps and has been in the work for almost 3 years
  • many of the changes were the accumulation of small chances
[33:07] It’s the little things
  • Letting people get small changes in accumulate into a big difference
  • the product gets much better that way
[33:57] What versions of Node are you actively updating?
  • Current releases of Node 8 for a half of year
  • Node 6 is LTS
  • Additional year of maintenance of previous LTSs.
  • Schedule is at http://github.com/node8js/lts in a chart
  • Support for Node 4 with only critical updates, Node 6 minor updates, and Node 8
  • Node 7 doesn’t get much support unless it’s vital security supports.
  • If you’re running 0.10 or 0.12 stop. Those do not get security fixes anymore
[35:42] Where do you see things going from here?
  • Mostly still working out Async hooks
  • Maybe add some web worker or worker support for Node JS
  • ES module support
  • Working to make promises better
  • Working on the performance profile and internal systems
[20:29] What is the adoption like of Node 8?
  • Node team gets better at getting people to adopt quickly
  • but about 5% - 6% will not upgrade
  • community doubles each year at 8 million users right now
  • Here is a graph on Twitter posted by NPM
  • Limiting breaks and softly deprecating things makes it’s easier to upgrade
[40:11] How can people contribute and get involved?
  • NodeToDo.org shows how to make contribution
  • Occasionally major conferences have information on how to contribute
  • Test it out and help make it stronger
[42:08] If people install Node 8 and have issues what can they do?
  • If it’s an NPM problem check with them
  • clear cache!
  • install newest version with: npm install -g npm@latest
  • Report problems to either NPM or Node
  • If you’re not sure where the problem is, check github.com/nodejs/help

Links

Node8 Node’s Twitter Node’s Medium Node Evangelism Group

Mikael on Twitter and GitHub Arunesh on Twitter Anna on Twitter

Picks

AJ

Overclocked Remix Super Mario RPG Window to The Stars

Amiee

Blogpost RisingStack on Node 8
2 Frugal Dudes

Charles

Homeland
House of Cards

Joe

Shimmer Lake

Mikael

Blake2b-wasm

Aremesh

Current Nightly News

Jun 27 2017
52 mins
Play

Rank #13: JSJ 368: TypeScript - Good or Bad

Podcast cover
Read more

Sponsors

Panel

  • Joe Eames

  • AJ O’Neal

Episode Summary

In this episode of JavaScript Jabber, Joe Eames and AJ O’Neal talk about what TypeScript is, and their background and experiences with it. They discuss the different kinds of typed languages such as dynamic vs static, strong vs weak, implicit vs explicit casting and the reasons for selecting one type over the other. AJ shares his opinion on not preferring TypeScript in general, while Joe offers a counter perspective on liking it, and both give a number of reasons to support each argument. They talk about some final good and bad points about TypeScript and move on to picks.

Links

Follow JavaScript Jabber on Devchat.tv, Facebook and Twitter.

Picks

Joe Eames:

AJ O’Neal:

Jun 11 2019
58 mins
Play

Rank #14: JSJ 278 Machine Learning with Tyler Renelle

Podcast cover
Read more

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:

Picks:

Aimee

AJ

Joe

Tyler

Sep 12 2017
58 mins
Play

Rank #15: JSJ 380: Expo for Web with Charlie Cheever

Podcast cover
Read more

Sponsors

Panel

  • Charles Max Wood

With Special Guest: Charlie Cheever

Episode Summary

Guest Charlie Cheever joins the discussion on JavaScript Jabber today. He was previously on React Round Up episode 47. Charlie works on Expo, which is a way to make React apps on every platform. Right now, Expo supports IOS, Android, and Web, provides a standard library of features, and takes care of services like builds and updates over the air. There are also code generators and templates available in Expo. Expo is focused on use cases where you just need to use a little bit of React Native in your app. Charlie talks about the origins of Expo, which was born from increased access of websites from people’s phones and the desire for a cross-platform tool that was as easy as building on the web. One of the biggest benefits is that Expo gives you the peace of mind knowing your app will work across all phones and all platforms.

They discuss how to approach building your API’s for Expo so that it’s easy for people to use and have it consistent across all these different systems. Expo also has a voting board canny.expo.io where people can submit suggestions for new features. Expo is compatible with map view and React Native maps. Currently, Expo is missing bluetooth and things where the underlying platform wants to have a direct relationship with the developer, such as in-app purchases. Charlie talks about other components available in Expo, all of which can be modified. They discuss the influence of React on augmented reality and VR. Charlie talks about the updating feature of Expo. Charlie talks about the evolution of Expo and their goal to be a “developer first” company. He talks about the company, libraries, The Client, and services. He gives advice on how to get started with React Native development and using Expo. There is also Expo Web, which can be used to create a website, and if you create an app with Expo you get a website too. Expo hopes to be a stable, easy, coherent way of using all these tools across your entire experience of building your application so that you can relax a little bit. 

Click here to cast your vote NOW for JavaScript Jabber - Best Dev Podcast Award

Links

Follow DevChat on Facebook and Twitter

Picks

Charles Max Wood:

Charlie Cheever:

  • Draft bit (still in beta)

  • AWS Amplify

  • Follow Charlie @ccheever

Aug 06 2019
50 mins
Play

Rank #16: JSJ 298: Angular, Vue and TypeScript with John Papa

Podcast cover
Read more

Panel: 

Charles Max Wood

Cory House

Joe Eames

Aimee Knight

Special Guests: John Papa

In this episode, JavaScript Jabber panelist speak with John Papa. John has been doing web programming for over twenty years on multiple platforms and has been contributing to the developer communities through conferences, authoring books, videos and courses on Pluralsight.

John is on the show to discuss an articles he wrote on A Look at Angular Along Side Vue, and another article on Vue.js  with TypeScript. John talks about the new features with the different versions of Angular technologies, anxiety in the different features, comparisons between the technologies and use case with Angular.

In particular, we dive pretty deep on:

  • A look at Angular Along Side Vue - Article
  • Angular 5, Amber,Vue,  React, Angular
  • Angular 2 - different features
  • CLI
  • Spell Webpack
  • Comparisons - Why the anxiety?
  • Opinions of Angular and sprinkling in other technologies
  • Vue is the easy to use with Angular
  • Are there breakpoints with the uses case?
  • Choosing technologies
  • Talk about working with Vue and Angular
  • DSL - Domain Specific Language
  • Vue and 3rd party libraries
  • Talk about Vue working with TypeScript
  • Vue.js  with TypeScript
  • Vue with TypeScript looks similar to Angular
  • Vetur
  • What does 2018 have in store for Angular?
  • Native apps and web functionality
  • And much more!

Links:

Picks:

Corey

Charles

Aimee

Joe

John

Jan 31 2018
1 hour 3 mins
Play

Rank #17: JSJ 299: How To Learn JavaScript When You're Not a Developer with Chris Ferdinandi

Podcast cover
Read more

Panel: 

AJ O’Neal

Joe Eames

Aimee Knight

Special Guests: Chris Ferdinandi

In this episode, JavaScript Jabber panelist speak with Chris Ferdinandi. Chris teaches vanilla JavaScript to beginners and those coming from a design background. Chris mentions his background in Web design and Web Develop that led him JavaScript development. Chris and the JSJ panelist discuss the best ways to learn JavaScript, as well as resources for learning JavaScript. Also, some discussion of technologies that work in conjunction with vanilla JavaScript.

In particular, we dive pretty deep on:

  • Teaching JavaScript - Beginners and Design patrons
  • Web Design and Web Development
  • CSS Tricks 
  • Todd Motto
  • How to do jQuery Things without jQuery
  • Doing things like mentors (Todd)
  • When JavaScript makes sense.
  • CSS is easier to learn then JS?
  • Being good at CSS and JS at the same time?
  • How about Node developers?
  • jRuby, DOM
  • Documentation
  • And much more!

Links:

Picks:

AJ

Aimee

Joe

Chris

Feb 07 2018
1 hour 11 mins
Play

Rank #18: JSJ 279: ES Modules in Node Today! with John-David Dalton

Podcast cover
Read more

Tweet this Episode

John-David Dalton is probably best known for the Lodash library. He's currently working at Microsoft on the Edge team. He makes sure that libraries and frameworks work well in Edge.

The JavaScript Jabber panel discusses the ECMAScript module system port to Node.js. John wanted to ship the ES module system to Node.js for Lodash to increase speed and decrease the disk space that it takes up. This approach allows you to gzip the library and get it down to 90 kb.

This episode dives in detail into:

  • ES Modules, what they are and how they work
  • The Node.js and NPM package delivery ecosystem
  • Module loaders in Node.js
  • Babel (and other compilers) versus ES Module Loader
  • and much, much more...

Links:

Picks:

Cory:

Aimee:

Aaron:

Chuck:

John:

Sep 19 2017
56 mins
Play

Rank #19: MJS #021 Justin Meyers

Podcast cover
Read more

My JS Story Justin Meyers

On this week’s episode of My JS Story, Charles Max Wood interviews Justin Meyers Co­founder and CEO of Bitovi, a Javascript consulting firm focused on simplifying Javascript development through the use and creation of open source tools as well general consulting, training, and web applications. He was on Episode 202 and talked about DoneJS and CanJS. Tune in to hear Justin’s full story!

7th Grade and a TI­82 [3:02]
Justin’s discovery of conditional statements and methods on a classic TI­82 was his first taste of programming. With a little guidance, he soon learned to program games on the TI­82 and then later moved onto bigger and better mediums like C and QBasic.

Grunt work is good for you. [4:51]
While studying Computer Science, Justin finds out that professors often have grunt work, and although they may not pay well now, sometimes they can in time lead to loads of experience and maybe even a bigger job. After 4 years of working on websites and writing documentation, he gets his first real job at Accenture.

Open Source and reducing waste. [6:23]
Accenture, while giving him a great chance to make some impressive projects, provoked Justin to see the efficiency in sharing code. Justin and a college friend get together to work on a project to build a platform that…builds. Although their project was unsuccessful, the tools they started to create for the project had plenty of potential.

The Last desperate gasp. AKA shaving his head. [9:40]
Justin talks about the Ajaxian blog and conference. Ten years ago, the Ajaxian blog was one of the best online resources for Javascript news. Justin was running low on funds and struggling and as his “last desperate gasp” he heads to the Ajaxian conference with his head shaved. Leaving only “Javascript MVC” shaped out of his hair. This stunt gets him remembered by many of the important attendees and also scores him his big break with a consulting job with T­-Mobile. Two to Three weeks later, Justin had a stroke. Justin talks about how incredible the timing was.

How Javascript MVC came to be[13:23]
Justin talks about starting with JSJunction and modeling after it. Their first steps were to add a model layer as well as Event Delegation. Javascript MVC reflects some of Ruby on Rails. Justin worked with Peter Svensson from Dojo, with a methodology that at the time seemed crazy. Justin reminisces when Steve Jobs “Killed” Flash with HTML5 and CSS.

Bitovi begins. [17:24]
Justin talks about how the T­-Mobile job meant that he would need an official business. Originally dubbing it JupiterIT. Justin found that MVC was too encompassing and that programmers enjoyed a sense of creativity. By pulling Javascript MVC’s tools apart and creating single frameworks from the tools, Justin then created tools like CanJS and DoneJS.

Who does the heavy lifting at Bitovi? [20:48]
As the CEO of Bitovi, Justin has less time to program as before. Working with Open Source, development is a mix between contributors and full time employees. The majority being the employees. Justin talks about not having a sales force and focusing on their product to drive sales. Mainly, long term cost of ownership and the ability for the framework to last, working hard to make sure that clients that have committed to Javascript MVC years ago still have a relevant use for the framework.

Exploring HTTP2 and Push. [23:42]
With the emergence of HTTP2 and Push, Justin talks about working on and exploring different ways for streaming/server side rendering. Justin describes one of the experiments with building an empty skeletons, javascript assets, but also pushing instructions on how to mutate the page to the client. Before the javascript payload is fully loaded, the page starts to mutate. Allowing for optimal performance on slower connections, fantastic for mobile. Problems they are looking at for the future include things like different ways that CDNs can work with HTTP2 and Push. Justin has also worked with using Fetch to enable streaming by building tools around that. He suggests that HTTP2 and Push will maybe bring a renaissance in the developer world.

Justin’s side Parsing Project. [28:45]
Additional to his other work, Justin is working on a generic parsing project. Similar to BISON or JISON. Designed for simple parsing at faster speeds. He describes how to compiles to the code that parses your code. Working in runtime.

A way other companies can learn from Bitovi. [29:52]
We don’t know what the future is going to be for code, so packaging the framework into separate repos allows for better scheduling and a better way to manage long term. Updating a segment of a framework can sometimes break another segment if having it all happen together.

Picks [34:26]

Justin:

Dean Radcliff’s Antares Framework

Charles:

Boom Beach

Clash of Clans

BlueTick.io

Nimble

Keeping up with Justin’s work.

Bitovi.com’s Blog

Justin’s Twitter.

Sponsors

Cachefly.com
Newbie Remote Conf 2017

Jun 14 2017
39 mins
Play

Rank #20: JSJ 365: Do You Need a Front-End Framework?

Podcast cover
Read more

Sponsors

Panel

  • Charles Max Wood

  • Aimee Knight

  • Chris Ferdinandi

  • AJ O’Neal

  • Joe Eames

Episode Summary

Today the panel discusses the necessity of a front end framework. Overall, there is a consensus that frameworks are not necessary in all situations. They discuss the downsides of using frameworks, such as being restricted by the framework when doing edge development and the time required for learning a framework. They talk about the value of frameworks for learning patterns in programming.

The panel delves into the pros and cons of different frameworks available. Joe shares a story about teaching someone first without a framework and then introducing them to frameworks, and the way it helped with their learning. One of the pros of frameworks is that they are better documented than manual coding. They all agree that it is not enough to just know a framework, you must continue to learn JavaScript as well.

They talk about the necessity for new programmers to learn a framework to get a job, and the consensus is that a knowledge of vanilla JavaScript and a general knowledge of the framework for the job is important. New programmers are advised to not be crippled by the fear of not knowing enough and to have an attitude of continual learning. In the technology industry, it is easy to get overwhelmed by all the developments and feel that one cannot possibly learn it all. Charles gives advice on how to find your place in the development world. The show concludes with the panel agreeing that frameworks are overall a good thing and are valuable tools.

Links

Follow DevChat on Facebook and Twitter

Picks

Charles Max Wood:

Aimee Knight:

Chris Ferdinandi:

AJ O’Neal:

May 21 2019
1 hour 14 mins
Play

Similar Podcasts