5 ms·

But I wish new frameworks stayed away from inventing new language syntax. Not only is it a cognitive burden on programmers, it throws all the tooling off. From

by jeswin 6y ago

But I wish new frameworks stayed away from inventing new language syntax. Not only is it a cognitive burden on programmers, it throws all the tooling off. From Svelte: {#each cats as { id, name }, i} JavaScript already has facility for loops and mapping, and relying on that will automatically get you tooling/IDE support. React handles this aspect quite well, and to me that's a point in favor of React. I do agree with your post - especially on hooks being a step backward.

lhorie 6y ago
I agree that gratuitous syntax differences are tiring, but in this case, there's actually a very good reason why it's not just using JS. When it comes to reactive systems, you need to be able to statically analyze control flow structures in order to compile to efficient code. In JS, a for loop is a loop, but so is array.map, Object.keys and someLib.each. The loop could be hidden three layers deep in a higher-order function composition from some third party library, it could be tail call recursion, etc. Dealing with this sort of complexity when writing optimizing compilers is very very hard, compared to coming up with dedicated loop syntax, because at any point it's possible there's a value of polymorphic type, a Proxy, a getter/setter side effect or some other crazy JS shenanigan going on. This is why, for example, Solid.js does control flow through <For /> and <Show /> components instead of map/ternaries even though it uses JSX.
- jeswin 6y ago
 I understand why they did it, but there are alternatives. Such as: import * from "svelte"; // ...omitted for brevity. { svelte.each(cats, ({ id, name }) => Hello {name}) } // ...omitted This is easy to parse and transform, while being fully within JS.
 - swsieber 6y ago
 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.
 - jeswin 6y ago
 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.
 - jestar_jokin 6y ago
 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)
 jugglebird 6y ago
 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.
 - lhorie 6y ago
 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)
 - jeswin 6y ago
 > 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.
 - lhorie 6y ago
 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.
 jeswin 6y ago
 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-db/blob/master/src/schemas/sort.js 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 https://github.com/jeswin/chimpanzee
- antihero 6y ago
 > Dealing with this sort of complexity when writing optimizing compilers is very very hard Which is why we use JS and allow V8/SpiderMonkey/JSC to do it for us :)
- snicker7 6y ago
 Javascript was originally supposed to be a Lisp. In this alternative universe, there would be no need for Svelte. For a portal into this universe, see Clojurescript's Mr. Clean [0]. [0]: https://bitbucket.org/sonwh98/mr-clean/src/master/ https://bitbucket.org/sonwh98/mr-clean/src/master/
dmitriid 6y ago
I was with you on this topic, and I have rants about this elsewhere. But with Svelte 3 I actually agree with their choice now: 1. The extra templating syntax is rather small and concise. And explicit. - There are very few directives, and they follow the same rules: `{# start block }{: alternative branch}{/end block}` - external data that comes from Javascript is always `{data}` - properties of html components that can be bound are always `prop:name|modifiers={data}` This is in contrast to, say, Vue, where the syntax can never decide where it's going. And compared to React, this isn't Javascript either if we think about it: { svelte.each(cats, ({ id, name }) => Hello {name}) } That's a specific extension that compiles to Javascript 2. Your work becomes MVC-ish Your template/html becomes "I have some data, let's display it". And since the template syntax doesn't allow arbitrary logic, you end up collocating transformations of your data with the code that's fetching it. Instead of doing some weird logic inside the template like `data.map.filter.map` 3. But to each their own :) What really turned me towards Svelte is going through the tutorial and then trying it. It really is good :)
- wildermuthn 6y ago
 As I noted in another comment, what we’re really dealing with in compiled templates are reader macros. And unfortunately, reader macros break composability.

by jeswin 6y ago

lhorie 6y ago

I agree that gratuitous syntax differences are tiring, but in this case, there's actually a very good reason why it's not just using JS. When it comes to reactive systems, you need to be able to statically analyze control flow structures in order to compile to efficient code. In JS, a for loop is a loop, but so is array.map, Object.keys and someLib.each. The loop could be hidden three layers deep in a higher-order function composition from some third party library, it could be tail call recursion, etc. Dealing with this sort of complexity when writing optimizing compilers is very very hard, compared to coming up with dedicated loop syntax, because at any point it's possible there's a value of polymorphic type, a Proxy, a getter/setter side effect or some other crazy JS shenanigan going on. This is why, for example, Solid.js does control flow through <For /> and <Show /> components instead of map/ternaries even though it uses JSX.

jeswin 6y ago
I understand why they did it, but there are alternatives. Such as: import * from "svelte"; // ...omitted for brevity. { svelte.each(cats, ({ id, name }) => Hello {name}) } // ...omitted This is easy to parse and transform, while being fully within JS.
- swsieber 6y ago
 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.
 - jeswin 6y ago
 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.
 - jestar_jokin 6y ago
 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)
 - jugglebird 6y ago
 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.
- lhorie 6y ago
 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)
 - jeswin 6y ago
 > 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.
 - lhorie 6y ago
 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.
 - jeswin 6y ago
 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-db/blob/master/src/schemas/sort.js 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 https://github.com/jeswin/chimpanzee
antihero 6y ago
> Dealing with this sort of complexity when writing optimizing compilers is very very hard Which is why we use JS and allow V8/SpiderMonkey/JSC to do it for us :)
snicker7 6y ago
Javascript was originally supposed to be a Lisp. In this alternative universe, there would be no need for Svelte. For a portal into this universe, see Clojurescript's Mr. Clean [0]. [0]: https://bitbucket.org/sonwh98/mr-clean/src/master/ https://bitbucket.org/sonwh98/mr-clean/src/master/

dmitriid 6y ago

I was with you on this topic, and I have rants about this elsewhere. But with Svelte 3 I actually agree with their choice now: 1. The extra templating syntax is rather small and concise. And explicit. - There are very few directives, and they follow the same rules: `{# start block }{: alternative branch}{/end block}` - external data that comes from Javascript is always `{data}` - properties of html components that can be bound are always `prop:name|modifiers={data}` This is in contrast to, say, Vue, where the syntax can never decide where it's going. And compared to React, this isn't Javascript either if we think about it: { svelte.each(cats, ({ id, name }) => Hello {name}) } That's a specific extension that compiles to Javascript 2. Your work becomes MVC-ish Your template/html becomes "I have some data, let's display it". And since the template syntax doesn't allow arbitrary logic, you end up collocating transformations of your data with the code that's fetching it. Instead of doing some weird logic inside the template like `data.map.filter.map` 3. But to each their own :) What really turned me towards Svelte is going through the tutorial and then trying it. It really is good :)

wildermuthn 6y ago
As I noted in another comment, what we’re really dealing with in compiled templates are reader macros. And unfortunately, reader macros break composability.