teekoiv

Right. So a custom build system which changes the built pages from dynamic path folders to named folders in a day. No bugs. Sure. Also I serve rich-text content with links so those gotta be rewritten as well.

That's cool but I fail to see how this results in 100% static bundle.

It doesn't really matter from user's point of view if the response is 200 or 404 if the end result is the same. This is just a rendered web page after all. But yeah, you can get stuck in the semantics of it but I personally just use what works and move along.

No. I disagree, you have to refactor all the pages from using [pathId] folder pattern and change all the links including switching to useSearchParams. It's just a huge change, especially if I want to keep the old routes in my web app.

Interesting. You can set up the server to respond with 200.html as the catch-all so the requests would return 200. There was some issue with it—can't remember what—which is why I switched to 404.html. After the initial load though the subsequent navigations would go through pushState so I think they'd be cached.

But I don't see this is as big of a problem. With this I can switch and choose—SSR dynamic pages or use hacky catch-all mechanism. For any reasonably large site you probably would SSR for SEO and other purposes. But for completely offline apps I have to do zero extra work to render them as is.

Personally, I much prefer route paths vs query parameters not just because they look ugly but because they lose hierarchy. Also, you can't then just decide to SSR the pages individually as they're now permanently fixed to same path.

It doesn't. Those are executed build-time and you can't just set a wildcard so anything outside the given set results in 404.

As background, I wanted to make a PoC with NextJS bundled into a static CapacitorJS app somewhat recently and had to give up because of this.

You can try tricking NextJS by transforming the pages into "normal" ones with eg query parameters instead of path, but then you need complicated logic changing the pages as well as rewriting links. As you of course want the normal routes in web app. Just a huge PITA.

Yeah, what the other commenter said. getStaticPaths still requires you to define the rendered routes build-time

It's baffling to me why more SSR frameworks, Astro and NextJS namely, can't adopt static pages with dynamic paths like SvelteKit. So for example, if you have a page /todos/[todoId] you can't serve those in your static bundle and NextJS straight-out refuse building your app statically.

Whereas with SvelteKit, it builds happily and does this beautiful catch-all mechanism where a default response page, say 404.html in Cloudflare, fetches the correct page and from user-perspective works flawlessly. Even though behind the scenes the response was 404 (since that dynamic page was never really compiled). Really nice especially when bundling your app as a webview for mobile.

Runes annoy me because they ruined the use of Svelte components as rendered widgets outside a Svelte site. I like using them in rich-text as rendered views but when Svelte 5 came out, the old way of simply setting the component props directly was thrown out and you implicitly are now expected to use runes for the props you pass to the components.

Which means, that anywhere I render those components I have to suffix the file as .svelte.ts Or switch to svelte/store but it's quite dumb to wrap everything as a Writable<T>

I still like Svelte regardless, but I just thought "why" as over-abstraction wasn't the original tenets of Svelte

Well I'd say this is rather clumsy attempt with no real upside on my side. 10% of imaginary profits for giving access to my computer, IP, Upwork—not even taking into consideration the illegality—with zero guarantees I'll see a single cent.