Is anyone using Svelte (https://www.svelte.dev) in production? What are your experiences with it? I can't seem to find any experience reports.
Thanks!
The only area of concern at this time is that there is no TypeScript support and debugging can be difficult as it often throws exceptions in vendor code if the error isn't caught by the compiler. Despite this, I've found that I am more productive and get less runtime exceptions developing with Svelte than Angular since it is simpler to develop with and does a lot of compile-time error checking.
I have a repository with working scss and IE 11 polyfills [3]. It's using a custom system for authentication, but it is easy to switch out with something more ideal. There is also a branch with svelte material UI installed. I find that Visual Studio Code with the svelte add-on is the easiest way to work with it.
[1] https://github.com/hperrin/svelte-material-ui/ [2] https://svelte.dev/tutorial/ [3] https://github.com/iwalton3/swapi-svelte
Svelte is the proper step forward - it's an actual improvement in web development and keeps you close to the fundamental technologies without large architectural costs. I know this is a religious argument but after 20 years I am squarely in the readable code vs highly architected code camp. With heavy architecture you have to know too much to get into the code. I remember a joke about Java that to read a text file you needed like 20 LOC and 10 classes (or something like that don't flame me please).
Svelte is clean, has intuitive separation of concerns, is close to the fundamentals, and using it feels like web development has actually been improved. The lack of Typescript will be resolved hopefully soon.
I only wrote this as a public kudos to the Svelte team and to voice my support. Angular's early days were close, vue is closer, Svelte might have nailed it. React belongs in the trash.
Dont flame me please
So obviously the tiny amount of run-time code leads to better performance, but what surprised me was how much better the run-time debugging story is. If my code causes an error to be thrown inside the "framework" code, the stack is always very shallow, and it's easy to follow to figure out what's going on.
Compared to my experience with e.g. trying to trace through AngularJS's digest cycle, following what's going on "under the hood" at run-time is pretty delightful.
I have used React and many others over the years - currently using react in my day job.
I really like Svelte. I would happily choose it over React for any of my own projects. I find Svelte simple and intuitive - it is the easiest framework i've ever used, to get to grips with.
The tooling, resources and no. of 3rd party libraries are way smaller than the bigger hitters, like React - understandably as it is much younger. I have not found this to be an issue at all - theres a VS code extension and a great community and website/docs/examples.
It will obviously be more difficult to find devs with Svelte skills, if you are hiring... but its so easy to pick up, i dont think thats a problem.
The documentation for svelte has been first rate. The shareable REPL has made asking questions and answering them very easy.
The community on Discord has been very helpful.
Since we began evaluating 6 months ago, we have seen a large growth in interest in svelte. I wondered if this was bias, due to our current focus, but I see the increase in my 100s of RSS feeds. (Still a small amount of data points)
Training is a key aspect for us. We will be needing to train our existing team, and svelte feels like a good fit for us. Any new hires would need this skill as a secondary ability, and we feel like it is more likely they would pick up svelte quickly
All that said, we have not made a commitment to svelte yet. Our alternative would be to stay with what we have
But it needs a router. I'm using svelte-routing which works pretty well but even in a lightweight package like Svelte I think it's almost essential to provide basic routing as part of the package.
After all, stores are provided even though plenty of third-party store libraries exist.
The refreshing thing about Vue is that it includes a great router solution out of the box. The Vue team obviously realized it couldn't be considered an optional extra, just as stores aren't.
Yes, Sapper has routing, of a specific kind, but a developer shouldn't have to employ a framework like Sapper to get basic routing functionality.
Otherwise Svelte is killing it. Well done.
However, there’s a couple of unwilling moments:
- A lot of boilerplate code in a newly generated project (very easy to get it outdated when new versions come)
- A popular one: still no good typescript support
And... I think that’s all? Pretty much all the rest is just beautiful.
I think these are two things which bind me from going all in, and use it everywhere, on every new project
Seems to have far less community support and 3rd party libraries available. If you're a business it's probably harder to hire for too as it's less well-known.
I'd also note that Svelte is the least framework-y of all the frameworks, which is why I think it's perfect for beginners.
I like how Blazor approach the template syntax by allowing C# control flow syntax (if, for, ...) but disallow expression and assignment. I think if svelte template syntax allow Js syntax with the same rule as Blazor, it can keep up with Js evolution, especially when it support pattern matching. Also, _maybe_ it will make it easier to implement the autocompletion in the svelte langserver.
Ah yes, one feature request. What about make props and reactive assignment reflect on custom css variable too? (which mean --css-var need to be locally scoped same as how .class is locally scoped).
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.
I get more done with less code, the code is more readable. I notice other frameworks creating hacky solutions to solve simple problems that Svelte just handles out of the box.
I'm also redoing my GitHub pages website to use Svelte to dynamically create the pages with the pages on GitHub as markdown files. This way, I just push new markdown file to the github site. Much quicker and easier.
I've been trying to use Hugo for my site, but I can't get it to do what I want. I'm most likely not patient enough to work with others code. But, by doing my own, I can get it to do what I want easily.
Svelte has totally changed the way I approach web based work!
https://blog.risingstack.com/the-history-of-react-js-on-a-ti...
Fun Fact: The audience was skeptical. Most people thought React was a huge step backward. This happened as mostly 'early adopters' attended this conference, however, React targeted 'innovators.' The creators of React realized this mistake on time, and decided to start a 'React tour' later on to turn haters into advocates.
Previously, only React users were able to use this debugging component (even though the library ships with an API for non-React vanilla JS users as well). After moving to Svelte, all users have a consistent experience, and it's now easy to create wrappers for Vue / Angular without much effort because a Svelte component can be used in all those places in a framework agnostic manner.
Pros:
- Great DX (happy developers)
- Easy to learn
- Code is easy to reason about
- Little boilerplate
- Very fast (not best in class, but close enough)
- The benefits of being a compiler (eg. data viz, more to come)
Cons:
- Lacks official support for TS (coming)
- Lacks the rich ecosystem of React/Vue/Angular (comes with adoption)
Somehow in your tutorials using `$page` for accessing `page` store values completely escaped me.
Keeping an eye on it's development.
I'm a competent all-round developer, but I (was) more comfortable on the server-side than the client-side. However, Svelte has been the first framework (I've used Angular a lot, Vue a lot, and React somewhat) where I've felt fully comfortable working on the client-side too. It's clean, understandable, fast, and it makes sense. It's easy to maintain, and scale my frontend, whereas I've not felt that when I've built similar sized applications with other frameworks.
Svelte, logically, makes sense to me - the API is consistent and sensible, and I can often take a good guess at how to do something without reading the docs. Having no client-side dependencies makes it an absolute ideal fit for distributable libraries too - people can just "slot" our widgets into their site, in one line.
My criticism, as somebody else voiced, is testability. I'm a huge fan of testing, and I generally look for libraries and frameworks which are test-first/test-centric - for instance I use Hapi on the backend, not Express, for this exact reason. That's not to stay that Svelte isn't testable, it's just not been a focus of the framework, and I'd really like it to be. I've had success using [https://github.com/testing-library/svelte-testing-library](h..., and it works well.
I originally built Beyonk in Nuxt but I switched over to Svelte as I had prior knowledge of it, and felt like Vue wasn't quite as nice to code in. After doing so my code was much terser, cleaner, and easier to understand, so I stuck with it and built out the other applications directly in Svelte.
I don't think I could face using any other framework after using Svelte, it would feel like a backwards step. Single-file components are a massive bonus, and scoped styles... I don't know how I lived without them.
It's worth mentioning that when I first learned Svelte (v1) it took me 45 minutes to get the basics and build what I wanted to build. I think the current v3 API could be learned from scratch by a decent frontend developer within a day. That learning curve is drastically lower than that of any other frontend framework I know, and for that reason I'm not concerned about hiring for Svelte.
I think that's about it really. I really enjoy, and in fact, look forward to writing code in Svelte on a daily basis - and for me, that was historically something I never expected to say!
I've used Svelte (with Sapper) for two production apps. One is a small e-commerce app [1] and the other an NFL stats app [2]. They are both static sites, but I won't really get into that. There is a tweet I detailed out a little bit of the second app [3].
Personally, I find Svelte to be the best dev experience I have had and it's not close. To me (like a said, a novice dev), I find myself tripping over frameworky things all the time. The only thing is that before Svelte, I didn't really realize that is what was happening. I just thought that was how web dev was.
However, when I played with Svelte, I instantly felt more productive and confident in my ability to create what I wanted. The main benefit that I have experienced is that it is so simple. There is just less to learn because it builds upon your knowledge of the basics (CSS, HTML, JS). To me, it just organizes these into a nice single file and throws a touch of template markup at you to give you what you would expect from a framework. There's more to comment on, but for brevity, I won't.
I also am just a huge fan of the compiler approach. I know that bundle size is a rather debatable topic as to what matters and what doesn't, but if I can have a great experience building a site AND I get smaller bundles (in most cases) for free, then that is huge to me. I think it is going to allow some cool features in the future, too. I just think it makes a great deal of sense to build things in this way.
The only con I have ran into, which isn't really a knock on Svelte itself, is that the community is tiny (relative to the others). The community that does exist lives on Discord, which is awful for searchability of questions. That said, the docs are great and I have had to Google far less things than I have in the other frameworks I have used, so it is less of a ding than it would otherwise be.
So, Svelte is my new default. I'll continue to fanboy over it to my developer coworkers who love React. They will roll their eyes and become filled with contempt and pity. I'll insult their intellectual capability. We laugh. All of our apps remain in React. Life goes on.
[1] https://bigcreekbarkery.com [2] https://quickfantasystats.com [3] https://twitter.com/pjbrown_11/status/1186012274164752388
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.