POPULARITY
67 episodes with redwoodjs
7 episodes with redwoodjs
5 episodes with redwoodjs
3 episodes with redwoodjs
3 episodes with redwoodjs
3 episodes with redwoodjs
2 episodes with redwoodjs
2 episodes with redwoodjs
2 episodes with redwoodjs
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).
Wes talks with Peter Pistorius about RedwoodSDK, a new React framework built natively for Cloudflare. They dive into real-time React, server components, zero-cost infrastructure, and why RedwoodSDK empowers developers to ship faster with fewer tradeoffs and more control. Show Notes 00:00 Welcome to Syntax! 00:52 What is RedwoodSDK? 04:49 Choosing openness over abstraction 08:46 More setup, more control 12:20 Why RedwoodSDK only runs on Cloudflare 14:25 What the database setup looks like 16:15 Durable Objects explained – Ep 879: Fullstack Cloudflare 18:14 Middleware and request flow 23:14 No built-in client-side router? 24:07 Integrating routers with defineApp 26:04 React Server Components and real-time updates 29:53 What happened to RedwoodJS? 31:14 Why do opinionated frameworks struggle to catch on? 34:35 The problem with Lambdas 36:16 Cloudflare's JavaScript runtime compatibility 40:04 Brought to you by Sentry.io 41:44 The vision behind RedwoodSDK Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads
Google announces a new Agent2Agent protocol meant to support AI agents communicating with each other. A2A aims to complement MCP and address the challenges of deploying large-scale, multi-agent systems from various providers across different platforms and cloud environments.GitHub Copilot's new code review feature is now generally available. Just like you'd assign a coworker to review a PR, users can now assign a Copilot agent to review that same PR and spot bugs, identify potential performance problems, and suggest fixes.RedwoodJS has rebranded itself RedwoodSDK, and is focusing on a new framework that will become the foundation of a personal software revolution. RedwoodSDK promises modern serverless infrastructure, AI-driven dev tools, and open ecosystems, with more details coming soon.News:Paige - RedwoodJS becomes RedwoodSDKJack - Google's A2ATJ - Copilot code reviews & premium requestsBonus News:StackBlitz is hosting the world's largest hackathonDevin 2.0Wordpress.com launches free AI-powered website builderFire Starter:text-wrap: prettyWhat Makes Us Happy this Week:Paige - Claude AIJack - The Accountant 2 movieTJ - Apple SportsThanks as always to our sponsor, the Blue Collar Coder channel on YouTube. You can join us in our Discord channel, explore our website and reach us via email, or talk to us on X, Bluesky, or YouTube.Front-end Fire websiteBlue Collar Coder on YouTubeBlue Collar Coder on DiscordReach out via emailTweet at us on X @front_end_fireFollow us on Bluesky @front-end-fire.comSubscribe to our YouTube channel @Front-EndFirePodcast
In this episode, Amy and Brad dive into the ongoing debate between Laravel and full stack JavaScript frameworks. They explore both ecosystems from their unique perspectives. Amy shares her real-world experience building a project in Laravel after working extensively with JavaScript frameworks, highlighting where each approach shines and struggles. From Laravel's backend prowess to the cognitive load of context switching between languages, this episode offers practical insights for developers weighing these technology choices.Show Notes00:00 - Intro01:00 - Sponsorship: Sanity01:59 - Origins of the Laravel vs JavaScript Discussion03:59 - Amy's Experience Building a Project in Laravel06:59 - PHP Development and Linting Experience11:59 - Understanding MVC Architecture15:00 - Challenges with JavaScript Backend Services18:00 - Backend Strengths of Laravel20:00 - Frontend Challenges in Laravel23:00 - Comparing Laravel and JavaScript Ecosystem Solutions26:59 - JavaScript Full Stack Frameworks Discussion30:00 - Architectural Differences Between Frameworks33:00 - Framework Choice Considerations38:59 - Picks and Plugs: Newsletter and Cameras42:00 - Picks and Plugs: Games and YouTube Links and ResourcesSanity.io (sponsor)LaravelSam's podcast: Frontend FirstRedwoodJSRemixNext.jsAstroSupabaseInngestResend (email service)Postmark (email service)OpenAIPrismaPHP StormLaravel Blade (templating language)Laravel LivewireAlpine.jsLaravel BreezeLaravel Eloquent ORMAdonis/AdonisJSEpisode 54: Why RedwoodJS is the App Framework for Startups, with David PriceViteStorybookAmy's newsletter: Broken CombInsta360 X2 cameraInsta360 Go 3 cameraStardew Valley (game)Brad's YouTube channelCloudinary channel and Dev Hints series
Join Amy and Brad as they break down the latest developments in the React ecosystem following React Conf 2024. From quality-of-life improvements in React 19 to the introduction of the new React compiler, they analyze how these changes will impact everyday development. The episode features an in-depth discussion about Remix's strategic decision to focus on React Router, the ongoing debate between JavaScript frameworks and traditional backend frameworks, and thoughtful insights into choosing the right tools for your projects. Whether you're a seasoned React developer or just getting started, this episode offers valuable perspective on the future of web development.SponsorsSanity delivers content anywhere (just like a headless CMS).Beyond that, Sanity gives you total composability. A fully decoupled, real-time content back end. Entirely customizable content workspaces.Chapters00:00 - Introduction00:42 - Sponsor: Sanity02:12 - React Conf Experience05:00 - Conference Personalities08:52 - React Compiler Deep Dive13:20 - Remix "Taking a Nap" Discussion26:41 - React 19 Features33:54 - JavaScript vs PHP/Laravel Debate41:11 - Framework Decision Fatigue44:45 - Picks & Plugs
In this episode, Amy and Brad dive into the top JavaScript frameworks, weighing their strengths and weaknesses. They discuss Svelte, Astro, Next, Remix, and Redwood, comparing their rendering processes, server-side vs. client-side preferences, routing systems, and developer experiences. Perfect for developers weighing options for their next app! 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 - Intro00:40 - Sponsor: Wix Studio01:42 - Discussing JavaScript Frameworks at Momentum ConferenceMichael Richardson on TwitterTaylor Dessyn on Twitter02:54 - Momentum Conference and Cincinnati as a Tech Hub05:21 - Speaker Feedback System and Conference Experience06:12 - Key Takeaways from CSS Talk08:56 - Amy's JavaScript Cage Match Talk and Framework Overviews11:30 - Baseline Features in Frameworks: A Comparison13:18 - Framework Longevity and Stability16:33 - Server vs. Client Rendering in JavaScript Frameworks22:01 - Framework Routers and Configuration DifferencesScott Tollinski - Svelte Course29:02 - Exploring Remix's Data Loader Pattern34:00 - Performance Testing with Sentry37:17 - Middleware Usage in Different Frameworks40:58 - Which Frameworks Excel in Specific Use Cases?45:01 - Avoiding the Framework Spiral: Stick with a FavoriteDeveloper Productivity, Episode 6849:09 - Picks and Plugs Section
Kicking off the discussion is the release of Vue 3.5. Although it's not a major release, Vue 3.5 packs some great new features and optimizations like: reactivity system improvements (up to 56% less memory usage for apps than before), reactive prop destructuring stabilization (it's simpler to declare props with default values), and SSR improvements like lazy hydration for async components.RedwoodJS is also out with a new version, and 8.0 packs a wallop. It makes RedwoodJS the third framework to support React Server Components behind Next.js and Waku.The shadcn CLI has gotten an update as well where it can spin up a brand new Next.js app with shadcn and Tailwind configured and ready to go. Additionally, shadcn has integrated more tightly with Vercel's v0 AI code generator, and now every shadcn component is editable on v0, so users can customize the components in natural language and paste it into their apps afterwards. Pretty amazing!The TC39 Committee responsible for evaluating what new features get added to the JavaScript language has added a new intermediate step for proposals: step 2.7. By the time new proposals reach step 3, they must already have full test suites to support their implementation, and if, for any reason, they must go back to step 2 to rethink things, a lot of that work can be for naught.News:Paige - Vue 3.5 is outJack - RedwoodJS 8.0 and shadcn CLI updatesTJ - JavaScript Standard Gets an Extra StageList of ECMAScript proposals on GitHubBonus News:Laravel raises $57 million series ASSR benchmark wars update (author Matteo is the Fastify lead maintainer)What Makes Us Happy this Week:Paige - House of the Dragon season 2Jack - Raspberry Pi TJ - Linkin Park is back!Thanks as always to our sponsor, the Blue Collar Coder channel on YouTube. You can join us in our Discord channel, explore our website and reach us via email, or Tweet us on X @front_end_fire.Front-end Fire websiteBlue Collar Coder on YouTubeBlue Collar Coder on DiscordReach out via emailTweet at us on X @front_end_fire
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
In this episode of Compressed FM, Amy, James, and Tobbe from the Redwood JS core team explore React server components. They discuss the implementation of React server components in Redwood, the benefits, challenges, and the future of web development with this new technology.Show Notes00:00:00 - Introduction 00:00:47 - Tobbe's Background and Role at Redwood JS 00:02:03 - Tobbe's Journey with Redwood JS 00:05:14 - Discussion on React Server Components (RSCs) 00:07:00 - Explanation of Different Rendering Methods 00:12:48 - Implementing React Server Components with Vite 00:15:22 - Technical Details of RSC Implementation 00:17:19 - Streaming and Suspense in React 00:18:28 - Future Developer Experience with Redwood and RSCs 00:19:51 - Explanation of Redwood Cells 00:22:01 - DX Considerations for RSCs in Redwood 00:24:23 - State of GraphQL in Redwood's Future 00:28:34 - GraphQL's Reputation and Challenges 00:31:17 - tRPC and TypeScript Safety with RSCs 00:34:14 - Advanced RSC Features in Redwood 00:36:31 - Server Actions and Their Role in Redwood 00:39:09 - Picks and PlugsTobbe's Pick: Tretorn Rubber BootsTobbe's Plug: RedwoodJSAmy's Pick - Aeropress GoAmy's Plug - Broken Comb NewsletterJames's Pick - On/Off PlugJames's Plug - James's Newsletter
In Episode 182, hosts James and Amy delve into the intricacies of React Server Components (RSCs) and the challenges of building multi-step forms. They discuss the latest developments in RSCs, including the implementation in RedwoodJS, and share insights on managing state and validations in multi-step forms. Throughout, the hosts offer practical advice and technical deep dives, making complex topics accessible and engaging.SponsorsPostmanPostman is an API platform for building and using APIs. Postman simplifies each step of the API lifecycle and streamlines collaboration so you can create better APIs—faster.Attend their upcoming conference, April 30 - May 1, 2024 in San Francisco. Amy and James will be there in person.Show Notes00:00:00 Intro00:00:40 Sponsored by Postman00:02:07 React Server Components00:03:12 Deep dive into RSC and Redwood JS implementation details00:04:23 Explanation of React Server Components ecosystem and challengesTheo's YouTube Video: The Truth About React Server Components Ben Holmes and Dan Abramov Stream: Dan Abramov explores React Server Components with us!Episode 71: Secret Things, Env Vars, How to Handle API Keys Correctly00:36:03 Transition to multi-step forms and their complexities00:37:05 Strategies for handling form state and validation00:45:28 Detailed considerations for different form steps and data handling00:55:49 Picks and PlugsAmy's Pick: Full House on Hulu and HBO Max, Fuller House on NetflixAmy's Plug: Two Week BuildJames's Pick: Baking Sheet, Mat, and Cooling Rack SetJames's Plug: Learn, Build, Teach DiscordThe Happiness Lab Podcast: Episode - Where Everybody Knows Your Name
In this episode of Compressed FM, hosts Amy Dutton and Brad Garropy are joined by Brooks Lybrand from Shopify to explore the latest in Remix and the future of React. They discuss the integration of server components, the challenges of package management, and strategies for effective software updates. The conversation also delves into the potential of React Server Components (RSC) and the role of SPA (Single Page Application) mode in web development.SponsorsPostmanPostman is an API platform for building and using APIs. Postman simplifies each step of the API lifecycle and streamlines collaboration so you can create better APIs—faster.Attend their upcoming conference, April 30 - May 1, 2024 in San Francisco. Amy and James will be there in person.Show Notes00:00:00 Introduction and Overview00:00:44 Sponsored by PostmanPostman Conference April 30 - May 1, 2024 in San Francisco00:01:14 Discussion on ESM and Development Trends00:02:25 Challenges in Package and Library Development00:03:07 Redwood JS Developments and Insights00:04:05 Release Strategies and Development PracticesRelease Tools for Redwood00:06:02 Detailed Discussion on Development Tools and Methods00:21:08 Future of Development Tools and Techniques00:25:53 Q&A on Technical Aspects and Team Dynamics00:35:48 Discussion on Single Fetch and Data Fetching Strategies00:37:17 Frameworks and Developer ChoicesBlog Post comparing Next.js App, Next.js Pages, Remix, and RedwoodJS Router00:43:46 The Future of React and Remix with RSC00:48:09 Wrap-up and Picks and Plugs SegmentBrook's Pick: Apple's Air Pods ProBrook's Plug: React RouterBrad's Pick: New Puppy (Blog Post)Brad's Plug: Brad's YouTube ChannelAmy's Pick: Deep Questions Podcast with Cal NewportAmy's Plug: Amy's YouTube Channel00:50:25 Closing
It turns out we had a lot of news to cover in this week's episode. We kicked it off discussing how RedwoodJS is the latest framework to support React Server Components, and has some pretty nice illustrated docs to help devs get started. Then, there was a rapid fire of interesting topics including a great new article about modern CSS from Mr. CSS Tricks himself, Chris Coyier, a new documentary film on the origin story of Node.js from the team that created the React and Ruby on Rails documentaries as well, and a footnote about a new antitrust case the US Department of Justice has leveraged against Apple. At NG Conf earlier in the week, it was announced Google's internal framework Wiz might be combining with Angular after the two teams successfully worked together to launch Angular signals primitives for 100% of YouTube's mobile web traffic to great effect. We can only hope the resulting combined framework is renamed to Wangular. And to round it all out, yet another CSS framework has popped up claiming to have all the answers to the ever pervasive feeling that CSS is hard. Will Nue CSS have the good to back up its claim? We'll have to wait and see, and give the new Promise.withResolvers a spin in the meantime.News:Paige - Wiz and Angular combine forcesJack - RedwoodJS supports RSCsTJ - What You Need to Know About Modern CSS, DOJ antitrust case against Apple, and Node.js: The Documentary | An origin storyBonus News:Nue CSSPromise.withResolvers() MDN Docs and a helpful explainer tweet from Wes BosWhat Makes Us Happy this Week:Paige - Masters of the Air TV seriesJack - Learning stuff! Like vector DBsTJ - Booking tours of the U.S. Capitol and White House through local repsThanks as always to our sponsor, the Blue Collar Coder channel on YouTube. You can join us in our Discord channel, reach out to us via email or Tweet us on X @front_end_fire.Blue Collar Coder on YouTubeBlue Collar Coder on DiscordReach out via emailTweet at us on X @front_end_fire
Join hosts RobbieTheWagner and Charles William Carpenter III as they delve into a wide variety of topics on their podcast, Whiskey Web and Whatnot. This episode features a detailed tasting of the Booker's Small Batch, Kentucky Straight Bourbon Whiskey – the Storyteller Batch. The hosts talk in-depth about the bourbon, its packaging, and flavors. Robbie and Charles go on to share their thoughts on the intricacies of web development, discussing the pros and cons of latest web frameworks. Additionally, they dive into personal anecdotes, talking about the winter and the joys of playing video games. Tune in for an engaging blend of whiskey sipping, tech talk, and casual banter. Key Takeaways [01:07] - Unboxing and Introduction to Booker's Bourbon [01:51] - Tasting and Reviewing the Whiskey [03:06] - Diving into Personal Stories and Jokes [03:28] - Analyzing the Whiskey's Aroma and Flavor [04:37] - Continuing the Whiskey Tasting and Discussion [07:10] - Final Thoughts and Rating of the Whiskey [13:02] - Transitioning to Tech Talk: Web Development [13:08] - Discussing Syntax Swag and Whiskey Web Merch [15:47] - Debate on React and Next.js [26:12] - Exploring Redwood JS and Django [34:39] - Discussing Web Development Frameworks [35:09] - Exploring Astro and HTMX [36:32] - Debate on JSON and JavaScript [38:19] - The Evolution of Web Design [39:10] - The Whiskey Experiment [40:27] - Snowy Adventures and Commuting Challenges [42:59] - The Quest for the Perfect Electric Car [51:23] - The Joys and Pains of Lawn Mowing [53:01] - TV Shows, Video Games, and Time Management [01:01:04] - Wrapping Up with Netflix and Barbie Links Booker's Bourbon Syntax Next.js RedwoodJS Astro HTMX Connect with our hosts Robbie Wagner Chuck Carpenter Subscribe and stay in touch Apple Podcasts Spotify Google Podcasts Whiskey Web and Whatnot Whiskey Web and Whatnot Merch Enjoying the podcast and want us to make more? Help support us by picking up some of our fresh merch at https://whiskey.fund/. --- Send in a voice message: https://podcasters.spotify.com/pod/show/whiskey-web-and-whatnot/message
Recording date: Aug 31, 2023Host:John Papa @John_PapaGuest:Tom Preston-Werner @MojomboBrought to you byAG GridNarwhal Visit nx.dev to get the preeminent open-source toolkit for monorepo development, today. Resources:RedwoodJS on Web Rush with Anthony Campolo episode 119RedwoodJSTypeScriptNext.jsReact.jsAuth0Netlify and RedwoodJSVercel and RedwoodJSPrisma and RedwoodJSGraphQL and RedwoodJSWhat is a meta-frameworkTailwind with RedwoodJSJest with RedwoodJSStorybook with RedwoodJSRedwoodJS and ViteNext Gen tooling with RedwoodJS with Vite and VitestReact server componentsRedwoodJS and react server componentsPublic roadmap for RedwoodJS Bighorn EpochWhy would I choose RedwoodJS over Next.jsPino loggingRedwoodJS startup fundChatterbugRedwoodJS tutorialRedwoodJS on YouTubeRedwoodJS Conference in September 2023Timejumps00:29 Welcome00:43 Who is Tom Preston-Werner?02:14 What is RedwoodJS?09:21 Sponsor: Narwhal Nx10:00 How do you evaluate new technology and integrate it into Redwood?19:36 How does RedwoodJS go further than NextJS?27:56 What is startups at scale?37:00 Sponsor: Ag Grid38:11 Maintainability of software43:53 Final thoughtsPodcast editing on this episode done by Chris Enns of Lemon Productions.
In episode 133 of Jamstack Radio, Brian speaks with Tom Preston-Werner, founder of GitHub and creator of RedwoodJS. This talk explores React server components, the origin story of RedwoodJS and its latest offerings, the inherent rewards of working in open source, and the tedious lifecycle of application development.
In episode 133 of Jamstack Radio, Brian speaks with Tom Preston-Werner, founder of GitHub and creator of RedwoodJS. This talk explores React server components, the origin story of RedwoodJS and its latest offerings, the inherent rewards of working in open source, and the tedious lifecycle of application development.
Tom Preston-Werner is a renowned software developer, inventor and entrepreneur. He co-founded GitHub and is the creator of the avatar service Gravatar, the TOML configuration file format, and the static site generator software Jekyll. Tom is currently working on the full-stack web framework, RedwoodJS. He joins us today to tell us the latest about RedwoodJS, The post The Latest on RedwoodJS with Tom Preston-Werner appeared first on Software Engineering Daily.
Tom Preston-Werner is a renowned software developer, inventor and entrepreneur. He co-founded GitHub and is the creator of the avatar service Gravatar, the TOML configuration file format, and the static site generator software Jekyll. Tom is currently working on the full-stack web framework, RedwoodJS. He joins us today to tell us the latest about RedwoodJS, The post The Latest on RedwoodJS with Tom Preston-Werner appeared first on Software Engineering Daily.
Tom Preston-Werner is a renowned software developer, inventor and entrepreneur. He co-founded GitHub and is the creator of the avatar service Gravatar, the TOML configuration file format, and the static site generator software Jekyll. Tom is currently working on the full-stack web framework, RedwoodJS. He joins us today to tell us the latest about RedwoodJS, The post The Latest on RedwoodJS with Tom Preston-Werner appeared first on Software Engineering Daily.
Tom joins James and Amy to talk all things React and Redwood and give a convincing pitch for the very first RedwoodJS conference.Show Notes00:00 Introduction and Welcome Tom02:36 Why Redwood07:40 Coming Full Circle in Tech17:23 Cell Pattern18:38 Streaming21:19 Natural Progression29:29 Boundaries of API and UI35:34 Custom API Functions36:42 Edge Deployment40:11 Modern Databases47:43 State of React Server Components54:33 Picks and Plugs
In this week's roundup, hear snippets from our discussions with Tom Preston-Werner about React Server Components, our panel on the success of Next.js, and Tejas Kumar on the benefits of Zod and tRPC when working with TypeScript. Links Apple Tom Preston-Werner talks React Server Components and the future of RedwoodJS: https://apple.co/3poFcIk Stack Overflow survey, React Server Components, and Google Domains: https://apple.co/3PzzCNS Zod and tRPC with Tejas Kumar: https://bit.ly/46ydKsi Google Tom Preston-Werner talks React Server Components and the future of RedwoodJS: https://bit.ly/3CPEPtp Stack Overflow survey, React Server Components, and Google Domains: https://bit.ly/44fq2Uy Zod and tRPC with Tejas Kumar: bit.ly/3JHXOd2 Spotify Tom Preston-Werner talks React Server Components and the future of RedwoodJS: https://spoti.fi/42VdxMM Stack Overflow survey, React Server Components, and Google Domains: https://spoti.fi/46vH2HW Zod and tRPC with Tejas Kumar: bit.ly/3CZaiJB Tell us what you think of PodRocket We want to hear from you! We want to know what you love and hate about the podcast. What do you want to hear more about? Who do you want to see on the show? Our producers want to know, and if you talk with us, we'll send you a $25 gift card! If you're interested, schedule a call with us (https://podrocket.logrocket.com/contact-us) or you can email producer Kate Trahan at kate@logrocket.com (mailto:kate@logrocket.com) 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 Guests: Colby Fayock, Jason Lengstorf, Shruti Kapoor, Tejas Kumar, and Tom Preston-Werner.
Tom Preston-Werner talks to us about how the Redwood team is going all in on React Server Components. Links https://twitter.com/mojombo https://www.linkedin.com/in/mojombo https://tom.preston-werner.com/2023/05/30/redwoods-next-epoch-all-in-on-rsc.html https://www.redwoodjsconf.com Tell us what you think of PodRocket We want to hear from you! We want to know what you love and hate about the podcast. What do you want to hear more about? Who do you want to see on the show? Our producers want to know, and if you talk with us, we'll send you a $25 gift card! If you're interested, schedule a call with us (https://podrocket.logrocket.com/contact-us) or you can email producer Kate Trahan at kate@logrocket.com (mailto:kate@logrocket.com) 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: Tom Preston-Werner.
Zach Lloyd is the CEO of Warp, a Rust-based terminal for modern development.In this episode we discuss the motivations for starting an entire company dedicated to building a terminal, the inefficiencies introduced by the current default terminals, and the company's future plans for monetization.Zach Lloyd Twitter LinkedIn Blog Warp Homepage Twitter GitHub Discord YouTube Links Oh My Zsh Starship Show Outline00:10 - Zach's background and motivation for creating Warp02:13 - What are the Warp features that make developers more productive?07:01 - Why is Warp written in Rust?10:36 - Does Warp work on multiple platforms?12:22 - How does Warp plan on monetizing in the future?16:06 - What are the benefits of Warp for beginners learning the terminal?22:29 - What shells does Warp support?25:17 - How do you prioritize feature development and what is the roadmap for the next sixth months?29:31 - Will Warp eventually be integrated with the VS Code terminal?31:43 - Final thoughts and where to learn more about Warp
Daniel Norman is a Developer Advocate at Protocol Labs. In this episode we discuss the philosophy and motivation behind the creation of IPFS, IPFS pinning services and gateways, how Protocol Labs relates to IPFS, and how to moderate content on a distributed, censorship resistant network.Daniel Norman Twitter Homepage Protocol LabsHomepageIPFSHomepageLinks Aragon web3.js Prisma Content Addressing Bluesky AT Protocol Fleek web3.storage Infura Pinata IPFS - Content Addressed, Versioned, P2P File System Cloudflare IPFS Gateway Fission State of IPFS in JS A First Look at IPFS Some Antics - Deploy to the Decentralized Web with IPFS Show Outline00:11 - Daniel's code journey11:19 - What is web3?13:36 - What does it mean to “own” something digital?22:19 - Bluesky and the At Protocol25:35 - Living in a high trust society28:01 - What is IPFS?36:32 - IPFS pinning services and gateways45:23 - Protocol Labs48:20 - Is it possible to block or moderate content on IPFS?54:58 - Where should someone go to get started with IPFS or get in touch with the IPFS community?58:17 - How can listeners get in touch with Daniel?
Adam Bradley is the Director of Technology at Builder.io and co-creator of Partytown, a lazy-loaded library to help relocate resource intensive scripts off the main thread and into a web worker.In this episode we discuss making sites significantly more performant by offloading third party scripts into a web worker with Partytown, how Partytown fits into the larger suite of tools that Builder.io is working on including Qwik, and cross-compiling any frontend UI library with Mitosis.Adam Bradley Twitter GitHub Partytown Homepage GitHub Links WordPress Partytown Support Add Partytown support to run scripts in WordPress Worker Thread Offloading Scripts To A Web Worker in Next.js (experimental) How to Add Google Analytics gtag to Gatsby Using Partytown How to Deploy the Qwik JavaScript Framework Deploy a Qwik site on Cloudflare Pages Building Marko 6 w/ Dylan Piercey, and Michael Rawlings Resumability, WTF? Show Outline00:12 - Introduction01:26 - Do you miss mobile?04:43 - What is Partytown?07:50 - Can you use Partytown with WordPress?09:42 - How does Google Tag Manager work with Partytown?12:45 - Is there a roadmap for upcoming features or is Partytown feature complete?13:50 - What is Partytown's opinion on shipping no JavaScript?14:39 - How does Partytown fit into the larger suite of tools that Builder.io is working on?16:24 - Qwik as a server-side rendering first framework with QwikCity19:35 - Will it be possible in the future to migrate a Next.js project to QwikCity? 23:07 - Is QwikCity production ready?25:00 - How do you deploy a Qwik or QwikCity application?30:45 - What is Mitosis?34:19 - How does Qwik compare to Solid and Marko?40:09 - Will JavaScript ever reach utopia by attaining the nirvana of PHP?
In this episode we discuss the origin of the name “Fuzzy Bear,” the benefits of learning Astro over other popular metaframeworks, and how to get involved in the Astro community.A Fuzzy Bear Twitter GitHub Astro Homepage Create a New Astro Project Links Asteroids Fuzzybear Project Server-side Rendering in Astro Astro Hackathon Projects Show Outline01:15 - What is the origin of the name “Fuzzy Bear?”03:13 - Why did you learn Astro over other frameworks and when did you join the team?06:00 - The pitfalls of Create React App08:30 - Fuzzy's life before web development09:48 - Learning web development through building the Astroids game12:10 - Fuzzy got into web development to make money but tripped into open source12:50 - How did you first hear about Astro?15:22 - How did you initially get involved in the Astro community?19:41 - What is the status of server-side rendering support in Astro?22:24 - What happened when Chris tried Astro for the first time?33:09 - Can Astro be used for dashboards? -------------------This episode is sponsored by Cloud66, a platform that allows you to deploy Jamstack sites on any cloud for just $1.99 per site per month. It's like your own Netlify and includes free unlimited team members, real-time logs, programmable traffic management, SSL certificates, and more. You can get started with Cloud 66 for free and get an extra $66 of free credits with the code FSJam-66.
In this episode we discuss how DevRel is organized at Supabase, why Supabase decided to build their own PostgreSQL extension, and new capabilities enabled by Supabase's Edge Functions. Jon Meyers Homepage Twitter GitHub YouTube Egghead Supabase Homepage Twitter GitHub YouTube Discord Links Supabase with Paul Copplestone (FSJam33) Open Source Stacks with Ant Wilson (FSJam52) pg_graphql: A GraphQL extension for PostgreSQL GraphQL is now available in Supabase pg_graphql v1.0 pg_graphql Documentation Launch Week Updates for Supabase Functions Supabase Edge Functions Edge Function Examples Supabase Integrations Supabase Series B Made with Supabase Show Outline01:25 - Jon Meyers Introduction04:44 - How is the DevRel team at Supabase organized?06:41 - What is Supabase?07:55 - Building and Using Postgres Extensions10:46 - How does the GraphQL Postgres Extension Work?12:15 - What is Supabase Launch Week?14:19 - Supabase Edge Functions22:31 - Supabase Integrations24:11 - Supabase Series B25:27 - What are people building with Supabase?27:24 - Jon's Favorite FSJam Episodes30:03 - Closing Thoughts-------------------This episode is sponsored by Cloud66, a platform that allows you to deploy Jamstack sites on any cloud for just $1.99 per site per month. It's like your own Netlify and includes free unlimited team members, real-time logs, programmable traffic management, SSL certificates, and more. You can get started with Cloud 66 for free and get an extra $66 of free credits with the code FSJam-66.
In episode 117 of Jamstack Radio, Brian is joined by Amanda Giannelli of Okta. This talk focuses on the full-stack web framework RedwoodJS, how it helped Amanda learn JavaScript, and her experience as a core team member and contributor. Other themes includes insights on getting started with open source and engaging with developer communities.
In this episode we discuss the past, present, and future of running serverless functions on the edge, why Netlify decided to build their edge functions with Deno, and the need for compatible edge runtimes built on open standards.Eduardo Bouças Homepage Twitter Mastodon GitHub Netlify Homepage Twitter GitHub Links Edge Handlers with Mathias Biilmann Christensen Netlify Edge Functions Edge Functions Documentation Netlify Edge Functions: A new serverless runtime powered by Deno Living on the edge: A deep dive into Netlify Edge Functions Understanding Edge Functions: The Edge and Beyond Web-interoperable Runtimes Community Group -------------------This episode is sponsored by Cloud66, a platform that allows you to deploy Jamstack sites on any cloud for just $1.99 per site per month. It's like your own Netlify and includes free unlimited team members, real-time logs, programmable traffic management, SSL certificates, and more. You can get started with Cloud 66 for free and get an extra $66 of free credits with the code FSJam-66.
In episode 117 of Jamstack Radio, Brian is joined by Amanda Giannelli of Okta. This talk focuses on the full-stack web framework RedwoodJS, how it helped Amanda learn JavaScript, and her experience as a core team member and contributor. Other themes includes insights on getting started with open source and engaging with developer communities.
In this episode we discuss how to visualize state machines, building tools to collaborate around state machines, and using state machines on the server.David Khourshid Twitter Polywork LinkedIn Stately Homepage Twitter Discord LinksZag-------------------This episode is sponsored by Cloud66, a platform that allows you to deploy Jamstack sites on any cloud for just $1.99 per site per month. It's like your own Netlify and includes free unlimited team members, real-time logs, programmable traffic management, SSL certificates, and more. You can get started with Cloud 66 for free and get an extra $66 of free credits with the code FSJam-66.
In this episode we discuss how to distinguish a design system from a component library, strategies to become a better user of Storybook, and the long-awaited release of React 18.Michael Chan Homepage Twitter GitHub YouTube Egghead React Holiday Lunch.dev Storybook Homepage Twitter GitHub YouTube Discord Chromatic Twitter Homepage Links Storybook Play Function Component Story Format 3.0 Integrate Storybook in a Next.js Application Integrate Next.js and Storybook automatically Storybook Framework API Migrate a Client-Side Application to React 18 Beta How to Upgrade to React 18 React v18.0 React Labs: What We've Been Working On React Server Components with Next 13 -------------------This episode is sponsored by Cloud66, a platform that allows you to deploy Jamstack sites on any cloud for just $1.99 per site per month. It's like your own Netlify and includes free unlimited team members, real-time logs, programmable traffic management, SSL certificates, and more. You can get started with Cloud 66 for free and get an extra $66 of free credits with the code FSJam-66.
In this episode we discuss the evolution of platforms-as-a-service over the last decade, how to most effectively leverage a multi-cloud world, and the characteristics of a resilient hosting provider.Khash SajadiTwitterCloud 66 Homepage Twitter GitHub -------------------This episode is sponsored by Cloud66, a platform that allows you to deploy Jamstack sites on any cloud for just $1.99 per site per month. It's like your own Netlify and includes free unlimited team members, real-time logs, programmable traffic management, SSL certificates, and more. You can get started with Cloud 66 for free and get an extra $66 of free credits with the code FSJam-66.
In this episode we discuss how to compare open source frameworks, starter projects that help developers quickly begin building, and the potential of a post-React future. Tracy Lee Twitter LinkedIn GitHub Homepage Dustin Goodman Twitter LinkedIn GitHub Homepage This Dot Labs Homepage Twitter LinkedIn GitHub Links This Dot Open Source starter.dev GitHub Showcases framework.dev The Perfect Egg Recipe react.framework.dev starter.dev About npm blockchain.education Smart Contract Database TanStack -------------------This episode is sponsored by Cloud66, a platform that allows you to deploy Jamstack sites on any cloud for just $1.99 per site per month. It's like your own Netlify and includes free unlimited team members, real-time logs, programmable traffic management, SSL certificates, and more. You can get started with Cloud 66 for free and get an extra $66 of free credits with the code FSJam-66.
Originally published on July 19th, 2022. We are taking some time off from production. We will be back with new episodes on November 15th. In this episode, we talk to Tom Preston-Werner, creator of RedwoodJS, Jekyll, and cofounder of GitHub, about why he wanted to create RedwoodJS, how it benefits startups, and the future of investing in startups. Links https://twitter.com/mojombo https://redwoodjs.com https://redwoodjs.com/docs/tutorial/foreword 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! Tell us what you think of PodRocket We want to hear from you! We want to know what you love and hate about the podcast. What do you want to hear more about? Who do you want to see on the show? Our producers want to know, and if you talk with us, we'll send you a $25 gift card! If you're interested, schedule a call with us (https://podrocket.logrocket.com/contact-us) or you can email producer Kate Trahan at kate@logrocket.com (mailto:kate@logrocket.com). 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: Tom Preston-Werner.
In this episode we discuss the origins and motivations of React Bricks, the challenges of creating content with grey forms, and how to build a CMS that balances the needs of both developers and content creators.Matteo Frana Twitter GitHub React Bricks Homepage Twitter Discord Links Logo React Bricks Tutorial React Bricks Live Demo Neoskop Case Study Everfund Case Study Woosmap Case Study -------------------This episode is sponsored by Cloud66, a platform that allows you to deploy Jamstack sites on any cloud for just $1.99 per site per month. It's like your own Netlify and includes free unlimited team members, real-time logs, programmable traffic management, SSL certificates, and more. You can get started with Cloud 66 for free and get an extra $66 of free credits with the code FSJam-66.
We need your vote to win a Jam stack Jammie! So, go to https://fsjam.org/vote. There will also be previous guests in other categories, so make sure you vote for them too!-------------------In this episode we discuss the difficulties of running jobs on serverless, use cases for Netlify's Scheduled Functions, the future of Blitz.js, and the trade-offs inherent to remote work.Simon Knott Twitter GitHub Homepage Netlify's Scheduled Functions Scheduled Functions Documentation Netlify Acquisition FAQ Quirrel is Acquired! And I Am Joining Netlify Netlify Acquires Quirrel Quirrel Joins Netlify and Scheduled Functions Launches in Beta Scheduled Functions (Cron Jobs) With Netlify - Learn with Jason How to Schedule Deploys with Netlify Blitz.js 2.0 Flightcontrol with Brandon Bayer and Mina Abadir (FSJam68) Important Discussion On Possible Blitz.js Pivot - Brandon Bayer Future of Blitz.js Announcing Blitz.js 2.0 - Brandon Bayer Introduction to Blitz.js Toolkit - Simon Knott 2.0 Stable Launch - Brandon Bayer Announcing Blitz.js 2.0 Beta - Aleksandra Sikora Upgrading Your Blitz.js App to Blitz.js 2.0 Links Quirrel with Simon Knott (FSJam15) The Self Provisioning Runtime Schedule Netlify Builds with GitHub Actions - Lunchdev Schedule Netlify Builds with GitHub Actions, Cron, and Webhooks - Michael Chan tRPC Retool Editor's note: When I asked Simon about tRPC he gave his understanding of the history and motivation of the project at the time of this recording, which was almost six months ago. Despite not having been heavily involved with tRPC, his explanation was basically spot on.There was, however, one exceptional point which I'd like to clarify for the record and our listeners. Simon said Alex Johansson, the lead maintainer and driving force behind tRPC, was inspired to create tRPC by his experience as an early maintainer for Blitz.js. Simon prefaced this with the following:"Why I find tRPC so interesting, it's basically a lot of the ideas behind Blitz's zero-API data layer taken out from Blitz and I think (I'm not super sure about this) but I think Alex (who's the maintainer of tRPC) got the idea from Blitz. He was a maintainer of Blitz in the first couple of months and I think he then took the idea and decided to build something outside of Blitz."It's true Alex was an early contributor to Blitz.js and understood their philosophical alignment on a zero-API layer. The part that's missing however, is Alex didn't create tRPC. Colin McDonnell (creator of Zod and current head of DevRel at EdgeDB) created tRPC in July 2020. Originally called ZodRPC, Colin described it as "a toolkit for creating typesafe backends powered by Zod."Zod uses a kind of schema to broadly refer to any data type which can be declared with static types in TypeScript. With ZodRPC, Colin hoped to build a new library to extend the functionality of Zod and offer an alternative to GraphQL. The key to the project's success would be retaining the simplicity of RPC calls without losing type safety.According to Colin:"Most people use GraphQL as a massively over-engineered way to share the type signature of their API with your client. What if you could import that type signature directly into your client using plain ole import syntax? Well... you can."The project began as an experiment and after writing the initial proof of concept, Colin handed the project off to Alex Johansson. Alex has been maintaining the project ever since. I think the widespread belief that Alex did create tRPC is actually a testament to how much work he's put into building up the project and community.
We need your vote to win a Jam stack Jammie! So, go to https://fsjam.org/vote. There will also be previous guests in other categories, so make sure you vote for them too!-------------------In this episode we discuss the fundamentals of Eleventy, how to approach web development from a conservationist's point of view, and utilizing Eleventy Serverless for deferred, on-demand rendering.Ben Myers Homepage Twitter GitHub Twitch Some Antics showmy.chat Eleventy Homepage Twitter GitHub Discord Links Fullstack Accessibility with Ben Myers (FSJam31) Slinkity with Ben Holmes (FSJam49) Eleventy Data Cascade Documentation I Finally Understand Eleventy's Data Cascade events.lunch.dev Eleventy Serverless A First Look at Eleventy Serverless with Zach Leatherman (Some Antics) Modern CSS with Stephanie Eckles (FSJam63) Incremental Static Regeneration Distributed Persistent Rendering Understanding Rendering in the Jamstack by Brian Rinaldi Eleventy Glossary Learn Eleventy From Scratch by Andy Bell Amit Sheen Codepens THE Eleventy Meetup Full Time Open Source Development for Eleventy, Sponsored by Netlify Transcript[Pre-show Clip]BenWhen I was on Learn with Jason talking about Eleventy Serverless, I actually spent a fair amount of time talking about... "hey, Eleventy doesn't work for every use case." There are certain websites you have in mind that Eleventy would not be a good fit for. That's okay, that just means it's better suited for other kinds of sites. I think there is this instinct in Jamstack communities to try to kludge Jamstack into a fundamentally un-Jamstacky problem space.ChrisWhat do you mean? Gatsby is the best for everything and we should have never moved off Gatsby and there's no need for Svelte or Solid or anything like that. Gatsby, it did everything.[Opening Theme Song]AnthonyBen Myers, welcome back.BenHey! It's good to be back.AnthonyYou were on an earlier episode, 30-something, talking about web accessibility. You are a web developer and accessibility advocate at Microsoft. Today, we're going to be talking to you about Eleventy cause Eleventy is a project that I know you're really passionate about. We've had others on the show talk about it a little bit, especially Ben Holmes who is building a meta framework on top of Eleventy called Slinkity. But, today we're going to be talking about Eleventy proper. What it is, why people are excited about it, and what kind of stuff they're building with it. BenI'm thrilled, I absolutely love Eleventy as a tool and it's one of those things that's been an absolute privilege to get to introduce people to. Fair disclosure! I totally have not introduced people to it through a podcast medium, so this is gonna be very interesting. Super excited to chat about it with y'all.AnthonyWhy don't we first start with what Eleventy is. I think if anyone has heard about it, they know that it's a static site generator. They may have heard that it's based a bit on Jekyll, so if you can talk a little bit about what it does and what you would build with it.BenYeah, so I find that simply saying, "Jekyll but JavaScript" is enough for some people to just get it. I will say that the fact that it is powered by JavaScript makes it more approachable than other static site generators for many people because JavaScript is the language of the web. If you're doing front end development, JavaScript is something you're very likely to be very familiar with. A static site generator that leverages JavaScript, specifically the Node.js ecosystem, is a very compelling sell for a lot of people. But, I should definitely back up and explain the bigger picture.You described it as a static site generator in the vein of Jekyll. I think that's absolutely, absolutely fair. But personally, I don't have experience with Jekyll. That's not something that really helps me understand what it is. The simplest way to think of Eleventy is, it is a tool that will take content, typically in a format such as markdown. It'll take that content, it'll just convert it to some pure, raw, boring, fantastic HTML (or other assets). That is, I think, the simplest way to think of it. You've got some content, maybe it's blog posts, maybe it's documentation pages. Maybe it's a landing page for some product. Some content that is mostly static and you want some output, typically HTML.That is what Eleventy is and what it's really, really good at. What Eleventy isn't, is a tool for building highly dynamic interactive experiences. For those, you might still consider a client side web application framework such as React or Vue. Eleventy simply isn't as interested in addressing those kinds of websites and I think that's totally fair. But if you've got something that could be expressed in static HTML, Eleventy is possibly a very good project for you.AnthonyI actually first started learning about Eleventy for a big reason cause of you, Ben. We were building out the lunch.dev calendar with it. That was a really interesting project because we were trying to create like an events calendar. What we did is we had a Git repo that was building the static site and then we had markdown files for the individual events. Then the individual events would be transformed into little cards on the front end. If you wanna talk a little bit about why you picked Eleventy specifically for building that cause I think Chan also, the reason why we went with that was cause you were really passionate about, we wanted to learn more about it. So I'd be curious about the thought process behind that.BenAn event calendar like that is, if you think about it, nothing but a bunch of articles. At the time, we were not heavily invested in doing anything interactive with that calendar. We just needed a place to stick a bunch of descriptions and details of different events going on, different links that we could send people to. That is, again, something that is very well suited for that kind of static markup. When you think about a lot of web application frameworks, a common criticism that some folks in various web dev spaces will point to, is that web app frameworks can be quite large and bloated.That means if you are building your site with those, your end user very likely will have to download all of that and construct an experience from that. Whereas, you could get more or less the same experience but very, very lightweight. I think that lightweight websites are fundamentally good and responsible. I try to take a very conservation mindset to the web. I like to only use what I need and I apply this to users resources such as their data. If they're out and about on their mobile phone and they're using their data plan, chances are good that they could have a really slow connection and they could have data caps.I think that if we don't need to send them an entire web app framework, we probably shouldn't send them a web app framework. That is, I think, not being the best steward of their resources. They're gonna have a slower chunkier experience as a result. So, why did I choose Eleventy for this project? It's because the project, at least as we were thinking of it at the time, didn't need anything more than that. We just wanted some lightweight HTML pages out there on the web that could build quickly, that anyone could add to.Eleventy is really based around this concept of a template. A template is a content file written in a language such as Markdown or HTML and sometimes with templating languages such as Liquid or Nunjucks that Eleventy builds into a page or pages of HTML (or sometimes other static assets). It's weird because there always feels like there needs to be some asterisks. But broadly, think of a template as a content file that gets transformed into some output pages.The nice thing is Markdown for most developers is a fairly ergonomic experience. That meant that if people wanted to add things to that site, they didn't have to worry about the whole instrumentation and orchestration of the entire project. They could contribute simply a Markdown file and that was really nice. Eleventy also has built into it this concept called the data cascade which I think is one of the most crucial things to understand about Eleventy. It's also one of the things that took me the longest time to wrap my head around. When you're in a template, again a content file, you can use template syntax.Eleventy allows you the opportunity to expose variables essentially in that template syntax that you can either print out onto the page as part of the content or you can transform or operate on them in different ways. It's data, it's variables that you have access to. Eleventy has this amazing order of operations for how it lets you aggregate that data. So you can say, "oh, I've got some data that will be made available to every template of my site." Or, "I've got data that's available to every template that uses a certain layout." Or "I've got data that applies to every template in a given directory or its sub directories." Or, "I have data that corresponds exactly to one template."The lovely thing about this is, it exactly follows the mental model you would hope for something like that. It is powered by co-location. Data that applies much more specifically to an individual template will have a higher precedence over data that corresponds globally. This mental model (once you start playing with it) allows for some really, really powerful configuration of your website. You can almost afford to set it and then forget it which I think is incredibly powerful. You could set some sensible defaults at the global level, such as maybe "every blog post uses this blog post layout that I've defined."Then one blog post you could override that and use a different layout, maybe to accomplish some art direction. You've got a very special blog post that you want to have a special layout. You can change that data as you go. That kind of configuration (once you start wrapping your head around the order of operations) is incredibly powerful and flexible. At the same time, it's magic enough that you can bring new people into the project and they don't have to worry about any of it. I think that is super cool.AnthonySomething that was interesting that came up while we were working on it was, we ended up in a situation where we had to rebuild certain things at certain times. Because the way events work, there'll be an event upcoming then there'll be an event that has passed. You don't want to have stale events still on the homepage. We ended up setting up a cron job type thing with a GitHub Action.But I think that this is the type of thing that now, today if we had been building that there would be other ways to do that. Not even mentioning the new scheduled jobs functions that Netlify just added. But, what I was curious to get more into was the serverless bit. There is now Eleventy Serverless, and you've actually been on the forefront of this. You did a stream with Zach when this first came out and you've been building stuff out with it this whole time.We talked with Stephanie Eckles a little bit about it and I'm really curious to get your take on it cause we've talked about serverless a ton of times here at Redwood it was built on serverless. We love serverless - well I love serverless, I don't know if Chris loves serverless - but I'd love to hear what is Eleventy Serverless and why was it built?BenEleventy Serverless is an opt-in build mode for Eleventy. Typically with Eleventy, everything is pre-rendered. You have a build step, you run probably `npm run build` if we're being honest. Eleventy kicks in and picks up all your templates and then converts them into HTML files. Once they're built, they're built. If data changes behind the scenes, such as data that was fueled by an API, you don't get any updates to that because there's nothing in the HTML linking that data like real data in any sort of backend. It's just pure HTML.This meant that Eleventy has historically been very limited. Eleventy could only reflect what was true at build time. Eleventy Serverless is this new opt-in build mode for Eleventy, where you can say certain templates are built whenever you request them. Again, non-Eleventy people should probably read that as either "certain pages are built when you request them", or I prefer to think of it as "certain routes are built when you request them." I think that framing gets really, really powerful because you can use Eleventy's data cascade, you can use Eleventy's front matter and templating languages.All the stuff that you absolutely love about Eleventy, you can use but in this on-demand way, this on request way. You create a page as you request it and if you're using, for instance, Netlify's on-demand builders, you can then cache that page. It's as if you had built that page in the build step. This is hugely powerful for a couple of reasons. I use this demonstration when I go on people's streams to talk about Eleventy Serverless. It's a color contrast checker. Take two Hex codes and display in this pretty format, the color contrast ratio. If you have two Hex codes, which are six digits long each, then that is - I want to say 2.75 times 10 to the 14th contrast ratio.I don't wanna build that. I don't want my dev server building that. I don't want my Netlify high build minutes building that, that's incredibly wasteful. I love to defer building those kinds of things until they're needed, because chances are the vast majority of those contrast ratios will never see the light of day. Very few of the ratios on that site will ever be explored, so why build them? Eleventy Serverless is a great way to defer building a large data set that folks might not ever look at. You also don't have to cache by default. Eleventy Serverless built pages don't cache. You have to use specific things like on-demand builders to cache.But what that means is that you can have up to date data. During the on request build you can hit an API and you can get the latest, greatest up-to-datest data. I think that is incredibly powerful. That is something that we haven't really had in Eleventy before. But at the end of the day, what gets sent over the wire is still an incredibly lightweight HTML page. It's not a whole client side page that's holding in a large framework. You don't have to worry about things like loading spinners because all the fetching is done server-side. You don't have to worry about things like authentication because all the fetching is done server-side.You get to take advantage of everything that you love about serverless functions and everything that you love about Eleventy. I've also brought up a couple times that this is opt-in. I really love this because you aren't turning your whole site suddenly into a quote unquote "serverless site." You first opt-in by installing the serverless plugin and then you still have to opt-in on a template by template basis. The core of your website, the main pages that guaranteed people are gonna hit (like your landing page, about page, and stuff like that) are still built during the build step and are still totally cached.They're still available for search engines to crawl and all of that. It's just that this one subsection of your site is now served on-demand. I think that that is super exciting. Another benefit of Eleventy Serverless routes is that you can take advantage of arguments passed in the URL. You have parameters in the path, or you could have query parameters, for instance. This allows for some really dynamic experiences all. Anthony, you've alluded to, I've got this project that I built that is designed really to test what I believe is the absolute limit of Eleventy Serverless.This product is showmy.chat. Anyone who's been in the streaming biz will know that it's very common for Twitch streamers to use websites as part of their stream layout. A very common use case for this is showing your chat bot as part of your stream so that folks can see who's interacting with the stream. It's really exciting, "look at me, Mom, I'm famous. I'm on my favorite Twitch streamers stream." Doing anything like that requires some understanding of web development and WebSockets to be able to read from the chat. This is not something I feel like people should not have to worry about.So, I built this site, showmy.chat. It allows you to put in your channel name as well as set a couple of other properties, configure a couple of extra values there. It will generate using Eleventy Serverless a page that has all of the WebSocket logic, the action to display the chat, and all of the theming all set in place for you. You get this on-demand themed chat that responds to the arguments that you passed in through the query parameters. Do I think that Eleventy Serverless was the right tool for that job? I'm not entirely sure.I've actually been kind of considering maybe looking and seeing if I could have done the same thing, but maybe more flexibly using something like SvelteKit. But I think that it's incredibly exciting that Eleventy, which has been this kind of beloved pre-build tool now affords you this extra flexibility where just because you wanted a page that always had dynamic stuff or the latest information, you don't have to like opt into a completely different framework. Now, you can still say within the Eleventy ecosystem that you love.ChrisThat was a lot. I've literally just been sitting here just like absorbing it all in. I feel like a mega React, Chad, when I say, "Yeah, but you didn't say any of the buzzwords. SSG, ISR, SSR..."AnthonyI think DPR would be one of them technically, right? Distributed persistent rendering?ChrisYeah, haha.BenThe Venn diagram of all of these words is a very pretty butterfly and also inscrutable to anyone outside of the space. For folks at home who are playing buzzword bingo, it's Eleventy's implementation of distributed persistent rendering, or sometimes not distributed persistent rendering, Brian Rinaldi calls it deferred rendering. That's the term I like. It's deferred rendering. Everyone's got their own different take depending on whether they're a framework or whether they're a CDN. It's deferred rendering that's most similar to - I think Gatsby now has, I forget what they're calling it now.ChrisI think they're calling it deferred... incremental deferred rendering? Something like that.Ben MyersThis is exactly why I'm just using Brian's term of deferred rendering. If you're looking at this and going, "What's Eleventy's version of incremental static regeneration" or something like that, the closest thing is Eleventy Serverless. What is distributed persistent rendering? It's Eleventy Serverless hooked up to on-demand builders. That's what we're talking about. Hopefully that helps for people who are hoping to play buzzword bingo. The crux of it is you hit a route and Eleventy is run in the serverless function to create a page for you in basically real time.ChrisThe reason I say all the buzzwords is because sometimes they help define where it sits in the market, and sometimes they really do not. And this is where we talk about like functionality is obviously what really makes people understand what all these terms. Things like Next have this, Gatsby have this. For example, you build a website, let's say an e-commerce store, really easy and you add a new product. Does that product then just get rendered onto the website using like a webhook, or does that product only show if that specific URL is then entered? Because then Serverless knows to run and make that page?BenServerless is still in its infancy, but it would really depend on your implementation. I know Zach is still working on having serverless routes that have been created, but then saved can now get added to like what Eleventy calls collections (which are arrays of templates). You could be able to then display it on the rest of the site. Truthfully, I haven't done a whole lot with that. I think it would depend a lot on your implementation. It's in the moment the on request (your server function that's handling that) is looking for any arguments that you supply it in the URL. Either through the structure of the URL itself or through query parameters. You're probably passing in a SKU or some other identifier in there. It would look up some known database or API and be able to render that for you.ChrisThis is actually what I've personally seen with all these different types of rendering methods is that you chuck out the complete build, they add a new product and go, "it's not in the store." I'm like, "well it is on the store," if you know the URL, but you need to go to the URL for it to appear on the rest of the store. Cause that means the website now knows about it. It's like, how do you explain that to someone not technical? They need to know the URL to go to the right product to then appear on the rest of the website. It's like, "I thought this was meant to save millions and time on all these things." It's still a really complicated subject. One of the really big things that I wanted to ask is, what Serverless is sending down the pipe back to the client is not rehydrated JavaScript or JavaScript JSON, it's just HTML?BenYes. Just pure boring, lovely, fantastic, delightful HTML. Which means that it's gonna be fairly lightweight. Really, the way to think about this is, "this is how the web used to work and in many places still does." This is what we now call server rendering. Except you don't have to own a persistent server and you're very likely not doing anything with sustained sessions or anything like that. But the meat of, "I go talk to a server and I ask for a page and the server builds me that page on the fly," it's that, that's what's going on. I'm waving my hands doing jazz hands - imagine sparkles around this - it's now **Jamstack**! That's what it is. But it's bringing that kind of server functionality into a tool (into a framework, whatever you wanna call it) that previously has been prebuilt.You create a directory of HTML files and then that directory of HTML files is yours to do whatever you want with. You could FTP that into some server and just host that directly. You could FTP that into a CDN. Or you could do what I do, which is I have a Git based workflow hooked up to a CDN (in this case, Netlify). Every time I push to my repo, Netlify rebuilds but you don't have to have any of that instrumentation and orchestration. You could just upload some boring old HTML to a server and host that. This provides the same lightweight end user experience where you're getting just HTML. It's not HTML that we then rehydrate down the road and replace your entire page with this app behind the scenes that hopefully you won't notice. It's just HTML, it's lightweight, it's easy to cache.It's a little friendlier for search engines to optimize. When all you need is static HTML on a page and not a whole lot of dynamic interactive stuff, it's fantastic. It's glorious. I think the performance thing is an interesting conversation. I don't know if y'all know this. But right now we are in the middle of a pandemic and this means businesses have taken measures around this pandemic. There have been a small handful of times I have gone out to eat at a restaurant. On the tables, instead of giving me menus, there are table tents that have QR codes I can scan to pull up their menu. This, to me, is an example of a wonderful idea to meet user's needs that typically fails miserably in the execution.When I scan the QR code, it pulls up the restaurant's website and the restaurant has used some site builder or something else that sends over gobs and gobs of JavaScript. A whole framework likely or at the very least probably jQuery, sending over a whole lot of stuff. I don't know if y'all have this experience, but every restaurant I seem to go to seems to have poor internet connection there. I don't have great connection there; I don't have great reception. It takes me, like, 20 seconds where there's just this spinner and then I get to see a list of foods, which is mostly text. Sometimes there's pictures but the pictures are strictly optional. That feels to me like no one quite anticipated this pandemic (restaurants least of all) and rearchitecting your website is an expensive process that you can't just say, "oh, just remake your website with faster stuff."But we are several years into this now. Folks haven't looked at this and gone, "huh, those slow websites at our own restaurant to pull up our own menu, that's an area of opportunity for improvement there." Especially considering that when people are out and about, they're often in those kind of reception dead zones, such as a restaurant. They're operating off of finite data caps. They don't need gizmos and widgets and all sorts of interactive stuff. They just want to see what kind of food they can buy at your restaurant. There are times where having tools that make it really easy and flexible to just serve some boring, static HTML is exactly what your users need. Having that developer experience to make that easier is just gorgeous.ChrisYes, but I have two counterpoints.BenI'm ready to hear them.ChrisOne, "But JavaScript. I can write my CSS in JavaScript. I can write my HTML in JavaScript. I can just write JavaScript" and two, "Hey, you're a captive audience in a restaurant. Of course, they want you to sit there a little bit longer."BenWell, I mean, I think both of those arguments are very fair. But I think that too often we look at JavaScript as this great enabler and don't think of it as also a responsibility and a possible point of failure. Here's an example I sometimes use because I think documentation sites are a fantastic use case for Eleventy. I would like you to envision we're building a documentation site for some library we've made. As is the custom, we want to show how many GitHub stars this library. In the React ecosystem, it's fairly commonplace to set up a fetch to the GitHub API and display that. But what if the GitHub API is down? Well, I sure hope you set up some error boundaries and stuff like that.What if the GitHub API isn't down but it's really sluggish? Well, I certainly hope that you set up loading states. You have a lot of complexity around a part of the page that honestly no one cares about. You incur risk and you incur complexity over such a minor part of the page. I think that sometimes that stuff is incredibly valuable and stuff to consider and to consider how do we do this responsibly? Of course, yes, we could work around the foot guns. We could build a robust, resilient experience. But I think it's also interesting sometimes to ask, "how critical is this really?" Could we get away with having the result of how many stars our GitHub project has? Could we get away with having that be just hard coded texts in the built HTML that gets updated with a nightly built? Is that acceptable in some cases?No, it won't be, but in many cases it totally could be. You say, "oh, we've got JavaScript" and I say, "sure, but it might be more resilient in the backend." We don't have to worry about the costs and the risks and the complexity around doing all this stuff client side. As for a captive audience, I mean sure, but no one's gonna look at that and go, "ah yes, this restaurant was very fancy and stuff like that and I sure did feel very fancy waiting on my phone to pull up this menu in the middle of this steak restaurant going, 'it'll load, I promise. Do I need to refresh this another few times?'" It's all about different experiences and there is no one size solution that fits everything.ChrisYeah, I would've walked out the restaurant if the website was made in PHP. Just not for me. I don't care how rare you like your steak, this ain't for me! Um... no, all jokes aside, Eleventy Serverless looks really, really cool. I think one of the things that is really cool about it is, what it's spitting out is HTML. So many times when it comes to like, if you even think about Next's implementation or Gatsby, do I even know what it's spitting out? Kind of... to what I understand, it's just JSON. It spits out a massive JSON chunk that then gets stored in the HTML file that then gets rehydrated into the client. To what I understand! When you see those messages in Next.js saying, "Hey, your ISSG step is a bit too big," it's because you are literally dumping a massive JSON object into a script tag for Next.js to read later. If you didn't know.Ben MyersI don't want bash on those tools. I think there's absolutely a time and a place for them. But there's a time and a place for boring old HTML as well. And Eleventy... amazing.ChrisAnd I think what's the most amazing thing about all this is that we're still very early. It's still all very early. Even what Next.js is doing, who you could say have been doing SSG for the longest time. We're still so early when we talk about things like frameworks like Marko who have been in the industry for like 10 years. Everything is still so early in this area. The more capabilities that we have with less abstraction, I think the better. I think what's really interesting is what you just said about it's opt-in, not automatically there. It still works as expected, but if you want to add this, then you get it.So many times when it comes to things like say Next.js or Gatsby, I use next Next.js all day every day, so I don't mind bashing it. Do I even know how much JavaScript it sends to the client by default? Well, I hope it's not a lot. What we tend to forget is when I say about the question, "I know JavaScript, I could just write everything," is that I've made an abstraction line that is so high because it's all in JavaScript that so much performance can be potentially lost. You are technically compiling down CSS, HTML, JavaScript by default. What Eleventy is doing is just saying, "Look, you know HTML, you know CSS. Just send that down the wire and that is good enough for 80% of use cases like a blog or documentation."BenAnd now with Serverless, you compliment the sites that are already built with static. A fantastic example, and I wanna give a shout out to both Brian Robinson and Stephanie Eckles who have done this kind of stuff. You can have your blog and the meat of your blog is all built statically ahead of time during a pre-build step. Great, using serverless you could add a search bar to that site. Now your search pages are generated serverless based on your search query. But the meat of your website is still that static, cached, search engine friendly version of your site so it's all additive.ChrisThat's what makes it really good. So much of the ecosystem right now is taking, like, your Ford Rapture by default. You're not starting with the smallest car you possibly can. It's like, "we got the biggest engine to do the school trip in." It's not like, "let's start with a really small city car," it's like, "take everything and just use it."BenAbsolutely.AnthonyOne of the other things I wanted to get into is, I know that you've been working a lot on adding to the Eleventy documentation. You've written a ton of blog posts about Eleventy. I think for the most part, when people want to explain the data cascade to people, your blog post is kind of the canonical example that is usually linked to. I would be curious, when you were looking at the Eleventy docs, where did you see areas that you felt you could add value?BenOne pull request that actually got merged in not long ago was I defined a bunch of terms because I was looking around for a definition of, for instance, the word "template." The definition that I eventually ended up adding to the site was the one that I gave y'all. "A content file, typically in a language such as HTML and Markdown that gets processed by a template language and gets built as output." I had the opportunity to add that to the site because I actually couldn't find anything like that anywhere on the site. I think that the Eleventy documentation right now is fantastic at showing you the breadth of Eleventy's API.But a room for opportunity I see is, onboarding new people to Eleventy. As it stands, the getting started guide as you build a template and then run Eleventy to build a site using that template, and then it kind of just goes, "Tada! Welcome to Eleventy!" I would love to see more resources from the ecosystem, but especially more resources in the core Eleventy documentation around how to take that getting started guide and build a fully fledged application that you could host something pro on. So that's a room for growth, I think. I think that is going to require kind of some more explicit step-by-step walkthroughs.I think that's also going to require a bit more tying pieces together, like painting a bigger picture of that. Which is why, for instance, I wrote that data cascade post. Eleventy has some great pages about each step of the data cascade. But painting that as one big picture - with the sense of when should you use one step or method versus when should you use another step or method - that was something that I felt was missing. that's something that I'm hoping to contribute more and more. I think it's a bit of a slow process. You don't wanna boil the ocean. You don't want to contribute every update all at once. This is something that I'm doing in a bit of my free time just here and there. Maybe I'll add a page or I'll add to a page that already exists but provide a bit more of the context in (what I hope is) a beginner, newcomer, friendly way to help them really understand why does this fit into the bigger picture of an Eleventy project.This is a sentiment I've heard a couple times in the Eleventy space and I don't wanna bash on the Eleventy docs. I do think that they are great and again, they reflect the breadth of Eleventy's API. But this is something that, right now, there is a need for. People are writing blog posts and making videos that rise to that need. If you're listening to this and you, yourself do Eleventy (or if you're learning Eleventy) I would say right now the community needs you. The community could really benefit from you writing about your experiences and the things you learned. The real practical step by step process of how you built the thing that you've built whether that's on your own blog post or on your own YouTube channel or maybe it's in some way contributed to the documentation.I have no official affiliation with Eleventy, but this is something that I'm seeing more and more that folks should benefit from. That is the encouragement I would give. I think this is what we need to see. Eleventy just hit 1.0 recently and that marks it as a mature product. I would love to see us figure out more and more ways to bring people into the fold. I myself learned Eleventy through Andy Bell's course "Learn Eleventy from Scratch," which used to be a paid course. It's now open and free, but no longer being updated. I think more resources like that, which take you from the docs (which can sometimes be very API focused) to something that is instead methodological in its design. I think it's something that Eleventy could benefit from.AnthonyI would use the term explanatory.ChrisOne of the favorite things that I love, something you said earlier that I wish all frameworks said is as simply this. We can do everything, but we are not good at everything. You should use this for X and Y type of websites and if it's not X or Y, go look at something else. And you said documentation and blogs and homepages, that's what Eleventy is really good at. Don't go try build a dashboard in it.BenAbsolutely and it's like, it could be done and I think that there is value in experimenting. Using a thing far beyond what it was meant to do is something I see a lot with the CSS space. Amit Sheen's work is using CSS to create hyper realistic 3D animations. This is so far beyond the realm of what anyone ever intended of CSS. But we learned something as a community from pushing CSS to its limits. We learned techniques that we can use in the day to day. So it's not to say you can't build hyper interactive dashboards with Eleventy. You can certainly learn some things from that. But if you're trying to publish, if you're trying to deploy to production and you're trying to have a resilient app - those kinds of things - probably Eleventy isn't on the table for you and that's okay.But I've definitely had this moment where I'll be working someone individually through Eleventy to rebuild their blog. They'll be coming from like a React mindset. Suddenly I show them how they could create something that looks identical to their blog but as HTML. There's that moment that clicks where they've been using a tool that wasn't intended for the. Now, they have a tool that was actually meant for that kind of thing, and it unlocks something in them. That is, I think, a huge takeaway. There's no one size fits all, but that means that the one size that fits all that you're thinking of, isn't a one size fits all.ChrisVery true. Building blogs with Next and Gatsby, it's pretty overkill when you could just send sweet, sweet HTML.BenMm-hmm.AnthonyYeah. I was really happy that you were working on the docs cause I know I've struggled with the docs and I know others have as well. But as you said, just bashing the docs doesn't solve anything or make anyone feel good. Especially when Zach spent so much of his own, free time creating this project. When you see things like that, contribute back. Especially if you're someone who's in a position to help with things like documentation and explanation. That's really awesome, that's very much the spirit of open source, so I'm happy you did that.BenI think in general, people benefit from having multiple possible explanations for things. If Zach is the only person writing documentation, then everything is going to be oriented around how Zach understands things. Zach has a lot of great context into the inner workings of Eleventy, as well as the inner workings of the web. But Zach is not everyone. I'm not everyone. The two of y'all aren't everyone, right? Bringing more people to the table documentation wise, means we can get a better diversity of explanations that can work better for a wider diversity of people who are coming to this project. That is awesome.AnthonyIs there anything else about Eleventy you want to talk about before we wrap it?BenWe touched a bit on how it's HTML and I think that part itself is really huge. I feel like I've become a more robust developer as a result because I can't just rely on a component to do things for me. I have to think about, what is the best markup for this and what are the scripts that I have to write to make this work robustly? I've been very fortunate that Eleventy has improved me as a developer and I'm super, super excited to see how much the community is growing. It feels like it's exploded in popularity recently, I think in part to the Learn Eleventy from Scratch Course by Andy Bell and I think in part due to things like The Eleventy meetup that have been organized by Sia Karamalegos, Stephanie Eckles, and Thomas Semmler.There's a lot more community outreach and stuff like that. I'm just incredibly excited to see this project grow. It just received full-time open source funding from Netlify, which means Zach is now paid to work on Eleventy full time. Already we've seen some longstanding pull requests get merged in that have enabled different things. The more people we could get in on this project, the more cool things we can build. Absolutely dive into Eleventy. See what you can build and see what you can break. See how you can make something that you previously might have wanted a whole framework for. See if you can build something lightweight, robust, semantic, performant, and just see what a different way to build is.AnthonyYep. And if you hit any roadblocks, check out Slinkity.BenThere we go. Yes.AnthonyGo ahead and let our listeners know where they can find more about Eleventy or more about yourself.BenYeah, so if you want to learn about Eleventy, the documentation can be found at their website, which is 11ty.dev. Eleventy kind of has two spellings. It's a whole thing. I'm sure the link will be in the show notes. There's multiple links on there to find the documentation. Poke around, see if you can find the Easter eggs there because it's delightful. The documentation button is incredible. If you wanna find me out and about on the web, I'm on Twitter at BenDMyers. Again, I'm sure that link will be in the show notes. And I host a weekly Twitch show, which Anthony has been a part of four times now.I think he was the inaugural guest and he's still the person who's been on the most times. It's called Some Antics. Every week I bring on a guest from around the web development and web design industry to teach me something about building a great user experience for the web in a hands on way with a focus on accessibility and/or core web technologies. You can find that at twitch.tv/someanticsdev. That's S-O-M-E-A-N-T-I-C-S-D-E-V, someanticsdev. I look forward to hearing from y'all. I look forward to seeing what y'all build, what y'all make, what y'all are learning, what you're doing. My cat has just jumped off the bed in a clunky, noisy way.AnthonyTuna wants to be on the show.BenYes. I think that probably means he is done with this podcast as well.AnthonyThank you so much, Ben. It's always a pleasure getting to speak with you.BenLikewise!AnthonyWe appreciate your time and hope to have you back soon.BenSee y'all later.[Post-show Clip]ChrisI remember back in the Gatsby days when you'd have 10,000 pages. You're like, "I just wanna rebuild just that one page!"BenYep. Even Eleventy beat them to that punch.ChrisWow, I should learn more about Eleventy.BenIt's almost as though we need a podcast episode about it.AnthonyOkay, that's our pre-show clip. Perfect. Okay, let's do it. Ready?BenYes sir.
Anthony Campolo Twitter GitHub Blog Christopher Burns Twitter GitHub Everfund Links uidotdev - JavaScript Modules Everfund GitHub
https://codingcat.dev/podcast/2-40-RedwoodJS-with-tom-preston-werner The amazing Tom Preston-Werner joins us. Tom is building Preston Werner Ventures and RedwoodJS. Tom was also cofounder of GitHub, on the board of Chatterbug, Netlify, and Hack Club. --- Send in a voice message: https://anchor.fm/purrfect-dev/message Support this podcast: https://anchor.fm/purrfect-dev/support
In this episode we discuss the Jamstack Innovation Fund, open source sustainability, deciding whether to use Cloudflare Workers or Deno for Netlify's Edge Handlers, and the future of the Jamstack.Matt BiilmannTwitterNetlify Home Page Twitter Links Jamstack Innovation Fund Home Page Netlify Launches $10 Million Jamstack Innovation Fund Jamstack Innovation Fund Launches with the 10 Most Promising Jamstack Startups The Fund ChiselStrike - prototype-to-production data platform Clerk - authentication service purpose-built for Jamstack Clutch - visual editor for Jamstack solutions Convex - global state management platform Deno - modern runtime for JavaScript and TypeScript Everfund - developer-first nonprofit tool to build custom fundraising systems NuxtLabs - making web development intuitive with NuxtJS Snaplet - tool for copying Postgres databases TakeShape - GraphQL API mesh Tigris Data - zero-ops backend for web and mobile apps
In this episode, Amy talks through the details of Dev Operations and setting up a CI/CD (Continuous Integration and Continuous Deployment) pipeline on a recent project, using RedwoodJS, Husky, Postgres, Render, and GitHub Integrations.SponsorsZEALZEAL is a computer software agency that delivers “the world's most zealous” and custom solutions. The company plans and develops web and mobile applications that consistently help clients draw in customers, foster engagement, scale technologies, and ensure delivery.ZEAL believes that a business is “only as strong as” its team and cares about culture, values, a transparent process, leveling up, giving back, and providing excellent equipment. The company has staffers distributed throughout the United States, and as it continues to grow, ZEAL looks for collaborative, object-oriented, and organized individuals to apply for open roles.For more information visit codingzeal.comVercelVercel combines the best developer experience with an obsessive focus on end-user performance. Their platform enables frontend teams to do their best work. It is the best place to deploy any frontend app. Start by deploying with zero configuration to their global edge network. Scale dynamically to millions of pages without breaking a sweat.For more information, visit Vercel.comDatoCMSDatoCMS is a complete and performant headless CMS built to offer the best developer experience and user-friendliness in the market. It features a rich, CDN-powered GraphQL API (with realtime updates!), a super-flexible way to handle dynamic layouts and structured content, and best-in-class image/video support, with progressive/LQIP image loading out-of-the-box."For more information, visit datocms.comShow Notes00:00 Introduction03:40 Amy's Rant On Work Life Balance06:56 What is DevOps?08:11 James Alternative Definition of DevOps10:37 DevOps Workflows of the Past13:00 CI/CD Pipelines + Vercel14:17 Sponsor: Vercel15:24 Amy's Experience with Redwood.js16:35 Readme.so17:12 Project Environments and Setup With Docker21:32 Project Setup - Github Projects, Github Actions, Kent C. Dodds Testing Trophy, etc.30:47 Hosting With Render35:01 Database Best Practices with Shipping Code36:43 Sponsor: DatoCMS37:37 Deploy Previews with Render Based on Github PRs44:01 Deploy Redwood.js on Render (Documentation)45:11 Sponsor: ZEAL45:57 Heroku Github Integration Issues49:39 Grab Bag Questions Section50:08 Picks and Plugs52:52 James's Plug - Top 5 Struggles of a Developer Advocate53:44 Create a SvelteKit Blog With Markdown FilesMDsvex57:03 Amy's Plug - Hashnode57:44 Amy's Pick - Matthew McConaughey's book, Greenlights
In this episode we discuss what is a resumable framework and how resumability relates to partial hydration.Miško Hevery Twitter GitHub LinkedIn Qwik Home Page Twitter GitHub Links Builder.io Partytown
In this episode, we talk to Tom Preston-Werner, creator of RedwoodJS, Jekyll, and cofounder of GitHub, about why he wanted to create RedwoodJS, how it benefits startups, and the future of investing in startups. Links https://twitter.com/mojombo https://redwoodjs.com https://redwoodjs.com/docs/tutorial/foreword 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: Tom Preston-Werner.
In this episode we discuss strategies for navigating remote work, whether it's useful or counterproductive to push all computing to the edge, and how to build composable websites and applications.Ishan Anand Twitter LinkedIn GitHub Scott Steinlage Twitter LinkedIn Edgio Home Page Twitter LinksComposability Summit
In this episode we discuss the history and mission of Prisma, the boundary between Prisma Client and Prisma Migrate, and whether developers need to know the difference between SQL and NoSQL.Austin Crim Home Page Twitter GitHub LinkedIn Prisma Home Page Twitter GitHub Links Prisma Data Platform Deploying Prisma to Cloudflare Workers Remix with Kent C. Dodds
In this episode we discuss podcasting in person for the first time, why we are attending Remix Conf, and the crucial role of marketing in a startup.Scott Steinlage Twitter LinkedIn Limelight Will De Ath Twitter LinkedIn Everfund Links Remix Conf 2022 Remix Conf 2023
In this supper club episode of Syntax, Wes and Scott talk with Tom Pretson-Werner about his work on RedwoodJS, the importance of documentation, and the new Redwood Startup Fund. AIOSEO - Sponsor Our Sponsor for today's episode is a popular WordPress plugin, AIOSEO, also known as All in One SEO for WordPress. It's becoming one of the most powerful SEO toolkit and is now used by over 3 million websites to improve search rankings. Shipshape (Whiskey, Web and Whatnot) - Sponsor Whiskey Web and Whatnot is different than your typical dev podcast. We show a lighter, more human side of developers you know and love, like a fireside chat with your favorite devs. Past guests include Tom Preston-Werner, Kent C. Dodds, Charlie Gerard, and of course Wes Bos! We have discussed everything from Next.js and TypeScript to Chuck's past life as a blackjack dealer, Cincinnati Chili, the best casseroles, and of course whiskey! Show Notes 00:34 Welcome 01:36 Guest introduction Tom Preston-Werner on Twitter Kai's Power Tools 04:23 Math is weird 07:21 User interface design 08:53 Sponsor: AIOSEO 10:24 What is RedwoodJS? RedwoodJS Chatterbug 15:31 Is JavaScript the stack you should be using these days? 18:40 Freedom vs decisions in software Where Good Ideas Come From 23:10 RedwoodJS docs and video strategy RedwoodJS Docs Readme Driven Development 29:13 The tech behind RedwoodJS Apollo Storybook 36:20 Sponsor: Shipshape (Whiskey, Web and Whatnot) 36:58 Redwood Startup Fund The Redwood Startup Fund 42:28 Supper club questions VS Code Netlify Hacker News RedwoodJS on Discord RedwoodJS Discourse RedwoodJS on Twitter Shameless Plugs Scott: LevelUp Tutorials Wes: Wes Bos Tutorials Tweet us your tasty treats Scott's Instagram LevelUpTutorials Instagram Wes' Instagram Wes' Twitter Wes' Facebook Scott's Twitter Make sure to include @SyntaxFM in your tweets
In this episode we discuss leveraging serverless knowledge to launch your career, measuring the true cost of migrating a production application, and how serverless initiatives can spin out.Ryan Jones Twitter LinkedIn Serverless Guru Home Page Twitter Talking Serverless Links FSJam37 - Talking Serverless with Josh Proto Serverless: Zero to Paid Professional
Redwood is a fully integrated, end-to-end, production-ready, fully tested framework. We talk to Amanda Giannelli, Software Engineer at Auth0 and a member of the RedwoodJS core team, about Redwood V1 and more. Links https://twitter.com/giannellitech https://redwoodjs.com https://auth0.com https://community.redwoodjs.com https://tom.preston-werner.com/2022/04/04/redwood-v1-and-funding.html https://podrocket.logrocket.com/redwoodjs Review us Reviews are what help us grow and tailor our content to what you want to hear. Give us a review here (https://ratethispodcast.com/podrocket). Contact us https://podrocket.logrocket.com/contact-us @PodRocketpod (https://twitter.com/PodRocketpod) 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: Amanda Giannelli.
© 2020-2025 Ivy Podcast Discovery LLC
