4 ms·

It may be unusual and has special semantics in Svelte, but it is JavaScript syntax after all. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference

by uallo 3y ago

It may be unusual and has special semantics in Svelte, but it is JavaScript syntax after all. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/label https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

schwartzworld 3y ago
The only $ in that post is in console.log strings.
- jjnoakes 3y ago
  That post describes "something followed by a colon is a label in certain contexts", so you need to extrapolate a tiny bit to realize that "$:" is a label, even if the post doesn't explicitly enumerate all possible labels.
spicebox 3y ago
It’s not JavaScript, it looks like JavaScript but it works differently
Zanfa 3y ago
Aren’t Svelte templates written in a completely custom template language that doesn’t even look like HTML/JS?
- dbrueck 3y ago
  No, and that's one of the things that's really nice, at least for our team: we really want our web designers to own the HTML/CSS from start to finish. If you use something like React (i.e. where there is code that emits chunks of HTML elements), you sometimes either force the designer to learn React or the designer no longer owns the markup once it gets handed off to a dev. For us at least, that was a maintenance nightmare and hindered our ability to add new features or freshen up the layout. Svelte combines a component's HTML, Javascript, and styles into a .svelte file, so it all lives in one place, but each of those 3 things lives in their own section. The HTML looks very close to what it looks like when it was originally created by the designer, with a few key changes such as markers conditional blocks or loops and additional element attributes to set up data and event bindings. Explaining these to a web designer takes about 10 minutes and they are fine with it, especially if they've ever seen a templating language before. This setup also leads to one of two really good workflows between dev and design; we end up using both of them and choose one based on the specific scenario. In the first, the designer goes from visual design all the way to valid HTML/CSS, and then hands it off to a dev to "wire it up" (make it functional). In the second, a dev will rough in the HTML and make it functional but hideous looking, and then hand it off to the designer to de-uglify it. In both cases, the dev owns the behavior and the designer owns styling/layout/etc. from then on, and it's rare for there to be any conflicts. YMMV of course, but it's been fantastic for us. :)
  - Zanfa 3y ago
    I haven't really used Svelte, but according to their website, they definitely seem to have a custom language that I don't think I've seen before (eg. not mustache, liquid, handlebars, erb). From their own examples [1]: <ul> {#each cats as { id, name }, i} <li> <a target="_blank" rel="noreferrer" href="https://www.youtube.com/watch?v={id}"> {i + 1}: {name} </a> </li> {/each} </ul> [1] https://svelte.dev/examples/each-blocks https://svelte.dev/examples/each-blocks
    - dbrueck 3y ago
      Hmm... apologies, but it seems like we're talking past each other. You thought that Svelte used a "completely custom template language that doesn’t even look like HTML", and I replied that no, compared to something like React, it looks very much like ordinary HTML, with a few exceptions around things like loops and hooks for data bindings, and you replied with a chunk of HTML annotated the way I described. :) Point being that if you take the HTML from a web designer and put it into your svelte app, it looks very similar to the original. For example, our web designers have no trouble continuing to "own" the HTML even after a dev has gone in and made it functional - the overall structure is the same, all of the elements they created are still there (with the exception that if they had e.g. a bunch of dummy rows in a table, those are replaced with one instance of the row and wrapped in a loop construct), the CSS doesn't break because new elements have been added, etc. Our experience with React was very different: once the devs took it, the result was so far removed from the original that the web designers couldn't effectively own it anymore. Maybe for some companies that's not a big deal, but for us it's hard to express just how much better the Svelte way is.

by uallo 3y ago

schwartzworld 3y ago

The only $ in that post is in console.log strings.

jjnoakes 3y ago
That post describes "something followed by a colon is a label in certain contexts", so you need to extrapolate a tiny bit to realize that "$:" is a label, even if the post doesn't explicitly enumerate all possible labels.

spicebox 3y ago

It’s not JavaScript, it looks like JavaScript but it works differently

Zanfa 3y ago

Aren’t Svelte templates written in a completely custom template language that doesn’t even look like HTML/JS?

dbrueck 3y ago
No, and that's one of the things that's really nice, at least for our team: we really want our web designers to own the HTML/CSS from start to finish. If you use something like React (i.e. where there is code that emits chunks of HTML elements), you sometimes either force the designer to learn React or the designer no longer owns the markup once it gets handed off to a dev. For us at least, that was a maintenance nightmare and hindered our ability to add new features or freshen up the layout. Svelte combines a component's HTML, Javascript, and styles into a .svelte file, so it all lives in one place, but each of those 3 things lives in their own section. The HTML looks very close to what it looks like when it was originally created by the designer, with a few key changes such as markers conditional blocks or loops and additional element attributes to set up data and event bindings. Explaining these to a web designer takes about 10 minutes and they are fine with it, especially if they've ever seen a templating language before. This setup also leads to one of two really good workflows between dev and design; we end up using both of them and choose one based on the specific scenario. In the first, the designer goes from visual design all the way to valid HTML/CSS, and then hands it off to a dev to "wire it up" (make it functional). In the second, a dev will rough in the HTML and make it functional but hideous looking, and then hand it off to the designer to de-uglify it. In both cases, the dev owns the behavior and the designer owns styling/layout/etc. from then on, and it's rare for there to be any conflicts. YMMV of course, but it's been fantastic for us. :)
- Zanfa 3y ago
  I haven't really used Svelte, but according to their website, they definitely seem to have a custom language that I don't think I've seen before (eg. not mustache, liquid, handlebars, erb). From their own examples [1]: <ul> {#each cats as { id, name }, i} <li> <a target="_blank" rel="noreferrer" href="https://www.youtube.com/watch?v={id}"> {i + 1}: {name} </a> </li> {/each} </ul> [1] https://svelte.dev/examples/each-blocks https://svelte.dev/examples/each-blocks
  - dbrueck 3y ago
    Hmm... apologies, but it seems like we're talking past each other. You thought that Svelte used a "completely custom template language that doesn’t even look like HTML", and I replied that no, compared to something like React, it looks very much like ordinary HTML, with a few exceptions around things like loops and hooks for data bindings, and you replied with a chunk of HTML annotated the way I described. :) Point being that if you take the HTML from a web designer and put it into your svelte app, it looks very similar to the original. For example, our web designers have no trouble continuing to "own" the HTML even after a dev has gone in and made it functional - the overall structure is the same, all of the elements they created are still there (with the exception that if they had e.g. a bunch of dummy rows in a table, those are replaced with one instance of the row and wrapped in a loop construct), the CSS doesn't break because new elements have been added, etc. Our experience with React was very different: once the devs took it, the result was so far removed from the original that the web designers couldn't effectively own it anymore. Maybe for some companies that's not a big deal, but for us it's hard to express just how much better the Svelte way is.