
Why Svelte is our choice for a large web project - overtowed
https://github.com/feltcoop/why-svelte
======
overtowed
Author here, just wanted to make a note. This isn't written to hype a battle
in the holy war. Frontend frameworks are a positive sum game! Svelte has no
monopoly on the compiler paradigm either. Just like I think React is worth
learning for the mental model it imparts, where UI is a (pure) function of
state, I think the frontend framework-as-compiler paradigm is worth
understanding. We're going to see a lot more of it because the tradeoffs are
fantastic, to where it'll be a boring talking point before we know it.

~~~
marcus_holmes
I'm curious that you didn't mention Elm here. Did you look at it and decide
not, or not look at it?

~~~
overtowed
It's not a comprehensive weighing of alternatives, instead it's a deep dive
into Svelte's pros and cons as they relate to my experience and our project.

Elm is awesome! There's nothing quite like it that I know of in its design
space to bring user-friendly functional programming to the web. Similar to
Svelte, its design holistically packages up the web's languages. Compared to
PureScript, it's focused on a small and beginner-friendly feature set, trading
general power to optimize for the webapp use cases. Elm has also been
influential to a lot of toolmakers!

~~~
marcus_holmes
Thanks, that's useful :)

~~~
overtowed
Sure, thank you for the question! It prompted me to add a note about Elm and
Dart in a relevant section in the document.

One important difference with Svelte versus Elm is that Elm makes a clean
break from web technologies, while Svelte is designed to work with future
versions of the web's languages.

------
xrd
I love React and I love Svelte. There, I said it.

These are the complaints that standout for me with Svelte after using it for a
few months:

* Sub-par editor support. For me, the litmus test is whether I can use F2 to rename a variable, and it often does not work inside a Svelte template. There are other places where the editor does not know what to do with your code, because it is not pure JS. Vue is much worse with this since so many things are just strings; React really shines with editor support. This makes a big difference when you are using a large project where you didn't write the code.

* I don't love that you have to re-assign a object/array variable to get Svelte to notice it changed, and you can do that inside a Svelte template to a const variable and you won't get a complaint from the compiler.

* Much smaller ecosystem compared to React and Vue, which is expected at this point.

Other than this, I absolutely love Svelte. Stores are such an amazing
abstraction. Animation is well thought out. Storybook works perfectly. Mostly
it is pure JS once it gets inside the browser, so you can debug effectively
which is not the case with Vue for example.

~~~
leppr
Since you've been using Svelte for a few months after using React, haven't you
been hit by the lack of composability in Svelte?

Passing around components as variables is such a common pattern in React, and
there's no good replacement in Svelte. The lack of dynamism in components and
styles makes theming and crafting reusable components (outside of simple
widgets) very tedious [1][2]. I'm genuinely curious how someone can come from
React and not be bothered by it.

[1]:
[https://github.com/sveltejs/svelte/issues/2106](https://github.com/sveltejs/svelte/issues/2106)

[2]:
[https://github.com/sveltejs/svelte/issues/1550](https://github.com/sveltejs/svelte/issues/1550)

~~~
jiofih
Passing components is totally supported, and you can use slots. There isn’t a
single issue I identify with in that GH thread...

~~~
leppr
Slots are currently an unwieldy band-aid.

[https://github.com/sveltejs/svelte/issues/1037](https://github.com/sveltejs/svelte/issues/1037)
(open since 2017)

[https://github.com/sveltejs/svelte/issues/2079](https://github.com/sveltejs/svelte/issues/2079)

The simple usage of passing a component to a component, which almost every
decently-sized project will make use of, has no convenient syntax, only
workarounds:

    
    
        // parent.svelte
        <script>
          import Nested from './nested.svelte'
          import Child from './child.svelte';
        </script>
        <Child>
          <div slot="bar">       <-- Extra wrapper DOM node
            <Nested foo="Foo"/>
          </div>
        </Child>
        
        // child.svelte
        <slot name="bar" {...data}/>
    
    

Passing down an element as a prop requires separating the component
constructor and its data and manually re-conciliating the two in the child
component every time, since components can't be rendered from functions. It
works but it's unnecessary boilerplate.

    
    
        // parent.svelte
        <script>
          import Nested from './nested.svelte';
          import Child from './child.svelte';
        </script>
        <Child nested={Nested} nestedData={{ foo: "Foo" }}/>
        
        // child.svelte
        <script>
          let export Component;
          let export componentData;
        </script>
        <Component {...componentData}/>

~~~
troyk
I'm evaluating svelte and have yet to do much, however handling dynamic
components is a key requirement, and appears to be supported like so:

    
    
      <script>
        import RedThing from './RedThing.svelte';
        import GreenThing from './GreenThing.svelte';
        import BlueThing from './BlueThing.svelte';
    
        const options = [
          { color: 'red',   component: RedThing   },
          { color: 'green', component: GreenThing },
          { color: 'blue',  component: BlueThing  },
        ];
    
        let selected = options[0];
      </script>
    
      <select bind:value={selected}>
        {#each options as option}
          <option value={option}>{option.color}</option>
        {/each}
      </select>
    
      {#if selected.color === 'red'}
        <RedThing/>
      {:else if selected.color === 'green'}
        <GreenThing/>
      {:else if selected.color === 'blue'}
        <BlueThing/>
      {/if}

~~~
leppr
That's the tutorial challenge code, you get the `svelte:component` solution
after clicking "Show me".

[https://svelte.dev/tutorial/svelte-
component](https://svelte.dev/tutorial/svelte-component)

But yea that's indeed what I should have done in my example if I wanted the
component to be reactive, as you can see that's even more verbose and still
doesn't take care of props.

~~~
xrd
I love this thread!

And, isn't it likely this will be easier to support with Svelte eventually? My
reasoning is that you just need to add a little syntactic sugar to the
language and the compiler can add whatever code is necessary? With a runtime
like React and Vue, it seems much harder to add in.

~~~
leppr
It's think it's likely the two issues I highlighted will eventually have
syntactic sugar, I never wrote a transpiler but it doesn't seem that hard to
support. It doesn't appear to be a priority though.

 _> With a runtime like React and Vue, it seems much harder to add in._

As a rule of thumb, it's almost always easier to add things at runtime than at
compile time. That's why it took us so long to get Rust.

------
DigitalSea
For me, the biggest downside to Svelte is the lack of TypeScript support. This
is a massive deal-breaker for myself as well as many other developers. I am
also not a fan of the Moustache/Handlebars inspired templating, it feels
outdated in the face of enhancing standard HTML or going in the direction of
something more extreme like JSX.

I think Svelte is refreshing, but I would not be comfortable using it on a
large-scale web application just yet given the downsides, particularly an
enterprise LOB application with many moving pieces. This is why frameworks
like Angular, Ember and Aurelia on the front-end lend themselves better to the
enterprise and React and other more component-based libraries do not.

In terms of community size, I don't think that matters in 2020. You don't need
a big community if you have something straightforward and easy to work with.
Great read.

~~~
aarpmcgee
I submit that any large Ember codebase is intractable without Typescript.

~~~
mdgrech23
I submit that Typescript is largely overrated, adds unnecessary complexity and
fails to catch a large number of issues at compile time that it should in fact
catch.

~~~
DigitalSea
What are you basing this on?

------
nlh
I'm rapidly becoming a huge Svelte fan. Quick self-promotion plug (but in the
name of altruism): I've been working on an open source project that glues
together Svelte (on the front end) and Crystal (on the back end).

[https://github.com/noahlh/celestite](https://github.com/noahlh/celestite)

Two slightly obscure (but growing) languages/frameworks, but hey, gotta pick a
niche. Contributions & feedback welcome!

~~~
ibly31
Cool project! Made me actually check out Crystal Lang - looks like a much
nicer, modern version of Ruby without the cruft.

Found a straggler "CrystalVue" substring in the main .cr file, you should give
'er the old find-and-replace all to change them.

~~~
nlh
Oh thank you!! I totally missed that.

------
rikroots
I enjoyed learning Svelte; it was fun to use when I rebuilt a personal project
from scratch using it[1].

I'm trying to think of some downsides to balance my enthusiasm for the
framework, but can't think of any. The article mentions the smaller community
as a possible issue, but the community on Discord seem very welcoming.

Re "using Svelte means adopting a new language" \- it didn't feel like that to
me. Every framework has its own way of doing things; Svelte's way didn't annoy
me as much as some other frameworks have done in the past (eg: Angular before
it became Angular2).

I've got another personal project rebuild coming up - I reckon I'll be
treating that as an opportunity to learn more Svelte.

[1] My poetry website (you have been warned!) -
[https://rikverse2020.rikweb.org.uk/](https://rikverse2020.rikweb.org.uk/) I
blogged about my experiences with Svelte, starting here:
[https://blog.rikworks.co.uk/2020/02/01/Recoding-the-
RikVerse...](https://blog.rikworks.co.uk/2020/02/01/Recoding-the-RikVerse-
website-Introduction/)

~~~
untog
> Re "using Svelte means adopting a new language" \- it didn't feel like that
> to me.

Me neither, but I've been around long enough to remember the handlebars.js
days. To someone that's only used React I imagine that at first sight things
like {#if} {/if} look ugly as hell. To those people I can only say to stick it
out: it starts to feel very natural very quickly.

~~~
papertokyo
This was my experience. I've been working with Vue for the last few years so
Svelte's syntax for loops and conditionals looked a bit funky...but after
using it I realised that it's a lot more readable and enjoyable to work with.

------
mattkrick
I LOVE what svelte is doing. I've been using React daily for the last 5 years
& it does the job, documentation is world class, community is great, but it
still has sharp edges & parts that feel bad. Things like hooks make
complicated things look & feel simple, which is great for 80% of my work, but
for that other 20% (exit animations, high frequency re-renders, drag-n-drop
without HTML5) I do some pretty atrocious things to make it work. This is
where svelete shines.

The readme does a good job of pointing out its shortcomings, too. Primarily,
no typescript support yet & the unknown bundle size inflection point. As soon
as these are solved, I can't imagine it not becoming the best (albeit not most
popular) solution.

~~~
jdmg94
you should look into the libraries of Paul Henschel

------
Tade0
I applaud the effort and will be following this project closely.

I love the pragmatism of this framework - no solutions looking for problems or
complex, badly documented abstractions.

Even if Svelte won't be _the_ next generation framework everyone will be
using, the ideas it presents are definitely something the web needs.

------
StevenWaterman
Having used Svelte for a couple of projects [1][2], I love it. Compared to my
day job working in react/redux, it is much simpler, and feels like it has far
less boilerplate.

There are certainly a few rough edges, but it's all related to the immaturity
of the language. Specifically, I had a hard time understanding transitions and
it wasn't at all obvious how to integrate it with D3. Hopefully as it grows we
will see improved docs and examples.

Also, I'm holding out for more mainstream TypeScript support. At that point,
it would be hard to convince me to use anything else.

[1] [http://musetree.stevenwaterman.uk](http://musetree.stevenwaterman.uk)

[2]
[http://optimisation.stevenwaterman.uk](http://optimisation.stevenwaterman.uk)
\+ [https://blog.scottlogic.com/2020/02/17/minesweeper-
optimisat...](https://blog.scottlogic.com/2020/02/17/minesweeper-
optimisation.html)

~~~
acemarke
FWIW, our new Redux Toolkit package is specifically designed to eliminate the
typical "boilerplate" concerns when using Redux:

[https://redux-toolkit.js.org](https://redux-toolkit.js.org)

~~~
StevenWaterman
I do use Redux Toolkit, but it really can't compare to Svelte. There are so
many moving parts in a Redux app that there's only so far it can be simplified

------
okareaman
I watched a tutorial by the author Rich Harris today after reading this link
on HN earlier and stopped when he started talking about a DSL he created for
Svelte so you don't have to write as much JS. I don't want to learn another
DSL. I don't see what the big deal is about compiling. We've have many
languages that compile to JavaScript and Google Closure Compiler to tree shake
and minify. For years now! Svelte is a nifty DSL to JS compiler that produces
small bundles because there is no SDK to back it up or include. Cool, I guess.

~~~
overtowed
Svelte is a component compiler, not a general language compiler. Big
distinction! Being purpose-built for this use case opens up a lot of
opportunities.

The article goes into this more, but Svelte's DSL is an extension of web
languages - not much to learn really! Your existing knowledge of HTML, CSS,
and JS transfers directly.

------
crubier
I dislike the templating pseudo language of Svelte (and many view frameworks).
Maybe I am spoiled by react but I never ever want to write my view logic in
anything else than JS. This is my main blocker for Svelte.

~~~
papertokyo
I've never fully understood this viewpoint, which comes up a lot in relation
to React and JSX specifically.

The templating in Svelte and Vue is (almost) html with some magic sprinkled
here and there, so much closer to the end result. Using JS for everything is
moving further away from the metal.

What is it about writing views the React way that appeals to you more?

~~~
hinkley
What I found on several consecutive projects was that less the HTML generation
resembles the final HTML, the harder it is for people to keep the CSS
selectors wired up correctly. Getting text into the page as fast as possible
at the cost of layout issues is a sucker's bet.

You can't ship until it looks good, and the longer features are in-flight the
worse management feels about the team's abilities.

~~~
inopinatus
A utility-first compile-time CSS framework (eg Tailwind) should be a perfect
fit for this scenario, on multiple levels

~~~
hinkley
Two of the projects I'm thinking of used Sass or Less. The problem is on
figuring out why you have black text on a black background because your CSS
selectors no longer match the DOM structure, when the DOM structure is split
up and/or not even HTML-like anymore.

You don't want situations where senior staff have to intervene on what should
be a straightforward issue. It gums up the works.

------
dzonga
I love svelte. but now resorting to server rendered html pages with sprinkles
of JS. shit I work on and I have noticed in the world doesn't really need
frameworks like react, svelte, vue etc.

~~~
snapetom
Same. I haven't done frontend work for a job for about a decade, but kept up
to date with things like Angular/Vue/React. I was recently vountold by my wife
to create a reunion site for her class. I looked up "barebones front end
frameworks." Anything that began the "Getting Started" page with "npm install"
I noped out of there.

I ended up with Skeleton/jQuery for the front end and PHP Slim for the
backend. This is a 5 page, 2 forms, site targeted at 100 people. There's no
need to SPA this, npm that.

~~~
ComputerGuru
Someone on HN recommended it to me before, so I’ll just pass this along: look
at intercooler JS for making individual “live widgets” on a well-designed
graceful degradation site like you describe.

~~~
sam_goody
Also Alpine.js, which has got quite a community behind it (somehow promoted by
Laravel, IIRC). It is less than intercooler, but provides timesavers for
simple sites like described. A compromise between a framework and none.

~~~
ComputerGuru
No, that’s not along the lines of what I’m suggesting at all.

------
mulholio
What I'd hoped to see here was why use Svelte for a _large_ web project. I get
the advantages, but devising and maintaining good architecture is hard enough
in the more established React paradigm. What do complex and older Svelte apps
look like? This is the part that's missing for me, not pleasant DX and early-
web nostalgia.

~~~
overtowed
Good question, thanks for asking it. I didn't explicitly address this (oops)
and I'll have to do some more thinking. My first reaction is that:

1) Svelte gives you a solid foundation and lots of flexibility

2) difficulty scaling for large apps is mostly orthogonal to the component
library

3) Svelte provides flexible and sugary integration points for these orthogonal
concerns

For example, since we're talking large projects, the biggest concern is state
management. Svelte is like React here, in that you could use MobX or Redux
with a connector library, or RxJS with Redux, or other combinations. As long
as your solution is compatible with stores like RxJS is, you benefit from
Svelte's auto-subscriptions[1] and sugary store dereferencing[2] that's
agnostic to your underlying state management solution.

[1] [https://svelte.dev/examples#auto-
subscriptions](https://svelte.dev/examples#auto-subscriptions)

[2] [https://svelte.dev/examples#readable-
stores](https://svelte.dev/examples#readable-stores)

------
nailer
Going back to React a week ago after doing Svelte seriously since Oct 2018 is
tough. Asides from the obvious stuff - Svelte's speed and bundle a size of 0:
JSX isn't HTML, using weird helpers to enable a class when a JS ternary would
do fine, setting state is clumsy, and there's way too much complexity if
you're not already used to using React.

That said, I'm also really enjoying TS so could understand why someone may
want to stick with React for a new project until Svelte gets TS.

My big Svelte project isn't public but my personal site is a Svelte app too:
[https://mikemaccana.com](https://mikemaccana.com) source is at
[https://github.com/mikemaccana/mikemaccana.com](https://github.com/mikemaccana/mikemaccana.com)

------
pier25
I love many things about Svelte but after using Vue for a couple of years I
wouldn't go back to single file components.

The idea of having markup+logic+styles in the same file works for small
components but it gets muddy on bigger ones. It can be argued that components
should be as small as possible but OTOH having to create a new file for every
damn component gets old very quickly.

For the past 2-3 years I've been working again with JSX based libraries and
being able to create micro components on the same JS file makes a lot more
sense.

I've also gone back to regular SASS and moved all CSS outside of components
(except for dynamic CSS). It works better IMO than single file components.

------
TekMol
I have switched to pure HTML/CSS/Javascript for frontend. And I am very happy
with it.

I sometimes use external libraries. For example handlebars if I want to
template something clientside.

But no more frameworks.

I think pure Javascript is plenty enough these days.

For those who can't live without a framework: What would you miss?

~~~
ratww
> For those who can't live without a framework: What would you miss?

The thing I miss the most is a good component and state abstraction. That's
it.

I would be very happy using ASP.NET WebForms today: components are rendered
100% in the server but the state is persisted by the client using a <input
type=hidden> field. The server can be 100% stateless.

Too bad it is impossible to convince anyone to pick up ASP.NET WebForms in
2020 :)

Modern backend frameworks such as Rails and Django have similar "component-
ish" helpers, but those always fall short of the capabilities of both
React/Vue and ASP.NET WebForms, and you have to worry about state by yourself.

Phoenix Live View is cool, but needs a stateful server, requires JS and
polyfills up the wazoo. At this point I'd rather use Vue or React.

~~~
aliswe
Aspnetcore Razor pages is basically web forms with cshtml, if you ask me...

~~~
ratww
That's true. I've been out of the MS ecosystem for ages, but I keep forgetting
about Razor Pages.

Components in Blazor actually look like Svelte, or maybe it's the other way
around.

------
leejoramo
I am on a team that has chosen Svelte to replace Riot.js. It has been an
excellent experience. We have found that since Riot and Svelte have some
similarities in structure and do not use a shadow DOM, we that our old Riot
code and new Svelte code co-exist while we build new features and slowly
migrate everything.

Our team has diverse experience with the other tools in this space. I would
say that the consensus is that Svelte is far more intuitive and _fun_ than
other tools.

------
d0100
I want my templates as first-class citizens. If I have to deal with strings
and weird, half-baked syntax for loops and conditionals, I'm out.

JSX really spoiled me to the point that if there isn't JSX, I don't want it.

~~~
toastal
I still feel the opposite. If your client-side 'templates' aren't just
function syntax, I don't want your template system.

------
Vinnl
Ah, I mentioned it on Twitter [1] somewhat prompted by seeing this article,
but before reading it, but:

> It's interesting that Svelte is positioned as a Javascript framework: it
> seems to be practically a different language, far more so than JS+JSX.

> The downside is that it's hard to integrate with much of the Javascript
> ecosystem, e.g. TypeScript.

> Yet at the same time, it doesn't fully embrace being a different language,
> so it does not add features like e.g. how Elm supports pattern matching.

> It does make it an easier sell, I suppose, which does certainly count for
> something. Am I missing something else?

After having read it, it does seem that the author does both consider it a
separate language, but also still presents it as a JS framework. I wonder if
the former isn't being underestimated?

[1]
[https://twitter.com/VincentTunru/status/1237422539128868865](https://twitter.com/VincentTunru/status/1237422539128868865)

------
sergiotapia
I like what I see from Svelte but I'm afraid it's going down the exact same
road Meteor did.

Too many options, not enough Blessed Solutions for basic things.

Take routing for example, in Svelte you have a lot of options but no real #1
"Svelte Recommends (tm)". They should solve this problem before it gets out of
hand. It killed Meteor.

~~~
mvolkmann
Sapper provides a great option for routing. I view that as the official
routing solution, but there are other options too.

~~~
pier25
But Sapper is server side, no?

------
finchisko
Shameless plug. I've choosen svelte for webextension that will be allow you to
record, replay and modify requests on the fly. I've choosen Svelte, because 1.
courisity and 2. it can compile to webcomponents and also reference
webcomponents in normal svelte components. I discarded the webcompoments for
everything idea, mostly because clunky passing and registering events with
svelte (svelte issue). There few thing that needs to be polished, like
typescript support and this events handling with webcomponents, but overall,
very satisfied with svelte so far (as former React guy).

------
vosper
I enjoyed the brief period I spent playing with Svelte. I ran into some bugs
with the built-in animation support when changing states (there's built in
animation support for changing states!) that I couldn't resolve, and which
were pretty glaring in the UI. This was 6-9 months ago, though, so it may well
have been fixed by now.

I'd really encourage all front-end devs to take Svelte for a spin, if for no
other reason than to see a framework really trying to do things differently.
There are a lot of nice ideas in there, and the works-out-of-the-box level is
admirable.

------
choward
> Svelte is one of the 6 JS frameworks in the (flawed) State of JS 2019 survey
> — 75% have heard of it, 7% have used it, and 45% are interested in learning
> more

Why is it flawed and why are you citing a flawed study? You mention that it's
flawed twice but then immediately cite data from it. If you're telling me it's
flawed why should I care about the data?

~~~
overtowed
I considered linking or footnoting that text and probably should have.

Like all surveys, there's a selection bias. For example where are the world's
millions of jQuery developers?

There's also a lot of controversy around Angular's treatment in the survey and
an alleged pro-React bias. This shouldn't affect the Svelte numbers much.

Thanks for bringing it up - I'll improve the text somehow.

------
awinter-py
hate all frontend compile steps from a developer productivity perspective but
love it from a user value perspective, especially if that enables JS-disabled
browsers to more or less use dynamic sites

------
afraca
Slightly offtopic: Why a git repo for a blog post? I guess there are some
pro's: public history, PR's , but a blog has comments directly under the
article for example. Forking is not expected. Ah well, extensive information
anyway, good work :)

~~~
frozenlettuce
some people have been using the Issues tab to create blogs (as it allows
comments)

------
smithza
Especially excited to consider a solution without huge runtime libraries
(think jQuery, React, Vue). Minimizing web page sizes and enabling dynamic
content (which is a mainstay in modern websites) is a huge plus.

~~~
krainboltgreene
React 16 is 2.2 KB or 34.8 KB if you include react-dom, Vue 2.4 is 20.9 KB,
and jquery 2.1 is 28.87 KB.

If you're using a bundler that can create chunks, your user is at best
downloading this once in a blue moon.

The reply page I'm using now is 10% bigger total than these packages and has
to be pulled every time apparently.

By what metric are these "huge runtime libraries"?

~~~
untog
> React 16 is 2.2 KB or 34.8 KB if you include react-dom

Gzipped. Uncompressed React is 6.3KB and react-dom is 114.5KB (and of course
you're going to include react-dom, how else would you use it?!)

Uncompressed matters because it takes a device longer to parse more code.
Particularly in a world where low end Android devices are being shipped with
slow CPUs and very little RAM.

The real killer combination is React plus a giant blob of state that has to be
parsed, and then hydrated into individual elements. It's a giant, giant waste
of CPU time that is acceptable on my iPhone XS, but when I plug in a Nokia 2
it's horrifying. VDOM itself is needlessly CPU intense in many ways.

Even if you don't want to use Svelte it baffles me that more people don't use
Preact. 9.5KB uncompressed and it does 95% of what React does. But people just
don't seem to care.

~~~
krainboltgreene
> Uncompressed matters because it takes a device longer to parse more code

This is...a trivial thing to measure, at best. Engineers write way worse code
that will be much bigger targets to care about that will likely never be
worked on.

> Particularly in a world where low end Android devices are being shipped with
> slow CPUs and very little RAM

The benchmarks for this (todomvc for example) aren't egregious, even for
mobile devices.

> The real killer combination is React plus a giant blob of state that has to
> be parsed, and then hydrated into individual elements.

That is a bad end-engineer design choice, you don't have to write react that
way.

> But people just don't seem to care.

Because they largely don't need to: Even if the end-engineer wrote and
designed things in a performant way, it wouldn't account for the slowness of
business process.

~~~
untog
So I guess the answer is "things are going to be bad, so why bother
optimising?". I guess I can't really argue with a self-fulfilling prophecy
like that. Not considering the size of a JS library because the business
process is slow? Oh... kay? Just feels like real lowest common denominator
stuff: why should I do good work when someone else isn't?

FWIW I did Lighthouse audits on React TodoMVC and Svelte TodoMVC In the
performance category React gets 74 while Svelte gets 100.

First contentful paint:

React: 3.8s

Svelte: 0.9s

Time to interactive:

React: 4.8s

Svelte: 0.9s

I can't make you care about this stuff but the numbers are very
straightforward.

------
elliotf
I love svelte on the personal/toy projects I've tried it on, but does someone
have an example of a large-ish svelte codebase with an example of a testing
pattern that they've found works?

Using mithril/vue/react, there are assertions you can make about how a given
action will modify the state, and given some state, how that state will be
rendered.

I've not found a good way to make assertions on the behavior of code without
resorting to poking through the DOM and dealing with asynchronous behaviors.

~~~
bronson
Have you seen this treatise on Svelte testing? (Click the Table of Contents to
switch pages)

[https://dev.to/d_ir/introduction-4cep](https://dev.to/d_ir/introduction-4cep)

~~~
elliotf
I have not! Thank you!

------
config_yml
I love the idea of svelte and want to try it on my next project.

The compiler paradigm is really powerful. What if you could extend Svelte to
give it knowledge of your db schema and it would figure out an optimized way
to load data by generating all that code if needed. Probably something like
this exists already somewhere and was forgotten about, but one can dream.

------
Can_Not
How is it that 23 hours in and nobody is pointing out that svelte/sapper just
freezes on runtime errors without the ability to show an error page or report
them to a tracker like sentry/rollbar/etc.? This is one of the biggest
barriers to being production ready or fit for use in large projects.

~~~
sw19
Wow is that true? My team has been considering moving to Svelte and not having
Sentry integration would be a dealbreaker.

~~~
Can_Not
[https://github.com/sveltejs/svelte/issues/1096](https://github.com/sveltejs/svelte/issues/1096)

------
hinkley
The one thing that gives me reservations about Svelte is that the description
about how code turns into web pages makes me wonder if there are any problems
with code-build-run-test cycles.

I'm concerned I'll spend all of my time restarting my application to validate
changes. Is this a non-issue?

~~~
combatentropy
I followed the tutorial ([https://svelte.dev/blog/the-easiest-way-to-get-
started](https://svelte.dev/blog/the-easiest-way-to-get-started)). It starts a
local server and automatically reloads whenever you save changes.

------
blaydator
The lack of a large and mature ecosystem would prevent me for starting a
"large" web project. Svelte is still missing UI frameworks like Material UI or
Vuetify. Won't you need date range picker ? Full powered data-tables ?
Treeview ? Advanced cards or other layouts ? Awesome effects / styles for a
rich UI ? Svelte Material UI is a start :
[https://sveltematerialui.com/](https://sveltematerialui.com/) But I will
definitely give Svelte a try for my next "medium" size project.

~~~
wirahx
Hey - Svelte Calendar actually has an open PR for a date-range picker which
just needs a bit of testing to get it over the line. Feel free to take a look

[https://github.com/6eDesign/svelte-
calendar](https://github.com/6eDesign/svelte-calendar)

As for the other components, as the ecosystem grows, these things start to
appear. The advantage to Svelte is that it's super-easy to integrate _any_
vanilla component into, much more so than other frameworks. You can totally do
away with nonsense wrapping projects, and just add the component verbatim.

------
abledon
does svelte have a way of hiding the .svelte components from the users on the
frontend? e.g. so they cant blatantly rip the source code in your components
and reuse them

~~~
rich_harris
Sure, it's easy: don't serve sourcemaps.

This isn't specific to Svelte though. In fact your code is much _more_
obfuscated with Svelte than with most comparable tools, since you're not
serving the code you actually wrote, but rather the output of a compiler
(while this is technically true if you're using TypeScript/a
minifier/whatever, it's qualitatively different).

~~~
xrd
This is what makes svelte so incredibly powerful and worthy of consideration.

Not having a run time on the client is huge. But, the developer experience is
exactly the same as you get from React and Vue.

You can trust this guy here, he knows what he is talking about.

------
theslurmmustflo
Use next.js the auto routing and ssr is a game changer, plus easy access to
the huge react community

------
camccar
As a javascript developer, I was getting nervous almost a day had gone by
without another framework.

~~~
vga805
I think this mindset is outdated. Svelte itself is already a few years old.

------
_prototype_
Svelte is absolute trash.

It actively encourages mutability, which is a one way avenue to bugs bugs and
more bugs. ie, shit like this is all over the official documentation:

    
    
      <script>
        let mutable = 1;
        function f1() {
          onMount(() => {
            mutable = /* do some complex shit here */
          });
        }
        function f2() {
          onMount(() => {
            mutable = /* do some complex shit here */
          });
        }
      </script>
    
      <Component onclick={f1}>
        <Component2 onclick={f2}>
        </Component2>
      </Component>
    

Complete non-deterministic state changes. Absolutely abhorrent stuff. Cannot
believe my coworkers and others actually like using this absolute garbage of a
framework.

~~~
Jasper_
What's wrong with mutability?

~~~
pier25
Nothing IMO but a lot of folks argue that using immutable state and functional
paradigm results in more predictable applications.

Not sure if all this immutability talk in the JS community is parroting
because "it's what Facebooks does" or what. Maybe it makes sense once you are
building really big front end projects but personally I've never had an issue
with mutable state in small to medium sized projects (less than 50k LOCs).
Although I admit I've never worked on a Facebook-scale kind of project.

