
Svelte – The magical disappearing UI framework - ergot
https://svelte.technology/
======
matchu
I'm confused by the anti-runtime argument.

The file size problem is about unused code, right? If we tree-shook the
runtime and shipped the minimal version that our app needs, wouldn't that be
even _better_ for most apps than inlining the framework? I'd expect that, the
moment you use a feature even _twice_ , the runtime approach yields a smaller
bundle.

Or is Svelte accepting a file size penalty to avoid the performance overhead
of function calls? If so, it'd be nice to see that tradeoff discussed more
explicitly: in every app, there are probably features worth inlining and
features worth keeping as function calls.

Really, it sounds like Svelte is trying to solve a very general compilers
problem with a very specific sledgehammer solution. Sure, tree-shaking and
thoughtful inlining are difficult to do well, especially in Javascript, so
this makes sense as a first draft for certain use cases. I just wish it were
touted as a first draft, rather than a new beautiful finished paradigm.

~~~
rich_harris
> If we tree-shook the runtime and shipped the minimal version that our app
> needs

I've heard this sentiment a lot. The reality is that UI libraries are
inherently difficult to tree-shake. You can't run a library that can be used
to produce an infinite range of outcomes and expect a tool like Rollup to
whittle it down to just the bits you need (source: I'm the creator of Rollup).

Code _is_ reused. While the compiler will output 'standalone' modules by
default, it can also generate modules that share code between components — the
zero-runtime part is about generating abstraction-free DOM manipulation code
rather than having a complex virtual DOM reconciliation or data-binding
process.

> rather than a new beautiful finished paradigm

Nowhere does it claim to be finished. If anything, it's the _start_ of a new
approach to building UIs.

~~~
matchu
Oh! I think I'm fundamentally misunderstanding the pitch here. Here's my new
guess: Svelte analyzes my component tree to discover the graph of data
dependencies… and then throws out the component tree entirely, instead
outputting code that directly implements my data flow graph.

Is that correct? If so, it's a very cool idea! (I'd been tossing this idea
around for a few months last year, but had trouble designing a non-awful API
xP)

I wish there were a way to make the messaging around this idea clearer. I know
that audiences are different, and this wouldn't work for everyone. But if the
introductory blog post had illustrated the transformation from component tree
to data graph, I would've _immediately_ understood the performance
implications and how this represents a _huge_ paradigm shift in application
compilation.

Instead, though, I thought the pitch was "ew, separate runtime library? let's
inline it and then it'll be smaller", which seemed misguided. I had to
reverse-engineer Svelte's motivation from your comment—and even now I'm still
not _sure_ I got it right. (Maybe this entire comment is wrong? Could be
wrong. No idea :/)

Are y'all planning a blog post about how Svelte works under the hood? That
would go a long way toward clarifying the pitch, I think.

~~~
rich_harris
Sort of, yeah. The previous wave of declarative UI libraries essentially
followed one of two models — there's the 're-render the entire app then apply
a diffing algorithm' approach (React and its many imitators), and there's the
data-binding approach (Knockout, Rivets, Ractive and later Vue) whereby
different nodes in your model/state/data graph (whatever you want to call it)
are linked to the DOM, usually via various levels of indirection.

Both are solid ideas. (As the creator of Ractive I'm biased towards data-
binding, but React's success speaks for itself.) But either way, the library
has to do a lot of work to essentially just translate state changes into
`element.setAttribute('foo', 'whatever')` and so on. Svelte was born out of a
realisation that if you can understand the shape of your component graph at
build time, you can eliminate those runtime abstractions — and with it, both
the bytes and the computational cost associated with them.

> Are y'all planning a blog post about how Svelte works under the hood?

Yes, we have a lot of blog posts we need to write! Hopefully soon.

~~~
the_duke
Please correct me if I'm off base here, but isn't a big part of the whole
virtual-dom abstraction performance?

Direct DOM updates are slow (rerender), diffing and smart patching much
faster. There must be a reason for virtual doms becoming so popular, even for
frameworks that don't have a 'functional' approach like React.

~~~
proyb2
Agreed with Rich, it's a misconception that virtual-dom is faster, web
browsers have made significant improvement to DOM. There must be a reason why
vanilla Javascript is fastest than most virtual-dom.

Inferno-1.1.0 have an error at runtime, could not test JS Framework right now.
Sveltejs works.

~~~
trueadm
What issue did you have with Inferno, would mind reporting it please so we can
fix it? :)

~~~
proyb2
Inferno in JS framework replies use beta, I guess that broken.

------
taspeotis
Previous discussion [1]

    
    
        Svelte – A UI framework that compiles into tiny standalone JavaScript modules (svelte.technology)
        533 points by bpierre 38 days ago | 228 comments
    

[1]
[https://news.ycombinator.com/item?id=13069841](https://news.ycombinator.com/item?id=13069841)

------
jc4p
Looks to have connectivity with gulp, browserify, webpack, system.js, a lot of
stuff. That's rad! I wish it had easier samples to show what the code you
write looks like.

I have a couple questions just off the homepage that I didn't quite really get
answered:

\- Can I use webpack? Can I add this into my current webpack flow?

\- Can I use TypeScript?

\- How does this compare to preact? Note that their homepage has a lot more
info than this one: [https://preactjs.com/](https://preactjs.com/)

~~~
jacobmischka
\- Yes: [https://github.com/sveltejs/svelte-
loader](https://github.com/sveltejs/svelte-loader)

\- Unsure

\- Preact is essentially a lightweight implementation of React. As such, it
requires a runtime, albeit an incredibly small one, to dynamically render HTML
from JSX (Edit: Well, compiled JSX. Essentially hyperscript function calls.).

Svelte components compile _at buildtime_ to pure es5, so you can just run it
directly on the client without a runtime.

There are benefits and drawbacks to each method, but that's the gist of their
main differences.

~~~
jc4p
Sorry if I'm just not getting it. is it compiling some nice language I write
into some JS that runs compile time? Or is this a static website generator?

If I use Svelte to make my site, is the expectation that the data is being
loaded in the cacheable HTTP call or is it a SPA?

~~~
allover
Check the REPL and compare the input to the output:
[https://svelte.technology/repl](https://svelte.technology/repl)

------
ricardobeat
Has anyone done further testing on the growth rate of the compiled code for
larger projects? From the discussion when this launched it seems like the
difference will be mostly felt by smaller apps. That aside, being able to
write 'universal' components that work independently of a framework is still a
great thing to have.

~~~
rich_harris
Since launch we've added the ability to generate code that reuses functions
between components. If you use the CLI it will create 'standalone' modules,
but if you use something like [https://github.com/rollup/rollup-plugin-
svelte](https://github.com/rollup/rollup-plugin-svelte) then code will
automatically be reused.

------
cohort
Been hoping this would get some more traction. Blog post is a good starting
point for those interested... [https://svelte.technology/blog/frameworks-
without-the-framew...](https://svelte.technology/blog/frameworks-without-the-
framework/)

------
fenollp
So the core idea is similar to
[https://github.com/purifycss/purifycss](https://github.com/purifycss/purifycss)
but for JS code.

Then why does Svelte wants to be yet another framework? Do a real good one to
the world and be something that you can plug into Gulp or a Makefile...

~~~
rich_harris
Not really similar at all. It's a compiler, not just a code removal tool.

> Do a real good one to the world and be something that you can plug into Gulp
> or a Makefile...

You can easily use Svelte in Gulp tasks or Makefiles. Maybe do a _tiny_ amount
of research before criticizing something. God the HN crowd is tedious
sometimes

~~~
arxpoetica
Ha!

------
laughingman2
I think with advent of Inferno, 9KB for a view layer runtime, which has
overhead of just 4% above vanilla JS is acceptable for me to compiled view
layer that repeats code everywhere.

------
purity_resigns
Interesting that Rich Harris is also behind rollup and that Svelte appears to
use CommonJS instead of ES modules still.

~~~
rich_harris
It's built out of ES modules (and is bundled by Rollup) but it can compile
components to ESM, AMD, CJS, UMD or a browser global, so it can be made to
work with just about any setup.

------
bastijn
"In Svelte, an application is composed from one or more components. A
component is a reusable self-contained block of code that encapsulates markup,
styles and behaviours that belong together."

So, the idea is to be kind of like Web components? Even after reading the
comments in this thread and the website it is hard for me to grasp where
Svelte's place is. Is it for people who need the performance without giving up
the work flows of the regular frameworks they are so used to? If it is for
encapsulation I would say webcomponents is the better choice here? Although
you could argue Web components isn't ready yet either for the big masses.

~~~
rich_harris
Very much like web components, except a) they work everywhere without
polyfills, and b) they're nicer to build, because they have a friendlier API
and templates are more declarative (with web components you still have to do a
lot of grubby manual DOM manipulation) and you don't have to learn a bunch of
confusing new shadow DOM stuff just to encapsulate styles.

Also, with Svelte you can do server-side rendering, which is a bit of an
oxymoron with web components.

~~~
bastijn
a) is a bit of a weak argument as polyfills are a temporary solution until
browser support is available everywhere. Also, Web components are (indirectly)
part of the W3C spec so browser support will follow.

B) OK. Though subjective.

C) Active support for this is a nice thing to have.

Guess it ain't enough for me to use hut I see its use for others. Still, YAJF
as far as I'm concerned.

~~~
rich_harris
> polyfills are a temporary solution until browser support is available
> everywhere

Well, you might be waiting a while! Web components are actually four separate
specs. While templates are widely supported, the future for custom elements,
shadow DOM and HTML imports is less clear (well it's very clear for HTML
imports — it ain't gonna happen). Edge is 'considering' whether to implement
shadow DOM and custom elements, Firefox says they're 'in development' but from
the outside it looks like that development has stalled.

Even if web components had major advantages that outweighed their
disadvantages, _personally_ I'd be very hesitant to use them until browser
vendors make their intent to support them much clearer.

~~~
bastijn
I agree, hence the last line in my original reply. Web components are not yet
ready for (most) production work. Too be honest I'm happy the only work I do
in the Web area is an SDK. We chose to use vanilla javascript and typescript
over a framework as any framework should be able to pick us up. I worked with
a couple of frameworks the past 2-3 years and didn't like any of them. Of
course Web is relative new and it takes time to mature. For now, I'll take a
pass on this one but keep an eye. They are closest to anything I could use,
but let's see what a little maturity brings it.

------
soperj
It's funny that everyone on here is pretty critical of this. To the maker,
don't pay any attention, your users will give you much better feedback.

~~~
rich_harris
Thanks! Don't worry, this ain't my first rodeo :-D Just glad for the
opportunity to help clear up any misconceptions people have, it's always
useful to get feedback about how we can better communicate the ideas.

------
simplify
How does this compare with Marko.js, which also compiles (and renders!)
JavaScript on the server before sending to the client?

------
kensign
I think [http://aurelia.io](http://aurelia.io) is much cleaner.

~~~
proyb2
Cleaner as in? Aurelia is on the same idea as Angular 1 by the same inventor.

------
gigatexal
How does anyone even begin to start learning how to make Web 2.0 webpages with
a new JS framework every week?

~~~
greyskull
If you can't afford to be on the cutting-edge, you use battle-tested
technologies, and let the people who can afford it do their thing to shake out
which products are worth keeping around. That's sort of the right approach for
any software development, yeah?

~~~
innocentoldguy
Yeah, but most other technologies don't have new libraries and frameworks
coming out every other day. For example, with Ruby, the community has stuck
with Rails and Sinatra for more than a decade now. With Python, most
developers go with Django or Flask. With Elixir, Phoenix or Plug. With
Javascript/Node, however, you have Hapi.js, Sails.js, Mean.js, Koa, Socket.io,
Mojito, Express.js, Meteor, Mithril.js, Derby, and others, not to mention the
front-end options, like Angular, React, Svelte, etc., Some of these frameworks
are even written by the same developers to accomplish largely the same thing
(e.g. Express vs. Koa).

This doesn't seem like a great strategy for long-term success. It got to the
point with me that I didn't want to invest any more time in Javascript
technologies, simply because their lifespans seemed to be quite short,
compared to other options. In the Javascript community, framework feel
disposable. I don't mind learning, but there has to be time for implementation
and mastery, and there has to be some level of long-term career payoff for the
time invested in learning. For example, I can still get any number of Rails
jobs after 11 or 12 years of using the framework. Can the same be said of the
original Express.js? I know it isn't a comprehensive, scientific study, but a
quick search on local job boards in my area turns up 15 Rails jobs, and no
Express.js jobs. No Hapi.js jobs. No Metor jobs. No Mithril.js jobs. No Derby
jobs.

I don't mean to take away from the successes the Javascript community has had
over the years. Javascript is certainly in a better state than it was a decade
ago. However, having so many libraries and frameworks come and go so quickly
isn't a good thing, in my opinion. I think the community could benefit a lot
by embracing more cohesion and focus, but that's just my opinion, based on my
experience with other languages and communities.

~~~
macinjosh
I find it kinda funny because we finally have decent cross browser consistency
on the front-end, which back in the day, was the main frustration point of
front-end dev. Now the problem is finding a framework that you can depend on
and invest in long term. Makes me wonder if the browser wars turned front-end
devs into masochists and now the only way to satisfy that urge for pain is to
reinvent their frameworks on a regular basis. /s

~~~
tracker1
Angular isn't going away, even 1.x will probably see updates for another 3-5
years. React also isn't going anywhere with the heavy hitters behind it...
although there may be some migration to react-alikes that use jsx etc, but the
techniques in the apps are largely the same.

Vue.js is probably here for a while, though a little uncertain, there's
definitely some desire there. I'm not sure about Polymer and web-components, I
think there will definitely be more web-component packages to work from in the
future, but for now, just kind of holding off myself.

I'm pretty actively following the JS world, and tbh in 2012 I felt so in over
my head as npm was growing... It's gotten easier. In general, your best bet is
to stay a little behind the bleeding edge and look at what the heavy hitters
are investing time/money in, and beyond that what you like.

I'm pretty heavy in the React camp (including Preact, Inferno, etc)... Most of
the look-alikes are compatible enough to work, or have a similar enough
workflow. I happen to like the component structure, and am a fan of Redux as
well. Others have hunkered down for Angular2+.

~~~
macinjosh
I totally agree that those things are not going to simply disappear. It just
seems that every new framework supposedly has some distinct advantage that
previous frameworks lack and the urge of most front-end devs is to move on to
the next shiny thing. If you don't move onto the next shiny thing you are
considered to be some sort of luddite or ignorant to the amazing new thing a
new framework has.

So while I can pick a framework like the ones you mentioned and stick with it
convincing team mates or colleagues to do the same becomes difficult.

~~~
ehsanu1
Then the problem seems to be the colleagues rather than the creation of
frameworks. I'm happily following all this framework turnover while totally
ignoring it for actual work.

To be fair, I have had colleagues want to switch to some new framework for
$reasons, but I guess I have enough sway (and we're time-constrained enough)
to not do just that.

------
revelation
Code generation, the frontend craze must have arrived at the Java enterprise
deadends.

Time to mount the JET emitters and blast out that code.

------
aaronfc
Whenever and wherever I read "rock solid" I stop reading... I hate that
expression so much!

~~~
aarpmcgee
Why?

~~~
Nekorosu
Because it expresses the authors confidence but doesn't give anything
informative. Show me metrics, features, idioms and working examples.

~~~
proyb2
Meanwhile, you can download and try the sample code.
[https://github.com/sveltejs](https://github.com/sveltejs)

I spent a few days testing and it was an eye opener, compare to the numbers of
>100 outstanding issues filed in React, Angular, etc which may probably never
fix it for some reason and complexity.

~~~
tracker1
Something tells me, should svelt get to the number of stars that React and
Angular have, you'll see a similar number of issues.

~~~
acemarke
At a minimum, it's a bad comparison metric. It's like with any software
rewrite: the first 80% is the easy part. It's when you get down to the fine
details of handling specific edge cases that things get really complicated.
(Seeing this in a rewrite I've been working on myself.)

Semi-similarly, there's three reasons why React (and other libs) have that
many issues: they've been around for a while, they're very popular, and the
wide variety of usages has led to a number of edge cases being found. Svelte,
being new, hasn't run into any of those things yet. Things like style of
development can also affect things - some communities might file more issues
than others.

------
achikin
Should I feel happy that my js crap compiles into the other js crap?

~~~
Traubenfuchs
You don't get it: Your js crap compiles to other js crap, yes, but this time
your other js crap is BETTER than other peoples js crap who don't use Svelte
because apparently downloading an executing 70 kb vue.min.js gzipped to 26 kb
is just too much for the toasters people allegedly use to execute your TodoMVC
application.

~~~
tracker1
Depends on what you're targeting.. a lot of the media stick interfaces, and
cheap android phones are pretty under powered. Of course, it also depends on
application complexity and types of interaction, animation, etc.

I've found React proper does a pretty decent job of running everywhere I've
needed, though I have used preact for smaller extensions, and bits that are
adding to an existing app, where I want to add new React-style code, to keep
the size down.

------
nkkollaw
Can I say something shallow?

I talked to a couple of programmers about the project, and they laughed at me
because of the name, dismissing the project and not even wanting to hear about
it.

Everyone keeps saying that the name is not important, citing examples like
Yahoo, Google etc., but it _is_.

I was reading about how execs didn't want to replace Android with Cyogenmod,
and I bet part of the reason is the name. It's hard to pronounce, it contains
"mod" in it, and it sounds like a tool for hackers instead of a reputable
operating system that corporate would be ok having on all their phones.

"Svelte" sounds like a name for a dish washer brand.

~~~
rich_harris
'Svelte' means 'slender and elegant', 'urbane', 'attractively thin, graceful,
and stylish', or 'lithe', depending on which dictionary you consult. It comes
from the Italian _svelto_ meaning 'quick'. Those are all excellent
connotations!

But yes, it seems that a lot of people, at least here in the US, aren't
familiar with the word.

It doesn't matter though. I build tools for my job because the existing ones
don't meet my needs, and then I share them because there's no good reason not
to. I couldn't care less whether or not people use them as long as the ideas
get out there. So if someone decides not to use Svelte because they don't like
the name, all I do is shrug.

~~~
nkkollaw
I'm from Italy and so were 2 of my programmer friends. We're used to English,
though. The other guy is from Sweden. I wonder if it sounds better to people
whose first language is English.

It doesn't seem like you care (I guess rightfully), just a note.

