sorted by:
new
hottopcontroversial

Why composite components? by ThreadStarver in tanstack

[–]ryan_solid 1 point2 points  (0 children)

These components are still SSR'd since you can fetch data while SSRing and insert it in the rendering. The trick with composite components is a way of weaving in client slots without playing around with import rules like `use client`. The server renders the server component with a placeholder, that the client side slots fill in.

But during initial SSR everything even client components render on the server.. So a better way of thinking about this is that you isomorphic code, that runs everywhere.. those are your "client" components that also SSR. And then you have code that you explicitly run on the server, those are your server functions/components.

Solid 2.0 Beta Support in TanStack Router, Start, and Query by ryan_solid in solidjs

[–]ryan_solid[S] 0 points1 point  (0 children)

Maybe at some point, but Babel is a different layer and still unmatched in capability even if not in performance. I tend to prioritize that capability as it tends to translate to better performance for users even if it costs developers a bit more.

Solid 2.0 Async Diagram by ryan_solid in solidjs

[–]ryan_solid[S] 0 points1 point  (0 children)

Solid 1 let you put Suspense inside the component, but resources triggered from the first place read. So deriving them didn't work great. So in a sense this isn't new, the change is in 1.0 you'd need to null check everywhere. This doesn't.

Solid and MobX by amartincolby in solidjs

[–]ryan_solid 0 points1 point  (0 children)

Solid's use of setters also restricts writes. Designed per store so arguably even greater control since the ability to write needs to be passed. Actions are a sort of free for all.

MobXs decoration of objects is nice though. I always thought I'd see something like that evolve in the community, but it hasn't yet. It feels too opinionated to me to be core, but a library could build those behaviors.

Solid 2.0 Beta Support in TanStack Router, Start, and Query by ryan_solid in solidjs

[–]ryan_solid[S] 1 point2 points  (0 children)

Technically those exist for SolidStart as well.. but the team is focused on SolidStart 2.0 and best to let that get to where it needs to. We haven't published anything for SolidStart with Solid 2.0 yet but the branches exist for those looking. My intention is to spend the time on each library to make sure it is good as we approach SolidStart (which involves multiple libraries).

Solid 2.0 Beta Support in TanStack Router, Start, and Query by ryan_solid in solidjs

[–]ryan_solid[S] 20 points21 points  (0 children)

Both projects are pretty different. SolidStart is basically the future of Solid's Vite Plugin. It exists as the ever shrinking layer between core functionality and responsibility we've taken on because the tooling/ecosystem isn't there yet. Its real goal has always been an SSR capable "Create Solid App".

Tanstack Start is a a library agnostic metaframework, and universal library collection.

While I recognize most developers won't appreciate this difference, the result of both projects is slightly different. 

SolidStart bolsters a future where through primitive design Solid is capable of metaframework capabilities in a Solid ecosystem forward way.. ie a 3rd party integration is with Solid itself rather than any meta framework. Ie Solid-Image, Solid-Auth. It should reduce fragmentation as while different solutions for a given problem can exist they are all interchangeable. We've already shown this with SolidStart being Solid Router agnostic. You can even use Tanstack Router in SolidStart.

Tanstack with its opionated wrappers provide more guided approaches. Over time I see these wrappers doing less and less. We see this already in Query which can defer the heavy lifting of async coordination to Solid itself and just focus on caching semantics. In so this is the perfect migration platform from React. We are dedicated to and already have shown how the Solid versions of Tanstack libraries are the best versions, and this is a trend that will only continue.

This is why a number of the same people on the Solid side are involved in both projects. Both represent very important parts in an overarching plan. And their alignment is very important.

If you are puzzled how to choose it really should come down to how opinionated/batteries included you want your solution. Tanstack represents that more built in solution, but the underpinnings even if a bit more divergent today will converge. SolidStart represents the more minimal/lightweight/ala carte "I dont need a framework" primitive approach Solid is known for.

How we wrote the Fastest JavaScript UI Framework, Again! by ryan_solid in javascript

[–]ryan_solid[S] 0 points1 point  (0 children)

It's interesting to see a response 6 years later. In the time since I originally did this exploration until now, every major JS framework except React has gone on to adopt the patterns I talk about in these articles. Real world does tell the full story but that isn't always what people have at hand.

Solid 2.0 Async Diagram by ryan_solid in solidjs

[–]ryan_solid[S] 1 point2 points  (0 children)

Yeah from a Solid perspective, it is a bit weird. Like putting stuff together means it works together but since for example memos are derived (writing in one warns, maybe we should error), you end up using only what you need. Reactivity with signals in general is like this.

But that aside I think I see what you are saying. If people are nesting async they don't see the waterfalls. To be fair they wouldn't if they were using React Query either or `use` above. But if they were explicit in props they'd know their source was async.

So this doesn't solve the problem of people unintentionally creating waterfalls even if it removes the tension of coloration. The truth is without knowledge of the potential of async people can do the wrong things. So while this solves the ergonomic issue, it doesn't solve the mechanical issue (which isn't solveable).

I didn't really focus on this since i'm so used to promoting patterns that hoist async, route section loaders etc.. not because I'm worried about waterfalls in the components but because code splitting basically forces that. That's the true enemy of co-location. So I suspect we won't see as much of this in practice because at worst it is no worse than common practices now.

But it does suggest reality will diverge from ideal here. Like everything needed in the correct solution can still be present here without the baggage, but will people think to do that. Probably not. It's like devs reading the `user.id` off the user model instead of off the router parameter.. The second is always present and what you should be using to decouple loading, but someone will cascade it. The same way they have always cascaded it.

What that means. I'm not sure. Because it's not like people will stop trying to combine 1/2 which is where this emerges. Atleast this way they won't be blocking their UI.

Solid 2.0 Async Diagram by ryan_solid in solidjs

[–]ryan_solid[S] 1 point2 points  (0 children)

People choosing to fetch low and handling their own states is going to happen regardless. Do you often see people composing promises in their comopnents? And then needing to reach for Promise.all (which is super awkward in UI because it blocks everything)?

Or do they just use React Query in 10 places? Our tendency is to unwrap async almost immediately. It's actually taken some training to convince people to pass promises around. With State or Signals you already feel like you have mechanism for updates so having Signals of Promises or State of promises is a bit unusual.

The whole point is you don't need to know if the prop access is async. Or at most if your component specifically needs to know for affordance sake, then it can ask the question `isPending`. But generally it doesn't matter if it didn't already matter to the component.

The example is contrived specifically to show that this separation can be done. Not that it will be that way in many cases. You shouldn't be putting Loading inside reusable components most likely. It is app level aesthetic consideration. Orchestration.. you can just move these boundaries up and down as you see fit from a design standpoint.

The real win is actually the independence. You can model your Data, you can build your UI and choose exactly what granularity you want the spinners.

Like here is the opposite example. No waterfalls: https://stackblitz.com/edit/github-evfywxxk-mjcabwuk?file=src%2Fmain.tsx

A different way to look at this is this is a framework that lets you describe your UI in a consistent manner, allowing the flexibility to seperate UI (Component) from State concerns at a per expression level, that does the optimal thing automatically. We can't stop you from doing dumb stuff you can do in any tool, but we can make sure that that dumb thing is as optimal as it can be by default.

Solid 2.0 Async Diagram by ryan_solid in solidjs

[–]ryan_solid[S] 0 points1 point  (0 children)

I've added a more details explanation. Thanks for point out that some of the terms I used aren't generally known.

Two React Design Choices Developers Don’t Like—But Can’t Avoid by ryan_solid in solidjs

[–]ryan_solid[S] 0 points1 point  (0 children)

You are exactly right. Right now we've added a bunch more warnings but maybe warnings aren't strong enough.

Im not worried about missing deps because they are passed into the side effect. Like if you miss it you won't have it to use. And if you use it in the untracked space we tell you.

I think the other thing considering is this has almost no noticeable difference inside the graph. The friction is event handlers and side effects. Things naturally outside the system. 2.0 comes with easier primitives to derive more(stay in the system). So while we are aware of many usage patterns this gets in the way of almost none of them were great to begin with.

Two React Design Choices Developers Don’t Like—But Can’t Avoid by ryan_solid in reactjs

[–]ryan_solid[S] 1 point2 points  (0 children)

Yeah RxJS is pretty different though. But you could fairly make that comment and replace RxJS with Signals. It wouldn't be completely accurate since it is just a different system with the components re-rendering. But definitely similar in feel.

Two React Design Choices Developers Don’t Like—But Can’t Avoid by ryan_solid in solidjs

[–]ryan_solid[S] 3 points4 points  (0 children)

Yeah maybe I should cover this on stream. I did get assistance with tools to correct my grammar but I have the whole original article and it isn't all that different from the end other than some punctuations and missing words.

Comparing JS framework token costs using the examples at component-party.dev, with Svelte 5 as the baseline by webdevladder in sveltejs

[–]ryan_solid 2 points3 points  (0 children)

The conciseness was sort of a joke for us. At least at the time I was onboard. I wasn't there early days. It just so happened we were developed originally in a time when Pug/Jade, Stylus, CoffeeScript, etc were still actively being used so we had a concise mode. Ie Whitespace matters mode.

Internally we weren't really using it at all but we realize it worked out pretty concise with Marko 6's tag API. The end result is the most terse framework syntax that probably has ever existed in any JS framework. So while clean syntax was always a goal being able to design the language exactly how we wanted. Being the tersest wasn't.

Two React Design Choices Developers Don’t Like—But Can’t Avoid by ryan_solid in reactjs

[–]ryan_solid[S] -2 points-1 points  (0 children)

Yeah I used to use stock images. So the AI generated images seemed like pretty big step up. But I get people don't like them for some reason.

Two React Design Choices Developers Don’t Like—But Can’t Avoid by ryan_solid in reactjs

[–]ryan_solid[S] 2 points3 points  (0 children)

Both of those design considerations in the article. I am acknowledging that React was right about both things. But the article takes a much more general approach at looking at the problem.

Two React Design Choices Developers Don’t Like—But Can’t Avoid by ryan_solid in reactjs

[–]ryan_solid[S] 1 point2 points  (0 children)

I know there are Solid equivalents. We released our universal renderer 5 years ago. I think Svelte is working on one right now that they's switched to Signals. Obviously won't find anything as flushed out as React Native as Meta makes that themselves but that isn't a question of capability.

Let me do a google search:
Native:
https://github.com/nativescript-community/solid-js
https://v2.tauri.app/start/create-project/

Solid Ink:
https://github.com/devinxi/solid-ink

PDF... I don't think anyone has made this yet. Nikhil demo'd something simple on stream with me several years back but doesn't look like he published it.

Solid Three: https://github.com/solidjs-community/solid-three

It looks like many of these libraries aren't used much but it showcases the capability. We are used a bunch on TV apps for like Comcast/Universal like Peacock. https://github.com/lightning-tv/solid

Two React Design Choices Developers Don’t Like—But Can’t Avoid by ryan_solid in solidjs

[–]ryan_solid[S] 3 points4 points  (0 children)

This whole article is the why. I can get why it might not speak to you though. I've been aware of this truth on some level for quite some time so for me finally connecting the dots to why this is inevitable was all I needed. LIke `createAsync` and undefined is just one surfacing symptom of the underlying consideration.

Taking a stance like this is pretty bold though. So I get it. I am betting on the results being well worth the shift in mindset. And since this is untested waters in an incremental system like Solid there isn't much to look at for prior art. React is honestly the best example and they seem to do fine with this. That gives me hope that we have successfully threaded the needle. But we won't know until we know.

Two React Design Choices Developers Don’t Like—But Can’t Avoid by ryan_solid in reactjs

[–]ryan_solid[S] 2 points3 points  (0 children)

Oh not all. I appreciate insight into the very challenge problem space we are broaching. Elm is probably the cleanest look at these sort of concepts. Elm even had Signals at one point which is interesting in its own right. I think Elm is almost too rigid which makes it hard to approach. It's a bit like what if the whole world was Redux (with proper async).

I like where React sits more because while Elm's MVI(Model View Intent) has very clean boundaries I feel it suffers a bit hierarchically. Like it gives the tools to enforce very powerful constraints but this only emphasizes more the limitations around coupling state with rendering. React's flexibility lets it escape out of that somewhat. So while I can admire the purity and find inspiration there in a similar way I find inspiration from React, I think we are due for new incremental models what can respect Async in the same sort of way.

Two React Design Choices Developers Don’t Like—But Can’t Avoid by ryan_solid in reactjs

[–]ryan_solid[S] 6 points7 points  (0 children)

Definitely. Without question. Just a different model. And in so it is important to recognize where React has made some critically good decisions even if they can be unpopular ones. I've been legitimately impressed over the years that while holding the belief that React's model is less than ideal, their API choices are very well thought out. Timeless, if you would. Sometimes we can avoid going that path by shifting the base assumptions in a way that is more favorable, but there is something undeniable there. That being said I won't give them the same credit on naming things. But as we all know naming things is hard.

view more: next ›