Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: What are your experiences with Svelte (JS framework)
110 points by melleb on Oct 28, 2019 | hide | past | favorite | 101 comments
Hi HN-crowd,

Is anyone using Svelte (https://www.svelte.dev) in production? What are your experiences with it? I can't seem to find any experience reports.

Thanks!




I've been pretty happy with it. I migrated my website to use it and I'm also using it for a new project. I've found that I'm significantly more productive with it than when using React or Angular, since there is two-way binding and very little boilerplate. There is also a material UI binding for it [1], which makes it easier to develop advanced user interfaces. In my experience, bundle sizes with Svelte can be smaller than JQuery, whereas I typically see bundles over 1 MB for Angular and larger than JQuery for React. The framework is also very easy to learn, as there is a full interactive tutorial [2] online and the framework is optimized for development experience.

The only area of concern at this time is that there is no TypeScript support and debugging can be difficult as it often throws exceptions in vendor code if the error isn't caught by the compiler. Despite this, I've found that I am more productive and get less runtime exceptions developing with Svelte than Angular since it is simpler to develop with and does a lot of compile-time error checking.

I have a repository with working scss and IE 11 polyfills [3]. It's using a custom system for authentication, but it is easy to switch out with something more ideal. There is also a branch with svelte material UI installed. I find that Visual Studio Code with the svelte add-on is the easiest way to work with it.

[1] https://github.com/hperrin/svelte-material-ui/ [2] https://svelte.dev/tutorial/ [3] https://github.com/iwalton3/swapi-svelte


How come there is no TypeScript support, but in the official GitHub repo (https://github.com/sveltejs/svelte) they state:

"The compiler is written in TypeScript, but don't let that put you off — it's basically just JavaScript with type annotations."


Writing a JS compiler in TS is easier than writing a TS compiler in TS, since TypeScript is a superset of JavaScript.


its written with typescript, but inside of svelte components, it doesnt support typescript authoring by default. there are third party ways to preprocess typescript though, just not officially supported.


Svelte (and Sapper) has the potential to be huge. I normally don't participate on any online forum but signed up specifically to comment on this topic. I've experienced building web sites starting with cgi-bin handlers to React apps and everything in between. React reminds me of the Java days when we would use the Spring framework - huge tooling and setup, architecturally moribound (in a sense, dont flame me), and too many layers separated from the fundamental technology - HTML/CSS/Javascript. Out of all web tech, React is my least favorite and I find it in many ways to be absurd (my opinion, dont flame me). Don't get me started on React Native...

Svelte is the proper step forward - it's an actual improvement in web development and keeps you close to the fundamental technologies without large architectural costs. I know this is a religious argument but after 20 years I am squarely in the readable code vs highly architected code camp. With heavy architecture you have to know too much to get into the code. I remember a joke about Java that to read a text file you needed like 20 LOC and 10 classes (or something like that don't flame me please).

Svelte is clean, has intuitive separation of concerns, is close to the fundamentals, and using it feels like web development has actually been improved. The lack of Typescript will be resolved hopefully soon.

I only wrote this as a public kudos to the Svelte team and to voice my support. Angular's early days were close, vue is closer, Svelte might have nailed it. React belongs in the trash.

Dont flame me please


> Dont flame me please

If you feel the need to include this 4x in your post, perhaps it's a good idea to do some re-evaluating ;)


Why do you think that React is absurd?

I’m not a Rect developer myself, but it is always interesting to listen to others experiences with it.


I almost flamed you.. but After xteen years I still try to like web development but I still fail to comprehend why the web dev world struggles to reinvent programming starting mid air and working towards foundations, starting with a flawed high level language and going towards "assembly", starting with an incomplete set of high(er) level UI primitives (input, button, select, p, div) and a primitive rigid layout system and working towards components and more complex forms of declarative layouts. Please someone make a Svelte compiler in Go.. I can't stand Node.js and I can't install it on my machine without feeling dirty. Please don't flame me..


There’s a decent JS to JS compiler (replacement of Babel) in Rust which understand TypeScript: https://swc-project.github.io This could be a good starting point.


I've been using Svelte in production for over two and a half years. It's tough to go back to a fully-run-time framework after using Svelte.

So obviously the tiny amount of run-time code leads to better performance, but what surprised me was how much better the run-time debugging story is. If my code causes an error to be thrown inside the "framework" code, the stack is always very shallow, and it's easy to follow to figure out what's going on.

Compared to my experience with e.g. trying to trace through AngularJS's digest cycle, following what's going on "under the hood" at run-time is pretty delightful.


Yes! I have been using Svelte on Budibase (https://github.com/Budibase/budibase) for the past year. Although Budibase is not in production yet, its a serious project that we plan to release in the next few months.

I have used React and many others over the years - currently using react in my day job.

I really like Svelte. I would happily choose it over React for any of my own projects. I find Svelte simple and intuitive - it is the easiest framework i've ever used, to get to grips with.

The tooling, resources and no. of 3rd party libraries are way smaller than the bigger hitters, like React - understandably as it is much younger. I have not found this to be an issue at all - theres a VS code extension and a great community and website/docs/examples.

It will obviously be more difficult to find devs with Svelte skills, if you are hiring... but its so easy to pick up, i dont think thats a problem.


Our small team is currently evaluating svelte as a replacement to riotjs and vuejs. We have reimplemented several of our projects in svelte and like the results and the easy learning curve for getting our team up to speed.

The documentation for svelte has been first rate. The shareable REPL has made asking questions and answering them very easy.

The community on Discord has been very helpful.

Since we began evaluating 6 months ago, we have seen a large growth in interest in svelte. I wondered if this was bias, due to our current focus, but I see the increase in my 100s of RSS feeds. (Still a small amount of data points)

Training is a key aspect for us. We will be needing to train our existing team, and svelte feels like a good fit for us. Any new hires would need this skill as a secondary ability, and we feel like it is more likely they would pick up svelte quickly

All that said, we have not made a commitment to svelte yet. Our alternative would be to stay with what we have


I've been using Svelte since inception, and you're 100% right, there's been a significant uptick in user base over the last 6 mos. Basically since Rich did his Rethinking Reactivity talk at YGLF back in April.[1]

[1] https://www.youtube.com/watch?v=AdNJ3fydeao


(which coincided with the launch of svelte 3)


I would love to have you write up your experiences and how you would transition from VueJS to Svelte. I'm going to set a reminder to check this comment for replies every day for the next month, I am THAT interested. :)


What is your opinion on riotjs?

I have followed that project for many years & it has always had an interesting component system, but I have never done anything serious with it. They have recently released a new major version. Very small community.


Fantastic.

But it needs a router. I'm using svelte-routing which works pretty well but even in a lightweight package like Svelte I think it's almost essential to provide basic routing as part of the package.

After all, stores are provided even though plenty of third-party store libraries exist.

The refreshing thing about Vue is that it includes a great router solution out of the box. The Vue team obviously realized it couldn't be considered an optional extra, just as stores aren't.

Yes, Sapper has routing, of a specific kind, but a developer shouldn't have to employ a framework like Sapper to get basic routing functionality.

Otherwise Svelte is killing it. Well done.


>But it needs a router.

Sapper. A bit rudimentary but it dovetails nicely. Plus, built in export for static sites.


I mention Sapper above.

Sapper adds a great deal of additional functionality and a framework layout that Svelte on its own does not. All Svelte needs is its own router to be the complete package.


Not using in production but really willing to do so, because the concept is just beautiful. Writing components is a pleasure. Fresh view at animations, which I haven’t tried much, but it looks very promising and convenient (and ofc fast, - first of all). Very, very good tutorials!

However, there’s a couple of unwilling moments:

- A lot of boilerplate code in a newly generated project (very easy to get it outdated when new versions come)

- A popular one: still no good typescript support

And... I think that’s all? Pretty much all the rest is just beautiful.

I think these are two things which bind me from going all in, and use it everywhere, on every new project


Looks neat but I don't know why you'd choose it over one of the big 3 (React/Vue/Angular).

Seems to have far less community support and 3rd party libraries available. If you're a business it's probably harder to hire for too as it's less well-known.


Not everything needs to be thought of as a business use case, you don't always need to think about the ability to hire additional developers who know your framework of choice. Also when I'm hiring I care very little about whether people have experience with the framework we use (Angular).

Even still, I think svelte can be a good choice if your focus is on enhancing html with javascript rather than focusing on javascript for everything.


What?

"you don't always need to think about the ability to hire additional developers who know your framework of choice"

Unless you are hiring a junior dev who has no experience I think this statement is pretty far fetched. The ramp up time for a new dev on a framework that isn't widely adopted yet will be way higher, plus hiring developers who would even want to work with said framework sounds like a task in itself as well.

If you want to enhance HTML use Vue, if you want to focus on Javascript for everything use React. I like the idea of Svelte coming in to push other frameworks forward, but by no means do I think Svelte will be the future (this may not age well, but at this time my opinion).


> The ramp up time for a new dev on a framework that isn't widely adopted yet will be way higher

What, like a couple more weeks? I find it hard to believe that an experienced React/Vue/Angular dev would take a long time to pick up Svelte.


What, like a couple more weeks?

For a junior, sure, but I would expect a mid-to-senior developer working on front-end JS for a living to have some experience of at least one of the popular rendering libraries/frameworks and therefore to be able to understand at least the essentials of any of the others after a few hours of training. They're relatively simple interfaces, and many of the same concepts come up in most or all of them. Of course it will take a bit longer to understand the edge cases, any unusual or unique aspects, and any common traps to avoid, but you don't need all of that to be productive with everyday front-end development work. Presumably anyone new and/or below senior level is going to be supervised/mentored while they're getting up to speed and have their code reviewed anyway.


Finding all the intricacies and gotchya's of a new framework does not happen in a couple of weeks. Also, a total workflow change is not adapted to in a couple of weeks.


> Finding all the intricacies and gotchya's of a new framework does not happen in a couple of weeks

That's how you know you picked the wrong framework.


That's sort of the beauty of Svelte. The surface area is minimal, and as such - though there are gotchas, you can almost count them on one hand.

I learned to use Svelte (granted, v1), in 45 minutes, and build something using it. I guarantee that a developer won't need 2 weeks to become comfortable in it.


Training doesn't happen in a vacuum. Intricacies and gotchas should be known and hopefully documented by the existing team which can help ramp a new developer up quickly


I agree, really good point.


I read that as an addendum to "Not everything needs to be thought of as a business use case". Which is to say: if you're working on something for fun, just choose the stack you'll enjoy the most.


Fair, but the rest of the comment did not support that point as there is a direct reference to hiring developers in the same sentence.


I was writing Svelte code after an udemy class having done Vue prior to that. They aren't that different. anyone who can write react or vue code could be writing svelte code in a week.


Yes, but it is so much easier to implement Svelte components than components in Angular, React, or Vue. So much less code to write. No need to write classes, just plain functions, so no need for "this". Automatically scoped CSS. Very easy state management, both inside components and shared between components. And Sapper adds even more cool things like server-side rendering and code splitting with no configuration required.


>Looks neat but I don't know why you'd choose it over one of the big 3

Vue is backed and influenced by Chinese corporations, and React is FB, if you dislike both and can somehow afford to avoid depending on them you might become a happier dev.


Seems to me that Vue is avoiding influence from Chinese corporations by being supported via his Patron[0].

I don't see any source backing up your claim that Vue would be influenced in any way by China.

[0] https://www.patreon.com/evanyou


He deleted his recent tweets in support of China regarding HK.

https://twitter.com/bravemav/status/1185065083690373120


Even if Vue was influenced by China, does it matter? It's an open source front-end library. It's there for everyone.

And React being supported by Facebook isn't a bad thing either. Means more development time is able to go into it from professional developers.


It matters if devs who depend on donations for a living get their donations cut because someone they know or even themselves do something China doesn't like.

With React it's different of course, objectively you're right, but subjectively, using React doesn't feel right if you dislike FB, and using FB technology can scare of customers if they get aware of it. If you want to trash a competitor in a space that's somehow privacy focused, just mention that your competitors tech stack is from FB!


I don't think it's fair to compare the community of a framework which is less than half the age of the ones you are comparing it to, but I agree community is a big one - luckily I've found the Svelte community super helpful, so I've really not suffered at all.

As for 3rd party libraries - it's ludicrously easy to integrate anything you want with Svelte. I've built wrappers for Vue and React before, and I can safely say that it isn't necessary for Svelte. Things just work.


Love the performance, love the component model, and honestly the tooling is starting to get really, really good. I think 2020 is really going to be Svelte's year.

I'd also note that Svelte is the least framework-y of all the frameworks, which is why I think it's perfect for beginners.


I wish the template syntax is similiar to Blazor. I feel the {#await} block is a bit too magical. Also, I'm afraid the template syntax can't keep up with Js syntax which keep evolving.

I like how Blazor approach the template syntax by allowing C# control flow syntax (if, for, ...) but disallow expression and assignment. I think if svelte template syntax allow Js syntax with the same rule as Blazor, it can keep up with Js evolution, especially when it support pattern matching. Also, _maybe_ it will make it easier to implement the autocompletion in the svelte langserver.

Ah yes, one feature request. What about make props and reactive assignment reflect on custom css variable too? (which mean --css-var need to be locally scoped same as how .class is locally scoped).


I've used it in a small project. It has so many great things but I don't love some of the dev ergonomics.

My first big problem is that you can't have more than one component per file, much like single file components in Vue. If you're working on a component that has many sub-components it becomes very tedious to switch around files. In Vue instead of creating new small components when using SFC I tended to complicate the template and logic of the current component... This made the workflow less tedious at first but I quickly learned is a terrible long-term approach. In more JS centric frameworks like React or Mithril I don't have this issue. It's ironic since Rich Harris preaches the "1 screen rule" and this completely breaks that.

The other issue I had with Svelte is the official reactive stores. The first weird thing is in Svelte a store is a reactive variable, not a bunch of reactive state like in other libs/frameworks. It quickly becomes tedious if you need to model semi complex data. Vue has the same problem in Vuex with its shallow (and dumb) objects. MobX IMO is so much better in terms of data modeling since you just define your models in any way you wish (pojos, classes, etc) and you just add decorators for the reactive properties/variables.

You can indeed add MobX to Svelte but then what's the point? It would be better to use Mobx-JSX which adds minimal overhead over MobX and is insanely fast.

https://github.com/ryansolid/mobx-jsx

Of course the problem with MobX is that while it has very nice dev ergonomics it's a very complex piece of machinery.

After fiddling with reactive state for about 4-5 years I've come to the conclusion the best approach is the one that Mithril and Imba follow: no reactivity. Your data is whatever you want and you don't need expensive tooling like MobX/Redux/Vuex to make it reactive. Whenever there is a user event everything is re-rendered automatically and the v-dom or memoized system take care of rendering the DOM parts that need to change. If the data is updated from an API response or some WebSocket the developer just calls a method to let know the renderer the data has changed. It might not be the ultimate fastest approach in terms of performance, but it makes development much more simple and it's fast enough for 99% of use cases.


A Svelte store can hold a deeply nested object. It's up to you how fine-grained you want the stores to be, anywhere from one store per value to one store for the entire application. I think a middle ground is best.


Yes you can, I didn't say otherwise. (I did criticize Vue though)

My point is that Svelte stores are tedious and ironically seem to go against Svelte's filosophy of lean code.

Here are the docs if anyone wants to take a look:

https://github.com/sveltejs/rfcs/blob/master/text/0002-react...


You can do complicated things with Svelte stores, but in my experience most of the time you only need something like this using a writable store:

<script> import {writable} from 'svelte/store'; const person = writable({name: 'Mark', zip: 63304});

  function handleChange(event) {
    const name = event.target.value;
    person.set({...$person, name});
  }
</script>

<input on:input={handleChange} value={$person.name} />

<div> Hello, {$person.name} at {$person.zip}! </div>

Of course if person is only used inside this component, you would not use a store. If it is used in other components, you would typically define and export the store in another .js file and import it everywhere it is needed.

My point is that this is a very simple way to share state between components and nowhere near as complex as the page you shared might indicate. That's because you do not need to use derived stores or custom stores. The simple writable store works in most cases.


Right but this is still a lot of code for changing the name of a person.

Also, this works with pojos and primitive values. What happens when you add class instances, relationships, children, etc?

For example in a project I was working I had geometrical figures in my reactive data model. With classes I could simply do:

    rectangle.getArea()
With MobX this was super simple to implement. If I wanted to change the position of the rectangle I would simply modify the x and y observable properties.


@pier25 You got me curious about this. I've never seen this done with Svelte, so I decided to try it. Check this out: https://github.com/mvolkmann/svelte-with-classes/blob/master....

The key is that when you update a Svelte store you must return a new value. It's enough to just return the value you updated. You see that happening here on lines 16 and 21.

I take your point that this is not as transparent as when using observables. But at least you can use classes that have relationships and call methods that modify the objects when those objects are in Svelte stores.


Exactly but this could become complicated pretty quickly.

Right now you have 1 update operation for an XY translate. What if you wanted to be able to change multiple properties of more complicated classes? You'd need more boilerplate for each update.

Like I said in a previous comment, my favorite approach right now is what Mithril and Imba do: no reactivity. You change your state and when you're done you tell the rendering engine that the state has changed.

https://mithril.js.org/redraw.html

https://www.imba.io/guides/essentials/state-management#state...

Since this is all vanilla you can do pretty much anything you want with your state. Mutable, immutable, etc. You don't need to add the weight and overhead of something like MobX/Redux/Vuex and you can add as much or as little bureaucracy/boilerplate as the project requires.


It seems like both Mithril and Imba do some form of DOM diffing. It’s easy because you just tell it to update the DOM using the latest state. Imba in particular says it has a really fast way to do that. But isn’t it that case that no matter how fast they can make it, it is still doing way more work than an approach that can determine what parts of the DOM need to be updated without DOM diffing?


Mithril uses a vdom so yes it's doing diffing. It's certainly slower than Svelte but it's still plenty fast for most use cases.

https://krausest.github.io/js-framework-benchmark/current.ht...

Most importantly Mithril is very lightweight. Check the startup metrics on those benchmarks. This is not a totally fair comparison since Mithril includes a router and an http client and the others do not. Still, it manages to be among the best.

Imba uses memoization and, much like Svelte, direct DOM manipulation.

https://www.imba.io/guides/advanced/performance

Imba was used to build Scrimba (an online code tutorial/editor) which is very impressive.

https://scrimba.com/

I couldn't get past the Ruby-esque syntax, but it is a very impressive effort.


You can create a custom store in Svelte and do almost the same:

import { writable } from 'svelte/store';

export default function(state) { const { subscribe, set, update } = writable(state);

  return {
   subscribe,
   getArea() { ... }
  };
};


I've written applications using JQuery, AngularJS, Angular, Polymer, and Vue. And I can easily say Svelte provides the best development UX of the bunch.

I get more done with less code, the code is more readable. I notice other frameworks creating hacky solutions to solve simple problems that Svelte just handles out of the box.


I've used it for a small side project. It's fun to build in, but the testing story is almost non-existent.


The testing story just hasn't been well documented yet in the official docs. I have documented both unit and end-to-end testing with Svelte here: https://objectcomputing.com/resources/publications/sett/july...


Great link! Were you able to get unit tests with `context` working? Last time I tried (I believe with @testing-library/svelte) it didn't work because each component is compiled separately and don't share a runtime.


I haven't tried that.


We are currently in a migration process. So far I love it. It's the smart thing and fast to learn. Tried vue.js as well. But Svelte is just more simple. Need to be self enabling and finding or making stuff , but having 100% control is great. Created our own Svelte repl for svelte template integration.


I love it. I am working on a project using NW.js for a desktop application. I first did it in Vue, then moved to Mint, and now using Svelte. I had to move away from the other two due to limitations that I could not figure out how to get past. Also, moving to Svelte had the final build 1/3 of the size of the other two (Mint uses React under the hood).

I'm also redoing my GitHub pages website to use Svelte to dynamically create the pages with the pages on GitHub as markdown files. This way, I just push new markdown file to the github site. Much quicker and easier.

I've been trying to use Hugo for my site, but I can't get it to do what I want. I'm most likely not patient enough to work with others code. But, by doing my own, I can get it to do what I want easily.

Svelte has totally changed the way I approach web based work!


It's cute but I can't recommend it for a project with more than one developer. Lack of TypeScript support and the hacky component model (specifically, Svelte's equivalent of React props) are the two big deal-breakers.


I haven’t done much React, but I’ve played around with svelte a bit recently and I haven’t found any severe issues with the props model. What don’t you like about it?


Since Svelte props are just variables it's pretty easy to do weird things. Also it's kind of a pain to need to open up a file and read through a dozen lines of code to figure out what the props are.

The most important thing is it makes it difficult to build the same tooling that other frameworks have. For example, in React you can either define your props as a TypeScript/Flow interfaces or use the `prop-types` library. This gives you an easy way to automatically validate props outside of the context of component instantiation. For example, you can do:

   import MyComponent, {MyComponentProps} from "./MyComponent"
   const props: MyComponentProps = {...}
Or you can do things like composing props (using prop-types here):

   import {propTypes} from "./MyComponent"
   import {propTypes as otherPropTypes} from "./MyOtherComponent"
   const MyNewComponent = () => {...}
   MyNewComponent.propTypes = {...propTypes, ...otherPropTypes}
All this is possible since props is just a single object that is baked into the React API. In my own Svelte project I've been toying with the idea of only having a single prop called `props` although I'm sure this affects Svelte's rendering performance.


You could just use the undocumented but totally available $$props object.


I understand if you really want TypeScript support, but why do you feel the component model is hacky? I find it beautifully simple.


I elaborated below. A mix of the strict one component per file rule and the definition of props as a sequence of independent variables prevents a lot of patterns I use on larger projects.


As somebody who doesn't want typescript support, at all, I relish the lack of typescript support!

Also the component model isn't "hacky". It's logical, unopinionated and straight-forward. I don't know how much you know about Rich Harris but he's not one for producing "hacky" public APIs.


> As somebody who doesn't want typescript support, at all, I relish the lack of typescript support!

That's a pretty strange statement. TypeScript support does not mean you have to use TypeScript. It's purely additive by design.

By hacky I mean "define some global variables and the compiler will do some checks to make sure you don't do anything untoward". You can see my other post in this thread for examples where this model falls apart.


Every new thing has humble beginnings...

https://blog.risingstack.com/the-history-of-react-js-on-a-ti...

Fun Fact: The audience was skeptical. Most people thought React was a huge step backward. This happened as mostly 'early adopters' attended this conference, however, React targeted 'innovators.' The creators of React realized this mistake on time, and decided to start a 'React tour' later on to turn haters into advocates.


I still think react and angular are a step back


I don't disagree, but there are enough references to the "big 3" in this discussion to warrant a reminder of its lack of developer acceptance early on.


A step back from what? Jquery?


I think Svelte is very good for sites. I'm using it for my own, and wrote it up: https://www.swyx.io/writing/svelte-static/. i like that the progressive upgrade story (aka if i need more dynamic functionality, i dont have to retool dramatically) is there and it is super straightforward to use React on top of Svelte if i absolutely need to.


Silly note, but its just https://svelte.dev and weirdly they don't appear to even have the www subdomain registered, so anyone copy pasting above will error, but the site is up.



Apparently they're adherents of http://no-www.org/.


if that is the case they are not doing it right - from your link: "we make the modest proposal that website makers configure their main sites to be accessible by domain.com as well as www.domain.com."

Seems completely anti-user to not have a redirect. I wonder if it's just an oversight.


Doesn't inspire confidence!


I absolutely love Svelte ... and Sapper too! Here's a talk I gave recently on Svelte. https://www.youtube.com/watch?v=PXOE7oZyaBA


I recently switched a debugging component that ships with https://boardgame.io/ to Svelte (previously React) and it has been quite nice to work with.

Previously, only React users were able to use this debugging component (even though the library ships with an API for non-React vanilla JS users as well). After moving to Svelte, all users have a consistent experience, and it's now easy to create wrappers for Vue / Angular without much effort because a Svelte component can be used in all those places in a framework agnostic manner.


I really love svelte. But in our company they afraid to use this because lack of typescript support. Without the typescript support it is very difficult to use in any enterprises application. We love svelte and waiting for .ts


I think it really needs an official router, on-par with vue-router, and of course Sapper doesn't count because it is a full framework, requires you to have a server and its too complex anyway


I'm very impressed with Svelte so far, I think it has set a new standard for front-end frameworks.

Pros:

- Great DX (happy developers)

  - Easy to learn

  - Code is easy to reason about

  - Little boilerplate
- Small code base (less bugs)

- Very fast (not best in class, but close enough)

- The benefits of being a compiler (eg. data viz, more to come)

Cons:

- Lacks official support for TS (coming)

- Lacks the rich ecosystem of React/Vue/Angular (comes with adoption)


I evaluated Sapper and Svelte previously for a side project. The tutorial and tooling was great. Unfortunately, the hacks needed to add typescript made it a nonstarter. I look forward to TS becoming a first class citizen like what happened with Next.js (the solution I chose in the end).


I've created a small site to be used by a nonprofit. A few pages, JAMstack. I think it's great and will try to use it as much as I can in the future.

Somehow in your tutorials using `$page` for accessing `page` store values completely escaped me.


I heard that too on the Reddit sub a few days ago. Perhaps it's something the doc writers want to address.


I used it for a few small apps and enjoyed. I also build/rebuild a few static sites with Svelte and it is my default tool for static sites now.


How does Svelte handle static site generation? For context, I did some React for a job (using SSR), and have recently tried learning Vue in a small hobby project, using nuxt.js with it for static site generation. Is there an equivalent of nuxt for Svelte to handle all the generator tooling?



My only problem is that I cannot export as custom element. Web component is nice but shadow dom is complicating far too much my use cases


The Svelte compiler does support exporting as a custom element: https://svelte.dev/docs#Custom_element_API


Well, I know that it supports exporting to custom elements, what I miss is the option to NOT use shadow DOM (now it is forced)


I feel crystal clear about the state and logics but missing typescript support bring me to stencil for now.

Keeping an eye on it's development.


I've been using Svelte for nearly 4 years now, with nearly 3 of those in production. Our entire site https://beyonk.com as well as our admin, backend, and client apps, widgets, and SDKs are all built in Svelte.

I'm a competent all-round developer, but I (was) more comfortable on the server-side than the client-side. However, Svelte has been the first framework (I've used Angular a lot, Vue a lot, and React somewhat) where I've felt fully comfortable working on the client-side too. It's clean, understandable, fast, and it makes sense. It's easy to maintain, and scale my frontend, whereas I've not felt that when I've built similar sized applications with other frameworks.

Svelte, logically, makes sense to me - the API is consistent and sensible, and I can often take a good guess at how to do something without reading the docs. Having no client-side dependencies makes it an absolute ideal fit for distributable libraries too - people can just "slot" our widgets into their site, in one line.

My criticism, as somebody else voiced, is testability. I'm a huge fan of testing, and I generally look for libraries and frameworks which are test-first/test-centric - for instance I use Hapi on the backend, not Express, for this exact reason. That's not to stay that Svelte isn't testable, it's just not been a focus of the framework, and I'd really like it to be. I've had success using [https://github.com/testing-library/svelte-testing-library](h..., and it works well.

I originally built Beyonk in Nuxt but I switched over to Svelte as I had prior knowledge of it, and felt like Vue wasn't quite as nice to code in. After doing so my code was much terser, cleaner, and easier to understand, so I stuck with it and built out the other applications directly in Svelte.

I don't think I could face using any other framework after using Svelte, it would feel like a backwards step. Single-file components are a massive bonus, and scoped styles... I don't know how I lived without them.

It's worth mentioning that when I first learned Svelte (v1) it took me 45 minutes to get the basics and build what I wanted to build. I think the current v3 API could be learned from scratch by a decent frontend developer within a day. That learning curve is drastically lower than that of any other frontend framework I know, and for that reason I'm not concerned about hiring for Svelte.

I think that's about it really. I really enjoy, and in fact, look forward to writing code in Svelte on a daily basis - and for me, that was historically something I never expected to say!


I work in the software dev industry, but not as a developer. I do some freelance and hobby development. I've made prod apps with AngularJS, Angular, and Vue. My view on development is much more from a business owner and creator perspective than a career developer. So, take that for whatever you want.

I've used Svelte (with Sapper) for two production apps. One is a small e-commerce app [1] and the other an NFL stats app [2]. They are both static sites, but I won't really get into that. There is a tweet I detailed out a little bit of the second app [3].

Personally, I find Svelte to be the best dev experience I have had and it's not close. To me (like a said, a novice dev), I find myself tripping over frameworky things all the time. The only thing is that before Svelte, I didn't really realize that is what was happening. I just thought that was how web dev was.

However, when I played with Svelte, I instantly felt more productive and confident in my ability to create what I wanted. The main benefit that I have experienced is that it is so simple. There is just less to learn because it builds upon your knowledge of the basics (CSS, HTML, JS). To me, it just organizes these into a nice single file and throws a touch of template markup at you to give you what you would expect from a framework. There's more to comment on, but for brevity, I won't.

I also am just a huge fan of the compiler approach. I know that bundle size is a rather debatable topic as to what matters and what doesn't, but if I can have a great experience building a site AND I get smaller bundles (in most cases) for free, then that is huge to me. I think it is going to allow some cool features in the future, too. I just think it makes a great deal of sense to build things in this way.

The only con I have ran into, which isn't really a knock on Svelte itself, is that the community is tiny (relative to the others). The community that does exist lives on Discord, which is awful for searchability of questions. That said, the docs are great and I have had to Google far less things than I have in the other frameworks I have used, so it is less of a ding than it would otherwise be.

So, Svelte is my new default. I'll continue to fanboy over it to my developer coworkers who love React. They will roll their eyes and become filled with contempt and pity. I'll insult their intellectual capability. We laugh. All of our apps remain in React. Life goes on.

[1] https://bigcreekbarkery.com [2] https://quickfantasystats.com [3] https://twitter.com/pjbrown_11/status/1186012274164752388


‪I miss code completion and tooltips from TypeScript. Thinking about migrating from Sapper to Next with TS TBH.‬


I've posted before about my experience with svelte (https://news.ycombinator.com/item?id=20338175). Will try to reiterate a few of them here.

I've been using it internally at my current job to great effect since March, after I convinced my manager to let me try it on a one-off project. That small project has led to us using it for other bigger projects, again pretty successfully.

tl;dr – I probably wouldn't choose to go back to other frameworks after my time in Svelte-land unless I'm in a situation where I have to use React. I don't MIND React, but it's clear that all things equal it simply takes longer to make things with it and the thing I make tends to be harder to work on over time. Svelte is just too good and has probably saved my company some money in dev time & dev happiness. For reference, I work across the data stack – data engineering to stats / ml modeling to frontends / products that use data. It shines in all areas, but it REALLY shines in data viz.

pros:

- the time to first meaningful render in svelte is substantially, substantially lower than it is in React, and you face none of the drawbacks of using the React starter stuff (ie ejecting isn't a thing). This may seem like a weird metric, but I think it's pretty vital. I can easily start a side project w/ svelte and not have to think deeply about getting all the dependencies, all the webpack stuff fiddled with, all that. The ramp to productivity is pretty flat.

- you don't need the Friends part of React & Friends nearly as much, but you can definitely use the ones that are framework-agnostic (like immer, or redux, or whatever). W/ the bigger React projects I work on, I have really struggled with the development speed of 3rd party libraries forcing me to update my components and wasting time. Having fewer dependencies has made my life substantially better. Most projects I just use immer + d3 modules.

- I was pleased to discover that in practice, the boilerplate doesn't ever sneak in, even in complex components. This means that I can either (1) deliver the thing faster, and / or (2) in the same amount of time, make it that much better. It ends up being that both of those things happen.

- svelte stores are incredible. We tend to use them with immer to make redux-like app state work nicely, but we use stores for all sorts of things – contexts for complex components like data graphics (ie we need to share reactive changes arbitrarily to children), tweened and spring. One way that I enjoy using them – I take params from my app store (the one I make w/ immer) and create a derived store that encapsulates a cached dataset request. There are SO MANY cool patterns you can implement with stores that makes your app easy to reason about. Example of a svelte immer app here: https://github.com/hamilton/svelte-immer-example

- having a great story for both style & animation really makes you think that most other frameworks are feature-incomplete. The component authoring experience really makes html and css feel like first-class citizens again. I currently have a designer helping me tweak the css of a bunch of components I've written, and it's wonderful – he doesn't have to learn all the css-in-js stuff I've encountered in other frameworks.

- Svelte truly, truly shines with data visualization, where the reactivity has reduced the cost of authoring data graphics for me. I say this as someone who used to use Protovis and then spent a lot of time in D3-land. Hoping svelte gl lands publicly sometime soon so I can get off of the regl train.

- Svelte creates joy the way jQuery did in the past. I noticed a talk by Rich where he talks about jQuery. This has been how I've described svelte to folks @ my work, and they get it – it DID feel magical then.

cons:

- the testing story isn't well-documented yet, and it probably just doesn't exist yet. I tend to just move code that definitely needs to be tested into separate modules and test them there.

- typescript support would be really nice.

- the community is small, so you have to find answers yourself or make them. This may not appeal to a lot of corporate frontend devs, but it works @ Mozilla where I work, since most folks are pretty web-friendly. I personally prefer this since things that are hard in other frameworks are trivial in Svelte. That is, you just don't need that big a community to be similarly productive.

- your dev culture has to be right for this, and the risk of moving has to be understood. It takes time to figure out how new frameworks pay off.


> the time to first meaningful render in svelte is substantially, substantially lower than it is in React, and you face none of the drawbacks of using the React starter stuff (ie ejecting isn't a thing). This may seem like a weird metric, but I think it's pretty vital.

I think this is the most important metric of any JS project.

We rarely need to update thousands of dom elements per second, but all JS projects need to download and start running ASAP. Specially on mobile.

This talk was pretty enlightening: https://vimeo.com/364402896


Thanks for the link. Incidentally I have that same talk bookmarked. Though for the record, I have needed to render thousands of dom elements per second :)


Testing for Svelte does exist! See my writeup on it here: https://objectcomputing.com/resources/publications/sett/july...


Oh, great! Thanks for the link. I had it on my to-do list to try something similar to what you did. Glad to learn from someone else's exploration.


Love svelte but you desperately need an official router




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: