Searchable transcript of Web dev is finally healing — Awesome (09:53). Search for a phrase, then click its timestamp to jump straight to that moment in the video.
Captions sourced from the original video on YouTube, published by Awesome. The video, its captions and all related intellectual property remain the property of their respective owners; AINotes claims no ownership. Provided for research, accessibility and search — see the Transcript Notice and Copyright Policy.
00:00 If I'm being honest, I'm in a full AI fatigue mode, especially since this is how my managers are reacting whenever I want to handwrite some code these days. >> You don't have future here. You don't have future. You can never make You can never make it. >> But today, we can enjoy an AI-free video and celebrate some good news from the web development world.
00:16 So, this is a great Monday morning. It's not often that we get major updates from both what I consider the best front-end framework and the JS library loved by every Java back-end developer who can't write a line of front-end code without complaining about JavaScript. These updates are especially fascinating because nothing makes the JavaScript ecosystem happier than solving the same problem in two completely opposite ways, especially since some people think that rendering some elements on a page is not really a
00:42 problem. So, in this Monday morning review, we'll look at Solid 2 and HTMX 4, review their main additions, and decide if the web dev world is finally moving forward or simply finding increasingly sophisticated ways to render and center-align buttons. If you've been following my channel, you probably know I'm a big fan of Solid because it feels like working in React and the framework is actually reactive.
01:04 It uses components and JSX, but instead of rerunning components and comparing virtual DOM trees whenever state changes, Solid creates precise reactive connections between state and the parts of the interface that consume it. This component function runs only once, and when the signal changes, Solid updates only the text node that reads count. This fine-grained reactivity made Solid extremely fast, but it also created an awkward boundary between synchronous reactive values and asynchronous operations.
01:31 Signals are available immediately, while network requests return promises that might resolve later, fail, or become obsolete because another request started in the meantime. Solid 1 addressed this using resources, suspense boundaries, transitions, and several specialized primitives. This worked well, but the asynchronous state still felt like a separate system attached to the synchronous reactive core.
01:51 And Solid 2 changes that by making asynchronous values a first-class part of the reactive graph. A memo can now produce a promise. When user ID changes, Solid understands that the derived value is pending, tracks the asynchronous dependency, and updates everything that depends on it when the request completes. And while this might look like a small improvement, trust me, the underlying change is much more important.
02:13 If the user quickly selects three different accounts, three requests might be running simultaneously. Solid knows which result belongs to the current reactive state, so an older and slower request cannot casually arrive last and replace the latest data. Race conditions are therefore handled through the structure of the reactive graph instead of through another collection of request IDs, abort controllers, loading flags, and effects written manually in every component.
02:37 Yes, I know it's weird to talk about race conditions in web development, but if you didn't know, changing your profile picture quickly enough can now expose you to the same category of problems as a distributed banking system. Solid now also understands asynchronous dependencies across several levels of derived state. So, each computation simply describes what it depends on, and the framework coordinates when these values become available and prevents intermediate states from escaping into the interface.
03:06 Of course, the framework remains synchronous by default, and sync only enters the parts of the graph that actually depend on an asynchronous value rather than forcing the entire application into a permanently scheduled model. The old suspense component has also been replaced by loading. This boundary primarily handles initial readiness, so if the application has no user data yet, it renders the fallback.
03:27 But what's important is that once the content becomes available, later refreshes can preserve the existing interface while Solid prepares the new state. So, the profile no longer has to disappear and turn back into a spinner every time the user changes something. The pending state can still be displayed separately when needed, and this gives the framework a useful distinction between having nothing to show and refreshing information that is already visible.
03:50 More importantly, however, is that Solid 2 introduces reveal, which is a replacement for suspense list for coordinating several asynchronous sections. But before looking at some more code examples, please let me tell you a few words about today's sponsor. I'm actually really excited about this collaboration because Supabase is one of those products I use in my projects and I discussed it on the channel multiple times.
04:12 If you are a developer who just wants to build things without worrying about setting up a database or REST API best practices, Supabase is the perfect fit for you. Its core purpose is to reduce back-end complexity so teams can innovate faster with the flexibility of open source. So they offer an intuitive UI where you can define your database schema, add tables and relationships, manage your data, and automatically expose everything through a generated REST API.
04:37 With Supabase, you get a Postgres back-end platform that offers a complete suite of back-end services. I'm talking database support, authentication, real-time capabilities, seamless storage solutions, edge functions, APIs, and more. Supabase gives you the speed of a back-end as a service without hiding the underlying infrastructure and because the platform is open source, you can use their managed cloud or self-host it if you need more control.
05:01 On top of that, it pairs well with tools like Laravel. So please check the link in the description to find out more about Supabase. Back to the video and the new reveal component. Without coordination, different parts of a page can appear in whatever order the request happen to finish. Reveal lets the application control that order and present the result as one intentional interface rather than a slot machine where elements appear randomly on the screen.
05:25 In this context, mutations are handled through actions while optimistic primitives allow the interface to update before the server confirms the operation. In this example, the new item appears immediately, the request runs in the background, and the final server state is reconciled afterward. I know that the generator syntax might look slightly unusual, but every yield creates a defined asynchronous boundary that solid can observe.
05:47 As a result, the framework can track the optimistic state, understand when the action finishes, and coordinate dependent updates. Effects have also been redesigned. In solid one, an effect automatically subscribes to every reactive value read inside its callback, but in solid two, the computation that collects dependencies can be separated from the side effects that consumes the result.
06:08 This makes the dependency explicit and gives developers a much clearer answer when an effect mysteriously runs again. Finally, updates are now batched through a microtask, meaning several writes can be collected before dependent computations and DOM updates run. And when code genuinely needs the new value immediately, it can force the queued work to complete using flush.
06:26 So, the main idea behind solid two is simple: synchronous state, asynchronous data, loading boundaries, mutations, and optimistic updates should all participate in the same reactive model. And if you think solid is too much of a hassle, even though, trust me, it doesn't compare with the complexity of the JS big boys, HTMX 4 is approaching web development from the exact opposite direction.
06:48 If you are not familiar with it, HTMX extends regular HTML with attributes that can send requests and replace parts of the document with HTML returned by the server. Clicking this button sends a delete request, the server returns HTML, and HTMX places that response directly into the target element. The idea is so simple that even I was able to copy it into my own original framework a couple of years ago.
07:10 HTMX 4 has been released after 8 months of development, but it remains intentionally similar to HTMX 2 from an application developer's perspective. The largest internal change is the migration from XML HTTP request to the modern fetch API. Most developers will never notice this directly, but it simplifies the core implementation and creates a much better foundation for streaming responses and extensions.
07:32 On the other hand, the most important visible breaking change is that attribute inheritance is now explicit. In HTMX 2, certain attributes placed on a parent element are automatically applied to descendants. In a practical example, this button inherits the confirmation behavior from the parent. This is concise, but in larger templates, it can become difficult to understand where an element's behavior actually comes from.
07:57 So, HTMX 4 requires inherited attributes to be marked explicitly. This might add a few characters, but it also tells us that propagation is deliberate, so it removes any unwanted magic from your code base. The HTMX team says implicit was inspired by CSS and worked approximately as well as in CSS. In other words, it is powerful and convenient, but occasionally, it is also capable of turning a simple debugging session into a 30-minute nightmare.
08:21 HTMX events have also been standardized around a predictable naming structure. Names like before request and after swap are now more explicit. Several error events have been consolidated. XHR specific events have disappeared, and form validation now relies more heavily on native browser behavior. But, there are some new features as well. There is now a new swap mode, which compares the existing DOM with the returned HTML and changes only the parts that differ.
08:46 This is great because we can now preserve focus, selection, scroll position, and other local element state while still letting the server send complete HTML fragments as responses. The second major feature is the new HX partial element, which allows a single response to update multiple parts of the page. In this example, the first partial appends a message, while the second updates a counter somewhere else.
09:08 HTMX already supported similar behavior through out-of-band swaps, but the new element expresses the server's intention much more clearly and works especially well with streaming HTML. Finally, streaming has become a major theme in HTMX 4. New or updated extensions support server-sent events, WebSockets, and multipart responses, allowing the server to send HTML fragments as they become available.
09:32 So, there you have it. An entire video without mentioning you know who while celebrating the good things that are still happening in the web dev world. The Lanterns TV series is your awesome recommendation for the day. Please click the like and subscribe buttons because it really helps a lot. And until next time, thank you for watching. >> YOU HAVE BREATHING HEAVY LIKE A DOG.