Hacker News Reader

Comment by BiteCode_dev | Hacker News Reader

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.

View on HN

I'm not sure how it forces less logic in the render. Looking at the Svelte docs you can do this:

``` {#if invokeFunction()} This function returned a truthy value! {/if} ```

And with React do this:

``` { invokeFunction() && This function returned a truthy value } ```

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} {vars} {#/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) => {vars} } ```

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.

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.

Vue's templates are great until they aren't, and then you wish you were using JSX.

The IDE tooling is worlds better with JSX as well. Vetur has.. had a rough year.

I don't have to debug my render functions much in vue because they contains little logic. Debugging is more common in JSX, it's better at solving a problem it introduces.

The second example isn’t making JS the hero, it’s making data the hero.

Which is the opposite of what you want in rendering. Ui is king here. Data has the rest of the code to shine.

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.htm....

In your first example, if invokeFunction() returns 0, the text "0" will be inserted into the page. 0 is falsey, so `0 && Hi` 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.

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.

Depends of the template language. I prefer vues's than svelte's.

Reply on news.ycombinator.com