I couldn't actually figure out what you were trying to do here, but there are a few points I do understand, and can answer:
1. If you want to bind a property it needs to be declared. This is the method of least surprise.
2. I've been running three Svelte sites in production for more than a year now, and 80% of our traffic is iOS. The sites work fine, it's the tutorials specifically, probably because of the embedded REPLs which have an iOS issue.
3. You claim that the Svelte code runs later than the server-generated HTML. This makes sense, since the DOM from Svelte components is built using Javascript. If you wanted to generate Svelte code on the server-side so that it renders at the same time, you would use { ssr: true } in your rollup config and generate code for both server and client side.
4. Not sure what the notion of lag is or where it comes from, Svelte outperforms everything else (when I last checked benchmarks), and is likely to, since it has the immediate advantage of not requiring a client-side runtime to download before it starts execution.
Thanks for replying. In my previous post, I just wanted to share my experience as someone who has used Svelte (for few days, though, nowhere close to how much you have).
1. I just missed the part of documentation that talks about optional properties. And with undefined and null issue, it's a bit surprising that two-way bindings behave differently that 1-way. Passing null or undefined is convenient when an API gives you such values and they represent empty there.
2. Ok. What I feared is that the tutorial would turn out not to be bugged, and Svelte would be a bad choice for CPU-intensive SPAs. Thanks for reassuring me that's not the case. I'd still love to see the fix for the tutorial bug (because at the first glance, there isn't anything that screams "wrong!" in its code).
3. Yup. I just wanted to point out it's noticeable if you look for it. I will look into SSR later.
4. Same as in point 2.
BTW I just wasted 2 hours fighting with bind:group[0][1]. This issue is an example of what I meant by saying that people may want to wait before jumping on Svelte.
1. If you want to bind a property it needs to be declared. This is the method of least surprise.
2. I've been running three Svelte sites in production for more than a year now, and 80% of our traffic is iOS. The sites work fine, it's the tutorials specifically, probably because of the embedded REPLs which have an iOS issue.
3. You claim that the Svelte code runs later than the server-generated HTML. This makes sense, since the DOM from Svelte components is built using Javascript. If you wanted to generate Svelte code on the server-side so that it renders at the same time, you would use { ssr: true } in your rollup config and generate code for both server and client side.
4. Not sure what the notion of lag is or where it comes from, Svelte outperforms everything else (when I last checked benchmarks), and is likely to, since it has the immediate advantage of not requiring a client-side runtime to download before it starts execution.