Comment by bdougherty

5 years ago

I am really curious to hear about specific examples of some of these points. Specifically:

> The abstraction leaks and when it does, it requires a good mental model of Svelte's magic.

Maybe because I have familiarized myself with how Svelte works I haven't noticed anything like that.

> Things that are easy in React at runtime turn out to be surprisingly difficult in Svelte

I suspect this is from trying to use React patterns in Svelte, which I've seen quite a lot in people asking questions on Reddit. But I'm sure there are some things like that, could you give an example?

> Two-way data binding is a constant source of bugs

Again, very curious to see an example of this.

> It's not possible to write a one-line function component or similar

What was your use case here? I haven't found myself wanting to do that anywhere.

Is it surprising that two-way data binding is a source of bugs? We learned that lesson from Angular, and it influenced React’s preference for one-way dataflow.

  • 2-way data binding is still a useful pattern with discipline, and still also common in React (using event handlers).

    • Any error-prone pattern can remain useful with enough discipline, but we've learned time and time again that relying solely on discipline to cover for error-prone patterns doesn't scale.

      3 replies →

  • What do you mean by two-way and one-way exactly? (Asking it because web sometimes has a different history for terms.)

Not the GP, but here's an example of abstraction leaking straight from their intro tutorial:

> A simple rule of thumb: the name of the updated variable must appear on the left hand side of the assignment. For example this...

  const foo = obj.foo;
  foo.bar = 'baz';

> ...won't trigger reactivity on obj.foo.bar, unless you follow it up with obj = obj.

This looks like a huge footgun to me, and it's not even an exotic usecase. It's in the very first page talking about reactivity in the docs.

  • It's not an abstraction leaking, it's an important point to understand about mutating objects.

    You are allowed to use `const` to declare an object and then modify its properties, because modifying properties is not the same as reassigning.

    You're absolutely right that it's something that might catch you out, but not understanding the difference between reassigning and mutating is likely to lead to other bugs and falling into other traps in future.

    (by 'it's not an abstraction leaking', I mean 'the abstraction's behaviour is consistent with the behaviour of the language' - I guess it's a subjective opinion that it's not leaking)

    • Other reactive frameworks like MobX will react when you only mutate objects. APIs like the useState hook at least make it obvious that you need to replace the whole object. Svelte on the other hand presents this "it's cool man, just change your plain JS state like normal!" paradigm, and it would be very reasonable without being told otherwise to assume that this applies to mutating objects as well. But then it doesn't.

      If re-assignment of the whole object is what I have to do anyway, I'd much rather just be given an API that's slightly clunkier but makes that fact obvious. Otherwise the behavior will be surprising and error-prone to those not closely familiar with it yet.

    • Another way of stating it is that Svelte doesn't attempt to plug any of the leaky abstractions that already existed in JavaScript.

      JavaScript is riddled with huge footguns that aren't even exotic use cases, and if you remove or paper over them, then it's not JavaScript any more.

      While React's biggest most obvious leaky abstraction is that React isn't actually reactive.

      Neither is Svelte, but at least Svelte doesn't have the audacity to falsly CLAIM it's reactive in ITS OWN NAME, like React does!

      I do give Svelte credit for being quite self-referentially svelte, though! And that's something great that React definitely isn't.

      How React isn't reactive, and why you shouldn't care

      https://news.ycombinator.com/item?id=22456831