Solid 2.0 Beta Refined YouTube video by Ryan Carniato

Streaming the latest in SolidJS 2.0 Beta in an hour.

www.youtube.com/live/RQd6FIV...

Yeah something I've been trying to do for years. I feel there would be a lot more SolidJS users if I could figure out how to make that appealing to the audience.

Up to now showmanship has counted for a lot more.

For sure but I think the feel changes. Like the pain of actually typing the thing, and remembering all the spots to change etc... I guess I will see but I feel it already on my streams.

I started creating benchmarks to this effect (token expense), but they feel handwavy at this point. The kind of things are too variable on the shape of the task. AI itself too variable.

And performance benchmarks of the solution itself no one has cared about for years.

How do you get people to commiserate with a problem when they don't identify with being the ones writing/debugging the code?

My typical demo follows a formula.

1. Present a problem
2. Lead the audience to a simple solution
3. Show the simple solution doesn't work (in today's tools).
4. Spend significant time fixing
5. Show same simple solution in Solid, but it works

AI throws a wrench in this.

I've seen talk of AI removing the need for frameworks. As an author using AI to assist writing, it feels we aren't there. Trying to debug/fix framework code without introducing regressions is non-trivial. To think app code isn't going to be missing edge cases is fanciful.

We're live!

Let's Talk: SolidStart 2.0 YouTube video by Ryan Carniato

The stream is back tomorrow!

The SolidStart team joins me from around the world to talk about the upcoming SolidStart 2.0 release and more:
www.youtube.com/watch?v=J7Sc...

I think an interesting question would be how big is a human's context window roughly. It's a lot higher than 1 million tokens. 10 Billion/more? Our problem is closer to where I think this heading. Size isn't the concern it is navigating such a large amount of knowledge relevance.

That's why I'm still so focused on declarative models. I don't think they are just for humans. Feels like so much context to keep in mind otherwise.

State machines is one way to look at that, make the transition consistent. But that doesn't account for emergent behaviors. You need to be very explicit around potential source state conditions. If instead the states encode their behavior that inconsistency should be a structural impossibility.

Yeah I think time is that wall. Once there is the potential for overlap/parallelization our imperative thinking gets lost. Not even overlap, different events impacting the same representation over time.

Honestly, I love those sweatshirts. So comfortable. My wife stole mine for a bit until she found the brand that made them and bought her own.

This differs from say a VDOM or a mechanical component model. Components have no needed mechanical purpose, and a VDOM only becomes unnecessary when you have the means to practically orchestrate widespread change with propagation guarantees.

So compilers? Language level? Reactivity isn't the goal, it's the means. What reactivity does is encode guarantees. The former 2 are better at that in many ways but also more limited at runtime. But in the absence of either there is significant weight being carried.

HackMD - Collaborative Markdown Knowledge Base Best way to write and share your knowledge in markdown.

Hmm.. not in a single place. I basically kept a journey of my ideas since June 2024 on HackMD. But the topics are all over the place and they have evolved. hackmd.io/@0u1u3zEAQAO...

Yeah I have debated that. I'm trying to remember why I didn't. It's possible it just slipped my mind but I had definitely thought about doing that.

Sure. This is probably my favorite write up on the concept: journal.stuffwithstuff.com/2015/02/01/w...

This example is a bit contrived. It's a bit like reactivity. It doesn't really matter what is Async as long as something above it handles that first load. You might want Loading higher. But it is purely a UX question.

Beyond that we have implicit transitions so things function reasonably after.

If people didn't quite get what I meant with the diagram. I suggest you try to build this contrived example with the framework of your choice:

stackblitz.com/edit/github-...

Yeah this conversation made me realize I didn't have this example.. I used to have a fine-grained example that was almost identicaly where I appended or modified props through the tree to show the components didnt re-run. Love how it still holds true with async.

That is something you can do. I don't dislike this pattern on a section-by-section basis. I wouldn't want to do it every time I broke into a new component. Caching in this modular way is an eventual reality for a lot of things. I just like when we can design in a way that cleanly isolates a layer.

I think what will standout as you look at my examples is there is no tension. The easy, dumb thing works the most optimally. Sure can cache the fetch but that's a different concern.

You can consume the promise wherever you want, which means if you cache the fetch that works. That's a way of shortening the gap. But once you get into components it appears again. This has a lot of parallels to comparing Solid's granular updates to any React best practices with complex state mgmt.

Solid encourages unwrapping the promise as soon as possible. And we don't need to encourage it. Sort of happens naturally. We don't have any tension to push it any further downward because the system takes care of itself. Where other solutions more suggest you should for UX reasons.

A bit.. we care about consistency between signals, whereas RX sort of lets things flow wherever, but there are similarities to this sentiment. I definitely started thinking of Signals in 3 states: value (next), throws error (error), throws promise (!complete).

Solid2 Nested Fetching - StackBlitz Run Solid2 Experiments created by Ryansolid on StackBlitz

And we don't need to block hierarchically on UI just on data. Like simple nested fetching example: stackblitz.com/edit/github-...

Solid2 Derived Async Components - StackBlitz Run Solid2 Experiments created by Ryansolid on StackBlitz

No Promises passed through the components. No MaybePromise props.. it means that we can Suspend as low as possible to where the values are actually used. I just threw an example together showing how each component modifies an async prop as it passes it through:
stackblitz.com/edit/github-...

It consumes the async into state generally at the top. Like you await where you fetch. But we don't block the UI there, instead it propagates through the reactive graph looking like a value (same trick React does with throwing promises). But we don't need to block/suspend until it is finally read.