[teekoiv]

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.

[littlecranky67]

I partly agree with you, but it is a design decision that comes with a drawback. A URL /todos/123 cannot be resolved in a SPA in a hard-reload. I.e. if a user were to bookmark /todos/123 or press reload in the browser, the browser would ultimately ask the underlying HTTP server for that file. As you mentioned, you would need a 404 page configured to fetch that - but that requires a configuration in the HTTP server (nginx etc.). So you are not just a static html+js+css+images deploy, you always will need server support. Another issue is, that 4xx errors in the HTTP spec are treated differently than 2xx: most notably, browsers are NOT allowed to cache any 404 responses, no matter what response header your server sends. This will ultimately mean, those /todo/123 bookmarks/hard-reloads will always trigger a full download of the page, even though it would be in the cache. And again, you would always need support in the web server to overwrite 404 pages. While the current NextJS output can be just deployed to something like github-pages or other webspace solutions.

Now, these are just the limitations I can think of, but there are probably more. And to be fair, why "break" the web this way, if you can just use query params: /todo?id=123. This solves all the quirks of the above solution, and is exactly what any server-side app (without JS) would look like, such as PHP etc.

[degamad]

> if a user were to bookmark /todos/123 or press reload in the browser, the browser would ultimately ask the underlying HTTP server for that file. As you mentioned, you would need a 404 page configured to fetch that - but that requires a configuration in the HTTP server (nginx etc.). So you are not just a static html+js+css+images deploy, you always will need server support.

> use query params: /todo?id=123. This solves all the quirks of the above solution, and is exactly what any server-side app (without JS) would look like, such as PHP etc.

We had PATH_INFO in virtually every http server since CGI/1.0 and were using it for embedding parameters in urls since SEO was a thing, if not earlier. Using PATH_INFO in a PHP script to access an ID was pretty common, even if it wasn't the default.

By way of example, here's a sample url from vBulletin, a classic PHP application <https:/ /forum.vbulletin.com/forum/vbulletin-sales-and-feedback/vbulletin-pre-sales-questions/4387853-vbulletin-system-requirements>[0] where the section, subsection, topic id, and topic are embedded into the URL path, not the query string.

[0] https://forum.vbulletin.com/forum/vbulletin-sales-and-feedba...

[teekoiv]

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.

[exiguus]

Maybe i misunderstood you, but I did dynamic routes/pages for Next and Astro static builds. Using contentful or storyblok as a CMS, where the editor defines the routes and the components/bloks per page. Basically, the projects had one slug like [...slug].

Routes and Components per Page are dynamically created while export Next or build Astro static pages. In both frameworks you create the pages / slugs via getStaticPaths. And if ISR/ISP is enabled, even new pages (that are not known during build time) are pre-rendert while running the server.

In Next it is called dynamic routes[1] and in Astro dynamic pages[2]. Catch all slugs in Next and Astro are [...slug] e.g..

[1] https://nextjs.org/docs/pages/building-your-application/rout...

[2] https://docs.astro.build/en/guides/routing/#example-dynamic-...

[dschuessler]

Maybe I am misunderstanding you, but isn't this what Astro's `getStaticPaths`[0] function is for?

[0]: `https://docs.astro.build/en/guides/routing/#static-ssg-mode

[threetonesun]

I think since they used [todoId] in the example they mean a static page which does not exist at build time. Which both can do, it’s called ISG (or on-demand in the Astro docs), but it requires a server to work, or you can create a static route that accepts any parameters and pass those to JavaScript to run on the client.

[teekoiv]

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

[arminluschin]

I’m also a big fan of static, and nextjs supports this: https://nextjs.org/docs/app/api-reference/functions/generate...

[teekoiv]

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.

[nchmy]

I might not be understanding you (or the various frameworks) completely, but are Astro's server Islands what you're looking for?

https://docs.astro.build/en/guides/server-islands/

[nchmy]

Or, actually, https://docs.astro.build/en/guides/on-demand-rendering/

[steve_taylor]

You can indeed do that with Next.js. In the app router, it’s called generateStaticParams. In the pages router, it’s getStaticProps.

[pheew]

This isn't the same as getStaticProps is evaluated at build time not runtime