A first look at Remix 3 🔗 **Source:** [A first look at Remix 3](https://www.youtube.com/watch?v=_STrAAi8Ujg) > [!note]+ Document Notes > tags: [remix, javascript-frameworks, full-stack, web-platform] > author: Syntax > source: YouTube > reference: https://www.youtube.com/watch?v=_STrAAi8Ujg > date created: 2024-12-19 14:30 > > # 🏷️ Title: A first look at Remix 3 > <!-- deep-read:sections start --> ## 🧰 Action Inbox - [H1] Test manual rerendering approach — practical evaluation needed #framework-evaluation - [H2] Explore event-based architecture patterns — compare with current React patterns #architecture - [H3] Evaluate standards-based approach — assess migration feasibility #technical-assessment ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [Remix Framework](https://remix.run) - [Syntax Podcast](https://syntax.fm) ## 📝 Summary - Remix 3 is a complete departure from React, built as a standards-based full-stack JavaScript framework - Uses web platform primitives like events, signals, and standard APIs instead of React-specific abstractions - Features manual rendering, event-driven architecture, and JSX/TSX templating without React dependency - Aims to be "LLM-ready" and allows bringing your own libraries without framework-specific wrappers - Still in early development with Ryan Florence and Michael Jackson leading the redesign ## 📖 Main Content Remix 3 represents a radical shift from the React-based Remix framework to a completely new full-stack JavaScript framework built on web platform standards. The framework abandons React entirely, instead leveraging native browser APIs like events, signals, web streams, and fetch. The core philosophy centers on using platform primitives rather than framework-specific abstractions. Components are written in JSX/TSX but don't use React's reconciliation. Instead, they use manual rendering where developers explicitly call `this.render()` when updates are needed. State is stored in regular JavaScript variables rather than reactive systems. The event-driven architecture extends JavaScript's native event system, allowing components to dispatch and listen for custom events that bubble through the DOM. This enables loose coupling between components and supports complex interaction patterns without framework-specific state management. The framework maintains full-stack capabilities with standard Web Request/Response APIs that work across different JavaScript runtimes (Node, Deno, Bun, Cloudflare Workers). Routing is configuration-based rather than file-system based, using the URL Pattern API for route matching. ## 🗒️ Notes #### ⏱️ [00:00](https://www.youtube.com/watch?v=_STrAAi8Ujg?t=0) — [H1] Remix 3 Introduction and Conference Context - Key idea: Remix 3 completely abandons React for a new standards-based approach - Evidence: "It's no more React. It's this brand new thing that they've thought up. It's full stack." #### ⏱️ [02:30](https://www.youtube.com/watch?v=_STrAAi8Ujg?t=150) — [H2] Platform-First Philosophy - Key idea: All features built on web platform primitives rather than custom abstractions - Evidence: "All of the features of Remix are things that are built into the web platform. Namely events is probably the biggest one" #### ⏱️ [04:15](https://www.youtube.com/watch?v=_STrAAi8Ujg?t=255) — [H3] LLM-Ready Design Principles - Key idea: Framework designed to be easily understood and generated by AI tools - Evidence: "A lot of the features are just vanilla JavaScript at the end of the day. So, an LLM is very easily able to generate code that looks like this" #### ⏱️ [06:45](https://www.youtube.com/watch?v=_STrAAi8Ujg?t=405) — [H2] Component Model and JSX Usage - Key idea: Uses JSX/TSX without React dependency, leveraging existing tooling - Evidence: "All of your tools that use TypeScript or TSX or JSX, they will just automatically work" #### ⏱️ [08:20](https://www.youtube.com/watch?v=_STrAAi8Ujg?t=500) — [H1] Manual Rendering Approach - Key idea: State uses regular variables with explicit render calls instead of reactivity - Evidence: "State is simply just variables. If you want to store some data in a component, you simply just create some variables" #### ⏱️ [10:30](https://www.youtube.com/watch?v=_STrAAi8Ujg?t=630) — [H2] Function Structure and Execution Model - Key idea: Components return functions that return JSX to avoid re-execution issues - Evidence: "The function doesn't return JSX. It returns a function that returns JSX" #### ⏱️ [12:45](https://www.youtube.com/watch?v=_STrAAi8Ujg?t=765) — [H1] Event-Based Architecture Foundation - Key idea: Everything built on JavaScript's native event system with custom events - Evidence: "Everything in Remix is based on an event which is a JavaScript primitive being an event target" #### ⏱️ [15:20](https://www.youtube.com/watch?v=_STrAAi8Ujg?t=920) — [H2] Event Target Extension Pattern - Key idea: Classes extend EventTarget to create typed, composable interaction logic - Evidence: "This is a class called podcast player and it extends event target" #### ⏱️ [18:10](https://www.youtube.com/watch?v=_STrAAi8Ujg?t=1090) — [H2] Type-Safe Context System - Key idea: Context provides type safety without triggering cascading re-renders - Evidence: "You can simply just put it on context and then you can access it by this.context.get" #### ⏱️ [20:30](https://www.youtube.com/watch?v=_STrAAi8Ujg?t=1230) — [H3] Composable Event Interactions - Key idea: Events can be composed and wrapped for reusable interaction patterns - Evidence: "You can compose your interaction logic in their own events" #### ⏱️ [22:15](https://www.youtube.com/watch?v=_STrAAi8Ujg?t=1335) — [H2] Abort Signals for Async Operations - Key idea: Uses web platform AbortSignal for canceling async operations - Evidence: "They're all using this idea of abort signals which is something that's built into the platform" #### ⏱️ [24:45](https://www.youtube.com/watch?v=_STrAAi8Ujg?t=1485) — [H1] Server-Side Standards Implementation - Key idea: Server uses standard Web Request/Response APIs across all runtimes - Evidence: "The server side is standard web request and web response. It's the same code that you would write in a Cloudflare worker" #### ⏱️ [27:20](https://www.youtube.com/watch?v=_STrAAi8Ujg?t=1640) — [H2] Frames for Async Components - Key idea: Frames provide URL-based async components with fallback support - Evidence: "Every single component in your application has a URL and all of the data for that URL can be sent" #### ⏱️ [29:30](https://www.youtube.com/watch?v=_STrAAi8Ujg?t=1770) — [H2] Configuration-Based Routing - Key idea: Explicit route configuration instead of file-system based routing - Evidence: "It's a code-based router so there's no more file system-based routing" ## 📚 References - [Remix Framework](https://remix.run) - [Web Platform APIs](https://developer.mozilla.org/en-US/docs/Web/API) - [URL Pattern API](https://developer.mozilla.org/en-US/docs/Web/API/URL_Pattern_API) - [EventTarget API](https://developer.mozilla.org/en-US/docs/Web/API/EventTarget) ## 🗣️ Paraphrase - Remix 3 completely abandons React in favor of a new framework built entirely on web platform standards like events, streams, and native APIs - The framework uses manual rendering where developers explicitly call render methods instead of relying on reactive systems that automatically update - An event-driven architecture allows components to communicate through native JavaScript events that bubble through the DOM, enabling loose coupling and composable interactions ## 📰 Newsletter **Remix 3: A Bold New Direction for Full-Stack JavaScript** The Remix team has unveiled a radical departure from React with Remix 3 - a completely new full-stack framework built on web platform standards. Instead of React abstractions, it leverages native browser APIs like events, signals, and web streams. Key innovations include manual rendering (you call `this.render()` explicitly), event-driven architecture using native JavaScript events, and standard Web Request/Response APIs that work across all JavaScript runtimes. Components use JSX/TSX but without React dependency. The framework emphasizes "bring your own" philosophy - use any library without framework-specific wrappers. It's designed to be "LLM-ready" with vanilla JavaScript patterns that AI can easily understand and generate. While still in early development, Remix 3 represents a fascinating experiment in leveraging web platform evolution rather than abstracting over it. Resources: [Remix Framework](https://remix.run), [Web Platform APIs](https://developer.mozilla.org/en-US/docs/Web/API), [Syntax Podcast](https://syntax.fm) ## ✅ Action Items #### DevRel - Developer advocacy: Create comparison guides between Remix 3 and existing frameworks - Education: Develop workshops on event-driven architecture patterns - Developer experience: Document migration paths from React-based applications - Developer marketing: Highlight standards-based approach in developer communications - Community management: Gather feedback on manual rendering vs automatic reactivity #### Community - Maintainers: Evaluate framework for potential adoption in community projects - Contributors: Explore contributing to early-stage framework development - Ecosystem: Assess compatibility with existing JavaScript tooling and libraries ## 🧪 Hypotheses - Manual rendering will reduce unexpected re-renders but increase developer cognitive load - Event-driven architecture will improve component decoupling but may increase debugging complexity - Standards-based approach will improve long-term maintainability and cross-runtime compatibility - LLM-friendly design will accelerate adoption among AI-assisted development workflows ### 📊 Methodology - Build prototype applications comparing manual vs automatic rendering performance - Conduct developer experience studies with React developers learning Remix 3 patterns - Benchmark performance across different JavaScript runtimes using standard APIs ### ❓ Questions - How will the community adapt to manual rendering after years of reactive frameworks? - What debugging tools will emerge for event-driven architecture patterns? - Can the "bring your own" philosophy maintain coherent developer experience at scale? ### 🔮 Future Research - Long-term maintainability of manually managed rendering in large applications - Performance implications of event-driven architecture vs traditional state management - Integration patterns with existing React codebases during migration periods ### 💡 Implications - Practice: Developers need to rethink state management and component communication patterns - Education: Training materials must emphasize web platform APIs over framework abstractions - Tooling: Development tools need updates to support event-driven debugging and manual rendering - Ecosystem: Library authors may need to provide framework-agnostic versions leveraging web standards ### 🧠 Learning Styles Assessment Reading level estimate: 12th Grade (technical framework discussion) #### 👀 Visual learners - Present: Code examples and architecture diagrams - Improve: Component lifecycle visualizations, event flow diagrams #### 🔊 Aural learners - Present: Podcast format with detailed explanations - Improve: Audio examples of event patterns, pronunciation guides #### 🗣️ Verbal learners - Present: Detailed comparisons with React, clear terminology definitions - Improve: More analogies to familiar web platform concepts #### 🧩 Kinesthetic learners - Present: Code examples that can be typed and modified - Improve: Interactive demos, step-by-step migration guides #### 🧠 Logical learners - Present: Clear architectural reasoning, systematic feature breakdown - Improve: Decision trees for choosing between patterns #### 🧑‍🤝‍🧑 Social learners - Present: Community discussion format, multiple perspectives - Improve: Collaborative coding examples, peer comparison activities #### 🧘‍♀️ Solitary learners - Present: Comprehensive individual explanation - Improve: Self-assessment questions, independent exploration prompts #### 🌿 Naturalistic learners - Present: Evolution from React ecosystem to web platform - Improve: Ecosystem thinking about framework lifecycle ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear headings and structure in discussion - Improve: Alt text for any visual code examples #### Keyboard navigation - Present: Standard podcast/video controls - Improve: Timestamped navigation options #### Contrast and readability - Present: Clear audio in podcast format - Improve: High-contrast code examples in show notes #### Media and captions - Present: Audio content available - Improve: Auto-generated captions, transcript availability ### 🌍 DEIB Assessment #### Cultural breadth - Present: Technical discussion accessible to global developer community - Improve: Examples from diverse development contexts #### Inclusive language - Present: Generally inclusive technical terminology - Improve: Avoid assumptions about prior React experience #### Neurodiversity support - Present: Structured discussion with clear topic transitions - Improve: More frequent summaries, consistent pacing #### Representation - Present: Focus on technical merit over individual personalities - Improve: Acknowledge diverse developer backgrounds and constraints ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Framework design principles logically follow from web platform capabilities - Inductive strength: Examples demonstrate broader patterns effectively - Causal reasoning: Clear connections between design decisions and outcomes - Analogical strength: Good comparisons with existing frameworks #### Fallacies - Appeal to novelty: Some emphasis on "new" approaches without full evaluation - Hasty generalization: Limited examples used to support broad claims about developer experience #### Tone of voice - Overall tone: Enthusiastic but measured, acknowledging uncertainties and limitations ### 🛡️ DARVO Analysis - Deny: No concerning denial patterns observed - Attack: No attacks on individuals or groups - Reverse victim/offender: No victim/offender dynamics present - Emotional cues and rhetoric: Positive technical enthusiasm without manipulation ## 🎯 Conclusion Remix 3 represents a bold experiment in building modern web frameworks directly on web platform standards rather than abstracting over them. While the manual rendering approach and event-driven architecture may require significant developer mindset shifts, the standards-based foundation offers compelling advantages for long-term maintainability and cross-runtime compatibility. The framework's early stage means many questions remain about developer experience at scale, but the core philosophy of leveraging platform evolution rather than fighting it deserves serious consideration from the JavaScript community. ## 🧱 Refactor Appendix ### 📚 Literature Split Pad ### [H1] Manual rendering reduces unexpected updates > [!quote] [A first look at Remix 3](https://www.youtube.com/watch?v=_STrAAi8Ujg) by [[Syntax]] via [[YouTube]]. Published 2024. Accessed 2024-12-19. > "Nothing is reactive. You simply just when you want to explicitly render you call this." Addresses React's cascading re-render problems through explicit control. [view highlight](https://www.youtube.com/watch?v=_STrAAi8Ujg#H1) #xref #articleseed ID:rw_001 ### <!-- deep-read:sections end --> ## 📺 Video  --- # 📄 Full Transcript *Auto-generated from YouTube captions · timestamps roughly every 30 seconds · [watch on YouTube](https://www.youtube.com/watch?v=_STrAAi8Ujg)* **[00:01]** Welcome to Syntax. Today we're talking about Remix 3. I went to Remix Jam, which was their conference in Toronto on Friday, and they gave us a CD, which is wild, with a demo on it. Um, and it was a fantastic conference, and basically what they did is they showed us what Remix 3 is going to be. So, it it's no more React. It's this brand new thing that they've thought up. It's full stack. We're going to try to explain all **[00:32]** of the little bits of it today here. We're not going to go super in-depth. Like Ryan and Michael had I don't know probably like 4 hours on stage and they still didn't get to the entire framework. So, I'm not going to get into every little little bit of it, but I do hope to sort of explain to you the angle and the ideas behind it. And then we're going to have Ryan and Michael on in a coming episode to to talk a little bit more about like why do they do things and and what are the what's the **[01:02]** component model look like and and why XYZ, you know, all the all the nitty-gritty. So just as like like a background, Remix was a full stack React framework and a lot of those features or almost all of those features have moved back into React Router and and Remix as you know it is essentially gone. Um, and it's been reincarnated as a new full stack framework that has has nothing to do with React other than a lot of the **[01:34]** ideas that they have are because they are fed up and frustrated with the state of the React ecosystem and that a lot >> Yeah. And a lot has changed since React has has sort of been rolled out. So they kind of like peeled it back and said like what would a simple dead nut simple JavaScript full stack framework look like if we were to design it from scratch today and I'm pretty **[02:04]** excited about it. So should we should we get into explaining how it all works? >> Let's do it because I'm curious. I'll tell you what, there's so much happening. I like I saw all the remix stuff and I'm sure I like many other people saw the remix stuff and were like, "Okay, that's happening." And just like I I was unable to keep up with it. I have seen the syntax back and forth between uh Ryan and the React team on Twitter. I have seen some of that conversation. The syntax to me, like **[02:37]** first glance, feels a little over, but like I'm I'm interested to to learn why and like what it is and how it works and the reasoning behind it all cuz I am totally out to lunch on this. >> That's that's what I'll I'll I'll encourage anybody listening, you probably people have written mean comments already in the replies. >> I don't say anything. honestly >> of but like it's very hard like I can't imagine them trying to explain everything and and the reasoning behind it in four hours and then you just have **[03:08]** one screenshot of uh some code on the page and >> and you get like a quick snap judgement ah it looks like react with extra steps you know >> that's that's what I thought but I didn't say it I'll say that because I'm smarter >> so first of all remix 3 is uses the platform meaning that all of the features of Remix are things that are built into the web platform. Um, namely events is probably the biggest one that we have here. um signals which we'll **[03:40]** talk about that the backend web streams web request web response fetch um state all of the stuff is built with browserbased uh or not even browser based JavaScript native features which I am a huge fan of because I'm I'm a huge fan of vanilla and I've written my own like little abstractions on top of vanilla in the past but they've never been like amazing. It's usually just because I'm I'm building an app and I I need a **[04:10]** little bit of extra stuff on top. Um, but this is just like fully thought out. So, Remix 3, it's full stack like and and I mean like fully full stack. Um, it's got a whole component model built in. It has a router built in. They're building an entire >> uh component library. Uh, I like that. Which, yeah, something similar to like like a Shad CN or something where they have a whole designer on staff, so they're actually going to look good. >> It's all based on HTML, CSS. Obviously, **[04:42]** they have a full server side to it as well. So, mutations, partial rendering of different parts. Um, a lot of handy helpers for things that you commonly want to do like stream in files. It's all LLM ready, which is something that I predicted, meaning that >> a lot of the features, like I'm just this morning I was just going through I had to literally take the demo off of the CD for me to use it. >> A lot of the features are just like **[05:14]** >> they're just v it's just vanilla JavaScript um at the end of the day. So, an LLM is very easily able to to generate code that looks like this because it's not a lot of custom APIs. And a lot of the custom APIs they do have are are very thin layer on top that are either make things a little bit easier, you know, like every time you have to like send HTML as a response from like a web response. If you ever used a Cloudflare worker and you have to return HTML, you know, like, oh, this is annoying. I have **[05:45]** to set the headers and everything like that. like just little convenience methods or they do things so that they are fully [music] type safe all the way through. And if you want to see all of the errors in your application, you'll want to check out Sentry at centry.io/sintax. You don't want a production application out there that well, you have no visibility into in case something is blowing up and you might not even know it. So head on over to centry.io/sax. Again, we've been using this tool for a long time and it totally rolls. All **[06:16]** right, >> my predictions. So, previously my predictions were and I thought I would go through them. I would say that it's an LLM first. I I was predicting the reason I predicted that is because I thought that Shopify needed some sort of framework that you could boop boop boop into the box and it would kick out like a a Shopify theme. I don't know that that it is LLM first. It can write this code very well. I I was doing it this morning. Um I don't know that this was specifically made for Shopify though. I **[06:48]** think I was wrong on on that regard. I bet Shopify will use it, but I I had thought more that this is Shopify needs something. Um and I think that this is more of a Shopify just cares about tech, so they're just funding these guys to build cool tech. [sighs] >> Um it's all standard space. Nailed it there. Um no build. I thought Ryan was talking about no build like the entire time, you know, like just use ESM, you don't need like live reloading, you don't need any of this blah blah blah. **[07:20]** That doesn't really seem to be the case. You can do this stuff with no build, but but really like I'll say it right now, there's there's TypeScript, there's TSX for templating it out. There's not a custom templating language that I thought they were going to have. There's full server support for all of it. So, you're very likely gonna need some sort of build tool, which I was relieved to see. >> Yeah, I I listen, build tools don't bother me, so that doesn't crush me. Standards based is huge plus for me. I **[07:51]** really like refuse to use anything that's just abstracting the platform these days. Just >> just ref I mean like >> like meaningfully abstracting it cuz like that's I've resisted saying spelt this whole time. But the thing that drove me to spelt in the first place was that there is no there is a spelt ecosystem but it is the web ecosystem. I can drop in >> any DOM manipulation library and not have to worry about a wrapper for it. So, >> exactly. A lot of the frustration in the **[08:22]** ecosystem right now is that React has a lot of custom APIs and if you want to do anything in the React way, you either install something or you have to do it, you have to make some weird use effect or or whatever. And I'm partially fine with that just cuz I understand how it works. But also it's very refreshing when when you don't have to know how some weird thing works because it's just just a web API, right? And and spell has done a fantastic job at that. **[08:53]** >> So >> yeah, and the browser API is not going to shift on you like if React comes out with a new version. Uh you have to wait for, you know, React form that works with React 19 whatever uh with their new APIs. We're like the web platform's not changing, folks. It's It's getting better, but you know, it's not changing. >> Mhm. So, let's talk about the component model. So, the components in Remix 3 are written in TSX or or JSX. They don't have to be similar to how you don't have **[09:24]** to use JSX in React. But >> yeah, >> most people will will be doing that. And I was really happy to see that because that what that means is that >> first of all, I'm comfortable in in JSX pro. I'm just going to say JSX. And when I say that, I mean obviously using TypeScript as TSX, but then all of your tools that use TypeScript or or or TSX or JSX, they will just automatically work. So all of your llinters, all of your formatterers, all of your editor **[09:55]** tools, those things just work. AI is really good at at writing JSX at the end of the day. So there's no like new custom templating language that you're going to need to learn. state is simply just variables. [laughter] Get this. Uh if you if you want to store some data in in a component, you simply just create some variables and then those variables are then scoped to the component itself. Um and then probably the biggest **[10:25]** >> do they update reactively? Sorry. >> Curuffle that that's it. That is not reactive. That was the biggest curuffle. So if you have a variable and you throw it into your JSX somewhere, that will not reactively update. You have to explicitly call this. When you want your component to rerender. Um, and the sort of the thinking behind that is that React gets into these weird loops of things or you end up rerendering too often or you have something way up **[10:57]** higher in a a context tree and then you want to access that lower via context and you have to rerender the whole tree all the way down. Um, so this gets around that by nothing is reactive. You simply just when you want to explicitly render you call this. I want to get your thoughts on that before we dive into a little bit more of that. What are your thoughts immediately? >> My thoughts are that it would be nice if that was the API, but then there was **[11:31]** also a reactive state primitive. Um, >> you just took my next point out of the >> cuz that's how that's how spelt 5 works again. Sorry folks, I'm going to say it in this episode, but they have a reactive variable primitive. You get uh fine grain reactivity where you want it, but then if you're just defining normal variables, they're just variables. Uh, like Yeah. >> Yeah. So to add reactivity to this, like I was sitting there watching this being **[12:01]** like, I I don't know if I want to have to call it render every single time something changes. But there's nothing from stopping you from bringing in your own data store >> and and then just listening for changes on that data store and and passing it this render into the >> into the callback. So, somebody already hooked it up to to Xstate. Uh, or if you're using any of your your local um local first packages like like zero sync or whatever, >> there's that's a reactive data store and **[12:34]** then you can you can listen for all of those things. So, what is really cool about that is >> you don't have to use a specific state and you don't have to use a specific package that adapts to this. Yeah, you bring your own data store and then just pass it the render method. >> Another question is when when render calls it's rerunning that entire function like react. >> Yes. So what I'm showing on screen right here is >> a well it's it's it's only rerendering **[13:05]** >> this component. I'm not sure if it will rerender it all the way down the tree but >> but still like rerunning a function, right? Not like >> No, it's not. It's not. It's not. That's that was a good question. So, one of the things was >> I have this function here and if I put some code at the top of the function, >> when that whole thing rerenders, then all of that code at the top of the function also rerenders and then you get into this weird thing where if you add event listeners in there or something **[13:36]** like that, the function doesn't return JSX. it returns a function that returns JSX. So, meaning that all of the code inside of your component >> that is above the return is simply just called once um when that initial thing is is run and then the actual templating is is rerun when the render is called. So that's really nice where you don't have to do some weird use effect or or **[14:07]** have like safe mode or or any of this oddities. My most controversial webdev opinion, and I don't even know if this is controversial, is that like React developers or developers really buying into the entire function needs to rerun on every rerender is such a tremendous waste of time in terms of like how many foot guns or workarounds or things you have to consider just because the **[14:37]** function reruns every time. You have to then consider all of the things that happened when that rerun. Like if a variable changes, just update the stuff that affects that variable. >> You can have side effects that watch for that variable to change, but like why you got to rerun the whole thing? I never understood why people were like this is the way you have to rerun the whole function. Like that makes no sense to me. Yeah. >> And it's funny because like this is not a a weird API either. It's like the only difference is it's just you return a function instead of **[15:09]** >> returning JSX. [laughter] >> That's dope. [gasps] >> It just works. Yeah. So big fan of that. Now let's talk about probably the biggest idea here and that is this like whole eventsbased architecture. So >> everything in in Remix is based on a an event which is a JavaScript primitive which is a browser primitive being an an event target. So if you think about let let's peel this back. If you want to think about a like a button or any HTML **[15:40]** element in general, right? Those elements you can you can listen for events on them, right? You can grab a button, you can listen for a click on that event. And that button itself can also dispatch events um if they need to be custom, right? You can you can fire off custom events from an event target which which may or may not be an HTML element. And if you have not done that before, I I encourage you to look into dispatching custom events because it's **[16:10]** really nice. So what you can do is >> you can make some sort of like data store >> and and when the data in that data store changes or or when anything happens to your application you can simply just fire off events and those events will bubble up to all of the parent elements. know in the past I've I've made a hockey game and whenever whenever anybody scores or whenever the score changes or whenever the players change you can just fire off events saying like the score **[16:40]** has been updated the players have been changed and then and then other parts of your applications that necessarily care about those events happening you can simply listen for them and if you don't want them to bubble up even further you can stop propagation you can use the event default prevent default API um so events in JavaScript script and I know a lot of you know this but events in JavaScript are not just the bakedin ones you can make your own custom events and those events can also contain payloads of information about what happened you **[17:10]** know like event current element of or whatever element you click that's that's baked into to JavaScript but you can also just fire off a whole bunch of custom data with your event and anybody who wants to listen to that can >> yeah I love that I love that uh custom events man I I've been building a handful of utilities myself and custom components and stuff I use on every project. I don't know about you, but you collect these things that you just end up rewriting on every project. I'm like trying to formalize those into a package uh for myself. **[17:41]** >> And uh I did it first with my own like personal little CSS framework and now I'm doing it with a like standard space components, but custom events totally underrated, man. I've been using a lot of custom events and I love that stuff. So that's just that's so far all the event stuff I've been talking about that's just JavaScript, right? So the remix stuff is is based on that. It's it's built on top of custom events. So what happens is like for example I'm showing a fetch episode method that I've **[18:13]** created. Um this is a class called podcast player and it extends event target. Right? This is this has nothing to do with remix. This is simply a class that extends event target. And I've added a whole bunch of custom methods onto that. One of them being fetch episodes. And what that does is it hits the syntax API it JSON. And then when that data comes back, we are simply adding that episode to state by saying **[18:43]** this. Equals >> spread it. >> This I don't even need to spread it. I don't even know why I'm spreading it. That's a reactism. >> Push it. >> I could just push [laughter] it. That's how far I've got my brain rotted by React state because I immediately went to spread it rather than just using >> my mutation push. >> Mutating state is not a terrible thing, folks. No, >> it's easy. [laughter] >> You don't got to create new state every time. Yeah. >> So, that state of this.ep episodes has been been mutated. But because it is not **[19:14]** reactive um then I have to go ahead and dispatch an event which is a custom event that I've created called create list updated um and that is a new remix API called create event type um which again it's just a a thin layer on top of dispatch event that allows us to have fully typed um things so that that way when you're you're firing off events or listening for them you you know exactly what type of data you're getting cuz if you've ever used TypeScript and add **[19:47]** event listener, you know, there's all this BS around uh is type of, you know, you have to check if it's a specific type and it's kind of a pain. So that's the firing off of it. Um and then you can simply just go ahead in your UI. So the event target code, that's kind of like the logic and the the state of what is happening. And then in the actual UI, the component part of your remix application, you simply just listen. This is their own **[20:19]** addvent listener syntax here where you can listen for like something on document or something on player. In my case, I'm listening for player. And then you listen for specific events like a spacebar event or in my case, I'm listening for a list updated event. So when the player fires off a list updated event, then I'm going to go ahead and run this. And what that will do is it will update this component. And of course, you can you could do other **[20:50]** things in this regard as well. Now, you might be saying, okay, well, well, how do I now surface this state or this custom functionality to the rest of my application? Right? Do you have to pass things down? Is it all is it down via props? Um, you can simply just put it on context and then you can access it by this.context.get. Um, and that will not re-trigger. It's sticking things in context is is **[21:21]** awesome. I love it. But the only downside is that it it sucks for for having to trigger those cascading rerenders. Um, so in this case, you just go into a child component, which is just a function, grab the context, and then you can access all of the items that were on your your initial player. Um, you can listen for things in here as well. Do exactly what you want. >> Yeah. Um, and is that type safe? >> Yes. Yes. All it's it's type safe all **[21:53]** the way down. Um, I love that. And the reason why they do that is they have to use this the keyword this which a lot of people groaned at initially myself included. Um but if you here we go this one here remix.andle you pass it a generic of podcast player and then you can say this dot context do whatever and you you have access to all of your types all the way down. >> I love that man. context is because it it you have to be careful about renders **[22:24]** in React. I think it is becomes an underrated API. But um in in in spelt context is great for those reasons, but it's not type safe. So like you're like then casting when you put stuff into context in spelt. So like type safe, context, I don't care about this keyword. I don't care about that. I'll take that all day. Yeah. Um, another thing is you can you can like wrap up or you can compose your interaction logic **[22:54]** in their own events. So in this case they built a drum machine as their their sample. Um, and they just created a custom event called a tempo tap. And the logic of how does a tempo tap fire >> is is nice and tucked away into its own interaction. And all of the code as to how that happens is is tucked away into this thing called an interaction. And and now you can just simply import that tempo tap event and and listen for it on **[23:26]** each of them. There's also a whole bunch I'm not going to go too much into it, but you can also compose uh the events as well. So, if you have a third party library that has some events, but you want to add your own on top of that, you don't want to overwrite them, but you want to you want to listen to both, but maybe you want to stop propagation so it doesn't bubble up. um you can compose them together, which is really funny because Ryan and Michael were the guys who popularized the idea of high order **[23:57]** functions of like composable React components that stuck together and and here they are again doing it but now with with the with events. >> Yeah. Yeah. >> So that's like a a quick [snorts] run. I know that wasn't quick, but that's a high-level look at the whole event space architecture. We'll get Ryan on here to maybe do a better job at explaining all of it, but I want to move into some of the other parts of Remix as well. >> Yeah, do it to it. >> Signals. So, they they said we have **[24:27]** signals and everybody got really excited. Um, but they said not that kind of signals. Uh, so when you have an async operation, most likely the most common one is like like a fetch request. sometimes you want to like like abort um those specific things. So in in React you might need to like have some sort of cleanup function or you might need to to cancel it or or use something else. In Remix they're all using this idea of abort signals which is something that's **[24:59]** built into the platform. So if a component like maybe fires off a fetch request and then it's unmounted um you can give that abort signal to remix and it will simply just call it and abort that fetch request if that's that's what you want. So yeah again just another example of using the built-in uh methods that are built into the browser. benefits of standard. I wanted to to press on this a little bit is is that you can bring your own whatever you want and and they're not the first one to do **[25:30]** this, but like there isn't necessarily a remix way of of doing most of this stuff. So you can bring a library in from it could be a web component. They showed many examples with web components. You can bring a library for for whatever you want and it's just going to work. There's no weird oddities where oh I gotta stick this inside of a use effect and I gotta memoize it and >> right >> I I gotta I gotta have a ref for this thing, you know, like if if you want to remember something, **[26:00]** >> maybe you have to stick it in a ref so that when that function reruns, you're not overwriting it. No, it's just it's just variables. It's variables and properties and events all the way down, which means bringing your own whatever you want to bring your own reactive data store to this. You want to bring XATE, you want to you want to code up your own thing. It seems to be that you'll be able to do a lot of this. Bring your own whatever you want. Ah, that's all I want. That's all I want out of any framework these days. That's it. You **[26:32]** know, we got all these tools. >> Bring your own. Yeah. >> Yeah. Don't make me learn a new concept that is like specific knowledge, right? You know, >> talking real quick about CSS. The CSS can be done any way you want. However, they do provide a built-in CSS prop um that you can also do nested CSS inside of. So, if you do want to bring your own CSS or you want to put your own CSS in via a prop like this because **[27:03]** you're some sort of weirdo, I I quite honestly think that this is not a good way. [laughter] >> Yeah, I'm giving a big old thumbs down. Yeah, >> you can uh but it's there and and I think the benefit of that they said exactly that we didn't put this in because we think this is how you should do CSS. We put this in because somebody should be able to ship a remix component and you should be able to import it and it should just work. There shouldn't be some weird thing like how many times have you ever tried to import a date picker in React and you have to do this weird dance where you're trying to **[27:35]** import their CSS because you don't use the same bundler as them. You know, like the OpenAI's example, they released this like SDK the other day and they had an example with like a date picker and they simply just copy pasted all of the CSS into the example because there was no way to simply just import import the CSS and and inline it. This CSS though, what they're doing is very similar to Spelt where they're they're just generating a class that is like a unique class and then the **[28:07]** CSS applies. I was I was I thought they would maybe use scope CSS. >> It's not there yet. >> They're using the platform. Yeah. You think that's why? >> Yeah. That's why the spell team hasn't done it either. I like there that like when that is like fully available, it doesn't it doesn't exist in Firefox at all. So >> Oh, yeah. Okay. >> One day. >> This is like the eighth thing I've looked up this week that doesn't exist in Firefox. So, [laughter] >> uh let's talk about the server. So all of that was simply just the like the **[28:37]** front-end UI rendering part of things, but this is a full stack framework. Um, so I think Ryan did a lot of work on like the actual front end side of things. And then Michael, I've been watching his GitHub and he's been cranking out a lot of these like tiny little standards packages and and this is what it was for. It was the server side is standard web request and web response. Meaning that it's it's the same code that you would write in a Cloudflare worker. It's the same code that you would write in like a a HANAJS. **[29:09]** Um it doesn't use any specific Node.js APIs. So if you're using streams, you're not using Node Streams, you're using web streams, which of course works in Node, it works in Dino, it works in bun, works in Cloudflare workers, right? It works across the board. So everything that they've they've done has sort of like gotten rid of any node baggage that maybe you had and now it's all using these brand new APIs or not brand new but these new standard web APIs that **[29:39]** that work across um all of the runtimes. >> Very good. >> The server itself has a bunch of like handy methods for common CRUD operations. So if you want to post to a specific endpoint or you wanted to get from one um all all of the stuff that you would probably expect from like a like a hano or something like that, but then it's also it also is connected to your your front end. So um there's a bunch of handy things for working with **[30:11]** file uploads as well. Like it seems like it's a step further than than most stuff is going to be. You know, we've always talked about like where's the Rails or where's the Laravel of JavaScript, whereas like the the difference there being >> a lot of these JavaScript frameworks today will say okay here you can here's your request >> good luck. Um and what a Laravel or what a Rails would would do is they would provide a whole bunch of helpers around **[30:42]** this type of thing. Um, so this doesn't have anything to do with databases in terms of like a difference between like a Laravel or Rails, but it does provide a lot of like nice helpers for common things that you're going to do like simply just uploading files. If you have a file object in the browser and you send that file object from the browser to the server on the server it's a file object and it's the exact same thing that you would you would be expect to have and whatever you have to do to make it like multi-art and all all of that **[31:14]** fussing is is taken care of for you. So I'm pretty excited about all of those little cut edges um being taken care of. One thing frames. [laughter] So they they were teasing this idea of like I frames being the way to share code >> and I wasn't sure if they were were joking or not and it it turns out they were kind of half joking. So in most of these frameworks um like in React and React server components you have an **[31:45]** asynchronous component that may take some amount of time. it's server rendered a synchronous component that maybe it needs to fetch some data and then render out and kick it out, right? There's all this like and spelt has this now as well with their sync components where um you're not sure should I wait for this component or or should I show like a a rendering screen. So it seems to be the same idea is now in in Remix with this idea called frames. a frame receives a URL. Um, which is kind of nifty. Meaning that every single **[32:17]** >> like a like a component in your application has a URL and all of the data for that URL can be can be sent um all sorry all of the request details can be sent over a URL >> and then a frame can be client rendered can be server rendered it can have a fallback. So if if it's taking a little while, you can show a loader screen or you can decide not to. So that's kind of their take on doing this like a synchronous components that shouldn't necessarily **[32:48]** hold up the the rest of the website. >> I love the name. >> Yes, it's a it's a great name. I still have to like a lot of this code was like like very early, very rough, and a lot of this there's just not examples online just yet. So that's as well as I understand it right now. >> Yeah. >> Tooling. So I already mentioned it's JSX. Um it's ESM all the way down. So like they didn't mention anything about tooling in the talk. So I asked him **[33:20]** after him. So like like what were you using there? Obviously you you had some some bundler running to run this code. Um and Michael said it's just ESM all the way down. So, anything that can output ESM can be used um as long as as long as it can bundle it output. So, what I'm their demos are using ES build um to just regenerate it. You're going to need something on the server. If you're running Node like ESB build to **[33:51]** actually compile this stuff on the fly, like you have a request and and it's written in TypeScript, but you need to like bundle it when somebody sends a request, you're going to need ESB build on the server, or you could do it you could do it at at buildtime as well if if it's like a static site. But very likely you're going to need something like bun or Dino or ESB build and node running on your server. And very likely I think everyone's just going to be using VIT with all of this stuff. They didn't explicitly come out and say that **[34:22]** probably because they want to say like you can use whatever you want. If you want to make your own weird >> bundler, splitter, loader, whatever, you can do that. Um, but this is just ESM at the end of the day. Whatever tools you want to use for that. And very likely it's going to be most people probably just be using V to kick out ESM at the end of the day. >> Yeah. Yeah. For sure. For show. For sure. >> Routing. Um it's a codebased router so there's no more file systembased **[34:53]** routing. Um >> they had some interesting talks from Shopify before in the morning and Shopify was saying like we have thousands of routes and we don't even know what our routes are. And um I think that was to sort of tee up this whole like >> this is a config based routing it there the all of these routes are named meaning that you would you give each one a name and you can each one could have like a get and a post and and whatever. So, it's all of this stuff is **[35:24]** very explicit, whereas like you probably saw some of the screenshots and were like, you know, I don't like that. And there's there's no magic in any of this. >> Um, which I like a little bit of magic, but also I I like a little bit of explicitness. I find it very easy debug. Just being a couple hours in, it's easy to debug and to understand how everything works. Yeah, I'm caught between the world of loving a ton of magic and loving no magic. >> The constant **[35:55]** [laughter] >> push and pull. Yes, for sure. [gasps] >> Um, so questions or concerns? I my [clears throat] only concern is like will I like the manual rerendering and will I like the like data being stored on an object or will I will I like something more which my favorite right now is like what spelt has where you just create a data store import that thing when you want it export it where you don't want you make computed that's that's a very good approach to to data **[36:26]** um and will I like this more it's it's yet to be seen I'm not quite Sure. Is will the manual rerendering get annoying? Will people simply just put this render everywhere, >> right? >> Because they don't know they're tired. Yeah. I like I have I had a couple examples and I clicked it and nothing happened and I saw the data log in and I was like I'm missing a this render somewhere, you know, and like is it better to do something like spelt where spelt will just figure out which parts **[36:57]** to to update for you, you know, where it's actually reactive >> yet to be seen. Yeah. >> Will the community come up with a convention that ends up becoming the way? Like remember with Dino they were like no package.json and then what we had we ended up having like a deps.ts or whatever it was that basically functioned as a a package.json right like where the community is just like okay well we need one place to put this stuff. I do love the idea of uh non-file **[37:28]** system based routing. I gotta be honest. I think there's a lot of truth to I don't know what all my routes are when you're looking at a massive folder structure, right? Yeah. And when you have a routes file and you see it all there, I really liked that in React Router in the past. I did really like that where it felt very like I had a total handle on everything because yeah, you get nested directories, directory, you know, you can really lose track of that stuff. I think it also made like nested layouts really easy. not an X.JS **[37:59]** obviously but made nested layouts in any sane system and uh I I really like that approach. So the the one thing I forgot to say is the routing is based on the new URL pattern API which again this is a brand new the JavaScript now has a way to specify routes and like pattern match um built in. It's called the URL pattern API. And if you want to like like back in the Express days when you you wanted **[38:30]** to like be like, oh well the PDF on the end is optional or it could be PDF or CSV and um the ID was is always going to be there and then it maybe the for/edit will be optional, you know, like these very complex route URLs. I find myself when I hit those complex route URLs, I'm simply just adding multiple blank files in my directory structure where I simply just import the component and then export it right away. **[39:00]** >> So, yeah, we'll see. I I don't think we're using the URL pattern directly, Michael said, but all of the APIs are built on top of this um this spec, which again is a really good thing because it's built into the engine of these these runtimes and so it's going to be fast as hell. Hell yeah. You know what, folks? We're in a new world of JavaScript frameworks. I can just imagine there's going to be comments about LOL, another JavaScript framework, **[39:30]** yada yada yada. uh anytime we talk about anything new. But man, let's face it, like it's it's like these things the the browser APIs have gotten better. We've learned a ton of lessons. These things change all the time between this >> and Ripple and [clears throat] modern versions of other frameworks. We we are eating uh in terms of like excellent framework options, SolidJS, like >> there's there's a lot of great stuff. So like I I often get frustrated when people are like react one and react is **[40:02]** it that's the only way to do things. It's like there's there are different approaches that have different strengths and you might like >> who knows try it you might be that bird who ate a cracker and liked it meme. Um [laughter] >> I I think like like one more thing is that like this stuff seems very easy. Um, and and I think that's their target audience is like a lot of people who who think that React is just too hard. Um, and but they also don't want to have to relearn a new I'm saying **[40:36]** they don't want to relearn a new framework, but uh I guess you are kind of learning a new framework. >> You got if you got to call render that's a new framework to me. >> Yeah. Yeah. >> That's a different type of concept. >> It's it's a tricky thing. But like this maybe this will be the other like flip side of the coin is that like LLMs crank [snorts] out React all day long. And in some regards React has won because of that. So are they building something here that can both make us dummy **[41:09]** developers happy but also have the LLMs be able to understand and crank it out? To be seen, but I hope so. >> Yeah. Yeah. We'll see. Um, cool. Well, that's uh that's really exciting and and I'm I'm happy to hear that it is so standards focused. I I had full uh faith that those guys would really put out something worth talking about uh given their track record. So, do you want to get into sick picks, Wes? >> All right. Sick pick. I'm going to sick pick my dishwasher. Um our dishwasher **[41:41]** >> died after 21 years or 23 years old or something like that. It lasted a long long time and it finally uh killed itself and it no longer was I can't going to get banned. >> Unlived itself. Yes. >> Yeah. I was Okay, cut all that out. It finally died. So, we bought pretty much the exact same one. This is a We got a Bosch 800 series. And this thing is freaking awesome, man. It just like scrubs the dishes so super well. There's **[42:13]** three rows. It feels like somehow there's more space inside of it for all of the kids stuff. There's an app, which is a bit odd, but it's kind of nice because you can ask Google how long is left on the dishwasher cycle. >> That's pretty sick. >> Um, it's got the [clears throat] quick 60, which our old one didn't have. We love that feature where it's like, uh, I just need to run like a quick load and I don't want I want to wait around for two and a half hours. So, I got to be honest, Wes, that that uh that that quick load feature is like really super handy. Like there are there are so many **[42:45]** times when your dishwasher does not need a full cycle like straight up. Yeah. >> No, very rarely if you especially if you're like rinsing most of the crap off your plates as well, >> right? >> 60 is plenty. Um so I've been we were very happy with this thing. I I installed it the other day and uh it's it's better than the one that we had the Bosch that lasted before. So if you need a new dishwasher spring for a Bosch. It's like a little it probably like 1.5 times the cost of **[43:15]** like a an LG or whatever, but like let me tell you, we got >> we have a Samsung a brand new Samsung at our cottage and I've had that thing pulled out probably five times. I've replaced parts on it all the time. It's so frustrating. Ruined our cabinets at one point. It's just not worth getting a like a what saving 400 bucks on a dishwasher and buying a very crappy one. It's not worth it. >> Yeah. Shout out to Bosch. Uh >> we bought a we bought a Bosch at our at **[43:47]** our old house and was great. And our new house the dishwasher LG or something, right? LG or something just started leaking all over the floor and it was like ruined our hardwood. Wes actually has been to our house. We had to like resurface our entire floors >> and was really sad when it was like during CO and you couldn't get a Bosch dishwasher. It was like 12 months to get one or something. So, we had to go with a different brand. But, um, >> you get you got a Cove though, didn't you? Those are amazing. **[44:18]** >> Yeah, but we paid for it. >> Oh, yeah. >> They are amazing. And by all means, but it it was at an era where like we we didn't have a working dishwasher. I had been washing them by hand for months and I was we had, you know, the two two little kids and I was just like, you know what? We'll just shell out for the fancy dishwasher. It's the only one we can get right now. And uh yeah, I had my buddy do the same thing because he was just like, "Guys, I cannot find a dishwasher. What did you end up doing?" It's like, "Uh, we we wanted this fancy brand." Um, **[44:49]** >> but it's also very nice dishwasher. No complaints there, but Bosch is where it's at. Uh, I'm going to sick pick a Mocha device. I recently switched my Wi-Fi routers and I now have a wired the ability to have like a wired back haul in my network, but I don't have Ethernet throughout my house. And uh I got this Sunbeam Mocha, which they go up to 2.5 uh gigabit. So I have 1 GB network. **[45:19]** These go 2.5 GBs and over coax. And I just since like a 1990s house, you best believe there's coax in every single room [laughter] of this house. They're like, you need >> you're going to need TV in every room. Uh so we we have for our mesh network. I now have a fully wired back haul uh via coax and I was in the basement, which is like the furthest away, worst router. Um and we have so many things like uh on that router that just like the **[45:49]** internet's always chugging. And now I got 900 up and down from that router uh just because of the coax back haul. No problem. So >> it works that well. Hey, I always thought like Ethernet over like over power or Ethernet over coax. I'm like, yeah, I bet it's a pain and doesn't work as well. But you're you're getting full speeds 2.5. Yeah. You know what? I did not tr the speeds were so good. I did not trust the speed test on the router. I was like, is this running like the full mesh mesh speed test or is this running from this specific endpoint? And **[46:21]** it was that endpoint. So, like they didn't call it an endpoint, whatever they call it. Uh uh whatever that router was. So, yeah, man. Uh Mocha, sick. The stuff works. >> And it's what was it likeund I'm looking at it right now. >> The one I got is 130 bucks for a Oh, no. 119 bucks for a two pack. Oh, that's cheaper than a box of Ethernet core. You would have spent more um running wires. [laughter] >> Yeah. [gasps] >> Holy smokes, that's great. **[46:52]** >> I never thought that would work that well. Our house was >> wired with Cat 5 >> E. Yes. Our house is 20 years old and it's it's Cat 5, which you can get 10 gigabits on short runs and all of the runs in our house are short enough that they fall into that. So, I was so happy because I didn't refish. That's great. >> Cool. Imagine doing underground. No thanks. >> All right. If you've got questions about remix, put them in the booply boop down **[47:23]** there and when we have Ryan and Michael on, we will be sure to ask them. Peace.