Giamir Buoncristiani, tech lead for the Stacks design system at Stack Overflow, joins Ryan for a conversation about all things front end, including how he joined Stack with a mandate to modernize the front-end user interface and why Stack Overflow developers are such big fans of Svelte.
Giamir is the tech lead for Stacks, Stack Overflow’s design system.
Svelte is a tool for building web apps. Delve into their docs or, if you’re brand-new to Svelte, start with this interactive tutorial.
More than 90,000 devs responded to our 2023 Developer Survey where Svelte was ranked the second-most admired web framework.
Connect with Giamir via his website or LinkedIn.
Today we’re shouting out a topical question asked by Félix Paradis, who (like 73,000 others) wanted to know How to pass parameters to on:click in Svelte?.
[intro music plays]
Ryan Donovan Hello, and welcome to the Stack Overflow Podcast, a place to talk about all things software and technology. My name is Ryan Donovan, I edit the blog here at Stack Overflow, and today we are talking about Svelte and how we're using it and how we're moving certain parts of our UI to it, and how we are developing our AI systems using Svelte. My guest today is Giamir Buoncristiani, a Senior Front End Engineer and Tech Lead for the Stacks Design System here at Stack Overflow. So welcome to the program, Giamir.
Giamir Buoncristiani Hello, hello, Ryan. Thanks for having me. Looking forward, actually, to having this chat with you about Svelte and what we've been doing with Svelte at Stack Overflow lately.
RD So at the beginning of these episodes, we like to ask our guests who they are, how they got into technology, and to give a brief overview of your career up to this point.
GB Sure. So I'm Italian, I'm originally from Italy. So I actually studied in Pisa, I come from Tuscany. That is where I did my study in computer engineering. And then in my early twenties, I actually moved to London in the UK and that is actually where I learned about stream programming, something that they don't teach often in university, so agile pair programming and all this good stuff that helps us write good quality software. And therefore I decided to do actually a bootcamp there, a four-month intense bootcamp that introduced me to, I would say, my first professional software company, which was ThoughtWorks. So ThoughtWorks is this global technology consultancy that I joined seven years ago, and there I became a UI subject matter expert over time. I was there for around seven years, and last summer actually, I thought I wanted to take a break from consulting, and there was an opening on the Design System team of Stack Overflow and I thought that would be a good occasion for me to join a product company and help out at the same time the global developer community. So I was lucky enough to get hired, and part of the job description for that opening was that Stack Overflow wants to modernize a little bit how we're doing front end development, and I guess this is one of the reasons also why we are here today talking about Svelte. It’s because we've done some work in the past year in my team to enable the product engineering organization to build UIs in a more modern way.
RD So you say that they wanted you to come in and modernize the UI, the front end. What was the UI landscape before you came in?
GB So Stack Overflow now is a more than 15 year old company, and being a tech company, primarily the development is being done in a monolithic .NET application. And talking about front end, Razor has been the view engine, if you want to go a little bit more into the technical detail, that has been used across the organization for many, many years. And for creating the little interactivity that was needed back then in 2008, of course jQuery was used because it was the de facto technology back then, and I think it has done a great job as a library to bring us where we are today in terms of front end development. Now over the years, things have changed and with the introduction of Node.js in 2009, there's been a lot of tooling that has been created for front end development and the developer experience has evolved a lot. And at Stack Overflow, while there were some projects here and there where there was an attempt to migrate to more modern approaches and perhaps introduce some more modern tool, in the monolith application that we call ‘core’ here internally, jQuery was still, even when I joined, the primary technology used by engineers to essentially build user interfaces. So we had these challenges and we had to actually come together as an organization and see what we could do to set us on the right track to build UIs in a more modern way.
RD I feel like the last 15 years have been kind of a golden age for front end frameworks. That's the era of Angular and React and all these others that have been created in that time.
GB Absolutely.
RD So what are the sort of front end paradigms that have been introduced that Stack Overflow wasn't taking advantage of?
GB So I would say that primarily what we've seen with the introduction, I would say React was one of the first frameworks that popularized the component-based architecture on front end development. And this was something that at Stack Overflow wasn't done quite yet, so it's something that when we went out and said, “Okay, what can we do to introduce this component-based front end architecture at Stack Overflow?” it's something that we considered. And as I said, React was the first one, and then I guess all the other frameworks. There was AngularJS and then we all know what happened between AngularJS and Angular 2. There was some breaking changes and Angular 2 actually started to use also a component-based kind of architecture. And then we had Vue and all the frameworks later on that all leverage component-based architecture because it's a good model to describe user interfaces. So that's what we were after, I suppose, when we started this discovery for a new framework.
RD Yeah, it's all very modular. Do you think it follows the same sort of back end mindset where everybody's moving to service architectures?
GB I would say yes. Certainly there is an aspect of encapsulation that comes with this component-based architecture. So what a component allows you to do is to describe all the things you need essentially in a nice big box that can be shipped. So you have your HTML, your JavaScript that helps you with behavior, your styles, all in one block that then can be rendered whatever you need. So there is this nice concept of encapsulation, and in a way also in the backend there is a lot of talk about modularization and microservices and whatnot, the idea of creating these components that are tied to a specific domain of your business, and then being able to think about them in an easy way because you kind of have everything scoped there and you don't have a lot of cognitive overhead as an engineer.
RD And I think what initially caught my eye is that you did a survey of the front end developers working on our new OverflowAI stuff, and I assume they were given leeway to pick whatever tools they wanted. Is that right?
GB Yeah, absolutely.
RD And 100% of them were using Svelte.
GB Yes, that is correct. So we were kind of surprised on my team. As you said, I'm part of the Stacks team which is the Design System team here at Stack Overflow and is also the custodian of all things front end to an extent, so we are also an enablement team for the other teams. And we introduced Svelte and I think that was around April/May, and we were impressed how quickly teams jumped on this new technology to experiment and prototype all these new OverflowAI features. So one of the things that a framework like Svelte actually brings to the table is fast experimentation, a fast time to market. When you have to try out an idea fast and see if it works, it's a really great tool compared to maybe a more complex architecture. So we were very surprised in a nice way that engineers jumped on it so quickly.
RD In our last developer survey it was one of the most admired frameworks, and I think it was very new on the survey. So what is it about Svelte that makes it so lovable?
GB I would say it's simplicity to an extent. So what happened from 2009 until now is that we've seen a lot of frameworks coming into the market. If you think about especially Angular, there are a lot of frameworks that are quite heavy and there's quite a bit of a learning curve for engineers to get productive with it. And here at Stack Overflow especially, we have a lot of full stack engineers, so we have cross functional teams where engineers need to be able to do a little bit of everything, not just front end things, so they don't have the mental space of just learning a full-fledged framework. So having something a little bit simpler to get closer to the actual standard of the language, so HTML and plain JavaScript, but just sprinkle on those concepts a little bit of reactivity. At least for our engineers, it was actually what was so appealing over a technology like React, which is pretty popular, which we also considered by the way. When we actually came out we had to make a decision on which framework to pick, it’s certainly a little bit more heavy. So while it might be a bit easier for people that already know the concept, and maybe to an extent it's even easier to find React developers in the market, for engineers that maybe are a bit more specialized in the .NET ecosystem and C#, it might have been a steeper learning curve. So that's one aspect. The other aspect, of course, is performance. And here at Stack Overflow, we have these massive sites that we need to maintain. We have so many people visiting our website every day, and we certainly don't want to send to the user a lot of framework code that is not really necessary. So the fact that Svelte comes with this runtime-less concept, so it doesn't have a runtime, was quite appealing to us. And we also did some proof of concept to see how introducing the framework will impact some user metric, and we saw that it is better. Compared to React, for example, it was performing way better and that was another factor as to why we decided to go the Svelte way rather than maybe a bigger framework.
RD Yeah. In just glancing at the Svelte site, one of the things I noticed is that it has a build process and it feels like a lot of these languages that were interpreted no-build process are now moving towards build processes. There's a language built off of Python now called Mojo that's moving to a compiled binary. Do you think there is simplicity to just building it to the basic building blocks?
GB Yeah, I think one of the cool new things that Svelte brought to the table back when it was introduced was the fact that it was doing most of the job at build time, as you mentioned. So that was essentially allowing the tool to ship at run time. So Svelte in a way sometimes is described as its own language and it has a compiler, so the code goes through a compiler and gets optimized before actually the code gets sent right to the final user. So it's certainly a trend that we are seeing at the moment. I know that also other frameworks including React have people within their core team that are experimenting with reducing their runtime and just trying to do as much as possible at build time so that the final user experience is not impacted by the JavaScript that need to be parsed into the browser of our user.
RD And we're a very international site, so I think taking into account the various network loads and performance capabilities of people around the world is pretty important.
GB Absolutely. And we have introduced Svelte specifically to address the parts of our UI that need to be a bit more interactive, but the whole architecture of Stack Overflow is still a server side rendered architecture so we essentially try to do our best to serve the content to the users in the quickest amount of time, even if they necessarily don't have JavaScript activated or something like that. It's just that when you get to these parts of our website that are always evolving and need interactivity, then it's where we actually recommend to use something a bit more modern like Svelte. So we actually borrowed a concept from Astro, which is another player in the front end world, and we started to call these interactive things that are in our website ‘interactive islands,’ and those are the parts that are actually implemented in Svelte with client-side rendering.
RD So I thought this was just for the new AI stuff, but it sounds like this is going to be everywhere on the site. Is that true?
GB Yeah, in fact, it's already the case. We already have a couple of islands where some stuff has been migrated because it was written maybe in jQuery and other technology, and the engineers actually wanted to migrate to something that becomes also more testable. I think one of the niceties of introducing such a framework, such structure to our codebase, is that we can start to test better what we are doing, while the classic approach, coming from the past where you just sprinkle some jQuery or JavaScript just into the page becomes a bit tricky to test. You can test it generally only when you do this kind of end to end test where you just assemble everything together, bring everything up, and then test it. The fact that you can have this component-based model allows you to test in isolation a bit better, which is of course a tenet if you want to write good quality software.
RD Yeah, I know that's something we've been moving to. We did an article with another engineer here, Wouter de Kort, about how we're improving our unit testing, so it's interesting that that's applying to the front end now too.
GB Absolutely. Because when we want to create these highly interactive experiences, this requires coding. And the more code you write, you want to be able to test this code.
RD So like you said, it's a pretty venerable code base, a big monolith, 15 years old. How did you go about integrating it into the existing code base?
GB Yeah, that was something that for us was very important. We didn't just want, as more of an enablement team, a platform team, to just come up with documentation and say, “Oh, we think that Svelte is going to be a good tool for us.” We actually wanted also to come up with some guidelines and guardrails and some tooling to support our engineers starting to adopt Svelte in our code base which is very big– as you say, it's 15 years old now. So we came up with this concept that we started to call internally ‘interactive islands,’ where essentially engineers now can create these Svelte components in an environment where they will get access also to all modern tools such as linters, formatters, testing is another thing that I mentioned. So we created something that internally we call an ‘island scripts package’ that allows engineers to spin up a new Svelte island quickly. And essentially then these islands can be plugged whatever is needed in the website. So these islands can be sometimes as big as a whole page, but also as more or less a component on the sidebar or something like that. So that's up to the engineers how they want to do that. There are some trade-offs, of course, as always in software architecture, that you need to make when you're developing a feature. If you need to develop something very interactive, you probably want to go and build an island. Otherwise, you might want to stick to the old pattern of having everything rendered server side by Razor, because our primary UI technology is still Razor because we have this MVC approach for our UI.
RD Okay. So can you say if this has increased or decreased the amount of code we're shipping to users?
GB You mean with the introduction of Svelte? So it depends, as always with software engineers.
RD Classic engineer.
GB Yeah, exactly. We always say it depends. So I'm saying it depends because it depends on the feature that you are actually building. We picked Svelte specifically because it's one of those frameworks that doesn't introduce a lot of bloated stuff to the website. So we wanted to keep the website as lean as possible, but as always, if you have the possibility to just render static HTML and don't pass any JavaScript down the line, that's what will always be less bloated. So I think it's about tradeoffs, and when we talk about performance in the context of all these front end tools that are out there, Svelte certainly shines compared to the competition, or at least the major competitors such as React and Angular.
RD So how was the move taken by our engineers? I know we have some folks who are nearly as venerable as the site.
GB Yeah, that's a very good question, actually. So there was a little bit, at least in the beginning, of I wouldn't say necessarily skepticism, but especially from the people that have been at Stack Overflow for many years and they've seen the attempts of introducing certain technologies fail, they were a bit careful about all of this, but I think that we've done a decent job to bring the whole organization on a journey together. So we started actually from establishing a front end guild, which essentially you can imagine as a group of people that are passionate about a specific topic, in this case about front end, and then taking it from there, understanding the pain points that the engineers were having, and from the get-go really always questioning what makes sense for us as an organization. So for example, I come from a background where I never used Svelte before so I had to learn quite a bit and do quite some research actually picking up this technology. I come from a background where I used a lot of React, a lot of Angular, and also some other more esoteric technologies, but I didn't use Svelte. And we ended up picking Svelte, so I didn't come in and say, “Okay, now we're going to introduce React.” So we went and experimented, did proof of concept, and we saw that Svelte was nicely integrating in the context that we have today, and that helped a lot for the engineers to jump on board, even the ones that were maybe a little bit more skeptical in the beginning because they've been here maybe for 10+ years and they've seen things done always in a certain way, let’s put it like that. So change is difficult but it's also necessary.
RD Sure. They also know where the changes have been attempted and where the failures have happened, right?
GB Absolutely.
RD So I know our design system is open source– stackoverflow.design. So is that being migrated to Svelte as well?
GB So the short answer is no. The design system is just a big word that essentially describes a little bit of the story of how an organization builds UI, let's put it like that. There are different artifacts that are part of our design system. In terms of technical artifacts, we have our primary design system, our primary library, is an Atomic CSS library, so something comparable to Bootstrap or Tailwind today, where we have these Atomic classes and also we have CSS classes also for components. So that will stay the same, it won't change. What will actually change and what we will start investing in is what we call a Svelte component library. And because our design system is called Stacks, confusingly enough, Stacks with an ‘S’ at the end, we will invest in a Stacks Svelte library, which essentially will enable engineers to assemble UI even faster than just with the barebones CSS classes. So that's what we are investing in right now these days.
RD So besides that, what's the future hold for Svelte at Stack Overflow?
GB We are at the very beginning, but we are super excited about the choice we've made. We are excited about what we're seeing also in the Svelte community in general. So there is the Svelte 5 major release coming up that is actually going to address this concept called Svelte Runes. Some of the actual things that engineers have complained a little bit about, which is reactivity in Svelte, can be a bit confusing at times compared to other frameworks, so we are really excited about that. And we are also starting to experiment with SvelteKit which is the companion framework or app framework for Svelte, because here at Stack Overflow we are trying to move a little bit more to decentralized architectures and this provides an opportunity actually for potentially building full-fledged parts of our product in Svelte. So essentially, all the UI being taken care of by Svelte and SvelteKit. So it’s a really exciting time and probably by the end of the year we might have some more recommendations and potentially have SvelteKit also in the mix here at Stack Overflow.
RD Very exciting. That's all I got. Anything else you want to talk about?
GB We covered a lot of the cool things we've done in the last six months or so. One of the reasons why we wanted to introduce a more modern technology was about trying to retain our front end talents, because in the past, maybe we struggled a bit with that being that a majority of our developers are specialized in the .NET ecosystem and C#. So I think that this is an opportunity to show that we are doing cool things also on the front end side.
[music plays]
RD Well, that is the end of the show. As we do, I'm going to shout out a popular Svelte question. Asked four years ago by Félix Paradis: “How to pass parameters to on:click in Svelte?” I assume that's very important.
GB I guess so.
RD Well, 71,000 people thought it was important. I'm Ryan Donovan. I edit the blog here at Stack Overflow. You can find it at stackoverflow.blog. And if you want to find me on X, you can reach out @RThorDonovan.
GB And I'm Giamir Buoncristiani. I'm the Tech Lead of the Stacks Design System team here at Stack Overflow, and you can find our work at stackoverflow.design. And if you want to find me, you can find me next, and my handle is @Giamir.
RD All right. We'll talk to you next time. Bye.
[outro music plays]