A rebuilt Sourcegraph UI
The Sourcegraph UI has been completely rewritten in SvelteKit for improved performance and development velocity.

The Sourcegraph UI has been completely rewritten in SvelteKit for improved performance and development velocity.
For almost two years, we have been working behind the scenes on a complete rewrite of Sourcegraph's user interface. The previous UI had accumulated more and more cruft, and it became increasingly difficult to maintain and to develop new features. Today, we're happy to share that this new UI is enabled for all customers, throughout the entire Sourcegraph experience.
This lays the foundation for a coherent, unified product. For our customers, this means a faster, more responsive experience with improved page load times and smoother navigation. For us, it means we can ship new features and improvements more quickly.
We didn't just write the UI from scratch again. We also took this opportunity to modernize our web application tech stack, switching from React + esbuild to SvelteKit + vite.
Application frameworks like Next.js or React Router v7 didn't exist when the original Sourcegraph UI was first created. We developed our own solutions and conventions that are provided by application frameworks these days. We saw the benefits that an application framework would provide but migrating the existing codebase seemed daunting. Most importantly though, when we started looking at possible candidates, all of them assumed to run as a node application on the backend. This was a no-go with our Go backend.
One of the exceptions: SvelteKit. From the beginning SvelteKit could easily be compiled to a Single Page Application that does not require a specific backend.
Every engineer at Sourcegraph sooner or later will make changes to the UI, whether they have frontend experience or not.
Over the years we've run into issues with how we use React that resulted in performance issues, race conditions, etc. Even frontend engineers do not always get useEffect right.
Svelte's reactivity model is a lot more forgiving in this regard. Our engineers felt like they could spend more time thinking about the product/feature they want to build and less about UI framework particularities.
And it doesn't stop there. All the small things that Svelte and SvelteKit offer add up to a really good experience:
*.module.css files, unless we want to.<Link>, <a> just works.Migrating a UI as broad as Sourcegraph's is not something you do in an afternoon. We've migrated the UI feature by feature, sometimes page by page. For a while we've actually been shipping two UIs, depending on which page was accessed: The old React UI for pages that have not been migrated and the new Svelte UI for all migrated pages. We've developed the necessary infrastructure to switch between both apps as seamlessly as possible.
In addition to automatic routing between the apps, customers also had the ability to disable the new UI and keep using the old one. This toggle is now removed.
However, maintaining two UIs clearly wasn't a long term solution and this setup also didn't reach the level of user experience quality we are aiming for.
After we've rewritten the core pages such as search and code browsing in Svelte, the question arose what we should (and can) do with the remaining pages. Do we have the resources to rewrite everything in Svelte?
The answer to this was "no".
Instead we found a compromise: Embed React-only pages in the Svelte app. We now have a route for every page in the Svelte app, only that some of these pages render the React components that make up the page.
Having only a single UI again makes maintenance easier for us and provides a better user experience for our customers. It gives us the room to rewrite more pages to Svelte as we see fit.
We are always striving to make the Sourcegraph UI better. This new foundation makes it easier for us to do so. You can expect many more improvements in the near future.