#Choosing between Nextjs vs. Vite for a v2 Desktop App

1 messages · Page 1 of 1 (latest)

hollow gyro
#

Hi, are there any pros/cons in choosing between Nextjs vs. Vite for a Tauri v2 app?

reef elm
#

Both are fine choices, but it's good to know that Tauri wants something completely static to serve, so Next's SSR will be fairly useless, and you'll probably be using tauri commands instead of Next's API functionality.

#

If Next with no API side and forced static site generation is still worth it to you to use it, go for it. Otherwise, I'd just use vite.

#

I haven't used Next in a while, is there anything really left at that point beyond routing?

hollow gyro
#

Hard to tell, from what I can tell it's "just enough" to get things to render, but I know next nothing about either Nextjs or Vite. Hence, the question 🙂

reef elm
#

they're not really directly comparable, though they implement many of the same features: dev server/hot reload, bundling, stuff like that. But vite basically stops there and next adds routing, image optimizations, SSR (which vite I think can have a hand in with server components or can delegate to other code at runtime but not to the same extent), and an API layer.

#

I think it probably comes down to routing. Do you like the file-based routing that Next offers, or are you going to use a single-page app or bring your own router instead? In that case, I'd probably go with vite.

hollow gyro
#

Thanks for the feedback. I'll try switching to Vite and see what that looks like. Cheers!

lilac kiln
#

I have a similar issue I'm facing... I have a NextJS app I'm generating statically to build with Tauri, and it works great until I need to access a URL that wasn't available at build-time -- for example, a user created a new item and wants to view the item. so they visit /deck/[lang]/phrase/[phrase_id] and get a 404 even though the phrase exists. I can pre-render all the layouts up through /deck/[lang]/phrase/layout.tsx but then I want to handle just the final route segment (the phrase_id) on the client side, including both routing and rendering. It seems like maybe Solid Start will do this? is there anything else that's recommended for folks who want to pre-render a bunch of static shells for their routes, and then have a client-side router take over after the first load?

#

I am actually rewriting my NextJS app with tanstack/router right now (or SvelteKit SPA... I'm kind of doing both to see what's good) but both of these options will take me in the other direction of full SPA with no static loading shells (or just the one for the whole app) -- so I'm just wondering if this is like a common pattern that others are trying to implement and if there are "favourite" approaches for it

reef elm
# lilac kiln I am actually rewriting my NextJS app with tanstack/router right now (or SvelteK...

I think SPA or a few high-level, generalized pages is probably your best bet in that case. Because Tauri doesn't have proper http backend (it uses IPC instead), it doesn't really have support for any kind of dynamic routing, because they'd have to generalize it to every possible case, to work with every framework, which I think would probably be beyond scope for Tauri, since javascript routers and SPAs do exist.

#

part of the reason Tauri is so fast is because there's no requests happening to load the UI (at least, outside of dev mode), only IPC calls, which are quite a bit faster and more than even a localhost http server. Not to mention you're not using memory to run an extra process.

lilac kiln
reef elm
lilac kiln
#

i didn't mean it like that. I have spent the last few weeks trying rewrites with Svelte, Tanstack Router, and now SolidJS and I think the Solid rewrite will probably stick 👍

reef elm
#

gotcha

#

well, good luck!

lilac kiln
#

thanks!