5 ms·

Svelte looks interesting, however I must say that when I saw stuff like `{#if value} <tag> stuff </tag> {/if}` it really was a turn off for me. One thing I real

• ng12 7y ago
  Same, I really don't like the mental overhead of having to learn the template syntax. I already know JavaScript, just let me use that.
• sibeliuss 7y ago
  I agree. Some argue that this kind of template syntax makes it easer for html folks to write logic, but really what it's doing in the long run is introducing yet another abstraction for them to learn while also poorly assuming that they "can't learn JS". Teach a person how to fish... I think the real reason, however, is that it allows for easier compiler-level optimizations.
• BiteCode_dev 7y ago
  It normalizes the way templates are coded and forces people to put minimal logic in their rendering. In react, there are as many ways to do the same things as there are coders. And of course, some don't follow best practices and will put logic code in it. Personnally I also find it easier to picture the resulting DOM structure because the stylee is forced to be declarative. Too often in react I have to look around a tag to know whats hapening, or I have to follow some nested map/filter/ternary chaining. Very good react coders will not do that. They will use a lot of tooling and abstract formatting a lot. But they are few.
  • crtlaltdel 7y ago
    I'm not sure how it forces less logic in the render. Looking at the Svelte docs you can do this: ``` {#if invokeFunction()} <p>This function returned a truthy value!</p> {/if} ``` And with React do this: ``` { invokeFunction() && <p>This function returned a truthy value</p> } ``` and the result would be the same, a conditionally rendered string. I totally agree in the normalizing/formalizing how templates are build and the more verbose syntax in the Svelete example does make it super obvious. The in-line React example is obvious to me...but maybe that's because I've been writing js for so long. Where I feel the cognitive overhead pain in looping. Svelete's docs say: ``` {#each collection as { vars }, i} <p key={i}> {vars} </p> {#/each} ``` For some reason, when I see this it rubs me the wrong way. I understand it...but my instinct is to just map over the collection like I would in a plain-old Node.js project. ``` { collection.map((vars, i) => <p key={i}> {vars} </p> } ``` I guess that saving a handful of keystrokes in exchange for super clearly expressing the intent may be a good tradeoff, even if my inclination is towards more terse code.
    • csande17 7y ago
      In your first example, if invokeFunction() returns 0, the text "0" will be inserted into the page. 0 is falsey, so `0 && <p>Hi</p>` evaluates to 0, but 0 is a number so React pastes it into the page contents. React has footguns like this because JavaScript expressions were not designed to be used as a templating language.
      • hombre_fatal 7y ago
        Thinking your function returns a boolean when it returns an int seems like another issue entirely, like habitually depending on implicit conversion like "==". If that's a common issue for a team, maybe it's time to look into Typescript. Seems like a very minor reason to use a whole new DSL with a whole new set of warts for all of your templating.
    • BiteCode_dev 7y ago
      Depends of the template language. I prefer vues's than svelte's.
    • hombre_fatal 7y ago
      Things like Hiccup and React/JSX were a breath of fresh air next to templating languages like Handlebars/Mustache/Jinja. I prefer to just write simple code instead of learning the idiosyncrasies of yet another DSL. I'm reminded of https://gbracha.blogspot.com/2014/09/a-domain-of-shadows.html https://gbracha.blogspot.com/2014/09/a-domain-of-shadows.htm....
    • BiteCode_dev 7y ago
      In Vue it would be: <p v-for="(vars, i) in collection" :key="i"> {{ vars }} </p> Instead of: { collection.map((vars, i) => <p key={i}> {vars} </p> } It's easier for me to picture what the first example is going to render because it makes the markup the hero, with code inside, while the second example is making JS the hero, with markup inside. But this example is not even touching the topic. A render function is rarely that simple. Now if you do maps, and filters, and ternary operators, and && / || pass trougth, and set several class conditionally, and pass an event and do preventDefault, etc., now you have a more real life example. And in react you'll get __a lot__ of JS, with very little markup. And you'll have either a lot of boilerplate, or a lot of dependencies to get helpers. While in Vue you'll get mostly markup, with a little code inside. It will read from top to bottom as well. No needs to wrap stuff in arrow functions to get the event object. PreventDefault has a helper. Setting classes as well. I prefer that.