JavaScript Jabber23 Okt 2018

JSJ 336: “The Origin of ESLint” with Nicholas Zakas

Panel:

Special Guests: Nicholas Zakas In this episode, the panel talks with Nicholas Zakas who writes on his site, Human Who Codes. He is the creator of ESLint, also the author of several books, and he blogs, too. He was employed through Box and today he talks about ESLint in full detail! Check it out! Show Topics:0:05 – Advertisement: KENDO UI 0:37 – Hello! The panel is...(Chuck introduces everyone).1:04 – Nicholas who are you?1:17 – Nicholas: Yeah it’s been about 5 years and then you invited me again, but I couldn’t come on to talk about ESLint back then. That’s probably what people know me most for at this point. I created ESLint and I kicked that off and now a great team of people is maintaining it.1:58 – Chuck: What is it?2:04 – It’s a Linter for JavaScript. It falls into the same category as JSLint. The purpose of ESLint is to help you find problems with your code. It has grown quite a bit since I’ve created it. It can help with bugs and enforcing style guides and other things.2:53 – Where did it come from?2:57 – Guest: The idea popped into my head when I worked at Pop. One of my teammates was working on a bug and at that time we were using...Nothing was working and after investigating someone had written a JavaScript code that was using a native code to make an Ajax request. It wasn’t the best practice for the company at the time. For whatever reason the person was unaware of that. When using that native XML...there was a little bit of trickiness to it because it was a wrapper around the...We used a library to work around those situations and add a line (a Linter) for all JavaScript files. It was a text file and when you tried to render code through the process it would run and run the normal expression and it would fail if any of the...matched.I am not comfortable using normal expressions to write code for this. You could be matching in side of a string and it’s not a good way to be checking code for problems. I wanted to find a better way.6:04 – Why did you choose to create a product vs. using other options out there?6:15 – Guest: Both of those weren’t around. JSHint was pretty much the defector tool that everyone was using. My first thought was if JSHint could help with this problem?I went back to look at JSHint and I saw that on their roadmap you could create your own rules, and I thought that’s what we need. Why would I build something new? I didn’t see anything on GitHub and didn’t see the status of that. I wanted to see what the plan was, and they weren’t going to get to it. I said that I really needed this tool and I thought it would be helpful to others, too.8:04 – My history was only back when it was customizable.8:13 – Aimee: It’s interesting to see that they are basing it on regular expressions.8:32 – Guest: Interesting thing at Box was that there was...I am not sure but one of the engineers at Box wrote...9:03 – Aimee: I was going to ask in your opinion what do you think ES Lint is the standard now?9:16 – Guest: How easy it is to plug things in. That was always my goal because I wanted the tool not to be boxed in – in anyway.The guest continues to talk about how pluggable ESLint is and the other features of this tool.13:41 – One thing I like about ESLint is that it can be an educational tool for a team. Did you see that being an educational tool?14:24 – Guest: How do you start introducing new things to a team that is running at full capacity? That is something that I’ve wondered throughout my career. As a result of that, I found that a new team there were some problems I the code base that were really hard to get resolved, because when one person recognizes it there isn’t a god way to share that information within a team in a non-confrontational way. It’s better to get angry at a tool rather than a person.Guest goes into what this can teach people.18:07 – Panelist: I am not surprised. Is there a best practice to get a team to start with ESLint?Do you get the whole team in a room and show them the options or take the best guess and turn it on?18:34 – Guest: The thing I recommend is that first and foremost get ESLint in your system with zero rules on. It starts that mindset into your development process. We can do something to automatically check...Get Syntax checking and you will se improvements on the number of bugs that are getting out of production. I recommend using the default the ESLint configuration. This has all of the things that we have found that are most likely errors and runtime errors vs. syntax errors. You can go through with those and sometimes it is easier to run that check with...Using those ESLint rules will clean up a lot of problems that you didn’t know you had with your code. There are too many problems with those rules. I recommend instead of turning them off then put the severity to warning and not error. That is something we started with in the beginning. We turned on as many rules as we could and it drove people crazy. They didn’t feel like when they were committing to a file why should I be...The idea with the different scenario levels you don’t’ want to turn off rules so people don’t know there is a problem. There can be a rule on so people will know that there is a problem, but...Doing that alone will give you a lot of benefit in using ESLint. How do you decide as a team on the rules that are maybe not for finding errors but for stylistic in error? Do we use four spaces, semi-colons, etc. To figure that out I am a big component on finding a pre-existing style guide and adapting it. Get everyone to agree.There is no right or wrong when it comes to stylistic preferences. It really is just getting everyone to do the same thing. I think it was Crawford that said: Whether you drive on the right side of the left side of the road – it doesn’t matter as long as everyone is dong the same thing. I agree with that and it applies to style guides. It can get heated but for the best thing for the team is stick with a guide and work together.24:36 – Aimee: I can go through the options to pick one of the style guides out there and then it will automatically create my configuration for me is helpful. Question: If you had to pick 2 or 3 rules that you are super helpful what would they be?25:30 – Guest: To touch briefly on indentation. Whether you like four spaces or whether you are wild and like tabs, I think the indent rule is very helpful. Just for wiping out and eliminating that discussion through your team. Have your editor setup however they want but on the pre-hook...But my favorite rules I tend to lean towards the ones that saved me.The Guest goes through his favorite rules with ESLint. Check it out!26:51 – Guest mentions his second favorite rule, here!28:24 – Guest mentions his third favorite rule, here!29:03 – Guest mentions the rule that makes him giggle a lot, here!30:07 – Advertisement – Sentry! 31:22 – What is your take on running Fix? Does it make sense to run Fix?32:00 – Guest: It depends and the idea behind Fix is the idea of doing a one time (at the start) fix everything that it can find wrong b/c I don’t want to do it by hand. It morphed into a more of a tool that people are using all the time. I too have mixed feelings about it. I think the greatest value you get out of Fix is that when you first install it or when you enable a new rule. I think in those situations you get a lot of value out of Fix. I think that when people were getting aggressive with their code styles it took us down a path where we...As a pre-commit hook it could be to fix things and part of the built system you wouldn’t want...People are probably wondering: Why doesn’t ESLint doesn’t fix all the time?It can be a team decision: do you want to run Fix at the point that the developer is writing the code, do you want to use Fix as running it as a build when you are bundling? It really seems more of a personal preference. I am on the fence about it. Even though I am leaning more towards...35:16 – Do you run Premier?35:20 – Guest: No I don’t. I don’t have anything against Premier but I think Prettier uses a very interesting space.37:50 – Chuck: What is next for ESLint and what is next for you?37:55 – Guest: Well, to be honest I am not sure what is next for ESLint. I haven’t been involved with keeping it maintained for the last few years. I do help out with feedback with decisions. But in general the ESLint the direction is that let’s add tings that help people avoid language hazards and make sure that ESLint is still pluggable. Lastly, that we will be there to help people and the community. There is this virtuosic cycle and tools like Babble and then tools like ESLint introducing rules adapting new rules and featur

Become a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

Upptäck Premium

Prova 14 dagar kostnadsfritt

Skaffa Premium

Avsnitt(725)

Exploring Vibe Coding and the Future of Product Management with Gunnar Berger - JSJ 690

In this episode of JavaScript Jabber, I sit down with Amazon product leader Gunnar Berger to dive into the fast-evolving world of vibe coding and how it’s reshaping the relationship between developers and product managers. Gunnar brings a wealth of experience from his years in IT, Citrix, and now Amazon, and shares a unique perspective on how AI tools are changing the way products get built—from idea to prototype.We talk about the shifting role of product managers, how AI is compressing traditional workflows, and what it means for developers, UX designers, and even junior devs entering the industry. From rapid prototyping to AI-assisted documentation, Gunnar opens up about both the opportunities and the challenges this new paradigm introduces. Whether you’re a developer, product manager, or just curious about where AI is taking us, this conversation is packed with insights you won’t want to miss.Links & ResourcesGunnar Berger on LinkedInCloud CodeCursorKiro.devIf you enjoyed this episode, don’t forget to rate, review, and follow JavaScript Jabber on your favorite podcast app. And of course—share it with a friend who’d love to learn more about the future of coding and product management!Become a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

12 Sep 1h 13min

How to Use Web Components, Iframes, and Module Federation for Multi-Framework Apps - JSJ 689

This week on JavaScript Jabber, we dive deep into the challenges and opportunities of mixing and matching frontend frameworks in modern applications. I’m joined by Dan Shapir, Steve Edwards, and our special guest Hadar Geva, CTO and co-founder of Myop.dev. Together, we explore how companies are tackling multi-framework environments, the role of web components and iframes, and why module federation isn’t always as simple as it sounds.We also take a closer look at how AI is changing the way developers and even non-developers generate code, the risks of integrating AI-written components, and strategies for safely managing that code in production. If you’ve ever struggled with legacy frameworks, integrating AI-generated components, or wondered whether web components or local iframes are the better fit—this episode is packed with insights you won’t want to miss.Links & ResourcesMyop.dev – Hadar’s company, building solutions for mixing and managing micro-frontends.Web Awesome – Web components library mentioned during picks.AG Grid – Heavy-duty data grid solution.TanStack Table – Lightweight table solution by Tanner Linsley.ShadCN UI – Component library for modern React apps.Become a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

2 Sep 1h 17min

Why We’re Building the Front End Wrong (and How to Fix It) - JSJ 688

In this episode of JavaScript Jabber, I sit down with Delaney Gilliland to dive into why most of us are building the front end wrong—and what a faster, leaner, and simpler alternative could look like. We explore his background in game development and military applications, which gave him a unique perspective on web performance and real-time data challenges. That perspective ultimately led him to create Datastar, a new framework designed to rethink the way we approach front-end development.We talk about the limitations of SPAs, the promise (and pitfalls) of tools like HTMX and Turbo, and how Datastar builds on web standards to deliver speed, efficiency, and simplicity without the baggage of heavy state management. Whether you’re curious about server-sent events, morphing strategies, or just want to see how front-end development could be done differently, this conversation will get you thinking about the future of the web.Links & ResourcesDatastar official sitehttps://x.com/DelaneyGillilanhttps://github.com/delaneyjBecome a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

28 Aug 46min

Vibe Coding: Building Faster with AI-Powered Development - JSJ 687

In this episode of JavaScript Jabber, we dive deep into the world of vibe coding—what it means, how it works in practice, and why it’s changing the way developers build software. I’m joined by Anthony Campolo, who shares his hands-on experience developing AutoShow, an app that automates podcast show notes, using AI-assisted workflows. We talk about how tools like Claude, ChatGPT, and Gemini accelerate development, the role of rule files, and the balance between automation and manual QA.Along the way, we explore the impact of LLMs on junior vs. senior developers, how companies are adapting AI-driven coding practices, and whether the future of software development still requires humans in the loop. This conversation blends real-world coding insights, practical tools, and some big-picture questions about where AI is taking the industry.Check out Anthony Campolo here.Become a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

22 Aug 1h 11min

The Next Wave of Dev Tools: AI Assistants and JavaScript Workflows - JSJ 686

In this episode of JavaScript Jabber, we sit down with Vinicius Dallacqua, a seasoned software engineer with a passion for performance and developer tooling. Vinicius shares his journey from coding in central Brazil with limited connectivity to building cutting-edge tools like PerfLab and PerfAgent. We dive into the intersection of AI and DevTools, exploring how artificial intelligence is transforming performance debugging, web development workflows, and even the future of browsers.We also tackle the big questions: How do developers avoid bias when building in high-performance environments? What role will agentic browsers play in the evolution of the web? And how can AI-powered DevTools lower the barrier for developers intimidated by performance profiling? If you’re curious about the future of frontend performance, DevTools, and AI-driven development, this conversation is packed with insights.Links & ResourcesPerfLab – Performance tooling platformPerfAgent – AI-powered DevTools assistantVinicius Dallacqua on X (Twitter)Paul Kinlan’s AI Focus – Essays on AI and the webPerfNow Conference – Leading performance conference in AmsterdamBecome a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

14 Aug 1h 6min

Inside VueConf: Nuxt 4, AI in Development, and the Future of Vue with Erik Hanchett - JSJ 685

In this episode of JavaScript Jabber, we welcome back Erik Hanchett, Senior Developer Advocate at AWS, to dive into his experience at VueConf. From the energy of the Vue community to lightning talks on AI and Nuxt updates, Erik shares his insights on where Vue is heading and why in-person conferences are still so valuable for developers. We also explore the balance between “vibe coding” and spec-driven development, plus Erik introduces us to Amazon Q CLI and its powerful MCP integrations for smarter AI-assisted coding.Along the way, we discuss the evolving state of Vue, the rise of Nuxt 4, Evan You’s projects (including Vite and RollDown), and how Amplify is simplifying full-stack app development on AWS. Whether you’re a Vue developer, curious about AI in frontend workflows, or just want to catch up on what’s happening in the broader JavaScript ecosystem, this episode is packed with insights you won’t want to miss.🔗 Links & ResourcesAmazon Q Developer CLI on GitHubAWS Amplify DocumentationCommit Your Code ConferenceErik Hanchett on X (Twitter)Program With Erik YouTube ChannelBecome a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

8 Aug 58min

Running Doom in TypeScript’s Type System with Dimitri Mitropoulos - JSJ 684

What if I told you someone managed to run Doom inside TypeScript’s type system? Sounds insane, right? That’s exactly what our guest Dimitri Mitropoulos did—and in this episode, we dive deep into the how, the why, and the mind-bending implications of this ambitious project. From type-level programming to the philosophical limits of Turing completeness, this is an episode that pushes the boundaries of what you thought was possible in JavaScript.We talk about how the TypeScript type system evolved to become Turing-complete, how Dimitri pulled off this seemingly impossible feat, and why “Doom-complete” might just be the new gold standard for computational capability. Along the way, we touch on functional programming, generics, recursion, and even some Lambda Calculus. It’s part computer science theory, part coding madness, and 100% geeky goodness.Episode Highlights[3:05] – Dimitri explains how a simple thought experiment turned into a year-and-a-half-long obsession[8:40] – The origins and significance of Turing completeness in type systems[14:15] – Why running Doom in TypeScript is more about proving limits than just showing off[19:55] – What it means to run programs inside the type system vs. TypeScript code itself[27:10] – ASCII art as output, functional recursion for game state, and hover-over frames in your editor[35:30] – How ignorance, determination, and obsession fueled the completion of the project[45:20] – Personal insights: balancing family, burnout, and passion while chasing an impossible dreamLinks & ResourcesDimitri MitropoulosMichigan TypeScript YouTube Channel – Dimitri's channel featuring the projectType Challenges by Anthony Fu – Advanced TypeScript exercisesSquiggleConf – The TypeScript-focused conference Dimitri co-foundedJosh Goldberg – TypeScript expert and co-organizer of SquiggleConfBecome a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

1 Aug 1h 18min

Preact, Performance, and the Future of Lightweight Frontends with Ryan Christian -JSJ 683

In this episode of JavaScript Jabber, we sit down with Ryan Christian, a core maintainer of Preact, to talk all things lightweight, performant, and practical in the JavaScript world. If you’ve ever wondered what makes Preact tick, why it continues to gain traction, and how it compares to the heavyweight champ React—this episode is for you.We get into the nitty-gritty of what separates Preact from React, not just in size but in philosophy. Ryan sheds light on how Preact is engineered for performance, why it's not just a “React clone,” and how its compatibility layer makes it easy to drop into existing projects. Plus, we explore signals, class components, and what the upcoming Preact v11 has in store.Episode Highlights[1:23] - Meet Ryan Christian: Preact core maintainer and open-source champion[4:10] - What is Preact, and how does it stack up against React?[10:15] - Preact’s tiny footprint and why size still matters[14:47] - Widgets, adoption, and why Preact powers ~6% of major sites[20:01] - Understanding Preact’s compatibility layer (PreactCompat)[25:40] - Hooks, signals, and modularity: build what you need, nothing more[31:10] - Why Preact won’t follow React into full-stack territory[37:22] - Server components, suspense, and what Ryan recommends instead[43:35] - Frameworks that pair well with Preact: Astro, Fresh, and Remix[47:55] - Sneak peek at Preact v11 and why it sticks with “classic” React experience🔗 Links & ResourcesPreact Official WebsiteAstroFresh by DenoRemixJason Miller’s VTalk on Signals (referenced)Google CrUX Report – for framework usage statsBecome a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

23 Juli 1h 7min

Allt en och samma app

Lyssna på dina favoritpoddar och ljudböcker på ett och samma ställe.

Noga utvalt innehåll

Njut av handplockade tips som passar din smak – utan ändlöst scrollande.

Fortsätt när du vill

Fortsätt lyssna där du slutade – även offline.

Premium

99 kr/mån

Tillgång till alla Premium-poddar
Lyssna utan reklam
Avsluta när du vill

Prova 14 dagar gratis

Premium

129 kr/mån

Tillgång till alla Premium-poddar
Lyssna utan reklam
Avsluta när du vill
Ett extra konto

Prova 14 dagar gratis

Populärt inom Business & ekonomi

rikatillsammans-om-privatekonomi-rikedom-i-livet

Berättelserna och rösterna du älskar att lyssna på

Obegränsad lyssning på alla dina favoritpoddar och ljudböcker

Upptäck Premium