Rich Harris joins Vercel to work on Svelte full time
I have recently joined a team that had invested in Svelte. I had previous experience in Angular and React. I was happy with React, but I decided to drink the koolaid and go all-in and do my best with Svelte.<p>6 months later, we&#x27;re moving to React. It is partly because our Svelte code was messy enough to warrant a rewrite, and partly because we wanted to leverage the React ecosystem in that rewrite. It was also partly because I just don&#x27;t like Svelte very much.<p>I think Svelte is clever, and interesting, and I&#x27;m glad it exists. But I found a few points insurmountable:<p>- Too much magic. The abstraction leaks and when it does, it requires a good mental model of Svelte&#x27;s magic. I noticed this threw our juniors off.<p>- Special syntax for reactivity is not javascript<p>- I find the javascript-native flexibility of JSX far more expressive than any custom templating<p>- There are major tradeoffs made by doing things at compile time. Things that are easy in React at runtime turn out to be surprisingly difficult in Svelte<p>- Two-way data binding is a constant source of bugs<p>- Svelte practically requires let-style variable rebinding, often at a file wide scope, which again caused our juniors in particular to write bad code<p>- The style system is too opinionated for me. I also find it necessary to break into the global scope for any minor restyling of a subcomponent (or worse, pass in the style as a prop)<p>- Built in reactive store is cool, but our developers all ended up using it for tight coupling and global variables<p>- The strict one component per file approach can be cumbersome. It&#x27;s not possible to write a one-line function component or similar<p>- Much smaller ecosystem than React, requiring much more to be done in house (exacerbated by all of the above).<p>- The faster runtime speed in no way made up for any of the above. Bad Svelte code is still slow compared to good React code.