Ask HN: What are your experiences with Svelte (JS framework)
Hi HN-crowd,
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!
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
"The compiler is written in TypeScript, but don't let that put you off — it's basically just JavaScript with type annotations."
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
If you feel the need to include this 4x in your post, perhaps it's a good idea to do some re-evaluating ;)
I’m not a Rect developer myself, but it is always interesting to listen to others experiences with it.
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
I have followed that project for many years & it has always had an interesting component system, but I have never done anything serious with it. They have recently released a new major version. Very small community.
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.
Sapper. A bit rudimentary but it dovetails nicely. Plus, built in export for static sites.
Sapper adds a great deal of additional functionality and a framework layout that Svelte on its own does not. All Svelte needs is its own router to be the complete package.
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.
Even still, I think svelte can be a good choice if your focus is on enhancing html with javascript rather than focusing on javascript for everything.
"you don't always need to think about the ability to hire additional developers who know your framework of choice"
Unless you are hiring a junior dev who has no experience I think this statement is pretty far fetched. The ramp up time for a new dev on a framework that isn't widely adopted yet will be way higher, plus hiring developers who would even want to work with said framework sounds like a task in itself as well.
If you want to enhance HTML use Vue, if you want to focus on Javascript for everything use React. I like the idea of Svelte coming in to push other frameworks forward, but by no means do I think Svelte will be the future (this may not age well, but at this time my opinion).
What, like a couple more weeks? I find it hard to believe that an experienced React/Vue/Angular dev would take a long time to pick up Svelte.
For a junior, sure, but I would expect a mid-to-senior developer working on front-end JS for a living to have some experience of at least one of the popular rendering libraries/frameworks and therefore to be able to understand at least the essentials of any of the others after a few hours of training. They're relatively simple interfaces, and many of the same concepts come up in most or all of them. Of course it will take a bit longer to understand the edge cases, any unusual or unique aspects, and any common traps to avoid, but you don't need all of that to be productive with everyday front-end development work. Presumably anyone new and/or below senior level is going to be supervised/mentored while they're getting up to speed and have their code reviewed anyway.
That's how you know you picked the wrong framework.
I learned to use Svelte (granted, v1), in 45 minutes, and build something using it. I guarantee that a developer won't need 2 weeks to become comfortable in it.
Vue is backed and influenced by Chinese corporations, and React is FB, if you dislike both and can somehow afford to avoid depending on them you might become a happier dev.
I don't see any source backing up your claim that Vue would be influenced in any way by China.
And React being supported by Facebook isn't a bad thing either. Means more development time is able to go into it from professional developers.
With React it's different of course, objectively you're right, but subjectively, using React doesn't feel right if you dislike FB, and using FB technology can scare of customers if they get aware of it. If you want to trash a competitor in a space that's somehow privacy focused, just mention that your competitors tech stack is from FB!
As for 3rd party libraries - it's ludicrously easy to integrate anything you want with Svelte. I've built wrappers for Vue and React before, and I can safely say that it isn't necessary for Svelte. Things just work.
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.
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...
<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});
}<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.
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()
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.
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.
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.
I couldn't get past the Ruby-esque syntax, but it is a very impressive effort.
import { writable } from 'svelte/store';
export default function(state) { const { subscribe, set, update } = writable(state);
return {
subscribe,
getArea() { ... }
};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!
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 = {...}
import {propTypes} from "./MyComponent"
import {propTypes as otherPropTypes} from "./MyOtherComponent"
const MyNewComponent = () => {...}
MyNewComponent.propTypes = {...propTypes, ...otherPropTypes}
Also the component model isn't "hacky". It's logical, unopinionated and straight-forward. I don't know how much you know about Rich Harris but he's not one for producing "hacky" public APIs.
That's a pretty strange statement. TypeScript support does not mean you have to use TypeScript. It's purely additive by design.
By hacky I mean "define some global variables and the compiler will do some checks to make sure you don't do anything untoward". You can see my other post in this thread for examples where this model falls apart.
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.
Seems completely anti-user to not have a redirect. I wonder if it's just an oversight.
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.
I think this is the most important metric of any JS project.
We rarely need to update thousands of dom elements per second, but all JS projects need to download and start running ASAP. Specially on mobile.
This talk was pretty enlightening: https://vimeo.com/364402896