Closed lourot closed 10 months ago
To be completely honest, I'm planning on replacing Vike in this initializer with our headless prerender plugin once it lands as it's far more consistent with our ecosystem (the prerendering setups of Preact-CLI and WMR, specifically).
That's not to say I don't think a vike-preact
package wouldn't be useful, but I'm not sure if anyone has bandwidth to maintain it from our side if we won't be using Vike here.
OK, thanks a lot for sharing @rschristian. Just curious: does the term prerender mean SSR or SSG in your case? Or both?
Generates HTML once, at build.
Whether that's SSR or not depends on your definitions I suppose. It doesn't support on-demand SSR, no.
I see, thanks. We will create and maintain the vike-preact
package at some point anyway, so feel free to ping us and use it at some point if you want your scaffolder to offer on-demand SSR too. Happy to help here.
Also, in general, feel free to let us know if there is anything about Vike that is a blocker for you. We're happy to accommodate Vike for UI frameworks such as Preact.
FYI a Vike user is building an island architecture. It uses React and Vue, but the same could be achieved using Preact.
Fair enough! And I just want to clarify, it wasn't so much that Vike is/was an issue for us, just we have a somewhat established headless prerendering setup that was asked for quite a bit from people migrating from those older tools. A few users were quite overwhelmed with Vike, as it does a lot more than what we'd need, so we needed to look into a more seamless bridge for that gap. If people need that sort of setup or more control I think we'd happily send them towards Vike.
As for islands, I think we're generally pretty covered there -- our community certainly loves the idea and so there's a good handful of implementations already floating around out there (and we have a fairly popular dedicated framework in Deno's Fresh).
👍 Makes sense.
overwhelmed with Vike
So far Vike's focus was to provide a tool for those who need and/or want flexibility. But we're now focusing about developers that want higher abstraction levels and something that just works a la Next.js. That's actually what Vike extensions vike-{react,vue,solid}
are about. We believe, with vike-preact
, there is an opportunity to offer a full-fledged frontend framework (all render modes i.e. SSR/SPA/CSR/pre-rendering, deploy anywhere, HTML streaming, HMR, layouts, etc.) to Preact users that is easier to use than Next.js.
that is easier to use than Next.js.
It's be pretty challenging to make something more difficult to use than Next, I think an easier tool is all but guaranteed 😅
In all seriousness, I totally agree and it sounds like a great leaping point, I just don't think we're super interested in offering that (a framework) ourselves time, due to time constraints w/ what we already maintain and are working on, existing frameworks/tooling that we might not want to directly compete with, and a community that generally has a lower reliance upon frameworks. Preact is somewhat uniquely situated for components & build-less setups, and larger companies using it already have their own tooling they're generally content with. Frameworks & build tooling have, historically, been a big time sink for us without huge benefit to the community IMO.
Will be watching Vike with interest though! vike-{ui-lib}
seems like it'd largely fix the few comments users have raised about what we ship here (that is, just some lower-level stuff being exposed to them), sounds like a great solution.
Hi Preact team, Aurélien from @vikejs here. We saw that
create-preact
is scaffolding projects with Vike, which is really nice.Instead of maintaining your own Vike hooks here in your templates, we recommend moving them to a Vike extension named
vike-preact
. Your templates could then just scaffold projects havingvike
andvike-preact
in theirpackage.json
.We (Preact and Vike) could then for example co-maintain together this new
vike-preact
package shipping the hooks. Andvike-preact
could be used in other scaffolders, like https://github.com/batijs/batiLet us know if you're interested in this collaboration. This would mean less maintenance work for you and less chances of mistakes if we co-maintain these hooks.
CC @brillout @magne4000