Author here, just wanted to make a note. This isn't written to hype a battle in the holy war. Frontend frameworks are a positive sum game! Svelte has no monopoly on the compiler paradigm either. Just like I think React is worth learning for the mental model it imparts, where UI is a (pure) function of state, I think the frontend framework-as-compiler paradigm is worth understanding. We're going to see a lot more of it because the tradeoffs are fantastic, to where it'll be a boring talking point before we know it.
I love React and I love Svelte. There, I said it.<p>These are the complaints that standout for me with Svelte after using it for a few months:<p>* Sub-par editor support. For me, the litmus test is whether I can use F2 to rename a variable, and it often does not work inside a Svelte template. There are other places where the editor does not know what to do with your code, because it is not pure JS. Vue is much worse with this since so many things are just strings; React really shines with editor support. This makes a big difference when you are using a large project where you didn't write the code.<p>* I don't love that you have to re-assign a object/array variable to get Svelte to notice it changed, and you can do that inside a Svelte template to a const variable and you won't get a complaint from the compiler.<p>* Much smaller ecosystem compared to React and Vue, which is expected at this point.<p>Other than this, I absolutely love Svelte. Stores are such an amazing abstraction. Animation is well thought out. Storybook works perfectly. Mostly it is pure JS once it gets inside the browser, so you can debug effectively which is not the case with Vue for example.
For me, the biggest downside to Svelte is the lack of TypeScript support. This is a massive deal-breaker for myself as well as many other developers. I am also not a fan of the Moustache/Handlebars inspired templating, it feels outdated in the face of enhancing standard HTML or going in the direction of something more extreme like JSX.<p>I think Svelte is refreshing, but I would not be comfortable using it on a large-scale web application just yet given the downsides, particularly an enterprise LOB application with many moving pieces. This is why frameworks like Angular, Ember and Aurelia on the front-end lend themselves better to the enterprise and React and other more component-based libraries do not.<p>In terms of community size, I don't think that matters in 2020. You don't need a big community if you have something straightforward and easy to work with. Great read.
I'm rapidly becoming a huge Svelte fan. Quick self-promotion plug (but in the name of altruism): I've been working on an open source project that glues together Svelte (on the front end) and Crystal (on the back end).<p><a href="https://github.com/noahlh/celestite" rel="nofollow">https://github.com/noahlh/celestite</a><p>Two slightly obscure (but growing) languages/frameworks, but hey, gotta pick a niche. Contributions & feedback welcome!
I enjoyed learning Svelte; it was fun to use when I rebuilt a personal project from scratch using it[1].<p>I'm trying to think of some downsides to balance my enthusiasm for the framework, but can't think of any. The article mentions the smaller community as a possible issue, but the community on Discord seem very welcoming.<p>Re "using Svelte means adopting a new language" - it didn't feel like that to me. Every framework has its own way of doing things; Svelte's way didn't annoy me as much as some other frameworks have done in the past (eg: Angular before it became Angular2).<p>I've got another personal project rebuild coming up - I reckon I'll be treating that as an opportunity to learn more Svelte.<p>[1] My poetry website (you have been warned!) - <a href="https://rikverse2020.rikweb.org.uk/" rel="nofollow">https://rikverse2020.rikweb.org.uk/</a>
I blogged about my experiences with Svelte, starting here: <a href="https://blog.rikworks.co.uk/2020/02/01/Recoding-the-RikVerse-website-Introduction/" rel="nofollow">https://blog.rikworks.co.uk/2020/02/01/Recoding-the-RikVerse...</a>
I LOVE what svelte is doing. I've been using React daily for the last 5 years & it does the job, documentation is world class, community is great, but it still has sharp edges & parts that feel bad. Things like hooks make complicated things look & feel simple, which is great for 80% of my work, but for that other 20% (exit animations, high frequency re-renders, drag-n-drop without HTML5) I do some pretty atrocious things to make it work. This is where svelete shines.<p>The readme does a good job of pointing out its shortcomings, too. Primarily, no typescript support yet & the unknown bundle size inflection point. As soon as these are solved, I can't imagine it not becoming the best (albeit not most popular) solution.
I applaud the effort and will be following this project closely.<p>I love the pragmatism of this framework - no solutions looking for problems or complex, badly documented abstractions.<p>Even if Svelte won't be <i>the</i> next generation framework everyone will be using, the ideas it presents are definitely something the web needs.
Having used Svelte for a couple of projects [1][2], I love it. Compared to my day job working in react/redux, it is much simpler, and feels like it has far less boilerplate.<p>There are certainly a few rough edges, but it's all related to the immaturity of the language. Specifically, I had a hard time understanding transitions and it wasn't at all obvious how to integrate it with D3. Hopefully as it grows we will see improved docs and examples.<p>Also, I'm holding out for more mainstream TypeScript support. At that point, it would be hard to convince me to use anything else.<p>[1] <a href="http://musetree.stevenwaterman.uk" rel="nofollow">http://musetree.stevenwaterman.uk</a><p>[2] <a href="http://optimisation.stevenwaterman.uk" rel="nofollow">http://optimisation.stevenwaterman.uk</a> + <a href="https://blog.scottlogic.com/2020/02/17/minesweeper-optimisation.html" rel="nofollow">https://blog.scottlogic.com/2020/02/17/minesweeper-optimisat...</a>
I watched a tutorial by the author Rich Harris today after reading this link on HN earlier and stopped when he started talking about a DSL he created for Svelte so you don't have to write as much JS. I don't want to learn another DSL. I don't see what the big deal is about compiling. We've have many languages that compile to JavaScript and Google Closure Compiler to tree shake and minify. For years now! Svelte is a nifty DSL to JS compiler that produces small bundles because there is no SDK to back it up or include. Cool, I guess.
I dislike the templating pseudo language of Svelte (and many view frameworks). Maybe I am spoiled by react but I never ever want to write my view logic in anything else than JS. This is my main blocker for Svelte.
I love svelte. but now resorting to server rendered html pages with sprinkles of JS. shit I work on and I have noticed in the world doesn't really need frameworks like react, svelte, vue etc.
What I'd hoped to see here was why use Svelte for a <i>large</i> web project. I get the advantages, but devising and maintaining good architecture is hard enough in the more established React paradigm. What do complex and older Svelte apps look like? This is the part that's missing for me, not pleasant DX and early-web nostalgia.
Ah, I mentioned it on Twitter [1] somewhat prompted by seeing this article, but before reading it, but:<p>> It's interesting that Svelte is positioned as a Javascript framework: it seems to be practically a different language, far more so than JS+JSX.<p>> The downside is that it's hard to integrate with much of the Javascript ecosystem, e.g. TypeScript.<p>> Yet at the same time, it doesn't fully embrace being a different language, so it does not add features like e.g. how Elm supports pattern matching.<p>> It does make it an easier sell, I suppose, which does certainly count for something. Am I missing something else?<p>After having read it, it does seem that the author does both consider it a separate language, but also still presents it as a JS framework. I wonder if the former isn't being underestimated?<p>[1] <a href="https://twitter.com/VincentTunru/status/1237422539128868865" rel="nofollow">https://twitter.com/VincentTunru/status/1237422539128868865</a>
Going back to React a week ago after doing Svelte seriously since Oct 2018 is tough. Asides from the obvious stuff - Svelte's speed and bundle a size of 0: JSX isn't HTML, using weird helpers to enable a class when a JS ternary would do fine, setting state is clumsy, and there's way too much complexity if you're not already used to using React.<p>That said, I'm also really enjoying TS so could understand why someone may want to stick with React for a new project until Svelte gets TS.<p>My big Svelte project isn't public but my personal site is a Svelte app too:
<a href="https://mikemaccana.com" rel="nofollow">https://mikemaccana.com</a> source is at <a href="https://github.com/mikemaccana/mikemaccana.com" rel="nofollow">https://github.com/mikemaccana/mikemaccana.com</a>
I love many things about Svelte but after using Vue for a couple of years I wouldn't go back to single file components.<p>The idea of having markup+logic+styles in the same file works for small components but it gets muddy on bigger ones. It can be argued that components should be as small as possible but OTOH having to create a new file for every damn component gets old very quickly.<p>For the past 2-3 years I've been working again with JSX based libraries and being able to create micro components on the same JS file makes a lot more sense.<p>I've also gone back to regular SASS and moved all CSS outside of components (except for dynamic CSS). It works better IMO than single file components.
I like what I see from Svelte but I'm afraid it's going down the exact same road Meteor did.<p>Too many options, not enough Blessed Solutions for basic things.<p>Take routing for example, in Svelte you have a lot of options but no real #1 "Svelte Recommends (tm)". They should solve this problem before it gets out of hand. It killed Meteor.
I have switched to pure HTML/CSS/Javascript for frontend. And I am very happy with it.<p>I sometimes use external libraries. For example handlebars if I want to template something clientside.<p>But no more frameworks.<p>I think pure Javascript is plenty enough these days.<p>For those who can't live without a framework: What would you miss?
I am on a team that has chosen Svelte to replace Riot.js. It has been an excellent experience. We have found that since Riot and Svelte have some similarities in structure and do not use a shadow DOM, we that our old Riot code and new Svelte code co-exist while we build new features and slowly migrate everything.<p>Our team has diverse experience with the other tools in this space. I would say that the consensus is that Svelte is far more intuitive and <i>fun</i> than other tools.
I want my templates as first-class citizens. If I have to deal with strings and weird, half-baked syntax for loops and conditionals, I'm out.<p>JSX really spoiled me to the point that if there isn't JSX, I don't want it.
Shameless plug. I've choosen svelte for webextension that will be allow you to record, replay and modify requests on the fly. I've choosen Svelte, because 1. courisity and 2. it can compile to webcomponents and also reference webcomponents in normal svelte components. I discarded the webcompoments for everything idea, mostly because clunky passing and registering events with svelte (svelte issue). There few thing that needs to be polished, like typescript support and this events handling with webcomponents, but overall, very satisfied with svelte so far (as former React guy).
I enjoyed the brief period I spent playing with Svelte. I ran into some bugs with the built-in animation support when changing states (there's built in animation support for changing states!) that I couldn't resolve, and which were pretty glaring in the UI. This was 6-9 months ago, though, so it may well have been fixed by now.<p>I'd really encourage all front-end devs to take Svelte for a spin, if for no other reason than to see a framework really trying to do things differently. There are a lot of nice ideas in there, and the works-out-of-the-box level is admirable.
> Svelte is one of the 6 JS frameworks in the (flawed) State of JS 2019 survey — 75% have heard of it, 7% have used it, and 45% are interested in learning more<p>Why is it flawed and why are you citing a flawed study? You mention that it's flawed twice but then immediately cite data from it. If you're telling me it's flawed why should I care about the data?
hate all frontend compile steps from a developer productivity perspective but love it from a user value perspective, especially if that enables JS-disabled browsers to more or less use dynamic sites
Slightly offtopic: Why a git repo for a blog post? I guess there are some pro's: public history, PR's , but a blog has comments directly under the article for example. Forking is not expected. Ah well, extensive information anyway, good work :)
Especially excited to consider a solution without huge runtime libraries (think jQuery, React, Vue). Minimizing web page sizes and enabling dynamic content (which is a mainstay in modern websites) is a huge plus.
I love svelte on the personal/toy projects I've tried it on, but does someone have an example of a large-ish svelte codebase with an example of a testing pattern that they've found works?<p>Using mithril/vue/react, there are assertions you can make about how a given action will modify the state, and given some state, how that state will be rendered.<p>I've not found a good way to make assertions on the behavior of code without resorting to poking through the DOM and dealing with asynchronous behaviors.
I love the idea of svelte and want to try it on my next project.<p>The compiler paradigm is really powerful. What if you could extend Svelte to give it knowledge of your db schema and it would figure out an optimized way to load data by generating all that code if needed. Probably something like this exists already somewhere and was forgotten about, but one can dream.
How is it that 23 hours in and nobody is pointing out that svelte/sapper just freezes on runtime errors without the ability to show an error page or report them to a tracker like sentry/rollbar/etc.? This is one of the biggest barriers to being production ready or fit for use in large projects.
The one thing that gives me reservations about Svelte is that the description about how code turns into web pages makes me wonder if there are any problems with code-build-run-test cycles.<p>I'm concerned I'll spend all of my time restarting my application to validate changes. Is this a non-issue?
The lack of a large and mature ecosystem would prevent me for starting a "large" web project. Svelte is still missing UI frameworks like Material UI or Vuetify. Won't you need date range picker ? Full powered data-tables ? Treeview ? Advanced cards or other layouts ? Awesome effects / styles for a rich UI ? Svelte Material UI is a start : <a href="https://sveltematerialui.com/" rel="nofollow">https://sveltematerialui.com/</a> But I will definitely give Svelte a try for my next "medium" size project.
does svelte have a way of hiding the .svelte components from the users on the frontend? e.g. so they cant blatantly rip the source code in your components and reuse them
Svelte is absolute trash.<p>It actively encourages mutability, which is a one way avenue to bugs bugs and more bugs. ie, shit like this is all over the official documentation:<p><pre><code> <script>
let mutable = 1;
function f1() {
onMount(() => {
mutable = /* do some complex shit here */
});
}
function f2() {
onMount(() => {
mutable = /* do some complex shit here */
});
}
</script>
<Component onclick={f1}>
<Component2 onclick={f2}>
</Component2>
</Component>
</code></pre>
Complete non-deterministic state changes. Absolutely abhorrent stuff. Cannot believe my coworkers and others actually like using this absolute garbage of a framework.