EPISODE 1728

[INTRODUCTION]

[0:00:00] GV: Stack Overflow is a legendary question-and-answer site for programmers and is likely well-known to most SED listeners. Svelte is an open-source front-end framework that was released in 2016 and continues to grow rapidly in popularity. Giamir Buoncristiani is a staff software engineer at Stack Overflow. He is also the Tech Lead for the Stacks Design team. Giamir joins the podcast to talk about modernizing Stack Overflow's front-end user interface and why the team has embraced Svelte.

Gregor Vand is a security-focused technologist and is the Founder and CTO of MailPass. Previously, Gregor was a CTO across cybersecurity, cyber-insurance, and general software engineering companies. He has been based in Asia Pacific for almost a decade and can be found via his profile at vand.hk.

[INTERVIEW]

[0:01:02] GV: Hi, Giamir. Welcome to Software Engineering Daily.

[0:01:05] GB: Hello, Gregor. Happy to be here today.

[0:01:08] GV: Yeah. Giamir, you are a staff software engineer at Stack Overflow. I don't think the platform needs any introduction to our listener base. That's what makes this one exciting today, that we get to peel-back the curtain a little bit on probably a platform that I imagine, virtually, every technical listener has used at some point in their career.

Let's also just hear, before we get into today's topic, which is basically, around using Svelte at Stack Overflow, what did you do before Stack Overflow? What was your path to Stack Overflow?

[0:01:46] GB: Yeah, sure. Yeah, I'm going to start with saying that I'm Italian. I studied computer engineering, actually in Italy and in Pisa. I was always passionate about user interface development since the very beginning. That's actually what drew me into what I'm doing today. I used to be one of these people that maintains CMS, like WordPress for small to medium businesses. That's how I started, actually. I got excited about web development in general. 

Then after my study, I left Italy. I decided to move to UK, where I actually started what I consider my first professional position. Because I was lucky enough to enter in a relatively well-known consultancy named Thoughtworks. As a consultant, really, I was able to experience a variety of domain and projects. I also got to travel quite a bit, being a consultant and work different industries between UK and Germany as well.

When I was at Thoughtworks, I actually, let's say, continue developing, right? My career as a UI developer expert I can - yeah, and this bring us to today to few years ago, where I decided, actually, to take a break from consulting and move to a product company. There was this great opportunity, where Stack Overflow's design system team was looking for an experienced engineer that could help the organization transition from, let's say, using outdated technology, really, when it comes to user interface development, to something that's a bit more modern, a bit fresh. Yeah, I was lucky enough to get hired. That's where it all started, I say.

We were able, over the last two years, I like to experiment a bit and slowly start, let's say, a journey with the organization to move towards modern front-end development. I mean, we're still in it, of course. Stack Overflow is, you can imagine the company started in 2008. A lot of the new, shiny things that we are all using today like, where did I think about that? jQuery was already around, which was great. But then, because the browser standards, they were all different from each other. Yeah. That's a little bit about myself and how I landed this position in Stack Overflow.

I'm really excited, actually, to get also the opportunity to give back to the community to an extent. I mean, probably every engineer that started around my time in the late 2000s, started with software development, they use Stack Overflow to learn and create their own careers off then. I felt that this is super opportunity that I like to feel on giving back something that I learned over all these years. Yeah, I'm still excited to be there.

[0:05:11] GV: Oh, yeah, that is, yeah, is exciting. Yeah. I mean, the number of things that Stack Overflow has solved for me, I think the first ever question I put up there was, we had a regex problem, and some regex wizard came on and talked about it being what's called catastrophic backtracking. I just thought, "Oh, my God. This is a community." You can find, literally, the most esoteric knowledge about leaders on this platform.

Even today, I still - obviously, maybe we'll get onto some of this topic, LLM and so forth, so you probably cut into how much it's used. I still find there are easily much better answers coming out of Stack Overflow than what an LLM can give me on some things. That's not quite the topic for today. The topic for today is how Stack Overflow is even built itself. You came to my attention when you did an episode for the Stack Overflow Podcast back in 2023. I mean, the word that piqued my interest was Svelte, because back, then I was also kicking off a new project, and I had decided this was now the first production project I was going to kick off with Svelte.

To see Stack Overflow talking about it, using it in production was a huge, I guess, yeah, really helped me confirm that choice, shall we say. Let's go back there a little bit. That was back in 2023, what were the challenges that you were needing to solve with the front-end, was that before bringing Svelte in? Let's start there.

[0:06:43] GB: Yeah. Many challenges. As I was saying, Stack Overflow, stackoverflow.com and the Stack Exchange Network, it's all there to understand, the software project started in 2008. Most of the UIs I like were built and are still today built with ASP.NET MVC better, and then the Razer as a Vue engine, right? The majority of our code is written in C# and .NET. Razer is the de facto Vue engine I like for C#.

Of course, that gives you all the HTML you need and Stack Overflow, especially even today, to an extent, there's a lot of static content on it and that's great. You just have some HTML and that's it. As the landscape and technology has changed, like a user has more expectation, like you start to add interactivity, to at least to certain pages, you of course need to use JavaScript, right? Of course, back then, there was jQuery, which was great, because you know all the cross-browser problem, compatibility problem that the web back then I like.

Honestly, jQuery, it's the majority of the JavaScript code, actually, that we still have in our code base. Stack Overflow was developed as a monolith. As of today, today we are actually on a journey of breaking down that monolith towards a more distributed architecture. But still, as of today, I would say that the core stuff, like, oh, Stack Overflow still lives within this monolith.

Yeah, just an interesting fact. NPM and Webpack, which is something that, I mean, today there is also [inaudible 0:08:36], actually, Webpack just feel already old to an extent. But they say, NPM and nodes and bundlers, right? They are tools that are probably using in any front-end project. Stack Overflow, we didn't have those until 2021. We introduced those tools and those bundle quite late. But those was also the effort that put us in a situation where we could start to explore more modern approaches to UI development. Also, ultimately, what allowed us to introduce Svelte for in some part of our codebase.

In terms of challenges, we actually listen to our engineers, and how it was, their experience working with building UIs in general. What we realized is that 65% of our engineers, actually, back in January, 2023, was still using jQuery as the primary tool to add interactivities to UI. Almost all of them, they were considering the tech at their disposal not adequate. Maybe, in part of the, let's say, front-end platform team, to an extent, we were responsible to actually change that, try to change that, and bring some modern tool to those individual that are essentially building stackoverflow.com, as you see it every day in highlight, I'm a product engineer.

Also, they were other benefits that we were hoping to gain by introducing something more there. Last but not least, I would say, attracting and retaining front-end talents, right? Because, of course, you can imagine and say, "Ah, Stack Overflow is great," but when you actually join a company and say, "Okay, all the UI development is done in jQuery." As a front-end engineer, you just say, "Okay, do I really want to be here? Does it make sense?"

We just wanted to make sure to introduce also pathway, right? Get people excited about UI development again, and don't start to see UI development as a chore. Like, okay, now I need to build some UI, and it's going to be in jQuery, and you don't get all this type benefit using TypeScript, for example. Yeah, so this is the situation that we were in, right?

[0:11:08] GV: Super interesting. I mean, I guess, what strikes maybe me from the outside is that it doesn't feel, and this might already sound terrible to someone working at Stack Overflow, it doesn't feel like the platform, and this is a positive thing, has needed to change much over the years.

[0:11:25] GB: Yeah.

[0:11:26] GV: I'm not sure if that - maybe, do you think that drove some of the stasis, I guess, is what you were describing of like, why would we need to change it? If it ain't broke, don't fix it, kind of thing. Actually, it was the developer experience that - the internal developer experience that was driving more of this, perhaps.

[0:11:43] GB: Yeah. I think it's a combination of things. The people developing Stack Overflow has been always a relatively small group of engineers. I would say that, most of them, they consider themselves full-stack engineers. The majority of our engineers are very experienced with .NET and C#. Funnily enough, the other day, I was looking at some .NET MVC tutorial, and just did recommended to use jQuery as a tool of choice, to actually add some interactivity to the razer pages.

That's probably also why there was never a thought of saying, maybe we should just move on, right? That's one part. The other part is that stackoverflow.com and Stack Exchange Network, they're very mature products. Our community really get accustomed to certain feature the way the work, and changing things in general, I just do big re-hold of how things work. It's not simple, right? Because you need to make sure that you get feedback from the community and you don't do anything abrupt.

At the same time, though at Stack Overflow, we are not developing just what we call the public platform, like what you see every day if you go to stackoverflow.com. We have also other products. Those were the products that I feel, they were suffering a bit more as well, because essentially, in there, we would be building private instance of Stack Overflow for different customers, and you can imagine that the pace of innovation that need to be much faster, because expectations are a bit different.

Thinking of innovating around UI with the technology, such as jQuery. I mean, you certainly can do some stuff, but it's a bit difficult. Maybe later, we will go and talk a little bit more about the differences between jQuery in this procedural way, of actually describing your UI, right? Passing all these imperative instructions, as opposed to what we got used to these days with the component-based framework. This is not just Svelte, but any of the new UI framework that allow you to be more declarative when you describe your UI.

That's a little bit the background, I guess, of why there wasn't maybe a big need life, or something shiny, and you went. In general, I had to say that if you're not into the UI ecosystem, as an engineer, let's say, you look at what's happening in the JavaScript world, and you feel these people are crazy. They're just innovating so much. Everything's changing every other week, right? Today, we have Angular JS, the day after there is React, and then now, we have Vue, Svelte. I mean, things have gotten better, I would say, and have stabilized a bit, but as a maybe more backend type of engineer, just say, "Maybe I should just stick to my old-fashioned jQuery and stay on the safe side."

[0:15:04] GV: Yeah, I think that's a great point. There was a period, it was moving almost too fast, you know? I mean, great to innovate, yes, but if you can't wake up another week, and there's now another framework, and someone else is saying, "Oh, why don't you use this, or why don't you use that?" I think we've had a few episodes where these discussions have played out of the problem, as you say, it has got a lot better, but the problem with front-end for a long time was just simply too much choice, what to choose, and defend that to whoever is asking you to build this thing.

I guess, I was lucky in this respect, but when I chose Svelte, I was choosing it as the founder of the company, so I can - I've only got myself to blame at the end if it was the wrong choice. But I was really persuaded by a fairly old video now. One of the first videos that Rich Harris, the creator of Svelte put out. I was really persuaded by the argument, basically, that video was all about how Svelte works under the hood and that it compiles, rather than re-rendering it on every millisecond.

Okay, we understand why Stack Overflow had to at least look ahead and try and say, "Okay, we need to innovate on the front-end, not across the entire product. That's too much." But in certain areas, how did you land on Svelte, in this case?

[0:16:20] GB: Yeah, that's certainly an interesting story. Because we, initially, there was so much option. As again, an example of the JavaScript fatigue, you could have gone with the classic, I think, in most organizations today they use React, or maybe Angular, if you're more into the, I don't know, enterprisey type of industries. But yeah, we actually took our time as a front-end platform team. We did a little bit of discovery, understand the things that also were important to us, like, from our architecture characteristics, and what we wanted for Stack Overflow, also talking to the other engineers.

Few things that I can mention is that we certainly look at developer experience. We wanted to make sure that when somebody would actually build something in Svelte, with this new UI framework that wasn't really specified, then they could just have a great developer experience within their IDE. They could iterate very fast and use leverage, all the nice things that if you are in the UI development space, you take for granted today, things like hot reloading and this kind of stuff, you develop something, you change some code over here, and you don't need to even click refresh on the browser, it just updates automatically.

We wanted that, because you can imagine, the experience in what we call our monolith, core monolith, when you change something on, I don't know, on some JavaScript file, it's a bit slow. The feedback loop is a bit slow. We wanted to improve that. I already touched upon the fact that we wanted to make sure that we are able to retain and also hire people that are a bit more specialized, also on UI development. Last but not least, we also look at easy of learn, because a lot of our engineers, they consider themselves full stack and they need to be able to pick up these new things, without having to burn themselves out.

I know that there was some strong opinion across the organization about, "Oh, just don't let me learn Angular, or something like that." Everybody had an opinion, to an extent. We try to stay objective. Then, last but not least, the footprint and performance of the action framework. We did few POCs, actually, and I think the two candidates, where we actually explore more things in the island were left, were React and Svelte. After the results of the POC and also, thought came, have an internal front-end guild as well. After a few discussion, we decided to move towards Svelte, even if it was a little bit of the world choice in the sense that, "Oh, React is very established. This a super huge community."

There were a lot of positive aspects on React. The bulk of my experience is also with React, a bit of Angular. Svelte didn't do much, but I was excited about certainly. I like, because, yeah, to understand the cool kid in town and brings a lot of interesting approaches, I like to how to do UI development. We landed on Svelte, because we were able to keep lean payloads for our user. That wasn't one thing. Svelte, it doesn't have really a runtime, while for React, you always need to ship some initial stuff. We knew that we were introducing this technology, yes, for our, let's say, products that are maybe a bit more internal, but we know that we wanted this stuff also in stackoverflow.com.

Actually, the POC that we do, we did against the website where we have most traffic and how it would affect the user experience. In fact, if I take a step back and actually look at what happened today, we have many, we call them Svelte Island. Maybe we will go into that in a second. We have many Svelte Island already running also for stackoverflow.com. It was a good choice on the front. I should just make sure that we didn't bloat our user with a bunch of JavaScript and needed to be executed all the time.

Another deciding factor was fast startup time. When we compare React and Svelte, we realized that React was taking longer, even for simple things to actually start up and render the UI, as you say, with its own things and render the UI client side. While Svelte was way quicker on the front. Svelte is also well-suited to auto-custom elements. We are on a journey at Stack Overflow, as I say, to move from, it's a centralized architecture. We have this big monolith. We want to move towards a distributed architecture, where we will start to have services, microservices, whatever we want to call it, or a service-oriented type of architecture.

Those services, they are also already start to have their UI. You will have, I don't know, a service responsible for a specific search experience, let's say, and that service will also have its own UI deployed alongside the service. This UI don't need to then be integrated in the rest of the experience, on the rest of the, on an auth application, on an auth page. In order to do that, we wanted to make sure we had a possibility to use a standard, such as web component, just to stick to the platform as much as possible.

I would say, the last things was also that, Svelte is being loved by our community as well. We look at a little bit of that. Every year, we're doing this Stack Overflow developer survey. He has been scoring top on satisfaction and productivity in that survey, but also, not the survey, in all other surveys. The community seems really to enjoy working with Svelte. We thought, yeah, okay, that's probably, it was the cherry on top, right? I would say, okay, let's give these things a try. So far, so good. After one year and a half, more or less, everything's still working, working fine and it's great.

[0:23:05] GV: Well, yeah. I'd love to get into that, just to reflect on what you just said there. Although, by no means did I go through as deeper processes, obviously, your team had to decide on which one. It's funny, a couple of things you said there reminded me also why I went with Svelte at the time. One, for example, was I was actually most familiar with Vue before Svelte, as opposed to React. The last time I'd been using Vue was more, I believe it was a couple of years, as in I had a break of pure programming where as a lot of CTOs have to, and you have to go do a ton more management than you may be expected.

When I stopped, Vue 2 was very much the current version. When I came back to things, Vue 3 was there, and I was like, okay, so I'm going to have to - my understanding at the time was it wasn't a great learning curve between two and three. I was like, I'm going to have to learn something here anyway, so I've got a choice. Do I learn Vue 3? Do I learn Svelte? I just thought, after the Rich Harris video, and also the surveys, I also saw the surveys, I was actually, I think, looking at the, just the state of JS survey that comes out every year. Svelte had been scoring, I think, for three years in a row, very highly. Adoption rate had stayed really quite high as well.

Yeah. I said, look, I'm going to do a day of Svelte. If after that day, I'm happy, this is the one to go with, and I was very happy, basically. It is just such an easy learning curve, I've got to say, when it comes to having sure learned React, didn't particularly enjoy it. Vue, did enjoy using Vue. But for sure, Svelte was the easiest learning curve of the three, and just is the most enjoyable. That is, reflects everything, I think, you just said.

[0:24:49] GB: Yeah, absolutely. I think we need to give kudos today to the community as well, because they did, and they're still doing a great job with their interactive tutorial, I saw. It was also for us. Stacked very easy. To pick up Svelte, and also to help our engineers to learn. I like it's this fun way of learning something new.

[0:25:09] GV: Yeah, for sure. Yeah, let's just dive a bit into where is it being used, and how did it get rolled out? I mean, I think back in 2023, when you talked about this on the Stack Overflow Podcast, you mentioned this very interesting concept of interactive islands. That was borrowed from another framework. Maybe you could just speak a bit to that, because that was pretty interesting.

[0:25:34] GB: Yeah. We internally, we created this - we needed something to easily convey to our engineers different ways of doing things. We decided to go with the interactive islands, to actually, sometimes we call them also Svelte, interactive islands, to describe island of interactivity across our big website, where Svelte in this case takes over, and essentially becomes responsible to render that path. Those islands, despite they're called island, they can be as big, or as small as they need to be. Of course, we borrow this term from us, because the asterisk is using the term island, but it's not exactly the same concept that we're using internally at Stack Overflow.

Essentially, for us, there are client-side render components that can be plugged into any of the monolith Vues. As you can imagine, we had to bring in the pooling to support the engineer, to create island in a fast way. Because we cannot expect the individual engineer, or individual product team to just go off, install Svelte and figure out how to integrate it within the internal Vue. We had to do some work as the platform team to enable the engineers to start building with Svelte.

One of the things that we created, it's also a package that we call island script. This is inspired by what, now I'm thinking about create React App and React Scripts. Essentially, it's bundling a bunch of sensible leave for life for our organization, and it creates a CLI that developers can use within their own island. As an engineer, today at Stack, you have a choice. If you want to build a piece of UI that is highly interactive and you want to use a modern way to do so, you can use this CLI, this island script CLI, that will generate for you initially, like a little bit of boilerplate and a root component. But also, will add a bunch of nice things, such as prepare you for testing as well. Testing front-end is something that we also not doing so great, like stuck, and we certainly wanted to improve that.

We took this occasion and say, okay, now we're using our component-based architecture. It's much easier for you to test your components in isolation. And also, all the nice things that comes with in modern front-end development. Prettier is there, so we have a four - you can just run the format command and they will format all the code base and then linters. Last but not least, a standalone mode for island, which is probably for many other engineers, the most exciting things, because it allowed them to start developing the UI in an isolated environment, without having to bring in the whole crazy monolith that is around. You can just develop much faster and then you can use hot reload. You can mock if you want, like API call site to go even faster if that's what you want to do. We introduced mock service work to do that.

Imagine it as some sort of a package that keeps you nice, let's say, sensible default. I like to start developing Svelte within the context of Stack Overflow, of course, like our code base. Maybe, I should also say that it's not that all our UI today is built, or will be built, that we didn't have the ambition of just saying, okay, now everything is built across all Stack Overflow. It's just where it makes sense, like we are building those islands.

On the other end, we still have razer views, right? Sometimes your static content and it makes sense to continue using server-side and the razer view. One thing that we've done that, though, is that we have agreed as an organization to don't use jQuery to build new UI. We won't be able to, of course, migrate all our jQuery, because, as you can imagine, it's thousand and thousand of lines of code. One thing we did recently, though, is upgrading to the latest version of jQuery, which was a very interesting project as well. This is exactly, we went through the effort, because we know that we have so many views. You can think about our moderators. It's simply not feasible to migrate everything. We decided to actually to, at least though, put ourselves to the latest version of jQuery on that front.

For new UI, for new static, let's say UI, we recommend to, of course, continue using razer views. If you need to add some sprinkles, some interactivity on those view, we're using a stimulus JS for that, which is part of the hotwire families been developed by Basecamp. It's an evolution of jQuery, of this procedural way of this adding interactivity to your UI. I think, maybe some people here in the past knows HTMLX, because it's probably, at least in our latest sub, I think it's called very, very well, HTMLX. Stimulus is, I would say, it's similar to an extent, where you can - HTML, SD, your core, things that you deliver and then stimulus is able to hook into this HTML and just add sprinkle on top, like some interactivity. Which is great and provide guardrails, a little bit more guardrails to engineer, to add these interactivity.

Instead of just going off and either do vanilla JavaScript, which is okay. We're okay, of course, having people do vanilla JavaScript, or just go with jQuery and being a similar position, when you write this procedural code.

[0:32:08] GV: Yeah, super interesting. I love the, I'm just going back to standalone mode, like that, or standalone. I don't know, it was a mode, I think you called it, but just that concept of being able to basically, just develop components with the data marks, but just be able to play around with it in isolation. That's super fun. Just looking at where is it used, I guess today, I think back in 23, you were already talking about AI initiatives that it was being worked with. Maybe, let's just focus, what were they and then in that time, obviously, AI, just that catch-all term has just only got bigger and bigger and bigger. Now here we are about eight months later, talking again. Where is Svelte now and where are those AI initiatives, like what are they? Yeah, I'd love to hear about that.

[0:32:59] GB: Yeah, absolutely. After introducing Svelte and we did some internal training for our engineers and then we started to see the number of islands going up. Then at some point, I think it was around September, 2023, when we say, okay, now it's a good time, to get some feedback. We ask our engineer, okay, how was your experience so far, using Svelte? I get that things improved. We realized between other things that, well, there was a 43% decrease in usage of jQuery, which was great. If you remember, I said in the beginning, that 65% of our engineer, they were still using jQuery in January, 2023. That was good.

Another interesting thing was that pretty much all of the new overflow AI, this is how we call these products, these category of products features that were implemented in Svelte, right? Because as you can imagine, back then, we were also in a phase where we were experimenting and try out multiple, multiple things. We were trying to learn as well as an organization. Having the tool available to an engineer, it couldn't come at a better time, because it just feel like, "Oh, I can easily experiment and create a little chat here that people can use that to actually refine their answer and stuff like that."

Today, overflow AI has evolved quite a bit. Still, most of our features of overflow AI, this is the UI, of course. It's written in Svelte. One notable mention is certainly our IDE extension. We have an IDE extension that is built entirely in Svelte for Visual Studio Code. In our, let's say website, we have several feature for our Stack Overflow private instances that are leveraging AI to, for example, do summarization like, of when you search for something, we provide summaries of the content that companies have in their internal instances of Stack Overflow.

I should also say that we are slowly, also, the public platform side of things rolling out as we speak some features that are based on Svelte. I'm not sure if you are familiar with staging ground, which is one on - it's essentially like a feature that has been introduced to lower the barrier for engineers that want to participate in the community to actually ask their first question. The staging ground, or at least part of staging ground is implemented, will be implemented using Svelte. Because it's pretty dynamic, right? You can imagine that it's an ask, we start to say, "Here, you should have your title, and then some suggestion can come in."

It's the path that type of UI where you don't want to have some HTML sent to the server. Then you have to write a lot of imperative procedural code to say, okay, if the user type this, then do this call and then change the HTML over that. It just becomes a little bit of a mess, right? I know that the teams behind staging ground, right? It's certainly going to use some of our new Svelte capability. Yeah.

Maybe the last thing that you mentioned is about our move to as a tech organization, as I already mentioned, we want to move to a more distributed architecture. We are at, let's say, at the beginning of this journey, where we're trying to break out some services out of this monolith, certainly in those new services, we expect people to use Svelte, unless, they have services that they just render some static content. Like in that case, a razer is still an option, of course. Otherwise, we recommend to use Svelte. As a platform team, we're helping out engineers to actually start up with Svelte.

We have also our first Svelte kit projects that we have done. It was part of this new services. We recently had an accessibility initiative to improve accessibility of all our products, and we have created a public dashboard and a whole project has been built using Svelte kit from the ground up. Yeah, and it was a pretty successful project. We were able to actually go pretty quick, compared to some other things that we do. Happy to see that.

[0:38:00] GV: Great to hear just how, obviously as you said, I think, towards the start of the episode, it's been a success, and being able to bring into more and more aspects of Svelte, and just you mentioning Svelte kit there, yeah, that's what I've ended up using as the front-end architecture for the product I'm working on. Also agree. It really works. A good call out on the accessibility. I think that's something that Rich Harris has clearly made a big point of from day one. Anytime a component isn't complying, you get a ton of squiggles and some slightly tongue-in-cheek error messages saying, "Why are you not doing this? Come on."

I think that's the best way to approach is the framework itself should be really trying to force this at the developer, because it cannot be ignored. That's super exciting. Loaded question, but Svelte 5, what's the thought on upgrading?

[0:38:54] GB: We're already talking a little bit internally about this. Of course, we're still not quite there yet, because first, I guess the official release that need to be out, and then we, as a company, we would probably wait a little bit and take a few months, maybe, to check that everything was fine. There is a lot of excitement internally, honestly, about Svelte 5. Especially because it's going to address some of the issues. I like that also some of our engineers have reported when they were using Svelte for the first time, they're calling their issue. It's just like, things that make them a bit uncomfortable, and they weren't so explicit.

One example I can certainly give, is just the fact that as of today, in order to declare props in Svelte, you just need to use the syntax. They make you think, okay, just to have let, and then the property and that becomes automatically a property, it's how you define a property. I think the runes API, it makes things be more auspicious. Similar story for the state as well, right? It makes, with these runes, it's making things a bit more explicit and also, eliminates the dollar label that was confusing for also, a lot of our engineers, which their activity model is getting an upgrade, and we are really excited to test it out.

We appreciate as well that they will give us also, quite some time to migrate things, right? Because for companies like ours, stability is very important and you need to provide a solid migration pathway. The fact that we can - they ensure that things will work in Svelte 5, the same stuff that you brought your Svelte first still work. This is pretty important, because I remember back in the day with AngularJS and Angular 2, that was a little bit of a nightmare. To understand that some stuff, or some project that I've been on that never been upgraded, like Angular 2, because it's just Angular 2 plus, because now we are, I don't know, Angular 16. I lost count. There's so many releases of Angular.

Some companies still, they weren't able to actually catch up with the framework. Really appreciate the value stability. It's really important to us. It give us the confirmation that we've done probably the right choice. Because they are behaving, like the core team on Svelte is behaving as a lot of company relies on them, right? They cannot just flip a switch and say, "Okay, we migrate all that once." We appreciate that.

[0:41:53] GV: Yeah, absolutely. I think that's a very good call out. The backwards compatibility that has been stated between five and four, that is huge. I think, again, I could be misremembering here, so I apologize to any listeners who are listening to this and saying, "This is completely wrong." I do think part of the problem with the Vue three and two, they had some of those issues as well, where our component was just so dramatically different between the two. Lessons have been learned, I think, is the best way to put it, where, especially React has gone through so many different stages of this. Whether it's just not compatible, or introducing very strange concepts that then get rolled back after a bit of time.

Yeah, unfortunately, I've got to say, I just think, I think React is the worst offender here in terms of with the modern frameworks, in terms of things that they could have done to make - moving through the upgrades less painful. I do appreciate that Svelte takes a slightly more, I would say, mature approach to what that should be. Yeah, I mean, Giamir, thank you so much for making the time today, and just, I'd say, getting to see behind the scenes a little bit on Stack Overflow and Overflow AI and the products that you guys are putting out. Maybe in another six months to a year, we'll catch up again and be talking about Svelte 5 and how that's going.

[0:43:07] GB: It was a pleasure to be here. Yeah, I think there is a lot of exciting things going on on Stack Overflow. I think, we are starting also a bit on a micro front-end journey now. It's interesting how Svelte then play out in that type of architecture as well, because we're just now starting to learn how Svelte will play out in this type of architecture. Yeah, maybe we'll talk again, sometime from now.

[0:43:33] GV: Absolutely. Anywhere people can, I don't know, follow you or, do Stack Overflow plays, do they have Stack Overflow accounts that they actively answer lots of questions on, or anything?

[0:43:45] GB: Yes, we do. But I'm not a very social media, let's say, person. I mean, I have a - for sure, I have a Stack Overflow account. Doesn't have a lot of reputation points. I should probably spend a bit more time answering things. Yeah, I'm also, this day, I guess, is X, Twitter, whatever you want to call it, handle @Giamir. As I say, sometimes I post some stuff, but as I say, I'm not a social media person. Then I have a website, giamir.com. When I do conference talk, or something like that, if you're interested, you can find me there.

[0:44:18] GV: Perfect. Well, as I hope to catch you again in the future. Thank you so much again for coming on.

[0:44:23] GB: Thanks.

[END]