[Umbrella] Starter Features

[kaushalyap]

Given below are things I would expect from a solid starter

• [x] #153
• [x] Per route code splitting
• [x] #154
• [x] #155
• [x] Stable SSR support
• [x] #156

[ryansolid]

Cool I think we have most of those already thanks to the preload scripts we do and Vite's CSS handling. Routes are automatically code split etc.

I think the Static adapter needs some work since I've never used a product that does this so I don't know the gaps and still doing improvements to SSR but I don't expect the APIs to be breaking, just augmenting some of the behavior around streaming.

Most of the work beyond stabilizing the build and config is around parallelized data fetching, caching, etc. API service offerings etc.

Edit: you probably mean navigation preloading not initial page assets preloading. We are working on that too but it isn't done yet.

[ryansolid]

Actually if you or anyone has ideas for the static adapter that would be great. I have no idea how these other solutions work here and it would save me a lot of footwork if someone familiar could help layout the requirements for that part specifically.

[TheFedaikin]

Just my two cents here on the static adapter. This is an adapter I am looking forward to the most, but unfortunately wasn't able to help or even play with it as of now, so hopefully I can help with a pain-points other SSGs have. All of this is personal/team experience after working with this kind of frameworks for the last 3 years.

FIrst of all, I've used Vuepress, Nuxt, Gatsby, Gridsome and Next as SSGs and I would say React based ones are the most feature-rich and kind of leading the way on most of this stuff, probably due to React share of the FE market, so I'll probably focus on these first and give you thoughts from my experience on working with them. But before that I'd like to note that I will not touch routing since Solid's official routing solution looks really good and is very flexible to build our own higher-order SSG or whatever it is you want. So this stuff is covered already, and as you mentioned before, Vite actually does a whole bunch of things out of the box, so I'll omit them from here too. I also think that Vite allow you to edit your index.html file easily, and in some of these frameworks this stuff was painfully abstracted away (like in Next) and sometimes you have to go against tutorials to get the desired outcome, if you are working with external scripts.

Gatsby

Good stuff

• Plugin system - it's really good, some of them work really well, some of them one-two fixes away from having the desired functionality. I don't think it's even the right discussion to be had here, but maybe the lesson from this is providing clean api to extend basic functionality of any adapter will go a long way. I'd say bringing official plugins for PWA and other stuff is really good for adaptability and feature parity with frameworks like these.
• Markdown/MDX support - self explanatory, very good stuff.

Sad stuff

• Build times - they are okaish, but could be a lot better I feel. It's actually was getting a lot better with latest releases and paid cloud platform stuff lately, but I am not using it anymore, so I don't really know. I think Solid's performance with SSR is orders of magnitude better than React, so it's something Solid will get for free even in the one thread scenario, unless fetching is a bottleneck.
• Data layer - it's HEAVILY opinionated and I don't even hate GQL. But sometimes it felt really cheesy doing the filesystem query through it. You can opt out, kind of, but it's not well designed in the first place. I think there's a discussion to be had about an ability to separate the data-layer from the presentation. The way it works is you have multiple "different" styles of doing that, but they are the same in the end - your query is tied to page/component that you are writing your query on and it's very limiting. You have to props drill/use some sort of mechanism to share this data or copy-paste your queries (I think they are batched when you are generating pages, but still it feels kind of wrong). You can do stuff with thier node-api here, but it's not really solving the underlying issue. I don't know what kind of an api will solve the data layer problem, and maybe it's a wrong discussion of how we want to query for stuff so we can easily share it within code, but since Solid's compiled and components works differently I don't mind using context here, but in React it's very sad stuff. If we agree this is something to be tackled I can help with sketching/proposing an api.
• Window tackling - feels SUPER hacky here, no real mechanism to avoid build failures except for stubbing window/adding insane amounts of checks. Very sad stuff.
• Image optimization - good by itself but only works for the local stuff and sometimes plugins were not build to download these images to then optimize them, which made me/team I was working with write our own to download images first. It's more of a community problem I think, but maybe there was an API for plugin creators that would greatly simplify it.

Next

Good stuff

• Internationalization - really good, but I wouldn't say it's not about SSG adapter, it's not a priority and it's also, probably a LOT of work.
• Per-page Layouts - api a little ehh, but in general much cleaner than in Gatsby, for example.
• First class aliases from tsconfig - self explanatory

Sad stuff

• getStaticPaths - it's really sad, actually. I understand the design choice here, but damn it's really limiting. The fact that you cannot supply data alongside your parameter of choice is a shame. You probably want the same mechanism, but also add the option to supply data directly without getStaticProps. Something like getStaticData and returning an array with ids/slugs and data/props field in them, where you directly supply props to them.

Nuxt

Good stuff

• Page transitions - nice touch, probably not hard to implement
• Loading - also very nice touch.
• Live preview - also was present in Next but I liked it better in Nuxt

Sad stuff

• Honestly, I don't remember, since this was my first JAMstack framework and I remember being blown-away by it.

It's pretty much all that I have on top of my head, hopefully it'll help!

[kaushalyap]

@TheFedaikin Thanks for sharing your experience!

I think there's a discussion to be had about an ability to separate the data-layer from the presentation.

This is probably opinionated, Is not it nice to have data and presentation in the same file. IMHO it is easier to reason.

You have to props drill/use some sort of mechanism to share this data or copy-paste your queries

Cannot you use React Context in such scenario? if it is static page copying a query is still fine than introducing unnecessary abstractions.

Window tackling - feels SUPER hacky here, no real mechanism to avoid build failures except for stubbing window/adding insane amounts of checks. Very sad stuff.

Assuming you are saying about browser window object, there is something in docs you might have seen, but there is not much if checks. Alternatively you can use environmental variables

Per-page Layouts - api a little ehh, but in general much cleaner than in Gatsby, for example.

I do not see any difference in Gatsby and Next in this regard both seems to be wrapping page content with a other component.

I may be bias towards Gatsby since I only have experience with it.

What about Gridsome experience? Have not tried anything in Vue at all.

[TheFedaikin]

Cannot you use React Context in such scenario? if it is static page copying a query is still fine than introducing unnecessary abstractions.

React Context is fine, but if you use it with just regular React useState you have to be VERY mindful with what you put into it, or you can end-up re-rendering whole page (or you can be doing memoization everywhere to avoid that, I guess), and if that was the case I was just copying the query

Assuming you are saying about browser window object, there is something in docs you might have seen, but there is not much if checks. Alternatively you can use environmental variables

I really hate require and this is really ugly. Ofc I've seen it and used it, but I remember having like 50+ checks for it across the project and wondering if there's a better way.

I do not see any difference in Gatsby and Next in this regard both seems to be wrapping page content with a other component.

I think it's actually the same, it maybe was different in Gatsby V1, but I might've also mixed them in my head, you are right here.

What about Gridsome experience? Have not tried anything in Vue at all.

Nothing worth noting that I didn't mention in other frameworks, overall it's poor man's Gatsby on top Vue. Even though I really prefer Vue to React I used it in one project and later migrated it to Nuxt, so not that much experience here.

Again, I think most of these pain-points would not be present in Solid at all, but some of them maybe will spawn discussion, so posting my grievances here for posterity.

Thanks for the response!

[nksaraf]

Created individual issues for some tasks that require documentation mainly #154, #155 since they are supported by vite out of the box. Created a separate issue for tracking the preloading on navigation since that's an important issue #153. And another one for tracking the progress on start-static. It difficult to track everything in this one issue. #156