It's been a while since I wrote a piece about a SolidJS technology innovation. It's been two years now since we added Suspense on the server with S...
For further actions, you may consider blocking this person and/or reporting abuse
Thanks for clearing that up.
I don't know how many times I've watched the Solid Movies App segment but I wasn't sure I was “getting it”—I had a sense of “islands with dynamically server rendered content” but couldn't quite pin it down if that was the case.
In that regard I suspect that the recent Next.js 13 use of “Server Components” doesn't tell the full RSC story as I was under the impression that in the original December 2020 demo server components were able to send updates even well past the first render into the client's VDOM.
So as I understand it Solid Start's dynamically server rendered islands in the Solid Movies Demo are the functional equivalent to the Server Components in the December 2020 RSC demo—which is why they are being referred to as “Solid Server Components” even though technically Solid's components vanish at runtime.
After the “component (repeated) render function” vs. “component (one time) setup function” confusion I'm afraid you may have set yourself up for having to explain repeatedly that “DOM diffing” doesn't mean that there is a VDOM.
This look solid :)👏👏👏
I'm really impressed! awesome work @ryansolid
The future of solidjs looks bright, I like how you challenged the status quo of the JavaScript Frameworks! this will bring more attention to the possibilities of shipping less Code to achieve interactive web apps.
This is all really exciting and I love your work!
I noticed that backwards navigation in the movies app takes the same time as new navigation. Is this unavoidable? I feel like the ideal solution would have instant backwards navigation.
Yeah it is possible. We haven't done any sort of caching here yet. I always consider caching the last level of optimization. This sort of architecture begs for back/forward caching but haven't created a solution for that as of yet.
Wow, these numbers are really impressive 👏
Thank you for the write up and the detailed explanations.
Something I don't quite understand about nested islands:
Am I missing something here or is this not the answer to the question? Or to put it more directly, can you rephrase why we want nested islands?
You are absolutely right. I've added a bit more of an explanation.
I don't know. I just grabbed the demos that were posted officially and the one from Qwik I had seen in a similar comparison. I haven't seen a Remix one as of yet. I checked their Discord and MJ suggested the community should build one, but it seems to confirm that one doesn't exist currently.
Always a solid knowledge 👍✨💯
I wasted 3 days experimenting with a similar concept using Astro + HTMX, but I haven't realized that Solid Start will support it out of the box. How far are these feature from being completed? I'm extremely impressed with this work!
Still a ways out. I am not content with the DX. And Context is still an unsolved problem. It works fine for these simple things, but there are things it doesn't support and it isn't clear why. I think the direction is good and I'm sold on what it gives, but we need to do more here. More than some linter rules etc.. So we need to spend some more time with it.
isn't something similar to what Iniertiajs is already doing?
inertiajs.com/routing
The protocol suggests that inertia.js is used to build fully client side rendered (CSR) UIs without having to define a separate supporting API (which likely would require lots of client side JS).
The Islands Architecture tries to minimize the shipped JavaScript by fully rendering the page on the server side as HTML and only delivering just enough JS to make the “islands” interactive.
Solid Start goes further by letting the client side islands manage content that was originally rendered on the server and even replace that content with server content rendered at a later time (while all client side components are hydrated on initial page load).
So the goal is to render as much as possible on the server so that the JS for rendering that server rendered content doesn't have to be shipped to the browser.
Thank you for the explanation and the links, really helpful.
Looks great, definitely worth trying 🤔, great work 👏👏
This is amazing! Great work!
Awesome work Ryan!
Could you elaborate a bit on this:
What does the order of the numbers in the
data-hkattribute stand for? What would the2and the1in this string correspond to?The order they are created. Since JSX can be inserted in any order we needed to keep track of that. We can't rely on the order things appear in the DOM. Template partials might be hydrated in a different order than they appear in the DOM. So presumably if the 2nd template is created first on the server it will be hydrated first in the client so being able to match that up is critical.
And the dashes are component depth. That is a bit arbitrary but since our control flow is components it was the easiest way to isolate. It's possible only Suspense and hydration entries need depth but it was a safer bet right now.