Svelte 5 runes: what's the deal with getters and setters?

Hey! So the other day we introduced runes which  are going to be the new way to deal with state in Svelte 5 and beyond. The reaction has been  remarkable — million plus views on the tweet, top of Hacker News, takes everywhere.  Overall, very positive reception so, you know, thank you for putting your faith in us.  Even outside the Svelte community people seemed pretty excited — every framework community was  tripping over themselves to be like hey this looks like our thing. They say that imitation is the  sincerest form of flattery but I actually think

the most sincere form of flattery is accusing  someone of copying you. I guess I should set the record straight on that front — we essentially  designed this stuff from first principles based on everything that we've learned since Svelte 3 came  out in 2019, but the intellectual context in which we did so was very much influenced by the work of  Ryan Carniato on the Solid team, so everyone else, I'm afraid we weren't really thinking about you  but I'm glad you like it anyway. That said there

were some naysayers and the bulk of the negative  reaction that we saw was basically "I don't want to have to write getters and setters everywhere",  or "this is way more code for basic things" Even the great Fireship who I have boundless respect  for got this totally wrong and that's our fault because we didn't do a good enough job of  explaining it. So in this short video I want to explain what getters and setters are why  we're using them and why it's not going to result

in you writing a bunch more code. So first up  what are getters and setters? Well imagine that I'm creating a createCounter function in regular  JavaScript. I type createCounter up here I declare a count value, I add an increment function  and then I return count and increment directly down here and then I call the function to get a  counter instance. I log counter dot count and I get zero — great. Now I increment the counter  like that and log the count again it's still

zero. Argh! What happened? Well you can see what's  happened — the count is fixed at the time we call the function, we're just returning an object  that has a count property whose value is zero, and the way that we fix that is with a get  property. So I'm just going to copy this code and this time we're going to do get count and  then I'm going to return count like that, right,

and then if I do counter equals createCounter,  counter dot count — zero, obviously. counter dot increment and then counter dot count again  — we now get one which is what we want. Now we could also have a corresponding set property which  would mean that anyone who had a reference to this counter would be able to set the value of counter  dot count to whatever they wanted, but that's not

what we want — in this case we only want people  to be able to increment this value. You'll notice also that we can't destructure the value — we  can't do const count increment equals counter. I mean we can but now if we call increment like  that then it's not going to do anything useful, we're always going to get the same value because  the the get method is invoked at the time of

destructuring. Now if this syntax is new to you  then this might all seem a little bit weird, a little bit funky. But you actually use this  stuff every day as a web developer whether you realize it or not, because web APIs are full  of this sort of thing. So here's an example. If I log out location.href I get example.com if  I set location dot hash equals hello then, oops, syntax error, then you'll notice that the URL bar  has actually updated here because we're not just