POPULARITY
5 episodes with htmx
4 episodes with htmx
4 episodes with htmx
4 episodes with htmx
4 episodes with htmx
3 episodes with htmx
6 episodes with htmx
3 episodes with htmx
3 episodes with htmx
Via en fråga om vi borde stödja saker utan JavaScript snackar vi om att server-rendera, kämpande AI-modeller, HTMX evangelism, Container Queries, tips på att hoppa från ett berg och Fluid Typography. Dessutom en hel del om att inte lära sig nya saker, Therése nya karriär, tråkigt hantverk, whitelabeling och mycket mycket annat. Tipsa oss gärna om ämnen du vill höra! Antingen genom att ringa 0766 86 05 07 eller skriv till @asdfpodden på Instagram
Software Engineering Radio - The Podcast for Professional Software Developers
In this episode, SE Radio host Sriram Panyam explores HTMX with its creator, Carson Gross, who is also creator of Hyperscript, the mind behind the Grug Brained Developer, a professor of software engineering at Montana State University, and co-author of Hypermedia Systems. HTMX is a modern JavaScript library that allows developers to access AJAX, WebSockets, CSS Transitions, and Server-Sent Events directly in HTML using attributes. It represents a return to hypermedia-driven application architecture while supporting modern user experiences. The episode starts with a look at the current complexity in web development and how HTMX offers an alternative approach. Carson explains the core philosophy of "HTML as the interface" and how hypermedia principles influenced HTMX's design. From there, they dive into HTMX's technical concepts, including its attribute system, server-side integration, event handling, and state management approach. Carson shares some real-world implementation strategies, including migration paths from JavaScript frameworks, architectural patterns, and performance considerations -- as well as a few scenarios in which HTMX might not be the best fit. Finally, they look at the growing HTMX ecosystem, community contributions, and future development roadmap. Throughout the episode, Carson provides concrete examples and case studies of HTMX in production environments. Brought to you by IEEE Computer Society and IEEE Software magazine.
Fredrik snackar med Camilo Tapia om att gå från Node till Rust, via chocker över hur fula saker kan se ut och hur stor omställning det kan vara att slåss med en kompilator. Det strukturerar om ens hjärna! På ett bra sätt! Man inser hur mycket andra saker tar hand om åt en, och att det kan finnas ett värde i att hantera de sakerna själv i vissa sammanhang. Vi diskuterar också Nodes historia, hur lång tid det tog för Rust att klicka, om det skapas för många jättestora ramverk som vill lösa allt åt en just nu, och en hel del annat. Inspelat under Øredev 2024. Ett stort tack till Cloudnet som sponsrar vår VPS! Har du kommentarer, frågor eller tips? Vi är @kodsnack, @thieta, @krig, och @bjoreman på Mastodon, har en sida på Facebook och epostas på info@kodsnack.se om du vill skriva längre. Vi läser allt som skickas. Gillar du Kodsnack får du hemskt gärna recensera oss i iTunes! Du kan också stödja podden genom att ge oss en kaffe (eller två!) på Ko-fi, eller handla något i vår butik. Länkar Camilo Twofour - där Camilo jobbar Øredev Jsconf Rust How to switch from cozy Node.js to scary Rust as a company - Camilos presentation på Øredev 2024 Node Node släpptes först 2009 io.js - fork av Node som senare återförenades med originalprojektet Commonjs ESM Bun Deno Express Denos Youtubevideo V8 Rustlings låter dig lösa små kodproblem i Rust Stöd oss på Ko-fi! Zig Gleam Mojo Swift på servern Kotlin på servern WASM Leptos Solidjs JSX Angular Solidstart för Solidjs Islands Nextjs HTMX Jquery Primer - ungefär HTMX, från Facebook, 2010 Svelte Headless Go Foo café Titlar Nyttigt att skippa någonting Det nya sättet att tänka Tillräckligt bra för det mesta Sträva efter mer Bakom kulisserna på Node Ett komplement Inte någon återvändo För mycket på köpet
In this week's episode, it's just me — Charles Max Wood — and I'm joined by the incredibly sharp and open-source-loving Aral Roca, direct from Barcelona! Aral's the creator of Brisa, a new full-stack web framework that flips the script on how we build modern web apps. If you thought the "another day, another framework" meme was played out... well, Brisa might just change your mind.Key Takeaways:-Brisa's Big Idea: It's designed to let you build web apps with minimal or zero JavaScript on the client side. Think HTML streaming, server actions, and components that render server-side first, but can gradually hydrate on the client.-Server-first FTW: Aral walks us through how Brisa handles server actions — even capturing click and scroll events on the server — using ideas inspired by HTMX, LiveView, and server components from frameworks like Next.js.-Tiny and Mighty: The whole framework is incredibly lightweight. Web components come in at just ~3 KB, and the built-in i18n system is under 1 KB!-From Idea to Reality: Aral started Brisa to scratch his own itch — building side projects and blogs without bloated front-end code. But now, others are using it too (yes, even in production!), including one travel agency that's gone all-in.-Multi-platform Future: Brisa has adapters in the works for Vercel, Node, and Deno — plus integration with Tauri for building native Android, iOS, and desktop apps from the same codebase.-What's Coming: Roadmap goals include improved hot reloads, more adapters, transitions, lazy-loaded components, and a better playground for developers to tinker with.Oh, and yes — Aral does parkour. For real.This episode is packed with deep technical insight and exciting potential for a new way to build web apps — especially for devs who love fast performance, server-rendering, and clean architecture.Become a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.
Carson Gross, creator of HTMX, talks about its evolution from intercooler.js, its viral rise on social media, and its philosophy of simplicity and stability. They dive into how HTMX fits into the modern web dev ecosystem, the idea of building 100-year web services, and why older technologies like jQuery and server-side rendering still have staying power. Carson also shares insights on open-source marketing, progressive enhancement, and the future of web development. Links https://bigsky.software https://www.linkedin.com/in/1cg https://github.com/bigskysoftware https://x.com/htmx_org https://htmx.org https://htmx.org/discord https://hypermedia.systems https://github.com/surrealdb/surrealdb.js https://unpoly.com https://ui.shadcn.com We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understand where your users are struggling by trying it for free at [LogRocket.com]. Try LogRocket for free today.(https://logrocket.com/signup/?pdr) Special Guest: Carson Gross.
Live von der DjangoCon Europe 2025 in Dublin - Tag 3 (click here to comment) 25. April 2025, Jochen Wir melden uns wieder von der DjangoCon Europe 2025 aus der Hotellobby. Diesmal haben wir Sebastian dabei, der am ersten Tag einen Vortrag über die Feinheiten in den Django Release Notes gehalten hat, den wir leider nicht sehen konnten, weil wir da noch mit Podcastaufnehmen beschäftigt waren. Er kommt auch aus dem Rheinland und betreibt in Köln eine Agentur für Softwareentwicklung und Beratung.In dieser Episode diskutieren wir:
Live von der DjangoCon Europe 2025 in Dublin - Tag 2 (click here to comment) 24. April 2025, Jochen Wir melden uns erneut von der DjangoCon Europe und sprechen über die Highlights des zweiten Konferenztages – mit jeder Menge technischer Einblicke, spannenden Talks und persönlichen Eindrücken.Diesmal mit dabei: Ronny als Gast in unserer Runde!
Live von der DjangoCon Europe 2025 in Dublin - Tag 1 (click here to comment) 23. April 2025, Jochen In dieser Sonderausgabe melden wir uns live von der DjangoCon Europe in Dublin!
Scott and Wes break down the current state of React Server Components — what they are, how they work, and why they're so controversial. From framework support to bundling complexity, it's everything you need to know about RSC in 2025. Show Notes 00:00 Welcome to Syntax! 01:01 Brought to you by Sentry.io. 01:55 What exactly are React Server Components? 02:18 Server components rendering. 03:17 Server components are async. 03:45 Server components can be suspended. 05:05 Server components send RSC payloads to the browser. 06:08 This feels like HTMX? 06:54 Client components are still server rendered. 07:58 Server Functions. 08:52 useActionState. 09:12 Frameworks and React Platforms. 09:16 NextJS. 09:42 Waku. 12:26 candycode.com Daishi Kato 14:23 React Router. Michael Jackson Tweet. 19:29 Vite. vite-plugin-react-server 20:54 Tanstack. Syntax Ep 833. 22:39 Bun. 23:01 DIY. 23:39 Why so much hate? 25:28 I want it my way. 27:46 React Server Components lock-in. 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
In this episode of the JavaScript Master Podcast, we explore HTMX, a powerful tool that simplifies frontend development by reducing the need for complex JavaScript frameworks. Our guest, Damian Płaza, Senior Software Engineer, Application Architect, and Product Development Leader at Volue, shares his insights on how HTMX can enhance modern web applications.What's inside?✅ What is HTMX? A deep dive into its purpose and core concepts✅ How HTMX compares to modern JavaScript frameworks like React, Vue, and Angular✅ Hypermedia-driven applications – what does that mean in practice?✅ Performance benefits – does HTMX make web apps faster?✅ Reducing JavaScript complexity – how much JavaScript can you eliminate?✅ Common use cases – when is HTMX the best choice?✅ Limitations of HTMX – when might it not be the right tool?✅ HTMX & server-side technologies – how it integrates with PHP, Python, and Node.js✅ Handling dynamic data & DOM updates – does HTMX replace JavaScript completely?✅ Security considerations – how does HTMX handle XSS and CSRF protection?✅ HTMX event model – how it differs from traditional JavaScript event handling✅ How HTMX fits into modern web development – should you use it in your next project?✅ Real-world examples & success stories – companies and projects using HTMX today✅ The future of HTMX – what's on the roadmap?If you're curious about hypermedia-driven applications and looking for ways to simplify frontend development, this episode is packed with valuable insights!
Today we are talking about The Drupal Developer Survey, Last year's results, and How it helps Drupal with guest Mike Richardson. We'll also cover HTMX as our module of the week. For show notes visit: https://www.talkingDrupal.com/493 Topics What is the Drupal Developer Survey How often does it come out How did it come to be What type of information does it collect Do you look at other surveys What were some of the most interesting stats last year Core contributors How do you expect last year to compare to this year Do you think the outlook will be more positive with Drupal CMS Drop off in Drupal 7 Home users DDEV usage AI questions Security questions Resources Drupal Developer Survey 2024 Results 2025 Drupal Developer Survey HTMX Sucks Guests Mike Richardson - Ironstar Dev Survey richo_au Hosts Nic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Andrew Berry - lullabot.com deviantintegral MOTW Correspondent Martin Anderson-Clutz - mandclu.com mandclu Brief description: Have you ever wanted to replace Drupal's AJAX capabilities with a lightweight library that has no additional dependencies? There's a module for that. Module name/project name: HTMX Brief history How old: created in May 2023 by wouters_f though recent releases are by fathershawn of Memorial Sloan Kettering Cancer Center Versions available: 1.3.5 and 1.4.0, both of which support Drupal 10.3 and 11 Maintainership Actively maintained, latest release less than a month ago Security coverage Test coverage Documentation included in the repo as well as online Number of open issues: 3 open issues, 1 of which is a bug Usage stats: 92 sites Module features and usage To use HTMX, you need to attach the library to the render array of one or more elements where you want to use it, and then add data attributes to your render array that indicate how you want HTMX to react to user behaviour HTMX can help make your Drupal sites more interactive by dynamically loading or reloading parts of a page, giving it a more “application-like” user experience There is a planning issue to discuss gradually replace Drupal's current AJAX system with HTMX, and a related Proof Of Concept showing how that could work with an existing Drupal admin form A number of elements in the current AJAX system also rely on jQuery, so adopting HTMX would also help to phase out jQuery in core. HTMX is also significantly more lightweight than JS frameworks like React HTMX is really a developer-oriented project, which is why I thought it would be appropriate for this week's episode
This week I talk with Delaney Gillilan, the creator of Datastar, a framework that helps building web applications with the reactivity of a single page app but with the programming model of a good old server-rendered page from the backend. Datastar combines the power of HTMX and Alpine.js in a simple and lightweight way.Links:Datastar websiteThe best way to support the show at this time is by talking about the pod and if you can, purchase my courses, which are at 50% discount for listeners of the show: Build SaaS apps in Go and Build a Google Analytics in Go.
In this episode, Carson Gross joins Carter and Nathan to discuss his book Hypermedia Systems Join them as Carson reflects on the process of publishing the book, the development of HTMX, and how to deal with setbacks!-- Books Mentioned in this Episode --Note: As an Amazon Associate, we earn from qualifying purchases.----------------------------------------------------------Hypermedia Systemshttps://amzn.to/4iou43T (Paid Link)----------------Spotify: https://open.spotify.com/show/5kj6DLCEWR5nHShlSYJI5LApple Podcasts: https://podcasts.apple.com/us/podcast/book-overflow/id1745257325X: https://x.com/bookoverflowpodCarter on X: https://x.com/cartermorganNathan's Functionally Imperative: www.functionallyimperative.com----------------Book Overflow is a podcast for software engineers, by software engineers dedicated to improving our craft by reading the best technical books in the world. Join Carter Morgan and Nathan Toups as they read and discuss a new technical book each week!The full book schedule and links to every major podcast player can be found at https://www.bookoverflow.io
Scott and Wes answer your listener questions! They debate Axios vs. Fetch, discuss whether Next.js is overkill without a backend, talk htmx and Alpine, dive into tech career transitions, and tackle everything from podcast ads to password hashing myths. Show Notes 00:00 Welcome to Syntax! 00:55 Scott's health update. 04:11 Submit your questions. 04:26 Is Axios still worth using over Fetch? shiki. xior. ky. 10:17 Does Alpine.js solve HTMX's client-side limitations? Syntax Ep. 868: The State of JavaScript. Server Driven Web Apps With HTMX. Syntax Ep. 568: Supper Club × Caleb Porzio. Alpine.js. Inertia.js. 16:47 How should I host my database for a local-first app? Neon Tech 22:50 Brought to you by Sentry.io. 24:14 Should I use Next.js if I want a separate backend? Create Vite Extra. 32:08 Are ad networks like BuySellAds worth it for podcasts? 36:36 Can I transition from airline pilot to senior software developer? 41:23 Is Base64 encoding a valid alternative to password hashing? 45:43 How do I use unexported functions from a third-party package? 48:09 How do you stay on top of package and browser updates? Syntax Ep. 425: Updating Project Dependencies. npm-check-update. 52:38 Why are Chrome and Firefox's mobile presets outdated? 57:20 Should I give feedback on bad UX/UI designs from agencies? 01:01:53 Sick Picks + Shameless Plugs. Sick Picks Scott: Nothing Ear (a). Wes: SmallRig Phone Cage. Shameless Plugs Wes: Syntax on YouTube. 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
This week I'm joined by Peter Strøiman, the author of Gost, a Go headless browser that can be pretty useful when doing TDD and even (especially) if you're using HTMX. We talk about the challenges and the "why" Peter wanted to build this project, where it can be helpful and we dive into the internals a bit.Links:Gost on GitHubPeter's websiteAs always I'd appreciate if you can talk about the pod and if you can and want to support to cover cost the best way is to purchase my courses which are 50% off for listeners of the show: Build SaaS apps in Go and Build a Google Analytics in Go.
Bartek träffar Johan Kronberg och pratar om trevligare sätt att jobba med webb i ASP.NET än vad som kommer out of the box. Det pratas komponenter, HTMX och statiska sajtgeneratorerLänkarKrompaco.nukrompaco (Johan Kronberg) · GitHubThe .NET 9.0 static site toolkitGitHub - Tietoevry-Create/dotnet-opinionated-blazor: A .NET 9.0 web app sample using Blazor Static SSR and with htmx.org+hyperscript.org support.How to add HTTP headers to Blazor Components with RazorComponentResult | Khalid AbuhakmehIdea: Stateless Blazor components · Issue #54547 · dotnet/aspnetcoreGitHub - egil/Htmxor: Supercharges Blazor static server side rendering (SSR) by seamlessly integrating the Htmx.org frontend library.GitHub - yusukebe/hono-htmx: Hono+htmx stackHotwire vs HTMX vs Unpoly - Lucas MendelowskiRender Razor components outside of ASP.NET Core | Microsoft Learn
In this episode of Book Overflow, Carter and Nathan discuss the back half of Hypermedia Systems by Carson Gross, Adam Stepinski, and Deniz Akşimşek. Join them as they discuss the pros and cons of HTMX, whether or not you should choose it over a more popular framework like React, and more!-- Books Mentioned in this Episode --Note: As an Amazon Associate, we earn from qualifying purchases.----------------------------------------------------------Hypermedia Systems by Carson Gross, Adam Stepinski, and Deniz Akşimşekhttps://amzn.to/3C503GQ (https://amzn.to/4aDjFyD)----------------Spotify: https://open.spotify.com/show/5kj6DLCEWR5nHShlSYJI5LApple Podcasts: https://podcasts.apple.com/us/podcast/book-overflow/id1745257325X: https://x.com/bookoverflowpodCarter on X: https://x.com/cartermorganNathan's Functionally Imperative: www.functionallyimperative.com----------------Book Overflow is a podcast for software engineers, by software engineers dedicated to improving our craft by reading the best technical books in the world. Join Carter Morgan and Nathan Toups as they read and discuss a new technical book each week!The full book schedule and links to every major podcast player can be found at https://www.bookoverflow.io
Hi, Spring and HTML fans! Today I talk to hypermedia enjoyer Carson Gross, creator of the ever popular HTMX library which eschews a ton of the complexity associated with building client side applications.
In this episode of Book Overflow, Carter and Nathan discuss the first 200 pages of Hypermedia Systems by Carson Gross, Adam Stepinski, and Deniz Akşimşek. Join them as they discuss HTMX, an alternative to modern JavaScript front-end frameworks, and the philosophies that made Web 1.0 so powerful! -- Books Mentioned in this Episode -- Note: As an Amazon Associate, we earn from qualifying purchases. ---------------------------------------------------------- Hypermedia Systems by Carson Gross, Adam Stepinski, and Deniz Akşimşek https://amzn.to/3C503GQ (https://amzn.to/4aDjFyD) ---------------- Spotify: https://open.spotify.com/show/5kj6DLCEWR5nHShlSYJI5L Apple Podcasts: https://podcasts.apple.com/us/podcast/book-overflow/id1745257325 X: https://x.com/bookoverflowpod Carter on X: https://x.com/cartermorgan Nathan's Functionally Imperative: www.functionallyimperative.com ---------------- Book Overflow is a podcast for software engineers, by software engineers dedicated to improving our craft by reading the best technical books in the world. Join Carter Morgan and Nathan Toups as they read and discuss a new technical book each week! The full book schedule and links to every major podcast player can be found at https://www.bookoverflow.io
Guest Alexander Petros Panelist Richard Littauer Show Notes Join host Richard Littauer as he dives into the world of open source sustainability with Alexander Petros, core maintainer of htmx and freelance software engineer. Today, they explore the evolution of HTML, the power of lightweight web protocols, and the broader implications of open-source software for the future of the web. Alexander shares his insights on building sustainable digital infrastructure, using simple tools effectively, and rethinking web development paradigms. Hit download now! [00:01:40] Alexander explains htmx as a lightweight front-end JavaScript library enhancing HTML capabilities. [00:03:16] There's a discussion about HTML's design for behavior and interactivity and a comparison of traditional HTML with modern practices, including JavaScript-heavy frameworks. [00:05:50] We hear the origins of htmx, how it started as a jQuery extension called intercooler.js, and the evolution during the pandemic to a standalone library. [00:09:16] Alexander explains building for the long term, why lightweight, adaptable systems matter, and reflects on the durability of early web standards and tools. [00:12:17] Richard inquires about what Alexander envisions a hundred years from now with htmx. [00:14:57] Balancing simplicity and scalability is discussed about HTML's capabilities for large-scale applications and why many developers overcomplicate solutions unnecessarily. [00:17:40] Alexander critiques over-reliance on tools like Docker and large-scale build systems and advocates for simpler development environments like SQLite. [00:19:42] Alexander talks about why open source frameworks like React solve organizational problems for tech giants. [00:25:42] Richard tells us he's been spending time on the International Code of Zoological Nomenclature as a foundational system for species classification and Alexander speaks about the challenges of contributing to protocols governed by large corporations and why HTML remains a uniquely sustainable and universal platform. [00:28:22] Richard asks Alexander if he's thought about the 1000 year approach to the work he's doing. [00:32:21] Find out where you can follow Alexander and his blog online. Quotes [00:13:11] “The web is going to be the most effective delivery mechanism for software for the next couple of decades.” [00:14:12] “If we look at the tools that we have available today, which tools can we use that are most likely to get us to that fifty, hundred year useful piece of software?” [00:24:06] “Different structural project models produce very different software.” Spotlight [00:33:11] Richard's spotlight is the International Code of Zoological Nomenclature. [00:34:07] Alexander's spotlight is better-sqlite3. Links SustainOSS (https://sustainoss.org/) podcast@sustainoss.org (mailto:podcast@sustainoss.org) richard@sustainoss.org (mailto:richard@sustainoss.org) SustainOSS Discourse (https://discourse.sustainoss.org/) SustainOSS Mastodon (https://mastodon.social/tags/sustainoss) Open Collective-SustainOSS (Contribute) (https://opencollective.com/sustainoss) Richard Littauer Socials (https://www.burntfen.com/2023-05-30/socials) Alexander Petros Website (https://alexanderpetros.com/) Alexander Petros LinkedIn (https://www.linkedin.com/in/apetros/) Unplanned Obsolescence (Alexander's Blog) (https://unplannedobsolescence.com/) Building the Hundred-Year Web Service with htmx- Alexander Petros (YouTube) (https://www.youtube.com/watch?v=lASLZ9TgXyc) htmx (https://htmx.org/) Sustain Podcast-Episode 238: Julia Evans and Wizard Zines (https://podcast.sustainoss.org/238) xkcd-927: How Standards Proliferate (https://xkcd.com/927/) Julia Evans Blog (https://jvns.ca/) International Code of Zoological Nomenclature (ICZN) (https://www.iczn.org/) better-sqlite3 (https://github.com/WiseLibs/better-sqlite3) Credits Produced by Richard Littauer (https://www.burntfen.com/) Edited by Paul M. Bahr at Peachtree Sound (https://www.peachtreesound.com/) Show notes by DeAnn Bahr Peachtree Sound (https://www.peachtreesound.com/) Special Guest: Alexander Petros.
In this episode of The Frontend Masters Podcast, Todd Gardner, co-founder of TrackJS and RequestMetrics, discusses his journey from consultant to entrepreneur. He shares insights on bootstrapping SaaS products, competing against VC-backed companies, and the importance of charging customers for your product or service early. Todd delves into technical aspects of his products' stacks, including the use of .NET Core, Clickhouse, and HTMX. He offers advice on public speaking, teaching, and maintaining healthy co-founder relationships. The conversation covers web performance optimization, JavaScript error monitoring, and the challenges of balancing product development with marketing efforts. Todd also reflects on his career philosophy of continuous learning and adaptation in the fast-paced tech industry. Marc has captured his advice on startups in this article, originally an email to Todd in 2014: https://marcgrabanski.com/articles/your-advice-startups/ Check out Todd's Frontend Masters courses here: https://frontendmasters.com/teachers/todd-gardner/ Frontend Masters Online: Twitter: https://twitter.com/FrontendMasters LinkedIn: https://www.linkedin.com/company/frontend-masters/ Facebook: https://www.facebook.com/FrontendMasters Instagram: https://instagram.com/FrontendMasters About Us: Advance your skills with in-depth, modern front-end engineering courses — our 150+ high-quality courses and 18 curated learning paths will guide you from mid-level to senior developer! https://frontendmasters.com/?utm_source=spotify&utm_medium=home_link&utm_campaign=podcastepisode21
Talk Python To Me - Python conversations for passionate developers
Have you heard about HTMX? We've discussed it a time or two on this show. We're back with another episode on HTMX, this time with a real-world success story and lessons learned. We have Sheena O'Connell on to tell us how she moved from a React-Django app to pure Django with HTMX. Episode sponsors Posit Bluehost Talk Python Courses Links from the show Sheena O'Connell: sheenaoc.com An HTMX success story essay: sheenaoc.com Sheena's HTMX Workshop: prelude.tech - discount code: talk_python Talk Python's HTMX Courses HTMX + Flask course: training.talkpython.fm HTMX + Django course: training.talkpython.fm Build An Audio AI App course: training.talkpython.fm HTMX: htmx.org Playwright: playwright.dev django-template-partials: github.com Michael's jinja_partials: github.com django-guardian: github.com Talk Python Courses HTMX Example: training.talkpython.fm/courses/all Alpine.js: alpinejs.dev David Guillot SaaS video: youtube.com awesome-htmx: github.com Guild of Educators: guildofeducators.org The big rewrite song: youtube.com Watch this episode on YouTube: youtube.com Episode transcripts: talkpython.fm --- Stay in touch with us --- Subscribe to us on YouTube: youtube.com Follow Talk Python on Mastodon: talkpython Follow Michael on Mastodon: mkennedy
Anthony Alaribe, co-founder of API Toolkit, discusses the power of the browser for building data-heavy applications. He talks about myths around single-page apps versus multi-page apps, leveraging tools like HTMX and Workbox, and the significance of browser-native features for interactive web development. Links https://htmx.org https://tonyalaribe.medium.com https://x.com/tonialaribe https://github.com/tonyalaribe https://www.linkedin.com/in/anthony-alaribe-293a41bb We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understand where your users are struggling by trying it for free at [LogRocket.com]. Try LogRocket for free today.(https://logrocket.com/signup/?pdr) Special Guest: Anthony Alaribe.
Today we have a special guest. We have Jeremy Daly, who's been in the cloud space for a while. Jeremy is the co-founder of Ampt, which is building an abstraction infrastructure layer on top of AWS, just to make it simpler to sift through all the different options and develop on AWS and do best practices there. So we wanted to get his opinions on a lot of different infrastructure stuff that he's seeing and how AI is changing development. We even talk about some front end stuff at the end and HTMX and whether it's real, whether it's a troll. So lots of good stuff in this episode. Timestamps 01:56 Start 04:28 Jeremy's Background 07:26 Hard things about building ampt 11:59 Infrastructure from Code 17:07 App Runner 20:10 Comparing ampt and PaaS 27:22 Managing a lot of AWS accounts 30:46 Better than AWS 35:27 Thoughts on AWS deprecating services 47:11 Using AI 57:20 ChatGPT Adoption - Non Programmers 01:06:19 AI affecting the job market 01:18:37 HTMX Software Huddle ⤵︎ X: https://twitter.com/SoftwareHuddle Substack: https://softwarehuddle.substack.com/
Disclaimer: We recorded this episode ~1.5 months ago, timing for the FastHTML release. It then got bottlenecked by Llama3.1, Winds of AI Winter, and SAM2 episodes, so we're a little late. Since then FastHTML was released, swyx is building an app in it for AINews, and Anthropic has also released their prompt caching API. Remember when Dylan Patel of SemiAnalysis coined the GPU Rich vs GPU Poor war? (if not, see our pod with him). The idea was that if you're GPU poor you shouldn't waste your time trying to solve GPU rich problems (i.e. pre-training large models) and are better off working on fine-tuning, optimized inference, etc. Jeremy Howard (see our “End of Finetuning” episode to catchup on his background) and Eric Ries founded Answer.AI to do exactly that: “Practical AI R&D”, which is very in-line with the GPU poor needs. For example, one of their first releases was a system based on FSDP + QLoRA that let anyone train a 70B model on two NVIDIA 4090s. Since then, they have come out with a long list of super useful projects (in no particular order, and non-exhaustive):* FSDP QDoRA: this is just as memory efficient and scalable as FSDP/QLoRA, and critically is also as accurate for continued pre-training as full weight training.* Cold Compress: a KV cache compression toolkit that lets you scale sequence length without impacting speed.* colbert-small: state of the art retriever at only 33M params* JaColBERTv2.5: a new state-of-the-art retrievers on all Japanese benchmarks.* gpu.cpp: portable GPU compute for C++ with WebGPU.* Claudette: a better Anthropic API SDK. They also recently released FastHTML, a new way to create modern interactive web apps. Jeremy recently released a 1 hour “Getting started” tutorial on YouTube; while this isn't AI related per se, but it's close to home for any AI Engineer who are looking to iterate quickly on new products: In this episode we broke down 1) how they recruit 2) how they organize what to research 3) and how the community comes together. At the end, Jeremy gave us a sneak peek at something new that he's working on that he calls dialogue engineering: So I've created a new approach. It's not called prompt engineering. I'm creating a system for doing dialogue engineering. It's currently called AI magic. I'm doing most of my work in this system and it's making me much more productive than I was before I used it.He explains it a bit more ~44:53 in the pod, but we'll just have to wait for the public release to figure out exactly what he means.Timestamps* [00:00:00] Intro by Suno AI* [00:03:02] Continuous Pre-Training is Here* [00:06:07] Schedule-Free Optimizers and Learning Rate Schedules* [00:07:08] Governance and Structural Issues within OpenAI and Other AI Labs* [00:13:01] How Answer.ai works* [00:23:40] How to Recruit Productive Researchers* [00:27:45] Building a new BERT* [00:31:57] FSDP, QLoRA, and QDoRA: Innovations in Fine-Tuning Large Models* [00:36:36] Research and Development on Model Inference Optimization* [00:39:49] FastHTML for Web Application Development* [00:46:53] AI Magic & Dialogue Engineering* [00:52:19] AI wishlist & predictionsShow Notes* Jeremy Howard* Previously on Latent Space: The End of Finetuning, NeurIPS Startups* Answer.ai* Fast.ai* FastHTML* answerai-colbert-small-v1* gpu.cpp* Eric Ries* Aaron DeFazio* Yi Tai* Less Wright* Benjamin Warner* Benjamin Clavié* Jono Whitaker* Austin Huang* Eric Gilliam* Tim Dettmers* Colin Raffel* Sebastian Raschka* Carson Gross* Simon Willison* Sepp Hochreiter* Llama3.1 episode* Snowflake Arctic* Ranger Optimizer* Gemma.cpp* HTMX* UL2* BERT* DeBERTa* Efficient finetuning of Llama 3 with FSDP QDoRA* xLSTMTranscriptAlessio [00:00:00]: Hey everyone, welcome to the Latent Space podcast. This is Alessio, partner and CTO-in-Residence at Decibel Partners, and I'm joined by my co-host Swyx, founder of Smol AI.Swyx [00:00:14]: And today we're back with Jeremy Howard, I think your third appearance on Latent Space. Welcome.Jeremy [00:00:19]: Wait, third? Second?Swyx [00:00:21]: Well, I grabbed you at NeurIPS.Jeremy [00:00:23]: I see.Swyx [00:00:24]: Very fun, standing outside street episode.Jeremy [00:00:27]: I never heard that, by the way. You've got to send me a link. I've got to hear what it sounded like.Swyx [00:00:30]: Yeah. Yeah, it's a NeurIPS podcast.Alessio [00:00:32]: I think the two episodes are six hours, so there's plenty to listen, we'll make sure to send it over.Swyx [00:00:37]: Yeah, we're trying this thing where at the major ML conferences, we, you know, do a little audio tour of, give people a sense of what it's like. But the last time you were on, you declared the end of fine tuning. I hope that I sort of editorialized the title a little bit, and I know you were slightly uncomfortable with it, but you just own it anyway. I think you're very good at the hot takes. And we were just discussing in our pre-show that it's really happening, that the continued pre-training is really happening.Jeremy [00:01:02]: Yeah, absolutely. I think people are starting to understand that treating the three ULM FIT steps of like pre-training, you know, and then the kind of like what people now call instruction tuning, and then, I don't know if we've got a general term for this, DPO, RLHFE step, you know, or the task training, they're not actually as separate as we originally suggested they were in our paper, and when you treat it more as a continuum, and that you make sure that you have, you know, more of kind of the original data set incorporated into the later stages, and that, you know, we've also seen with LLAMA3, this idea that those later stages can be done for a lot longer. These are all of the things I was kind of trying to describe there. It wasn't the end of fine tuning, but more that we should treat it as a continuum, and we should have much higher expectations of how much you can do with an already trained model. You can really add a lot of behavior to it, you can change its behavior, you can do a lot. So a lot of our research has been around trying to figure out how to modify the model by a larger amount rather than starting from random weights, because I get very offended at the idea of starting from random weights.Swyx [00:02:14]: Yeah, I saw that in ICLR in Vienna, there was an outstanding paper about starting transformers from data-driven piers. I don't know if you saw that one, they called it sort of never trained from scratch, and I think it was kind of rebelling against like the sort of random initialization.Jeremy [00:02:28]: Yeah, I've, you know, that's been our kind of continuous message since we started Fast AI, is if you're training for random weights, you better have a really good reason, you know, because it seems so unlikely to me that nobody has ever trained on data that has any similarity whatsoever to the general class of data you're working with, and that's the only situation in which I think starting from random weights makes sense.Swyx [00:02:51]: The other trends since our last pod that I would point people to is I'm seeing a rise in multi-phase pre-training. So Snowflake released a large model called Snowflake Arctic, where they detailed three phases of training where they had like a different mixture of like, there was like 75% web in the first instance, and then they reduced the percentage of the web text by 10% each time and increased the amount of code in each phase. And I feel like multi-phase is being called out in papers more. I feel like it's always been a thing, like changing data mix is not something new, but calling it a distinct phase is new, and I wonder if there's something that you're seeingJeremy [00:03:32]: on your end. Well, so they're getting there, right? So the point at which they're doing proper continued pre-training is the point at which that becomes a continuum rather than a phase. So the only difference with what I was describing last time is to say like, oh, there's a function or whatever, which is happening every batch. It's not a huge difference. You know, I always used to get offended when people had learning rates that like jumped. And so one of the things I started doing early on in Fast.ai was to say to people like, no, you should actually have your learning rate schedule should be a function, not a list of numbers. So now I'm trying to give the same idea about training mix.Swyx [00:04:07]: There's been pretty public work from Meta on schedule-free optimizers. I don't know if you've been following Aaron DeFazio and what he's doing, just because you mentioned learning rate schedules, you know, what if you didn't have a schedule?Jeremy [00:04:18]: I don't care very much, honestly. I don't think that schedule-free optimizer is that exciting. It's fine. We've had non-scheduled optimizers for ages, like Less Wright, who's now at Meta, who was part of the Fast.ai community there, created something called the Ranger optimizer. I actually like having more hyperparameters. You know, as soon as you say schedule-free, then like, well, now I don't get to choose. And there isn't really a mathematically correct way of, like, I actually try to schedule more parameters rather than less. So like, I like scheduling my epsilon in my atom, for example. I schedule all the things. But then the other thing we always did with the Fast.ai library was make it so you don't have to set any schedules. So Fast.ai always supported, like, you didn't even have to pass a learning rate. Like, it would always just try to have good defaults and do the right thing. But to me, I like to have more parameters I can play with if I want to, but you don't have to.Alessio [00:05:08]: And then the more less technical side, I guess, of your issue, I guess, with the market was some of the large research labs taking all this innovation kind of behind closed doors and whether or not that's good, which it isn't. And now we could maybe make it more available to people. And then a month after we released the episode, there was the whole Sam Altman drama and like all the OpenAI governance issues. And maybe people started to think more, okay, what happens if some of these kind of labs, you know, start to break from within, so to speak? And the alignment of the humans is probably going to fall before the alignment of the models. So I'm curious, like, if you have any new thoughts and maybe we can also tie in some of the way that we've been building Answer as like a public benefit corp and some of those aspects.Jeremy [00:05:51]: Sure. So, yeah, I mean, it was kind of uncomfortable because two days before Altman got fired, I did a small public video interview in which I said, I'm quite sure that OpenAI's current governance structure can't continue and that it was definitely going to fall apart. And then it fell apart two days later and a bunch of people were like, what did you know, Jeremy?Alessio [00:06:13]: What did Jeremy see?Jeremy [00:06:15]: I didn't see anything. It's just obviously true. Yeah. So my friend Eric Ries and I spoke a lot before that about, you know, Eric's, I think probably most people would agree, the top expert in the world on startup and AI governance. And you know, we could both clearly see that this didn't make sense to have like a so-called non-profit where then there are people working at a company, a commercial company that's owned by or controlled nominally by the non-profit, where the people in the company are being given the equivalent of stock options, like everybody there was working there with expecting to make money largely from their equity. So the idea that then a board could exercise control by saying like, oh, we're worried about safety issues and so we're going to do something that decreases the profit of the company, when every stakeholder in the company, their remuneration pretty much is tied to their profit, it obviously couldn't work. So I mean, that was a huge oversight there by someone. I guess part of the problem is that the kind of people who work at non-profits and in this case the board, you know, who are kind of academics and, you know, people who are kind of true believers. I think it's hard for them to realize that 99.999% of the world is driven very heavily by money, especially huge amounts of money. So yeah, Eric and I had been talking for a long time before that about what could be done differently, because also companies are sociopathic by design and so the alignment problem as it relates to companies has not been solved. Like, companies become huge, they devour their founders, they devour their communities and they do things where even the CEOs, you know, often of big companies tell me like, I wish our company didn't do that thing. You know, I know that if I didn't do it, then I would just get fired and the board would put in somebody else and the board knows if they don't do it, then their shareholders can sue them because they're not maximizing profitability or whatever. So what Eric's spent a lot of time doing is trying to think about how do we make companies less sociopathic, you know, how to, or more, you know, maybe a better way to think of it is like, how do we make it so that the founders of companies can ensure that their companies continue to actually do the things they want them to do? You know, when we started a company, hey, we very explicitly decided we got to start a company, not a academic lab, not a nonprofit, you know, we created a Delaware Seacorp, you know, the most company kind of company. But when we did so, we told everybody, you know, including our first investors, which was you Alessio. They sound great. We are going to run this company on the basis of maximizing long-term value. And in fact, so when we did our second round, which was an angel round, we had everybody invest through a long-term SPV, which we set up where everybody had to agree to vote in line with long-term value principles. So like never enough just to say to people, okay, we're trying to create long-term value here for society as well as for ourselves and everybody's like, oh, yeah, yeah, I totally agree with that. But when it comes to like, okay, well, here's a specific decision we have to make, which will not maximize short-term value, people suddenly change their mind. So you know, it has to be written into the legal documents of everybody so that no question that that's the way the company has to be managed. So then you mentioned the PBC aspect, Public Benefit Corporation, which I never quite understood previously. And turns out it's incredibly simple, like it took, you know, like one paragraph added to our corporate documents to become a PBC. It was cheap, it was easy, but it's got this huge benefit, which is if you're not a public benefit corporation, then somebody can come along and offer to buy you with a stated description of like turning your company into the thing you most hate, right? And if they offer you more than the market value of your company and you don't accept it, then you are not necessarily meeting the kind of your fiduciary responsibilities. So the way like Eric always described it to me is like, if Philip Morris came along and said that you've got great technology for marketing cigarettes to children, so we're going to pivot your company to do that entirely, and we're going to pay you 50% more than the market value, you're going to have to say yes. If you have a PBC, then you are more than welcome to say no, if that offer is not in line with your stated public benefit. So our stated public benefit is to maximize the benefit to society through using AI. So given that more children smoking doesn't do that, then we can say like, no, we're not selling to you.Alessio [00:11:01]: I was looking back at some of our emails. You sent me an email on November 13th about talking and then on the 14th, I sent you an email working together to free AI was the subject line. And then that was kind of the start of the C round. And then two days later, someone got fired. So you know, you were having these thoughts even before we had like a public example of like why some of the current structures didn't work. So yeah, you were very ahead of the curve, so to speak. You know, people can read your awesome introduction blog and answer and the idea of having a R&D lab versus our lab and then a D lab somewhere else. I think to me, the most interesting thing has been hiring and some of the awesome people that you've been bringing on that maybe don't fit the central casting of Silicon Valley, so to speak. Like sometimes I got it like playing baseball cards, you know, people are like, oh, what teams was this person on, where did they work versus focusing on ability. So I would love for you to give a shout out to some of the awesome folks that you have on the team.Jeremy [00:11:58]: So, you know, there's like a graphic going around describing like the people at XAI, you know, Elon Musk thing. And like they are all connected to like multiple of Stanford, Meta, DeepMind, OpenAI, Berkeley, Oxford. Look, these are all great institutions and they have good people. And I'm definitely not at all against that, but damn, there's so many other people. And one of the things I found really interesting is almost any time I see something which I think like this is really high quality work and it's something I don't think would have been built if that person hadn't built the thing right now, I nearly always reach out to them and ask to chat. And I tend to dig in to find out like, okay, you know, why did you do that thing? Everybody else has done this other thing, your thing's much better, but it's not what other people are working on. And like 80% of the time, I find out the person has a really unusual background. So like often they'll have like, either they like came from poverty and didn't get an opportunity to go to a good school or had dyslexia and, you know, got kicked out of school in year 11, or they had a health issue that meant they couldn't go to university or something happened in their past and they ended up out of the mainstream. And then they kind of succeeded anyway. Those are the people that throughout my career, I've tended to kind of accidentally hire more of, but it's not exactly accidentally. It's like when I see somebody who's done, two people who have done extremely well, one of them did extremely well in exactly the normal way from the background entirely pointing in that direction and they achieved all the hurdles to get there. And like, okay, that's quite impressive, you know, but another person who did just as well, despite lots of constraints and doing things in really unusual ways and came up with different approaches. That's normally the person I'm likely to find useful to work with because they're often like risk-takers, they're often creative, they're often extremely tenacious, they're often very open-minded. So that's the kind of folks I tend to find myself hiring. So now at Answer.ai, it's a group of people that are strong enough that nearly every one of them has independently come to me in the past few weeks and told me that they have imposter syndrome and they're not convinced that they're good enough to be here. And I kind of heard it at the point where I was like, okay, I don't think it's possible that all of you are so far behind your peers that you shouldn't get to be here. But I think part of the problem is as an R&D lab, the great developers look at the great researchers and they're like, wow, these big-brained, crazy research people with all their math and s**t, they're too cool for me, oh my God. And then the researchers look at the developers and they're like, oh, they're killing it, making all this stuff with all these people using it and talking on Twitter about how great it is. I think they're both a bit intimidated by each other, you know. And so I have to kind of remind them like, okay, there are lots of things in this world where you suck compared to lots of other people in this company, but also vice versa, you know, for all things. And the reason you came here is because you wanted to learn about those other things from those other people and have an opportunity to like bring them all together into a single unit. You know, it's not reasonable to expect you're going to be better at everything than everybody else. I guess the other part of it is for nearly all of the people in the company, to be honest, they have nearly always been better than everybody else at nearly everything they're doing nearly everywhere they've been. So it's kind of weird to be in this situation now where it's like, gee, I can clearly see that I suck at this thing that I'm meant to be able to do compared to these other people where I'm like the worst in the company at this thing for some things. So I think that's a healthy place to be, you know, as long as you keep reminding each other about that's actually why we're here. And like, it's all a bit of an experiment, like we don't have any managers. We don't have any hierarchy from that point of view. So for example, I'm not a manager, which means I don't get to tell people what to do or how to do it or when to do it. Yeah, it's been a bit of an experiment to see how that would work out. And it's been great. So for instance, Ben Clavier, who you might have come across, he's the author of Ragatouille, he's the author of Rerankers, super strong information retrieval guy. And a few weeks ago, you know, this additional channel appeared on Discord, on our private Discord called Bert24. And these people started appearing, as in our collab sections, we have a collab section for like collaborating with outsiders. And these people started appearing, there are all these names that I recognize, like Bert24, and they're all talking about like the next generation of Bert. And I start following along, it's like, okay, Ben decided that I think, quite rightly, we need a new Bert. Because everybody, like so many people are still using Bert, and it's still the best at so many things, but it actually doesn't take advantage of lots of best practices. And so he just went out and found basically everybody who's created better Berts in the last four or five years, brought them all together, suddenly there's this huge collaboration going on. So yeah, I didn't tell him to do that. He didn't ask my permission to do that. And then, like, Benjamin Warner dived in, and he's like, oh, I created a whole transformers from scratch implementation designed to be maximally hackable. He originally did it largely as a teaching exercise to show other people, but he was like, I could, you know, use that to create a really hackable BERT implementation. In fact, he didn't say that. He said, I just did do that, you know, and I created a repo, and then everybody's like starts using it. They're like, oh my god, this is amazing. I can now implement all these other BERT things. And it's not just answer AI guys there, you know, there's lots of folks, you know, who have like contributed new data set mixes and blah, blah, blah. So, I mean, I can help in the same way that other people can help. So like, then Ben Clavier reached out to me at one point and said, can you help me, like, what have you learned over time about how to manage intimidatingly capable and large groups of people who you're nominally meant to be leading? And so, you know, I like to try to help, but I don't direct. Another great example was Kerem, who, after our FSTP QLORA work, decided quite correctly that it didn't really make sense to use LoRa in today's world. You want to use the normalized version, which is called Dora. Like two or three weeks after we did FSTP QLORA, he just popped up and said, okay, I've just converted the whole thing to Dora, and I've also created these VLLM extensions, and I've got all these benchmarks, and, you know, now I've got training of quantized models with adapters that are as fast as LoRa, and as actually better than, weirdly, fine tuning. Just like, okay, that's great, you know. And yeah, so the things we've done to try to help make these things happen as well is we don't have any required meetings, you know, but we do have a meeting for each pair of major time zones that everybody's invited to, and, you know, people see their colleagues doing stuff that looks really cool and say, like, oh, how can I help, you know, or how can I learn or whatever. So another example is Austin, who, you know, amazing background. He ran AI at Fidelity, he ran AI at Pfizer, he ran browsing and retrieval for Google's DeepMind stuff, created Jemma.cpp, and he's been working on a new system to make it easier to do web GPU programming, because, again, he quite correctly identified, yeah, so I said to him, like, okay, I want to learn about that. Not an area that I have much expertise in, so, you know, he's going to show me what he's working on and teach me a bit about it, and hopefully I can help contribute. I think one of the key things that's happened in all of these is everybody understands what Eric Gilliam, who wrote the second blog post in our series, the R&D historian, describes as a large yard with narrow fences. Everybody has total flexibility to do what they want. We all understand kind of roughly why we're here, you know, we agree with the premises around, like, everything's too expensive, everything's too complicated, people are building too many vanity foundation models rather than taking better advantage of fine-tuning, like, there's this kind of general, like, sense of we're all on the same wavelength about, you know, all the ways in which current research is fucked up, and, you know, all the ways in which we're worried about centralization. We all care a lot about not just research for the point of citations, but research that actually wouldn't have happened otherwise, and actually is going to lead to real-world outcomes. And so, yeah, with this kind of, like, shared vision, people understand, like, you know, so when I say, like, oh, well, you know, tell me, Ben, about BERT 24, what's that about? And he's like, you know, like, oh, well, you know, you can see from an accessibility point of view, or you can see from a kind of a actual practical impact point of view, there's far too much focus on decoder-only models, and, you know, like, BERT's used in all of these different places and industry, and so I can see, like, in terms of our basic principles, what we're trying to achieve, this seems like something important. And so I think that's, like, a really helpful that we have that kind of shared perspective, you know?Alessio [00:21:14]: Yeah. And before we maybe talk about some of the specific research, when you're, like, reaching out to people, interviewing them, what are some of the traits, like, how do these things come out, you know, usually? Is it working on side projects that you, you know, you're already familiar with? Is there anything, like, in the interview process that, like, helps you screen for people that are less pragmatic and more research-driven versus some of these folks that are just gonna do it, you know? They're not waiting for, like, the perfect process.Jeremy [00:21:40]: Everybody who comes through the recruiting is interviewed by everybody in the company. You know, our goal is 12 people, so it's not an unreasonable amount. So the other thing to say is everybody so far who's come into the recruiting pipeline, everybody bar one, has been hired. So which is to say our original curation has been good. And that's actually pretty easy, because nearly everybody who's come in through the recruiting pipeline are people I know pretty well. So Jono Whitaker and I, you know, he worked on the stable diffusion course we did. He's outrageously creative and talented, and he's super, like, enthusiastic tinkerer, just likes making things. Benjamin was one of the strongest parts of the fast.ai community, which is now the alumni. It's, like, hundreds of thousands of people. And you know, again, like, they're not people who a normal interview process would pick up, right? So Benjamin doesn't have any qualifications in math or computer science. Jono was living in Zimbabwe, you know, he was working on, like, helping some African startups, you know, but not FAANG kind of credentials. But yeah, I mean, when you actually see people doing real work and they stand out above, you know, we've got lots of Stanford graduates and open AI people and whatever in our alumni community as well. You know, when you stand out above all of those people anyway, obviously you've got something going for you. You know, Austin, him and I worked together on the masks study we did in the proceeding at the National Academy of Science. You know, we had worked together, and again, that was a group of, like, basically the 18 or 19 top experts in the world on public health and epidemiology and research design and so forth. And Austin, you know, one of the strongest people in that collaboration. So yeah, you know, like, I've been lucky enough to have had opportunities to work with some people who are great and, you know, I'm a very open-minded person, so I kind of am always happy to try working with pretty much anybody and some people stand out. You know, there have been some exceptions, people I haven't previously known, like Ben Clavier, actually, I didn't know before. But you know, with him, you just read his code, and I'm like, oh, that's really well-written code. And like, it's not written exactly the same way as everybody else's code, and it's not written to do exactly the same thing as everybody else's code. So yeah, and then when I chatted to him, it's just like, I don't know, I felt like we'd known each other for years, like we just were on the same wavelength, but I could pretty much tell that was going to happen just by reading his code. I think you express a lot in the code you choose to write and how you choose to write it, I guess. You know, or another example, a guy named Vic, who was previously the CEO of DataQuest, and like, in that case, you know, he's created a really successful startup. He won the first, basically, Kaggle NLP competition, which was automatic essay grading. He's got the current state-of-the-art OCR system, Surya. Again, he's just a guy who obviously just builds stuff, you know, he doesn't ask for permission, he doesn't need any, like, external resources. Actually, Karim's another great example of this, I mean, I already knew Karim very well because he was my best ever master's student, but it wasn't a surprise to me then when he then went off to create the world's state-of-the-art language model in Turkish on his own, in his spare time, with no budget, from scratch. This is not fine-tuning or whatever, he, like, went back to Common Crawl and did everything. Yeah, it's kind of, I don't know what I'd describe that process as, but it's not at all based on credentials.Swyx [00:25:17]: Assemble based on talent, yeah. We wanted to dive in a little bit more on, you know, turning from the people side of things into the technical bets that you're making. Just a little bit more on Bert. I was actually, we just did an interview with Yi Tay from Reka, I don't know if you're familiar with his work, but also another encoder-decoder bet, and one of his arguments was actually people kind of over-index on the decoder-only GPT-3 type paradigm. I wonder if you have thoughts there that is maybe non-consensus as well. Yeah, no, absolutely.Jeremy [00:25:45]: So I think it's a great example. So one of the people we're collaborating with a little bit with BERT24 is Colin Raffle, who is the guy behind, yeah, most of that stuff, you know, between that and UL2, there's a lot of really interesting work. And so one of the things I've been encouraging the BERT group to do, Colin has as well, is to consider using a T5 pre-trained encoder backbone as a thing you fine-tune, which I think would be really cool. You know, Colin was also saying actually just use encoder-decoder as your Bert, you know, why don't you like use that as a baseline, which I also think is a good idea. Yeah, look.Swyx [00:26:25]: What technical arguments are people under-weighting?Jeremy [00:26:27]: I mean, Colin would be able to describe this much better than I can, but I'll give my slightly non-expert attempt. Look, I mean, think about like diffusion models, right? Like in stable diffusion, like we use things like UNet. You have this kind of downward path and then in the upward path you have the cross connections, which it's not a tension, but it's like a similar idea, right? You're inputting the original encoding path into your decoding path. It's critical to make it work, right? Because otherwise in the decoding part, the model has to do so much kind of from scratch. So like if you're doing translation, like that's a classic kind of encoder-decoder example. If it's decoder only, you never get the opportunity to find the right, you know, feature engineering, the right feature encoding for the original sentence. And it kind of means then on every token that you generate, you have to recreate the whole thing, you know? So if you have an encoder, it's basically saying like, okay, this is your opportunity model to create a really useful feature representation for your input information. So I think there's really strong arguments for encoder-decoder models anywhere that there is this kind of like context or source thing. And then why encoder only? Well, because so much of the time what we actually care about is a classification, you know? It's like an output. It's like generating an arbitrary length sequence of tokens. So anytime you're not generating an arbitrary length sequence of tokens, decoder models don't seem to make much sense. Now the interesting thing is, you see on like Kaggle competitions, that decoder models still are at least competitive with things like Deberta v3. They have to be way bigger to be competitive with things like Deberta v3. And the only reason they are competitive is because people have put a lot more time and money and effort into training the decoder only ones, you know? There isn't a recent Deberta. There isn't a recent Bert. Yeah, it's a whole part of the world that people have slept on a little bit. And this is just what happens. This is how trends happen rather than like, to me, everybody should be like, oh, let's look at the thing that has shown signs of being useful in the past, but nobody really followed up with properly. That's the more interesting path, you know, where people tend to be like, oh, I need to get citations. So what's everybody else doing? Can I make it 0.1% better, you know, or 0.1% faster? That's what everybody tends to do. Yeah. So I think it's like, Itay's work commercially now is interesting because here's like a whole, here's a whole model that's been trained in a different way. So there's probably a whole lot of tasks it's probably better at than GPT and Gemini and Claude. So that should be a good commercial opportunity for them if they can figure out what those tasks are.Swyx [00:29:07]: Well, if rumors are to be believed, and he didn't comment on this, but, you know, Snowflake may figure out the commercialization for them. So we'll see.Jeremy [00:29:14]: Good.Alessio [00:29:16]: Let's talk about FSDP, Qlora, Qdora, and all of that awesome stuff. One of the things we talked about last time, some of these models are meant to run on systems that nobody can really own, no single person. And then you were like, well, what if you could fine tune a 70B model on like a 4090? And I was like, no, that sounds great, Jeremy, but like, can we actually do it? And then obviously you all figured it out. Can you maybe tell us some of the worst stories behind that, like the idea behind FSDP, which is kind of taking sharded data, parallel computation, and then Qlora, which is do not touch all the weights, just go quantize some of the model, and then within the quantized model only do certain layers instead of doing everything.Jeremy [00:29:57]: Well, do the adapters. Yeah.Alessio [00:29:59]: Yeah. Yeah. Do the adapters. Yeah. I will leave the floor to you. I think before you published it, nobody thought this was like a short term thing that we're just going to have. And now it's like, oh, obviously you can do it, but it's not that easy.Jeremy [00:30:12]: Yeah. I mean, to be honest, it was extremely unpleasant work to do. It's like not at all enjoyable. I kind of did version 0.1 of it myself before we had launched the company, or at least the kind of like the pieces. They're all pieces that are difficult to work with, right? So for the quantization, you know, I chatted to Tim Detmers quite a bit and, you know, he very much encouraged me by saying like, yeah, it's possible. He actually thought it'd be easy. It probably would be easy for him, but I'm not Tim Detmers. And, you know, so he wrote bits and bytes, which is his quantization library. You know, he wrote that for a paper. He didn't write that to be production like code. It's now like everybody's using it, at least the CUDA bits. So like, it's not particularly well structured. There's lots of code paths that never get used. There's multiple versions of the same thing. You have to try to figure it out. So trying to get my head around that was hard. And you know, because the interesting bits are all written in CUDA, it's hard to like to step through it and see what's happening. And then, you know, FSTP is this very complicated library and PyTorch, which not particularly well documented. So the only really, really way to understand it properly is again, just read the code and step through the code. And then like bits and bytes doesn't really work in practice unless it's used with PEF, the HuggingFace library and PEF doesn't really work in practice unless you use it with other things. And there's a lot of coupling in the HuggingFace ecosystem where like none of it works separately. You have to use it all together, which I don't love. So yeah, trying to just get a minimal example that I can play with was really hard. And so I ended up having to rewrite a lot of it myself to kind of create this like minimal script. One thing that helped a lot was Medec had this LlamaRecipes repo that came out just a little bit before I started working on that. And like they had a kind of role model example of like, here's how to train FSTP, LoRa, didn't work with QLoRa on Llama. A lot of the stuff I discovered, the interesting stuff would be put together by Les Wright, who's, he was actually the guy in the Fast.ai community I mentioned who created the Ranger Optimizer. So he's doing a lot of great stuff at Meta now. So yeah, I kind of, that helped get some minimum stuff going and then it was great once Benjamin and Jono joined full time. And so we basically hacked at that together and then Kerim joined like a month later or something. And it was like, gee, it was just a lot of like fiddly detailed engineering on like barely documented bits of obscure internals. So my focus was to see if it kind of could work and I kind of got a bit of a proof of concept working and then the rest of the guys actually did all the work to make it work properly. And, you know, every time we thought we had something, you know, we needed to have good benchmarks, right? So we'd like, it's very easy to convince yourself you've done the work when you haven't, you know, so then we'd actually try lots of things and be like, oh, and these like really important cases, the memory use is higher, you know, or it's actually slower. And we'd go in and we just find like all these things that were nothing to do with our library that just didn't work properly. And nobody had noticed they hadn't worked properly because nobody had really benchmarked it properly. So we ended up, you know, trying to fix a whole lot of different things. And even as we did so, new regressions were appearing in like transformers and stuff that Benjamin then had to go away and figure out like, oh, how come flash attention doesn't work in this version of transformers anymore with this set of models and like, oh, it turns out they accidentally changed this thing, so it doesn't work. You know, there's just, there's not a lot of really good performance type evals going on in the open source ecosystem. So there's an extraordinary amount of like things where people say like, oh, we built this thing and it has this result. And when you actually check it, so yeah, there's a shitload of war stories from getting that thing to work. And it did require a particularly like tenacious group of people and a group of people who don't mind doing a whole lot of kind of like really janitorial work, to be honest, to get the details right, to check them. Yeah.Alessio [00:34:09]: We had a trade out on the podcast and we talked about how a lot of it is like systems work to make some of these things work. It's not just like beautiful, pure math that you do on a blackboard. It's like, how do you get into the nitty gritty?Jeremy [00:34:22]: I mean, flash attention is a great example of that. Like it's, it basically is just like, oh, let's just take the attention and just do the tiled version of it, which sounds simple enough, you know, but then implementing that is challenging at lots of levels.Alessio [00:34:36]: Yeah. What about inference? You know, obviously you've done all this amazing work on fine tuning. Do you have any research you've been doing on the inference side, how to make local inference really fast on these models too?Jeremy [00:34:47]: We're doing quite a bit on that at the moment. We haven't released too much there yet. But one of the things I've been trying to do is also just to help other people. And one of the nice things that's happened is that a couple of folks at Meta, including Mark Seraphim, have done a nice job of creating this CUDA mode community of people working on like CUDA kernels or learning about that. And I tried to help get that going well as well and did some lessons to help people get into it. So there's a lot going on in both inference and fine tuning performance. And a lot of it's actually happening kind of related to that. So PyTorch team have created this Torch AO project on quantization. And so there's a big overlap now between kind of the FastAI and AnswerAI and CUDA mode communities of people working on stuff for both inference and fine tuning. But we're getting close now. You know, our goal is that nobody should be merging models, nobody should be downloading merged models, everybody should be using basically quantized plus adapters for almost everything and just downloading the adapters. And that should be much faster. So that's kind of the place we're trying to get to. It's difficult, you know, because like Karim's been doing a lot of work with VLM, for example. These inference engines are pretty complex bits of code. They have a whole lot of custom kernel stuff going on as well, as do the quantization libraries. So we've been working on, we're also quite a bit of collaborating with the folks who do HQQ, which is a really great quantization library and works super well. So yeah, there's a lot of other people outside AnswerAI that we're working with a lot who are really helping on all this performance optimization stuff, open source.Swyx [00:36:27]: Just to follow up on merging models, I picked up there that you said nobody should be merging models. That's interesting because obviously a lot of people are experimenting with this and finding interesting results. I would say in defense of merging models, you can do it without data. That's probably the only thing that's going for it.Jeremy [00:36:45]: To explain, it's not that you shouldn't merge models. You shouldn't be distributing a merged model. You should distribute a merged adapter 99% of the time. And actually often one of the best things happening in the model merging world is actually that often merging adapters works better anyway. The point is, Sean, that once you've got your new model, if you distribute it as an adapter that sits on top of a quantized model that somebody's already downloaded, then it's a much smaller download for them. And also the inference should be much faster because you're not having to transfer FB16 weights from HPM memory at all or ever load them off disk. You know, all the main weights are quantized and the only floating point weights are in the adapters. So that should make both inference and fine tuning faster. Okay, perfect.Swyx [00:37:33]: We're moving on a little bit to the rest of the fast universe. I would have thought that, you know, once you started Answer.ai, that the sort of fast universe would be kind of on hold. And then today you just dropped Fastlight and it looks like, you know, there's more activity going on in sort of Fastland.Jeremy [00:37:49]: Yeah. So Fastland and Answerland are not really distinct things. Answerland is kind of like the Fastland grown up and funded. They both have the same mission, which is to maximize the societal benefit of AI broadly. We want to create thousands of commercially successful products at Answer.ai. And we want to do that with like 12 people. So that means we need a pretty efficient stack, you know, like quite a few orders of magnitude more efficient, not just for creation, but for deployment and maintenance than anything that currently exists. People often forget about the D part of our R&D firm. So we've got to be extremely good at creating, deploying and maintaining applications, not just models. Much to my horror, the story around creating web applications is much worse now than it was 10 or 15 years ago in terms of, if I say to a data scientist, here's how to create and deploy a web application, you know, either you have to learn JavaScript or TypeScript and about all the complex libraries like React and stuff, and all the complex like details around security and web protocol stuff around how you then talk to a backend and then all the details about creating the backend. You know, if that's your job and, you know, you have specialists who work in just one of those areas, it is possible for that to all work. But compared to like, oh, write a PHP script and put it in the home directory that you get when you sign up to this shell provider, which is what it was like in the nineties, you know, here are those 25 lines of code and you're done and now you can pass that URL around to all your friends, or put this, you know, .pl file inside the CGI bin directory that you got when you signed up to this web host. So yeah, the thing I've been mainly working on the last few weeks is fixing all that. And I think I fixed it. I don't know if this is an announcement, but I tell you guys, so yeah, there's this thing called fastHTML, which basically lets you create a complete web application in a single Python file. Unlike excellent projects like Streamlit and Gradio, you're not working on top of a highly abstracted thing. That's got nothing to do with web foundations. You're working with web foundations directly, but you're able to do it by using pure Python. There's no template, there's no ginger, there's no separate like CSS and JavaScript files. It looks and behaves like a modern SPA web application. And you can create components for like daisy UI, or bootstrap, or shoelace, or whatever fancy JavaScript and or CSS tailwind etc library you like, but you can write it all in Python. You can pip install somebody else's set of components and use them entirely from Python. You can develop and prototype it all in a Jupyter notebook if you want to. It all displays correctly, so you can like interactively do that. And then you mentioned Fastlight, so specifically now if you're using SQLite in particular, it's like ridiculously easy to have that persistence, and all of your handlers will be passed database ready objects automatically, that you can just call dot delete dot update dot insert on. Yeah, you get session, you get security, you get all that. So again, like with most everything I do, it's very little code. It's mainly tying together really cool stuff that other people have written. You don't have to use it, but a lot of the best stuff comes from its incorporation of HTMX, which to me is basically the thing that changes your browser to make it work the way it always should have. So it just does four small things, but those four small things are the things that are basically unnecessary constraints that HTML should never have had, so it removes the constraints. It sits on top of Starlet, which is a very nice kind of lower level platform for building these kind of web applications. The actual interface matches as closely as possible to FastAPI, which is a really nice system for creating the kind of classic JavaScript type applications. And Sebastian, who wrote FastAPI, has been kind enough to help me think through some of these design decisions, and so forth. I mean, everybody involved has been super helpful. Actually, I chatted to Carson, who created HTMX, you know, so about it. Some of the folks involved in Django, like everybody in the community I've spoken to definitely realizes there's a big gap to be filled around, like, highly scalable, web foundation-based, pure Python framework with a minimum of fuss. So yeah, I'm getting a lot of support and trying to make sure that FastHTML works well for people.Swyx [00:42:38]: I would say, when I heard about this, I texted Alexio. I think this is going to be pretty huge. People consider Streamlit and Gradio to be the state of the art, but I think there's so much to improve, and having what you call web foundations and web fundamentals at the core of it, I think, would be really helpful.Jeremy [00:42:54]: I mean, it's based on 25 years of thinking and work for me. So like, FastML was built on a system much like this one, but that was of hell. And so I spent, you know, 10 years working on that. We had millions of people using that every day, really pushing it hard. And I really always enjoyed working in that. Yeah. So, you know, and obviously lots of other people have done like great stuff, and particularly HTMX. So I've been thinking about like, yeah, how do I pull together the best of the web framework I created for FastML with HTMX? There's also things like PicoCSS, which is the CSS system, which by default, FastHTML comes with. Although, as I say, you can pip install anything you want to, but it makes it like super easy to, you know, so we try to make it so that just out of the box, you don't have any choices to make. Yeah. You can make choices, but for most people, you just, you know, it's like the PHP in your home directory thing. You just start typing and just by default, you'll get something which looks and feels, you know, pretty okay. And if you want to then write a version of Gradio or Streamlit on top of that, you totally can. And then the nice thing is if you then write it in kind of the Gradio equivalent, which will be, you know, I imagine we'll create some kind of pip installable thing for that. Once you've outgrown, or if you outgrow that, it's not like, okay, throw that all away and start again. And this like whole separate language that it's like this kind of smooth, gentle path that you can take step-by-step because it's all just standard web foundations all the way, you know.Swyx [00:44:29]: Just to wrap up the sort of open source work that you're doing, you're aiming to create thousands of projects with a very, very small team. I haven't heard you mention once AI agents or AI developer tooling or AI code maintenance. I know you're very productive, but you know, what is the role of AI in your own work?Jeremy [00:44:47]: So I'm making something. I'm not sure how much I want to say just yet.Swyx [00:44:52]: Give us a nibble.Jeremy [00:44:53]: All right. I'll give you the key thing. So I've created a new approach. It's not called prompt engineering. It's called dialogue engineering. But I'm creating a system for doing dialogue engineering. It's currently called AI magic. I'm doing most of my work in this system and it's making me much more productive than I was before I used it. So I always just build stuff for myself and hope that it'll be useful for somebody else. Think about chat GPT with code interpreter, right? The basic UX is the same as a 1970s teletype, right? So if you wrote APL on a teletype in the 1970s, you typed onto a thing, your words appeared at the bottom of a sheet of paper and you'd like hit enter and it would scroll up. And then the answer from APL would be printed out, scroll up, and then you would type the next thing. And like, which is also the way, for example, a shell works like bash or ZSH or whatever. It's not terrible, you know, like we all get a lot done in these like very, very basic teletype style REPL environments, but I've never felt like it's optimal and everybody else has just copied chat GPT. So it's also the way BART and Gemini work. It's also the way the Claude web app works. And then you add code interpreter. And the most you can do is to like plead with chat GPT to write the kind of code I want. It's pretty good for very, very, very beginner users who like can't code at all, like by default now the code's even hidden away, so you never even have to see it ever happened. But for somebody who's like wanting to learn to code or who already knows a bit of code or whatever, it's, it seems really not ideal. So okay, that's one end of the spectrum. The other end of the spectrum, which is where Sean's work comes in, is, oh, you want to do more than chat GPT? No worries. Here is Visual Studio Code. I run it. There's an empty screen with a flashing cursor. Okay, start coding, you know, and it's like, okay, you can use systems like Sean's or like cursor or whatever to be like, okay, Apple K in cursors, like a creative form that blah, blah, blah. But in the end, it's like a convenience over the top of this incredibly complicated system that full-time sophisticated software engineers have designed over the past few decades in a totally different environment as a way to build software, you know. And so we're trying to like shoehorn in AI into that. And it's not easy to do. And I think there are like much better ways of thinking about the craft of software development in a language model world to be much more interactive, you know. So the thing that I'm building is neither of those things. It's something between the two. And it's built around this idea of crafting a dialogue, you know, where the outcome of the dialogue is the artifacts that you want, whether it be a piece of analysis or whether it be a Python library or whether it be a technical blog post or whatever. So as part of building that, I've created something called Claudette, which is a library for Claude. I've created something called Cosette, which is a library for OpenAI. They're libraries which are designed to make those APIs much more usable, much easier to use, much more concise. And then I've written AI magic on top of those. And that's been an interesting exercise because I did Claudette first, and I was looking at what Simon Willison did with his fantastic LLM library. And his library is designed around like, let's make something that supports all the LLM inference engines and commercial providers. I thought, okay, what if I did something different, which is like make something that's as Claude friendly as possible and forget everything else. So that's what Claudette was. So for example, one of the really nice things in Claude is prefill. So by telling the assistant that this is what your response started with, there's a lot of powerful things you can take advantage of. So yeah, I created Claudette to be as Claude friendly as possible. And then after I did that, and then particularly with GPT 4.0 coming out, I kind of thought, okay, now let's create something that's as OpenAI friendly as possible. And then I tried to look to see, well, where are the similarities and where are the differences? And now can I make them compatible in places where it makes sense for them to be compatible without losing out on the things that make each one special for what they are. So yeah, those are some of the things I've been working on in that space. And I'm thinking we might launch AI magic via a course called how to solve it with code. The name is based on the classic Polya book, if you know how to solve it, which is, you know, one of the classic math books of all time, where we're basically going to try to show people how to solve challenging problems that they didn't think they could solve without doing a full computer science course, by taking advantage of a bit of AI and a bit of like practical skills, as particularly for this like whole generation of people who are learning to code with and because of ChatGPT. Like I love it, I know a lot of people who didn't really know how to code, but they've created things because they use ChatGPT, but they don't really know how to maintain them or fix them or add things to them that ChatGPT can't do, because they don't really know how to code. And so this course will be designed to show you how you can like either become a developer who can like supercharge their capabilities by using language models, or become a language model first developer who can supercharge their capabilities by understanding a bit about process and fundamentals.Alessio [00:50:19]: Nice. That's a great spoiler. You know, I guess the fourth time you're going to be on learning space, we're going to talk about AI magic. Jeremy, before we wrap, this was just a great run through everything. What are the things that when you next come on the podcast in nine, 12 months, we're going to be like, man, Jeremy was like really ahead of it. Like, is there anything that you see in the space that maybe people are not talking enough? You know, what's the next company that's going to fall, like have drama internally, anything in your mind?Jeremy [00:50:47]: You know, hopefully we'll be talking a lot about fast HTML and hopefully the international community that at that point has come up around that. And also about AI magic and about dialogue engineering. Hopefully dialogue engineering catches on because I think it's the right way to think about a lot of this stuff. What else? Just trying to think about all on the research side. Yeah. I think, you know, I mean, we've talked about a lot of it. Like I think encoder decoder architectures, encoder only architectures, hopefully we'll be talking about like the whole re-interest in BERT that BERT 24 stimulated.Swyx [00:51:17]: There's a safe space model that came out today that might be interesting for this general discussion. One thing that stood out to me with Cartesia's blog posts was that they were talking about real time ingestion, billions and trillions of tokens, and keeping that context, obviously in the state space that they have.Jeremy [00:51:34]: Yeah.Swyx [00:51:35]: I'm wondering what your thoughts are because you've been entirely transformers the whole time.Jeremy [00:51:38]: Yeah. No. So obviously my background is RNNs and LSTMs. Of course. And I'm still a believer in the idea that state is something you can update, you know? So obviously Sepp Hochreiter came up, came out with xLSTM recently. Oh my God. Okay. Another whole thing we haven't talked about, just somewhat related. I've been going crazy for like a long time about like, why can I not pay anybody to save my KV cash? I just ingested the Great Gatsby or the documentation for Starlet or whatever, you know, I'm sending it as my prompt context. Why are you redoing it every time? So Gemini is about to finally come out with KV caching, and this is something that Austin actually in Gemma.cpp had had on his roadmap for years, well not years, months, long time. The idea that the KV cache is like a thing that, it's a third thing, right? So there's RAG, you know, there's in-context learning, you know, and prompt engineering, and there's KV cache creation. I think it creates like a whole new class almost of applications or as techniques where, you know, for me, for example, I very often work with really new libraries or I've created my own library that I'm now writing with rather than on. So I want all the docs in my new library to be there all the time. So I want to upload them once, and then we have a whole discussion about building this application using FastHTML. Well nobody's got FastHTML in their language model yet, I don't want to send all the FastHTML docs across every time. So one of the things I'm looking at doing in AI Magic actually is taking advantage of some of these ideas so that you can have the documentation of the libraries you're working on be kind of always available. Something over the next 12 months people will be spending time thinking about is how to like, where to use RAG, where to use fine-tuning, where to use KV cache storage, you know. And how to use state, because in state models and XLSTM, again, state is something you update. So how do we combine the best of all of these worlds?Alessio [00:53:46]: And Jeremy, I know before you talked about how some of the autoregressive models are not maybe a great fit for agents. Any other thoughts on like JEPA, diffusion for text, any interesting thing that you've seen pop up?Jeremy [00:53:58]: In the same way that we probably ought to have state that you can update, i.e. XLSTM and state models, in the same way that a lot of things probably should have an encoder, JEPA and diffusion both seem like the right conceptual mapping for a lot of things we probably want to do. So the idea of like, there should be a piece of the generative pipeline, which is like thinking about the answer and coming up with a sketch of what the answer looks like before you start outputting tokens. That's where it kind of feels like diffusion ought to fit, you know. And diffusion is, because it's not autoregressive, it's like, let's try to like gradually de-blur the picture of how to solve this. So this is also where dialogue engineering fits in, by the way. So with dialogue engineering, one of the reasons it's working so well for me is I use it to kind of like craft the thought process before I generate the code, you know. So yeah, there's a lot of different pieces here and I don't know how they'll all kind of exactly fit together. I don't know if JEPA is going to actually end up working in the text world. I don't know if diffusion will end up working in the text world, but they seem to be like trying to solve a class of problem which is currently unsolved.Alessio [00:55:13]: Awesome, Jeremy. This was great, as usual. Thanks again for coming back on the pod and thank you all for listening. Yeah, that was fantastic. Get full access to Latent Space at www.latent.space/subscribe
In the latest episode of the "Giant Robots On Tour" podcast, hosts Rémy Hannequin and Sami Birnbaum welcome Marc G. Gauthier, a solopreneur and startup coach, who shares his journey from software development to becoming the founder and developer of The Shadow Boxing App. Marc describes how his interest in software engineering began at a young age with QBasic and evolved through various leadership roles at companies like Drivy (now Getaround) and Back Market. His early passion for gaming led him to learn coding, and over time, he naturally transitioned into management roles, finding excitement in organizing and leading teams while maintaining his love for building products. During the episode, Marc discusses the challenges and intricacies of scaling startups, emphasizing the importance of balancing speed and reliability in software development. He recounts his experiences in leadership positions, where he faced the dual task of managing rapid team growth and maintaining software efficiency. Marc also shares insights into the startup ecosystem, noting that most startups struggle to achieve success due to a combination of market timing, team dynamics, and resource management. His own venture, The Shadow Boxing App, represents his attempt to return to hands-on coding while leveraging his extensive experience in startup coaching and advising. Marc also touches on the role of AI in the future of software development, expressing cautious optimism about its potential to augment human workflows and automate repetitive tasks. He advises current and aspiring developers to embrace AI as a tool to enhance their capabilities rather than a replacement for human ingenuity. Marc concludes by highlighting the importance of realistic expectations in the startup world and the need for continuous learning and adaptation in the ever-evolving tech landscape. Getaround (https://getaround.com/) Follow Getaround on LinkedIn (https://www.linkedin.com/company/getaround/), Facebook (https://www.facebook.com/getaround), X (https://twitter.com/getaround), YouTube (https://www.youtube.com/getaround), or Instagram (https://www.instagram.com/getaround/). Back Market (https://www.backmarket.com/en-us) Follow Back Market on LinkedIn (https://www.linkedin.com/company/back-market/), Facebook (https://www.facebook.com/BackMarketCom), X (https://x.com/backmarket), or Instagram (https://www.instagram.com/backmarket). The Shadow Boxing App (https://shadowboxingapp.com/) Follow Marc Gauthier on LinkedIn (https://www.linkedin.com/in/marcggauthier/). Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). Transcript: RÉMY: This is the Giant Robots Smashing Into Other Giant Robots podcast, the Giant Robots on Tour series coming to you from Europe, West Asia, and Africa, where we explore the design, development, and business of great products. I'm your host, Rémy Hannequin. SAMI: And I'm your other host, Sami Birnbaum. RÉMY: If you are wondering who we are, make sure you find the previous podcast where we introduced the Giant Robots on Tour series by throwing random icebreakers at each other. And find out that Jared likes it when someone takes the time to understand someone else's point of view. Joining us today is Marc G Gauthier, a Solopreneur and Startup Coach. Marc, you used to be VP of Engineering at Drivy, now known as Getaround, and also Director of Engineering at Back Market. You also have been a coach and advisor to a startup for over a decade. Currently, your current adventure is being the Founder and Developer of The Shadow Boxing App available on the Apple App Store. We always like to go back to the start with our guests. Everyone has a story, and we are interested in your journey. So, Marc, what led you into the world of software engineering in the first place? MARC: Hello. Well, happy to be here. And, yeah, I started getting into software development quite a long time ago. I actually learned software development with QBasic when I was something like seven. And, from there, I just kept on learning, learning, and learning and got into school for it, then worked in different startups, and then moved into more leadership position management. And I'm now, like, coaching people and building my own product. What do you want to get? Because it's broad. I've been doing it for quite a while. Like, I don't think the QBasic days are that insightful. The only thing I remember from that time is being confused by the print comment that I would expect it to print on my printer or something, but it didn't; it just printed on the screen. That's the only thing I have from back then. SAMI: Why at seven years old? And I'm taking you back too far, but at seven years old, I was probably collecting Pokémon cards and possibly like, you know, those football stickers. I don't know if you had the Panini stickers. MARC: Oh yeah, I was doing that as well. SAMI: But you were doing that as well. But then what drove you at that age? What do you think it was that made you think, I want to start learning to code, or play around with the computer, or get into tech? MARC: [laughs] Yeah. Well, I remember, back then, I really wanted a computer to play games. Like, I had a friend who had a computer. He was playing games, and I wanted to do that. So, I was asking my mom to have a computer, and she told me, "Yeah, you can have one." And she found a really old computer she bought from a neighbor, I think. But she told me like, "I don't know anything about it. So, you have to figure it out and set it up." And she just found someone to kind of help me. And this person told me to, like, take the computer apart. She taught me a bit of software development, and I kind of liked it. And I was always trying to change the games. Back then, it was way easier. You could just edit a sound file, and you would just edit the sound file in the game, so yeah, just learning like this. It wasn't really my intent to learn programming. It just kind of happened because I wanted to play video games really. SAMI: That's really cool. It's really interesting. Rémy, do you remember how...how did you first get...do you remember your first computer, Rémy? RÉMY: My first computer, I think I remember, but the first one I used it was, first, a very long time ago. I discovered that it was an Apple computer way, way later when I discovered what Apple was and what computers were actually. And I just remember playing SimCity 2000 on it, and it was amazing. And we had to, you know, cancel people from making phone calls while we were on the computer because of the internet and all the way we had to connect to the internet back then. And after that, just, I think, Windows 95 at home. Yeah, that's the only thing I can remember actually. Because I think I was lucky, so I got one quite early. And I don't really remember not having one, so I was quite lucky with that. And so, I was always kind of in the computer game without being too much [inaudible 05:02] [laughs]. SAMI: Yeah, I think that's similar to me as well. Like, it's interesting because my initial introduction to computers would have been watching my older brothers kind of play computer games and actually being told to get out the room, or like, you know, "We're busy now. Don't bother us." And then, what actually happened is when they left the room, I managed to play what they were playing, which was the first ever GTA. I don't know if anyone ever played this, but it is so cool if you look back on it. You could probably find emulators online, but it was, like, a bird's eye view, like, way of operating. And it was probably also that drive where you get frustrated on a computer because you want to do something, so, like you were saying, Marc, where you went to edit the sound files because you want to change something. You want to do something. I definitely think that is something which I felt as well is that frustration of I want to change this thing. And then, that kind of gets into well, how does it work? And if I know how it works, then I can probably change it. MARC: Yeah. And once you figure out how things work, it's also really exciting. Like, once you figure out the initialization file on Windows, like, you can edit, like, what level is unlocked right away. It's kind of cheat codes but not really. And there are some really fun ones. Like, I would edit sound files for racing games. And, usually, it's just a base sound file, and then they would pitch shift the sound to make it sound like an engine. So, if you record your voice, it's just really funny. RÉMY: So, Marc, you mentioned moving to management positions quite early. Do you remember what made you do this move? Was it for, like, a natural path in your career, or was it something you really wanted from the first part of your career as a developer? What happened at this moment? MARC: Yeah, that was not completely planned. Like, I don't think I really plan my career precisely. It's just something that happens. So, I joined Drivy after, like, I was already a software engineer for, like, five years at that point. I joined as a lead backend engineer. I did that for three years. And after three years, the company went from...I think there was, like, three software engineers to a dozen. There was a need for more structure, and the CTO, at the time so, Nicolas, wanted to focus more on products. And it was hard to do both, like do the product side, the design, the data, and do the engineering, the software, and so on. So, he wanted to get a bit away from software engineering and more into product. So, there was a gap in the organization. I was there. I was interested to try, and I was already doing some more things on the human side, so talking to people, organizing, internal communication. I kind of liked it. So, I was excited to try, give it a try. It was really interesting. I found that it was a different way to have an impact on the team. I just kept doing it. And my plan was to keep doing it until I'm bored with it. And I'm still not bored with it, even though you kind of miss just actually building the software yourselves, actually coding. So, that's also why I'm trying something different right now with my mobile app adventure. SAMI: Right. So, on the side, you've got this Shadow Boxing App, which, in my dedicated research, I downloaded and had a go with it. MARC: Did you actually try it, or did you just click around? SAMI: I did a proper workout, mate. I did. I put myself as, like, the absolute beginner. I did it on my MacBook Pro. I know it's built for iPad or iPhone, but it still worked amazingly well. And it kind of reminded me why I stopped doing boxing because it's hard work. MARC: [laughs] Yeah, it is. SAMI: It's not a gimmick this thing, right? So, it's like, the best way to describe it is it's essentially replacing if I was to go to the gym and have a trainer who's telling me kind of the moves to make or how to do it, then this kind of replaces that trainer. So, it's something you can do at home. It was really cool. I was surprised, actually. I thought, at the beginning, it's not going to be that interactive, or it won't actually be as hard or difficult as a workout, and it really was. So, it's, yeah, it was really cool, really interesting to try it. And going into that, you say you wanted to get back more into coding, and that's why you are doing this kind of, like, app on the side, or it allowed you to kind of do a bit more coding away from the people management. You've been involved in a lot of startups, and I actually often get...as consultants, when we work at thoughtbot, we get a lot of people who come with different startup ideas. When you look back at all the startups you've been involved with, do you think more startups are successful than those that fail? Or have you seen a lot of startups...actually, people come with these great ideas; they want to build this amazing product, but it's actually really hard to be a successful product? MARC: I think it's [inaudible 10:22] how to have the right idea, be at the right spot at the right time, build the right team, get enough momentum. I think most startups fail, and even startups that are successful often can be the result of a pivot. Like, I know companies that pivoted a bunch of times before finding any success. So, it's really hard actually...if I take my past four companies, only two are still alive. Like, the first two went under. Actually, there's even more companies that went under after I left. Yeah, it's just really hard to get anything off the ground. So, yeah, it's complicated, and I have a lot of respect for all the founders that go through it. For The Shadow Boxing App, I worked on it for the past three years, but I'm only working on it almost full-time for the past two months. And it was way safer. I could check the product-market fit. I could check if I enjoyed working on it. So, I guess it was easier. I had the luxury of having a full-time job. Building the app didn't take that much time. But to answer your question, I think, from my experience, most startups fail. And the ones that succeed it's kind of lightning in a bottle, or, like, there's a lot of factors that get into it. It's hard to replicate. A lot of people try to replicate some science, some ideas. They go, oh, we'll do this, and we'll do that. And we use this technique that Google uses and so on, but it's never that straightforward. SAMI: Yeah, I'm so happy you said that because I think it's a real brutal truth that I'd also say most of the startup projects that I've worked on probably have failed. Like, there's very few that actually make it. It's such a saturated market. And I think, I guess, in your role as advising startups, it's really good to come in with that honesty at the beginning and to say, "It's a big investment if you want to build something. Most people probably aren't successful." And then, when you work from that perspective, you can have, like, way more transparent and open discussions from the get-go. Because when you're outside of tech...and a lot of people have this idea of if I could just get an app to do my idea, I'm going to be the next Facebook. I'm going to be the next, you know, Amazon Marketplace. And it just kind of isn't like that. You've got these massive leaders in Facebook, Amazon, Google, Netflix. But below that, there's a lot of failures and a massively saturated market. So, yeah, just, it's so interesting that you also see it in a similar way. MARC: What I saw evolve in the past 10 years is the fact that people got more realistic with it. So, maybe 10 years ago, I would have people coming to me with just the most ridiculous idea, like, you know, I'll do Airbnb for cats. And really think, yeah, I just need a good idea, and that's it. But now I feel like people kind of understand that it's more complicated. There's way more resources online. People are more educated. They also see way more successes. Failures are also a bit more advertised. We saw a bunch of startups just go under. It feels like every month I get an email from a tool I used in the past saying, "Oh, we're shutting down," and so on. So, I think it's not as bad as 10 years ago where weekly I would have just people asking me, "I want to build this app," and the app would be just the most ridiculous thing or something that would be really smart, but it's really like, "Oh, I want to do, like, food delivery but better than what exists." It's like, yeah, that's a really good idea, but then you need...it's not only software. There's logistics. There's so much behind it that you don't seem to understand just yet. But, as a coach, so, what I'm doing is I'm helping startups that are usually before or after series A but not too large of startups just go to the next stage. And people are really aware of that and really worried. Like, they see money going down, market fit not necessarily being there. And they know, like, their company is at risk. And especially when you talk to founders, they're really aware that, you know, everything could be collapsing really quickly. If they make, like, three really bad decisions in a row, you're basically done. Obviously, it depends on the company, but yeah, people are more aware than before, especially nowadays where money is a bit harder to get. Let's say two years ago, there was infinite money, it felt like. Now it's more tight. People are more looking at the unit economics precisely. So, people need to be more realistic to succeed. RÉMY: What's the kind of recurrent struggle the startups you coach usually face? Apparently, it quite changed in the past decade, but maybe what are the current struggles they face? MARC: It really depends. It's kind of broad. But, usually, it would be, let's say, a startup after their first round of funding, let's say, if you take startups that are looking for funding. So, you usually have a group of founders, two to four, usually two or three, that are really entrepreneurs that want to bootstrap some things. They're builders. They're hacking things together, and they're really excited about the product. And, suddenly, fast forward a few years, they're starting to be successful, and they have to lead a team of, you know, like, 50 people, 100 people, and they weren't prepared for that. They were really prepared to, like, build software. Like, especially the CTOs, they are usually really great hackers. They can, like, create a product really quickly. But, suddenly, they need to manage 30 engineers, and it's completely different, and they're struggling with that. So, that's a common problem for CTOs. And then, it creates a bunch of problems. Like, you would have CEOs and CTOs not agreeing on how to approach the strategy, how to approach building a thing. What should be the methodology? Something that worked with 3 engineers around the table doesn't work with 50 engineers distributed in 5 countries. And if it's your first time being a CTO, and often founders of early-stage startups are first-time CTOs, it can be really hard to figure out. MID-ROLL AD: Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features? We know maintaining your own servers can be costly and that it's easy for spending creep to sneak in when your team isn't looking. By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer. Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops. RÉMY: In your past companies, so you've been VP and CTO. So, in your opinion, what's the best a VP or a CTO can bring to a scaling startup? What are your best tips to share? MARC: I guess it depends [laughs], obviously, like, depending on the stage of the company, the size of the company. For instance, when I was at Drivy, at some point, the most important thing was scaling the team hiring, and so on. But, at some point, we got acquired by Getaround, and the priorities got shifted. It was more like, okay, how do you figure out this new setup for the company and the team? Like, what is good? What is bad? How do you communicate with the team? How do you get people to stay motivated when everything is changing? How do you make sure you make the right decisions? And then, when I joined Back Market, Back Market when I joined, I had a team of a bit less than 12 engineers reporting directly to me. And after a bit more than a year, I had 60, and I hired most of them. So, here the challenge was just scaling insanely fast. Like, the company is really successful. Like, Back Market is selling refurbished electronics in a mission to, you know, provide a viable alternative to buying new electronics. So, it's basically, do you want a smartphone that is both cheaper and more ecologically viable? And most people would say yes to that. So, a company is insanely successful, but it's really hard to scale. So, at that point, the role was, okay, how do you make sure you scale as well as possible with a lot of pressure while still leaving the team in a state that they're able to still build software? Because it's just really chaotic. Like, you can't, like, 5X your team without chaos. But how do you minimize that but still go really fast? SAMI: Yeah. So, not only did I try that Shadow App. I actually went on that Backup website. What's it called? It's not called Backup. What's it called again? MARC: Back Market. SAMI: Back Market. Thank you. Yeah, it was really cool. I checked my old iPhone SE from 2020, which I've kept for about...over three years, I've had this iPhone. And they said they would give me $72 for it, which was really cool. So, it sounds like a really cool idea. MARC: That's something we worked on, which is, basically, if you have any old phones in your drawer, it's a really bad spot for them. And so, there's a service. You go on the website. You say, "I have this, I have that; I have this, I have that." And either we buy it from you, or we just take it away from you, and we recycle them, which is much better than just having them collect dust. SAMI: Yeah, no, it's a great idea. What interested me when you were speaking about kind of these different positions that you've been in, I was almost expecting you to talk about maybe, like, a technical challenge or code complexity difficulty. But, actually, what you've described is more people problems. And how do we scale with regards to people, and how do we keep people motivated? So, I guess using that experience, and this might be counterintuitive to what a lot of people think, but what do you think is the hardest thing about software development? I know there could be many things. But if you had to pick something that is the most difficult, and maybe we can all have an answer to what we think this is, but starting with you, Marc, what do you think is the hardest thing about software development then? MARC: What I saw is how do you build something that works for enough time to bring value to the customers? So, it's easy to hack something together pretty quickly and get it in front of people, but then it might not be reliable. It might break down. Or you could decide to build something perfect and spend, like, two years on it and then ship it, and then it's really stable, but maybe it's not what people want. And finding this balance between shipping something fast, but shipping something that is reliable enough for what you're building. Obviously, if you're building a health care system, you will have more, like, the bar will be higher than if you build, like, Airbnb for cats. Finding this balance and adjusting as you go is really hard. So, for instance, when do you introduce caching? Because, obviously, caching is hard to do right. If you don't do it, your site will be slow, which can be okay for a time. But then if you introduce it too late, then it's really hard to just retrofit into whatever you already have. So, finding the right moment to introduce a new practice, introduce a new technology is tricky. And then, like, I talked a lot about the people, and it's also because I spent quite a bit of time in leadership position. But, at the end of the day, it will be the people writing the code that gets the software to exist and run. So, having people aligned and agreeing on the vision is also key because unless I'm the only developer on the project, I can't really make all decisions on things that are going to get built. So, figuring out how to get people motivated, interested in just building in the same direction is really important. It's really easy. Like, one thing with Drivy, when I was there, that was really fun to see, like, many people have this reaction, especially the more senior people joining the company. They would see the engineering team, and they were really, really surprised by how small it was because we were being really, really efficient. Like, we were paying really close attention to what we would work on. So, kind of technology we would introduce would be quite conservative on both to really be able to deliver what is the most important. So, we were able to do a lot with, honestly, not a lot of people. And I think this is a great mark for success. You don't need a thousand people to build your software if you ask the right question, like, "Do I need to build X or Y?" and always having these discussions. RÉMY: What's your opinion on that, Sami? SAMI: Yeah, I guess it changes. Like, for example, today, the hardest thing about software development was just getting Jira to work. That has literally ruined my whole day. But I've found, for me, what I find is the most difficult thing to do is making code resilient to change. What I mean by that is writing code that's easy to change. And a lot of that, I guess, we try to work on at thoughtbot, as consultants, is following kind of design principles and best practices and certain design patterns that really make the code easy to change. Because that, I think, when I'm writing code is the biggest challenge. And where I feel when I'm working with our clients one of the biggest things they can invest in, which is difficult because there's not a lot of visibility around it or metrics, is ensuring that code that's written is easy to change because, at some point, it will. And I've also worked on systems which are bigger, and when you can't change them, conversations start happening about the cost of change. Do we rewrite it from the ground up again? And that opens a whole different can of worms. So, that, for me, I think, is definitely one of the hardest things. How about yourself, Rémy? RÉMY: I don't know about the most difficult. I mean, there are many things difficult. But I remember something that I had to put extra effort, so maybe it was one of the most difficult for me. When I started being a consultant, when I joined thoughtbot was to understand what's the boundary between executing and giving an advice? So, basically, I discovered that when you're a consultant, but it works also when you're a developer in a team, you know, you're not just only the one who is going to write the code. You're supposed to be also someone with expertise, experience to share it and to make the project and the team benefit from it. So, at some point, I discovered that I should not just listen to what the client would say they want. Obviously, that's what they want, but it's more interesting and more difficult to understand why they want it and why they actually need, which could be different from what they want. So, it's a whole different conversation to discover together what is actually the necessary thing to build, and with your expertise and experience, try to find the thing that is going to be the most efficient, reliable, and making both the client and the customers happy. MARC: Yeah. And as software engineers, it's really easy to get excited about a problem and just go, "Oh, I could solve it this way." But then you need to step back and go, "Well, maybe it doesn't need fixing, or we should do something completely different." At some point, I was working with a customer service organization. In their workflows, they had to go on, let's say, five different pages and click on the button to get something to do one action. And so, what they asked for is to have those five buttons on one single page, and so, they could go, click, click, click, click, click. But after looking at it, what they needed is just automation of that, not five buttons on the page. But it's really easy to go, oh, and we could make those buttons, like, kind of generic and have a button creator thing and make it really fancy. When you step back, you go, oh, they shouldn't be clicking that many buttons. SAMI: Yeah, that makes so much sense because just in that example...I can't remember where I read this, but every line of code you write has to be maintained. So, in that example where you've got five buttons, you're kind of maintaining probably a lot more code than when you've got the single button, which goes to, I don't know, a single action or a method that will handle kind of all the automation for you. And that's also, you know, driving at simplicity. So, sometimes, like, you see this really cool problem, and there's a really cool way to solve it. But if you can solve it, you mentioned, like, being conservative with the type of frameworks maybe you used in a previous company, like, solve it in the most simple way, and you'll thank yourself later. Because, at some point, you have to come back to it, and maintain it, change it. Yeah, so it makes a lot of sense. And, Marc, you said you started when you were 7, which is really young. Through that amount of time, you've probably seen massive changes in the way websites look, feel, and how they work. In that time, what's the biggest change you actually think you've seen? MARC: The biggest thing I saw is, when I started, internet didn't exist or at least wasn't available. Like, I remember being at school and the teacher would ask like, "How many people have a computer at home?" And we'd be like, two or three people. So, people didn't have internet until I was like 14, 15, I'd say. So, that's the biggest one. But, let's say, after it started, they just got more complicated. Like, so, the complexity is getting crazy. Like, I remember, at some point, where I saw I think it was called Aviary. It was basically Photoshop in the browser, and I was just insanely impressed by just the fact that you could do this in the browser. And, nowadays, like, you've got Figma, and you've got so many tools that are insanely impressive. Back then, it was just text, images, and that's it. I actually wrote a blog post a few years ago about how I used to build websites just using frames. So, I don't know if you're familiar with just frames, but I didn't really know how to do divs. So, I would just do frames because that's what I understood back then, again, little kid. But it was kind of working. You were dealing with IE 5 or, like, I remember, like, professionally fixing bugs for IE 5.5 or, like, AOL, like, 9, something ridiculous like this. So, building a website just got way easier but also way more complicated, if that makes sense. Like, it's way easier to do most things. For instance, I don't know, like, 20 years ago, you wanted a rounded corner; you would have to create images and kind of overlay them in a weird way. It would break in many cases. Nowadays, you want rounded corners? That's a non-topic. But now you need, like, offline capabilities of your website. And, in a lot of cases, there's really complex features that are expected from users. So, the bar is getting raised to crazy levels. SAMI: Yeah, I always wonder about this. Like, when you look at how the internet used to be and how people develop for the internet, and, like you're saying, now it's more complex but easier to do some things. I don't know if as developers we're making things harder or easier for ourselves. Like, if you look at the amount of technology someone needs to know to get started, it grows constantly. To do this, you have to add this framework, and you need to have this library, and maybe even a different language, and then, to even host something now, the amount of technologies you need to know. Do you think we're making things harder for ourselves, or do you think easier? MARC: Well, I guess there's always back and forth, like, regarding complexity. So, things will get really, really complex, and then someone will go, "Well, let's stop that and simplify." That's why, like, I'm seeing some people not rejecting React and so on, but going a simpler route like Rails has options like this. There's people using HTMX, which is really simple. So, just going back to something simpler. I think a lot of the really complex solutions also come from the fact that now we have massive teams building websites, and you need that complexity to be able to handle the team size. But it's kind of, then you need more people to handle the complexity, and it's just getting crazy. Yeah, honestly, I don't know. I'm seeing a lot of things that feel too complex for...like, the technology feels really complicated to accomplish some things that should be simple or at least feel simple. But, at the same time, there are things that got so simple that it's ridiculous like just accepting payment. I remember, like, if you wanted to accept payment on a site, it would be months of work, and now it takes a minute. You just plug in Stripe, and it works. And it's often cheaper than what it used to be. So, it's kind of...or deploying. You mentioned deploying can be really hard. Well, you don't need to have a physical server in your room just eating your place up to have your website, your personal website running. You just push it to Vercel, or Heroku, or whatever, or just a static page on S3. So, this got simpler, but then, yeah, you can get it to be so much more crazy. So, if you host your static website on S3, fairly simple. But then if you try to understand permissions on S3, then, you know, it's over. RÉMY: I don't know if it's really in the path of our discussion. I just wanted to ask you, so this is the on tour series, where we...so, usually, the Giant Robots podcast used to be a little bit more American-centric, and this on tour is moving back to the other side of the Atlantic with, again, Europe, West Asia, and Africa. You've been part of a company, Drivy, which expanded from France to neighboring countries in Europe. What could you tell our listeners about how to expand a business internationally? MARC: That's a tough question, especially in Europe. Because I know looking from the outside, like, if you're from the U.S. and you look at Europe, it feels like, you know, a uniform continent, but really, it's very different. Like, just payment methods are different. Culture is very different. For instance, when I was working at Back Market in France, one of the branding aspects of Back Market was its humor. Like, we would be making a lot of jokes on the website, and it would work really well in France. Like, people would love the brand. But then you expand to other countries, and they just don't find that funny at all. Like, it's not helping at all, and they're expecting a different tone of voice. So, it's not just, okay, I need to translate my own page; it's I need to internationalize for this market. I guess my advice is do it country by country. Sometimes I see companies going like, oh, we opened in 20 different countries, and you go, how even do you do that? And spend some time understanding how people are using your product or, like, a similar product locally because you would be surprised by what you learn. Sometimes there's different capabilities. For instance, when Drivy went to the UK, there's so much more you can learn. There's the government database that you can look up, and it really helps with managing risk. If people are known to steal cars, you can kind of figure it out. I'm simplifying a bit, but you can use this. You don't have that in France because we just don't have this solution. But if you go to Nordic countries, for instance, they have way more electric vehicles, so maybe the product doesn't work as well. So, it's really understanding what's different locally and being willing to invest, to adapt. Because if you go, okay, I'm going to open in the Netherlands but you don't adopt the payment methods that are used in the Netherlands, you might as well not open at all. So, it's either you do it properly and you kind of figure out what properly means for your product, or you postpone, and you do it well later. Like, right now, I'm struggling a bit with my app because it's open. So, it's on the App Store, so it's open globally. And it's a SaaS, so it's simpler, but I struggle with language. So, it's in French and English. I spoke both of this language, obviously, French better than English. But I think I'm doing okay with both. But I also built it in Spanish because I speak some Spanish fairly poorly, and I wanted to try to hit a different market like the Mexican market that are doing boxing quite a lot. But the quality doesn't seem there. Like, I don't have the specific boxing lingo, so I'm contemplating just rolling it back, like, removing the Spanish language until I get it really well, maybe with a translator dedicated to it that knows boxing in Spanish. Because I work with translators that would translate, but they don't really know that, yeah, like a jab in boxing. In Spanish, they might also say, "Jab." They won't translate it to, like, [inaudible 38:31]. SAMI: Yeah. At thoughtbot, we have one of our clients they wanted to release their app also internationally. And so, we had also kind of a lot of these problems. We even had to handle...so, in some languages, you go from left to right, right to left. So, that kind of also changed a lot of the way you would design things is mainly for people who are going from left to right. I mean, that's thinking kind of more Europe, U.S.-centric. And then, you could be releasing your app into a different country where they read the other direction. So, yeah, a lot of this stuff is really interesting, especially the culture, like you're saying. Do they find this humor funny? And then, how do they translate things? Which, in my head, I think, could you use AI to do that. Which is a nice segue into, like, the mandatory question about AI, which we can't let you go until we ask you. MARC: [laughs] SAMI: So, okay, obviously, I'm going to ask you about your thoughts on AI and where you think we're headed. But I've seen something interesting, which I don't know if this is something that resonates with you as well. I've seen a bit of a trend where the more experienced developers or more senior developers I talk to seem to be a bit more calm and less concerned. Whereas I would consider myself as less experienced, and I feel, like, kind of more anxious, more nervous, more jumping on the bandwagon sort of feeling of keeping an eye on it. So, I guess, with your experience, what are your thoughts on AI? Where do you think we are headed? MARC: That's a big question, and it feels like it's changing month to month. It feels way more interesting than other trends before. Like, I'm way more excited about the capabilities of AI than, like, NFTs or stuff like this. I'm actively using AI tooling in my app. I was using some AI at Back Market. So, it's interesting. There's a bunch of things you can be doing. Personally, I don't think that it's going to, like, make programming irrelevant, for instance. It will just change a bit how you will build things just like...so, we talked about what changed in the past. For instance, at some point, you would need a team of people moving around physical computers and servers and just hooking them up to be able to have a website. But now, most people would just use a cloud provider. So, all those people either they work for the cloud provider, or they're out of a job. But really what happened is most shifted into something different, and then we focused on something different. Instead of learning how to handle a farm of servers, we learned how to, I don't know, handle more concurrency in our models. And I think when I look back, I feel like, technically, maybe, I don't know, 70%, 80% of what I learned is now useless. Like, I spent years getting really good at handling Internet Explorer as a web developer. Now it's just gone, so it's just gone forever. And it feels like there's some practice that we're having right now that will be gone forever thanks to AI or because of AI, depending on how you look at it. But then there'll be new things to do. I'm not sure yet what it will be, but it will create new opportunities. There are some things that look a bit scary, like, or creepy. But I'm not worried about jobs or things like this. I'm a bit concerned about people learning programming right now because, yeah, there's a lot of hand-holding, and there's a lot of tools that you have to pay to get access to this hand-holding. So, if you're a student right now in school learning programming and your school is giving you some AI assistant, like Copilot or whatever, and this assistant is really good, but suddenly it goes away because you're not paying anymore, or, like, the model change, if you don't know how to code anymore, then it's a problem. Or maybe you're not struggling as much. And you're not digging deep enough, and so you're learning slower. And you're being a bit robbed of the opportunity to learn by the AI. So, it's just giving you the solution. But it's just, like, the way I use it right now, so I don't have an assistant enabled, but I usually have, like, a ChatGPT window open somewhere. It's more like a better Stack Overflow or a more precise Stack Overflow. And that helps me a lot, and that's really convenient. Like, right now, I'm building mostly using Swift and Swift UI, but I'm mainly a Ruby and JavaScript developer. So, I'm struggling a lot and being able to ask really simple questions. I had a case just this morning where I asked how to handle loading of images without using the assets folder in Xcode. I just couldn't figure it out, but it's really simple. So, it was able to tell me, like, right away, like, five options on how to do it, and I was able to pick the one that would fit. So, yeah, really interesting, but yeah, I'm not that worried. The only part I would be worried is if people are learning right now and relying way too much on AI. RÉMY: Well, at least it's positive for our job. Thank you for making us believe in a bright future, Marc. MARC: [laughs] RÉMY: All right. Thank you so much, Marc, for joining us. It was a real pleasure. Before we leave, Marc, if you want to be contacted, if people want to get a hold of you, how can you be contacted? MARC: There's two ways: either LinkedIn, look up Marc G Gauthier. Like, the middle initial is important because Marc Gauthier is basically John Smith in France. My website, which is marcgg.com. You can find my blog. You can find a way to hire me as a coach or advisor. That's the best way to reach out to me. RÉMY: Thank you so much. And thank you, Sami, as well. You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have any questions or comments, you can email us at hosts@giantrobots.fm. You can find me on social media as rhannequin. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening, and see you next time. AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.
In today's episode, we bring Spiro Floropoulos, a senior developer and architect with over 20 years of experience. This episode is an unusual one, as Spiro recently got laid off due to a bizarre chain of events that involved HTMX, overworking, and technical debt. But we'll learn from this story, as we want to shed some light on how situations that Spiro described could be avoided, namely how the tech industry is obsessing over developer experience and why that's detrimental, why abstractions should be teaching you the technology as opposed to just doing the work for you, why you should be able to train your junior devs and much more! Learn back-end development - https://boot.dev Listen on your favorite podcast player: https://www.backendbanter.fm Spiro's X/Twitter: https://x.com/spirodonfl Spiro's Website: https://spirofloropoulos.com/ Timestamps: 00:00 Intro 00:35 Why are we having this conversation 01:33 How was HTMX involved in this? 03:38 Spiro's background 05:58 Why are we focusing so much on developer experience? 13:38 The Tech Industry as a whole is headed down the wrong path 16:17 Abstractions teaching you about the underlying technology rather than hiding it 18:47 What are the long-term consequences of unresolved technical debt? 26:46 There's things you can't blame frameworks for 28:27 We have to slow down 30:46 What happened after the introduction of HTMX into the project? 40:26 Hiring juniors is great, but you should have the resources to train them 47:00 The Technical Debt 50:32 The more complex the feature became, the bigger the struggle with HTMX 53:42 The reasons why Spiro was let go 57:10 Instead of Agile we should treat our programmers like adults 57:31 HTMX was instant and testing ability was better 01:01:21 Is Spiro looking for work? 01:02:00 Where to find Spiro
On this episode, Sacha Greif, designer, developer, and entrepreneur, talks about the state of JavaScript in 2023 survey results. We discuss trends in the JavaScript ecosystem and the future of popular frameworks and tools. Learn about the challenges and innovations shaping the world of JavaScript today. Links https://stateofjs.com https://sachagreif.com https://github.com/sachag http://twitter.com/sachagreif https://jp.linkedin.com/in/sacha-greif We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understand where your users are struggling by trying it for free at [LogRocket.com]. Try LogRocket for free today.(https://logrocket.com/signup/?pdr) Special Guest: Sacha Greif.
Topics covered in this episode: Joining Strings in Python: A "Huh" Moment 10 hard-to-swallow truths they won't tell you about software engineer job My thoughts on Python in Excel Extra, extra, extra Extras Joke Watch on YouTube About the show Sponsored by ScoutAPM: pythonbytes.fm/scout Connect with the hosts Michael: @mkennedy@fosstodon.org Brian: @brianokken@fosstodon.org Show: @pythonbytes@fosstodon.org Join us on YouTube at pythonbytes.fm/live to be part of the audience. Usually Tuesdays at 10am PT. Older video versions available there too. Finally, if you want an artisanal, hand-crafted digest of every week of the show notes in email form? Add your name and email to our friends of the show list, we'll never share it. Brian #1: Joining Strings in Python: A "Huh" Moment Veronica Berglyd Olsen Standard solution to “read lines from a file, do some filtering, create a multiline string”: f = open("input_file.txt") filtered_text = "n".join(x for x in f if not x.startswith("#")) This uses a generator, file reading, and passes the generator to join. Another approach is to add brackets and pass that generator to a list comprehension: f = open("input_file.txt") filtered_text = "n".join([x for x in f if not x.startswith("#")]) At first glance, this seems to just be extra typing, but it's actually faster by 16% on CPython due to the implementation of .join() doing 2 passes on input if passed a generator. From Trey Hunner: “I do know that it's not possible to do 2 passes over a generator (since it'd be exhausted after the first pass) so from my understanding, the generator version requires an extra step of storing all the items in a list first.” Michael #2: 10 hard-to-swallow truths they won't tell you about software engineer job College will not prepare you for the job You will rarely get greenfield projects Nobody gives a BLANK about your clean code You will sometimes work with incompetent people Get used to being in meetings for hours They will ask you for estimates a lot of times Bugs will be your arch-enemy for life Uncertainty will be your toxic friend It will be almost impossible to disconnect from your job You will profit more from good soft skills than from good technical skills Brian #3: My thoughts on Python in Excel Felix Zumstein Interesting take on one person's experience with trying Python in Excel. “We wanted an alternative to VBA, but got an alternative to the Excel formula language” “Python runs in the cloud on Azure Container Instances and not inside Excel.” “DataFrames are great, but so are NumPy arrays and lists.” … lots of other interesting takaways. Michael #4: Extra, extra, extra Code in a castle - Michael's Python Zero to Hero course in Tuscany Polyfill.io JavaScript supply chain attack impacts over 100K sites Now required reading: Reasons to avoid Javascript CDNs Mac users served info-stealer malware through Google ads HTMX for the win! ssh to run remote commands > ssh user@server "command_to_run --arg1 --arg2" Extras Brian: A fun reaction to AI - I will not be showing the link on our live stream, due to colorful language. Michael: Coding in a Castle Developer Education Event Polyfill.io JavaScript supply chain attack impacts over 100K sites See Reasons to avoid Javascript CDNs Joke: HTML Hacker
En este episodio, descubre cómo HTMX simplifica la creación de aplicaciones web interactivas, añadiendo atributos que permiten realizar peticiones HTTP para obtener bloques de HTML que reemplazan contenido. --- Support this podcast: https://podcasters.spotify.com/pod/show/fernando-her85/support
This is a recap of the top 10 posts on Hacker News on June 17th, 2024.This podcast was generated by wondercraft.ai(00:33): FTC sues Adobe for hiding fees and inhibiting cancellationsOriginal post: https://news.ycombinator.com/item?id=40707558&utm_source=wondercraft_ai(02:04): How to get stuff repaired when the manufacturer don't wanna: take 'em to courtOriginal post: https://news.ycombinator.com/item?id=40702782&utm_source=wondercraft_ai(03:53): Htmx 2.0.0 has been releasedOriginal post: https://news.ycombinator.com/item?id=40709769&utm_source=wondercraft_ai(05:31): Trading cards with e-ink displays (2023)Original post: https://news.ycombinator.com/item?id=40705222&utm_source=wondercraft_ai(07:17): DJI ban passes the House and moves on to the SenateOriginal post: https://news.ycombinator.com/item?id=40705196&utm_source=wondercraft_ai(09:15): Being laid off and unplanned entrepreneurshipOriginal post: https://news.ycombinator.com/item?id=40704428&utm_source=wondercraft_ai(11:00): EU to greenlight Chat Control tomorrowOriginal post: https://news.ycombinator.com/item?id=40710993&utm_source=wondercraft_ai(12:30): “Attention assault” on FandomOriginal post: https://news.ycombinator.com/item?id=40711086&utm_source=wondercraft_ai(14:08): Understanding SPF, DKIM, and DMARC: A Simple GuideOriginal post: https://news.ycombinator.com/item?id=40708476&utm_source=wondercraft_ai(15:50): TDK claims solid state battery breakthroughOriginal post: https://news.ycombinator.com/item?id=40706164&utm_source=wondercraft_aiThis is a third-party project, independent from HN and YC. Text and audio generated using AI, by wondercraft.ai. Create your own studio quality podcast with text as the only input in seconds at app.wondercraft.ai. Issues or feedback? We'd love to hear from you: team@wondercraft.ai
In today's episode, we welcome Ken Wheeler, a dope programmer, who creates cool projects and just gives them away for free, helping thousands of developers worldwide, a based beatmaker and just in general a cool person. In this episode, we talk about AI, React, OCaml, why stressing over specific frameworks is not worth it, advice for new developers, HTMX, SPA's and a LOT of other stuff, so stay tuned! Ken's X/Twitter: https://x.com/ken_wheeler Timestamps: 00:00 Introduction 00:25 Do you hate AI? 02:10 How diffusion works 17:47 First impressions with writing Go 18:29 Where's the line between Backend Development and DevOps 24:11 Does anyone version their REST? 24:57 urql 25:38 Offloading the data work to the other side 29:55 Wordpress is 80% of the websites 31:15 HTMX 33:12 Single Page Apps 34:02 Is React still your go-to 36:38 Is it hard to switch from React to Vue? 39:37 Picking a first language to learn 40:43 OCaml 43:12 HEX and raw Binary Data 44:42 Bluetooth powered crossbow 52:20 What got Ken into doing talks 58:45 Where to find Ken
Bahaa Zidan says your web framework doesn't matter, DHH writes about magic machines, Dylan Huang reviews thousands of opinions on HTMX, Tim Ottinger says programming is thinking & Tim Spann says small language models (SLM) for the win.
Bahaa Zidan says your web framework doesn't matter, DHH writes about magic machines, Dylan Huang reviews thousands of opinions on HTMX, Tim Ottinger says programming is thinking & Tim Spann says small language models (SLM) for the win.
Bahaa Zidan says your web framework doesn't matter, DHH writes about magic machines, Dylan Huang reviews thousands of opinions on HTMX, Tim Ottinger says programming is thinking & Tim Spann says small language models (SLM) for the win.
Episode 68: In this episode of Critical Thinking - Bug Bounty Podcast Mathias is back with some fresh HTMX research, including CSP bypass using HTMX triggers, converting client-side response header injection to XSS, bypassing HTMX disable, and the challenges of using HTMX in larger applications and the potential performance trade-offs. We also talk about the results of his recent CTF Challenge, and explore some more facets of CDN-CGI functionality.Follow us on twitter at: @ctbbpodcastWe're new to this podcasting thing, so feel free to send us any feedback here: info@criticalthinkingpodcast.ioShoutout to YTCracker for the awesome intro music!------ Links ------Follow your hosts Rhynorater & Teknogeek on twitter:https://twitter.com/0xteknogeekhttps://twitter.com/rhynoraterProject Discovery Conference: https://nux.gg/hss24------ Ways to Support CTBBPodcast ------Hop on the CTBB Discord at https://ctbb.show/discord!We also do Discord subs at $25, $10, and $5 - premium subscribers get access to private masterclasses, exploits, tools, scripts, un-redacted bug reports, etc.Today's Guest:https://twitter.com/avlidienbrunnResources:Masato Kinugawa's research on Teamshttps://speakerdeck.com/masatokinugawa/how-i-hacked-microsoft-teams-and-got-150000-dollars-in-pwn2own?slide=33subdomain-only 307 open redirecthttps://avlidienbrunn.se/cdn-cgi/image/onerror=redirect/http://anything.avlidienbrunn.seTimestamps(00:00:00) Introduction(00:05:18) CSP Bypass using HTML(00:14:00) Converting client-side response header injection to XSS(00:23:10) Bypassing hx-disable(00:32:37) XSS-ing impossible elements(00:38:22) CTF challenge Recap and knowing there's a bug(00:51:53) hx-on (depreciated)(00:54:30) CDN-CGI Research discussion
Join Dan Vega and DaShaun Carter for the latest updates from the Spring Ecosystem. In this episode we sit down with special guest Wim Deblauwe who is the author of Modern Frontends with HTMX. This book focuses on using htmx with Spring Boot and Thymeleaf to build dynamic interactive web applications. This will be a great introduction for anyone curious about what htmx is and how to get started with it in Spring. Join our live stream to get your questions answered, or watch the replay on your preferred podcast platform.Show NotesWim Deblauwe websiteWim Deblauwe on TwitterTaming ThymeleafModern Frontends with HTMXSpring Boot and Thymeleaf Library for HTMXHTMX Discord
Join Dan Vega and DaShaun Carter for the latest updates from the Spring Ecosystem. This episode explores the evolving landscape of frontend development with Spring. Join us as we discuss Vaadin and Hilla, uncovering their capabilities and how they seamlessly integrate with Spring Boot applications. We'll also discuss popular template engines like Mustache and Thymeleaf, exploring their strengths and best practices for implementation. Additionally, HTMX is rapidly gaining traction and revolutionizing the frontend scene. Join our live stream to get your questions answered, or watch the replay on your preferred podcast platform.Show NotesRelease Calendar SpringOne CFPSpring Academy Learning Resources for SpringSpring Frontend Resources
Delve into a thought-provoking discussion with Owen Buckley, a seasoned web developer with 20 years of experience. Owen introduces Greenwood, a project focused on leveraging web standards and simplifying web development. Throughout the episode, They explore Greenwood's evolution, capabilities, and unique approach to application scaffolding and local development. From the emphasis on HTML and web components to Greenwood's seamless integration with HTMX, they uncover the project's vision to provide an onramp close to web standards. Join them as they navigate through the world of web development and gain valuable insights from Owen's expertise and passion for web standards and components.SponsorsChuck's Resume TemplateDeveloper Book ClubBecome a Top 1% Dev with a Top End Devs MembershipSocialsLinkedIn: Owen BuckleyPicksCharles - The White CastleOwen - Hypermedia SystemsBecome a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.
Show DescriptionWe're opening up the ShopTalk mailbag and answering your questions, including does WordPress on your resume kill your job chances, what are our fav and least fav parts of web dev, our thoughts on HTMX, and what is it like to use pnpm instead of npm. Listen on Website →Links Front End Happy Hour Playdate Develop for Playdate Nuxt: The Intuitive Vue Framework · Nuxt ThePrimeagen Fast, disk space efficient package manager | pnpm Yarn SponsorsRadical DesignAre you an aspiring designer, developer, marketer, or fanny pack tester? Maybe you're a burnt-out designer struggling for fresh ideas, or perhaps you have no idea where to start with design? Do you need to find a way to make your sites less boring and more memorable? Well then, this course is for you.
Avalonia XPF This episode of The Modern .NET Show is supported, in part, by Avalonia XPF, a binary-compatible cross-platform fork of WPF, enables WPF apps to run on new platforms with minimal effort and maximum compatibility. Show Notes Hateos allows you to add links to the actions you can perform with the data you're returning. So imagine a tweet and imagine, for example, just a links. It's just an object with some arrays. And one of the links could be a retweet link or like a favourite link or like a delete link. And each link contains a type, which is like the HTTP type, it contains the URL to where you perform this action, and it also contains like a name. So kind of human readable kind of name. So like like retweet, delete, stuff like that. —Sander ten Brinke Welcome to The Modern .NET Show! Formerly known as The .NET Core Podcast, we are the go-to podcast for all .NET developers worldwide and I am your host Jamie "GaProgMan" Taylor. In this episode, I spoke with Sander ten Brinke about HATEOAS and HTMX. These are two separate but complementary technologies which help to build reactive web applications. In fact, as Irina pointed out back in episode 2 of the current season (released on Sept 22nd, 2023), you're likely not building RESTful services if you're not doing HATEOAS. And HTMX is something, as you'll find out, which aims to simplify building HTML-based apps that utilise web-based APIs by taking care of the boilerplate JavaScript code that you might need to include, using a series of attributes that you can place on elements. So HTMX is in the principle, it's a JavaScript library, which you can use. So you can use it in your application to write a whole lot less JavaScript. Let's think back to the good old days, right, where we were writing, like, Web 1.0 applications and our servers were simply like, we're using HTML templating engines, which they still do. It worked and it worked fine, but it wasn't very interactive because then we kind of got to the point where we were like, we want to do some cool clients application, but we don't want to reload the page the entire time. And that is kind of where the SPA movement came along. We want to be able to have a rich interactive application where clicking a button or clicking multiple buttons, just a bit of the page refreshes, right? That's kind of the Web 2.0, I suppose. —Sander ten Brinke So let's sit back, open up a terminal, type in dotnet new podcast and we'll dive into the core of Modern .NET. Supporting the Show If you find this episode useful in any way, please consider supporting the show by either leaving a review (check our review page for ways to do that), sharing the episode with a friend or colleague, buying the host a coffee, or considering becoming a Patron of the show. Full Show Notes The full show notes, including links to some of the things we discussed and a full transcription of this episode, can be found at: https://dotnetcore.show/season-6/navigating-the-web-of-hateoas-and-htmx-unleashing-the-power-of-hypermedia-and-simplified-front-end-wizardry-with-sander-ten-brinke/ Useful Links HATEOS Chapter 5 Representational State Transfer (REST) of Roy Thomas Fielding's paper which introduced REST in 2000 HTMX munisio - Sander's HATEOS NuGet library riskfirst.hateoas Sander's blog post introducing munisio HTMX.NET HTMX for ASP.NET Core Developers Getting in touch with Sander: on Twitter: @SanderTenBrinke on LinkedIn his website Everything you need to know about configuration and secret management in .NET Supporting the show: Leave a rating or review Buy the show a coffee Become a patron Getting in touch: via the contact page joining the Discord Music created by Mono Memory Music, licensed to RJJ Software for use in The Modern .NET Show Remember to rate and review the show on Apple Podcasts, Podchaser, or wherever you find your podcasts, this will help the show's audience grow. Or you can just share the show with a friend. And don't forget to reach out via our Contact page. We're very interested in your opinion of the show, so please get in touch. You can support the show by making a monthly donation on the show's Patreon page at: https://www.patreon.com/TheDotNetCorePodcast.
We welcome back Carson Gross, creator of HTMX, to talk about the upcoming release of HTMX v2 and all its new features and updates. Links https://bigsky.software https://www.linkedin.com/in/1cg https://github.com/bigskysoftware https://twitter.com/htmx_org We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket combines frontend monitoring, product analytics, and session replay to help software teams deliver the ideal product experience. Try LogRocket for free today. (https://logrocket.com/signup/?pdr) Special Guest: Carson Gross.
Scott and Wes welcome HTMX creator Carson Gross to discuss the versatile applications and optimal scenarios for using HTMX, alongside insights into its creation and evolution. Join us as we explore the future prospects and improvements as we look towards HTMX 2.0. Show Notes 00:00 Welcome to Syntax! 00:52 Brought to you by Sentry.io 02:22 Who is Carson Gross? BigSkySoftware GitHub BigSkySoftware 03:53 What exactly is HTMX? htmx.org htmx.org/examples 07:04 What made you want to create something like HTMX? intercooler.js 10:01 Would HTML look more like HTMX if we were to rebuild it today? 12:54 Isn't HTMX a step backward into old-school AJAX? 16:09 When would you avoid using HTMX? 17:56 Does HTMX put an unnecessary load on the server? 21:46 What are your thoughts on rendering everything on the server? 26:29 What is your favorite stack? 28:49 Things that are lost moving to the JavaScript framework world. 30:16 HTMX coupling your front end and back end. 32:28 How do you feel about web components? 33:40 What are the big templating engines and your top pick? HTMX Essays 36:33 Object-oriented HTML. 37:38 Is there an offline story or a “local-first” story for HTMX? 38:44 What does the future of HTMX look like given its rise in popularity? 40:03 HTMX and X (Twitter). Syntax Show 726 HTMX on X 42:30 The Microsoft story. 45:26 Carson's thoughts on de-escalating the language around HTMX. 47:44 Sick Picks + Shameless Plugs. Sick Picks Carson: AlpineJS, Datastar Shameless Plugs Carson: Hypermedia Systems, HTMX Swag 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
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
Is the Virtual DOM Bad? Are keyboard shortcuts important? What is S3 storage? In this potluck episode of Syntax, Wes and Scott answer your questions. Show Notes 00:08 Welcome 01:27 Syntax Brought to you by Sentry.io 02:45 Welcome Randy, our new Producer! Randy's YouTube 04:14 A ‘Canadian Podcast' 04:43 Is Alpine JS or HTMX a replacement for pug or other templating libraries? 08:21 What powers the “in-app” browsers and how can we test our sites on it? Inject tracking code Tauri 13:16 A deep dive on generators and iterators. An Insight into Iteration Protocol through Infinite Scroll in Angular 15:25 Video podcast observations 17:18 PROBLEM I need a way of managing state. 22:34 Why is Virtual Dom (a la React) suddenly bad? 28:31 In a recent episode (659), Wes mentioned he updated the OG image cards, and noticed a higher click through rate. 29:07 Updated logo and monster truck intro. 30:19 Back to OG Images. 31:51 Are “import * as X” exports build stripped? 36:46 What is the difference between S3 storage and a CDN. Backblaze CDN 45:00 How important are keyboard shortcuts or extensions? Are they necessary to be a good developer? 50:04 Sick Picks + Shameless Plugs Sick Picks Scott: Perplexity.ai, Serversideup Wes: Zojirushi Rice Cooker Shameless Plugs Wes: Wes Bos Courses Scott: Sentry Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Randy: YouTube Scott: X Instagram Tiktok LinkedIn Threads
HTML All The Things - Web Development, Web Design, Small Business
Three web development topics grace this episode's contents as Matt and Mike discussed the seemingly never ending tech layoffs that keep making headlines. The guys also discussed HTMX, a lightweight UI library that has taken off in popularity recently to the pleasure of some and dismay of others - is HTMX the "Tailwind CSS" of backend technology? Finally the guys discussed how to handle your family and friends approaching you with their ideas and wanting you to work on them. We've all been there, you're at a family gathering, and someone wants to work with you on their new idea that's sure to "take the world by storm" - or in a twist, sometimes they just want you to be their mentor...what do you do if you just don't have the time? Thanks to this episode's sponsor Magic Mind. Use our link (https://www.magicmind.com/JANhtml) and promo code (HTML20) for up to 75% off in January 2024! After January? Our code is still good for up to 20% off! Show Notes: https://www.htmlallthethings.com/podcasts/more-tech-layoffs-htmx-is-real-friends-with-ideas Scrimba Discount: https://tinyurl.com/ScrimbaHATT
Talk Python To Me - Python conversations for passionate developers
Are you considering or struggling with replacing much of the interactivity of your Django app with frontend JavaScript frameworks? After all, your users do expect an interactive and modern app, right? Before you make a rash decision, you owe it to yourself to check out HTMX. It goes well with Django. We have Christopher Trudeau to run through a whole awesome list of HTMX and Python and tell us about his new HTMX + Django course. Links from the show Chris on ExTwitter: @cltrudeau Django in Action book: manning.com Django: djangoproject.com HTMX + Django course: talkpython.fm HTMX: htmx.org awesome-htmx: github.com awesome-python-htmx: github.com django-js-lib-htmx: github.com htmxflask: github.com fastapi-sse-htmx: github.com django-htmx-patterns: github.com jinja2-fragments: github.com jinja_partials: github.com chameleon_partials: github.com django-render-block: github.com flask-htmx: github.com htmx-flask: github.com asgi-htmx: github.com hx-requests: github.com django-dashboards: github.com A Real World React -> htmx Port: htmx.org 3 IRL use cases for Python and HTMX: bitecode.dev owela-club: github.com Watch this episode on YouTube: youtube.com Episode transcripts: talkpython.fm --- Stay in touch with us --- Subscribe to us on YouTube: youtube.com Follow Talk Python on Mastodon: talkpython Follow Michael on Mastodon: mkennedy Sponsors IRL Podcast Sentry Error Monitoring, Code TALKPYTHON Talk Python Training
Talk Python To Me - Python conversations for passionate developers
Have you heard of Django? It's this little web framework that, well, kicked off much of Python's significance in the web space back in 2005. And that makes Django officially an adult. That's right, Django is now 18. And Django continues to lead the way on how community should be done for individual projects such as web frameworks. We have Carlton Gibson and Will Vincent back on the show this episode to discuss a bit of the Django history, Django trends in 2023, a little HTMX + Django, and lots more. Links from the show Guests Will Vincent: wsvincent.com Carlton Gibson: @carlton@fosstodon.org Button.dev: btn.dev Learn Django: learndjango.com Django News: django-news.com Yak-Shaving to Where the Puck is Going to Be Talk: youtube.com Open Source for the Long Haul: fosstodon.org Django 4.2: docs.djangoproject.com Django 5: docs.djangoproject.com Environs: github.com Neapolitan: github.com Django Template Paritals: github.com Jinja Partials: github.com Django Chat Podcast: djangochat.com Locality of Behavior Essay: htmx.org HTMX: htmx.org You're Fullstack Now Meme: twitter.com Deployment Checklist: docs.djangoproject.com Django-HTMX: github.com Django @Instagram DjangoChat: djangochat.com Talk Python HTMX Course: talkpython.fm Watch this episode on YouTube: youtube.com Episode transcripts: talkpython.fm --- Stay in touch with us --- Subscribe to us on YouTube: youtube.com Follow Talk Python on Mastodon: talkpython Follow Michael on Mastodon: mkennedy Sponsors Sentry Error Monitoring, Code TALKPYTHON Talk Python Training
© 2020-2025 Ivy Podcast Discovery LLC
