benmccann

Immich has a concept of storage template, which you can use to set the directory layout using year and month and maintain the original filename.

We're not arguing against it, but simply haven't committed to doing or not doing it as Svelte 5 has been higher priority. We would rather be deliberative than introduce a feature where we don't have the developer experience fully thought out. We want to understand what the experience would be for Svelte users both with and without SvelteKit and have good guidance around the trade-offs of different rendering modes.

You can catch the rest of the Svelte Summit, which is still going on for the next hour with the grand finale still to come: https://www.sveltesummit.com/2023/fall

Reactivity is faster now: https://twitter.com/Rich_Harris/status/1688581184018583558

And the output from the compiler is much smaller. You can compare the output on the Svelte 4 REPL to the output on the Svelte 4 REPL. The runtime has grown a bit, but the output overall is still much smaller even when factoring that in

This set of changes makes things more explicit. That's the opposite of a black magic box as far as I can see

No, runes like $state do not need to be imported. They're similar to import() that they look similar to functions, but are keywords built into the language.

adapter-static is meant for generating fully static sites. It's fundamentally not aiming to and cannot support SSR in that context. However, SSR is fully supported in adapter-node, which is well maintained.

INP feels like a pretty problematic way to compare sites because INP is going to be way lower on a site that doesn't do client-side rendering eventhough client-side rendering makes interaction with a site faster!

That N is very large. E.g. here's a page that talks about it: https://github.com/halfnelson/svelte-it-will-scale. I'll note that was done with Svelte 3 and that with Svelte 4 components are at least 10% smaller, so it's actually even better than that. SvelteKit is also very efficient at JS splitting per-route thanks to Vite. It ensures only the JS that is necessary for a page is loaded and you're extremely unlikely to be using anywhere near that many components. Based on the article above, you'd have to have three entire sites worth of components on a single page.

A lot! Sourcemaps are often twice the size of the code itself.

There are tradeoffs there. E.g. many of Svelte's dependencies are shared by bundlers such as Vite, Rollup, and their plugins. If you bundle those dependencies it means they have to be downloaded multiple times. It also means you can't use the cache from efficient package managers like pnpm. And lastly, it makes it harder to deal with security issues. If there's a security issue in a dependency then Svelte would need to ascertain whether it could affect users, upgrade the dependency, and file a CVE against Svelte itself. Users would then have to upgrade Svelte in addition to the dependency if it's shared by any other libraries.

> global exit transitions

you'll be happy to know that those are no longer the default in Svelte 4!

Can you clarify how you would normally switch tabs and why that's difficult? If I open up a bunch of `+page.svelte` files I see them as "+page.svelte ../docs" or "+page.svelte ../blog" and so it's fairly obvious which one is which to me. Longer-term, I think we can tweak VS Code to get rid of the duplicate "+page.svelte" part as it is duplicative and unnecessary, but I don't find it unworkable at the moment. I'm wondering if it's simply that we have different tolerances for this or if there's something else going on in some cases.

Some people have mentioned liking to set the label format to short under File > Preferences > Settings and then search for Label Format.

How would you otherwise navigate that you find difficult with SvelteKit?

I haven't had much trouble in VS Code since it shows the directory name just after the file name. Some people have mentioned liking to set the editor tab label format to short. Go to File > Preferences > Settings then search for Label Format.

I'm hoping https://github.com/microsoft/vscode/issues/41909 will get implemented so we can make the problem go away entirely

It's referring to all transitive dependencies - not just direct dependencies. More like this: https://npm.anvaka.com/#/view/2d/vue

As far as I'm aware, SvelteKit has fully supported Deno since 1.17.0: https://github.com/sveltejs/kit/blob/master/packages/kit/CHA...

@dang https://news.ycombinator.com/item?id=36432447 was on the front page and has substantially more discussion. It was somehow marked as a duplicate of this post. Could you merge them?

One of the things released today was dedicated documentation for TypeScript: https://svelte.dev/docs/typescript. The site was also updated today to include a JS/TS toggle so that you can see all the examples written in TypeScript if you prefer it to JS.

I'm not sure how long ago you tried or what issues you ran into, but hopefully this will help with getting started with Svelte and TypeScript much more easily.

I was skeptical at first when we made the change in SvelteKit. However, SvelteKit has a large integration test suite and being able to change the code and rerun the tests against the real final version of the code without waiting for any build step to complete has been a big improvement to productivity and I'm now a big fan of having made the change there. The tradeoff may be a bit different in Svelte core where we have more unit tests and fewer integration tests, so we're still investigating and considering the change, but we do have experience with both approaches and at the end of the day great software can be built using either approach.

Svelte will still provide type definitions. We're working on Svelte 4 currently and are taking the opportunity to make a few small breaking changes to the type definitions for improved TypeScript support: https://github.com/sveltejs/svelte/blob/version-4/CHANGELOG....

We'll cut a preview release soon and would love help testing and feedback from folks that have given it a try.

Here's an amazing version that was recently written using Svelte, HTML, and CSS! https://wolfensvelte-3d.vercel.app/

You're asking for two things that seem largely incompatible. How do you expect to do SSR in a Go-gin or Django app? Svelte components get compiled to JavaScript and SvelteKit is written in JavaScript. Doing SSR in those frameworks would necessitate calling JavaScript from Go or Python and introduce far more complexity if you could get it to work at all. The simplest options are either to run a Node server or turn off SSR, which you can do with 1-line in SvelteKit.

> And it's a lot of money (e.g. 30% loss on $200bn is about $600 per US resident household).

I'm not sure where you got this number, but it's different than what I've seen. Yes, SVB had $200B in deposits, but it had $15B in unrealized losses. The FDIC is probably contributing $12B as roughly 6% of deposits were insured. That means the gap is probably $3B if the government is to step in, which is very different than the $60B you're suggesting. If these instruments can't be held to maturity then the losses may be greater as many of them are illiquid and would have to be sold at a discount, but the government has the liquidity to avoid that.

https://learn.svelte.dev/tutorial/introducing-sveltekit was built with web containers. SvelteKit allows developers to create server-side APIs and do server-side rendering and web containers allow those server-side components to run in the browser.

It appears that it has been. However, it's still a Samsung and not a Qualcomm. Qualcomm was used on Pixel 5 and is used in most other smartphones on the market including iPhones.

From https://www.androidpolice.com/google-tensor-g2-cpu-cores/

> Other improvements include a new modem — the Samsung S5300 — which will bring support for access to both unlicensed spectrum as well as satellite reception through 5G

This is compared to the Samsung 5123b used in the Pixel 6 Pro

It has been fixed

It has been fixed

Most apps I've seen can upgrade to Vite 3 without any changes. While there are breaking changes, there aren't a lot and they're not very big.

It sounds like you might have some misunderstanding. You can write SSR applications with Vite, but each framework or application is responsible for the rendering. There isn't really such a thing as an SSR runtime in Vite. It will run code on the development server in SSR mode, but all it does is make sure it's picking up code updates and passes it through to Node.js.