Nextjs like Static site generation, stabilizing start-static would be okay

[nksaraf]

No description provided.

[nksaraf]

This comment has a bunch of good ideas so copying here for reference

#17 (comment)

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!

[ryansolid]

In setting up for SolidStarts next Beta Phase built on Nitro and Vinxi we are closing all PRs/Issues that will not be merged due to the system changing. If you feel your issue was closed in mistake. Feel free to re-open it after updating/testing against 0.4.x release. Thank you for your patience.

See #1139 for more details.