← Back to context

Comment by cphoover

5 years ago

What how can you say that???

      <ul>{myItems.map({id, title}) => 
          <li key={id}>{title}</li>
      }</ul>

vs... svelte

     <ul>{#each myItems as item}
         <li>{item.title}</li>
     {/each}</ul>

One is literally just javascript and html the other is an entirely different template language. You might say... JSX is not HTML... well it's very very similar... If you know HTML you JSX is very intuitive.

84 comments

cphoover

Reply
benmccann  5 years ago

But React isn't just JSX. It's also the entire runtime library, hooks, event handling, forms, state handling, etc. The example you shared is a bit too simple to understand where Svelte shines because it doesn't introduce any of those concerns.

By having it's own templating language, Svelte is able to compile the templates to JavaScript in a way that addresses many of those concerns in a way that I think it easier to deal with as an end user of the framework.

If Svelte were using JSX, I don't know that it'd be possible to do everything else that it does so simply because you can write anything that's valid JavaScript in JSX whereas Svelte has just a couple of basic control structures that its compiler can parse and convert to runnable code.

  • noir_lord  5 years ago

    Not to mention it takes reactivity to new heights while adding amazingly little actual syntax.

    When property changes, the fetch refires, loading appears until the fetch resolves then it displays whatever array someFetch resolved to.

    I came from Vue and that plus the way Svelte does stores (literally nothing special about them) was a breath of fresh air.

        <div>
        {#await someFetch(property)}
            <div>Loading...</div>
        {:then data}
        
            {#each data as item, index}
                <div>{item}</div>
            {/each}
    
        {/await}
    </div>

    • Aeolun  5 years ago

      But what does ‘#await someFetch’ actually do? The thing I like most about react is that it’s just executing plain Javascript most of the time.

      11 replies →

    • wruza  5 years ago

      I’m neither of (react, vue, svelte) guy, but isn’t that snippet equivalent to some:

        div
    Await promise={mypromise}
      div Loading…
      {res => res.map(…)}
      div Error: {err => err.message}

      (writing in pug-like because I can’t stand closing these tags on the phone)

      Isn’t it easier in both react and vue to create Await component with children=(ifwaiting, ifresolved, ifrejected) than suffering all over the code?

      Edit: I messed data flow up in the error handler, wontfix but you get the idea

makeramen  5 years ago

> If you know HTML you JSX is very intuitive.

That's a poor assumption that appears to be based on your personal preferences and what you're comfortable with. I personally find both require some learning, but prefer the svelte version.

  • DonHopkins  5 years ago

    And JSX isn't JavaScript and it isn't HTML, and if you know JavaScript and HTML you still don't know JSX, so you're still using "yet another language" in addition to JavaScript and HTML.

    • Ambroos  5 years ago

      JSX is easy to summarize as: HTML where everything in curly brackets is a JS expression that gets evaluated. There are some additions (prop spreading) and restrictions (curly brackets apply to whole attribute values and element bodies only), but they're very simple.

      1 reply →

    • dwaltrip  5 years ago

      Come on… If you know JavaScript and HTML you are 95% of the way to being fluent in JSX. It’s basically just JavaScript expressions.

      1 reply →

    • hunterb123  5 years ago

      JSX is JS. Nested brackets are simply converted to nested function calls & objects, attributes convert to properties.

      This is evident when comparing conditionals, loops, etc. Instead of learning template syntax you simply use JS syntax, albeit a declarative subset (no branches).

      JSX is simply syntactical sugar for nested JS, you can use it without, but it's prettier with.

      One could add this syntactical sugar natively to the language spec, in fact E4x (ECMAScript for XML) share some properties w/ JSX and was once proposed to the spec.

      edit: instead of downvoting, please voice how you disagree with my assessment

      5 replies →

    • proxyon  5 years ago

      JSX is just JS with brackets instead of nested function calls. I expected more from this community than this kind of commentary.

subpixel  5 years ago

I grant that it isn't Javascript and you have to get familiar with it. But at least it's not Hugo templating.

bGl2YW5j  5 years ago

This JSX syntax is a perfect example of one of its subtleties: map() creates an array, and an array of elements is automatically expanded to single elements. I know that when I learnt JSX, this was not intuitive.

The word 'each' conveys the intent of this code way more explicitly.

  • wruza  5 years ago

    And this subtlety is based on a difference in React.createElement() interface. If you pass an array among its children, it automatically requires all of its items to be keyed, and if you pass it as …array, i.e. variadic arguments, it doesn’t. But I believe you either can’t do {…array.map()} in jsx or its creators decided that it is not tasty enough.

uallo  5 years ago

> literally just javascript

Repeating it over and over again does not make it true.

https://linkedlist.ch/jsx_is_not_just_javascript_39/

  • hunterb123  5 years ago

    Repeating a blog post over and over doesn't make it true.

    The author is wrong. Most of his statements are about React, not JSX.

    It's syntactical sugar for nested function calls, that's all. Brackets are turned into function statements, attributes are turned into object props.

    The author conflates React properties with JSX, which is wrong. The author also confused JSX limitations, you cannot do statements because it's a single expression.

    Please go read the JSX spec instead of some random blog post.

    https://github.com/facebook/jsx

    • DonHopkins  5 years ago

      Thank you for that definitive link. Note that first boldfaced sentence in that JSX specification is as follows: "It's NOT a proposal to incorporate JSX into the ECMAScript spec itself."

      That should have been the end of this discussion and fight that you picked about your incorrect statement that "JSX is JavaScript". You just unwittingly undermined and terminated your own argument by linking to the JSX spec itself, which clearly and explicitly says you are wrong, in BIG BOLD WORDS.

      As JimDabel said, "They wanted to be 100% clear about it." So stop repeating something that the JSX designers so insistent is not true that they put it in bold at the top of their design specification.

      You already won this argument, for the "JSX is NOT JavaScript" side. It's over.

      1 reply →

    • JimDabell  5 years ago

      Right from the very top of your source:

      > JSX is an XML-like syntax extension to ECMAScript without any defined semantics. It's NOT intended to be implemented by engines or browsers. It's NOT a proposal to incorporate JSX into the ECMAScript spec itself. It's intended to be used by various preprocessors (transpilers) to transform these tokens into standard ECMAScript.

      Further down:

      > Why not just use that instead of inventing a syntax that's not part of ECMAScript?

      It is not JavaScript.

      23 replies →

    • kall  5 years ago

      and if you really want to use statements, you can, using an IIFE for example. It’s not pretty but you can because… ehm… it‘s just javascript.

      At this point the "is JSX just javascript" discussion has gone on a little to long imho. It feels like "is html a programming language". We all have strong convictions about the answer but it doesn‘t matter, really.

      It‘s interesting that fans all of 3 frameworks constantly claim that it’s "just“ or "closer to vanilla" html or js. Should we really care anymore?

pier25  5 years ago

Objectively, the Svelte example is cleaner and easier to read.

  • diegof79  5 years ago

    The issue is not only the syntax, but the semantics. What happens to the scope when you nest #each expressions? Does it work with iterables (like for..of), or it behaves like for..in? I don't use Svelte, and I don't know those differences by reading the code. To me the nice thing about JSX is that is straight forward with JS semantics:

        const a = <div prop={expression()} />

    is a DSL for:

       const a = factory('div', {prop: expression()})

    is only a DSL to create tree structures (React is another story, you can use JSX without React).

  • kosolam  5 years ago

    Subjectively, I’d say. But since I agree that it’s cleaner and easier to read- I upvote you

  • epolanski  5 years ago

    Saying it is objective but not mentioning the reason really makes your statement subjective.

midrus  5 years ago

Yeah, now add state management, event handling, side effects and performance optimizations and come back with your example. You're just comparing syntax. This is very naive.

ksdnjweusdnkl21  5 years ago

Seems like svelte is superior for not needing a key.

  • cphoover  5 years ago

    fair criticism I wonder how svelte optimizes for rerendering of long component lists. React uses keys to avoid rerendering the entire list.

    • wruza  5 years ago

      Keys are also essential to retaining an element identity, which is structurally more important than performance, because 1) code may have a reference to an element and think that it relates to some data, 2) an element may have an explicit state (like focused, animating, etc).

      Keys are a hugely leaking abstraction, but are inevitable when you bridge a declarative immediate mode rendering into a stateful one.