JSJ 267 Node 8 with Mikeal Rogers, Arunesh Chandra, and Anna Henningsen
JavaScript Jabber27 Kesä 2017

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

JSJ 267 Node 8 with Mikeal Rogers, Arunesh Chandra, and Anna HenningsenOn 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 https://www.npmjs.com/package/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 https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey
- https://github.com/mozilla/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
- https://turboc.codeplex.com/ 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 call

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

Jaksot(734)

The Comeback of RPC: SolidJS, TanStack, and the Future of JavaScript Frameworks with Ryan Carniato & Tanner Linsley - JSJ 691

The Comeback of RPC: SolidJS, TanStack, and the Future of JavaScript Frameworks with Ryan Carniato & Tanner Linsley - JSJ 691

In this episode of JavaScript Jabber, I sit down with Ryan Carniato, creator of SolidJS, and Tanner Linsley, the force behind TanStack, for a deep-dive conversation on the resurgence of Remote Procedure Calls (RPC) in modern web development. We explore why RPC is making a comeback, how frameworks like Solid, TanStack, and others are shaping the way we think about data fetching, and the technical innovations that are driving this movement forward.From streaming and serialization to type safety and the future of client-server communication, Ryan and Tanner share their experiences, insights, and the unique challenges they’ve faced building cutting-edge tools for developers. If you’ve been curious about where RPC fits in today’s frameworks—or just love geeking out about performance, signals, and developer experience—this is one episode you won’t want to miss.Links & ResourcesRyan Carniato on SolidJSTanStack (React Query, Router, Table, and more)Sentry – where Ryan is currently workingCreate TanStackSolidJS DiscordRyan CarniatoRyan Carniato is the creator of SolidJS, a high-performance JavaScript framework built on fine-grained reactivity. He’s also a Senior Software Engineer at Sentry, where he explores new approaches to front-end architecture and developer experience. Through his open-source contributions, talks, and in-depth content, Ryan has become a trusted voice in the web development community, helping developers think differently about building fast, reactive applications.Tanner LinsleyTanner Linsley is the founder of TanStack, the home of widely adopted open-source libraries like TanStack Query (formerly React Query), TanStack Router, Table, Virtual, and more. A full-time open-source entrepreneur, Tanner has redefined how developers manage state, caching, and data fetching in modern applications. With a focus on performance, simplicity, and type safety, his tools power some of the most advanced applications on the web today.Become a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

22 Syys 1h 29min

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

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 Syys 1h 13min

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

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 Syys 1h 17min

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

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 Elo 46min

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

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 Elo 1h 11min

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

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 Elo 1h 6min

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

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 Elo 58min

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

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 Elo 1h 18min

Suosittua kategoriassa Liike-elämä ja talous

sijotuskasti
psykopodiaa-podcast
rss-rahapodi
mimmit-sijoittaa
ostan-asuntoja-podcast
pomojen-suusta
rss-lahtijat
rss-bisnesta-bebeja
rss-sisalto-kuntoon
inderespodi
taloudellinen-mielenrauha
yrittaja
rss-startup-ministerio
rss-seuraava-potilas
rss-paasipodi
pari-sanaa-lastensuojelusta
bakkari-tarinoita-tapahtumien-takahuoneista
rss-markkinointiradio
rss-lindholm-savolainen
rss-podcast-podcasteista