
Web Development Simplified with Svelte - gavreh
https://objectcomputing.com/resources/publications/sett/july-2019-web-dev-simplified-with-svelte
======
vfc1
I just prefer batteries-included and fewer decisions. Angular already compiles
components at build-time using the Angular CLI, and the new upcoming
(November) Ivy engine is going to produce bundles that will rival in size with
any framework.

The webpack build that the Angular CLI uses internally is completely
transparent, you don't have to know Webpack at all. Just do ng build --prod
and you have your optimized bundles will all the bell and whistles.

Webpack is even going to be replaced by Bazel but we won't even notice it, all
we have to do is ng update and live goes on the next day after the release.

The Angular ecosystem with the Angular CLI is just so stable and complete,
with hardly any API changes in years, it's just a joy to work with. The CLI
even integrates with Sass and other CSS processors.

You can really focus on the application, and forget tooling. I think the take
of Angular on batteries-included tooling & their take on incremental upgrades
are such a huge advantage over other ecosystems, AFIK nothing else comes even
close.

~~~
izelnakri
There is something close, even better, when overall API design/architecture is
considered, that is ember.js. Check ember-cli/embroider which angular-cli
initially forked from. I give it 1.5 years for ember to pretty much dominate
SPA development, In the last two years some people were laughing at me, now Im
laughing at them.

~~~
howdydoo
Our company trialed Ember this year alongside React, Angular, and Vue for a
new SPA. Ember was the worst of the bunch:

\- It is stringly typed. All over the place you're globally registering names
as strings (or worse, using strings that implicitly resolve to filenames).
You'll write `store.createRecord('mymodel')` instead of just importing things
using standard ECMAScript imports.[1] This means static analysis is out the
window, which makes it labor-intensive to find usages or do even simple
refactors like renames.

\- It leans on global state and object mutation way too much, instead of using
functional state updating. This was the way older frameworks like Backbone,
YUI, etc worked. Web development is moving away from this paradigm, and for
good reason.

\- Static typing support is non-negotiable in 2019 (and 2015 for that matter,
but I digress). Support in Ember is just not there, and I don't see much
promise for the future either. React and Angular have had good support for
Typescript and/or Flow for a good 5 years now.

\- One high point for Ember: the in-browser testing beat the pants off any of
the other frameworks. We ended up going with React/Jest/Puppeteer, but this
meant we (meaning, I) had to write 150 lines of boilerplate that Ember gives
you for free.

Overall working in Ember honestly felt like being transported back in time by
10 years. I guess if you're a solo dev it's easy to whip up a quick demo that
seems fine, but you'll hit the wall very quickly where the project becomes
write-only. I think it's unlikely a brand new build system, no matter how
fancy, can make up for these architectural problems.

[1]: [https://guides.emberjs.com/release/getting-
started/creating-...](https://guides.emberjs.com/release/getting-
started/creating-a-new-model/)

EDIT: I regret taking the time to write this. Should have checked submission
history first…

~~~
cies
> It is stringly typed.

This is a big issue.

> \- It leans on global state and object mutation

I dont see this as a problem, it's an implementation details. If the software
works well (fast enough) and provides a nice API, I dont care much about the
internals.

> \- Static typing support is non-negotiable in 2019

Agreed, but I'd like to combine this point with the first.

EDIT: thanks for typing your reply. :)

~~~
izelnakri
There are 3 places where one can say ember is stringly typed:

1- controller/service dependency injection(no more with octane).

2- ember data API(store.createRecord(modelNameString) and
serializerFor(modelNameString)). I don't mind it results in less imports and
API might change in the future.

3- this.owner.lookup('$abstractionName:$fileName') => I like this one. It
removes the need for an extra line of import code and import path could have
been very verbose for something far away in dependency tree.

Therefore, I don't think it is a serious issue anymore.

Majority of the ember source code and internal packages are in typescript and
there is a good typescript support for app development via addons. As a person
who wrote an ember-cli alternative, I can say with confidence that you can
build ember apps in typescript. Despite all that, the type analysis
performance overhead/cost of typescript compiler today isn't worth the type
benefits for really big SPAs yet in my opinion. I think instead those frontend
teams should optimize their hiring and mentoring practices until we have a
very fast typescript compiler.

Addon/package authors can write their code in typescript and make it work with
JS or TS ember application code today.

TLDR for the ones who made weak typescript arguments here against ember.js:
Don't be a hypester and claim certain things without making a good research.

~~~
cies
Thanks for this breakdown, very helpful.

------
onion2k
The fact you can easily make yet another To Do list app isn't very useful. If
you can't easily make a very simple app then something is _seriously_ wrong
with the framework.

A much more useful question is whether or not a framework makes it easier (or
faster, or better, or something) to write a complex app. In the case of
Svelte, all the hard stuff (eg state management, sync'ing data from APIs, etc)
is outside of the scope framework. That make Svelte much smaller and simpler,
but it makes writing a complex app harder (because you need to glue some other
libraries together yourself; the framework isn't doing it for you).

~~~
hamilton
From experience building more complex apps in Svelte, I can say that this has
not been my experience, & doesn't accurately depict React in practice. Three
aspects that make it really killer – a really great story for handling app &
component state cleanly regardless of complexity, a great style scoping story,
and powerful transition / animation primitives that fit neatly into the idiom
– has made it easier to build large data apps than I've found with React
(which I also use).

Another aspect I have really appreciated is that I have substantially fewer
dependencies, since there is more included in Svelte than in React. I tend to
only use d3 utility functions (format, scales, etc.) & immer (which I pair
with svelte stores to get something kind of Redux-y, which is great for other
devs jumping into Svelte from React-land). Fewer dependencies means I'm less
likely to encounter awful dependency hell.

Generally, I feel like every time I see a Svelte thread here, there's a lot of
random noise, but it's good to listen to the folks who actually use it. There
are situations where it makes sense, and situations where it probably doesn't.
The main reason why I might not use it is ecosystem friction – a lot of devs I
know would prefer to just use what they know, even if it is painful relative
to Svelte & friends.

~~~
mokanfar
>There are situations where it makes sense, and situations where it probably
doesn't.

I have been working with svelte for quite some time now, and honestly I can
not think of a time where it did not make sense to use it. At its most basic
form, its compiles down to vanilla javascript with a small footprint and
offers a tidy workspace when working with html/css/es6.

------
mrtksn
I've been distanced from web development for a year and you now have a cool
new framework, ReactJS is surpassed by VueJS and probably some other packaging
tools did something interesting and new opinions about how the same old things
should be built are on the rise.

But I have a serious question: Why the web dev is still a relevant thing?
Don't get me wrong, I won't argue that the web is dead and all should move
into AI or VR or something but I am under the impression that most of the
problems that can be solved through a Web UI are mostly solved. Sure people
come up with interesting business ideas all the time but they usually don't
require innovative Web UI tech and can be built just fine with 10-year-old
frameworks.

How is the web world doing? Why would anyone keep creating cool new
frameworks?

~~~
rahilb
My personal view is that the 'what' in frontend development generally isn't
super interesting and most web frontends are very similar; if you do not focus
on new tooling, you will just do the same thing over and over which is
unsatisfying.

If you're a very smart dev at one of the biggest tech companies in the world,
getting paid a quarter of a million dollars per year working on a niche team
that handles a small section of a single product, you will probably get bored
pretty quickly and start focusing on the how. It's a shame really; some of the
greatest minds of our generation are being put into rooms to work on
animations for buttons on virtual DVD cases and Photo Books.

The silver lining is all these tools are given away for free. The tools so
great and their corporate creators so cool that you can just have them! A
cynical reading is that they are only given away because the competition can
derive no value from them... In fact, forcing your competitors to retrain
every 6 months when you release another major version that breaks all existing
projects will only slow them down and fill your coffers! The new whatsapp will
never get off the ground, because the devs were too busy rewriting babel files
and the money ran out... you just saved a cool $18bn.

If these frameworks were really the key to anyone's successful business you
would not know that they exist.

~~~
oblio
> A cynical reading is that they are only given away because the competition
> can derive no value from them... In fact, forcing your competitors to
> retrain every 6 months when you release another major version that breaks
> all existing projects will only slow them down and fill your coffers!

[https://www.joelonsoftware.com/2002/01/06/fire-and-
motion/](https://www.joelonsoftware.com/2002/01/06/fire-and-motion/)

As a sort of side note, amusingly, Microsoft is rarely included in the FANG-
style acronyms. There's a reason for that, Microsoft is the granddaddy of
FANGs, from a strategy perspective :-)

~~~
hanoz
Or perhaps that the granddaddy of FANG-style acronyms, NOISE, was coined
specifically to refer to Microsoft competitors; Netscape, Oracle, IBM, Sun and
Everyone else.

------
_benj
I recently started a project using svelte and the difference from React and
Vue is so drastic for me that it isn't even funny!

Now, I know how opinionated we all are and how the best thing is what we
already know, but after working with Vue and React extensively (the company I
currently work for uses Vue/TS for a huge app, think over 1000+ .vue files)
the particularity about svelte is that you hardly notice that you are using
it!

Vue has the Vue way and React has prophet Abramov to light the way, but svelte
is completely out of your way. You wanna follow MVC? go ahead, DDD? why not?

I have learned more HTML5 and CSS3 using svelte than any of the other
frameworks because it encourages you to use it, because the wheel has been
invented already.

Again, everybody has their opinion but for me svelte is the framework that has
the least magic of all, the you can set it up without a incredibly complicated
webpack config or obscure 'create-react-app' that makes it very easy to start
a project but you don't really know what's happening underneath.

And it just HTML and probably 5 or 6 extra JS things like $: and a different
use for export in a component.

If you are already religious about your framework, good for you, but if you
are open to ideas, take a look a svelte!

~~~
JMTQp8lwXL
If you really want something that will get of your way, use Web Components.
They're a web standard, after all.

~~~
kjksf
React, Vue and Svelte solve 2 big problems.

1\. components (creating re-usable UI parts (i.e. components) that combine
data and their rendering)

2\. reactivity - re-rendering UI when data changes.

Web Components only solve one of those problems. And arguably not as well.

~~~
_benj
is it only me or a standard that includes what we have learned from UI
frameworks included in the browser would be really nice?

------
choward
> Svelte has not yet received the attention it deserves. When it is mentioned,
> the focus is typically on its ability to produce bundled code that is
> significantly smaller than the alternatives. However, Svelte makes many
> tasks easier, including defining components, managing component state,
> managing application state, and adding animation.

Under the "Why Consider Svelte?" it only mentions bundle size and performance.

~~~
lhorie
The way I see Svelte is as a one-stop-shop type of framework (similar to
Angular and Ember in philosophy), but exclusively for client-side concerns,
and aggressively geared towards leveraging standard web idioms (HTML that
looks like HTML, CSS that looks like CSS, JS that looks like JS), whereas most
competing frameworks extend grammars in various non-standard ways (Angular's
"HTML" isn't parseable via a standard HTML parser, and React's "JS" requires a
parser that supports JSX - and then there's the whole CSS-in-JS thing where
people get tripped up by double quoting and camel casing rules). Said
frameworks typically also have steeper learning curves due to framework-
specific APIs.

Where I think Svelte falls a bit short (given its flavor of comprehensiveness)
is that while it concerns itself with strictly client-side things like in-
memory state and animations, it offers nothing for sorta-server-related things
like data fetching or routing, and you're left to find libraries to fill the
gaps (similar to how you would in React). I feel like the bigger frameworks
are up to something DX-wise, with providing more integrated/idiomatic ways of
interfacing between subsystems (e.g. getting a data fetching API to talk to a
state store, or making routing aware of them). Gluing subsystems from
different libraries adds weight to application space code (see e.g. react-
redux vs Vue) and at some point this starts mattering (usually during
maintenance phase). Maybe Svelte's middle ground is your cup of tea, but
obviously YMMV a lot.

~~~
no_wizard
You’re the guy who came up with mithril.js? If I recognize the username
anyway.

Do you think mithril will solve these issues or is a good alternative?

~~~
lhorie
Yes, I created Mithril. I also co-authored Fusion.js[1], which - in contrast -
is about as "big boy" as a framework gets (and mostly works w/ the React
ecosystem, if you're curious). We use the latter at over 100 projects at Uber.

Mithril fits in a similar camp as Svelte, and it does offer APIs for HTTP
requests and routing out of the box. I've worked on projects before where I
literally only had Mithril as a sole dependency (and this was with supporting
IE10).

Fusion.js solves a lot of complexity-at-scale problems but it does so at a
trade-off of not being nearly as geared towards standards tracking as systems
like Svelte and Mithril.

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

------
urthen
I'm a primarily React-based developer, but have taken to using Svelte on side
projects. Don't get me wrong, I still like React, but Svelte is phenomenally
easy to get started and wrap your head around. I've started suggesting it
instead of React to people looking to learn front-end JS.

~~~
mellosouls
I read the main article which took some time to reach the conclusion a small
footprint was the main point.

So I googled, found the Svelte homepage, and I'm still none the wiser as to
why it might be an easy intro to web development.

Honestly, if Svelte is as easy as you suggest to get your head around,
somebody needs to work on the presentation of that.

~~~
spoiler
I feel like like saying svelte is an "easy intro to web development" is
misleading. The svelte compiler "abuses" (I don't mean it in a bad way)
existing technology so it doesn't have to create special tooling and works
with existing tools. I think that's okay _only if_ you're aware of this as a
developer.

If I was hiring a JS dev, and someone _only_ had svelte on their CV, I'd be a
bit reluctant to hire them, only because the svelte compiler hides a lot of JS
warts (which I think people should be aware of).

~~~
cpfohl
Genuine question: where does the svelte complier hide JS warts? I've used
Svelte for some production tools and personally in a few projects.

My experience thus far is that if you don't have at least a base-level
understanding of JS you really can't use Svelte to its fullest. I can back up
that intuition by having observed the svelte support channel on discord, where
many of the questions really wind up being questions about javascript rather
than Svelte.

------
pzmarzly
I'm migrating one of my sites from jQuery (+ server-generated HTML) to Svelte.
I like how Svelte+rollup make it easy to replace just a part of a website
(take HTML from a file, put it into Foo.svelte, back in the original file
insert <script>new App.Foo({target: document.body, props: { /* data */
}})</script> [0]). Instead of generating HTML, server-side scripts now
generate JSON, which could be used later to make a proper API.

I don't like handling of "undefined" and "null" values in properties[1]. It
would also be nice to have optional properties so that warnings wouldn't get
emitted to JS console. Also, someone should investigate iOS bugs[2]. It would
be bad if someone made complex site in Svelte+Sapper and only later discovered
it lags on iOS.

Overall performance is okay, but it's visible to a naked eye that Svelte parts
render later than the rest of the website.

All in all, I would recommend giving Svelte devs few more months before moving
to it. But definitely keep an eye on it, it has great ergonomics (maybe except
for styling subcomponents, but some say it's a code smell anyway).

[0] assuming you set output { format: "iife", name: "App" } in
rollup.config.js, imported bundle.js in the original file, and put export {
Foo } in main.js

[1]
[https://svelte.dev/repl/f1f2bf4c50cf4a75ba6ea38c3390af5b?ver...](https://svelte.dev/repl/f1f2bf4c50cf4a75ba6ea38c3390af5b?version=3.12.1)

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

~~~
wirahx
I couldn't actually figure out what you were trying to do here, but there are
a few points I do understand, and can answer:

1\. If you want to bind a property it needs to be declared. This is the method
of least surprise.

2\. I've been running three Svelte sites in production for more than a year
now, and 80% of our traffic is iOS. The sites work fine, it's the tutorials
specifically, probably because of the embedded REPLs which have an iOS issue.

3\. You claim that the Svelte code runs later than the server-generated HTML.
This makes sense, since the DOM from Svelte components is built using
Javascript. If you wanted to generate Svelte code on the server-side so that
it renders _at the same time_ , you would use { ssr: true } in your rollup
config and generate code for both server and client side.

4\. Not sure what the notion of lag is or where it comes from, Svelte
outperforms everything else (when I last checked benchmarks), and is likely
to, since it has the immediate advantage of not requiring a client-side
runtime to download before it starts execution.

~~~
pzmarzly
Thanks for replying. In my previous post, I just wanted to share my experience
as someone who has used Svelte (for few days, though, nowhere close to how
much you have).

1\. I just missed the part of documentation that talks about optional
properties. And with undefined and null issue, it's a bit surprising that two-
way bindings behave differently that 1-way. Passing null or undefined is
convenient when an API gives you such values and they represent empty there.

2\. Ok. What I feared is that the tutorial would turn out not to be bugged,
and Svelte would be a bad choice for CPU-intensive SPAs. Thanks for reassuring
me that's not the case. I'd still love to see the fix for the tutorial bug
(because at the first glance, there isn't anything that screams "wrong!" in
its code).

3\. Yup. I just wanted to point out it's noticeable if you look for it. I will
look into SSR later.

4\. Same as in point 2.

BTW I just wasted 2 hours fighting with bind:group[0][1]. This issue is an
example of what I meant by saying that people may want to wait before jumping
on Svelte.

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

[1]
[https://svelte.dev/repl/efbe52272558468397b66e46fa906561?ver...](https://svelte.dev/repl/efbe52272558468397b66e46fa906561?version=3.12.1)

------
JTenerife
Does anyone know what's the status of Typescript support in Svelte is? This
thread is understandably locked:

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

Still I'm curious.

Typescript and RxJS (or MobX) with Svelte as the afterthought
([https://michel.codes/blogs/ui-as-an-
afterthought](https://michel.codes/blogs/ui-as-an-afterthought)) would be a
nice combo.

~~~
cies
I'm afraid Svelte with typescript will loose some of its charm. Typescript is
a little more verbose and explicit, also it cannot be directly executed by the
browser (so you need to compile it, yet it is intermingled with HTML at times
— there's JSX for that but Svelte kinda wants to NOT go the JSX/ShadowDOM
route)

Internally Svelte uses TS though, the author claims to love TS also! It just
does not mix very well with Svelte.

Stencil.js and lit-element are better picks in this regard IIRC.

------
chrshawkes
I've been writing React professionally for 5 years straight and I'm absolutely
sick of it. I haven't spent enough time with Svelte but I'm sick of React and
all the noobs who swear by it. I'm sick of it spinning around in circles and
nobody getting anywhere. I'm sick of terrible SPA's consisting of a pile of
bandaids stacked on top of one another. I'm sick of testing it with tools like
Enzyme. If React were so great, I'd expect to see better things coming out of
Facebook. They do one thing well, steal and sell users data. Everything else
was bought. Honestly, just sick of Facebook. I was more productive writing
stateful apps using C# and ASP.NET with jQuery. In fact, 9/10 we don't need
stateful UI's nor React.

GraphQL sucks too. Good luck setting up caching. For instance, hey we forgot
caching is important, now that the architecture doesn't allow for it since it
uses a single api endpoint... the talked about solution is to use localStorage
or sessionStorage. JS is a huge noobfest and those that think React is the
answer to everything, probably haven't been in this game long enough.

~~~
bavell
I too have been using react professionally for the last 5 years and I have the
opposite take on it - I still love it as much as when I started using it. I'm
a solo dev so I get to control quality end-to-end, perhaps this is where our
difference in opinion stems from.

I have no doubt there is tons of awful react code out there written by noobs
but the same can be said for practically any software engineering endeavor.

I'll concede that it takes time + effort to understand how to best use react
but it's merely a tool and you need experience and insight to understand how
best to use your tools. I try to use as little state as possible and use
functional components everywhere I can. Hooks have been a big help.

I agree about having reservations with GraphQL, it doesn't seem ready for
primetime to me although I'm keeping a close eye on it because I like the
underlying concept.

JS is a "huge noobfest" imo because webdev is so accessible and prevalent. But
today's noobs are tomorrow's professionals ;) Typescript has been a very
welcome development to encourage better dev practices.

~~~
Phillips126
> I too have been using react professionally for the last 5 years and I have
> the opposite take on it...

I'm with you mostly. When I started React close to 5 years ago it was PAINFUL.
Coming from mostly jQuery (single library and I'm on my way) to trying to
figure out gulp, bower, webpack, babel, etc. The tooling has much improved
with the release of `create-react-app`. I can't exactly say the tooling has
become better as much as it has been hidden away and the defaults are mostly
ideal. Yesterday I had a huge headache trying to figure out why my treeshaking
wasn't working (it was bundling 1.5mb of icons into my app). Turns out I was
using an old version of `react-scripts` and with it an older webpack which I
may have noticed sooner had I hand-built the tooling like the old days of
React.

It has become impressively complex with all of the moving parts that are
required for a React app these days. Webpack alone is not for the faint of
heart with all of the configuration and babel-hell that code (and other files)
has to flow through. Without `create-react-app`, I would probably have left
React long ago, which would be disappointing because I enjoy the syntax,
hooks, readability. I've tried Angular and absolutely hated it, perhaps Svelte
would be interesting to me.

~~~
bavell
I definitely agree the tooling for modern JS can be a huge PITA. Once it's all
setup life is great and productivity soars but I completely sympathize with
beginners feeling lost and even experienced devs turned off from the opaque
complexity.

------
chiefalchemist
Whoa. Sounds interesting and promising. If anyone from Svelte is here
listening I'd like to point out that this isn't quite correct. WCAG actually
specifies that __decorative__ images have no alt= or use alt=''. But yeah, a
warning can't hurt. Kudos!

Svelte provides runtime warnings for accessibility issues. For example, <img>
elements that have no alt attribute are flagged.

~~~
fredleblanc
Having no alt and having alt="" do not produce the same results to the
audiences relying on those attributes to perceive images. The W3C's tutorial
on decorative images (found at
[https://www.w3.org/WAI/tutorials/images/decorative/](https://www.w3.org/WAI/tutorials/images/decorative/))
says to use alt="" to mark an image decorative, as some (prominent) screen
readers will read the image's file name when no alt attribute is set.

But hey, that Svelte is providing these warning is great for accessibility!

~~~
chiefalchemist
Yeah. Thanks. Maybe you'll know this? Is it kosher to user aria-hidden=true
for decorative images?

I'm asking because it's not easy convincing a client that alt="" is ok.
They've read so many times "also have a value for alt-=. This is especially
true of clients who are SEO-centric. It seems to me there should be an easy
and obvious way have a decorative image with a non-blank alt=.

~~~
fredleblanc
In my experience, aria-hidden will effectively accomplish the same ends for
accessibility purposes. That article mentions using role="presentation" but
with the caveat that not all screen readers and such understand that well
enough to then not try to start reading the filename.

I guess the question is if SEO crawlers still read alt text for images marked
as aria-hidden="true" or not. I have no idea on this one, but I'm very curious
about it.

I've been pushing the folks I work with to consider SEO as a second-class
citizen within alt text. If you can reasonably use a keyword in a natural,
useful way, definitely use it. Otherwise, from what I can tell, an image's alt
text doesn't seem to have any greater SEO value than the rest of the content
on the page. Write better on-page content with better keyword use, with alt
text being informative extra content.

And clarification on when alt text is needed: 1) if the image contains
informative content that adds to the surrounding content, but also 2) a linked
image where the image is the ONLY thing within the link, in which case the alt
text should describe the destination of the link, not the contents of the
image. I just recently learned this, but it makes sense when you think about
it.

~~~
chiefalchemist
"2) a linked image where the image is the ONLY thing within the link, in which
case the alt text should describe the destination of the link, not the
contents of the image. I just recently learned this, but it makes sense when
you think about it. "

Yeah. Good stuff. Thx.

p.s. Best I can tell most images are decorative. That is, they are there for
the visual appeal, to create "white space", etc. It's fairly rarely they
actually contain content. Of course, there are exceptions, but in general.

~~~
fredleblanc
I agree! I work on a marketing team and it’s interesting to hear the
conversations about what is and isn’t decorative. Are brand elements
decorative? Generally yes, but on a marketing site, aren’t those half the
point? At which point does that make them informative?

It can be frustrating to sit in meetings where people go back and forth about
this stuff. But at the end of it all, any meeting where people are
constructively discussing accessibility is a win for me.

------
ConcernedCoder
You want simple? Try HTML, CSS, and JavaScript.

~~~
felideon
Ergonomically, that is exactly what Svelte feels like.

------
turtlebits
Svelte really resonates with me - as a previous AngularJS dev, tried to get
into React and VueJS several times, but I did not want to learn a build system
(grunt, gulp, webpack) and always have to stay up the date with the "best"
ways to build. And I don't have the time to invest in learning another tool.

The nice thing about Svelte isn't necessarily the syntax. It's the fact that
out of the box it builds without me having to learn how to build it. That and
the small bundle sizes and single file components sealed the deal for me.

------
Bantros
This is a framework I've been interested in for while. Need to find an excuse
to use it

------
sharmi
Does Svelte have a prebuilt set of components like ant.design?

------
ifthenelseend
Svelte is great, but I will probably use the new Blazor framework from
Microsoft that compiles to WebAssembly. The benefit is that I can use C#
instead of JavaScript.

~~~
cjblomqvist
Unfortunately with the downside that your bundle will be quite large.
Hopefully that'll get better, but most likely, due to fundamental reasons (you
need to pass along a C# runtime), I doubt it'll be even remotely close to
something like Svelte.

------
sadlion
Looks interesting. Is there a list of libraries that are productions ready
that can be used with it? I'm looking for Formik and ReactRouter equivalents
at least.

------
matmo
So for small apps, the final bundle size is significantly smaller since
there's no framework "runtime" code included. What about large apps though?

------
sunseb
Svelte is great. It's a shame we need a framework to do that and that the
standard HTML/CSS/JS platform can't do that natively.

------
Kye
One of the more popular Mastodon frontends uses Svelte.

[https://pinafore.social/](https://pinafore.social/)

------
brainzap
The template syntax is a bit weird. Not sure what would have been better but
thats just a gut feeling.

------
maitredusoi
Svelte is a real good shot vs the angularjs (v1) I used in 2015, but still, I
will stick to imba ;)

------
wintorez
I've never been so excited about a library since the React itself.

------
jcmontx
Looks like early Vue to me

