
Ask HN: What are your experiences with Svelte (JS framework) - melleb
Hi HN-crowd,<p>Is anyone using Svelte (https:&#x2F;&#x2F;www.svelte.dev) in production? What are your experiences with it? I can&#x27;t seem to find any experience reports.<p>Thanks!
======
iwalton3
I've been pretty happy with it. I migrated my website to use it and I'm also
using it for a new project. I've found that I'm significantly more productive
with it than when using React or Angular, since there is two-way binding and
very little boilerplate. There is also a material UI binding for it [1], which
makes it easier to develop advanced user interfaces. In my experience, bundle
sizes with Svelte can be smaller than JQuery, whereas I typically see bundles
over 1 MB for Angular and larger than JQuery for React. The framework is also
very easy to learn, as there is a full interactive tutorial [2] online and the
framework is optimized for development experience.

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/](https://github.com/hperrin/svelte-material-ui/) [2]
[https://svelte.dev/tutorial/](https://svelte.dev/tutorial/) [3]
[https://github.com/iwalton3/swapi-svelte](https://github.com/iwalton3/swapi-
svelte)

~~~
snak
How come there is no TypeScript support, but in the official GitHub repo
([https://github.com/sveltejs/svelte](https://github.com/sveltejs/svelte))
they state:

"The compiler is written in TypeScript, but don't let that put you off — it's
basically just JavaScript with type annotations."

~~~
pcr0
Writing a JS compiler in TS is easier than writing a TS compiler in TS, since
TypeScript is a superset of JavaScript.

------
throwaway541403
Svelte (and Sapper) has the potential to be huge. I normally don't participate
on any online forum but signed up specifically to comment on this topic. I've
experienced building web sites starting with cgi-bin handlers to React apps
and everything in between. React reminds me of the Java days when we would use
the Spring framework - huge tooling and setup, architecturally moribound (in a
sense, dont flame me), and too many layers separated from the fundamental
technology - HTML/CSS/Javascript. Out of all web tech, React is my least
favorite and I find it in many ways to be absurd (my opinion, dont flame me).
Don't get me started on React Native...

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

~~~
leaveyou
I almost flamed you.. but After xteen years I still try to like web
development but I still fail to comprehend why the web dev world struggles to
reinvent programming starting mid air and working towards foundations,
starting with a flawed high level language and going towards "assembly",
starting with an incomplete set of high(er) level UI primitives (input,
button, select, p, div) and a primitive rigid layout system and working
towards components and more complex forms of declarative layouts. Please
someone make a Svelte compiler in Go.. I can't stand Node.js and I can't
install it on my machine without feeling dirty. Please don't flame me..

~~~
batisteo
There’s a decent JS to JS compiler (replacement of Babel) in Rust which
understand TypeScript: [https://swc-project.github.io](https://swc-
project.github.io) This could be a good starting point.

------
TehShrike
I've been using Svelte in production for over two and a half years. It's tough
to go back to a fully-run-time framework after using Svelte.

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.

------
mjashanks
Yes! I have been using Svelte on Budibase
([https://github.com/Budibase/budibase](https://github.com/Budibase/budibase))
for the past year. Although Budibase is not in production yet, its a serious
project that we plan to release in the next few months.

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.

------
leejoramo
Our small team is currently evaluating svelte as a replacement to riotjs and
vuejs. We have reimplemented several of our projects in svelte and like the
results and the easy learning curve for getting our team up to speed.

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

~~~
arxpoetica
I've been using Svelte since inception, and you're 100% right, there's been a
significant uptick in user base over the last 6 mos. Basically since Rich did
his Rethinking Reactivity talk at YGLF back in April.[1]

[1]
[https://www.youtube.com/watch?v=AdNJ3fydeao](https://www.youtube.com/watch?v=AdNJ3fydeao)

~~~
swyx
(which coincided with the launch of svelte 3)

------
hackjackback
Fantastic.

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.

~~~
jcollum
>But it needs a router.

Sapper. A bit rudimentary but it dovetails nicely. Plus, built in export for
static sites.

~~~
hackjackback
I mention Sapper above.

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.

------
jerrygreenest
Not using in production but really willing to do so, because the concept is
just beautiful. Writing components is a pleasure. Fresh view at animations,
which I haven’t tried much, but it looks very promising and convenient (and
ofc fast, - first of all). Very, very good tutorials!

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

------
benbristow
Looks neat but I don't know why you'd choose it over one of the big 3
(React/Vue/Angular).

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.

~~~
deltron3030
>Looks neat but I don't know why you'd choose it over one of the big 3

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.

~~~
benbristow
Even if Vue was influenced by China, does it matter? It's an open source
front-end library. It's there for everyone.

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.

~~~
deltron3030
It matters if devs who depend on donations for a living get their donations
cut because someone they know or even themselves do something China doesn't
like.

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!

------
himynameisdave
Love the performance, love the component model, and honestly the tooling is
starting to get really, really good. I think 2020 is really going to be
Svelte's year.

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.

------
drsensor
I wish the template syntax is similiar to Blazor. I feel the {#await} block is
a bit too magical. Also, I'm afraid the template syntax can't keep up with Js
syntax which keep evolving.

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).

------
pier25
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](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.

~~~
mvolkmann
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.

~~~
pier25
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...](https://github.com/sveltejs/rfcs/blob/master/text/0002-reactive-
stores.md)

~~~
mvolkmann
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.

~~~
pier25
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.

~~~
mvolkmann
@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...](https://github.com/mvolkmann/svelte-with-
classes/blob/master/src/App.svelte).

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.

~~~
pier25
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://mithril.js.org/redraw.html)

[https://www.imba.io/guides/essentials/state-
management#state...](https://www.imba.io/guides/essentials/state-
management#state-management)

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.

~~~
mvolkmann
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?

~~~
pier25
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...](https://krausest.github.io/js-framework-
benchmark/current.html)

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](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/](https://scrimba.com/)

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

------
shdh
I've written applications using JQuery, AngularJS, Angular, Polymer, and Vue.
And I can easily say Svelte provides the best development UX of the bunch.

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.

------
spiffytech
I've used it for a small side project. It's fun to build in, but the testing
story is almost non-existent.

~~~
mvolkmann
The testing story just hasn't been well documented yet in the official docs. I
have documented both unit and end-to-end testing with Svelte here:
[https://objectcomputing.com/resources/publications/sett/july...](https://objectcomputing.com/resources/publications/sett/july-2019-web-
dev-simplified-with-svelte)

~~~
spiffytech
Great link! Were you able to get unit tests with `context` working? Last time
I tried (I believe with @testing-library/svelte) it didn't work because each
component is compiled separately and don't share a runtime.

~~~
mvolkmann
I haven't tried that.

------
mvanhalen
We are currently in a migration process. So far I love it. It's the smart
thing and fast to learn. Tried vue.js as well. But Svelte is just more simple.
Need to be self enabling and finding or making stuff , but having 100% control
is great. Created our own Svelte repl for svelte template integration.

------
raguay
I love it. I am working on a project using NW.js for a desktop application. I
first did it in Vue, then moved to Mint, and now using Svelte. I had to move
away from the other two due to limitations that I could not figure out how to
get past. Also, moving to Svelte had the final build 1/3 of the size of the
other two (Mint uses React under the hood).

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!

------
ng12
It's cute but I can't recommend it for a project with more than one developer.
Lack of TypeScript support and the hacky component model (specifically,
Svelte's equivalent of React props) are the two big deal-breakers.

~~~
vivekseth
I haven’t done much React, but I’ve played around with svelte a bit recently
and I haven’t found any severe issues with the props model. What don’t you
like about it?

~~~
ng12
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.

~~~
thebosz
You could just use the undocumented but totally available $$props object.

------
dkondrad
Every new thing has humble beginnings...

[https://blog.risingstack.com/the-history-of-react-js-on-a-
ti...](https://blog.risingstack.com/the-history-of-react-js-on-a-timeline/)

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.

~~~
derision
I still think react and angular are a step back

~~~
dkondrad
I don't disagree, but there are enough references to the "big 3" in this
discussion to warrant a reminder of its lack of developer acceptance early on.

------
swyx
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/](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.

------
bglusman
Silly note, but its just [https://svelte.dev](https://svelte.dev) and weirdly
they don't appear to even have the www subdomain registered, so anyone copy
pasting above will error, but the site is up.

~~~
ceejayoz
Apparently they're adherents of [http://no-www.org/](http://no-www.org/).

~~~
lootsauce
if that is the case they are not doing it right - from your link: "we make the
modest proposal that website makers configure their main sites to be
accessible by domain.com as well as www.domain.com."

Seems completely anti-user to not have a redirect. I wonder if it's just an
oversight.

------
mvolkmann
I absolutely love Svelte ... and Sapper too! Here's a talk I gave recently on
Svelte.
[https://www.youtube.com/watch?v=PXOE7oZyaBA](https://www.youtube.com/watch?v=PXOE7oZyaBA)

------
nicolodavis
I recently switched a debugging component that ships with
[https://boardgame.io/](https://boardgame.io/) to Svelte (previously React)
and it has been quite nice to work with.

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.

------
sheikalthaf
I really love svelte. But in our company they afraid to use this because lack
of typescript support. Without the typescript support it is very difficult to
use in any enterprises application. We love svelte and waiting for .ts

------
jerrekent
I think it really needs an official router, on-par with vue-router, and of
course Sapper doesn't count because it is a full framework, requires you to
have a server and its too complex anyway

------
joakims
I'm very impressed with Svelte so far, I think it has set a new standard for
front-end frameworks.

Pros:

\- Great DX (happy developers)

    
    
      - Easy to learn
    
      - Code is easy to reason about
    
      - Little boilerplate
    

\- Small code base (less bugs)

\- 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)

------
jakestuart
I evaluated Sapper and Svelte previously for a side project. The tutorial and
tooling was great. Unfortunately, the hacks needed to add typescript made it a
nonstarter. I look forward to TS becoming a first class citizen like what
happened with Next.js (the solution I chose in the end).

------
jcollum
I've created a small site to be used by a nonprofit. A few pages, JAMstack. I
think it's great and will try to use it as much as I can in the future.

Somehow in your tutorials using `$page` for accessing `page` store values
completely escaped me.

~~~
leke
I heard that too on the Reddit sub a few days ago. Perhaps it's something the
doc writers want to address.

------
softwarerero
I used it for a few small apps and enjoyed. I also build/rebuild a few static
sites with Svelte and it is my default tool for static sites now.

~~~
godot
How does Svelte handle static site generation? For context, I did some React
for a job (using SSR), and have recently tried learning Vue in a small hobby
project, using nuxt.js with it for static site generation. Is there an
equivalent of nuxt for Svelte to handle all the generator tooling?

~~~
vivekseth
There is! [https://sapper.svelte.dev/](https://sapper.svelte.dev/)

------
dgrammatiko
My only problem is that I cannot export as custom element. Web component is
nice but shadow dom is complicating far too much my use cases

~~~
TehShrike
The Svelte compiler does support exporting as a custom element:
[https://svelte.dev/docs#Custom_element_API](https://svelte.dev/docs#Custom_element_API)

~~~
dgrammatiko
Well, I know that it supports exporting to custom elements, what I miss is the
option to NOT use shadow DOM (now it is forced)

------
aabbcc1241
I feel crystal clear about the state and logics but missing typescript support
bring me to stencil for now.

Keeping an eye on it's development.

------
wirahx
I've been using Svelte for nearly 4 years now, with nearly 3 of those in
production. Our entire site [https://beyonk.com](https://beyonk.com) as well
as our admin, backend, and client apps, widgets, and SDKs are all built in
Svelte.

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...](https://github.com/testing-library/svelte-testing-
library\]\(https://github.com/testing-library/svelte-testing-library\)), 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!

------
pjbrown_11
I work in the software dev industry, but not as a developer. I do some
freelance and hobby development. I've made prod apps with AngularJS, Angular,
and Vue. My view on development is much more from a business owner and creator
perspective than a career developer. So, take that for whatever you want.

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](https://bigcreekbarkery.com) [2]
[https://quickfantasystats.com](https://quickfantasystats.com) [3]
[https://twitter.com/pjbrown_11/status/1186012274164752388](https://twitter.com/pjbrown_11/status/1186012274164752388)

------
hasparus
‪I miss code completion and tooltips from TypeScript. Thinking about migrating
from Sapper to Next with TS TBH.‬

------
hamilton
I've posted before about my experience with svelte
([https://news.ycombinator.com/item?id=20338175](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](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.

~~~
pier25
> _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 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](https://vimeo.com/364402896)

~~~
hamilton
Thanks for the link. Incidentally I have that same talk bookmarked. Though for
the record, I have needed to render thousands of dom elements per second :)

------
chovy
Love svelte but you desperately need an official router

