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.

I very much agree with the overall thesis of the post. Runes are just irksome in subtle ways.

One big point that the post misses, is that the Class escape hatch for runes is incompatible with constructor-set parameters.

Say you have a class that wraps a HTMLElement which you set in the constructor. This doesn't work:

  class Wrapper {
    dom: HTMLElement = $state()
    constructor(el: HTMLElement) {
      this.dom = el
    }
  }

as TypeScript throws an error about `Type 'undefined' is not assignable to type 'HTMLElement' for the $state()`. You could fix it by eg. `$state(undefined as unknown as HTMLElement)` but that's dumb. Interesting enough you could do something like:

  class Wrapper {
    dom: HTMLElement
    constructor(el: HTMLElement) {
      let d = $state(el)
      this.dom = d
    }
  }

Moreover, Vite/esbuild mangles class-field parameters with esnext into constructor-set parameters as they are just more versatile. So the original code becomes something like:

  class Wrapper {
    constructor(el: HTMLElement) {
      this.dom = $state(el)
    }
  }

Which is incompatible with rules of runes. I did whine about this already https://github.com/sveltejs/svelte/issues/14600 but so far no clear answer

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.

Damn. I did use webmidi to wrap the access but apparently there's something missing. Works with my MPK3. Thanks for the feedback.

Great job on launching! It sure does feel good to ship something and get a positive reaction. I don't want to steal your thunder but I did something similar a year ago and posted it here with a fresh HN account without much fanfare.

https://midi-note-trainer.teemukoivisto.xyz/

I maybe put even too much effort in it, all those different keyboard layouts and all. But I am happy with the end result and noticed it did actually work. For me, the most important thing was (and still is) just learning music notation. Maybe one day I'll make a v2.

  Location: Helsinki
  Remote: Yes
  Willing to relocate: No
  Technologies: JS/TS, HTML/CSS, NodeJS, Svelte, React, Vue, ProseMirror, Tailwind, AWS, Terraform, Postgres
  Résumé/CV:  https://teemukoivisto.xyz/cv
  Email: [email protected]

I'm a full-stack dev of 6 years who is interested working on some Svelte or rich-text related project or anything else in the realm of TS with some infra or databases sprinkled on top.

  Location: Helsinki
  Remote: Yes
  Willing to relocate: No
  Technologies: Rust, TS/JS, NodeJS, Svelte, React, Terraform, Ansible, ProseMirror, HTML/CSS, Tailwind
  Résumé/CV: https://teemukoivisto.xyz/cv
  Email: [email protected]

I have 6 years of work experience with webdev and rich-text but I've come interested in learning Rust. During the past 1.5 years I've taught myself the basics and programmed a game engine (with a friend) in Rust with multiplayer (Rapier, tokio, axum, Flutter) as well as websocket server for collaborative editing.

I'd consider myself moderately skilled in getting stuff done with Rust but there's still a lot to learn about the intricacies of memory management and general best practises. So I'm looking for opportunities where I could write Rust with perhaps some webdev on the side.