JSJ 439: More Jabber About Less JavaScript with Alex Russell

Vitali Zaidman is a full stack developer who works for WellDone Software Solutions and is currently working on a SEO project. Today’s show is about SEO for developers. SEO stands for search engine optimization, which helps your website appear higher on search engines. SEO has changed a lot in the past 10 years. It has become much more regulated, and the “dirty tricks” of the past will actually penalize you, so it is important to do it properly. Today the best way to promote yourself on Google besides making good content is for developers to optimize the content, make it small, operational, secure, accessible, and operate on mobile. Much of it goes back to using semantic HTML since Google looks at it before looking at the structure of your website, how valuable it is, and how users interact with it. Having good semantics helps Google determine how valuable it is, so semantic HTML should be a top priority. Semantic HTML can also make your site more accessible to users, which will in turn give you a larger audience. The panel talks about some of the challenges of SEO faced by companies. While bigger companies have the privilege of dedicated SEO teams, small companies often lack these specialists. Thankfully, Google has made their guidelines for SEO very accessible and gives you a lot of tools to track your optimization. The panel talks about different methods of SEO, such as including FAQ at the bottom of the web page, optimizing page speed, and image optimization. Structured data like questions and answers enriches the data that is shown for users on the search results page. To score your website’s SEO, Google released the tool PageSpeed Insights, which will assign your website a performance score. Google uses two main tools to track a website’s SEO. First, they use real field data. If you opt in to ‘help improve Chrome’s features and performance’ when you install Chrome, it tracks how fast websites load on your Chrome, and they collect this information to understand how webpages load. It is required that your website has a certain amount of visitors to be tracked and added to the database. Second, Google has their own devices that will check your website. Currently, they are using a Moto G4 to test for mobile access, and a slow internet connection. Because of this, it is pretty easy to get a good score on desktop, but difficult to get a good score on mobile. The technology that drives all this is called Lighthouse. Overall, performance is the main thing users look for, so aim for good performance and fast websites. The panel discusses the correlation between performance and SEO. For example, Fox News and CNN are two of the top search results for ‘news’, but they have a dismal Google PSI score. They conclude that performance shouldn’t be ignored, but be careful about directly correlating performance and SEO. They also caution against getting obsessed over certain aspects of SEO by themselves. PanelistsDan ShapirAimee KnightCharles Max WoodWith special guest: Vitali ZaidmanSponsorsTideliftSentry use the code “devchat” for 2 months free on Sentry’s small plan Elixir MixLinksSEOJSONGoogle Webmaster guidelinesGoogle PageSpeed InsightsChrome CrUXLighthouseHere's How the Google Speed Update Will Impact Your SiteSEO for Developers - A Quick OverviewGoogle Quality Guidelines Follow DevChatTV on Facebook and Twitter PicksAimee Knight:Spotify CLIDan Shapir:Chrome Dev Summit 2019 Dan Shapir on TwitterThe Anubis GatesCharles Max Wood:St. George MarathonVitali Zaidman: Vitali’s websiteArzamas Academy Follow Vitali on Medium and TwitterSpecial Guest: Vitali Zaidman . Support this podcast at — https://redcircle.com/javascript-jabber/donationsPrivacy & Opt-Out: https://redcircle.com/privacyBecome a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

22 Okt 201938min

Tanmai is one of the founders at Hasura. Hasura gives you instant graphQL APIs on top of a Postgres database. The eventual idea is to make data access secure and easy. Tanmai explains the challenges of doing this in the cloud. He talks about some of the difficulties with the tooling around using GraphQL and its bias towards working well with a monolith. Since GraphQL is basically a shared type system that describes your API, that means all your types need to be in the same code base. This is at odds with the folks who want to do microservices and serverless functions, because since their API is split across multiple services they have different types, and forcing these types to work together defeats the purpose of using microservices. Also, storing state across requests doesn’t work well with serverless and cloud native stuff. In short, learning to live without state is one of the general challenges with going serverless. This is where Hasura comes into play, and Tanmai explains how it works. Hasura is metadata driven, and each instance of the server can leverage multiple calls and exhibit a high amount of concurrency. It’s designed to be a little more CPU bound than memory bound, which means that configuring auto scaling on it is very easy and allows you to utilize the elasticity of cloud native applications. Tanmai clarifies his usage of the word ‘cloud native’, by which he means microservices. He explains that when you have a metadata based engine, this metadata has a language that allows you to bring to bring in types from multiple upstream microservices, and create a coherent graphQL API on top of that. Hasura is a middle man between the microservices and the consumer that converts multiple types into a single coherent graphQL API.Next, Tanmai explains how Hasura handles data fetching and a high volume of requests. They also invented PostgresQL, RLS-like semantics within Hasura. He explains the process for merging your microservices into a single graphQL interface. Back on data fetching, Tanmai explains that when the product is an app, preventing an overabundance of queries becomes easier because during one of the staging processes that they have, they extract all of the queries that the app is actually making, and in the production version it only allows the queries that it has seen before. Hasura is focused on both the public interface and private use cases, though private is slightly better supported. Tanmai talks about the customizations available with Hasura. Hasura supports two layers. One is an aliasing layer that lets you rename tables, columns, etc as exposed by PostgresQL. The other is a computer column, so that you can add computer columns so you can extend the type that you get from a data model, and then you can point that to something that you derive. The panelist discusses the common conception of why it is a bad idea to expose the data models to the frontend folks directly. They discuss the trend of ‘dumbing down’ available tooling to appeal to junior developers, at the cost of making the backend more complicated. They talk about some of the issues that come from this, and the importance of tooling to solve this concern. Finally, Tanmai talks about the reasons to use Hasura over other products. There are 2 technologies that help with integrating arbitrary data sources. First is authorization grammar, their version of RLS that can extend to any system of types and relationships, The second is the data wrapper, part of the compiler that compiles from the graphQL metadata AST to the actual SQL AST. That is a generic interface, so anyone can come in and plug in a Haskell module that has that interface and implement a backend compiler for a native query language. This allows us to plug in other sources and stitch microservices together. The show concludes with Tanmai talking about their choice to use Haskell to make Hasura. PanelistsAJ O’NealDan ShapirSteve EdwardsCharles Max WoodWith special guest: Tanmai GopalSponsorsAdventures in DevOpsSentry use the code “devchat” for 2 months free on Sentry’s small plan The Dev Ed PodcastLinksHasuraHaskellNode.jsCloud NativeMicroservices PostGraphile  Postgres PostgresQL RLSSwaggerJAMstackSoapRest Follow DevChatTV on Facebook and Twitter PicksAJ O’Neal:The Economic SingularityCapital CitiesGameCube HomebrewDan Shapir:RomaniaJSCampSteve Edwards:Cold Blooded: The Clutter Family MurdersCharles Max Wood:Maxcoders.ioTripItSt. George MarathonVO2 Max appTanmai Gopal:  Follow Tanmai on Twitter @tanmaigoBroken Earth TrilogyThe Three-Body ProblemgraphQL AsiaSpecial Guest: Tanmai Gopal. Support this podcast at — https://redcircle.com/javascript-jabber/donationsPrivacy & Opt-Out: https://redcircle.com/privacyBecome a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

17 Okt 20191h 10min

JavaScript Jabber celebrates its 400th episode with former host Dave Smith and some other familiar voices. Each of the panelists talks about what they’ve been up to. Dave hasn’t been on the show for 3 years, but he and Jameson Dance have started a podcast called Soft Skills Engineering where they answer questions about the non-technical side of engineering. When he left the show he was the director of engineering on Hire View, and currently he works for Amazon on Alexa. Christopher Buecheler has been on several JSJ, RRU, and MJS episodes. His time is divided between contracting for startups and his own company closebrace.com, a tutorial and resource site for JavaScript developers.  Dan Shapir has also been on JSJ as a guest, and is currently works for Wix doing performance tech. He enjoys speaking at conferences, such as JS Camp in Bucharest, Romania and the YGLF conference. Steve Edwards was previously on MJS 078. He started on Drupal in the PHP world, switched to JavaScript, and then a few years ago he started looking at Vue. Now he does Vue fulltime for ImageWare Systems.As for Charles, his primary focus is the podcasts, since DevChat.tv produces around 20 episodes per week. 5 new shows were started in July, and he talks about some of the challenges that that brought. One of his most popular shows recently was JSJ 389: What makes a 10x Engineer? This helped him realize that he wants to help teach people how to be a successful engineer, so he’s working on launching a new show about it. The panelists share some of their favorite JSJ episodes. They discuss the tendency of JSJ to get early access to these fascinating people when the conversation was just beginning, such as the inventor of Redux Dan Abramov, before their rise to stardom. The talk about the rise in popularity of podcasting in general. They agree that even though JavaScript is evolving and changing quickly, it’s still helpful to listen to old episodes. Charles talks about the influence JavaScript Jabber has had on other podcasts. It has spawned several spinoffs, including My JavaScript Story. He’s had several hosts start their own DevChat.tv shows based off JavaScript Jabber, including Adventures in Angular and The DevEd Podcast. JavaScript Jabber has also been the inspiration for other podcasts that aren’t part of DevChat.tv. There aren’t many podcast companies that produce as many shows as they do and they’re developing their own tools. DevChat.tv moved off of WordPress and is in the process of moving over to Podwrench. Charles talks about all the new shows that have been launched, and his view on ‘competing’ podcasts. Charles is also considering doing an audio drama that happens in a programming office, so if you would like to write and/or voice that  show, he invites you to contact him. The show concludes with the panel talking about the projects they’ve been working on that they want listeners to check out. Christopher invites listeners to check out closebrace.com. He also has plans to write a short ebook on unit testing with jest, considered doing his own podcast, and invites people to check out his fiction books on his website. Dan talks about his involvement with Wix, a drag and drop website service, that recently released a technology called Corvid which lets you write JS into the website you build with Wix. This means you can design your user interface using Wix, but then automate it, add events functionality, etc. Dan is also going to be at the Chrome Dev Summit conference. Dave invites listeners to check out the Soft Skills Engineering podcast, and Charles invites listeners to subscribe to his new site maxcoders.io. Panelists- Dan Shapir- Christopher Buecheler- Steve Edwards- Dave Smith- Charles Max WoodSponsors- https://tidelift.com/- http://sentry.io/ use the code “devchat” for 2 months free on Sentry’s small plan - https://devchat.tv/adventures-in-dotnet/Links- https://devchat.tv/dev-rev/- https://devchat.tv/my-javascript-story/mjs-099-christopher-buecheler/- https://devchat.tv/js-jabber/jsj-338-its-supposed-to-hurt-get-outside-of-your-comfort-zone-to-master-your-craft-with-christopher-buecheler/#viewport- https://devchat.tv/react-round-up/rru-029-christopher-buecheler-getting-ready-to-teach-lessons-learned-from-building-an-84-tutorial-software-course/#viewport- https://devchat.tv/my-javascript-story/mjs-108-dan-shappir/#viewport- https://devchat.tv/js-jabber/jsj-334-web-performance-api-with-dan-shappir/#viewport- https://devchat.tv/js-jabber/jsj-371-the-benefits-and-challenges-of-server-side-rendering-ssr-with-dan-shappir/#viewport- https://devchat.tv/my-javascript-story/mjs-078-steve-edwards/#viewport- https://devchat.tv/js-jabber/179-jsj-redux-and-react-with-dan-abramov/- https://devchat.tv/js-jabber/187-jsj-vue-js-with-evan-you/- https://devchat.tv/js-jabber/jsj-383-what-is-javascript/- https://devchat.tv/js-jabber/jsj-385-what-can-you-build-with-javascript/- https://devchat.tv/js-jabber/jsj-390-transposit-with-adam-leventhal/- https://devchat.tv/js-jabber/jsj-395-the-new-ember-with-mike-north/- https://devchat.tv/js-jabber/220-jsj-teaching-javascript-with-kyle-simpson/- https://devchat.tv/js-jabber/jsj-313-light-functional-javascript-with-kyle-simpson/- https://devchat.tv/js-jabber/124-jsj-the-origin-of-javascript-with-brendan-eich/- https://devchat.tv/js-jabber/073-jsj-react-with-pete-hunt-and-jordan-walke/- https://devchat.tv/js-jabber/jsj-392-the-murky-past-and-misty-future-of-javascript-with-douglas-crockford/- https://player.fm/series/all-javascript-podcasts-by-devchattv/jsj-391-debugging-with-todd-gardner- https://devchat.tv/js-jabber/jsj-389-what-makes-a-10x-engineer/- http://cwbuecheler.com/- https://closebrace.com- https://www.wix.com/corvid  - https://softskills.audio/- https://maxcoders.io/                                                                                                                                                                           Follow DevChatTV on https://www.facebook.com/DevChattv/?__tn__=%2Cd%2CP-R&eid=ARDBDrBnK71PDmx_8gE_IeIEo5SnM7cyzylVBjAwfaOo1ck_6q3GXuRBfaUQZaWVvFGyEVjrhDwnS_tV and https://twitter.com/devchattv?lang=en PicksSteve Edwards:- https://github.com/formio/formioChristopher Buecheler:- https://www.apollographql.com/docs/apollo-server/testing/graphql-playground/- https://twitter.com/TheTimeCowboy Jake Lawrence Charles Max Wood:- https://www.stgeorgemarathon.com/-Become a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

15 Okt 20191h 10min

Valeri Karpov is a maintainer on Mongoose, has started a few companies, and works for a company called Booster Fuels. Today’s topic debugging with Async/Await. The panel talks about some of the challenges of debugging with Async. AJ, however, has never encountered the same problems, so he shares his debugging method. Valeri differentiates between .catch vs try...catch, and talks about why he prefers .catch. There are two ways to handle all errors in an async function without leading to an unhandled promise rejection. The first is to wrap the entire body of the async function in a try...catch, has some limitations. Calling an async function always returns a promise, so the other approach is calling .catch on the promise to handle any errors that occur in that function body. One of the key differences is if you return a promise within an async function, and that return promise is wrapped in a try...catch, the catch block won’t get called if that promise is rejected, whereas if you call .catch on the promise that the function returns, you’ll actually catch that error. There are rare instances where this can get tricky and unintuitive, such as where you have to call new promise and have resolve and reject, and you can get unexpected behavior.The panel discusses Valeri’s current favorite JS interview question, which is,  “Given a stream, implement a function called ‘stream to promise’ that, given a stream, returns a promise that resolves to the concatenation of all the data chunks emitted by the stream, or rejects if the stream emits an error event.” It’s really simple to get this qustion right, and really simple to get it wrong, and the difference can be catastrophic. AJ cautions listeners to never use the data event except in the cases Val was talking about, only use the readable event.The conversation turns to the function of a readable event. Since data always pushes data, when you get a readable event, it’s up to you to call read inside the function handler, and then you get back a chunk of data, call read again and again until the read returns null. When you use readable, you are in control and you avoid piling functions into RAM. In addition, the right function will return true or false to let you know if the buffer is full or not. This is a way to mix imperative style into a stream.The next discussion topics are the differences between imperative style and reactive style and how a waits and promises work in a normal four loop. A wait suspends the execution of a function until the promise is resolved. Does a wait actually stop the loop or is it just transpiling like a promise and it doesn’t stop the loop. AJ wrote a module called Batch Async to be not as greedy as promise.all but not as limited as other options.The JavaScript panelists talk about different async iterators they’ve used, such as Babel. They discuss the merits of Babel, especially since baseline Android phones (which a significant portion of the population of the world uses) run UC Browser that doesn’t support Babel, and so a significant chunk of the population of the world. On the other hand, if you want to target a large audience, you need to use Babel.Since frameworks in general don’t handle async very well, the panel discusses ways to mitigate this. They talk about different frameworks like Vue, React, and Express and how they support async functions. They discuss why there is no way for you to actually cancel an async option in an actual case, how complex canceling is, and what you are really trying to solve for in the cancellation process. Canceling something is a complex problem. Valeri talks about his one case where he had a specific bug that required non-generic engineering to solve, and cancelling actually solved something. When AJ has come across cancellation issues, it’s very specific to that use case. The rest of the panelists talk about their experiences with having to cancel something. Finally, they talk about their experience with async generator functions. A generator is a function that lets you enter into the function later. This makes sense for very large or long running data sets, but when you have a bounded items, don’t complicate your code this way. When an async generator function yields, you explicitly need to call next in order for it to pick up again. If you don’t call ‘next’, it’s essentially cancelled. Remember that object.keys and object.values are your friends. PanelistsChristopher BuechelerAJ O’NealCharles Max WoodWith special guest: Valeri KarpovSponsorsThe DevEd PodcastSentry use the code “devchat” for 2 months free on Sentry’s small plan Adventures in DevOpsLinksMongooseExpress 5Node StreamsPull StreamsMasteringjs.ioMongoDBBabelHTMLWebpackVueExpressRxJSConsole.logJson.stringifyBatchasync.jsHow to Write Batch Async Functions Follow DevChatTV on Facebook and Twitter PicksAJ O’Neal:Ethan Garofolo YouTubeChristopher Buecheler:Functional Design Patterns for Express.jsCharles Max Wood:Microsoft IgniteMaxcoders.ioValeri Karpov: Follow Valeri on Twitter @code_barbarian and Github @vkarpov15Masteringjs.ioJurassic Park: A NovelSpecial Guest: Valeri Karpov. Support this podcast at — https://redcircle.com/javascript-jabber/donationsPrivacy & Opt-Out: https://redcircle.com/privacyBecome a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

10 Okt 20191h 3min

Guest Paige Niedringhaus has been a developer full time for 3 years, and today she is here to talk about Node 12. One of the things she is most excited about is the ES6 support that is now available, so things that used to require React, Angular, or Vue can now be done in Node. The require function will not have to be used in Node 12. AJ is worried about some of these changes and expresses his concerns. Paige assures him that in the beginning you won’t have to switch things to imports. You may have to change file extensions/types so Node can pick up what it’s supposed to be using. They are also trying to make it compatible with CommonJS.Node 12 also boasts an improved startup time. The panel discusses what specifically this means. They talk about the code cache and how Node caches the built in libraries that it comes prepackaged with. The V8 engine is also getting many performance enhancements. Paige talks about the shift from promises to async. In Node 12, async functions will actually be faster than promises. They discuss some of the difficulties they’ve had in the past with Async08, and especially callbacks. Another feature of Node 12 is better security. The transcripted security layer (TLS), which is how Node handles encrypted strains of communication, is upgrading to 1.3. The protocol is simpler to implement, quicker to negotiate sessions between the applications, provides increased end user privacy, and reduces request time. Overall, this means less latency for everybody. 1.3 also gets rid of the edge cases that caused TLS to be way far slower than it needed to be. The conversation turns to properly configuring default heap limits to prevent an ‘out of memory’ error. Configuring heap limits is something necessary when constructing an incredibly large object or array of objects. Node 12 also offers formatted diagnostic summaries, which can include information on total memory, used memory, memory limits, and environment lags. It can report on uncaught exceptions and fatal errors. Overall, Node 12 is trying to help with the debugging process. They talk about the different parsers available and how issues with key pairing in Node have been solved. Paige talks about using worker threads in Node 12. Worker threads are really beneficial for CPU intensive JavaScript operations. Worker threads are there for those things that eat up all of your memory, they can alleviate the load and keep your program running efficiently while doing their own operations on the sideline, and returning to the main thread once they’ve finished their job. None of the panelists have really used worker threads, so they discuss why that is and how they might use Worker Threads in Node 12. In addition, Node 12 is making Native module creation and support easier, as well as all the different binaries a node developer would want to support. Paige makes it a point to mention the new compiler and minimum platform standards. They are as follows:GCC minimum 6GLIVC minimum 2.17 on platforms other than Mac and Windows (Linux)Mac users need at least 8 and Mac OS 10.10If you’ve been running node 11 builds in Windows, you’re up to speedLinux binaries supported are Enterprise Linux 7, Debian 8, and Ubuntu 14.04If you have different requirements, go to the Node websitePanelistsJ.C. HyattSteve EdwardsAJ O’NealWith special guest: Paige NiedringhausSponsorsTideliftSentry use the code “devchat” for 2 months free on Sentry’s small plan Sustain Our SoftwareLinksAsyncCommonJSnjsPromiseNodeEvent StreamllhttpllparseLLVMPapa ParseJson.stringify Json.parseOptimizing Web Performance TLS 1.3Overlocking SSLGenerate Keypair Follow DevChatTV on Facebook and Twitter PicksJ.C. Hyatt:AWS Amplify framework12 Rules for Life: An Antidote to Chaos by Jordan PetersenReact and Gatsby workshopsSteve Edwards:The Farside comic coming back?AJ O’Neal:Field of Hopes and StringsLink’s AwakeningDunePaige Niedringhaus:DeLonghi Magnifica XS Automatic Espresso Machine, Cappuccino MakerCONNECT.TECH Conference Follow Paige on Twitter, Medium, and Github Special Guest: Paige Niedringhaus. Support this podcast at — https://redcircle.com/javascript-jabber/donationsPrivacy & Opt-Out: https://redcircle.com/privacyBecome a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

8 Okt 20191h 4min

Kaelig Deloumeau-Prigent is a self taught web developer from west France. He has worked for BBC, The Guardian, and The Financial Times in the UK. He has also worked in the US for SalesForce and currently works for Shopify on their Polaris design system. Shopify has multiple design systems, and Polaris is open source. Today the panel is talking about design systems and developer tooling around design systems. To begin, Kaelig explains what a design system is. A design system is all of the cultural practices around design and shipping a product. It includes things like the words, colors, spacing grid system, and typography, plus guidance on how to achieve that in code. The panelists discuss what has made design systems so popular. Design systems have been around for a while, but became popular due to the shift to components, which has been accelerated by the popularity of React. The term design system is also misused by a lot of people, for it is much more than having a Sketch file. Next, they talk about whether design systems fall under the jurisdiction of a frontend developer or web designers. Kaelig has found that a successful design system involves a little bit of everyone and shouldn’t be isolated to one team. They talk about what the developer workflow looks like in a design system. It begins with thinking of a few common rules, a language, and putting it into code. As you scale, design systems can become quite large and it’s impossible for one person to know everything. You either give into the chaos, or you start a devops practice where people start to think about how we build, release, and the path from designer’s brain to production.The panelists then talk about how to introduce a design system into a company where there are cultural conflicts. Kaelig shares his experience working with SalesForce and introducing a design system there. They discuss what aspects of a design system that would make people want to use it over what the team is currently doing. Usually teams are thankful for the design system. It’s important to build a system that’s complete, flexible, and extensible so that you can adapt it to your team. A good design system incorporates ‘subatomic’ parts like the grid system, color palette, and typography, referred to as design tokens. Design systems enable people to take just the bits of the design system that are interesting to them and build the components that are missing more easily. The conversation turns to the installation and upgrade process of a design system. Upgrading is left up to the customer to do on their own time in most cases, unless it’s one of the big customers. They talk about the role of components in upgrading a design system. Kaelig talks about the possibility of Shopify transitioning to web components. Kaelig shares some of his favorite tools for making a design system and how to get started making one. A lot of design teams start by taking a ton of screen shots and looking at all the inconsistencies.Giving them that visibility is a good thing because it helps get everyone get on the same page. The panelists talk about the role of upper management in developing components and how to prioritize feature development. Kaelig talks about what drives the decision to take a feature out. The two main reasons a feature would be removed is because the company wants to change the way things are done and there’s a different need that has arisen. The show concludes by discussing the possibility of a design system getting bloated over time. Kaelig says that Design systems takes some of the burden off your team, help prevent things from getting bloated, allow you to ship less code. PanelistsChris FerdinandiAimee KnightSteve EmmerichWith special guest: Kaelig Deloumeau-PrigentSponsorsSustain Our SoftwareSentry use the code “devchat” for 2 months free on Sentry’s small plan Adventures in BlockchainLinksShopify PolarisBootstrapReactSketch.uiFigma.ui CSSStoryBookESLintJestEnsignWebpacker Follow DevChatTV on Facebook and Twitter PicksSteve Emmerich:CedarWorks play beds  Azure’s container instancesAimee Knight:Awesome Actions for GithubChris Ferdinandi:Free Meek docuseriesSimplicity: Part 2 by Bastian AllgeierKaelig Deloumeau-Prigent:DependabotInk by Vadim Demedez Follow Kaelig on Twitter @kaeligSpecial Guest: Kaelig Deloumeau-Prigent. Support this podcast at — https://redcircle.com/javascript-jabber/donationsPrivacy & Opt-Out: https://redcircle.com/privacyBecome a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

3 Okt 201939min

Jonathan Lee Martin is an instructor and developer. He got his start in teaching at Big Nerd Ranch doing 1-2 week trainings for mid to senior developers, and then transitioned to 16 week courses for career switchers. He also worked for Digital Crafts for a year, and then wanted to focus on building out his own personal teaching brand. One of his first steps toward building his own brand was to publish his book, Functional Design Patterns for Express.js.The inspiration for Jonathan’s book came from his experience teaching career switchers. He wanted to experiment in the classroom with teaching functional programming in a way that would be very approachable and applicable and dispel some of the magic around backend programming, and that became the template for the book. Jonathan loves the minimalist nature of Express.js and talks about its many uses. He believes that it knowing design patterns can take you pretty far in programming, and this view is related to his background in Rails. When he was working in Rails taming huge middleware stacks, he discovered that applying design patterns made builds take less time. He talks about other situations where knowing design patterns has helped. Express.js leans towards object oriented style over functional programming, and so it takes to these patterns well. Express.js has its shortcomings, and that’s where Jonathan’s favorite library Koa comes into play. The conversation switches back to Jonathan’s book, which is a good way to start learning these higher level concepts. He purposely made it appealing to mid and senior level programmers, but at the same time it does not require a lot of background knowledge. Jonathan talks about his teaching methods that give people a proper appreciation for the tool. Jonathan talks more about why he likes to use Express.js and chose to use it for his book. He cautions that his book is not a book of monads, but rather about being influenced by the idea of composition over inheritance. He talks about the role of middleware in programming. The panel asks about Jonathan’s toolchain and approach to writing books, and he explains how his books are set up to show code. They discuss the different forms required when publishing a book such as epub, MOBI, and PDF. Jonathan found it difficult to distribute his book through Amazon, so he talks about how he built his own server. Charles notes that your method of distributing your book will depend on your goal. If you want to make the most money possible, make your own site. If you want to get it into as many hands as possible, get it on Amazon.Many of the JavaScript Jabber panelists have had experience publishing books, and Jonathan shares that you can reach out to a publisher after you’ve self-published a book and they can get it distributed. Jonathan believes that If he had gone straight to a publisher, he would have gotten overwhelmed and given up on the book, but the step by step process of self-publishing kept things manageable. The panelists discuss difficulties encountered when publishing and editing books, especially with Markdown. Jonathan compares the perks of self-editing to traditional editing. Though he does not plan to opensource his entire editing pipeline, he may make some parts available. The show concludes with the panelists discussing the clout that comes with being a published author. PanelistsCharles Max WoodChristopher Buecheler J.C. HyattWith special guest: Jonathan Lee MartinSponsorsAdventures in BlockchainSentry use the code “devchat” for 2 months free on Sentry’s small plan The Freelancers’ ShowLinksBig Nerd RanchDigital CraftsJSJ 070: Book Club JavaScript Allonge with Reginald BraithwaiteJavaScript Allonge by Reginald BraithwaiteFunctional Design Patterns for Express JS by Jonathan Lee MartinNode.jsExpress.jsKoaMinjs  SinatraHttp.createserverMonadsMiddleware  MarkdownPandocDiff-match-path libraryEpubMOBILaTeX Stripe CheckoutFstoppersSoftcoverBookseller API  Follow DevChatTV on Facebook and Twitter PicksChristopher Buecheler:Cluisbrace.com newsletterJ.C. Hyatt:Corsair wireless charging mouse padCharles Max Wood:Magnetic whiteboard basketsMrs. Piggle-Wiggle booksJonathan Lee Martin:Eric Elliot JSYellowScale Follow Jonathan and find his book at jonathanleemartin.comSpecial Guest: Jonathan Lee Martin. Support this podcast at — https://redcircle.com/javascript-jabber/donationsPrivacy & Opt-Out: https://redcircle.com/privacyBecome a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

1 Okt 201958min

Mike North is the Ember guy at Frontend Masters and LinkedIn’s web developer trainer. Today the panel is talking about the upcoming Ember update, which Mike calls a total reinvention of the way you build with Ember. Finally, they are letting go of the cruft and stuff they had to hold on to in order to support IE8 and using modern interfaceThe panel talks about some of the issues with IE8, and agree that the reason Ember felt its age because it was built for IE8. Ember 314 is moving from the past into the present, a sleek modern way to build apps. Mike talks about how easy the new Ember is to use. Mike talks about the excitement in the Ember community because the new build is focused on stability and seamlessness. Charles talks about his less seamless experience with the Angular community. For context, Mike North’s first frontend masters course was recorded in 2014, and he’s only had to change two lines of code. Ember is the only framework that has managed to go all the way from IE7/IE8 to today without a major gap,breaks, or rewrites.They transition to talking about what keeps Ember going. There is an effort to make sure things are decentralized and not tied to any specific company, although Apple, Netflix, Nasa, and PlaysStation all use it. LinkedIn has also been hiring Ember core member to continue working on it, and sponsoring open source work. Next, they talk about how Ember works with TypeScript. You can install an Ember add on with one terminal command that will enable TypeScript in an Ember app.There are some issues that could cause misalignment with JavaScript and TypeScript, but Ember has designed things around it. MIke talks about the major change in the learning curve with using Ember and how far Vanilla JS will take you. Overall, it is a lot more approachable than it used to be. They move on to talk about the availability of third party solutions with Ember. Mike assures them that Ember has add-ons, and parts of the framework are opening up to allow experimentation with components. There are lots of ways to make Ember your own without running the risk of diverging, giving more flexibility than ever while maintaining the happy path. Testing within Ember is also a priority, and they want the code to be as readable as possible.The last topic discussed in this show is the importance of developer education. LinkedIn looks at employment numbers and the rate at which new jobs open, and software engineering is growing like crazy and will likely continue to grow.The rate at which new people are graduating with computer science and programming degrees, as well as those from unconventional backgrounds, is not keeping up with the number of jobs. This means that there will be fewer senior people spread across bigger groups of developers with less experience. The panel agrees that it is the responsibility of people who have been around or learned something period to pass on the knowledge because the more knowledge is passed on, the more stable things will remain as seniors become more scarce. It is also important for companies to level up junior developers. They conclude by talking about tools available for people who want to learn more about Ember Octane, and Mike makes an open request to the JS community. PanelistsCharles Max WoodSteve EmmerichChris FerdinandiAimee KnightAJ O’NealChristopher BuechelerWith special guest: Mike NorthSponsorsReact Native RadioSentry use the code “devchat” for 2 months free on Sentry’s small plan Dev Ed PodcastLinksEmberFrontend MastersIE8Ember OctaneSprout CoreTypeScriptES6Lodash  MochaBackstop.js  Semverhttps://twitter.com/thefalken/status/1177483501777473537 Follow DevChatTV on Facebook and Twitter PicksChris Ferdinandi:Vanilla JS Academy, get 30% off with code ‘jsjabber’ leanweb.devSteve Emmerich:123 MagicRGDKAimee Knight:Recursion blog postWholesome Provisions Protein CerealAJ O’Neal:Carby V2 by Insurrection IndustriesGameCube ModsCharles Max Wood:Nikon D5600Rode NewsshooterViltrox light panelQuest Nutrition pumpkin barsChristopher Buecheler: Tool’s Fear Inoculum on Apple Music, Spotify, and Google PlayMike North:Github UniverseGithub Tracer Bench Follow Mike @mike-north on Github, @northm on LinkedIn, and @michaellnorth on TwitterSpecial Guest: Mike North. Support this podcast at — https://redcircle.com/javascript-jabber/donationsPrivacy & Opt-Out: https://redcircle.com/privacyBecome a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

26 Sep 20191h 8min