
Svelte Is Unappealing - pcr910303
https://www.ryanprior.com/posts/svelte-is-unappealing/
======
excerionsforte
What I get is "Svelte is Unappealing" because the compiled code doesn't look
like my code. If you minimize JS in general, it doesn't look like your code.
SourceMaps are provided for this purpose.

Unappealing because of the approach taken for compilation is not a good reason
for me not to recommend Svelte. I will recommend Svelte or any library that
helps cut down on the cognitive overload on trying to get your application up
and running and provides a multitude a ways to debug state.

The API surface of Svelte is very tiny allowing you to do what you need to do
without running into limitation. I've never had to complain about Svelte not
exposing something, but sure have for React. API on React has changed multiple
times causing modest rewrites of components. I have found the debugger with
Svelte's @debug marker very helpful during development.

I'm glad I can use components compiled with Svelte in any application without
bringing in a whole runtime and vice versa. It makes sharing natural and much
easier than React, Angular, etc.. I dislike any frameworks (front and backend)
that shut the door on previous work and make you conform to that world.
Countless times I have questioned why do I need to build a component that
implements pre-react work in React in order to use it in a React application.
I should be able to bring in any library that works on the web today and use
it without having it conform to "The Framework". I haven't had this trouble
with Svelte.

I can agree that Svelte is early and there will be offspring that will likely
leap frog and build on the ideas of Svelte.

~~~
jbergens
You can use useRef in React to get a DOM node and pass it to other parts if
needed.

Saying that every framework should be possible to combine with every other
sounds very nice but probably impossible. Unless you restrict what you can do
in a framework a lot. Most frameworks has components that has an api and a
life cycle. Since frameworks have different api's and life cycles they are
hard to combine in one application. Not impossible but hard.

I have a feeling this is somewhat true for Svelte also. How would I how to
update a state inside a Svelte component from the outside?

There is a standard for components, Web Components, but it did not exist when
Angular and React was created. It also works in a different way and don't
solve the exact same use cases.

~~~
excerionsforte
I am aware of useRef.

> Saying that every framework should be possible to combine with every other
> sounds very nice but probably impossible.

I said specifically that I disliked frameworks that want me to conform. I did
not say that all frameworks should conform to me.

> How would I how to update a state inside a Svelte component from the
> outside?

How would you update a Web Component is the same way this works.
[https://dev.to/silvio/how-to-create-a-web-components-in-
svel...](https://dev.to/silvio/how-to-create-a-web-components-in-svelte-2g4j)

------
schappim
I stumbled on Svelte after using both react and vue. I have to say Svelte is a
breath of fresh air and a pleasure to use, especially with a rails 6 app using
webpacker.

I’d recommend you check Svelte out as it will only take 20 minutes for you to
get your head around it. This is a far cry from react.

~~~
fraktl
This was the same thought I had about Vue when I first used it.

I knew vanilla javascript - Vue is vanilla javascript. I knew HTML and CSS -
Vue's component-based approach looks exactly like HTML.

It didn't take more than 20 minutes to get some code running using Vue and it
made me significantly faster.

Then I stumbled upon Svelte and after using it for a day, I asserted it won't
make me much faster and I'd have to learn yet another tool.

That's why I stuck with Vue, and then I discovered Vuetify and Nuxt, awesome
tools that made my life even easier. I really can't draw a parallel between
Svelte and Vue in terms of "better", so I started using my subjective feeling
to justify my decision of going with a tool.

Subjectively speaking, I don't like Svelte. I don't have a solid, objective
reason except this one: I really don't want to abandon 3 years of work I've
put into projects that are based on Vue and TypeScript and go with Svelte
without obvious gains.

There's nothing so different that it'd justify yet another downtime in order
to swap the toolset so I can satisfy my peers online who approve or disapprove
my choice of tooling.

~~~
sireat
Interestingly the more common view is that Vue feels less vanilla Javascripty
than React.

When I am writing React I am writing Javascript (usually a bit obscured with
JSX).

With Vue a large part of functionality is in v-directives.

That doesn't change the fact that Vue is easier to learn for those new to
webdev than React.

Students who just started learning Javascript can usually pick up Vue but I am
yet to see someone with little JS experience pick up React in a hurry.

------
rgoulter
I understand the author's claims to be "Svelte makes it hard to debug the
compiled code, compared to plain-old uncompiled JavaScript" and "the Svelte
runtime architecture makes it harder to observe the system as a whole, so
debugging is harder".

I think the article would benefit from specific examples of where this caused
a problem, and if e.g. whether the claim about "compiled code hard to debug"
applies to Svelte in a way that it doesn't apply to TypeScript, Babel, etc.

~~~
chrismorgan
The likes of TypeScript, Babel and JSX are providing a simple source-to-source
transformation that leaves the structure untouched, broadly just changing the
exact syntax employed. (I exclude any transformation of async code to not use
async/await syntax; that one is a more involved transformation.)

Svelte is not like that. It’s unequivocally a _compiler_ , doing much more
involved transformations. If reactivity becomes involved in your debugging
efforts, it can indeed be harder to pin down than in plain old
JavaScript—depending on how that JavaScript was written, of course.

Compared with the likes of React? I have no real idea, I’ve never used React
seriously. If the issue gets involved with the depths of React or Svelte,
remember that there’s a lot less _of_ Svelte, which may make it easier to
debug. But for some of the sorts of problems that could occur, I would expect
React to be easier to debug, because the bit that’s your code _is_ essentially
just plain JavaScript.

For myself, I choose to use Svelte.

------
PudgePacket
Debugging the svelte compiled code is easy though, it has an order of
magnitude less indirection and layers than equivalent React code. Ever got a
stack trace in a react event handler? 30 stack frames. Svelte handler? 3.

This is one of the reasons Svelte is much faster than React.

~~~
onion2k
_This is one of the reasons Svelte is much faster than React._

Possibly an unpopular opinion here on HN, but if the framework is actually
making a difference to the speed of your app then you've probably made some
horrible mistakes in _your_ part of the code. React apps aren't slow because
of React. Vue apps aren't slow because of Vue. Svelte apps aren't slow because
of Svelte. And so on. Framework developers work hard not to get in the way,
and they do a damn good job. If your app is slow then it's _very_ likely to be
your own fault. There are React apps out there that handle _tens of thousands_
of DOM elements at once at a solid 60fps. React doesn't automatically mean
slow at scale. Likewise I could write a Svelte app that's struggles along at
5fps. Svelte doesn't automatically mean fast.

There are edge cases where an app is really pushing what the browser can do,
and that's where the choice of framework really makes a difference. In those
cases which framework is the right choice depends on the app - it's not simply
a case that X is always better than Y. If you're updating tons of DOM elements
then Svelte is a good choice. If you have lots of DOM elements but you're only
updating a few then React (or any virtual DOM based framework) probably works
better. But if your app is a glorified To Do list as so many really are,
there's no excuse for it to be slow in _any_ framework.

~~~
PudgePacket
Broadly I agree with you, though my personal opinion is that Svelte is also
more pleasant to use, so it really only loses out to React in ecosystem. I've
also used React for years and have used it much more than Svelte, so I may be
biased from seeing all the warts of React.

Being small & fast enables real business use-cases that just weren't possible
before, eg
[https://artemdemo.com/static/2f8acbe19c0ba4ec4d98e06e6b8fd85...](https://artemdemo.com/static/2f8acbe19c0ba4ec4d98e06e6b8fd85b/2fc68/svelte-
pos-twitter.jpg).

Billions of people around the world are coming online in recent years, and
they're using budget $100, underpowered android phones. Every little
difference in performance is magnified for them.

------
beaker52
Not sure why the author points out that Svelte isn't JS/HTML/CSS then goes on
to recommend Preact over React. Preact isn't React either. If using Preact
were caveat-free, React would be redundant.

~~~
ratww
> goes on to recommend Preact over React

The author isn't recommending Preact over React. He's recommending Preact over
Svelte.

If one is already looking at Svelte because it's small (and a lot of people
are), then Preact makes a lot of sense.

React is fine if size is not a constraint, of course.

------
pcr910303
I'm not the writer of the post, but what I understand is that Svelte is a
super-leaky abstraction mostly because the compiler's output is unpredictable.

JSX (that most React-esque libraries use) is basically a syntactic sugar for
function calls with objects - so the output is fully predictable.

One of Svelte's selling points was that it abstracts complex state management
by compiling JS down into DOM API calls - but that abstraction is leaky and
it's hard to debug why something's not working when it's expected to be.

~~~
rimliu
How do you think the final step of DOM updates are done in any other libraries
if not via DOM API calls?

~~~
pcr910303
Well, React diffs the VDOM and decides what elements to update on runtime;
Svelte decides the elements to update on compile time. That's the difference
(and the meaning of 'compiling JS down into DOM API calls').

~~~
bufferoverflow
That's not true. I've been fighting with React rerendering every element of a
long list when I change one element and update the context state. For some
reason React rerenders everything, even when the keys are set and the
references are the same.

The only recommendation I got is to use React.memo, which still rerenders
every element, but from some internal cache.

~~~
jbergens
I don't use context so I don't know if this is true or not. It might think it
has to re-render since the context could affect anything below a component. It
should however use the virtual DOM to diff first and not update the actual DOM
more than needed.

For class components in react you also have a special method
shouldComponentUpdate that you can write to optimize things. But I feel we are
into performance details now, it doesn't make the code hard to understand. You
updated a value in the context and some component re-renderd, hopefully with
the correct output.

------
steerablesafe
I'm a C++ developer, not a frontend developer. I can debug C++ executables,
because of debug symbols and gdb. I generally don't need to know any assembly
for debugging.

If Svelte is compiles down to JS where the connection between the compiled
down code and the source code is unclear then maybe they need similar tooling
to address this.

~~~
GonzaloQuero
I've been testing Svelte for a project, and it seems to generate good source
maps. In the Firefox Dev Tools, you can just breakpoint on .Svelte files with
no issues.

------
ijpsud
Would be great to see some code examples which exemplify the problems that the
author is talking about, and compares it to alternative frameworks. Currently
it's only about half a blog post.

------
kitd
The author seems to start from the premise that the purpose of the Svelte
compiler is to generate code for him to look at and fiddle with. Surely that
is where he's going wrong? If it's merely a question of debugging, source maps
are the answer, no?

~~~
wirahx
I feel like the author would benefit from writing some tests or isolating his
code better. It doesn't feel like a language or framework problem.

------
joekrill
I sort of agree - for now, at least. The tooling around React for debugging is
pretty great. React Dev Tools lets you easily debug your component tree. And
the underlying source is pretty much what you wrote (JSX doesn't really get in
the way here).

I've been working with some older Angular (1.5) code recently and it's been an
absolute nightmare because the debugging experience is just awful. Error
messages are unusable at times. Failures simply get swallowed. It's difficult
to debug bindings. But with React, I don't have to deal with any of this
(though much is because of the simpler API).

You see a similar thing with Redux. It's very straight-forward to debug, and
there are similar dev tools. Even Apollo has dev tools for their GraphQL
library. And I think this is what sets these things apart and makes them so
much more popular than similar libraries - the debugging experience. And while
I haven't used Svelte for a project, I'm getting the sense that the debugging
experience is going to be painful. It may be great _most of the time_. But I
don't think that's going to be enough in the long run. Just my opinion.

~~~
Blaiz0r
Isn't it a little crazy that we have to have bespoke dev tools for frameworks
and APIs?

Has any other language needed this kind stack to support it?

------
anotherevan
This reminds me that I've got to draft an email on why we should change our
three quarters complete project from using Vue to using Svelte (even if it is
not Typescript friendly yet).

Not that I'm actually intending to do that. I'm just going to send it to our
front-end developer on April 1st and watch him freak out.

------
wirahx
So your overarching point is that compiled languages are unappealing.
Obviously, this isn't correct.

If a fresh user were to spend a few minutes learning React (or Preact),
Svelte, Vue, or Angular, they'd almost definitely pick the terse and simple
API of Svelte, or Vue, over the others. I've in fact tested this with a number
of Junior and Senior developers.

Every language has downsides and upsides, some people find interpreted
languages easier to hack around with than compiled ones, but the sheer speed
of Svelte's complilation (especially when you try out the new HMR stuff)
really excludes Svelte from this anyway.

Your other point is about every component having it's own runtime. This also
isn't correct. Have a look at the code outputted from the REPL to see the
"runtime" (which is just a set of shared functions in pure javascript) being
declared. These are global to your entire Svelte app. It's as close as Svelte
gets to a runtime, and it's shared.

As for changing data somewhere and looking how it all renders differently,
that's what the Store is for. It's a cross-component store of data, and if you
change it, dependends will render differently.

It's not that there's no merit to your article, it's just that a lot of it
applies to most development languages, and it would be silly to call them all
unappealing. Upsides and downsides, that's all. And my personal feeling about
interpreted frameworks like React or Preact is that they offload the downsides
to the user, which is unnacceptable.

~~~
arxpoetica
Sorry tangent, but been working w/ Svelte a long time. Can you tell me about
this:

> especially when you try out the new HMR stuff

I tried setting up HMR w/ Sapper but couldn't figure it out. Using Rollup. Are
you referring to WebPack? Happy to take offline. Ping me on Discord if you
want: @arxpoetica

------
robocat
> Svelte code looks like JavaScript, CSS, and HTML, but its compilation stage
> takes that and munges it totally out of recognition into a tangle of
> reactive JS code.

Isn’t that fairly similar to React? I tried to understand some React on a
page, and there is no way the JavaScript events or HTML updeates have any
obvious connection to the code causing it.

~~~
namelosw
In React, they're basically all JavaScript. Even for JSX people can imagine
themselves as compilers, and can easily write down the JavaScript output by
hand - it's totally predictable. It's really a super thin layer of DSL with
nothing interesting at all.

In Svelte, people cannot do that for a fairly small application with only
hundreds lines of code.

~~~
bryanrasmussen
I would say I could theoretically write down the JS output by hand, but not
easily - for any application likely to need debugging. Also in most cases
you've got WebPack there, and I'm not sure if I can really write down that
output by hand.

------
gregors
Highly recommend this talk
[https://www.youtube.com/watch?v=AdNJ3fydeao](https://www.youtube.com/watch?v=AdNJ3fydeao)

Rich Harris is an excellent speaker and it's worth seeing how Svelte
approaches some things

------
arxpoetica
Ryan's arguments are actually what so many of us love about Svelte. To each
one's own.

------
pictur
preact is a pretty bad framework. It's pretty funny to recommend it instead of
svelte.

~~~
jamwaffles
I’ve been looking to switch to it. What’s bad about it?

~~~
ratww
Preact is great _by itself_ , and works _very well_. All the advantages are
true, it's fast and about 10x smaller than React [1]. It's GREAT for super-
small interactive apps that need to be fast.

But if you try to use it as a drop-in replacement for React [2] and use a lot
of third-party React components, Redux, React Router, then you might run into
incompatibilities. React is very large and some components rely on obscure
behavior, sometimes bugs. You'll have to do some deep diving and opening PRs
in third-party repos, and a lot of those people will even deny those PRs.

But honestly: if you're gonna use third-party stuff, Redux, React Router, all
that... is the ~38kb it saves really all that much?

If you're doing startup-style development where number of dependencies don't
matter, go with React. If you're aiming for an app with only 30kb or 50kb of
gzipped Javascript, maybe try Preact.

I'd it's actually more of a competitor to Svelte or to VanillaJS, not to
React.

\--

[1] 3750 vs 42623 gzipped for the UMD, last I checked. Used the UMD production
dist of both of them. Used React+React-DOM concatenated for measuring React.

[2] Sure, maybe they should drop the compatibility line from their "sales"
pitch. It mostly works fine, but it's a hard position for them to be in.

