Hacker News new | ask | show | jobs
by xrd 2292 days ago
I love React and I love Svelte. There, I said it.

These are the complaints that standout for me with Svelte after using it for a few months:

* Sub-par editor support. For me, the litmus test is whether I can use F2 to rename a variable, and it often does not work inside a Svelte template. There are other places where the editor does not know what to do with your code, because it is not pure JS. Vue is much worse with this since so many things are just strings; React really shines with editor support. This makes a big difference when you are using a large project where you didn't write the code.

* I don't love that you have to re-assign a object/array variable to get Svelte to notice it changed, and you can do that inside a Svelte template to a const variable and you won't get a complaint from the compiler.

* Much smaller ecosystem compared to React and Vue, which is expected at this point.

Other than this, I absolutely love Svelte. Stores are such an amazing abstraction. Animation is well thought out. Storybook works perfectly. Mostly it is pure JS once it gets inside the browser, so you can debug effectively which is not the case with Vue for example.

3 comments

Since you've been using Svelte for a few months after using React, haven't you been hit by the lack of composability in Svelte?

Passing around components as variables is such a common pattern in React, and there's no good replacement in Svelte. The lack of dynamism in components and styles makes theming and crafting reusable components (outside of simple widgets) very tedious [1][2]. I'm genuinely curious how someone can come from React and not be bothered by it.

[1]: https://github.com/sveltejs/svelte/issues/2106

[2]: https://github.com/sveltejs/svelte/issues/1550

It's a great point. I'm not bothered by it only because I'm not using react professionally right now and don't use that pattern. Thanks for bringing that important point up.
Passing components is totally supported, and you can use slots. There isn’t a single issue I identify with in that GH thread...
Slots are currently an unwieldy band-aid.

https://github.com/sveltejs/svelte/issues/1037 (open since 2017)

https://github.com/sveltejs/svelte/issues/2079

The simple usage of passing a component to a component, which almost every decently-sized project will make use of, has no convenient syntax, only workarounds:

    // parent.svelte
    <script>
      import Nested from './nested.svelte'
      import Child from './child.svelte';
    </script>
    <Child>
      <div slot="bar">       <-- Extra wrapper DOM node
        <Nested foo="Foo"/>
      </div>
    </Child>
    
    // child.svelte
    <slot name="bar" {...data}/>

Passing down an element as a prop requires separating the component constructor and its data and manually re-conciliating the two in the child component every time, since components can't be rendered from functions. It works but it's unnecessary boilerplate.

    // parent.svelte
    <script>
      import Nested from './nested.svelte';
      import Child from './child.svelte';
    </script>
    <Child nested={Nested} nestedData={{ foo: "Foo" }}/>
    
    // child.svelte
    <script>
      let export Component;
      let export componentData;
    </script>
    <Component {...componentData}/>
I'm evaluating svelte and have yet to do much, however handling dynamic components is a key requirement, and appears to be supported like so:

  <script>
    import RedThing from './RedThing.svelte';
    import GreenThing from './GreenThing.svelte';
    import BlueThing from './BlueThing.svelte';

    const options = [
      { color: 'red',   component: RedThing   },
      { color: 'green', component: GreenThing },
      { color: 'blue',  component: BlueThing  },
    ];

    let selected = options[0];
  </script>

  <select bind:value={selected}>
    {#each options as option}
      <option value={option}>{option.color}</option>
    {/each}
  </select>

  {#if selected.color === 'red'}
    <RedThing/>
  {:else if selected.color === 'green'}
    <GreenThing/>
  {:else if selected.color === 'blue'}
    <BlueThing/>
  {/if}
That's the tutorial challenge code, you get the `svelte:component` solution after clicking "Show me".

https://svelte.dev/tutorial/svelte-component

But yea that's indeed what I should have done in my example if I wanted the component to be reactive, as you can see that's even more verbose and still doesn't take care of props.

I love this thread!

And, isn't it likely this will be easier to support with Svelte eventually? My reasoning is that you just need to add a little syntactic sugar to the language and the compiler can add whatever code is necessary? With a runtime like React and Vue, it seems much harder to add in.

On your 2nd point, you can tell Svelte that your data is mutable, in which case it will do deep equality. However, the benefits of immutable data often mean it's worth just reassigning the variable.

I also wouldn't consider that a disadvantage vs React/Redux, since that also requires using immutable data.

Thanks for sharing!

On point 1, this issue is the one to watch. https://github.com/sveltejs/svelte/issues/4518 Language server support will work for both JavaScript and TypeScript and error/type checking and editor support should be pretty comprehensive when it's ready. Svelte 3 was written with TypeScript in mind, so the idioms are fairly compatible with type checking. (a nice pit of success for design!)

This should also fix reassigning to a const mentioned in point 2.