JSJ 334: “Web Performance API” with Dan Shappir

JSJ 334: “Web Performance API” with Dan Shappir

Panel: Special Guests: Dan Shappir (Tel Aviv)In this episode, the panel talks with Dan Shappir who is a computer software developer and performance specialist at Wix.com. As Dan states, his job is to make 100 million websites (hosted on the Wix platform) load and execute faster! Past employment includes working for companies, such as: Ericom, Ericom Software, and BackWeb. He studied at Technion Institute of Management and currently lives in Tel Aviv, Israel. The panel talks about web performance API among other things. Check it out!Show Topics:1:29 – Charles: Let us know who you are and why you’re famous!1:39 – “Hello!” from Dan Shappir.2:25 – Charles: You should say that you go to EACH site EVERY day out of the millions of sites out there.2:53 – Charles: My mom mentioned Wix to me at first. My mom teaches High School Math.3:16 – Dan: Yes that is our mission statement. That everyone can get a website without the knowledge of how to build a website.3:52 – Aimee makes her comments.3:59 – Dan: On our platform we try to offer people flexibility. There are bounds and limits, but people can do their very own thing, though. To make Wix faster because as we add more features and functionality that is our goal.4:40 – Chuck: Okay, I know how to make X perform a little bit better. You are looking at a platform that controls TONS of sites, how do you even go about that?4:58 – Dan: It is more difficult then that. We have millions of users leveraging the platform but there are a lot of developers in Wix who are developing the platform. I don’t think anyone at Wix has a total grasp of the complexity of the platform that we built. We have hundreds of frontend people working on our platform. All of them have pieces to the kingdom. We have processes in place with code reviews and whatnot, but there is so much going on. There is a change every 2 minutes, 24/7. We need to make sure progressing instead of regressing. 6:54 – Aimee: I think it was interesting in one of the links you sent over. Because you know when something is getting worse you consider that a bug.7:15 – Dan: It is more than a bug because if we see regression in performance then that is a problem. I can literally see any part of the organization and say, “stop” if it will7:57 – Chuck: We are talking about performance, but what does that mean? What measures are there?8:15: Dan: We are looking at performance can mean different things in different contents. User sites, for example, most important aspect is load time. How quickly the page loads and gets open to the viewer to that specific site. When they click something they want it instantly and no drag time. It does change in different contexts.9:58 – Chuck: People do talk about load time. People have different definitions of it.10:12: Dan: Excellent question. When you look at the different sites through Wix. Different people who build sites – load time can mean something else to everybody. It can mean when you see the MAIN text or the MAIN image. If it’s on an ECON site then how soon can they purchase or on a booking site, how long can the person book X product.I heard someone at a conference say that load time is when: HERO TEXT And HERO IMAGE are displayed.12:14 – Chuck: What is faster React or Vue?12:21 – NEW HOST: Not sure. It all depends.12:34 – Dan: We are big into React. We are one of the big React users outside of Facebook. I joined Wix four years ago, and even back then we were rebuilding our framework using React. One of our main modifications is because we wanted to do server-side rendered.13:27 – Christopher asks Dan a question.14:16 – Dan: We are in transition in this regard. Before we were totally client-site rendered, and that was the case until middle of last year. Then we deployed...Dan: We are 100% server-side rendered now. Some things we are still using JavaScript. We have another project going on now and it’s fully CSS, and little JavaScript as possible. What you might want to do with that site is...You might get in a few months every Wix site will be visible even if JavaScript is disabled.16:26 – Aimee adds in her comments and observations to this topic.16:55 – Dan: We don’t want things displayed incorrectly before it lays out. We hide the content while it’s downloading then make it visible. They lay-outing are done faster, because...17:44 – Christopher asks Dan a question.18:04 – Dan: I got into API...Either you are moving forward or are you moving back. AKA – You are either progressing or regressing.Different stages:1.) Development stage2.) Pre-Production (automated tools that check the performance with specific use cases)3.) Check it out!It’s beneficial to use these APIs.21:11 – Christopher: What is performance APIs?21:38 – Dan: There is a working group – Todd from Microsoft and others who are exposing the information (that is available in the browser) out into the browser. When the browser downloads a certain source (image, font, etc.) it can measure the various stages of downloading that feature. You have these different sages of downloading this resource. The browser can measure each of these stages and then expose them to you. Basically it’s for the browser to expose this information to you and in a way that is coherent and uniform. It essentially maintains this buffer that puts performance entries sequentially.Dan continues explaining this topic in detail.25:55 – Dan: You have this internal buffer...28:45 – Advertisement – Sentry – They support opensource.29:39 – Christopher: everything you are saying seems that I can use this or that tab right now...Why would I prefer the API to something visual, hypothetically?30:03 – Dan: Three Different Stages. (See above.)This information is very, very helpful during the developmental stage. Say you got a link from someone...Dan mentions: Performance.mark 34:04 – Aimee: When you were talking about resource-ends. Many people don’t know what this is. Can you spend 2-3 minutes about how you guys are using these? Are there people can add for big bang for their buck?34:41 – Dan: This might want to be a topic for its own podcast show.Dan gives a definition of what a resource-end means.Go back to fonts as an example.Pre-connect for example, too.39:03 – Dan: Like I said, it’s a huge topic.You have to exercise some care. Bandwidth is limited. Make sure you aren’t blocking other resources that you do need right now.40:02 – Aimee: Sounds like a lot of great things to tap into. Another question I have is about bundling.40:27 – Dan: One of the things that we try to do (given that we are depending on the JavaScript we are downloading) we need to download JavaScript content to the client side. It has been shown often that JS is the most impactful resources that you need to download. You really want to be as smart as possible with that. What is even more challenging is the network protocols are changing.Dan continues to go in-depth about this topic. Dan: What we have found is that you want to strive to bundle resources together.44:10 – Aimee: Makes sense.44:15 – Dan continues talking about this topic.45:23 – Chuck asks two questions. (First question is now and second question is at 51:32.)2 Questions:1. You gather information from web performance AI - What system is that?45:42 – Dan: I am not the expert in that. I will try not to give misleading information. Actually let me phrase it different. There are 3rd party tools that you can use leverage in your website. IF you are building for commercial reasons I highly recommend that you use performance-monitoring solution. I am not going to advertise one because there are tons out there. We ended up rolling out our own infrastructure because our use case is different than most.At a conference I talked with a vendor and we talked about...51:32 – 2nd Question from Charles to Dan: Now you’ve gathered this information now what to you do? What patterns? What do you look for? And how do you decide to optimize things?54:23 – Chuck: Back to that question, Dan. How should they react to it and what are they looking for54:41 – Dan: Three main ways: 1.) Generate alerts 2.) See trends over long period of time 3.) Looking at real-time graphs.Frontend developer pro is that likely being woken up in the middle of the night is lower. We might be looking at the real time graph after we deployed...57:31 – Advertisement – Get a Coder Job!58:10 – Picks!Links:

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

Avsnitt(725)

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

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

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

Populärt inom Business & ekonomi

framgangspodden
varvet
badfluence
svd-ledarredaktionen
rss-borsens-finest
uppgang-och-fall
avanzapodden
lastbilspodden
rss-dagen-med-di
fill-or-kill
affarsvarlden
rss-kort-lang-analyspodden-fran-di
borsmorgon
rikatillsammans-om-privatekonomi-rikedom-i-livet
tabberaset
kapitalet-en-podd-om-ekonomi
dynastin
market-makers
borslunch-2
rss-inga-dumma-fragor-om-pengar