Ryan Carniato

Breaking SolidJS 2.0 Beta I'm pretty excited to have the beta released. But because it was built with extremely powerful primitives even I don't know its limits. The combinatorics feel like it could get us into crazy places bu...

Solid 2.0 is so powerful even I don't know the limits of its capability. Join me Friday when I try to break it:
www.youtube.com/watch?v=-VzC...

I'm worried even exposing createTrackedEffect is handing people footguns. People are so insistent on this though.

I want to look into this. Because i think there are situations it may make sense for them to be held up.

Slow Double Reproduction - StackBlitz Vite + solid templates

Ok I've laid it all out. createTrackedEffect could never hold but we had some interesting decisions around how to handle User effects. They aren't responsible for rendering so they don't trigger Loading. But do they participate in transitions as they are unbound?

stackblitz.com/edit/solidjs...

Ah.. ok I will make a reproduction in an environment where everything is setup correct but I think I know the problem. `createTrackedEffect` happens too late to hold async. Another good example why effects need to be split.

It all makes sense and honestly reading after writing in event handlers should be frowned upon anyway. But it leaves the developer to encode behavior around an expectation that can break if the graph changes shape.

Yeah it sort of by design. It isn't so much missing it is that it applies what it can immediately in the event handler (even though the UI might not reflect it). If you read derived state also in that event handler it may or may not be updated if it passes through async.

I don't think 2.0 is in the playground yet.

By far the biggest pain. It is only noticeable in imperative code like event handlers. This is cost of async first. Otherwise you risk like Svelte 5 some things updated and other not in the same sync frame. This is something that React had right from a consistency/safety perspective.

I have ideas. Gonna focus on the release first. But some sort of solution in this space is high on my list after that.

Simple solution but not an extensive one. I determined that the approach was too brittle. In order to do it properly the core of the framework had to change which wasn't somethign reasonable to do before 2.0. We made demos. But nothing could ultimately stand behind.

Release v2.0.0 Beta - The <Suspense> is Over · solidjs/solid I know you all probably weren't expecting this announcement next. But after reviewing the roadmap, we spent so long iterating in the Experimental phase, most of the goalposts within Alpha don't app...

The <Suspense> is over.

Solid 2.0 Beta is now released (next tag on npm). 🎉

github.com/solidjs/soli...

That's like saying a paper weight can be used as a hammer.

Fair enough. I'm obviously biased. I've been preparing for this inevitable flattening. I don't know what the next higher-level abstraction looks like right now, nor do I care to. I like vinext's existence as I think it will likely give an indicator where the value is (or isn't).

Yeah I shouldn't be using perception of reactions. I agree about React. React being the defacto choice or not doesn't really change the importance of the language being there, just opens the door to other languages. Part of that being due to shaking up what lies on top.

True but RSCs require almost all those pieces to complete the abstraction. So if that is the abstraction you want to build on it makes sense that React owns it and not say Next.js.

I mean libraries still have a place too.. the thing that doesn't as much is the glue. Core library encodes more behavior.. extension libraries fill the gaps.. orchestrator less important of a role because of growth on both sides.

Looking at how people responded to Vinext, there is nothing contentious about dropping Next. But swapping out React? Not even a consideration. I mean you pretty much said it first. JS Frameworks are languages. Svelte's direction doubles down on that.

So my expectation here is that this back porting happens until we hit a point that the remaining infrastructure, best practices are so encodable that while I doubt we drop our higher level harness it becomes equally reasonable that AI comes and circumvents it.

It's inevitable many of these pieces become core. Part of the language so to speak. I think all framework authors intrinsically feel it. Look at the work we've all been doing the last 5 years. It's like we knew the direction but didn't know exactly what the catalyst for change would be.

And I honestly think we've had varied success there. Metaframeworks mostly exist as a stopgap to cover our lack of knowledge of how to best integrate/redefine the boundaries in the core libraries. With just enough opinions sprinkled in to keep use easy.

I agree about structure being important. People see abstractions disappearing. I see them flattening. And potentially new ones being introduced once we see the shape. I will argue that in frontend a lot of the work the last 8 years has been around reducing perceived complexity.

I think AI wants DSLs they want encoded behavior they can easily express intent with. They will write/grab all the pieces, amalgamate all the parts to fit the prescribed opinions of the day. So library in the React is a library sense, not the isOdd on npm sense.

I mean I already know because of the disagreements/differences between frameworks some of these things shouldn't be standardized. If we can't reach alignment even there what hope do we have. I really don't like having to work against the underlying platform because of assumptions made.

This isn't that interesting to browsers because they can special case for the DOM to streamline. And why would JS care about having a markup template syntax. Tagged Template Literals already allow it. The problem is 3rd party tooling won't standardize around a non-standard.

Well the conversation started because I was trying to get types in Tagged Template Literals that resembled markup. The characteristics I'd want in that solution are similar to JSX where there is a set syntax with no semantic meaning. Ie.. not DOM specific. Ie Runtime swappable.

Yes. Until it doesn't. Software's lack of physicality has let it get by. You'd never expect a local bridge to be constructed by a few neighbours without any oversight, because they had a need. Who is responsible if it collapses? Software should be no different. Can't hide behind AI indefinitely.

I mean so do people. Once you aren't responsible for building what you design. The consequence is you get better at producing clearer specs. I'm not saying AI doesn't assist in that too. I'm just saying that is the artifact.

We should become stricter here. Look at all the security issues of late.

To frame it another way:

Code was never the goal.
Code isn't the hammer either.
Code is the nail/screw. It's part of the output, it holds it together and defines its shape. It's a functional material, building block.

How often does a mechanical engineer pick up a welder? Or electicral fabricate the production chip? They might make a prototype but they aren't responsible often for manufacturing. They write specs, create designs, test prototypes. Code was never the goal. It's the materials.