As discussed in #2, we want SSR. It has emerged through experimentation that neither Next nor Remix are great choices to do this for this application.
Rolling your own SSR with routing, etc in React is not fun. So, I investigated a Svelte/SvelteKit rewrite and SvelteKit works to my satisfaction. From a tooling perspective, SvelteKit focuses on having a very minimal runtime, which I appreciate; there are zero non-dev dependencies that are not third party libs used directly by the application. It has none of the performance problems Remix did, and I'd argue it has a much better-designed router than Remix or Next.
Finally, Svelte (with SvelteKit's router) has much improved the "bidirectional" link between the URL and the search form, removing hacks we had to use with react keys.
Rewriting to use Svelte's more... tailored component format also gives us the nice benefit of substantially smaller browser bundles.
The biggest cost of using SvelteKit is generally in the tsserver/lsp integration, which I find to be measurably worse in emacs. But, if it all works at build time, I can deal with it.
Svelte's handling of whitespace in inline-block elements is also pretty brutal, faithfully recreating the terribly unintuitive behavior of HTML. But, with trial and error, I have dealt with it.
With the introduction of SSR, the most notable change is that preferences are now persisted in cookies instead of localstorage, so that they may be used during SSR.
Alright well the fly.io deployments are failing due to obscure docker problems. The docker image pulls are simply failing. Unclear how this could be related to these changes, I think fly may just be struggling.
As discussed in #2, we want SSR. It has emerged through experimentation that neither Next nor Remix are great choices to do this for this application.
Rolling your own SSR with routing, etc in React is not fun. So, I investigated a Svelte/SvelteKit rewrite and SvelteKit works to my satisfaction. From a tooling perspective, SvelteKit focuses on having a very minimal runtime, which I appreciate; there are zero non-dev dependencies that are not third party libs used directly by the application. It has none of the performance problems Remix did, and I'd argue it has a much better-designed router than Remix or Next.
Finally, Svelte (with SvelteKit's router) has much improved the "bidirectional" link between the URL and the search form, removing hacks we had to use with react keys.
Rewriting to use Svelte's more... tailored component format also gives us the nice benefit of substantially smaller browser bundles.
The biggest cost of using SvelteKit is generally in the tsserver/lsp integration, which I find to be measurably worse in emacs. But, if it all works at build time, I can deal with it.
Svelte's handling of whitespace in inline-block elements is also pretty brutal, faithfully recreating the terribly unintuitive behavior of HTML. But, with trial and error, I have dealt with it.
With the introduction of SSR, the most notable change is that preferences are now persisted in cookies instead of localstorage, so that they may be used during SSR.
Closes #2.