← Back to context

Comment by RoboticWater

5 years ago

For all the use cases I deal with on a regular basis, Svelte looks more like vanilla HTML/JS than any equivalent React code.

And the reason these things change is because that's what needed changing. One of the topline features of Svelte is that is has less boilerplate than React, and it achieves that quite handily. Unless you're criticizing particular constructs in Svelte that are unjustifiably different, I don't think unfamiliarity is that damning a criticism.

Maybe I'm just used to switching up languages on a regular basis, but the idea of having to learn different language constructs for loops and the like doesn't seem that herculean of a task.

95 comments

RoboticWater

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

  • 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>

      13 replies →

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

      12 replies →

  • 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

      27 replies →

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

fron  5 years ago

> but the idea of having to learn different language constructs for loops and the like doesn't seem that herculean of a task.

I agree. As long as you understand the basic concepts, it's only a matter of learning the syntax, which is really not as big of a deal as the person you replied to is making it out to be.

  • cphoover  5 years ago

    It's not a herculean task... I agree, until you've learned 10+ (angular, vue, svelte, wordpress/php, jade templates, laravel, underscore/lodash, handlebars/mustache, hugo, etc..) of these "super simple templating languages"! And keep them all straight. I have no problem learning a new language if there is a compelling reason. But If it's just additional shit I have to remember for no clear reason... No thanks...

    We can have a debate on unidirectional data flow vs 2-way binding, how each framework manages state changes, how opinionated each framework is... How mature and vibrant each developer community is... etc. These are all another discussion though. My question is why must we reinvent the wheel again and again.

    • bryans  5 years ago

      You need to stop insisting that a wheel has been reinvented with Svelte. It shares 95% of the same DNA as other frameworks, with multiple improvements over them. So with that in mind, what you're actually suggesting is that the existing offerings were somehow perfect, and we don't ever need to improve on anything again. That is an absurd notion, especially given that the other frameworks have gone through MASSIVE changes since launch -- sometimes even complete rewrites, because they acknowledged they got it wrong the first time.

      1 reply →

    • rawoke083600  5 years ago

      >It's not a herculean task... I agree, until you've learned 10+ (angular, vue, svelte, wordpress/php, jade templates, laravel, underscore/lodash, handlebars/mustache, hugo, etc..)

      So you want all of these to be a universal-template-language - (D)HTML ?

  • rawoke083600  5 years ago

    100% - Common guys we are programmers in a field that is know for changing consistently (probably a lot faster than other careers). If you see learning new "syntax" for the basics (loops,conditionals etc) then you going to have problems down the road. Weather you use svelte, or some other new tech. If you really never want to learn another syntax.. learn LISP and be done with it.

    You are a programmer, you will need to learn new syntax a few times in your career.

    If some of the "biggest" complaints are "oh no I have to learn how to write for-loops again" - I guess svelte is doing the important stuff right.

    Wayyyy back in the day(ok not that long ago - 80/90's) when I was learning a new lang (Pascal,C, C++) I used to tell myself If I can get an working example of:

    1) "user-input (readline,scanf etc)"

    2) "printing input/output"

    3) "calling functions/procedures"

    4) "Do the loops + conditionals"

    5) "file I/O"

    6) "Memory schematics"

    You basically mastered the "building blocks/mrk(min-req-knowledge)" of the new lang and like maths you only need now practice or a good project.

    TL;DR If you are a professional-career-programmer, learning "new syntax (we used to call them keywords)" is a requirement.

  • kall  5 years ago

    Oh but it‘s not just about the syntax, it‘s also about the semantics, scope rules etc. This is the reason I still like JSX best, because I have a fairly deep understanding of that stuff in javascript while vue templates still leave me scratching my head sometimes. But I can see the appeal either way.

nnoitra  5 years ago

What boilerplate does React have? Do you mean Babel?

  • cphoover  5 years ago

    I know...

    This comment had no context...

    You don't have to even

        import React from 'react';

    anymore

  • kall  5 years ago

    useMemo and useCallback do feel a little boilerplate-y. Something is slow, I wrap it in the thing, I let eslint fill the dependencies and there‘s no big downside to doing it all the time anyway. Feels like something I maybe don‘t need to be typing?

    useState is also something svelte eliminates, though I personally prefer to keep that explicit.