SolidStart 1.0 RC - Progress so Far

[ryansolid]

Ok. I wasn't intending to let this one linger so long. I had a family tragedy and it kept me away from my work for several weeks. Basically the whole month since releasing the RC. It's been a month and like any month since Beta 2 we are doing a reflection on SolidStart's progress.

I'm pretty happy with the RC so far. APIs seem good and locked and we are starting to see some bugs coming in. Many of them are not related to SolidStart. Some are core Solid issues and others aren't bugs but have gotten us to worker harder on documentation as it shows that people are using it.

However, I do think we have 2 concerns that are holding back release so I wanted to put them out to discussion. Really appreciate feedback here.

CSS Handling

Vinxi has some opinions here and has been slightly adjusting over time. I'd like to review them with the community at large to make sure we are doing the right things. And it comes down to a couple questions/assumptions that Vinxi makes.

1. Do we want CSS unload?

I think the answer ultimately is yes. But this has been the source of a lot of confusion. Frameworks with SFCs (Single File Components) have always handled their CSS a bit better than we have and truthfully we are looking at building primitives into the framework. But I do think this is the source of a decent amount of complexity impacting other decisions. Largely why we don't just go with Vite's default handling.

2. Do we want to crawl node_modules for CSS in dev?

Probably not. This is an interesting one. Vite will during production builds but it does something different during dev. But that is also why there is a flash of unstyled content in dev. Vinxi gets rid of that by pre-processing CSS in dev but that is slower. And node_modules start adding up. Vinxi originally did this in dev but stopped. Hence the need for: #1423

However, my understanding to be fair they still come in, just later. We get the FOUC. So maybe this is a reasonable tradeoff. We could look at adding exceptions in the future, but I believe you could just import the required CSS in your projects anyway?

3. Do we want CSS to load lazily in lazy components?

Currently Vinxi stops crawling on dynamic imports. We use a special lazy component in the FS router to determine which stylesheets to render from the build but it stops at any user land dynamic imports. Right now my understanding is that loading CSS is broken in production not just lazy.

Now there are a few ways we can approach solving this.

1. The most obvious is to not have Vinxi stop tracing through imports so we can eagerly load all the CSS. But I do see advantage of only adding the CSS that is related to components that are rendered.

2. Expose a version of our routeLazy wrapper. However this would still require compilation and it would be SolidStart specific. I'm ok if SolidStart does some extra transforms but having a different lazy wrapper seems not great. This suggests to me that depending on dynamic import granular handling of this may not be for the best. That being said the approach works as seen in userland with: https://codeberg.org/lufrai/solid-lazy-plus

3. We import the URL instead of the CSS and use it in SolidMeta component (or equivalent).. like:

import style from "/my-styles.css?url"

<Link rel="stylesheet" href={style} />

This would leave the mounting and unmounting to the component lifecycle. Some challenges here are that streaming timing might make this harder. We've started work bringing this into solid core so that we can manage it better. We also still need to use static analysis to get the right preload tags as we may want to send those back before everything has rendered.

Handling Preload Errors in the Router

First of all this isn't a SolidStart problem exactly, but a Solid Router one. However, I want a solution for 1.0. This one has been a bit tricky because we don't await generally during load functions so any thrown errors are thrown into space. But maybe the solution could be specific to cache functions. Maybe based on us knowing when they are initiated we could suppress errors. This is an imperfect solution but, any solution that didn't depend on a cache-like mechanism would be passing promises to await them so that is probably our best bet.

---

In any case I want to address both issues. Are there any other design concerns/high level issues with Start you'd like to make sure are tackled in 1.0 release. Let us know below.

[jer3m01]

I think we should also take CSS Modules into consideration. Solid already has a docs page for it https://docs.solidjs.com/guides/styling-components/css-modules and it seems that Nuxt supports them already https://nuxt.com/docs/getting-started/styling#css-modules.
It's worth a look and can probably be ported over due to nitro.

[shiro]

My 2 cents about 3. Do we want CSS to load lazily in lazy components? based on the issues I dealt with:

• there's some huge apps out there, I can't imagine #1 scaling well
• approach #2 is IMO pretty good, I used (and forked to add dev-mode support) solid-lazy-plus and it works pretty well. I think SS will have to add some build-time transforms sooner or later and as long as it's not pure magic that's alright, some things can't be done without
• I use styled components (linaria) that generate CSS at build time, so approach #3 wouldn't work in that case

[ryansolid]

Thanks for the example of the problem with #3. From where I sit #3 is very appealing in the sense that we don't need anything SolidStart specific. Bundler awareness plus special different primitives from standard ones, and that those primitives can't be added to core because of that bundle awareness makes #2 very difficult.

[apatrida]

Just be sure it works with Panda-CSS without rendering affects due to component/CSS loading order.

[birkskyum]

I had an issue recently where i wanted to import some global styles in a layout as import "style.scss" rather than import style from "style.scss", and it would run fine in dev, but now load in production where the import presumably got removed as "unused" or something like that. Always confusing when things behave different in dev and production. Had to make it .css, put it in /public and load it with a link tag to get it working consistently, but lost the abilities of Sass in the process

[ryansolid]

Interesting. See on the other side stock Vite handling I think in prod works fine in all these cases. We have custom behavior to support style removal. But that seems like it might be less important.

[katywings]

Thank you for this update 😊!

Do we want CSS to load lazily in lazy components?

Personally I find it really exhausting to work with foucs and i also dont like to see them in prod builds, they can make a site feel very flaky. Then again I also wanna be able to optimize the css loading.

As the creator of solid-lazy-plus and #1423 I obviously would love to see solid-start supporting granular css loading without foucs out-of-the-box. I am using glob imports in my projects, and there is the case where eg. only 20 components are actually rendered from a glob import with 50 components. solid-lazy-plus can handle that case. There is also the case where I have a website with an admin route: I don't want the css of all admin components getting loaded into the public routes and vice-versa.

If solid-start goes the eager route to load all css - which I hope it doesnt - it would be very important that the eager loading can be disabled. Otherwise it would break community solutions and would personally leave me in a worse css state that I am right now 😅.

Other design concerns/high level issues

Config based router limitations

There are some limitations with config based routers, making them hard to use in a solid-start project:

1. they break when you nest them in the fs router (workaround). If this is not solved, I think there should be atleast a hint in the docs about this limitation and possible workarounds :).
2. they have css foucs in dev, if they are not wrapped in an fs-router. @shiro figured out a way, how we can solve this in solid-lazy-plus, by using a babel transform instead of rollups renderDynamicImport hook.

Vinxi crashes in dev

The dev server has a tendency to crash quickly in some cases, instead of just showing an error in the browser/terminal. E.g when you try import a file that doesn't exist.

Router load + action + server-functions

There is some inconsistency with actions and server-functions, which I think would make sense to be explored before start 1.0: solidjs/solid-router#407.

[shiro]

Vinxi crashes in dev

I think this refers to this vinxi issue? Would be nice to reduce crashes to a minimum before 1.0 IMO 👍

[gabrielmfern]

On issues with Vinxi, I can't really reproduce this, but I've found on and off that it gets into some sort of infinite loop with HMR and crashers my computer. Maybe something related to leaving FS routing and having some parts of pages be client-only, but not sure.

[ryansolid]

CSS

I agree that eager #1 wasn't really an option. I just was trying to weigh the importance of tradeoffs if we weren't easily able to account for all the features initially. It seems given the choice between being lazy and not unloading people would take being lazy.

I agree eagerly along routes removes the ability to be built upon. I'm actually really interested in the viability of #3 or something in between. I understand SFC things like Svelte and Vue have that direct component relationship so they can basically get #3 without having to wire it in. But doing it via URL imports is the only way I can see doing stuff without specific compilation. And we can't do specific compilation to do #3 because we don't know what component it goes in.

But it is from my perspective the only thing I have right now that doesn't require the combination of bundler-aware plugin + API. I'm ok with Start specific (bundler specific) plugins build them in if we need to but not using the standard lazy is awkward. I'm just not quite sure if there is a path to hook into it otherwise. Maybe understanding your solution better might find something here.

Let's pretend in the future something with SolidMeta's capability was in Solid's core. In such a world we wouldn't need 3rd party libs to handle injecting head tags, including style tags it would just happen when mounted/unmounted. We could still use static analysis for preload for initial load but we wouldn't need to include the CSS on the page unless rendered. In that world I think you'd want to do it by component. Which seems to only be by URL.. I think.

Config Based Router issues

To be fair, getting this smoothed out is not of the highest priority. Most things here get better in time but I don't think they are first goal. Mostly I wanted to make it possible to support other routers with the FS more so than having config-based work perfectly with SSR. It's hard. There is a reason every metaframework uses FS routing. It would be great to get around this but I'm being realistic too. Nested routers as well isn't a feature our router supports so again it isn't really going to work cleanly here. And to be fair this is true of all existing metaframeworks to my knowledge.

Vinxi Crashes

To be fair I used to see a whole lot of these. But I know they still happen occasionally. We will have to tackle this issue by issue I think. @nksaraf did some decent work here to improve the situation but I know there is still a few more cases.

Route Load inconsistency

Thanks for reporting I will look at it.

[LiMao00]

I hope solid.js can develop a stronger ecosystem. Currently, its progress seems slow, which makes me hesitant to use it in my projects. It's a pity.

[birkskyum]

There is nothing slow about that adoption curve, but it takes time to grow

[LiMao00]

Why do you think the current ecosystem is good when many libraries named with 'solid-xx' haven't been updated for a year or even several years?

[davedbase]

Why do you think the current ecosystem is good when many libraries named with 'solid-xx' haven't been updated for a year or even several years?

It could be a number of reasons. One could be that Solid core lib has not had a major breaking update in a while prompting the need for library changes. A lot work out of the box. Another is because Solid requires thinner wrappers so breakage might be less of a problem over time. Then there are a good number of those libraries are also abandoned which is a common issue in large and small ecosystems. There usually are forks or redundant libs as a result.

The real question is: what ecosystem utilities do you need to actually work with Solid (or any framework for that matter)? Does that prohibit you from making use of Solid or is there a perception issue that you are blowing out of proportion.

As a 3 year user of Solid all the packages I personally need are well maintained and supported. Mileage will indeed vary, hence why you should investigate further. If you're not convinced then Solid isn't for you.

Good luck!

[LiMao00]

If you only view others' comments from your own perspective and respond with a defensive mindset, piling up examples to argue your point, it can be quite frustrating for me.Good luck!

[thedanchez]

If you only view others' comments from your own perspective and respond with a defensive mindset, piling up examples to argue your point, it can be quite frustrating for me.Good luck!

Not to be mean or sarcastic, but how else do people respond but from their own perspective of matters? 🤔

People share stories and thoughts from their own personal experiences with the hope that it can be helpful to others. And I didn't see any defensiveness in the post shared to you so I think that was an unfair characterization of the reply.

I can understand the ecosystem concerns you have, but here are my two cents -- I think devs tend to miss something important with regard to this particular topic that is also an available option: Just because a "Solid-version" of a JS library doesn't exist, that doesn't stop you from using the vanilla JS version of said library in your Solid app codebase. Sure, it may not be as declarative of an experience since the library isn't in a JSX-declarative form, but that can be viewed as something of a luxury. Perhaps you can make your own local declarative wrapper of the imperative JS library in your codebase and you can get what you're looking for because you're only going to codify the bits that you care about.

Solid itself is pretty close to vanilla JS, perhaps something akin to a light layer on top of it. I've heard people use the phrase that Solid is a state management library that just happens to render which I tend to like.

I raised the earlier point because, sharing my experiences, I myself have made the same mistake in thinking the "ecosystem is not big enough" -- but I was missing the forest behind the tree. The ecosystem is already there because it is all just JS which I would argue you can tap into more easily with how straightforward Solid is compared to React.

I hope this reply helped in some way. Hoping others can chime in and correct me if something I said wasn't accurate.

All the best on the endeavors!

[h4xmd]

Keep up the awesome work team! I can only hope that this library helps push SolidJS higher. You've done well and I've been happy with the tools you have provided so far.

[ryansolid]

Thank you.

[jchatard]

Thanks for the update Ryan.

CSS Topics

I didn’t encounter any of the related CSS issues, or I guess I didn’t look for them. But it makes sense that a lazy component only loads its CSS at request time and we remove it upon disposal.

But avoiding FOUC seems like a priority, in the sense that we tend to choose Solid and SolidStart for its performance, and its Lighthouse score (being a good metric or not is another subject), and FOUC is quite important in that regard.

But my understanding of the challenges in that matter is limited…

Handling Preload Errors in the Router

I’m not sure that this is the same subject, but it looks like it. On several occasions, I had Seroval complaining that a particular data I was sending with load functions wasn’t serializable. But I had to dig through the payload response to understand it (looking for New Error() or the like), which is not convenient, so better error management of corner cases like this would help, even if only for a log statement on the server; that would be a good start.

Global Feedback

I’ve been using SolidStart for almost two years now, maintaining a medium-sized website on SolidStart v0.3.10. It runs great and performance-wise, it’s very satisfying. I’m now rewriting another website frontend closely following the SolidStart main branch, and the DX has improved so much (maybe my understanding as well :-D); it’s a joy to use. I really like the unopinionated approach, and the fact that it’s not fully featured. So that I can choose and then understand what I add and why.

The thing that I’m really looking forward to is the island mode.

It’s so nice to see the project coming close to its first stable number.

Félicitations for the awesome work 🎉

[b3nten]

Maybe a hot take, but isn't the unmounting of CSS a potential source of bugs? Since you can't guarantee that <Foo/> is never mounted when <Bar/> is, by unmounting CSS you're hiding potential conflicts until they're mounted at the same time - and that might be across separate parts of the app (and/or separate teams).

[atk]

We allow for Portal with shadow root for CSS isolation, in case you're unable to prevent leaking styles.

Otherwise, there is a good reason to unmount styles: less memory and CPU consumption for every layout cycle that has to iterate over the rules, whether they apply or not.

[ryansolid]

Looking at this all. I've realized that CSS solutions in other Vite frameworks like Remix aren't that different. I see that lazy loading CSS is important. So without being able to really take an official stance we are going to see how this plays out. I'm going do the bug fixes suggested, but in general if you want proper CSS handling of lazy styles you should use either 2 or 3 above. I won't be making a decision in SolidStart just yet because I don't know the right decision here. It is unclear.

Other than that I've fixed most of the router stuff so on to the RC.