POPULARITY
Peter Pistorius, co-creator of RedwoodJS, talks about the evolution from RedwoodJS GraphQL to the new Redwood SDK, a React framework built for Cloudflare. They dive deep into serverless architecture, React Server Components, durable objects, AI-assisted development, and the challenges of modern deployment and hosting. Learn how Redwood SDK is empowering developers to focus on building and shipping, instead of managing infrastructure. Links https://rw-sdk.com http://peterp.org https://github.com/peterp https://bsky.app/profile/p4p8.bsky.social https://x.com/appfactory https://cursor.sh https://neon.tech Resources https://rwsdk.com We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Em, at emily.kochanek@logrocket.com (mailto:emily.kochanek@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket's Galileo AI watches user sessions for you and surfaces the technical and usability issues holding back your web and mobile apps. Understand where your users are struggling by trying it for free at LogRocket.com (https://logrocket.com/signup/?pdr).
How do you structure and run the perfect tech conference? What things are involved behind the scenes that attendees don't see? What advice would you give to someone looking to start their own event? We're glad you asked! This episode is an All Day Hey! Special where hosts, Josh and James spill the beans on what goes on behind the All Day Hey! conference curtain, how we can collectively safeguard the future of events and what makes running a tech conference like this so special. Join us in Leeds on Thursday, 1st May for this year's All Day Hey! Tickets and schedule at https://heypresents.com/conferences/2025 00:00 How to run a conference 01:00 Why start a conference? - The aim behind All Day Hey! 02:00 What do you want to provide for the audience? 03:00 Avoiding trends and providing backed knowledge 04:00 How to plan the day of talks to keep people engaged? 05:00 Dealing with technical blunders 07:00 Process of picking speakers and who to contact 08:00 Avoiding talks being sponsored ads 11:00 Getting diversity of topic and idea 12:00 All Day Hey! is community focussed - how to create this? 13:00 How to open up the networking and make it welcoming 14:00 How to close a conference to provoke questions 15:00 Tips for other organisers 16:00 Investing in production quality 17:00 Setting up a conference in 2025 19:00 Keeping the indie conference alive Find out more about Stac and Parallax: * https://stac.works (https://stac.works) * https://parall.ax (https://parall.ax)
What is a discovery workshop and how can they be used to work through problems in your business? In this episode, James and Josh discuss how they've run them in the past and offer some tips and tricks to getting the most out of these sessions. Listen now for a brand new instalment of Off Script! 00:00 Introduction 01:00 What is a discovery workshop 02:00 Using Miro 02:30 Slideument - slide deck with a documents worth of content 03:00 Use the right medium to foster discussion 04:00 Break workshop sessions into two 05:00 Use other physical spaces to inspire 06:00 Framing the problem but not steering 07:00 Amazon's idea - Write the Press Release 08:00 What are the challenges, resources, and politics? 09:00 What would the bad press be? 10:00 How to be honest and open? 11:00 Creating a safe environment 14:00 Find out what they want from the session 16:00 90 min cycles of energy 17:00 Risk register 18:00 Walk and talk to reenergise 20:00 Keeping discussions on track 21:00 Capturing and processing the data 22:00 Using AI to digitise and distribute 23:00 The next steps 23:30 One Two Three All 26:00 Handy thing to do to unblock Find out more about Stac and Parallax: * https://stac.works (https://stac.works) * https://parall.ax (https://parall.ax)
Join Amy, Brad, and special guest Ryan Chenkie as they unpack Prisma's expanding ecosystem of database tools. Ryan explains why Prisma launched their own hosted Postgres service and what sets it apart from competitors in the space. The trio examines Prisma's comprehensive feature set including Accelerate for connection pooling, Pulse for real-time events, and optimization tools that help identify performance bottlenecks. They also discuss the upcoming transition from Rust to TypeScript for Prisma's core engine, making it lighter and faster. If you've been curious about modern approaches to database management or wondering which ORM is right for your next project, this conversation provides practical insights and expert perspectives.Show Notes0:00 - Intro1:12 - Working with Prisma and Supabase2:29 - Prisma Postgres Introduction4:17 - Why Choose Postgres6:36 - Prisma's Database Adapter Flexibility8:14 - Serverless Database Architecture11:13 - Connection Pooling with Accelerate14:13 - Pulse for Real-time Database Events16:54 - Studio Integration in Prisma Console18:01 - Database Optimization Tools20:00 - Benefits of Prisma Schema Language22:10 - Prisma Schema vs SQL Definitions23:01 - Comparing Prisma and Drizzle26:24 - Future Improvements to Prisma28:52 - Ryan's History with Prisma32:05 - Learning Resources for Prisma33:37 - Picks and PlugsLinks and ResourcesPrisma ResourcesPrisma WebsitePrisma Twitter/XPrisma YouTube ChannelPrisma Postgres DocumentationPrisma ConsolePrisma VS Code ExtensionPrisma AcceleratePrisma PulsePrisma OptimizePrisma StudioRyan Chenkie ResourcesRyan's Website: https://holodeck.runRyan's YouTube Channel: https://youtube.com/@holodeck_runRyan on Twitter/XFramework and Technologies MentionedRemixRedwood JSSupabasePlanetScaleDrizzle ORMPostgresMySQLMongoDBBrad's ResourcesYouTube Channel: https://youtube.com/@bradgarropyRemix Starter: https://github.com/bradgarropy/remix-appAmy's ResourcesBuild12 Projects: https://buildtwelve.comOther Resources MentionedSkylight FrameAura FrameNetflix Show: "Making Fun"Netflix Show: "Is It Cake"
In this episode of the Ardan Labs Podcast, host Bill Kennedy speaks with Delaney Gillilan about his work with NATS and the development of Datastar, a hypermedia framework that blends server-side rendering with the power of a full-stack SPA. Delaney shares his journey from performing in Vegas to tech startups, his experience in real-time systems and 3D design, and the challenges of data management in modern development. They also discuss AI integration, Web 4.0, and the future of reactive web applications.00:00 Introduction02:34 What is Delaney Doing Today?10:44 Frontend Innovation21:29 Background and Early Computer Experiences31:00 Transition to 3D Design39:10 Moving to Game Development44:00 Writing Code that Lasts48:30 Casino Logistics56:30 Military Experience / Frontend Work1:02:30 Datastar in Modern Development1:17:30 Future Directions / Closing1:26:30 Contact InfoConnect with Delaney: Linkedin: https://www.linkedin.com/in/delaney-gillilan-338734a8/X: https://x.com/DelaneyGillilanMentioned in this Episode:Datastar : https://data-star.dev/ Want more from Ardan Labs? You can learn Go, Kubernetes, Docker & more through our video training, live events, or through our blog!Online Courses : https://ardanlabs.com/education/ Live Events : https://www.ardanlabs.com/live-training-events/ Blog : https://www.ardanlabs.com/blog Github : https://github.com/ardanlabs
Guy Royse, dev advocate at Redis, discusses going beyond the cache with Redis and Node.js. He explores its capabilities as a memory-first database, session management, and even fun use cases like the Bigfoot Tracker API. He also shares insights on Redis OM for object mapping and its future in the JavaScript ecosystem. Links http://guyroyse.com http://github.com/guyroyse https://www.twitch.tv/guyroyse https://www.youtube.com/channel/UCNt5SDc6LosO41E77jr59cQ https://x.com/guyroyse https://www.linkedin.com/in/groyse https://2024.connect.tech/session/693665 We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understand where your users are struggling by trying it for free at [LogRocket.com]. Try LogRocket for free today.(https://logrocket.com/signup/?pdr) Special Guest: Guy Royse.
We cover how the Shadow DOM encapsulates styles and behavior, why it matters for Drupal theming, and how Web Components fit into modern workflows.
Single Directory Components (SDC) in Drupal 10 are transforming theming by simplifying component structure, improving maintainability, and enhancing developer experience.
If you're in SF, join us tomorrow for a fun meetup at CodeGen Night!If you're in NYC, join us for AI Engineer Summit! The Agent Engineering track is now sold out, but 25 tickets remain for AI Leadership and 5 tickets for the workshops. You can see the full schedule of speakers and workshops at https://ai.engineer!It's exceedingly hard to introduce someone like Bret Taylor. We could recite his Wikipedia page, or his extensive work history through Silicon Valley's greatest companies, but everyone else already does that.As a podcast by AI engineers for AI engineers, we had the opportunity to do something a little different. We wanted to dig into what Bret sees from his vantage point at the top of our industry for the last 2 decades, and how that explains the rise of the AI Architect at Sierra, the leading conversational AI/CX platform.“Across our customer base, we are seeing a new role emerge - the role of the AI architect. These leaders are responsible for helping define, manage and evolve their company's AI agent over time. They come from a variety of both technical and business backgrounds, and we think that every company will have one or many AI architects managing their AI agent and related experience.”In our conversation, Bret Taylor confirms the Paul Buchheit legend that he rewrote Google Maps in a weekend, armed with only the help of a then-nascent Google Closure Compiler and no other modern tooling. But what we find remarkable is that he was the PM of Maps, not an engineer, though of course he still identifies as one. We find this theme recurring throughout Bret's career and worldview. We think it is plain as day that AI leadership will have to be hands-on and technical, especially when the ground is shifting as quickly as it is today:“There's a lot of power in combining product and engineering into as few people as possible… few great things have been created by committee.”“If engineering is an order taking organization for product you can sometimes make meaningful things, but rarely will you create extremely well crafted breakthrough products. Those tend to be small teams who deeply understand the customer need that they're solving, who have a maniacal focus on outcomes.”“And I think the reason why is if you look at like software as a service five years ago, maybe you can have a separation of product and engineering because most software as a service created five years ago. I wouldn't say there's like a lot of technological breakthroughs required for most business applications. And if you're making expense reporting software or whatever, it's useful… You kind of know how databases work, how to build auto scaling with your AWS cluster, whatever, you know, it's just, you're just applying best practices to yet another problem. "When you have areas like the early days of mobile development or the early days of interactive web applications, which I think Google Maps and Gmail represent, or now AI agents, you're in this constant conversation with what the requirements of your customers and stakeholders are and all the different people interacting with it and the capabilities of the technology. And it's almost impossible to specify the requirements of a product when you're not sure of the limitations of the technology itself.”This is the first time the difference between technical leadership for “normal” software and for “AI” software was articulated this clearly for us, and we'll be thinking a lot about this going forward. We left a lot of nuggets in the conversation, so we hope you'll just dive in with us (and thank Bret for joining the pod!)Timestamps* 00:00:02 Introductions and Bret Taylor's background* 00:01:23 Bret's experience at Stanford and the dot-com era* 00:04:04 The story of rewriting Google Maps backend* 00:11:06 Early days of interactive web applications at Google* 00:15:26 Discussion on product management and engineering roles* 00:21:00 AI and the future of software development* 00:26:42 Bret's approach to identifying customer needs and building AI companies* 00:32:09 The evolution of business models in the AI era* 00:41:00 The future of programming languages and software development* 00:49:38 Challenges in precisely communicating human intent to machines* 00:56:44 Discussion on Artificial General Intelligence (AGI) and its impact* 01:08:51 The future of agent-to-agent communication* 01:14:03 Bret's involvement in the OpenAI leadership crisis* 01:22:11 OpenAI's relationship with Microsoft* 01:23:23 OpenAI's mission and priorities* 01:27:40 Bret's guiding principles for career choices* 01:29:12 Brief discussion on pasta-making* 01:30:47 How Bret keeps up with AI developments* 01:32:15 Exciting research directions in AI* 01:35:19 Closing remarks and hiring at Sierra Transcript[00:02:05] Introduction and Guest Welcome[00:02:05] Alessio: Hey everyone, welcome to the Latent Space Podcast. This is Alessio, partner and CTO at Decibel Partners, and I'm joined by my co host swyx, founder of smol.ai.[00:02:17] swyx: Hey, and today we're super excited to have Bret Taylor join us. Welcome. Thanks for having me. It's a little unreal to have you in the studio.[00:02:25] swyx: I've read about you so much over the years, like even before. Open AI effectively. I mean, I use Google Maps to get here. So like, thank you for everything that you've done. Like, like your story history, like, you know, I think people can find out what your greatest hits have been.[00:02:40] Bret Taylor's Early Career and Education[00:02:40] swyx: How do you usually like to introduce yourself when, you know, you talk about, you summarize your career, like, how do you look at yourself?[00:02:47] Bret: Yeah, it's a great question. You know, we, before we went on the mics here, we're talking about the audience for this podcast being more engineering. And I do think depending on the audience, I'll introduce myself differently because I've had a lot of [00:03:00] corporate and board roles. I probably self identify as an engineer more than anything else though.[00:03:04] Bret: So even when I was. Salesforce, I was coding on the weekends. So I think of myself as an engineer and then all the roles that I do in my career sort of start with that just because I do feel like engineering is sort of a mindset and how I approach most of my life. So I'm an engineer first and that's how I describe myself.[00:03:24] Bret: You majored in computer[00:03:25] swyx: science, like 1998. And, and I was high[00:03:28] Bret: school, actually my, my college degree was Oh, two undergrad. Oh, three masters. Right. That old.[00:03:33] swyx: Yeah. I mean, no, I was going, I was going like 1998 to 2003, but like engineering wasn't as, wasn't a thing back then. Like we didn't have the title of senior engineer, you know, kind of like, it was just.[00:03:44] swyx: You were a programmer, you were a developer, maybe. What was it like in Stanford? Like, what was that feeling like? You know, was it, were you feeling like on the cusp of a great computer revolution? Or was it just like a niche, you know, interest at the time?[00:03:57] Stanford and the Dot-Com Bubble[00:03:57] Bret: Well, I was at Stanford, as you said, from 1998 to [00:04:00] 2002.[00:04:02] Bret: 1998 was near the peak of the dot com bubble. So. This is back in the day where most people that they're coding in the computer lab, just because there was these sun microsystems, Unix boxes there that most of us had to do our assignments on. And every single day there was a. com like buying pizza for everybody.[00:04:20] Bret: I didn't have to like, I got. Free food, like my first two years of university and then the dot com bubble burst in the middle of my college career. And so by the end there was like tumbleweed going to the job fair, you know, it was like, cause it was hard to describe unless you were there at the time, the like level of hype and being a computer science major at Stanford was like, A thousand opportunities.[00:04:45] Bret: And then, and then when I left, it was like Microsoft, IBM.[00:04:49] Joining Google and Early Projects[00:04:49] Bret: And then the two startups that I applied to were VMware and Google. And I ended up going to Google in large part because a woman named Marissa Meyer, who had been a teaching [00:05:00] assistant when I was, what was called a section leader, which was like a junior teaching assistant kind of for one of the big interest.[00:05:05] Bret: Yes. Classes. She had gone there. And she was recruiting me and I knew her and it was sort of felt safe, you know, like, I don't know. I thought about it much, but it turned out to be a real blessing. I realized like, you know, you always want to think you'd pick Google if given the option, but no one knew at the time.[00:05:20] Bret: And I wonder if I'd graduated in like 1999 where I've been like, mom, I just got a job at pets. com. It's good. But you know, at the end I just didn't have any options. So I was like, do I want to go like make kernel software at VMware? Do I want to go build search at Google? And I chose Google. 50, 50 ball.[00:05:36] Bret: I'm not really a 50, 50 ball. So I feel very fortunate in retrospect that the economy collapsed because in some ways it forced me into like one of the greatest companies of all time, but I kind of lucked into it, I think.[00:05:47] The Google Maps Rewrite Story[00:05:47] Alessio: So the famous story about Google is that you rewrote the Google maps back in, in one week after the map quest quest maps acquisition, what was the story there?[00:05:57] Alessio: Is it. Actually true. Is it [00:06:00] being glorified? Like how, how did that come to be? And is there any detail that maybe Paul hasn't shared before?[00:06:06] Bret: It's largely true, but I'll give the color commentary. So it was actually the front end, not the back end, but it turns out for Google maps, the front end was sort of the hard part just because Google maps was.[00:06:17] Bret: Largely the first ish kind of really interactive web application, say first ish. I think Gmail certainly was though Gmail, probably a lot of people then who weren't engineers probably didn't appreciate its level of interactivity. It was just fast, but. Google maps, because you could drag the map and it was sort of graphical.[00:06:38] Bret: My, it really in the mainstream, I think, was it a map[00:06:41] swyx: quest back then that was, you had the arrows up and down, it[00:06:44] Bret: was up and down arrows. Each map was a single image and you just click left and then wait for a few seconds to the new map to let it was really small too, because generating a big image was kind of expensive on computers that day.[00:06:57] Bret: So Google maps was truly innovative in that [00:07:00] regard. The story on it. There was a small company called where two technologies started by two Danish brothers, Lars and Jens Rasmussen, who are two of my closest friends now. They had made a windows app called expedition, which had beautiful maps. Even in 2000.[00:07:18] Bret: For whenever we acquired or sort of acquired their company, Windows software was not particularly fashionable, but they were really passionate about mapping and we had made a local search product that was kind of middling in terms of popularity, sort of like a yellow page of search product. So we wanted to really go into mapping.[00:07:36] Bret: We'd started working on it. Their small team seemed passionate about it. So we're like, come join us. We can build this together.[00:07:42] Technical Challenges and Innovations[00:07:42] Bret: It turned out to be a great blessing that they had built a windows app because you're less technically constrained when you're doing native code than you are building a web browser, particularly back then when there weren't really interactive web apps and it ended up.[00:07:56] Bret: Changing the level of quality that we [00:08:00] wanted to hit with the app because we were shooting for something that felt like a native windows application. So it was a really good fortune that we sort of, you know, their unusual technical choices turned out to be the greatest blessing. So we spent a lot of time basically saying, how can you make a interactive draggable map in a web browser?[00:08:18] Bret: How do you progressively load, you know, new map tiles, you know, as you're dragging even things like down in the weeds of the browser at the time, most browsers like Internet Explorer, which was dominant at the time would only load two images at a time from the same domain. So we ended up making our map tile servers have like.[00:08:37] Bret: Forty different subdomains so we could load maps and parallels like lots of hacks. I'm happy to go into as much as like[00:08:44] swyx: HTTP connections and stuff.[00:08:46] Bret: They just like, there was just maximum parallelism of two. And so if you had a map, set of map tiles, like eight of them, so So we just, we were down in the weeds of the browser anyway.[00:08:56] Bret: So it was lots of plumbing. I can, I know a lot more about browsers than [00:09:00] most people, but then by the end of it, it was fairly, it was a lot of duct tape on that code. If you've ever done an engineering project where you're not really sure the path from point A to point B, it's almost like. Building a house by building one room at a time.[00:09:14] Bret: The, there's not a lot of architectural cohesion at the end. And then we acquired a company called Keyhole, which became Google earth, which was like that three, it was a native windows app as well, separate app, great app, but with that, we got licenses to all this satellite imagery. And so in August of 2005, we added.[00:09:33] Bret: Satellite imagery to Google Maps, which added even more complexity in the code base. And then we decided we wanted to support Safari. There was no mobile phones yet. So Safari was this like nascent browser on, on the Mac. And it turns out there's like a lot of decisions behind the scenes, sort of inspired by this windows app, like heavy use of XML and XSLT and all these like.[00:09:54] Bret: Technologies that were like briefly fashionable in the early two thousands and everyone hates now for good [00:10:00] reason. And it turns out that all of the XML functionality and Internet Explorer wasn't supporting Safari. So people are like re implementing like XML parsers. And it was just like this like pile of s**t.[00:10:11] Bret: And I had to say a s**t on your part. Yeah, of[00:10:12] Alessio: course.[00:10:13] Bret: So. It went from this like beautifully elegant application that everyone was proud of to something that probably had hundreds of K of JavaScript, which sounds like nothing. Now we're talking like people have modems, you know, not all modems, but it was a big deal.[00:10:29] Bret: So it was like slow. It took a while to load and just, it wasn't like a great code base. Like everything was fragile. So I just got. Super frustrated by it. And then one weekend I did rewrite all of it. And at the time the word JSON hadn't been coined yet too, just to give you a sense. So it's all XML.[00:10:47] swyx: Yeah.[00:10:47] Bret: So we used what is now you would call JSON, but I just said like, let's use eval so that we can parse the data fast. And, and again, that's, it would literally as JSON, but at the time there was no name for it. So we [00:11:00] just said, let's. Pass on JavaScript from the server and eval it. And then somebody just refactored the whole thing.[00:11:05] Bret: And, and it wasn't like I was some genius. It was just like, you know, if you knew everything you wished you had known at the beginning and I knew all the functionality, cause I was the primary, one of the primary authors of the JavaScript. And I just like, I just drank a lot of coffee and just stayed up all weekend.[00:11:22] Bret: And then I, I guess I developed a bit of reputation and no one knew about this for a long time. And then Paul who created Gmail and I ended up starting a company with him too, after all of this told this on a podcast and now it's large, but it's largely true. I did rewrite it and it, my proudest thing.[00:11:38] Bret: And I think JavaScript people appreciate this. Like the un G zipped bundle size for all of Google maps. When I rewrote, it was 20 K G zipped. It was like much smaller for the entire application. It went down by like 10 X. So. What happened on Google? Google is a pretty mainstream company. And so like our usage is shot up because it turns out like it's faster.[00:11:57] Bret: Just being faster is worth a lot of [00:12:00] percentage points of growth at a scale of Google. So how[00:12:03] swyx: much modern tooling did you have? Like test suites no compilers.[00:12:07] Bret: Actually, that's not true. We did it one thing. So I actually think Google, I, you can. Download it. There's a, Google has a closure compiler, a closure compiler.[00:12:15] Bret: I don't know if anyone still uses it. It's gone. Yeah. Yeah. It's sort of gone out of favor. Yeah. Well, even until recently it was better than most JavaScript minifiers because it was more like it did a lot more renaming of variables and things. Most people use ES build now just cause it's fast and closure compilers built on Java and super slow and stuff like that.[00:12:37] Bret: But, so we did have that, that was it. Okay.[00:12:39] The Evolution of Web Applications[00:12:39] Bret: So and that was treated internally, you know, it was a really interesting time at Google at the time because there's a lot of teams working on fairly advanced JavaScript when no one was. So Google suggest, which Kevin Gibbs was the tech lead for, was the first kind of type ahead, autocomplete, I believe in a web browser, and now it's just pervasive in search boxes that you sort of [00:13:00] see a type ahead there.[00:13:01] Bret: I mean, chat, dbt[00:13:01] swyx: just added it. It's kind of like a round trip.[00:13:03] Bret: Totally. No, it's now pervasive as a UI affordance, but that was like Kevin's 20 percent project. And then Gmail, Paul you know, he tells the story better than anyone, but he's like, you know, basically was scratching his own itch, but what was really neat about it is email, because it's such a productivity tool, just needed to be faster.[00:13:21] Bret: So, you know, he was scratching his own itch of just making more stuff work on the client side. And then we, because of Lars and Yen sort of like setting the bar of this windows app or like we need our maps to be draggable. So we ended up. Not only innovate in terms of having a big sync, what would be called a single page application today, but also all the graphical stuff you know, we were crashing Firefox, like it was going out of style because, you know, when you make a document object model with the idea that it's a document and then you layer on some JavaScript and then we're essentially abusing all of this, it just was running into code paths that were not.[00:13:56] Bret: Well, it's rotten, you know, at this time. And so it was [00:14:00] super fun. And, and, you know, in the building you had, so you had compilers, people helping minify JavaScript just practically, but there is a great engineering team. So they were like, that's why Closure Compiler is so good. It was like a. Person who actually knew about programming languages doing it, not just, you know, writing regular expressions.[00:14:17] Bret: And then the team that is now the Chrome team believe, and I, I don't know this for a fact, but I'm pretty sure Google is the main contributor to Firefox for a long time in terms of code. And a lot of browser people were there. So every time we would crash Firefox, we'd like walk up two floors and say like, what the hell is going on here?[00:14:35] Bret: And they would load their browser, like in a debugger. And we could like figure out exactly what was breaking. And you can't change the code, right? Cause it's the browser. It's like slow, right? I mean, slow to update. So, but we could figure out exactly where the bug was and then work around it in our JavaScript.[00:14:52] Bret: So it was just like new territory. Like so super, super fun time, just like a lot of, a lot of great engineers figuring out [00:15:00] new things. And And now, you know, the word, this term is no longer in fashion, but the word Ajax, which was asynchronous JavaScript and XML cause I'm telling you XML, but see the word XML there, to be fair, the way you made HTTP requests from a client to server was this.[00:15:18] Bret: Object called XML HTTP request because Microsoft and making Outlook web access back in the day made this and it turns out to have nothing to do with XML. It's just a way of making HTTP requests because XML was like the fashionable thing. It was like that was the way you, you know, you did it. But the JSON came out of that, you know, and then a lot of the best practices around building JavaScript applications is pre React.[00:15:44] Bret: I think React was probably the big conceptual step forward that we needed. Even my first social network after Google, we used a lot of like HTML injection and. Making real time updates was still very hand coded and it's really neat when you [00:16:00] see conceptual breakthroughs like react because it's, I just love those things where it's like obvious once you see it, but it's so not obvious until you do.[00:16:07] Bret: And actually, well, I'm sure we'll get into AI, but I, I sort of feel like we'll go through that evolution with AI agents as well that I feel like we're missing a lot of the core abstractions that I think in 10 years we'll be like, gosh, how'd you make agents? Before that, you know, but it was kind of that early days of web applications.[00:16:22] swyx: There's a lot of contenders for the reactive jobs of of AI, but no clear winner yet. I would say one thing I was there for, I mean, there's so much we can go into there. You just covered so much.[00:16:32] Product Management and Engineering Synergy[00:16:32] swyx: One thing I just, I just observe is that I think the early Google days had this interesting mix of PM and engineer, which I think you are, you didn't, you didn't wait for PM to tell you these are my, this is my PRD.[00:16:42] swyx: This is my requirements.[00:16:44] mix: Oh,[00:16:44] Bret: okay.[00:16:45] swyx: I wasn't technically a software engineer. I mean,[00:16:48] Bret: by title, obviously. Right, right, right.[00:16:51] swyx: It's like a blend. And I feel like these days, product is its own discipline and its own lore and own industry and engineering is its own thing. And there's this process [00:17:00] that happens and they're kind of separated, but you don't produce as good of a product as if they were the same person.[00:17:06] swyx: And I'm curious, you know, if, if that, if that sort of resonates in, in, in terms of like comparing early Google versus modern startups that you see out there,[00:17:16] Bret: I certainly like wear a lot of hats. So, you know, sort of biased in this, but I really agree that there's a lot of power and combining product design engineering into as few people as possible because, you know few great things have been created by committee, you know, and so.[00:17:33] Bret: If engineering is an order taking organization for product you can sometimes make meaningful things, but rarely will you create extremely well crafted breakthrough products. Those tend to be small teams who deeply understand the customer need that they're solving, who have a. Maniacal focus on outcomes.[00:17:53] Bret: And I think the reason why it's, I think for some areas, if you look at like software as a service five years ago, maybe you can have a [00:18:00] separation of product and engineering because most software as a service created five years ago. I wouldn't say there's like a lot of like. Technological breakthroughs required for most, you know, business applications.[00:18:11] Bret: And if you're making expense reporting software or whatever, it's useful. I don't mean to be dismissive of expense reporting software, but you probably just want to understand like, what are the requirements of the finance department? What are the requirements of an individual file expense report? Okay.[00:18:25] Bret: Go implement that. And you kind of know how web applications are implemented. You kind of know how to. How databases work, how to build auto scaling with your AWS cluster, whatever, you know, it's just, you're just applying best practices to yet another problem when you have areas like the early days of mobile development or the early days of interactive web applications, which I think Google Maps and Gmail represent, or now AI agents, you're in this constant conversation with what the requirements of your customers and stakeholders are and all the different people interacting with it.[00:18:58] Bret: And the capabilities of the [00:19:00] technology. And it's almost impossible to specify the requirements of a product when you're not sure of the limitations of the technology itself. And that's why I use the word conversation. It's not literal. That's sort of funny to use that word in the age of conversational AI.[00:19:15] Bret: You're constantly sort of saying, like, ideally, you could sprinkle some magic AI pixie dust and solve all the world's problems, but it's not the way it works. And it turns out that actually, I'll just give an interesting example.[00:19:26] AI Agents and Modern Tooling[00:19:26] Bret: I think most people listening probably use co pilots to code like Cursor or Devon or Microsoft Copilot or whatever.[00:19:34] Bret: Most of those tools are, they're remarkable. I'm, I couldn't, you know, imagine development without them now, but they're not autonomous yet. Like I wouldn't let it just write most code without my interactively inspecting it. We just are somewhere between it's an amazing co pilot and it's an autonomous software engineer.[00:19:53] Bret: As a product manager, like your aspirations for what the product is are like kind of meaningful. But [00:20:00] if you're a product person, yeah, of course you'd say it should be autonomous. You should click a button and program should come out the other side. The requirements meaningless. Like what matters is like, what is based on the like very nuanced limitations of the technology.[00:20:14] Bret: What is it capable of? And then how do you maximize the leverage? It gives a software engineering team, given those very nuanced trade offs. Coupled with the fact that those nuanced trade offs are changing more rapidly than any technology in my memory, meaning every few months you'll have new models with new capabilities.[00:20:34] Bret: So how do you construct a product that can absorb those new capabilities as rapidly as possible as well? That requires such a combination of technical depth and understanding the customer that you really need more integration. Of product design and engineering. And so I think it's why with these big technology waves, I think startups have a bit of a leg up relative to incumbents because they [00:21:00] tend to be sort of more self actualized in terms of just like bringing those disciplines closer together.[00:21:06] Bret: And in particular, I think entrepreneurs, the proverbial full stack engineers, you know, have a leg up as well because. I think most breakthroughs happen when you have someone who can understand those extremely nuanced technical trade offs, have a vision for a product. And then in the process of building it, have that, as I said, like metaphorical conversation with the technology, right?[00:21:30] Bret: Gosh, I ran into a technical limit that I didn't expect. It's not just like changing that feature. You might need to refactor the whole product based on that. And I think that's, that it's particularly important right now. So I don't, you know, if you, if you're building a big ERP system, probably there's a great reason to have product and engineering.[00:21:51] Bret: I think in general, the disciplines are there for a reason. I think when you're dealing with something as nuanced as the like technologies, like large language models today, there's a ton of [00:22:00] advantage of having. Individuals or organizations that integrate the disciplines more formally.[00:22:05] Alessio: That makes a lot of sense.[00:22:06] Alessio: I've run a lot of engineering teams in the past, and I think the product versus engineering tension has always been more about effort than like whether or not the feature is buildable. But I think, yeah, today you see a lot more of like. Models actually cannot do that. And I think the most interesting thing is on the startup side, people don't yet know where a lot of the AI value is going to accrue.[00:22:26] Alessio: So you have this rush of people building frameworks, building infrastructure, layered things, but we don't really know the shape of the compute. I'm curious that Sierra, like how you thought about building an house, a lot of the tooling for evals or like just, you know, building the agents and all of that.[00:22:41] Alessio: Versus how you see some of the startup opportunities that is maybe still out there.[00:22:46] Bret: We build most of our tooling in house at Sierra, not all. It's, we don't, it's not like not invented here syndrome necessarily, though, maybe slightly guilty of that in some ways, but because we're trying to build a platform [00:23:00] that's in Dorian, you know, we really want to have control over our own destiny.[00:23:03] Bret: And you had made a comment earlier that like. We're still trying to figure out who like the reactive agents are and the jury is still out. I would argue it hasn't been created yet. I don't think the jury is still out to go use that metaphor. We're sort of in the jQuery era of agents, not the react era.[00:23:19] Bret: And, and that's like a throwback for people listening,[00:23:22] swyx: we shouldn't rush it. You know?[00:23:23] Bret: No, yeah, that's my point is. And so. Because we're trying to create an enduring company at Sierra that outlives us, you know, I'm not sure we want to like attach our cart to some like to a horse where it's not clear that like we've figured out and I actually want as a company, we're trying to enable just at a high level and I'll, I'll quickly go back to tech at Sierra, we help consumer brands build customer facing AI agents.[00:23:48] Bret: So. Everyone from Sonos to ADT home security to Sirius XM, you know, if you call them on the phone and AI will pick up with you, you know, chat with them on the Sirius XM homepage. It's an AI agent called Harmony [00:24:00] that they've built on our platform. We're what are the contours of what it means for someone to build an end to end complete customer experience with AI with conversational AI.[00:24:09] Bret: You know, we really want to dive into the deep end of, of all the trade offs to do it. You know, where do you use fine tuning? Where do you string models together? You know, where do you use reasoning? Where do you use generation? How do you use reasoning? How do you express the guardrails of an agentic process?[00:24:25] Bret: How do you impose determinism on a fundamentally non deterministic technology? There's just a lot of really like as an important design space. And I could sit here and tell you, we have the best approach. Every entrepreneur will, you know. But I hope that in two years, we look back at our platform and laugh at how naive we were, because that's the pace of change broadly.[00:24:45] Bret: If you talk about like the startup opportunities, I'm not wholly skeptical of tools companies, but I'm fairly skeptical. There's always an exception for every role, but I believe that certainly there's a big market for [00:25:00] frontier models, but largely for companies with huge CapEx budgets. So. Open AI and Microsoft's Anthropic and Amazon Web Services, Google Cloud XAI, which is very well capitalized now, but I think the, the idea that a company can make money sort of pre training a foundation model is probably not true.[00:25:20] Bret: It's hard to, you're competing with just, you know, unreasonably large CapEx budgets. And I just like the cloud infrastructure market, I think will be largely there. I also really believe in the applications of AI. And I define that not as like building agents or things like that. I define it much more as like, you're actually solving a problem for a business.[00:25:40] Bret: So it's what Harvey is doing in legal profession or what cursor is doing for software engineering or what we're doing for customer experience and customer service. The reason I believe in that is I do think that in the age of AI, what's really interesting about software is it can actually complete a task.[00:25:56] Bret: It can actually do a job, which is very different than the value proposition of [00:26:00] software was to ancient history two years ago. And as a consequence, I think the way you build a solution and For a domain is very different than you would have before, which means that it's not obvious, like the incumbent incumbents have like a leg up, you know, necessarily, they certainly have some advantages, but there's just such a different form factor, you know, for providing a solution and it's just really valuable.[00:26:23] Bret: You know, it's. Like just think of how much money cursor is saving software engineering teams or the alternative, how much revenue it can produce tool making is really challenging. If you look at the cloud market, just as a analog, there are a lot of like interesting tools, companies, you know, Confluent, Monetized Kafka, Snowflake, Hortonworks, you know, there's a, there's a bunch of them.[00:26:48] Bret: A lot of them, you know, have that mix of sort of like like confluence or have the open source or open core or whatever you call it. I, I, I'm not an expert in this area. You know, I do think [00:27:00] that developers are fickle. I think that in the tool space, I probably like. Default towards open source being like the area that will win.[00:27:09] Bret: It's hard to build a company around this and then you end up with companies sort of built around open source to that can work. Don't get me wrong, but I just think that it's nowadays the tools are changing so rapidly that I'm like, not totally skeptical of tool makers, but I just think that open source will broadly win, but I think that the CapEx required for building frontier models is such that it will go to a handful of big companies.[00:27:33] Bret: And then I really believe in agents for specific domains which I think will, it's sort of the analog to software as a service in this new era. You know, it's like, if you just think of the cloud. You can lease a server. It's just a low level primitive, or you can buy an app like you know, Shopify or whatever.[00:27:51] Bret: And most people building a storefront would prefer Shopify over hand rolling their e commerce storefront. I think the same thing will be true of AI. So [00:28:00] I've. I tend to like, if I have a, like an entrepreneur asked me for advice, I'm like, you know, move up the stack as far as you can towards a customer need.[00:28:09] Bret: Broadly, but I, but it doesn't reduce my excitement about what is the reactive building agents kind of thing, just because it is, it is the right question to ask, but I think we'll probably play out probably an open source space more than anything else.[00:28:21] swyx: Yeah, and it's not a priority for you. There's a lot in there.[00:28:24] swyx: I'm kind of curious about your idea maze towards, there are many customer needs. You happen to identify customer experience as yours, but it could equally have been coding assistance or whatever. I think for some, I'm just kind of curious at the top down, how do you look at the world in terms of the potential problem space?[00:28:44] swyx: Because there are many people out there who are very smart and pick the wrong problem.[00:28:47] Bret: Yeah, that's a great question.[00:28:48] Future of Software Development[00:28:48] Bret: By the way, I would love to talk about the future of software, too, because despite the fact it didn't pick coding, I have a lot of that, but I can talk to I can answer your question, though, you know I think when a technology is as [00:29:00] cool as large language models.[00:29:02] Bret: You just see a lot of people starting from the technology and searching for a problem to solve. And I think it's why you see a lot of tools companies, because as a software engineer, you start building an app or a demo and you, you encounter some pain points. You're like,[00:29:17] swyx: a lot of[00:29:17] Bret: people are experiencing the same pain point.[00:29:19] Bret: What if I make it? That it's just very incremental. And you know, I always like to use the metaphor, like you can sell coffee beans, roasted coffee beans. You can add some value. You took coffee beans and you roasted them and roasted coffee beans largely, you know, are priced relative to the cost of the beans.[00:29:39] Bret: Or you can sell a latte and a latte. Is rarely priced directly like as a percentage of coffee bean prices. In fact, if you buy a latte at the airport, it's a captive audience. So it's a really expensive latte. And there's just a lot that goes into like. How much does a latte cost? And I bring it up because there's a supply chain from growing [00:30:00] coffee beans to roasting coffee beans to like, you know, you could make one at home or you could be in the airport and buy one and the margins of the company selling lattes in the airport is a lot higher than the, you know, people roasting the coffee beans and it's because you've actually solved a much more acute human problem in the airport.[00:30:19] Bret: And, and it's just worth a lot more to that person in that moment. It's kind of the way I think about technology too. It sounds funny to liken it to coffee beans, but you're selling tools on top of a large language model yet in some ways your market is big, but you're probably going to like be price compressed just because you're sort of a piece of infrastructure and then you have open source and all these other things competing with you naturally.[00:30:43] Bret: If you go and solve a really big business problem for somebody, that's actually like a meaningful business problem that AI facilitates, they will value it according to the value of that business problem. And so I actually feel like people should just stop. You're like, no, that's, that's [00:31:00] unfair. If you're searching for an idea of people, I, I love people trying things, even if, I mean, most of the, a lot of the greatest ideas have been things no one believed in.[00:31:07] Bret: So I like, if you're passionate about something, go do it. Like who am I to say, yeah, a hundred percent. Or Gmail, like Paul as far, I mean I, some of it's Laura at this point, but like Gmail is Paul's own email for a long time. , and then I amusingly and Paul can't correct me, I'm pretty sure he sent her in a link and like the first comment was like, this is really neat.[00:31:26] Bret: It would be great. It was not your email, but my own . I don't know if it's a true story. I'm pretty sure it's, yeah, I've read that before. So scratch your own niche. Fine. Like it depends on what your goal is. If you wanna do like a venture backed company, if its a. Passion project, f*****g passion, do it like don't listen to anybody.[00:31:41] Bret: In fact, but if you're trying to start, you know an enduring company, solve an important business problem. And I, and I do think that in the world of agents, the software industries has shifted where you're not just helping people more. People be more productive, but you're actually accomplishing tasks autonomously.[00:31:58] Bret: And as a consequence, I think the [00:32:00] addressable market has just greatly expanded just because software can actually do things now and actually accomplish tasks and how much is coding autocomplete worth. A fair amount. How much is the eventual, I'm certain we'll have it, the software agent that actually writes the code and delivers it to you, that's worth a lot.[00:32:20] Bret: And so, you know, I would just maybe look up from the large language models and start thinking about the economy and, you know, think from first principles. I don't wanna get too far afield, but just think about which parts of the economy. We'll benefit most from this intelligence and which parts can absorb it most easily.[00:32:38] Bret: And what would an agent in this space look like? Who's the customer of it is the technology feasible. And I would just start with these business problems more. And I think, you know, the best companies tend to have great engineers who happen to have great insight into a market. And it's that last part that I think some people.[00:32:56] Bret: Whether or not they have, it's like people start so much in the technology, they [00:33:00] lose the forest for the trees a little bit.[00:33:02] Alessio: How do you think about the model of still selling some sort of software versus selling more package labor? I feel like when people are selling the package labor, it's almost more stateless, you know, like it's easier to swap out if you're just putting an input and getting an output.[00:33:16] Alessio: If you think about coding, if there's no ID, you're just putting a prompt and getting back an app. It doesn't really matter. Who generates the app, you know, you have less of a buy in versus the platform you're building, I'm sure on the backend customers have to like put on their documentation and they have, you know, different workflows that they can tie in what's kind of like the line to draw there versus like going full where you're managed customer support team as a service outsource versus.[00:33:40] Alessio: This is the Sierra platform that you can build on. What was that decision? I'll sort of[00:33:44] Bret: like decouple the question in some ways, which is when you have something that's an agent, who is the person using it and what do they want to do with it? So let's just take your coding agent for a second. I will talk about Sierra as well.[00:33:59] Bret: Who's the [00:34:00] customer of a, an agent that actually produces software? Is it a software engineering manager? Is it a software engineer? And it's there, you know, intern so to speak. I don't know. I mean, we'll figure this out over the next few years. Like what is that? And is it generating code that you then review?[00:34:16] Bret: Is it generating code with a set of unit tests that pass, what is the actual. For lack of a better word contract, like, how do you know that it did what you wanted it to do? And then I would say like the product and the pricing, the packaging model sort of emerged from that. And I don't think the world's figured out.[00:34:33] Bret: I think it'll be different for every agent. You know, in our customer base, we do what's called outcome based pricing. So essentially every time the AI agent. Solves the problem or saves a customer or whatever it might be. There's a pre negotiated rate for that. We do that. Cause it's, we think that that's sort of the correct way agents, you know, should be packaged.[00:34:53] Bret: I look back at the history of like cloud software and notably the introduction of the browser, which led to [00:35:00] software being delivered in a browser, like Salesforce to. Famously invented sort of software as a service, which is both a technical delivery model through the browser, but also a business model, which is you subscribe to it rather than pay for a perpetual license.[00:35:13] Bret: Those two things are somewhat orthogonal, but not really. If you think about the idea of software running in a browser, that's hosted. Data center that you don't own, you sort of needed to change the business model because you don't, you can't really buy a perpetual license or something otherwise like, how do you afford making changes to it?[00:35:31] Bret: So it only worked when you were buying like a new version every year or whatever. So to some degree, but then the business model shift actually changed business as we know it, because now like. Things like Adobe Photoshop. Now you subscribe to rather than purchase. So it ended up where you had a technical shift and a business model shift that were very logically intertwined that actually the business model shift was turned out to be as significant as the technical as the shift.[00:35:59] Bret: And I think with [00:36:00] agents, because they actually accomplish a job, I do think that it doesn't make sense to me that you'd pay for the privilege of like. Using the software like that coding agent, like if it writes really bad code, like fire it, you know, I don't know what the right metaphor is like you should pay for a job.[00:36:17] Bret: Well done in my opinion. I mean, that's how you pay your software engineers, right? And[00:36:20] swyx: and well, not really. We paid to put them on salary and give them options and they vest over time. That's fair.[00:36:26] Bret: But my point is that you don't pay them for how many characters they write, which is sort of the token based, you know, whatever, like, There's a, that famous Apple story where we're like asking for a report of how many lines of code you wrote.[00:36:40] Bret: And one of the engineers showed up with like a negative number cause he had just like done a big refactoring. There was like a big F you to management who didn't understand how software is written. You know, my sense is like the traditional usage based or seat based thing. It's just going to look really antiquated.[00:36:55] Bret: Cause it's like asking your software engineer, how many lines of code did you write today? Like who cares? Like, cause [00:37:00] absolutely no correlation. So my old view is I don't think it's be different in every category, but I do think that that is the, if an agent is doing a job, you should, I think it properly incentivizes the maker of that agent and the customer of, of your pain for the job well done.[00:37:16] Bret: It's not always perfect to measure. It's hard to measure engineering productivity, but you can, you should do something other than how many keys you typed, you know Talk about perverse incentives for AI, right? Like I can write really long functions to do the same thing, right? So broadly speaking, you know, I do think that we're going to see a change in business models of software towards outcomes.[00:37:36] Bret: And I think you'll see a change in delivery models too. And, and, you know, in our customer base you know, we empower our customers to really have their hands on the steering wheel of what the agent does they, they want and need that. But the role is different. You know, at a lot of our customers, the customer experience operations folks have renamed themselves the AI architects, which I think is really cool.[00:37:55] Bret: And, you know, it's like in the early days of the Internet, there's the role of the webmaster. [00:38:00] And I don't know whether your webmaster is not a fashionable, you know, Term, nor is it a job anymore? I just, I don't know. Will they, our tech stand the test of time? Maybe, maybe not. But I do think that again, I like, you know, because everyone listening right now is a software engineer.[00:38:14] Bret: Like what is the form factor of a coding agent? And actually I'll, I'll take a breath. Cause actually I have a bunch of pins on them. Like I wrote a blog post right before Christmas, just on the future of software development. And one of the things that's interesting is like, if you look at the way I use cursor today, as an example, it's inside of.[00:38:31] Bret: A repackaged visual studio code environment. I sometimes use the sort of agentic parts of it, but it's largely, you know, I've sort of gotten a good routine of making it auto complete code in the way I want through tuning it properly when it actually can write. I do wonder what like the future of development environments will look like.[00:38:55] Bret: And to your point on what is a software product, I think it's going to change a lot in [00:39:00] ways that will surprise us. But I always use, I use the metaphor in my blog post of, have you all driven around in a way, Mo around here? Yeah, everyone has. And there are these Jaguars, the really nice cars, but it's funny because it still has a steering wheel, even though there's no one sitting there and the steering wheels like turning and stuff clearly in the future.[00:39:16] Bret: If once we get to that, be more ubiquitous, like why have the steering wheel and also why have all the seats facing forward? Maybe just for car sickness. I don't know, but you could totally rearrange the car. I mean, so much of the car is oriented around the driver, so. It stands to reason to me that like, well, autonomous agents for software engineering run through visual studio code.[00:39:37] Bret: That seems a little bit silly because having a single source code file open one at a time is kind of a goofy form factor for when like the code isn't being written primarily by you, but it begs the question of what's your relationship with that agent. And I think the same is true in our industry of customer experience, which is like.[00:39:55] Bret: Who are the people managing this agent? What are the tools do they need? And they definitely need [00:40:00] tools, but it's probably pretty different than the tools we had before. It's certainly different than training a contact center team. And as software engineers, I think that I would like to see particularly like on the passion project side or research side.[00:40:14] Bret: More innovation in programming languages. I think that we're bringing the cost of writing code down to zero. So the fact that we're still writing Python with AI cracks me up just cause it's like literally was designed to be ergonomic to write, not safe to run or fast to run. I would love to see more innovation and how we verify program correctness.[00:40:37] Bret: I studied for formal verification in college a little bit and. It's not very fashionable because it's really like tedious and slow and doesn't work very well. If a lot of code is being written by a machine, you know, one of the primary values we can provide is verifying that it actually does what we intend that it does.[00:40:56] Bret: I think there should be lots of interesting things in the software development life cycle, like how [00:41:00] we think of testing and everything else, because. If you think about if we have to manually read every line of code that's coming out as machines, it will just rate limit how much the machines can do. The alternative is totally unsafe.[00:41:13] Bret: So I wouldn't want to put code in production that didn't go through proper code review and inspection. So my whole view is like, I actually think there's like an AI native I don't think the coding agents don't work well enough to do this yet, but once they do, what is sort of an AI native software development life cycle and how do you actually.[00:41:31] Bret: Enable the creators of software to produce the highest quality, most robust, fastest software and know that it's correct. And I think that's an incredible opportunity. I mean, how much C code can we rewrite and rust and make it safe so that there's fewer security vulnerabilities. Can we like have more efficient, safer code than ever before?[00:41:53] Bret: And can you have someone who's like that guy in the matrix, you know, like staring at the little green things, like where could you have an operator [00:42:00] of a code generating machine be like superhuman? I think that's a cool vision. And I think too many people are focused on like. Autocomplete, you know, right now, I'm not, I'm not even, I'm guilty as charged.[00:42:10] Bret: I guess in some ways, but I just like, I'd like to see some bolder ideas. And that's why when you were joking, you know, talking about what's the react of whatever, I think we're clearly in a local maximum, you know, metaphor, like sort of conceptual local maximum, obviously it's moving really fast. I think we're moving out of it.[00:42:26] Alessio: Yeah. At the end of 23, I've read this blog post from syntax to semantics. Like if you think about Python. It's taking C and making it more semantic and LLMs are like the ultimate semantic program, right? You can just talk to them and they can generate any type of syntax from your language. But again, the languages that they have to use were made for us, not for them.[00:42:46] Alessio: But the problem is like, as long as you will ever need a human to intervene, you cannot change the language under it. You know what I mean? So I'm curious at what point of automation we'll need to get, we're going to be okay making changes. To the underlying languages, [00:43:00] like the programming languages versus just saying, Hey, you just got to write Python because I understand Python and I'm more important at the end of the day than the model.[00:43:08] Alessio: But I think that will change, but I don't know if it's like two years or five years. I think it's more nuanced actually.[00:43:13] Bret: So I think there's a, some of the more interesting programming languages bring semantics into syntax. So let me, that's a little reductive, but like Rust as an example, Rust is memory safe.[00:43:25] Bret: Statically, and that was a really interesting conceptual, but it's why it's hard to write rust. It's why most people write python instead of rust. I think rust programs are safer and faster than python, probably slower to compile. But like broadly speaking, like given the option, if you didn't have to care about the labor that went into it.[00:43:45] Bret: You should prefer a program written in Rust over a program written in Python, just because it will run more efficiently. It's almost certainly safer, et cetera, et cetera, depending on how you define safe, but most people don't write Rust because it's kind of a pain in the ass. And [00:44:00] the audience of people who can is smaller, but it's sort of better in most, most ways.[00:44:05] Bret: And again, let's say you're making a web service and you didn't have to care about how hard it was to write. If you just got the output of the web service, the rest one would be cheaper to operate. It's certainly cheaper and probably more correct just because there's so much in the static analysis implied by the rest programming language that it probably will have fewer runtime errors and things like that as well.[00:44:25] Bret: So I just give that as an example, because so rust, at least my understanding that came out of the Mozilla team, because. There's lots of security vulnerabilities in the browser and it needs to be really fast. They said, okay, we want to put more of a burden at the authorship time to have fewer issues at runtime.[00:44:43] Bret: And we need the constraint that it has to be done statically because browsers need to be really fast. My sense is if you just think about like the, the needs of a programming language today, where the role of a software engineer is [00:45:00] to use an AI to generate functionality and audit that it does in fact work as intended, maybe functionally, maybe from like a correctness standpoint, some combination thereof, how would you create a programming system that facilitated that?[00:45:15] Bret: And, you know, I bring up Rust is because I think it's a good example of like, I think given a choice of writing in C or Rust, you should choose Rust today. I think most people would say that, even C aficionados, just because. C is largely less safe for very similar, you know, trade offs, you know, for the, the system and now with AI, it's like, okay, well, that just changes the game on writing these things.[00:45:36] Bret: And so like, I just wonder if a combination of programming languages that are more structurally oriented towards the values that we need from an AI generated program, verifiable correctness and all of that. If it's tedious to produce for a person, that maybe doesn't matter. But one thing, like if I asked you, is this rest program memory safe?[00:45:58] Bret: You wouldn't have to read it, you just have [00:46:00] to compile it. So that's interesting. I mean, that's like an, that's one example of a very modest form of formal verification. So I bring that up because I do think you have AI inspect AI, you can have AI reviewed. Do AI code reviews. It would disappoint me if the best we could get was AI reviewing Python and having scaled a few very large.[00:46:21] Bret: Websites that were written on Python. It's just like, you know, expensive and it's like every, trust me, every team who's written a big web service in Python has experimented with like Pi Pi and all these things just to make it slightly more efficient than it naturally is. You don't really have true multi threading anyway.[00:46:36] Bret: It's just like clearly that you do it just because it's convenient to write. And I just feel like we're, I don't want to say it's insane. I just mean. I do think we're at a local maximum. And I would hope that we create a programming system, a combination of programming languages, formal verification, testing, automated code reviews, where you can use AI to generate software in a high scale way and trust it.[00:46:59] Bret: And you're [00:47:00] not limited by your ability to read it necessarily. I don't know exactly what form that would take, but I feel like that would be a pretty cool world to live in.[00:47:08] Alessio: Yeah. We had Chris Lanner on the podcast. He's doing great work with modular. I mean, I love. LVM. Yeah. Basically merging rust in and Python.[00:47:15] Alessio: That's kind of the idea. Should be, but I'm curious is like, for them a big use case was like making it compatible with Python, same APIs so that Python developers could use it. Yeah. And so I, I wonder at what point, well, yeah.[00:47:26] Bret: At least my understanding is they're targeting the data science Yeah. Machine learning crowd, which is all written in Python, so still feels like a local maximum.[00:47:34] Bret: Yeah.[00:47:34] swyx: Yeah, exactly. I'll force you to make a prediction. You know, Python's roughly 30 years old. In 30 years from now, is Rust going to be bigger than Python?[00:47:42] Bret: I don't know this, but just, I don't even know this is a prediction. I just am sort of like saying stuff I hope is true. I would like to see an AI native programming language and programming system, and I use language because I'm not sure language is even the right thing, but I hope in 30 years, there's an AI native way we make [00:48:00] software that is wholly uncorrelated with the current set of programming languages.[00:48:04] Bret: or not uncorrelated, but I think most programming languages today were designed to be efficiently authored by people and some have different trade offs.[00:48:15] Evolution of Programming Languages[00:48:15] Bret: You know, you have Haskell and others that were designed for abstractions for parallelism and things like that. You have programming languages like Python, which are designed to be very easily written, sort of like Perl and Python lineage, which is why data scientists use it.[00:48:31] Bret: It's it can, it has a. Interactive mode, things like that. And I love, I'm a huge Python fan. So despite all my Python trash talk, a huge Python fan wrote at least two of my three companies were exclusively written in Python and then C came out of the birth of Unix and it wasn't the first, but certainly the most prominent first step after assembly language, right?[00:48:54] Bret: Where you had higher level abstractions rather than and going beyond go to, to like abstractions, [00:49:00] like the for loop and the while loop.[00:49:01] The Future of Software Engineering[00:49:01] Bret: So I just think that if the act of writing code is no longer a meaningful human exercise, maybe it will be, I don't know. I'm just saying it sort of feels like maybe it's one of those parts of history that just will sort of like go away, but there's still the role of this offer engineer, like the person actually building the system.[00:49:20] Bret: Right. And. What does a programming system for that form factor look like?[00:49:25] React and Front-End Development[00:49:25] Bret: And I, I just have a, I hope to be just like I mentioned, I remember I was at Facebook in the very early days when, when, what is now react was being created. And I remember when the, it was like released open source I had left by that time and I was just like, this is so f*****g cool.[00:49:42] Bret: Like, you know, to basically model your app independent of the data flowing through it, just made everything easier. And then now. You know, I can create, like there's a lot of the front end software gym play is like a little chaotic for me, to be honest with you. It is like, it's sort of like [00:50:00] abstraction soup right now for me, but like some of those core ideas felt really ergonomic.[00:50:04] Bret: I just wanna, I'm just looking forward to the day when someone comes up with a programming system that feels both really like an aha moment, but completely foreign to me at the same time. Because they created it with sort of like from first principles recognizing that like. Authoring code in an editor is maybe not like the primary like reason why a programming system exists anymore.[00:50:26] Bret: And I think that's like, that would be a very exciting day for me.[00:50:28] The Role of AI in Programming[00:50:28] swyx: Yeah, I would say like the various versions of this discussion have happened at the end of the day, you still need to precisely communicate what you want. As a manager of people, as someone who has done many, many legal contracts, you know how hard that is.[00:50:42] swyx: And then now we have to talk to machines doing that and AIs interpreting what we mean and reading our minds effectively. I don't know how to get across that barrier of translating human intent to instructions. And yes, it can be more declarative, but I don't know if it'll ever Crossover from being [00:51:00] a programming language to something more than that.[00:51:02] Bret: I agree with you. And I actually do think if you look at like a legal contract, you know, the imprecision of the English language, it's like a flaw in the system. How many[00:51:12] swyx: holes there are.[00:51:13] Bret: And I do think that when you're making a mission critical software system, I don't think it should be English language prompts.[00:51:19] Bret: I think that is silly because you want the precision of a a programming language. My point was less about that and more about if the actual act of authoring it, like if you.[00:51:32] Formal Verification in Software[00:51:32] Bret: I'll think of some embedded systems do use formal verification. I know it's very common in like security protocols now so that you can, because the importance of correctness is so great.[00:51:41] Bret: My intellectual exercise is like, why not do that for all software? I mean, probably that's silly just literally to do what we literally do for. These low level security protocols, but the only reason we don't is because it's hard and tedious and hard and tedious are no longer factors. So, like, if I could, I mean, [00:52:00] just think of, like, the silliest app on your phone right now, the idea that that app should be, like, formally verified for its correctness feels laughable right now because, like, God, why would you spend the time on it?[00:52:10] Bret: But if it's zero costs, like, yeah, I guess so. I mean, it never crashed. That's probably good. You know, why not? I just want to, like, set our bars really high. Like. We should make, software has been amazing. Like there's a Mark Andreessen blog post, software is eating the world. And you know, our whole life is, is mediated digitally.[00:52:26] Bret: And that's just increasing with AI. And now we'll have our personal agents talking to the agents on the CRO platform and it's agents all the way down, you know, our core infrastructure is running on these digital systems. We now have like, and we've had a shortage of software developers for my entire life.[00:52:45] Bret: And as a consequence, you know if you look, remember like health care, got healthcare. gov that fiasco security vulnerabilities leading to state actors getting access to critical infrastructure. I'm like. We now have like created this like amazing system that can [00:53:00] like, we can fix this, you know, and I, I just want to, I'm both excited about the productivity gains in the economy, but I just think as software engineers, we should be bolder.[00:53:08] Bret: Like we should have aspirations to fix these systems so that like in general, as you said, as precise as we want to be in the specification of the system. We can make it work correctly now, and I'm being a little bit hand wavy, and I think we need some systems. I think that's where we should set the bar, especially when so much of our life depends on this critical digital infrastructure.[00:53:28] Bret: So I'm I'm just like super optimistic about it. But actually, let's go to w
Join us for an insightful conversation with Dani Grant, co-founder of Jam.dev, as she shares her journey from Cloudflare PM to startup founder. Learn how Jam.dev persevered through eight failed attempts before finding product-market fit and growing to 85,000 users. Dani reveals valuable lessons about product-led growth, building in public, and raising venture capital. From tactical fundraising tips to creative community building strategies like jam.pizza, this episode is packed with practical insights for founders and anyone interested in the startup journey. SponsorConvex is the backend for founders. Convex is the backend application platform for product-obsessed founders. Show Notes0:00 - Intro0:29 - Sponsor: Convex1:08 - Meeting Dani Grant1:41 - Early Career at Cloudflare3:09 - Finding Internships & Career Growth5:25 - Starting Jam.dev11:56 - Product Evolution & User Growth16:57 - Product Features & Implementation21:22 - Monetization Strategy23:37 - Technical Deep Dive: How Jam Works27:49 - Future Plans & Mobile Development29:12 - Fundraising Tips & Strategies34:00 - Supporting Developer Communities36:18 - Picks and Plugs LinksCompanies/Products:Jam.devCloudflareConvex (sponsor)SentryData DogHotjarFullStoryJIRAMetabaseNotionSocial/Personal:Dani Grant's TwitterDani Grant's email (dani@jam.dev)Brad Garropy's Twitter (@bradgarropy)Learn Build Teach DiscordDeals for Devs projectBooks/Media:"Tomorrow and Tomorrow and Tomorrow" (book mentioned by Dani)Matt Wolf's YouTube channel (AI recaps)Career Resources:jam.dev/careers (mentioned they're hiring)jam.pizza (community meetup sponsorship form)Technical Tools Mentioned:ViteRemixES BuildProducts Similar to Jam:FullStoryHotjarSentryDatadogDevelopment Tools:Chrome Extension Store (where Jam is available)Community:LearnBuildTeach.comDeals for Devs
Join us as Tanner Linsley, the creator and founder of TanStack Start talks about its transition from Vinci to a more streamlined architecture built on Nitro. Learn about the framework's innovative approach to server functions, its isomorphic design philosophy, and how it differs from other frameworks like Remix. Tanner also shares insights into TanStack's sustainable open-source business model and his journey to building developer tools that prioritize user experience over rapid growth.Show Notes0:00 - Intro0:38 - Welcome Tanner Linsley3:43 - React Server Components and TanStack Evolution6:04 - TanStack Start Overview and Vinci Transition11:26 - Nitro Integration and Framework Architecture15:19 - Server Functions and Framework Comparisons20:58 - API Design Philosophy24:19 - Testing and Development Process30:58 - Team and Collaboration Discussion33:38 - Open Source Sponsorship Strategy36:32 - Netlify Partnership Announcement38:37 - Open Source Sustainability Discussion41:03 - Picks and Plugs LinksProducts & Tools:TanStackVinxi by Nikhil SarafNitroReact RouterTRPCRemixH3 (web request library)XPro (Tweet Deck)Deck.blue (BlueSky client)MOTU M4 audio interfaceBamboo Lab A1 3D printerLashbrook Designs (Brad's wedding band)Companies & Sponsors:ConvexClerkAG GridSentryNetlifyGames & Entertainment:Blockus (board game)Severance (TV Show on Apple TV+)"First Lie Wins" (book)Personal Projects & Links:buildtwelve.com (Amy's project)Brad on BlueSky (@bradgaropy.com)Nozzle (Tanner's startup)Technical Resources:Babel Dead Code Elimination (by Pedro Katori)GitHub 3D Contribution Graph GeneratorReact Server Components documentationOther Projects Mentioned:Solid StartAstro
This week we talk to Ryan Carniato, the creator of SolidJS. SolidJS is a modern frontend framework that is designed to be simple, fast, and reactive. It work in almost the exact opposite way of React, but with very familiar patterns. Learn how it's been behind the scenes influencing things for years. https://bsky.app/profile/ryansolid.bsky.social https://www.youtube.com/@ryansolid https://markojs.com/ https://dev.to/ryansolid https://www.solidjs.com/ https://github.com/ryansolid Apply to sponsor the podcast: https://devtools.fm/sponsor Become a paid subscriber our patreon, spotify, or apple podcasts for the ad-free episode. https://www.patreon.com/devtoolsfm https://podcasters.spotify.com/pod/show/devtoolsfm/subscribe https://podcasts.apple.com/us/podcast/devtools-fm/id1566647758 https://www.youtube.com/@devtoolsfm/membership
In this episode of the Modern Web Podcast, Rob Ocel, Danny Thompson, Adam Rackis, and Brandon Mathis discuss the role of abstractions in software development. They explore frontend tools like React and SolidJS, backend abstractions like serverless platforms, and the importance of understanding patterns and learning through mistakes. The group also highlights emerging trends for 2025, including opportunities in platform plugins and developer marketplaces. Key Points for the Episode: The Role of Abstractions in Development: The panel discusses the benefits and challenges of abstractions in software development, emphasizing the importance of understanding underlying systems to avoid over-reliance on tools like React hooks and serverless platforms. Learning Through Experimentation: Personal experiences with tools like Advent of Code, exploring new languages like Swift and Rust, and experimenting with new frameworks like SolidJS highlight the importance of hands-on learning and stepping outside comfort zones. Platform Opportunities: A growing interest in building apps and plugins on established platforms like Stripe, Zoom, and Chrome Extensions showcases untapped opportunities for developers to create impactful solutions and monetize their skills. Chapters 0:00 - The Potential of Plugins and Platforms 0:42 - Welcome to the Modern Web Podcast 0:47 - Introducing the Hosts and Guests 1:19 - Holiday Projects and Side Gigs 1:31 - Danny's Speedrun of a New Platform 2:07 - Adam's Holiday Reading List 3:38 - Brandon's Advent of Code Challenge in Swift and Rust 5:01 - Learning New Programming Languages Through Challenges 6:52 - Discussion on Abstractions in Software Development 7:10 - The Balance Between Abstractions and Understanding the Basics 8:56 - Learning Through Experience: The Importance of Stepping on Rakes 9:46 - React's Role in Frontend Development and Its Critics 10:39 - The Evolution of Frontend and Backend Abstractions 12:09 - The Impact of Serverless and Cloud Platforms 13:31 - Misuse of Abstractions and Overcomplicated Code 14:27 - The Common Pitfalls of React Hooks Misuse 15:29 - Overuse of `useEffect` and Its Performance Implications 16:41 - Learning from Industry Experts: Insights from Ben Lesh 17:53 - The Evolution of the Web from Static Documents to Interactive Applications 19:04 - The Role of Abstractions in Backend Development and Serverless Adoption 21:06 - Advice for Developers on Understanding Patterns and Abstractions 22:21 - Sponsor Message: This Dot Labs 22:27 - Looking Ahead to 2025: Technologies and Trends 22:43 - Excitement Around SolidJS and Signals-Based Frameworks 23:29 - The Growing Ecosystem Around SolidJS and TanStack Router 24:48 - Insights from a Conversation with Ryan Carniato 25:19 - Interest in TanStack Start and React 19 Features 26:09 - Danny Learning Spanish and Coding Challenges 27:16 - Exploring New Platforms for Side Projects and Monetization 27:55 - The Untapped Potential in Plugin and App Store Ecosystems 29:01 - Case Study: Monetization through Small Chrome and Office Extensions 30:09 - Growth of Developer Marketplaces (Stripe, Slack, Shopify, Zoom) 31:06 - The Challenge of Getting Projects in Front of Users 32:03 - Opportunities in Game Modding and Twitch Extensions 32:32 - Closing Thoughts and Future Podcast Episodes 32:45 - Sponsor Message and Where to Find the Podcast Online Follow the crew on Twitter and Linkedin: Rob Twitter: https://x.com/robocell Rob Linkedin: / robocel Danny Twitter: https://x.com/DThompsonDev Danny Linkedin: / dthompsondev Adam Twitter: https://x.com/AdamRackis Adam Linkedin: / adam-rackis-5b655a8 Brandon Twitter: https://x.com/BrandonMathis Brandon Linkedin: / mathisbrandon Sponsored by This Dot: thisdot.co
Brooks Lybrand discusses the transformation of React Router from a simple routing library to a powerful framework option for React applications. Learn about React Router 7's new framework mode, upcoming middleware support, and the team's innovative approach to React Server Components. Brooks explains how the Remix team is working to bring proven patterns and web standards to the broader React community while building a foundation for future web development that leverages native web APIs.Chapter Marks0:00 - Intro0:37 - Guest Introduction & SNL Jacket Discussion1:12 - The Remix "Nap" Announcement3:25 - Understanding React Router's Evolution7:51 - React Router Framework Mode10:21 - Middleware Support Plans15:42 - React Server Components Integration19:14 - Server-Side Capabilities & RSC Benefits24:17 - Team Size and Structure25:13 - Remix Brand & Future Direction30:19 - Future of Web APIs32:03 - Austin Remix Meetup Discussion34:54 - Community Engagement and Open Source36:19 - Picks and Plugs LinksPeople & Profiles:Brooks Lybrand's social profilesTwitterBlueSkyMichael ChanJames PerkinsRyan FlorenceEvan Bacon (mentioned for RSC mobile demo)Tools & Projects:React Router 7Remix RunRemix DiscordVite 6Cursor AI (mentioned in Amy's pick)The dev.to article about Cursor settings that Amy referencedElgato XLR Deck (Brad's pick)OXO Silicon Measuring Cup (Amy's pick)Events & Communities:Epic Web Conf (March 2024, where Brooks will be speaking)React Miami (April 2024, where Brooks will be speaking)Remix Austin MeetupTechnical Resources:React Server Components documentationRemix Project RoadmapVite's Environment API documentationBooks:The Three-Body Problem book series (Brooks' pick)Additional Resources:Netflix's Three-Body Problem show (mentioned in relation to Brooks' pick)
It's time to reflect and plan ahead! James and Josh look back at a tumultuous 2024 in tech and ask the big questions about where things are heading. What were the highlights? What lessons can we learn? How do we prepare for 2025? Listen now as we kick-off the year with a brand new instalment of Off Script! In praise of indie conferences The struggles of smaller events AWS re:Invent conference Multi Cloud Distributed SQL - DSQL Tough time for tech in 2024 All Day Hey! Publishing platforms Tech Influencers Complete CSS - Any Bell Learn with Jason The state of the tech economy Whisper Flow CrowdStrike outage AI, Automation, valid JSON, OLLAMA , Constrained Sampling AI Agents, Cursor IDE SASS is in danger? Adobe Podcast New Ruby on Rails Laravel 11 Deno BlueSky References * https://piccalil.li/complete-css (https://piccalil.li/complete-css) * https://www.youtube.com/@learnwithjason (https://www.youtube.com/@learnwithjason) Find out more about Stac and Parallax: * https://stac.works (https://stac.works) * https://parall.ax (https://parall.ax)
In this episode of Compressed FM, Dustin Goodman shares insights from his journey from IC to engineering manager at companies like ClickUp and This Dot. The conversation explores the nuances of technical leadership, team dynamics, and the importance of understanding personal values in management. The discussion then shifts to a deep dive into React Server Components, examining their implementation challenges and potential impact on the framework ecosystem. SponsorsWix Studio combines the best of both worlds—intuitive design tools for clients and full-stack flexibility for developers. Customize every detail with your own code and take control of your projects.Chapter Marks00:00:00 - Intro00:00:42 - Sponsor: Wix Studio00:01:33 - Engineering Management Journey00:05:11 - Managing Different Experience Levels00:07:14 - Technical Skills in Management00:09:27 - Should Managers Code?00:12:19 - Managing Up vs Managing Down00:17:27 - Team Values Discussion00:20:11 - Strengths and Management Styles00:26:07 - React Server Components Introduction00:29:27 - RSC Implementation Challenges00:34:34 - GraphQL and Server Components00:39:13 - Future of React Frameworks00:43:10 - Vite 6 Discussion00:47:52 - React Community Evolution00:51:21 - Picks and PlugsAmy Dutton:Pick: Browse AI (web scraping tool with AI capabilities)Plug: Advent of CSS and Advent of JavaScript (24 coding challenges in December)Dustin Goodman:Pick: Cursor (AI-powered code editor)Plug: "Engineering Management for the Rest of Us" by Sarah DrasnerBrad Garropy:Pick: Helldivers 2 (video game)Plug: Raycast extension for Stripe (automatically fills checkouts with test cards)01:00:14 - Show Wrap-upLinksBooks Mentioned:"The Manager's Path" by Camille Fournier"Engineering Management for the Rest of Us" by Sarah DrasnerTools & Software:Wix StudioBrowse AICursor (code editor)RaycastRaycast Stripe extensionVite 6Next.jsSocial/Community:BlueSky (Brad and Amy)Bytes NewsletterConnectTech conferencePeople Referenced:Ryan BurgessGergely OroszTracy LeeDan AbramovTanner LindsleyJohn LindquistDavid KhourshidAssessment Tools:Clifton StrengthsFinderAPIs/Documentation:Stripe test cards documentationReact Server Components documentationVite documentationProjects:Advent of CSS (adventofcss.com)Advent of JavaScript (adventofjs.com)
Part 2 has landed! For this outing of Off Script, Josh and James explore the ‘Future of engineering leadership'. This is an episode born from Q&A discussions and ideas at the recent Off Script Live event in Leeds. Dive into the modern challenges and the future direction of leadership in software engineering. AI Sustainability Company energy offset Energy demands of AI vs speed of innovation AI on device Apple Siri LLM on device? Loneliness in leadership positions Talk with peers in other companies Lattice HR for feedback Finding your role Event culture Consistency creates community Organiser sets the tone Challenges for future leaders Addressing the gap between vocal and and non vocal team members Communication types Generating positive feedback culture Find out more about Stac and Parallax: * https://stac.works (https://stac.works) * https://parall.ax (https://parall.ax)
In this episode, Bill Kennedy interviews Tanmai Gopal, co-founder and CEO of Hasura, discussing the evolution of San Francisco post-pandemic, the innovative approach of Hasura, and the importance of data security and access. Tanmai shares insights from his academic journey, including his experiences with internships and his master's degree in computer vision, culminating in a fascinating project involving drones. In this conversation, Tanmai Gopal discusses his journey from academia to entrepreneurship, focusing on his experiences in building a consulting business and transitioning to product development. He shares insights on the evolution of GraphQL, the challenges of navigating business decisions, and the future of data access in the context of AI and emerging technologies. The discussion highlights the importance of understanding data modeling and the need for innovative solutions in the software industry.00:00 Introduction03:15 What is Tanmai Doing Today05:45 Understanding Hasura's Approach to APIs14:40 Pre-Hosted Solutions in Hasura22:26 First Memories of a Computer35:40 Favorite Classes During University49:25 From Consulting to Product1:01:35 Extending GraphQL 1:10:30 Competitors of Hasura1:18:40 Data Privacy1:22:10 Contact InfoConnect with Tanmai: Linkedin: https://www.linkedin.com/in/tanmaig/X: https://x.com/tanmaigo?lang=enMentioned in today's episode:Hasura: https://hasura.io/GraphQL: https://graphql.org/Want more from Ardan Labs? You can learn Go, Kubernetes, Docker & more through our video training, live events, or through our blog!Online Courses : https://ardanlabs.com/education/ Live Events : https://www.ardanlabs.com/live-training-events/ Blog : https://www.ardanlabs.com/blog Github : https://github.com/ardanlabs
"It's not enough just being right. You've got to actually convince people of your way of thinking and take other people on the journey". Off Script is back with Josh and James hosting the first episode in a massive two-parter! They take lessons and hot topics from the recent Off Script Live event in Leeds. Dive into the modern challenges and the future direction of leadership in software engineering in this episode. Part 2 out soon! Subscribe so you don't miss it. Recorded: 27th November 2024 Recap re:invent festival AI announcements Event themes Remote & Hybrid working Slack working dynamics Methods of communication Importance of communication Huddle to convey tone of information Reduce crosstalk and chatter Mandating behaviour vs Encouraging participation Sarah Wells Talk - Nudge Theory - LINK Make it easy for people to do the right thing Diversity, Equity, and Inclusion (DEI) Hiring policies Soft Skills in hybrid working Empowering vs washing hands of decisions AI Important to understand the black box Using AI for leadership decisions Reference * https://www.youtube.com/watch?v=UxcgywwC4u8 (https://www.youtube.com/watch?v=UxcgywwC4u8) Find out more about Stac and Parallax: * https://stac.works (https://stac.works) * https://parall.ax (https://parall.ax)
In this Thanksgiving repeat episode, Tanner Linsley, creator of TanStack and co-founder at Nozzle, dives into the evolution and philosophy behind TanStack, his work on TanRouter, and shares insights on the importance of type safety in routing within web development. Links https://x.com/tannerlinsley https://tannerlinsley.com https://www.youtube.com/tannerlinsley https://github.com/tannerlinsley https://www.linkedin.com/in/tannerlinsley https://tanstack.com We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understand where your users are struggling by trying it for free at [LogRocket.com]. Try LogRocket for free today.(https://logrocket.com/signup/?pdr) Special Guest: Tanner Linsley.
Join us as we chat about frontend development with Lars Erik Bruce and Therese Ring Persen! Lars-Erik, a senior software developer, shares his insights on the importance of coding. He emphasizes that code should not only be effective but also easily readable for future developers. Therese, also a senior software developer dives into the broader picture, highlighting the critical role of frontend in integrating technology, branding, security, and cost management. They further explain why effective communication in frontend development is essential, as many opinions need to be heard when setting up an application, leading to a cohesive final product. Listen to this information-packed session to learn more!
Speaker: Honey Mittal, Co-Founder, CEO & CPO at Locofy.aiHost: Krystian Bergmann, AI Consulting Lead at NetguruThis session was a part of Disruption Forum Design Horizons.
Die Website im Designprozess auf Barrierefreiheit zu testen, ist Qualitätskontrolle. Im zweiten Teil unseres Gesprächs mit Sarah Fossheim vertiefen wir das Thema Barrierefreiheit und dessen Einfluss auf den Designprozess. Sarah berichtet, wie eine sorgfältige Berücksichtigung von Barrierefreiheit dazu führen kann, dass Entwickler und Designer besseren und standardkonformen Code schreiben. Diese Praxis verbessert nicht nur die Zugänglichkeit, sondern auch die Robustheit und Qualität der Webprojekte. Wie das Einbeziehen von Barrierefreiheit in den Entwicklungsprozess nicht nur ein breiteres Publikum erreicht, sondern auch dazu beiträgt, effizientere und durchdachtere Produkte zu erstellen. Und wir sprechen darüber, wo Barrierefreiheit noch nicht weit genug oder vielleicht sogar zu weit geht. Mehr über Sarah Fossheim: https://fossheim.io/Sarah Fossheim CSS art@fossheim@frontend.social auf MastodonSarah Fossheim auf Linkedin: https://www.linkedin.com/in/sarah-fossheim/ Semantic htmlWCAGBarrierefreiheitsstärkungsgesetz (BFSG) Das ist Besser mit Design, ein Wahnsinn Design PodcastVielen Dank fürs Zuhören
In this episode, Amy, Brad, and guest Alex dive into cutting-edge CSS features that are transforming web development. They explore container queries, logical properties, CSS layers, and scopes, sharing practical applications and browser support updates. The trio also discusses Tailwind CSS and its role in modern web design, offering spicy takes on its implementation.SponsorWix Studio combines the best of both worlds—intuitive design tools for clients and full-stack flexibility for developers. Customize every detail with your own code and take control of your projects.Show Notes00:00 - Welcome and Introductions01:16 - Shoutout to Wix Studio03:12 - CSS as a Typed Language04:10 - The Magic of CSS Layers07:38 - Logical Properties and Global Support10:47 - Browser Wars: Who's Leading in CSS?20:24 - Container Queries in Action25:37 - CSS Scopes and Their Potential28:03 - Revolutionizing CSS: Style Queries and Beyond36:12 - Tailwind CSS: A Spicy Debate46:13 - Picks and PlugsAlex's Pick: Dropout.tv, especially Gastronauts.Alex's Plug: Speaking at Connect Tech (Atlanta) and Codemash (Ohio). Socials: @fimion (Twitter), @DangitAlex.wtf (Blue Sky)Brad's Pick: Love is Blind season and reunion episodes.Brad's Plug: New to Blue SkyAmy's Pick: Happy Little Dinosaurs board gameAmy's Plug: Freaking Full Stack workshopLinksRaindrop.ioInterop 2025 ListTailwindCSS
In this episode of Cutting Edge: Web Content Development, host Jonathan Ames is joined by Chandan Pasunoori, Director of Product Engineering at Nvizion Solutions, to explore the intricacies of web framework selection, performance optimization, and the evolution of web development. They discuss how to choose the right framework for different project needs, overcome common implementation challenges, and achieve microsecond-level response times in web applications.
Tanner Linsley, creator of TanStack and co-founder at Nozzle, dives into the evolution and philosophy behind TanStack, his work on TanRouter, and shares insights on the importance of type safety in routing within web development. Links https://x.com/tannerlinsley https://tannerlinsley.com https://www.youtube.com/tannerlinsley https://github.com/tannerlinsley https://www.linkedin.com/in/tannerlinsley https://tanstack.com We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understand where your users are struggling by trying it for free at [LogRocket.com]. Try LogRocket for free today.(https://logrocket.com/signup/?pdr) Special Guest: Tanner Linsley.
Shruti Kapoor, lead member of Technical Staff at Slack, explores the new features and updates in React 19. From enhanced form handling to the introduction of React Actions and the React Compiler, this episode provides valuable insights for developers eager to leverage the latest advancements in React. Links https://www.linkedin.com/in/shrutikapoor08 https://shrutikapoor.dev https://x.com/shrutikapoor08 https://www.youtube.com/@shrutikapoor08 bit.ly/shruti-newsletter bit.ly/shruti-discord https://github.com/shrutikapoor08 https://github.com/reactwg/react-compiler https://bit.ly/shruti-discord https://www.youtube.com/watch?v=ExZUdkfu-KE&t=810s We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understand where your users are struggling by trying it for free at [LogRocket.com]. Try LogRocket for free today.(https://logrocket.com/signup/?pdr) Special Guest: Shruti Kapoor.
In this episode of PodRocket, Joel Hooks, creator of egghead.io, talks about the power of durable, event-driven workflows, the practicalities and benefits of serverless as a billing model, the intricacies distributed systems, and more. Links https://joelhooks.com https://x.com/jhooks https://www.linkedin.com/in/joelhooks https://egghead.io https://www.coursebuilder.dev/tips/using-inngest-to-add-email-automation-feature-to-pro-next-js-adt43 We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understand where your users are struggling by trying it for free at [LogRocket.com]. Try LogRocket for free today.(https://logrocket.com/signup/?pdr) Special Guest: Joel Hooks.
Ray Deck, a seasoned data scientist and founder of State Change AI, talks about the evolving landscape of software development with the rise of no code and low code platforms. He explains how these tools are not just for non-technical founders but also offer significant advantages to experienced developers. The episode explores the practical applications of no code tools in business and how they can lead to faster, more efficient product development.Show Notes00:00 - Introduction to the episode and guest Ray Deck01:02 - Ray's background in data science and founding State Change AI03:01 - The concept of no code and low code and their impact on accessibility07:06 - Choosing between no code, low code, and traditional coding09:12 - Pitching no code tools to developers14:01 - When to use no code vs. custom developmentOutSystemsMendixXanoFlutter FlowWeWebWebflow24:06 - Automation as a critical component of no code solutionsZapierBuildShipFastGen32:00 - Discussing State Change AI's role in the no code ecosystemBubble39:27 - Picks and PlugsJames's Pick: Powerstep Inserts - High-quality shoe inserts for added comfort.James's Plug: Learn Build Teach Community - A Discord community for developersBekah's Pick: Flux Footwear - Zero drop shoes ideal for walking, weightlifting, and runningBekah's Plug: 29 Days of Open Source Series on Dev.to - Highlighting open-source alternatives to proprietary software.Ray's Pick: Ollama - Open-source platform for running large language models locally.Ray's Plug: State Change AI YouTube Channel - Focusing on the hardest projects in no code and low code.
Matheus Albuquerque discusses the basics, benefits, and common pitfalls of Atomic CSS, while giving insights into best practices for using utility-first styling in modern web development projects. Links https://www.ythecombinator.space https://x.com/ythecombinator https://github.com/ythecombinator https://www.linkedin.com/in/ythecombinator We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understand where your users are struggling by trying it for free at [LogRocket.com]. Try LogRocket for free today.(https://logrocket.com/signup/?pdr) Special Guest: Matheus Albuquerque.
Marc Hess, a Developer Advocate at Prisma, talks about the evolution of Prisma from an ORM tool to a comprehensive platform for database management. The discussion includes practical advice on using Prisma, optimizing documentation, and Marc's experience with developer advocacy. The team also explores the benefits of Prisma Pulse for real-time applications and how it compares to other ORM tools like Drizzle.Sponsor ConvexConvex is the backend for founders. Convex is the backend application platform for product-obsessed founders.Show Notes00:00 - Introduction and Sponsor Shoutout00:43 - Sponsor: Convex01:06 - Introducing Marc Hess from PrismaPrismaRedwoodJS04:04 - YouTube Content Creation Tips11:24 - Introduction to Prisma and Its Products14:19 - Deep Dive into Prisma Pulse19:06 - Best Practices for DocumentationPrisma DocumentationDivio's Documentation System29:13 - Client Extensions in PrismaPrisma Client Extensions37:13 - Prisma vs Drizzle DiscussionDrizzle44:00 - Picks and Plugs Segment
Alexandra Spalato, AI integration specialist and frontend visionary, discusses how AI is revolutionizing the workflow for React developers, the indispensable tools making development faster and more efficient, and the exciting possibilities AI opens up for the entire software development process. Links https://www.alexandraspalato.com https://x.com/alexadark https://github.com/alexadark https://www.linkedin.com/in/alexandraspalato https://www.latent.space/p/ai-engineer https://cursor.sh https://pieces.app https://sourcegraph.com https://www.langchain.com https://www.llamaindex.ai https://langbase.com We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understand where your users are struggling by trying it for free at [LogRocket.com]. Try LogRocket for free today.(https://logrocket.com/signup/?pdr)
Evan Bacon joins to the pod to talk about the latest advancements in React Native and the Expo Router. He discusses React Server Components, state management, and the new features coming in Expo SDK 52. Links https://evanbacon.dev https://github.com/EvanBacon https://x.com/Baconbrix We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understand where your users are struggling by trying it for free at [LogRocket.com]. Try LogRocket for free today.(https://logrocket.com/signup/?pdr) Special Guest: Evan Bacon.
Retool is a platform to help engineers quickly build internal frontends. It does this by abstracting away repetitive aspects of frontend development. The platform was started in 2017 and has received funding from Sequoia, Stripe Co-Founders, and Nat Friedman. David Hsu is the founder and CEO of Retool. He joins the show to talk about The post Fast Frontend Development with David Hsu appeared first on Software Engineering Daily.
Retool is a platform to help engineers quickly build internal frontends. It does this by abstracting away repetitive aspects of frontend development. The platform was started in 2017 and has received funding from Sequoia, Stripe Co-Founders, and Nat Friedman. David Hsu is the founder and CEO of Retool. He joins the show to talk about The post Fast Frontend Development with David Hsu appeared first on Software Engineering Daily.
Atila Fassina, a GDE for web technologies and SolidJS developer, discusses the exciting release of SolidStart v1.0, its unique philosophy, and the journey behind its development. Links https://atila.io https://twitter.com/atilafassina https://github.com/atilafassina https://www.youtube.com/AtilaIO https://mas.to/@atila https://www.linkedin.com/in/AtilaFassina https://www.solidjs.com/blog/solid-start-the-shape-frameworks-to-come https://x.com/solid_js https://discord.com/invite/solidjs We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket combines frontend monitoring, product analytics, and session replay to help software teams deliver the ideal product experience. Try LogRocket for free today. (https://logrocket.com/signup/?pdr) Special Guest: Atila Fassina.
Join Emily and PodRocket hosts Noel and Paul as they revisit predictions from last year, dive into the latest announcements from Vercel Ship including React 19 and Next.js 15, explore the merging of Remix into React Router, and share their hot takes on current industry trends. Links https://www.linkedin.com/in/noel-minchow https://www.linkedin.com/in/paul-mikulskis-37a50b4a https://x.com/emily_kochanek https://www.linkedin.com/in/emily-kochanek-11582750/ We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanek@logrocket.com (mailto:emily.kochanek@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket combines frontend monitoring, product analytics, and session replay to help software teams deliver the ideal product experience. Try LogRocket for free today. (https://logrocket.com/signup/?pdr)
In Elixir Wizards Office Hours Episode 8, hosts Sundi Myint and Owen Bickford lead an engaging Q&A session with co-host Dan Ivovich, diving deep into the nuances of DevOps. Drawing from his extensive experience, Dan navigates topics from the early days before Docker to managing diverse polyglot environments and optimizing observability. This episode offers insights for developers of all levels looking to sharpen their DevOps skills. Explore the realms of Docker, containerization, DevOps workflows, and the deployment intricacies of Elixir applications. Key topics discussed in this episode: Understanding DevOps and starting points for beginners Best practices for deploying applications to the cloud Using Docker for containerization Managing multiple programming environments with microservices Strategies for geographic distribution and ensuring redundancy Localization considerations involving latency and device specs Using Prometheus and OpenTelemetry for observability Adjusting scaling based on application metrics Approaching failure scenarios, including database migrations and managing dependencies Tackling challenges in monitoring setups and alert configurations Implementing incremental, zero-downtime deployment strategies The intricacies of hot code upgrades and effective state management Recommended learning paths, including Linux and CI/CD workflows Tools for visualizing system health and monitoring Identifying actionable metrics and setting effective alerts Links mentioned: Ansible open source IT automation engine https://www.ansible.com/ Wikimedia engine https://doc.wikimedia.org/ Drupal content management software https://www.drupal.org/ Capistrano remote server automation and deployment https://capistranorb.com/ Docker https://www.docker.com/ Circle CI CI/CD Tool https://circleci.com/ DNS Cluster https://hex.pm/packages/dnscluster ElixirConf 2023 Chris McCord Phoenix Field Notes https://youtu.be/Ckgl9KO4E4M Nerves https://nerves-project.org/ Oban job processing in Elixir https://getoban.pro/ Sidekiq background jobs for Ruby https://sidekiq.org/ Prometheus https://prometheus.io/ PromEx https://hexdocs.pm/promex/PromEx.html GitHub Actions - Setup BEAM: https://github.com/erlef/setup-beam Jenkins open source automation server https://www.jenkins.io/ DataDog Cloud Monitoring https://www.datadoghq.com/
In Office Hours Episode 6, SmartLogic Developers Anna Dorigo and Bilal Hankins join Elixir Wizards Sundi and Dan to discuss their experiences maintaining a decade-old Ruby on Rails codebase. They delve into the critical importance of deeply understanding the codebase, keeping dependencies current, and adapting to the original application's evolving priorities and design choices. The conversation spans a range of topics, including accessibility, testing, monitoring, and the challenges of deploying database migrations in production environments. The guests share effective strategies for sustaining and enhancing older codebases, such as employing automated tools, performing code audits, and adhering to clean coding principles. Key topics discussed in this episode: Grasping the legacy codebase and its historical context Overcoming accessibility issues in older applications Safe dependency management and upgrades The effects of application scaling on database performance The critical role of comprehensive test suites in legacy systems Using tools like Sentry for error tracking and performance monitoring The benefits of automated security and dependency scans Juggling client needs with budget constraints Local simulation techniques for large datasets The value of iterative code reviews and maintaining clean code Utilizing git history for contextual understanding Onboarding strategies for legacy projects Removing obsolete code and avoiding "magic numbers" Importance of descriptive naming for better code clarity Leveraging a rich repository of example code for learning and reference Proactive code audits to anticipate issues Managing pull request sizes for smoother reviews Communicating effectively about upgrades and potential impacts Strategies for handling large databases efficiently Ensuring thorough test coverage Keeping open lines of communication with clients regarding ongoing maintenance Links mentioned: COBOL programming language https://developer.ibm.com/languages/cobol/ Ruby on Rails https://rubyonrails.org/ ARIA Rules (Accessible Rich Internet Applications) https://www.w3.org/TR/using-aria/ Shawn Vo on Elixir as a Competitive Advantage https://smartlogic.io/podcast/elixir-wizards/s5e5-vo/ Bundler Audit Ruby Gem https://rubygems.org/gems/bundler-audit/ Sentry application monitoring and error tracking software https://sentry.io/ Dependabot Github automated dependency updates Mix hex.audit https://hexdocs.pm/hex/Mx.Tasks.Hex.Audit.html Git Blame https://git-scm.com/docs/git-blame Cow hoof trimming videos - The Hoof GP on YouTube (TW graphic imagery) Special Guests: Anna Dorigo and Bilal Hankins.
In today's episode, Elixir Wizards Owen and Dan delve into the complexities of building advanced reporting features within software applications. They share personal insights and challenges encountered while developing reporting solutions for user-generated data, leveraging both Elixir/Phoenix and Ruby on Rails. The discussion zeroes in on crucial data modeling and architectural decisions that enhance reporting efficiency and flexibility. Owen and Dan explore tactics like materialized views, event sourcing, and database triggers to optimize data handling while being mindful of UX elements like progress indicators and background job management. They share insights on leveraging the Elixir/Beam ecosystem's strengths—like concurrency and streamlined deployment—to tackle common reporting, caching, and integration challenges. The episode highlights the impact of reporting features across all aspects of a software application's design and architecture. Key topics discussed in this episode: Reporting on assessment data, survey results, and user metrics Differences between reporting and performance/error monitoring Implementing reporting in Elixir/Phoenix vs. Ruby on Rails Displaying reports in web, printable, PDF, SVG, and CSV formats Challenges of generating PDFs for large data sets Streaming CSV data directly to the client Handling long-running report generation tasks Providing progress indicators and user notifications Strategies for canceling or abandoning incomplete reports Tradeoffs of pre-calculating report data vs. real-time generation Materializing views and denormalizing data for reporting Exploring event sourcing patterns for reporting needs Using database triggers and stored procedures for reporting Balancing data structure optimization for reports vs. day-to-day usage Caching report data for faster retrieval and rendering Charting and visualization integration in reporting systems Links mentioned: Prometheus monitoring system & time series database https://prometheus.io/ Thinking Elixir "FLAME with Chris McCord" https://podcast.thinkingelixir.com/181 Phoenix LiveView Uploads https://hexdocs.pm/phoenix/fileuploads.html https://hexdocs.pm/phoenixlive_view/Phoenix.LiveView.UploadWriter.html Postgrex PostgreSQL driver for Elixir https://hexdocs.pm/postgrex/Postgrex.html Ecto https://hexdocs.pm/ecto/Ecto.html Heroku cloud application platform https://www.heroku.com/ Elixir Wizards S9E12 Marcelo Dominguez on Command and Query Responsibility Segregation https://smartlogic.io/podcast/elixir-wizards/s9-e12-marcelo-dominguez-cqrs/ Commanded Elixir CQRS/ES applications https://github.com/commanded/commanded Tailwind CSS Framework https://github.com/tailwindlabs Memcached https://memcached.org/ Redis https://redis.io/ Oban https://hexdocs.pm/oban/Oban.html ETS https://hexdocs.pm/ets/ETS.html Capistrano remote server automation and deployment tool https://capistranorb.com/
How to keep up in frontend development?
What are realistic expectations when switching career to frontend development?
In Elixir Wizards Office Hours Episode 4, SmartLogic Product Designer Ava Slivkoff joins hosts Sundi Myint and Owen Bickford to discuss the product designer's role in software development. Ava shares her experience navigating client expectations, software design principles, and technical constraints. They explore the integration of design and development workflows and how designers and engineers can collaborate to meet a project's specific needs. The conversation emphasizes the value of cross-functional teams and the synergy that can arise when all team members work in harmony to bring a product to life. Key concepts discussed in the episode: The broad scope of the designer role in web app development The value of an MVP in the iterative software design process Challenges of aligning client expectations with design best practices Pros and cons of leveraging pre-built Tailwind CSS styled components Trends and evolution in web design aesthetics and patterns Leveraging open-source design systems like Tailwind UI Balancing technical constraints with design aspirations Communication and trust-building between designers and engineers Workflows for design handoffs and feedback loops Importance of user flows and mapping the product experience Challenges around the implementation of complex UI elements Benefits of regular design review meetings and syncs Fostering empathy and collaboration across disciplines Links mentioned Figma Dev Mode https://www.figma.com/dev-mode/ Tailwind CSS utility-first CSS framework https://tailwindcss.com/ Tailwind UI https://tailwindui.com/ https://devinai.ai/ Special Guest: Ava Slivkoff.
Today on Elixir Wizards Office Hours, SmartLogic Engineer Joel Meador joins Dan Ivovich to discuss all things background jobs. The behind-the-scenes heroes of app performance and scalability, background jobs take center stage as we dissect their role in optimizing user experience and managing heavy-lifting tasks away from the main application flow. From syncing with external systems to processing large datasets, background jobs are pivotal to successful application management. Dan and Joel share their perspectives on monitoring, debugging, and securing background jobs, emphasizing the need for a strategic approach to these hidden workflows. Key topics discussed in this episode: The vital role of background jobs in app performance Optimizing user experience through background processing Common pitfalls: resource starvation and latency issues Strategies for effective monitoring and debugging of task runners and job schedulers Data integrity and system security in open source software Background job tools like Oban, Sidekiq, Resque, Cron jobs, Redis pub sub CPU utilization and processing speed Best practices for implementing background jobs Keeping jobs small, focused, and well-monitored Navigating job uniqueness, locking, and deployment orchestration Leveraging asynctask for asynchronous operations The art of continuous improvement in background job management Links mentioned in this episode: https://redis.io/ Oban job processing library https://hexdocs.pm/oban/Oban.html Resque Ruby library for background jobs https://github.com/resque Sidekiq background processing for Ruby https://github.com/sidekiq Delayed Job priority queue system https://github.com/collectiveidea/delayed_job RabbitMQ messaging and streaming broker https://www.rabbitmq.com/ Mnesia distributed telecommunications DBMS https://www.erlang.org/doc/man/mnesia.html Task for Elixir https://hexdocs.pm/elixir/1.12/Task.html ETS in-memory store for Elixir and Erlang objects https://hexdocs.pm/ets/ETS.html Cron - https://en.wikipedia.org/wiki/Cron Donate to Miami Indians of Indiana https://www.miamiindians.org/take-action Joel Meador on Tumblr https://joelmeador.tumblr.com/ Special Guest: Joel Meador.
On this month's panel episode, PodRocket hosts Paige, Chris, Noel, and Paul talk about the introduction of Devin, the first AI engineer, Google's rollout of INP, and if the frontend dev is being diminished. Links https://twitter.com/trashh_dev https://www.linkedin.com/in/paul-mikulskis-37a50b4a https://staging.bsky.app/profile/noel.minc.how We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket combines frontend monitoring, product analytics, and session replay to help software teams deliver the ideal product experience. Try LogRocket for free today. (https://logrocket.com/signup/?pdr)
In this week's episode, we're joined by Nikhil Karkra, who shares his journey as a Front-end Developer in the Salesforce ecosystem. He discusses his education and early career, including his transition to IT and front-end development. Nikhil explains the role of a Front-end Developer in Salesforce and the challenges they face, such as keeping up with JavaScript frameworks and building responsive and accessible designs. He highlights the evolution of front-end development in Salesforce, from the Aura framework to Lightning Web Components (LWC) and Lightning Web Runtime (LWR). Nikhil emphasises the importance of HTML, CSS, and JavaScript fundamentals in front-end development and the need to stay updated with new frameworks. He also discusses the role of low-code development tools like OmniStudio and the importance of UX knowledge for Front-end Developers. Nikhil shares his content on YouTube and his blog, and he encourages aspiring Front-end Developers to start with Trailhead and explore other resources. Make sure you're following Nikhil on LinkedIn here: https://www.linkedin.com/in/nikhilkarkra/ You can find his blog and YouTube channel here: https://www.youtube.com/@salesforcetroop https://www.salesforcetroop.com/ You can find more content from us at Talent Hub, here: LinkedIn@ https://www.linkedin.com/company/talent-hub-global/ YouTube@ https://www.youtube.com/@talenthub1140 Facebook@ https://www.facebook.com/TalentHubGlobal/ Instagram @ https://www.instagram.com/talenthubglobal/ Twitter X @ https://twitter.com/TalentHubGlobal We hope you enjoy the episode!
Today on Elixir Wizards, Wojtek Mach of HexPM and Amal Hussein, engineering leader and former NPM team member, join Owen Bickford to compare notes on package management in Elixir vs. JavaScript. This lively conversation covers everything from best practices for dependency management to API design, SemVer (semantic versioning), and the dark ages of web development before package managers existed. The guests debate philosophical differences between the JavaScript and Elixir communities. They highlight the JavaScript ecosystem's maturity and identify potential areas of improvement, contrasted against Elixir's emphasis on minimal dependencies. Both guests encourage engineers to publish packages, even small ones, as a learning opportunity. Topics discussed in this episode: Leveraging community packages rather than reinventing the wheel Vetting packages carefully before adopting them as dependencies Evaluating security, performance, and bundle size when assessing packages Managing transitive dependencies pulled in by packages Why semantic versioning is difficult to consistently enforce Designing APIs with extensibility and backward compatibility in mind Using tools like deprecations to avoid breaking changes in new releases JavaScript's preference for code reuse over minimization The Elixir community's minimal dependencies and avoidance of tech debt Challenges in early package management, such as global dependency Learning from tools like Ruby Gems and Bundler to improve experience How log files provide visibility into dependency management actions How lock files pin dependency versions for consistency Publishing packages democratizes access and provides learning opportunities Linting to enforce standards and prevent certain bugs Primitive-focused packages provide flexibility over highly opinionated ones Suggestions for improving documentation and guides Benefits of collaboration between programming language communities Links mentioned in this episode: Node.js https://github.com/nodejs npm JavaScript Package Manager https://github.com/npm JS Party Podcast https://changelog.com/jsparty Dashbit https://dashbit.co/ HexPM Package Manager for Erlang https://hex.pm/ HTTP Client for Elixir https://github.com/wojtekmach/req Ecto Database-Wrapper for Elixir https://github.com/elixir-ecto (Not an ORM) XState Actor-Based State Management for JavaScript https://xstate.js.org/docs/ Supply Chain Protection for JavaScript, Python, and Go https://socket.dev/ MixAudit https://github.com/mirego/mixaudit NimbleTOTP Library for 2FA https://hexdocs.pm/nimbletotp/NimbleTOTP.html Microsoft Azure https://github.com/Azure Patch Package https://www.npmjs.com/package/patch-package Ruby Bundler to manage Gem dependencies https://github.com/rubygems/bundler npm-shrinkwrap https://docs.npmjs.com/cli/v10/commands/npm-shrinkwrap SemVer Semantic Versioner for NPM https://www.npmjs.com/package/semver Spec-ulation Keynote - Rich Hickey https://www.youtube.com/watch?v=oyLBGkS5ICk Amal's favorite Linter https://eslint.org/ Elixir Mint Functional HTTP Client for Elixir https://github.com/elixir-mint Tailwind Open Source CSS Framework https://tailwindcss.com/ WebauthnComponents https://hex.pm/packages/webauthn_components Special Guests: Amal Hussein and Wojtek Mach.
On today's episode, Elixir Wizards Owen Bickford and Dan Ivovich compare notes on building web applications with Elixir and the Phoenix Framework versus Ruby on Rails. They discuss the history of both frameworks, key differences in architecture and approach, and deciding which programming language to use when starting a project. Both Phoenix and Rails are robust frameworks that enable developers to build high-quality web apps—Phoenix leverages functional programming in Elixir and Erlang's networking for real-time communication. Rails follows object-oriented principles and has a vast ecosystem of plug-ins. For data-heavy CRUD apps, Phoenix's immutable data pipelines provide some advantages. Developers can build great web apps with either Phoenix or Rails. Phoenix may have a slight edge for new projects based on its functional approach, built-in real-time features like LiveView, and ability to scale efficiently. But, choosing the right tech stack depends heavily on the app's specific requirements and the team's existing skills. Topics discussed in this episode: History and evolution of Phoenix Framework and Ruby on Rails Default project structure and code organization preferences in each framework Comparing object-oriented vs functional programming paradigms CRUD app development and interaction with databases Live reloading capabilities in Phoenix LiveView vs Rails Turbolinks Leveraging WebSockets for real-time UI updates Testing frameworks like RSpec, Cucumber, Wallaby, and Capybara Dependency management and size of standard libraries Scalability and distribution across nodes Readability and approachability of object-oriented code Immutability and data pipelines in functional programming Types, specs, and static analysis with Dialyzer Monkey patching in Ruby vs extensible core language in Elixir Factors to consider when choosing between frameworks Experience training new developers on Phoenix and Rails Community influences on coding styles Real-world project examples and refactoring approaches Deployment and dev ops differences Popularity and adoption curves of both frameworks Ongoing research into improving Phoenix and Rails Links Mentioned in this Episode: SmartLogic.io (https://smartlogic.io/) Dan's LinkedIn (https://www.linkedin.com/in/divovich/) Owen's LinkedIn (https://www.linkedin.com/in/owen-bickford-8b6b1523a/) Ruby https://www.ruby-lang.org/en/ Rails https://rubyonrails.org/ Sams Teach Yourself Ruby in 21 Days (https://www.overdrive.com/media/56304/sams-teach-yourself-ruby-in-21-days) Learn Ruby in 7 Days (https://www.thriftbooks.com/w/learn-ruby-in-7-days---color-print---ruby-tutorial-for-guaranteed-quick-learning-ruby-guide-with-many-practical-examples-this-ruby-programming-book--to-build-real-life-software-projects/18539364/#edition=19727339&idiq=25678249) Build Your Own Ruby on Rails Web Applications (https://www.thriftbooks.com/w/build-your-own-ruby-on-rails-web-applications_patrick-lenz/725256/item/2315989/?utm_source=google&utm_medium=cpc&utm_campaign=low_vol_backlist_standard_shopping_customer_acquisition&utm_adgroup=&utm_term=&utm_content=593118743925&gad_source=1&gclid=CjwKCAiA1MCrBhAoEiwAC2d64aQyFawuU3znN0VFgGyjR0I-0vrXlseIvht0QPOqx4DjKjdpgjCMZhoC6PcQAvD_BwE#idiq=2315989&edition=3380836) Django https://github.com/django Sidekiq https://github.com/sidekiq Kafka https://kafka.apache.org/ Phoenix Framework https://www.phoenixframework.org/ Phoenix LiveView https://hexdocs.pm/phoenixliveview/Phoenix.LiveView.html#content Flask https://flask.palletsprojects.com/en/3.0.x/ WebSockets API https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API WebSocket connection for Phoenix https://github.com/phoenixframework/websock Morph Dom https://github.com/patrick-steele-idem/morphdom Turbolinks https://github.com/turbolinks Ecto https://github.com/elixir-ecto Capybara Testing Framework https://teamcapybara.github.io/capybara/ Wallaby Testing Framework https://wallabyjs.com/ Cucumber Testing Framework https://cucumber.io/ RSpec https://rspec.info/
This week, the Elixir Wizards are joined by Yohana Tesfazgi and Wes Bos to compare notes on the experience of learning Elixir vs. JavaScript as your first programming language. Yohana recently completed an Elixir apprenticeship, and Wes Bos is a renowned JavaScript educator with popular courses for beginner software developers. They discuss a variety of media and resources and how people with different learning styles benefit from video courses, articles, or more hands-on projects. They also discuss the current atmosphere for those looking to transition into an engineering career and how to stick out among the crowd when new to the scene. Topics Discussed in this Episode Pros and cons of learning Elixir as your first programming language Materials and resources for beginners to JavaScript and Elixir Projects and methods for learning Elixir with no prior knowledge Recommendations for sharpening and showcasing skills How to become a standout candidate for potential employers Soft skills like communication translate well from other careers to programming work Learning subsequent languages becomes more intuitive once you learn your first How to decide which library to use for a project How to build an online presence and why it's important Open-source contributions are a way to learn from the community Ship early and often, just deploying a default Phoenix app teaches deployment skills Attend local meetups and conferences for mentoring and potential job opportunities Links Mentioned https://syntax.fm/ https://fly.io/ https://elixirschool.com/en Syntax.fm: Supper Club × How To Get Your First Dev Job With Stuart Bloxham (https://syntax.fm/show/667/supper-club-how-to-get-your-first-dev-job-with-stuart-bloxham) Quinnwilton.com (https://quinnwilton.com/) https://github.com/pallets/flask https://wesbos.com/courses https://beginnerjavascript.com/ Free course: https://javascript30.com/ https://pragmaticstudio.com/ https://elixircasts.io/ https://grox.io/ LiveView Mastery YouTube Channel (https://www.youtube.com/channel/UC7T19hPLqQ-Od3Rb3T2OX1g) Contact Yohana: yytesfazgi@gmail.com
In today's episode, Sundi and Owen are joined by Yordis Prieto and Stephen Chudleigh to compare notes on HTTP requests in Elixir vs. Ruby, JavaScript, Go, and Rust. They cover common pain points when working with APIs, best practices, and lessons that can be learned from other programming languages. Yordis maintains Elixir's popular Tesla HTTP client library and shares insights from building APIs and maintaining open-source projects. Stephen has experience with Rails and JavaScript, and now works primarily in Elixir. They offer perspectives on testing HTTP requests and working with different libraries. While Elixir has matured, there is room for improvement - especially around richer struct parsing from HTTP responses. The discussion highlights ongoing efforts to improve the developer experience for HTTP clients in Elixir and other ecosystems. Topics Discussed in this Episode HTTP is a protocol - but each language has different implementation methods Tesla represents requests as middleware that can be modified before sending Testing HTTP requests can be a challenge due to dependence on outside systems GraphQL, OpenAPI, and JSON API provide clear request/response formats Elixir could improve richer parsing from HTTP into structs Focus on contribution ergonomics lowers barriers for new participants Maintainers emphasize making contributions easy via templates and clear documentation APIs drive adoption of standards for client/server contracts They discuss GraphQL, JSON API, OpenAPI schemas, and other standards that provide clear request/response formats TypeScript brings types to APIs and helps to validate responses Yordis notes that Go and Rust make requests simple via tags for mapping JSON to structs Language collaboration shares strengths from different ecosystems and inspires new libraries and tools for improving the programming experience Links Mentioned Elixir-Tesla Library: https://github.com/elixir-tesla/tesla Yordis on Github: https://github.com/yordis Yordis on Twitter: https://twitter.com/alchemist_ubi Yordis on LinkedIn: https://www.linkedin.com/in/yordisprieto/ Yordis on YouTube: https://www.youtube.com/@alchemistubi Stephen on Twitter: https://twitter.com/stepchud Stephen's projects on consciousness: https://harmonicdevelopment.us Owen suggests: Http.cat HTTParty: https://github.com/jnunemaker/httparty Guardian Library: https://github.com/ueberauth/guardian Axios: https://axios-http.com/ Straw Hat Fetcher: https://github.com/straw-hat-team/nodejs-monorepo/tree/master/packages/%40straw-hat/fetcher Elixir Tesla Wiki: https://github.com/elixir-tesla/tesla/wiki HTTPoison: https://github.com/edgurgel/httpoison Tesla Testing: https://hexdocs.pm/tesla/readme.html#testing Tesla Mock: https://hexdocs.pm/tesla/Tesla.Mock.html Finch: https://hex.pm/packages/finch Mojito: https://github.com/appcues/mojito Erlang Libraries and Frameworks Working Group: https://github.com/erlef/libs-and-frameworks/ and https://erlef.org/wg/libs-and-frameworks Special Guests: Stephen Chudleigh and Yordis Prieto.