Comment by pier25 | Hacker News Reader

Comment by pier25 | Hacker News Reader

I've used it in a small project. It has so many great things but I don't love some of the dev ergonomics.

My first big problem is that you can't have more than one component per file, much like single file components in Vue. If you're working on a component that has many sub-components it becomes very tedious to switch around files. In Vue instead of creating new small components when using SFC I tended to complicate the template and logic of the current component... This made the workflow less tedious at first but I quickly learned is a terrible long-term approach. In more JS centric frameworks like React or Mithril I don't have this issue. It's ironic since Rich Harris preaches the "1 screen rule" and this completely breaks that.

The other issue I had with Svelte is the official reactive stores. The first weird thing is in Svelte a store is a reactive variable, not a bunch of reactive state like in other libs/frameworks. It quickly becomes tedious if you need to model semi complex data. Vue has the same problem in Vuex with its shallow (and dumb) objects. MobX IMO is so much better in terms of data modeling since you just define your models in any way you wish (pojos, classes, etc) and you just add decorators for the reactive properties/variables.

You can indeed add MobX to Svelte but then what's the point? It would be better to use Mobx-JSX which adds minimal overhead over MobX and is insanely fast.

https://github.com/ryansolid/mobx-jsx

Of course the problem with MobX is that while it has very nice dev ergonomics it's a very complex piece of machinery.

After fiddling with reactive state for about 4-5 years I've come to the conclusion the best approach is the one that Mithril and Imba follow: no reactivity. Your data is whatever you want and you don't need expensive tooling like MobX/Redux/Vuex to make it reactive. Whenever there is a user event everything is re-rendered automatically and the v-dom or memoized system take care of rendering the DOM parts that need to change. If the data is updated from an API response or some WebSocket the developer just calls a method to let know the renderer the data has changed. It might not be the ultimate fastest approach in terms of performance, but it makes development much more simple and it's fast enough for 99% of use cases.

A Svelte store can hold a deeply nested object. It's up to you how fine-grained you want the stores to be, anywhere from one store per value to one store for the entire application. I think a middle ground is best.

Yes you can, I didn't say otherwise. (I did criticize Vue though)

My point is that Svelte stores are tedious and ironically seem to go against Svelte's filosophy of lean code.

Here are the docs if anyone wants to take a look:

https://github.com/sveltejs/rfcs/blob/master/text/0002-react...

You can do complicated things with Svelte stores, but in my experience most of the time you only need something like this using a writable store:

<script> import {writable} from 'svelte/store'; const person = writable({name: 'Mark', zip: 63304});

  function handleChange(event) {
    const name = event.target.value;
    person.set({...$person, name});
  }

</script>

<input on:input={handleChange} value={$person.name} />

<div> Hello, {$person.name} at {$person.zip}! </div>

Of course if person is only used inside this component, you would not use a store. If it is used in other components, you would typically define and export the store in another .js file and import it everywhere it is needed.

My point is that this is a very simple way to share state between components and nowhere near as complex as the page you shared might indicate. That's because you do not need to use derived stores or custom stores. The simple writable store works in most cases.

Right but this is still a lot of code for changing the name of a person.

Also, this works with pojos and primitive values. What happens when you add class instances, relationships, children, etc?

For example in a project I was working I had geometrical figures in my reactive data model. With classes I could simply do:

    rectangle.getArea()

With MobX this was super simple to implement. If I wanted to change the position of the rectangle I would simply modify the x and y observable properties.

@pier25 You got me curious about this. I've never seen this done with Svelte, so I decided to try it. Check this out: https://github.com/mvolkmann/svelte-with-classes/blob/master....

The key is that when you update a Svelte store you must return a new value. It's enough to just return the value you updated. You see that happening here on lines 16 and 21.

I take your point that this is not as transparent as when using observables. But at least you can use classes that have relationships and call methods that modify the objects when those objects are in Svelte stores.

Exactly but this could become complicated pretty quickly.

Right now you have 1 update operation for an XY translate. What if you wanted to be able to change multiple properties of more complicated classes? You'd need more boilerplate for each update.

Like I said in a previous comment, my favorite approach right now is what Mithril and Imba do: no reactivity. You change your state and when you're done you tell the rendering engine that the state has changed.

https://mithril.js.org/redraw.html

https://www.imba.io/guides/essentials/state-management#state...

Since this is all vanilla you can do pretty much anything you want with your state. Mutable, immutable, etc. You don't need to add the weight and overhead of something like MobX/Redux/Vuex and you can add as much or as little bureaucracy/boilerplate as the project requires.

It seems like both Mithril and Imba do some form of DOM diffing. It’s easy because you just tell it to update the DOM using the latest state. Imba in particular says it has a really fast way to do that. But isn’t it that case that no matter how fast they can make it, it is still doing way more work than an approach that can determine what parts of the DOM need to be updated without DOM diffing?

Mithril uses a vdom so yes it's doing diffing. It's certainly slower than Svelte but it's still plenty fast for most use cases.

https://krausest.github.io/js-framework-benchmark/current.ht...

Most importantly Mithril is very lightweight. Check the startup metrics on those benchmarks. This is not a totally fair comparison since Mithril includes a router and an http client and the others do not. Still, it manages to be among the best.

Imba uses memoization and, much like Svelte, direct DOM manipulation.

https://www.imba.io/guides/advanced/performance

Imba was used to build Scrimba (an online code tutorial/editor) which is very impressive.

https://scrimba.com/

I couldn't get past the Ruby-esque syntax, but it is a very impressive effort.

You can create a custom store in Svelte and do almost the same:

import { writable } from 'svelte/store';

export default function(state) { const { subscribe, set, update } = writable(state);

  return {
   subscribe,
   getArea() { ... }
  };

};

Reply on news.ycombinator.com