
Svelte is the most beautiful web framework I've seen - bhalp1
https://www.thefutureoftheweb.com/blog/svelte-is-the-most-beautiful-framework-ive-ever-seen
======
beardedman
Let the "soap box brigade" commence!

I got introduced to Rich Harris via a podcast (not personally), but am a big
fan of his perspective on JS. I think we can all agree that; if you don't like
Svelte, then fine. If you love JSX/TSX - then great! If you're a Vue person,
then awesome - its exactly what makes this community great - the diversity &
innovation. Not the soap-boxing antics, polarised opinions & vilification of
opinions that aren't congruent with your own.

As someone much wiser than me once said - "always bet on Javascript".

~~~
cmroanirgo
> *"always bet on Javascript"

I've been keeping all the modern javascript frameworks at arms distance,
because I've always preferred to bet on HTML, for the client at least. That
said, I've no issues with heavy reliance on JS on the developer machine, but I
always prefer pages that can work without the reliance on JS.

So, it seems opportune to ask: Is there a JS framework around that actually
compiles to HTML and CSS rather than embedding the HTML in JS/DOM calls? In my
rudimentary analysis of React/Vue and others (eg svelte), I can't find out how
to have the end result without the framework sitting in there too. Perhaps I
keep missing something in my understanding?

~~~
beardedman
So this is what Svelte does, the app gets built at build time so you don't
need the include any script in the browser for it to run. I remember RH
talking about the React Hooks inspiration thing, so whether the API will go
more in that direction (and eventually be a runtime thing), I'm not too sure.

~~~
rahimnathwani
GP wants something that compiles down to HTML and CSS.

Svelte compiles down to JS.

------
caiocaiocaio
I like playing with different web frameworks, but the article had a bad
hype:information ratio, so I googled the Svelte homepage, which I think is
really well presented: [https://svelte.dev/](https://svelte.dev/)

~~~
notus
I get a 404

~~~
rich_harris
The site is hosted on Google Cloud Run, which seems to have been having some
intermittent problems for the last couple of days. _EDIT: some other people
have had the same issue and the Cloud Run team are investigating_

~~~
ernsheong
Looks like this issue:
[https://issuetracker.google.com/issues/136539678](https://issuetracker.google.com/issues/136539678)

~~~
rich_harris
Yep — I added our details to it. I mentioned the problems we were having on
Twitter and a Cloud Run PM came to help immediately! So I'm hopeful we'll get
a resolution before long. (Aside from this glitch, Cloud Run has been great
for us, and we're looking forward to it coming out of beta)

------
CharlesW
I watched Rich Harris's "Rethinking reactivity" presentation
([https://www.youtube.com/watch?v=AdNJ3fydeao](https://www.youtube.com/watch?v=AdNJ3fydeao))
and was incredibly impressed.

Has anyone with React/Vue experience used Svelte for a significant project?
I'd love to hear about your experience with it.

~~~
wirahx
Yeah - I wrote [https://www.beyonk.com](https://www.beyonk.com) in Nuxt first,
and I've now rewritten it in Svelte (Sapper).

There are some things which weren't ready when I started, but I worked around
them. The overall experience is that Svelte results in faster pages, less
code, more predictability, faster builds... overall, it's a better experience.

~~~
vimota
Other than performance, was the developer experience any different? Just
curious!

------
tthisk
The idea behind svelte is neat, i wonder though what the impact of its
approach will be on a developers ability to understand what is happening under
the hood. In my experience opaque abstraction layers can really hamper your
ability to properly understand what is going on. Traditionally the JS
ecosystem has been a frontrunner in this area (e.g. sourcemaps). But I have
had terrible experiences in the Java ecosystem, with all its aspect weaving
and annotation magic.

~~~
mfatica
I think svelte compiling to native javascript is lightyears more
understandable than whatever the hell react is doing

~~~
s_y_n_t_a_x
I think it's the reverse. If you write pure functional components, React is
very understandable. It's easily testable, you know that you'll have the same
output if you pass it the same props. Svelte templates just take us back where
we've been, with the twist of compiling the templates, which I believe some
templating libraries already did.

~~~
mfatica
React conceptually is very understandable, but understanding what it's
actually doing under the hood is not.

~~~
s_y_n_t_a_x
You can dive down and learn the inner workings, the same as you can dive down
and learn how the svelte compiler works, but it's not needed for either one.
Understanding the concept is more important.

------
fasterdom
I have a table of 100 rows x 10 columns mostly of numbers which change 10
times a second (think trading).

The source data sits in an array of objects.

On each update, I need to update the table cells with the latest values from
the source array. The content of each cell can change, possibly it's css class
too (from red it become blue for example).

I'm using Vue/Bootstrap-Vue table at the moment, but it's quite slow.

Is Svelte suitable for this? Other options to quickly update a <table> from
data in an array of objects, one object per row?

~~~
deaddodo
No matter which framework you describe, this is an iterative approach and will
be inefficient. The optimized (or, at least faster) way to handle this would
be to have a unique ID attached to a cell and offer a direct callback to it
via the data.

E.g. the symbol for "GOOG" stored in a hash table, when GOOG updates; call
that hash directly: "symbols[symbol].update(data)" then re-render the cell DOM
element.

~~~
tylerhou
If you update all the data why is this more efficient?

~~~
allannienhuis
contents _can_ change, not _will_ change. So this approach should update fewer
cells per update cycle.

~~~
tylerhou
For a realtime view of stock symbols, it's highly likely they _will_ change.
And a hashmap lookup is not free.

You really have to profile the code to figure out what's expensive. Maybe
there is no scaling wrt. the number of nodes that change because
repainting/relayouting is more expensive than updating the DOM.

~~~
username90
> And a hashmap lookup is not free.

They are basically free when you have this little data. 1k cells updates 10
times a second means that you have around 100 micro seconds per cell, you can
do thousands of lookups in that time. The only things which could even come
close to costing 100 micro seconds are if you accidentally re-flow the html
each cell update, re-render the html each cell update, send a http request
each cell update or if you go through all the data each cell or the framework
you are using is extremely inefficient or other unnecessary work. Each of
those are easily fixable by doing the html and javascript by hand instead of
using frameworks.

------
langitbiru
So I just read about "Choosing Boring Technology" before coming into this
thread. I guess React.js is the boring technology (already 5-6 years) one and
Svelte is the new and exiting one! :)

~~~
Rotareti
I went through the svelte examples and I was exited until I reached the _If
block_ example:

    
    
        {#if user.loggedIn}
          <button on:click={toggle}>
            Log out
          </button>
        {/if}
    

To me such template language is a huge step back from JSX. JSX is JavaScript,
thus you get the full power of the language (JS/TS) with the full support from
your editor (type checking, auto-completion, etc.).

~~~
dmitriid
I hate template languages myself. But in Svelte’s defence, their template
language in version 3 seems to be well-designed and streamlined.

It doesn’t have the ad-hoc nature of “oh crap we forgot to add if-then-else”
of Angular or “let’s create half-a-dozen incompatible javascript-like DSLs” of
Vue.

------
s_y_n_t_a_x
My main gripes are no TypeScript support and going to mustache-like templates
after working with JSX/TSX is a step back for me.

Also losing React Native, which is non-issue if you're just developing a web
app.

~~~
yodon
Agreed, JSX/TSX feels so incredibly natural it's hard to imagine giving it up,
and starting a significant JS project in 2019 or 2020 without using TypeScript
would feel professionally negligent to me.

~~~
_0o6v
Using JS ternaries for conditional rendering doesn't feel natural to me at all

~~~
ng12
Using {#if} or v-if or whatever feels even less natural -- especially when
these template languages are hyped as being "logicless".

~~~
core-questions
I don't see why anyone would want a "logicless" templating language. Doesn't
that sort of kill the point of it being a "language" to begin with?

/me goes back to happily "server side rendering" HTML with PHP

------
knubie
There was a really interesting discussion recently in r/Clojure about Svelte,
and how its ideas relate to and can be translated to Clojurescript.

[https://www.reddit.com/r/Clojure/comments/bqh0z4/virtual_dom...](https://www.reddit.com/r/Clojure/comments/bqh0z4/virtual_dom_is_pure_overhead/)

------
pkstn
Also try RE:DOM, very close to Svelte but RE:DOM does not need a compiler and
is faster than Svelte:

[https://redom.js.org](https://redom.js.org)

[https://rawgit.com/krausest/js-framework-
benchmark/master/we...](https://rawgit.com/krausest/js-framework-
benchmark/master/webdriver-ts-results/table.html)

------
hamilton
As someone who has built a number of data products w/ React, I decided to give
Svelte a try a few months ago. At this point I am using it on some internal
projects to great success & ease and probably wouldn't go back to React for
newer projects unless there was a compelling reason to (eg collaboration w/
other React devs). As a disclaimer, I admire the React community + devs and
think React has made a lot of hard things much, much easier.

A few unvarnished takeaways from a data science / viz point of view that I was
thinking of writing up, but will use HN as a sketchpad:

1\. I don't really miss the React 3rd party ecosystem as much as I thought I
would. Since most of what I do is data viz / data presentations, I really just
need a few d3 helper functions, and most other things I can build myself w/
svelte's affordances. The biggest downside, however, is that there aren't any
good accessible UX component libraries for Svelte, so I have built my own.
This all said, I'm productively code-homesteading and I love it. Animating
component lifecycles, component style scoping, and state management are 1st-
class citizens, so these pieces are pretty high-quality, usable, and
thoughtfully built.

2\. my "time to first meaningful render" metric was at an all-time low with
Svelte. Getting started on a new idea or project is far, far easier than w/
any React project I've ever done. Substantially less boilerplate means I can
get much, much more done in the same amount of time. I feel this every time I
jump back into the React projects I work on & maintain.

3\. as my apps have grown in complexity, I've found that Svelte really holds
up beautifully. The style/layout/behavior colocation strategy keeps the
cognitive overhead of working on all the parts of multiple components to a
minimum. The performance gains of Svelte, even with complex components and
interactions, feels magical. Bundle sizes are bizarrely small.

4\. as someone who feels CSS will absolutely outlive all of these frameworks,
I think the design of Svelte really feels like the best of both worlds. And
that's how it should be – css + markup should be first-class citizens.

5\. the testing story isn't fully there yet, so I would say to that end,
proceed with caution. I typically try to compartmentalize JS logic from
presentation as much as possible, but perhaps you don't.

6\. the reactivity parts shine everywhere and are fairly easy to reason about
in all cases, but they REALLY shine when you're building complex
visualizations.

7\. this is an important one to me – building something in Svelte really
tickles the same part of the pleasure centers of the brain that JQuery did for
a previous generation (and d3 did for early data scientists). You just SEE the
thing work, effortlessly, at a low cognitive cost, and everything fits
together so nicely. I often start svelte-powered experiments and end with a
great, reusable component. I think there is a large group of engineers who
remember the JQuery days and sat out the React era because it just seemed like
way too much to do simple things. I think Svelte is especially for them.

In sum, really highly recommended to at least try it. I wanted to find
evidence to discount Svelte, but haven't found any at this point, despite my
best efforts. There is probably a certain class of dev that should be trying
it – one without a ton of organizational constraints, probably. But if you do
data science and want to level up your data presentation skills, you should be
using Svelte imo.

~~~
ajflores1604
I've been considering svelte for exactly this d3 datavis use case. Are any of
your projects publicly available to explore and get a feel for? I'm new to
front end and so far have been disappointed with the speed of plotly and dash,
which as I understand it are written around react. I'd love to see an example
of svelte performance in a more datavis use case.

~~~
hamilton
Unfortunately not – they're all private, internal views at the moment. I do
hope to clean up some of my components and write something about some of the
cool workflow aspects I've been able to unlock.

In the meantime, I would recommend walking through the tutorials & examples.
They're very well written and I go back to them regularly to try out different
parts. Try just making a simple line chart! Now make six on one page! Now try
to link the rollovers for all of them! You'll probably learn a ton doing just
that.

~~~
keithnz
as an aside, Rich made svelte, according to a podcast I was listening to,
because he does dataviz for, currently the Times ( previously the Guardian ).
So it should work well for that use case.

------
anderspitman
Svelte looks really cool. Has anyone compared it in-depth to imba[0]?

[0] [http://imba.io/](http://imba.io/)

~~~
onemoresoop
I really like the demo video, you can select the code, scroll up and down, see
different files. This is really neat!

~~~
anderspitman
Oh cool I didn't realize it was interactive. I'm pretty sure this is their
scrimba platform[0], which is what they built imba for in the first place.

[0] [https://scrimba.com/](https://scrimba.com/)

~~~
theturtletalks
I also read that Imba can be used with other frameworks like React and Vue.
That’s why Scrimba has courses on those where you can edit code while
learning.

Imba can also be used to make desktop applications it seems. The team behind
it also released GitSpeak, a Github client that works really well.

------
prashnts
It does look great. I’m concerned though, few years ago I used to use rivets
[1] for two-way data binding in html. It worked very well. Unfortunately, it’s
abandoned. Same fate as coffeescript, backbonejs, etc.

Now I primarily use react. Vue looks great, but I don’t want to introduce yet
another framework.

I could use some insights/view points from hn. I don’t feel using/learning the
now-abandoned frameworks is useless though — the things I built are still
working. But good luck to anyone who’d want to maintain that codebase
(unlikely in my case).

[1]: [http://rivetsjs.com/](http://rivetsjs.com/)

~~~
pier25
Someone forked Rivets and made TinyBind which seems to be maintained and has
new features such as WC support.

[https://github.com/blikblum/tinybind](https://github.com/blikblum/tinybind)

I haven't used it though.

------
benatkin
Interesting that the custom element appears to just take a single JavaScript
object as a parameter:

    
    
      <Board {game} />
    

In JSX this would be either:

    
    
      <Board game={game} />
    

or:

    
    
      <Board {...{game}} />
    

This is almost as ergonomic as JSX except for attributes like checked where
the value is omitted. It might encourage some refactoring, compared with
React, because the thought of putting attributes in a variable and adding them
as a spread might occur more often when seeing an object being passed in.

At any rate, I recommend looking at the code example linked in the post, or
watching the video. Otherwise the post is pretty low in information, as the
top comment at the time of writing this suggested.
[https://github.com/jesseskinner/svelte-tic-tac-
toe](https://github.com/jesseskinner/svelte-tic-tac-toe)

~~~
ScottFree
Am I the only one who would rather write the following instead of JSX?

    
    
        Board.draw(game)
    

or

    
    
        drawBoard(game)

~~~
mixedCase
Well you might like Hyperscript or Elm, those are two approaches that work
quite well using simple function calls.

The thing with JSX is introduces a syntax that is familiar to the rendered
output (which is the status quo), and there's a relatively clear visual
separation between the declarative and imperative parts; which is hard to
enforce in pure JS.

~~~
ScottFree
The problem with JSX (and it's the same problem with all declarative
languages) is you have no control over the control flow.

~~~
mixedCase
That's because JSX doesn't concern itself with control flow; it's not its job.
Your framework has that job.

~~~
ScottFree
No, that's my job.

------
mvolkmann
If you want to get up to speed on Svelte quickly, read this!
[https://objectcomputing.com/resources/publications/sett/july...](https://objectcomputing.com/resources/publications/sett/july-2019-web-
dev-simplified-with-svelte)

------
Layvier
How would it scale for a bigger app ? Shipping a library with the app like
react creates poor performance for small components for sure, but abstractions
must become worth it beyond a certain scale no ? I guess the compiler could
also create abstractions when it becomes worth using them ?

~~~
arve0
Rich Harris addresses scale in the Changelog podcast, and claims it to scale
better than regular frameworks.

[https://changelog.com/news/a-ui-framework-without-the-
framew...](https://changelog.com/news/a-ui-framework-without-the-
framework-0PzO)

------
atrilumen
Man, I keep thinking "just keep on chugging with Choo", but I'm really tempted
by Svelte.

( [https://choo.io](https://choo.io) )

------
AliAdams
If you are getting a 404 trying to view the main Svelte site
([https://svelte.dev/](https://svelte.dev/)), there seems to be an
intermittent issue with Google Cloud Run.

You can view the site directly at the uglier url: [https://svelte-website-
mrf26sti4q-uc.a.run.app/](https://svelte-website-mrf26sti4q-uc.a.run.app/)

------
larvaetron
It's kind of funny that the styling example is literally just plain-old CSS
and HTML, not sure if that was intentional?

------
marcus_holmes
I get a 500 error on the second page of the "getting started", so... nope, not
the most beautiful I've seen.

~~~
rich_harris
Yep, having some problems this week with Google Cloud Run (which hosts the
site). I guess that's what happens when you use a platform that's still in
beta...

------
zaiste
Svelte is strikingly similar to Marko.js [1] which predates it by few good
years I believe.

Sadly the latter is still under the radar despite bringing in many interesting
innovations to the space: its server-side approach being one of my favorite
features.

[1]: [https://markojs.com/](https://markojs.com/)

------
jbverschoor
This is not a web-framework. It is an frontend app framework for
html/javascript

~~~
http-teapot
This is not a car. It is an electricity-powered four-wheel vehicle. So yeah,
it's a car.

This is not a PC. It is a Mac. So yeah, it's a personal computer.

A framework that powers the web, isn't it a web framework? It's just a very
broad category that also includes backend framework.

~~~
jbverschoor
Nah, it does not power the web in any way. It is a html/java script
application framework.

Nginx powers the web. Chrome powers the web. Rails powers the web.

------
bin0
Svelte is so great... so were react, angular, ember, meteor, and vue. I'm
sorry, but I've got trouble seeing how having one more framework to learn is
going to help any thing.

There's a webcomic of some sort to which I can't find the link, which talks
about this. Some one is sick of the bloat of x framework/tool/whatever, and
decides to build it better. He works hard, and finally version 1.0 is released
to dramatic music. But there's a problem - it hits the real world and starts
running into edge cases, bugs, and other things that can't be predicted in
design and testing, necessarily. Features creep, and over time, it becomes
just as bad as that which it sought to replace. Then, some bright young soul
gets the idea that he can do it better...

This is not to discourage innovation. It doesn't appear it's been battle-
tested like other frameworks, and I don't see many major operations on the
list of users. If it ends up better, great, but I can't say I'm optimistic.

~~~
manigandham
It's just more options. Svelte is new in that it actually compiles the
components and logic into plain low-level JS code instead of having a
"runtime".

It's something most of these frameworks should have already done by now
considering they need build steps but maybe it needed a new project to make it
happen. It's a brand new release though so it'll take more time for uptake,
and by people who think the opposite of what you typed.

~~~
bin0
You're right that it's more options, but it's also one more box a "competent
JS dev" is expected to tick. One of the best and worst things about the JS
ecosystem is the plethora of choices available.

On compilation, nope. Riot.js did it first, and this is literally the entire
premise of typescript (I know typescript is a different language, but I see
little difference here as it can mix with JS between writing only some stuff
in TS).

You're right, they probably should have done it, and I'm excited to see it.
But I also don't see why they couldn't have submitted a PR to
react/angular/ember/meteor/vue.

~~~
rich_harris
> But I also don't see why they couldn't have submitted a PR to
> react/angular/ember/meteor/vue.

I see this sentiment a lot in open source. When I made Rollup — which is now
used to build the most popular libraries in the JavaScript ecosystem,
including some you just mentioned! — people asked why I didn't just submit a
PR to webpack?

I understand why people ask that. But it just doesn't work like that. Very
often, to take a step forward, you can't simply make incremental changes to an
existing project — you need to create new foundations altogether. When Svelte
1 came out in 2016 I was already responsible for a different framework
(Ractive), and it wasn't possible to make the changes I wanted there. If you
can't do what you need to do by making a PR to _your own project_ , then
imagining that you can do it in a PR to someone else's is a fantasy.

And it's not simply about adding some extra compiler smarts to existing
frameworks. The whole point of Svelte 3 is to rethink the developer
experience. It has radical opinions about _how we should be building apps_ ,
which I've written about in [https://svelte.dev/blog/svelte-3-rethinking-
reactivity](https://svelte.dev/blog/svelte-3-rethinking-reactivity) and
[https://svelte.dev/blog/write-less-code](https://svelte.dev/blog/write-less-
code).

~~~
CharlesW
It's a shame that the site's down. Until then, you can (and I heartily
recommend doing so) watch the "Rethinking reactivity" video here:
[https://www.youtube.com/watch?v=AdNJ3fydeao](https://www.youtube.com/watch?v=AdNJ3fydeao)

~~~
mgomez
You do realize that you replied to the very same person that's presenting in
that video, right? :)

