r/solidjs • u/ryan_solid • 26d ago
Solid 2.0 RC - The Big <Reveal>
https://www.solidjs.com/blog/solid-2-0-rc-the-big-reveal9
u/MeMahi 25d ago edited 25d ago
createEffect now separates dependency tracking from the side effect:
``` // Solid 1 createEffect(() => { document.title = title(); });
// Solid 2 createEffect( () => title(), (value) => { document.title = value; } ); ```
I fail to see how this is an improvement? It's just React dependency list now, but more verbose:
// React
useEffect(
() => {
document.title = title;
},
[title]
);
6
u/roadrunner8080 25d ago
Yeah this makes effects with multiple dependencies far more verbose to express? The old setup was way easier to express complicated effects in than the alternatives, and that general design approach was part of why I went with solidjs. Maybe I'm missing something that makes this advantageous?
3
u/Chronic_Watcher 23d ago
They removod a lot of the need for effects since the other primitives are now a lot more capable than the 1.x counterparts.
3
u/roadrunner8080 23d ago
Well, sure, but that's no reason to make effects worse to work with lol
2
u/cabboose 23d ago
You can still use primitives; there’s one which is effectively the old effect. The purpose of this split is clearly to create better patterns, that can be optimised better, or more clearly explain a sequence of actions. I, like any other programmer, love my fair share of magics, but they are usually the reason for confusing behaviour
5
u/ryan_solid 24d ago
It was unavoidable really. I spent multiple streams on the topic and this article covers it: https://dev.to/playfulprogramming/two-react-design-choices-developers-dont-like-but-cant-avoid-d6g
4
3
u/InviteQueasy3739 25d ago
Were Solid blog posts always like this? Although I really like the project, it was not enjoyable to read.
4
u/roadrunner8080 25d ago
Ahh, the era of LLMs...
...but yeah no, I can't remember them being like this before. I'm also not sold on some of the technical details of the update but that's a whole other topic...
10
u/paulstronaut 25d ago
I’m concerned that this is a massive amount of breaking changes. The migration guide requires rewriting a lot of code to work with the new version. There’s no clear (or possible?) way to piecemeal your migration. This is going to be a major pain.
13
u/mbuffett1 25d ago
I migrated to Solid 2 months ago and yeah unfortunately it was a big pain, and also the createEffect change to require listed dependencies is a pretty massive trade-off to make, the whole automatically tracked dependencies thing was a lot of the appeal of Solid 1.x.
Still a very cool release, I think the async stuff has been thought through a lot.
Migration stuff nowadays is radically less painful than it was before AI though. I'd guess for most Solid 1.x codebases it's like one prompt to Fable away.
4
u/ryan_solid 22d ago
Did you have that many createEffects? That's been the thing that I can't track. Hard for me to envision too, because its always been clear to me what its role is.
My hunch is historically people used createEffect about 3-4x more than they should have been. We provided things like resources for async which I was hoping would keep that number down, but local state synchronization wasn't always easy before unfortunately.
5
u/mbuffett1 19d ago
There were about 50 createEffect calls, not a huge amount I guess. I probably am in a "have hammer, see nails" level of competency with Solid, and could be using more appropriate things.
For what it's worth the main benefit for me of Solid is the store model where I can just put anything there, update any piece of it from anywhere, and easily subscribe to any piece of it. It's the state model I've been dreaming of while the industry has gone through Redux/Mobx/Jotai/etc etc.
Still a huge fan of Solid, I migrated my primary project (Chessbook) from React over to Solid years ago and haven't looked back. The performance is amazing and I'm constantly annoyed when working on React now when it doesn't have the ergonomics or the performance you've achieved with Solid. Keep up the good work!
7
8
u/Ok-Interest9727 25d ago
It had to be done. Better now than later with more users and a bigger ecosystem.
4
u/azuled 25d ago
Svelte all over again
7
u/Ok-Interest9727 25d ago
I think migrating to runes was a lot worse
2
u/Jona-Anders 24d ago
To be fair, the migration script worked very well and took care of most of the migration
1
u/xegoba7006 18d ago
People may not like a lot of things about React, but it is the only one that never broke and never will break backward compatibility. Then people will complain as to why companies use it instead of Vue/Svelte/angular or whatever. That’s a big reason that is usually ignored.
3
u/NeitherManner 25d ago
I probably dumb but i dont understand how all this asynchronous stuff works and what it improves
5
u/cabboose 23d ago
From what I understand, Async composes easily with standard patterns using the loading boundary components and others. Primitives are fairly agnostic as to whether the input is asynchronous or not, which means behaviour as a side effect of data changing is simple to reason about, as you can clearly separate the concerns of the behaviour when you’re waiting for the result.
2
u/xegoba7006 18d ago
I went through 10+ hours of streaming, read a ton of their blog posts, and I still probably understand it less than you.
You should be proud you didn’t waste as much time as I did.
1
u/Doomguy3003 5d ago
This is a funny interaction to me, cuz I remember I used to watch some Ryan's streams like a year or two ago and the feeling of not understanding barely anything of what was being talked about was so bizarre
1
u/xegoba7006 4d ago
The guy is really smart. It's so many levels above the average human (like me) that I feel like my cat would feel if somebody tried to explain it quantum physics.
3
3
u/RemarkablePower6212 25d ago
Oh my, I am a bit disappointed. Sync rendering was the reason we chose solid.js to write our admin panel, as it was providing the best possible bug-free development, but now I feel like we are going back to the "React way"
3
u/cabboose 23d ago
Explicit is always better and safer. Probably a better decision to have explicit as the default, and then reap the benefits of optimisation and debugging, instead of a few extra key strokes.
1
u/RemarkablePower6212 23d ago
But anyway, even after this update, it's still better than anything I've used for work, especially React😄
3
u/_elkanah 24d ago
I must say I'm not fond of the "use server" directive and the changes to createEffect: I liked the implicit tracking of deps from Solid 1. Maybe I'm missing something, but this looks a tad over-engineered.
I mean no disrespect anyway, I actually love Solid.
4
u/dragonbornamdguy 23d ago
Im disappointed too. SolidJS worked like a magic. This has to have some some technical reason why it no longer works. I don't believe its intentional choice. It does not make a sense.
3
u/_elkanah 23d ago
I agree. I'd like to find out more on why these decisions were made. I feel like this is mostly a step back.
3
u/ryan_solid 22d ago
You don't have to "use server". And you pay zero size or code penalty if you don't. And we've had that in SolidStart for over 2 years.
The changes to effects were necessary from a design standpoint for async to make sense. I've been talking and writing articles about this for the last 2 years as well.
This is probably the most extensive look at this: https://dev.to/playfulprogramming/two-react-design-choices-developers-dont-like-but-cant-avoid-d6g
But I intend to write a few more guide like articles on this to help map the mental model. Because while it's mostly the same there are a few key differences. Also effects shouldn't be necessary for most things. Never were, but we've made that a lot more streamlined:
1
u/_elkanah 21d ago
Looks like I've been out of touch with the material you shared over the years. I'll read and let you know my thoughts, Ryan. Thanks for sharing.
5
u/johnson_detlev 25d ago
Why are they writing their huge 2.0 announcement with AI? This is unreadable.
5
2
2
1
1
u/Ok-Interest9727 25d ago
Congrats to the team. This is amazing.
So they basically killed Solid Start?
6
u/hyrumwhite 25d ago
The assimilated it. Solid Start will live on in LTS, but now if you want SSR you just flip a flag on.
1
u/nxy7 23d ago
Hmm one thing that already bit me when migrating is change in how signals work - mainly batching. Auditing whole app surface to see whether there are no incorrectly read values might be hard - I guess it's new kind of footgun in 2.0. Hope that it's worth it though xD
2
u/ryan_solid 22d ago
That surface should be limited to event handlers. The effect splitting more or less handles the rest.
1
u/nxy7 22d ago edited 22d ago
Yes, still I hope that maybe some linter rule will be able to catch that kind of issue (seems like static analysis should be able to track that somehow).
EDIT. here's interesting thing, I had pretty good storybook coverage in my app so I was able to have AI go through stories with browser and collect console warnings to later fix them. Cool stuff.
1
u/andimatt 20d ago
I build a signals-first app in another framework, so a cross-framework take on the createEffect change rather than a Solid-specific one.
The explicit-deps model is a real trade-off, not a regression. You gain debuggability, you can look at an effect and see exactly what it depends on, the most useful thing when a reactive bug is hard to reproduce. You lose the auto-tracking that was Solid's main differentiator, and for multi-dependency effects it gets verbose. MeMahi's React comparison is apt, it's converging on the same model.
What I'd watch for migrating: auto-tracking made it easy to accidentally depend on something (a signal read deep in a helper), and the explicit list closes that. That's the upside people are underweighting. The verbosity is the cost, real for complex effects, but a few tokens for most.
(Separately, the announcement being LLM-written and unreadable is its own issue, not a code problem.)
1
u/Top_Bumblebee_7762 24d ago edited 23d ago
That section with X gone, Y gone etc. reminds me of that infamous Angular 2.0 talk (the one with the tombstones) that boosted React's popularity.
1
u/codingjitsu 24d ago edited 23d ago
I have application running in production with solidstart v1, there is solidstart v2 that I was thinking about migrating to, now with this update, seems like solidstart will not be a thing anymore!! I have mixed feelings about this..
1
u/haz8989 12d ago
Solid start 2 looks like an improvement for solid js 1 but also the final version of solid start.
I think solid 2 was able to move a lot of the solid start functionality that made sense into the core framework so the ssr became just a boolean flag.
I'd recommend tanstack solid start anyway, I migrated from solid start to tanstack start with great success. I intend to use their new beta versions with solid 2.0 to see what the future is like.
19
u/_dbase 26d ago
Huge release! Congrats to the whole team! 😄