Until you try to do something svelte doesn't understand. Then it'd silently break. Templates are powerful _because_ of the restrictions they place, not in spite of them.

I think a much better recommendation would be an existing template language, iff svelte could understand it with perfect parity.

I hate being handed normal syntax to use when not all of it is normal, or when using it has different semantics than the syntax usually carries.

I was saying elsewhere on the thread - I am not suggesting that each should be turned into a runtime call. Instead, 'svelte.each()' callsites are easy to identify in the AST and transform in the compiler.

So the errors remain compile-time, not run-time.

The danger is that a developer will use `svelte.each()`, thinking it uses the same rules as normal JS syntax, but it turns out Svelte applies its own rules which _are_ slightly different (hypothetically).

So the developer must remember a new rule: "JS rules when calling foo.each(), Svelte rules when calling svelte.each()". A little harder to remember. Having a unique non-JS syntax makes the distinction obvious.

(Just playing Devil's Advocate here)

That's a pretty reasonable argument and I believe a big part of what makes hooks somewhat complex since they look like regular Javascript but can behave differently.

FWIW, I did a mini-study a while back about the different possible syntaxes. It turns out there's more than meets the eye wrt what control flow structures need to do, and there are also DX reasons why the dedicated syntax might be more desirable: when you consider all permutations of loop flavors - w/ else clauses, keyed, exposing index, etc - the DSL consistently came out on top in terms of succinctness and readability (for an average developer familiar w/ algol-like syntax).

There are also technical reasons why `svelte.each` would be problematic, namely the fact that it is a compile-time concept which does not necessarily compile correctly if you move the call into a library, unless you have an extremely sophisticated compiler (aka: a slow compiler)

> There are also technical reasons why `svelte.each` would be problematic...

I am not suggesting that the svelte.each() call be moved into a library; I'm proposing that the callsite is trivial to identify in the AST. Svelte compiler could then do the same thing that it does now.

Yes, parsing is trivial, but compiling (in the traditional sense, not the transpilation sense) is a different story. The other sibling comment nails it.

Grammar enforces where a grammar construct is allowed to exist. A custom grammar can be very restrictive (which it is, to great effect, in Svelte's case).

If we reuse JS grammar, then that comes with expectations of what should semantically work. For example something as simple as `$ = svelte.each` might evade a not-sufficiently-smart compiler. Or maybe `console.log(svelte.each(...))` might mis-compile because nobody ever thought to handle that case.

Having used systems with compile-time grammar constructs that look like runtime constructs, I can tell you that having your expectations about semantics being changed from under your feet can be a very frustrating experience.

You're right about it being complex (my experience [1]), but such work is within scope for what's perhaps a central design decision for a library. Yes there'll be bugs, but it'll stabilize over time.

Just to be clear, I am NOT saying that Svelte needed to do this. But merely suggesting options for discussion and learning.

[1]: https://github.com/jeswin-unmaintained/isotropy-ast-analyzer... - Here's for instance, some code I wrote for analyzing a JS sort expression. You'd think it'd take just a few hours, until you get to it. Btw, it uses an AST analysis framework I wrote called chimpanzee - it has only one user though. :) https://github.com/jeswin/chimpanzee

To deal with the issues they're talking about, you usually end up encumbering `svelte.each` with limitations such that it only looks like Javascript superficially.

In such a case, I think it's less confusing at the end of the day to just have a custom DSL for looping so that there's no clashing with its list of arbitrary limitations.

I think you are persistently suggesting something to someone who knows more than you, without taking the proper time beforehand to understand the problem space.

I do believe I understand the problem space well enough to comment on it - both AST analysis and frontend frameworks. My comment above also included a clarification that I was not suggesting that this be turned into a runtime call. Just presenting an entirely subjective viewpoint (of avoiding new language syntax), but one that many people share.