Proposal for significant changes to syntax for V4

[Monkatraz]

Rendered

Sorry for the unusual format of this RFC - I didn't feel that it was right for me to make an individual RFC for each of these changes, as I don't feel like they should be implemented individually. Of course, if it turns out that there is a desire to, any of these changes could be split out into their own RFC.

Please let this be a catalyst for discussion, I really want to see this furiously discussed as I think there is a lot to ponder here.

[pngwn]

Well, in JS, ${} is self-contained. Nothing inside of those brackets ever has any affect on anything outside of it, unless you're doing probably bad things like reassigning variables.

You use string templates as an example here but curly braces are used for far more than that in JavaScript. They're most commonly used to define a scope of some description, not a template literal, and modifying things outside of the current scope is a common pattern. There is nothing bad about it.

I think the attribute suggestions are particularly problematic, but even if they weren't, I'm struggling to see the value in any of these changes. This just looks like change for it's own sake, if anything the suggested syntax is even more esoteric than the existing syntax which is at least inspired by handlebars (it was never intended to be compatible with HTML, Svelte has had its own template parser forever).

This just looks like a personal preference for different syntax, it would cause significant disruption for relatively little value.

[Monkatraz]

You use string templates as an example here but curly braces are used for far more than that in JavaScript. They're most commonly used to define a scope of some description, not a template literal, and modifying things outside of the current scope is a common pattern. There is nothing bad about it.

The syntax is inherited from templating engines, and this is referring to string templates, which I think is an obvious and apt comparison. However, even with blocks - yes, they do define a scope, but only inbetween the braces. But, at least to me, I don't think of {} in Svelte as a block, I think of it as a string template expression, because, well, that's kind of where that whole syntax came from. Also, I meant assigning things inside of string template braces, as I cannot imagine why you would ever do that.

I think the attribute suggestions are particularly problematic, but even if they weren't, I'm struggling to see the value in any of these changes. This just looks like change for it's own sake, if anything the suggested syntax is even more esoteric than the existing syntax which is at least inspired by handlebars (it was never intended to be compatible with HTML, Svelte has had its own template parser forever).

It seems almost every time a change is suggested it is pushed back because of inconsistencies with HTML spec. And Svelte absolutely WAS intended to at least be vaguely parsed by HTML tooling - the attr="{interpolation}" syntax is to not break syntax highlighters.

This just looks like a personal preference for different syntax, it would cause significant disruption for relatively little value.

I disagree that this is of "little value", how often have you heard developers incessantly complain about how JS syntax is awful? Syntax, especially the feeling of it and how it flows as you read it, is very important.

[pngwn]

It seems almost every time a change is suggested it is pushed back because of inconsistencies with HTML spec. And Svelte absolutely WAS intended to at least be vaguely parsed by HTML tooling - the attr="{interpolation}" syntax is to not break syntax highlighters.

All valid HTML should work in Svelte but I don't know that we've ever tried to maintain compatibility with HTML in the template, that boat sailed a long time ago. We do want to maintain compatibility with JS tooling inside the script block and CSS tooling inside the style block though. Where possible we will take the approach that is most compatible with existing tooling if all else is equal (including the HTML).

I disagree that this is of "little value", how often have you heard developers incessantly complain about how JS syntax is awful? Syntax, especially the feeling of it and how it flows as you read it, is very important.

Then please explain the value. I'm not seeing any convincing arguments outside of the fact that you think it is better. But any significant overhaul of syntax doesn't just need to be slightly better but needs to also be worth the upheaval it will cause. It is a pretty high bar.

[pngwn]

The reason curly braces around attribute expressions are a 'good idea' is because we subscribe to the view that explicit is better than implicit. Curly braces make it very easy for the reader to work out whether or not something is a plain attribute or attribute expression, even if technically they aren't always necessary.

[Monkatraz]

Then please explain the value. I'm not seeing any convincing arguments outside of the fact that you think it is better. But any significant overhaul of syntax doesn't just need to be slightly better but needs to also be worth the upheaval it will cause. It is a pretty high bar.

I feel like this is somehow about me when I didn't intend for this to be my personal demands. This is quite literally the repo for making controversial suggestions.

The reason curly braces around attribute expressions are a 'good idea' is because we subscribe to the view that explicit is better than implicit. Curly braces make it very easy for the reader to work out whether or not something is a plain attribute or attribute expression, even if technically they aren't always necessary.

Regardless, I'll focus on attributes, which I do agree probably has the least value out of the three proposed changes. My argument for it is that Svelte is already so dynamic that making such an explicit divide between the dynamic 'script' bits of Svelte and the static HTML bits of Svelte is counterproductive. For example, in components, explicitly having to type curly brackets for props you know can't even accept a string feels strange to me.

However, I think most importantly, and I think I got this across in the RFC, is that you can already represent plain attributes with Svelte expressions near identically already. It feels bizarre to separate the two when HTML is only ever going to accept a string anyways - if it's a string, it's a string, and you can see it. If it's not a string, well it must be something else then. Pug does this already, and I don't think anyone is confused by that.

[pngwn]

I feel like this is somehow about me when I didn't intend for this to be my personal demands. This is quite literally the repo for making controversial suggestions.

And whoever makes those suggestions needs to try to communicate the advantage of the change. You have suggested some alternatives but I don't really see any benefits.

For example, in components, explicitly having to type curly brackets for props you know can't even accept a string feels strange to me.

Then there would be a significant disparity between passing props and passing attributes. I don't think that would be beneficial outside of saving a few characters. You read code far more than you write it, so optimising for write-ability is a mistake. Making attribute and prop expressions easy scannable without need to know all of the context is beneficial.

Pug does this already, and I don't think anyone is confused by that.

We do not wish to take design tips from Pug.

[Monkatraz]

And whoever makes those suggestions needs to try to communicate the advantage of the change. You have suggested some alternatives but I don't really see any benefits.

They're syntax changes. The advantages of the change depend upon literally your personal opinion as there isn't anything technical to talk about here. This is your opinion, and that's absolutely fine - I'm sorry if I can't convince you of why I prefer this.

Then there would be a significant disparity between passing props and passing attributes. I don't think that would be beneficial outside of saving a few characters. You read code far more than you write it, so optimizing for write-ability is a mistake. Making attribute and prop expressions easy scannable without need to know all of the context is beneficial.

I personally find it easier to read cleaner, less symbol-ridden code. Many people prefer Python for just this reason alone, and that's a perfectly fine reason. Additionally, syntax highlighters are pretty much everywhere - almost always strings and other types will be highlighted differently.

We do not wish to take design tips from Pug.

I think you missed the point, it wasn't a design tip, just a real-world example. I am not suggesting you go make Svelte pythonic or something.

[Monkatraz]

I will add that I have finally found where I read that Rich had put forward the idea of updated control flow. It has been discussed and proposed before - and mentions a lot of ideas that I already talked about. Perhaps it is fruitless to suggest an update to control flow considering this previous discussion, but time has passed, and it should be at least talked about again.

[benmccann]

I generally think syntax changes are not worth it due to the backwards compatibility issues they cause. Unless it enables new functionality or addresses a significant confusion demonstrated over a prolonged period of time by a large number of users, the pain it causes is not worth it to our users who would need to update all their code.

[antony]

It's also a no vote from me I'm afraid. I don't like any of the new syntax proposals, I actively dislike all of them in fact.

Thanks for taking the time to create this RFC however, absolutely the right way to go about it.

[dummdidumm]

Going through the proposed changes / areas of changes:

Changing control flow syntax

For me the "{} implies other things syntax"-thinking is the opposite in the template: Whenever I encounter a { I know "now I encounter Svelte-land", and when I encounter } I know I exit it. This makes it very easy to read for me. That's why I like the current status of {#XXX control flow syntax. Using syntax like #if XXX { ... } would break my expectations of "now I enter Svelte-land-dynamic stuff" because it's used as a "surrounding area"-statement (don't know how to express that better). Using <if ... is too close to HTML for me which makes it harder to read.

More terse props syntax

This will make it harder to understand what's going on since the syntax is now ambiguous. Does prop=value mean prop="value" or prop={value}? Also see my "what does {} imply for me" above. What I would be okay with is prop=value === prop="value" similar to how it's for HTML attributes. Btw you don't need {} for string props, you can do stringProp="a string".

Changing parameters for actions/transitions/etc

With more than three parameters this will become hard to read. You also may not know what these parameters are. Yes it's more to type, but easier to read for others. It would also close off the possibility to ever introduce some third parameter which is not used for parameters but something else.

[antony]

Thanks for this RFC, however I don't think we feel that these changes are right for Svelte.