I need to remember to talk about this more. Because we pulled everything(including async) into our reactive graph at runtime, @solid_js has more knowledge to guide agents than any other solution out there. We basically made agent targetted dev tools, shipped with every project.

It is probably of little surprise to anyone I'm in favor of this change. When we implemented our official TSRX preview for Solid 2.0 we intentionally walked back from lazy destructuring. You can check out Solid 2.0 TSRX template here: github.com/solidjs/templates…

Stream is back today. Going to look at even more of the capabilities of Solid 2.0. youtube.com/watch?v=khmx8Dvl…

Seriously WTF @AnthropicAI?

I'm retiring Dom Expressions today. For those who don't know it was a project that in a sense predates Solid itself. When I first was making a reactive renderer, I knew I wanted fine-grained updates but I wasn't sure how I wanted my signals to behave. So I made the renderer agnostic. Early on I made versions that worked with Solid's Signals, my own reactive library, as well as Knockout and MobX. When Vue composition API came out I made a version with it too, basically foreshadowing Vue Vapor back in 2020. I entered all of these in the JS Framework Benchmark and they all outperformed all the popular libraries. It had a good run but it has been a maintenance burden for Solid over the years as fixes needed to land cross repo. It wasn't that big of a deal when I was managing this all myself, but contributors would be confused about where the JSX types came from or how the rendering worked. In Solid 2.0 with the increased core responsibilities this just got out of hand. The code got more inbred. Most Signals libraries aren't async native to start. And hoisting features core meant as we built on the protocols there has been a ton of back and forth. The most painful part is managing release sequencing, especially when DOM Expressions now with a Rust compiler has a binary build step. We'd need to locally link repos in multiple work trees and then try to merge them all at the same time to make a release. If we discovered an issue or bug during this process the repos would be broken for contributors. The last month and a half has been so painful in this regard, and has made iterating on things like Server Functions, Server Components, along with bug fixes and performance optimizations related to the runtime/compiler seam incredibly painful. We spend half our time with the Solid repo in a broken build state and that isn't acceptable. So today we fold it in. There are upsides here because we can finally optimize the code to be Solid specific. I left this on the table for the sake of agnosticism. But the reality I've seen over the years is people didn't implement their own dom-expressions libraries. They just forked the code when they wanted their own frameworks. And in an age of AI that seems even more likely. This has basically zero API surface impact for Solid 2.0 RC users. It isn't really a breaking change. But it is part of growing up and recognizing the experiment is over. Dom Expressions will be continued to be maintained for Solid 1.x users. github.com/solidjs/solid/pul…