Giving up on Qwik

[proud stream]

Hi there, we are thinking about giving up on Qwik for our core application.

I'm going to put you in context to understand our position.

Business/Product/Problem to solve: ERP with custom dashboard/profile based menu and a small but very important part for the business with great interactivity such as dynamic forms.

Our current stack: Nanostores for state management, Tailwind and Modular Forms.

Our approach: We have built the MVP with Qwik and its SSG mode.We are operating with version 1.2.X, and we are having problems upgrading to version 1.5.X (but that's a topic for another thread).

Our premise was to make a SPA, but we have seen that Qwik doesn't support a SPA mode, like Nuxt or Remix, that's why we have moved forward with SSG.

Our question for the Qwik/Frontend "seniors":

1. Did we make a mistake in choosing the SSG approach for such an application?
2. Are we missing out on Qwik functionalities, both performance and development, by not choosing the SSR approach?
3. Is there any approach recommended by the Qwik team in order to manage state, or going with SSR or SSG?
4. Our concern of not going for the SSR approach is that we do not want to put the burden of API calls, navigation, rendering, on the server and leave it on the client, but we are open to new approaches and improvement opportunities.

Thanks in advance and thank you very much for the time and the recommendations you may have.

[golden jolt]

SSG is SPA more or less

for state management with nanostores since it's like signals but you have to manually wire up everything

you lose server$ and routerLoader$ when not going ssr but nothing wrong with just using fetch

this is a good example of CSR fetching
https://github.com/PatrickJS/qwik-ssg-csr/blob/main/src/routes/index.tsx#L20

when you want to speed up SPA you basically end up making an app-shell when is SSG. in Qwik you want to do SSG for CSR. I think the docs can be better explaining why since SSG/SSR are both fine

server$ you can remake to wrap your own endpoints so not much missed there. routeloader and actions are lost only because you need a server for it.

[proud stream]

This is something I read a lot in the last months and I agree with you, we are basically using Nanostores because we share some stores with another NextJS app in a monorepo arch.

[proud stream]

Do you mind explaining this a little more in depth, please? I don't understand it completely.

[proud stream]

Yea I see. Thanks man. I will share this insights with my team. 🙂

[ripe mural]

Our premise was to make a SPA, but we have seen that Qwik doesn't support a SPA mode, like Nuxt or Remix, that's why we have moved forward with SSG.

Can you elaborate on this? Anything with a <Link /> component or with useNavigate should be full on SPA.

--

Our approach: We have built the MVP with Qwik and its SSG mode.We are operating with version 1.2.X, and we are having problems upgrading to version 1.5.X (but that's a topic for another thread).

As a heads up, there was a breaking change in 1.5 that was later fixed in 1.5.1 (no longer breaking). If that might be part of the issue.

--

Our current stack: Nanostores for state management, Tailwind and Modular Forms.

I tried creating a qwik integration for nanostores, it seemed like no matter what I tried, nanostores would eagerly execute the component. (regardless of framework)

Maybe user error on my part 😅 . https://github.com/nanostores/nanostores/issues/174#issuecomment-1949039570

What I currently use, are custom events instead of nanostores. Albeit my example is a tiny app, so may not be the best developer experience large scale.

--

Is there any approach recommended by the Qwik team in order to manage state, or going with SSR or SSG?

Definitely signals & context. Haven't really needed a state manager using signals.

[proud stream]

Sure, Im referring to something like Remix (https://remix.run/docs/en/main/future/spa-mode) or Nuxt (https://nuxt.com/docs/guide/concepts/rendering#client-side-rendering) gives out of the box when starting an application and designing the architecture. Mainly because we do not need the SEO and other pages generated since every page is different in more or less aspects.

[golden jolt]

here is a better repo for CSR examples
https://github.com/PatrickJS/qwik-ssg-csr-only

[proud stream]

Sure we will look into it, we were just focused on building de the MVP and got lost on the version updates.

[golden jolt]

CSR-only in qwik is a lot simpler than other frameworks but it should be better documented. if you do SSG it's basically CSR

[proud stream]

Haha Actually I was following your suggestion on github from the moment you volunteered.
I will propose the signals context approach on the next meeting.

[proud stream]

Just one thing more, what do you think about the 4th point, is SSR a better approach for this kind of apps. Because that is what the docs suggest https://qwik.builder.io/docs/guides/static-site-generation/#ssg-vs-server-side-rendered-ssr
@ripe mural @golden jolt

[golden jolt]

what kind of app do you have

if you have access to deploy backend code like a lambda/cloudflare worker etc then SSR would be it easier. otherwise if you don't just use SSG

[proud stream]

It is a CRM-ERP with a lot of profile/role based content

[proud stream]

We are using Azure to deploy our apps and we were having some pain points with that aswell hahah

[golden jolt]

well Qwik is better for that since you can have unlimited features with less js being shipped.

are you using this? I haven't used azure in years
https://qwik.builder.io/docs/deployments/azure-swa/

if you can SSR it would be great to do it otherwise SSG->CSR is fine

Modular Forms has a signal-only version. if you drop nanostore then it will be easier just using signals

[celest sonnet]

This is really what i was looking for, thank you so much for example