Svelte: Why two-way binding isn't bad...

[MikeBeaton]

The project already has a couple of issues suggesting potential blog posts... so, veeery tentatively, I wondered if it was OK to post here a suggestion for what seems like an obvious additional one.

The issue, as far as it goes, is discussed (e.g.) here - which contains a useful timed link to this - or here (amongst, of course, many other similar discussions). These are reasons why a dev might come to believe that two-way binding is 'bad'.

In ever so slightly more detail, Svelte 3 templates certainly do look lovely, terse and easy to read and write, and yes, it does seem that two-way binding (which is part of that) is much quicker and easier for prototyping and for small apps. But the types of discussions linked above seem to strongly indicate that two-way binding doesn't scale (is no longer predictable, or easily debuggable) in (medium to?) large scale apps.

It certainly seems that Svelte doesn't see this as a problem. Perhaps the reason for this is hinted at above: is Svelte only aimed at small (to medium?) scale apps? Or perhaps the Svelte project believes that two-way binding used correctly can and does scale? (Or, of course, any number of other reasons I haven't thought of!)

(#2546 is also about scaling, but a different issue)

[sudomaxime]

Do not see this reply as a rant, it's simply an opinion that express my point of view, there are many good (different) points of view out there.

We are currently building fairly large applications using svelte and so far we did not run into any issues in reguards to scaling. I think there is in theory an inflection point where a "traditional" framework would produce less boilerplate but I think the benefits svelte/sapper brings far outweight this. You have to take into account that you get a lot of things OOTB (tree shaking, SSR sapper, legacy browser dynamic polyfills, make it recognisable as a PWA by Google, service worker... etc.) you would have to go a long way to get this with a "traditional" framework.

It's the simplest way to make apps, but it's by no means easy.

To me using Svelte is a bit of a philosophical statement which is: _Simple is better and less is happyness._

There's always compromises to make, after so much time shipping out products, I have to admit I'm going to the dark side of things - getting shit out of the door, in a maintainable way, as quick as possible is how we create good business - And svelte is great for that.

Other frameworks I feel, get's "in the way".

I have come to realise that no matter how much time you take to refactor code, use typings, use the best practices, scaling and maintaning front-end code is always a pain. The bazzilion frameworks and npm modules creates a "Bring what you like, work how you want" mentality to the Javascript ecosystem, and it becomes really hard to come back to a 3 year old project filled with a bunch of "branded" function names that makes the codebase look like a display of pokemon names that no one understands.

I used to be a big React fan, but after taking over projects over time, I feel like most React projects become Rude Goldberg machines, ex: generator functions over redux stores with redux saga, if you are not the one that originated the code, good luck trying to understand all the ramifications and side effects going on.

To me two way binding is far easier to grasp.

Trying to teach junior devs React lifecycle methods along with SSR state management is like shooting yourself in the foot. The need for developpers (which is a scarce ressource) force many teams to hire less experienced devs all the time. When I think about Sapper excellent prefetch function, I see so many shouldComponentUpdate, didComponentUpdate, mapStateToRidiculouslyLongFunctionNames explanations I don't have to do to junior staff just to get network data printed on a page.

The road to hell is paved with good intentions. React is a great tool that can scale, but like Svelte or Vue or anything else, the inflection point is in the hands of the developpers.

Another point too is that, front-end code is trashable and it's not a long term asset, UI/UX and understanding your market is, so why bother in the first place ? You are going to refactor stuff all the time anyways.

Svelte allows us to write fantastically easy to understand code, and less of it too !

Less code = less maintenance = less problems = profit.

[sw-yx]

React guy turned Svelte fan here. i agree with you, except be careful, prefetch is serverside, whereas the stuff you listed are clientside. the correct equivalent is Next.js' getInitialProps which is basically the same thing as prefetch.

Just want to encourage good arguments for Svelte, or else the argument will lose persuasiveness because people will focus on the weak parts.

[antony]

@sw-yx I think you mean preload not prefetch :)

[MikeBeaton]

Thanks for the answers.

It's occurred to me that another reason is that two-way binding isn't necessarily bad, at all, at a local state level, e.g. to link form elements to the state of the component which is rendering them (i.e. as long as that state isn't then itself bound onwards to components above that, see next point).

Where it's bad is if you've got two-way binding running all up and down your component tree (as I think the links I posted above, referring to the bitter experience of bigger projects, show that that won't scale).

But there's nothing in Svelte that forces you to do that; and Svelte even supports stores to help you not do that, and implement a modern alternative.

Does that sound about right (i.e. anything like what the Svelte project might say, or endorse, if there was a blog post about this?)?!!

[antony]

I would encourage a blog post on this, as I think it's a common misconception. It would ideally contain practical examples of where each state type might be a good fit, and perhaps a comparison of advantages and drawbacks for each type of state.

[mjgartendev]

It would be great to provide insight on Svelte's departure from a single state tree that's at the core of a lot of popular state management patterns. Some comments on why Svelte is intentionally different would help grasp when and how to use various features of the framework. Deciding between two-way binding vs. a props down/events up approach can definitely be a mental hurdle.

Auto-subscriptions and the ability to bind directly to store values can make smaller apps extremely readable while preventing some hard to track bugs behind the scenes.

Being able to create domain specific stores that are intended to be used with certain components definitely helps keep two-way binding more precise and easier to track, but coming from a Flux architecture makes it hard to figure out.

[vipero07]

It's occurred to me that another reason is that two-way binding isn't necessarily bad, at all, at a _local_ state level, e.g. to link form elements to the state of the component which is rendering them (i.e. as long as that state isn't then itself bound onwards to components above that, see next point).

Where it's bad is if you've got two-way binding running all up and down your component tree (as I think the links I posted above, referring to the bitter experience of bigger projects, show that _that_ won't scale).

But there's nothing in Svelte that forces you to do _that_; and Svelte even supports stores to help you _not_ do that, and implement a modern alternative.

This, to me, is exactly what I see as the difference between the two approaches. Svelte is built to be able to easily produce small self contained components. React was initially built to have one large SPA. Things like component specific css in react requires CSS Modules, and it is no way near the simplicity of adding some CSS to a svelte file.

I think a big driving factor behind the difference is react's virtual dom. Since tracking changes in a tree of virtual dom nodes is difficult and costly, its a lot easier to just pass changes down the tree and ignore passes where no changes occur.

Somewhat related, react has also gone down a functional programming path, which necessitates a single source of truth for the entire application. Especially because it reruns every cycle and short circuits unchanged branches. Whereas svelte seems to follow more OOP principles, I'd even differentiate it more to something like Component Oriented Programming (COP). Svelte allows for the application to have a single source of truth through its stores.

To compare to other languages react is similar to F# and how you need to implement Dependency Injection in it. Svelte is more like C# with DI where its state is loosely coupled from the rest of the application unless otherwise specified.