Ask HN: What are your experiences with Svelte (JS framework)

I think Svelte is very good for sites. I'm using it for my own, and wrote it up: https://www.swyx.io/writing/svelte-static/. i like that the progressive upgrade story (aka if i need more dynamic functionality, i dont have to retool dramatically) is there and it is super straightforward to use React on top of Svelte if i absolutely need to.

(which coincided with the launch of svelte 3)

I've posted before about my experience with svelte (https://news.ycombinator.com/item?id=20338175). Will try to reiterate a few of them here.

I've been using it internally at my current job to great effect since March, after I convinced my manager to let me try it on a one-off project. That small project has led to us using it for other bigger projects, again pretty successfully.

tl;dr – I probably wouldn't choose to go back to other frameworks after my time in Svelte-land unless I'm in a situation where I have to use React. I don't MIND React, but it's clear that all things equal it simply takes longer to make things with it and the thing I make tends to be harder to work on over time. Svelte is just too good and has probably saved my company some money in dev time & dev happiness. For reference, I work across the data stack – data engineering to stats / ml modeling to frontends / products that use data. It shines in all areas, but it REALLY shines in data viz.

pros:

- the time to first meaningful render in svelte is substantially, substantially lower than it is in React, and you face none of the drawbacks of using the React starter stuff (ie ejecting isn't a thing). This may seem like a weird metric, but I think it's pretty vital. I can easily start a side project w/ svelte and not have to think deeply about getting all the dependencies, all the webpack stuff fiddled with, all that. The ramp to productivity is pretty flat.

- you don't need the Friends part of React & Friends nearly as much, but you can definitely use the ones that are framework-agnostic (like immer, or redux, or whatever). W/ the bigger React projects I work on, I have really struggled with the development speed of 3rd party libraries forcing me to update my components and wasting time. Having fewer dependencies has made my life substantially better. Most projects I just use immer + d3 modules.

- I was pleased to discover that in practice, the boilerplate doesn't ever sneak in, even in complex components. This means that I can either (1) deliver the thing faster, and / or (2) in the same amount of time, make it that much better. It ends up being that both of those things happen.

- svelte stores are incredible. We tend to use them with immer to make redux-like app state work nicely, but we use stores for all sorts of things – contexts for complex components like data graphics (ie we need to share reactive changes arbitrarily to children), tweened and spring. One way that I enjoy using them – I take params from my app store (the one I make w/ immer) and create a derived store that encapsulates a cached dataset request. There are SO MANY cool patterns you can implement with stores that makes your app easy to reason about. Example of a svelte immer app here: https://github.com/hamilton/svelte-immer-example

- having a great story for both style & animation really makes you think that most other frameworks are feature-incomplete. The component authoring experience really makes html and css feel like first-class citizens again. I currently have a designer helping me tweak the css of a bunch of components I've written, and it's wonderful – he doesn't have to learn all the css-in-js stuff I've encountered in other frameworks.

- Svelte truly, truly shines with data visualization, where the reactivity has reduced the cost of authoring data graphics for me. I say this as someone who used to use Protovis and then spent a lot of time in D3-land. Hoping svelte gl lands publicly sometime soon so I can get off of the regl train.

- Svelte creates joy the way jQuery did in the past. I noticed a talk by Rich where he talks about jQuery. This has been how I've described svelte to folks @ my work, and they get it – it DID feel magical then.

cons:

- the testing story isn't well-documented yet, and it probably just doesn't exist yet. I tend to just move code that definitely needs to be tested into separate modules and test them there.

- typescript support would be really nice.

- the community is small, so you have to find answers yourself or make them. This may not appeal to a lot of corporate frontend devs, but it works @ Mozilla where I work, since most folks are pretty web-friendly. I personally prefer this since things that are hard in other frameworks are trivial in Svelte. That is, you just don't need that big a community to be similarly productive.

- your dev culture has to be right for this, and the risk of moving has to be understood. It takes time to figure out how new frameworks pay off.

Since Svelte props are just variables it's pretty easy to do weird things. Also it's kind of a pain to need to open up a file and read through a dozen lines of code to figure out what the props are.

The most important thing is it makes it difficult to build the same tooling that other frameworks have. For example, in React you can either define your props as a TypeScript/Flow interfaces or use the `prop-types` library. This gives you an easy way to automatically validate props outside of the context of component instantiation. For example, you can do:

   import MyComponent, {MyComponentProps} from "./MyComponent"
   const props: MyComponentProps = {...}

Or you can do things like composing props (using prop-types here):

   import {propTypes} from "./MyComponent"
   import {propTypes as otherPropTypes} from "./MyOtherComponent"
   const MyNewComponent = () => {...}
   MyNewComponent.propTypes = {...propTypes, ...otherPropTypes}

All this is possible since props is just a single object that is baked into the React API. In my own Svelte project I've been toying with the idea of only having a single prop called `props` although I'm sure this affects Svelte's rendering performance.

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.