Monogram prides itself on being at the cutting edge of Composable Architecture. For years, our team has been one of the premier Next.js and Nuxt.js agencies, creating digital experiences for companies like GitHub and Vercel.
When we found out about the front-end tool Svelte and it’s companion framework, SvelteKit, we were intrigued. Svelte has been developing quite the buzz in the developer community for some time now. SvelteKit stood out as an attractive alternative to Next.js
As with any new technology, Monogram wanted to stress-test SvelteKit internally before using it on any external projects. When the time came to build a new company website, Monogram saw it as a the perfect opportunity to try the new framework out.

While building our new website with SvelteKit (isn’t it beautiful?), we came across a number of pros and cons that we wanted to share.

Let’s get into it.
Performance
Our previous website was built with Jekyll, a static site generator.
Being fully static, the site was highly performant. However, Jekyll is restricted to outputting MPAs, or multi-page applications. The best example of a MPA is any Web 1.0 site: each link triggers a full page load when clicked.
For the next iteration of our website, we wanted a static site with a SPA ( single-page application) feel. In a SPA, when a link is clicked, internal JavaScript logic switches out the page contents and updates the browser history without triggering a full page load.
The shortcoming of most SPAs is that they load large JavaScript bundles during the initial page load. The tradeoff here is that this large initial bundle makes subsequent page loads nearly instant.
SvelteKit gave us the best of both worlds: SPA routing with a small initial JS bundle size. Svelte keeps JS bundles small by acting as a compiler instead of a client-side library. All Svelte code is compiled into vanilla JS at build time, ensuring no bloat or excess code is shipped to the user’s browser.
This feature, combined with SvelteKit’s router, enables the site to have a SPA feel while remaining blazing fast.

Compatibility
Unlike other frameworks like React and Vue, Svelte doesn’t utilize a virtual DOM. Due to this fact, Svelte is compatible with the majority of vanilla JS libraries.
Although Svelte is a relatively new technology, it’s embrace of the core browser DOM gives it an immediate edge over other frameworks like React that have compatibility issues with DOM-dependent libraries. By this logic, Svelte’s ecosystem is actually larger than React’s!
For example, all we needed was Svelte’s bind:this
feature to add an interactive Three.js background to the homepage. In contrast, a React implementation would usually require a higher-level library like react-three-fiber
.
Development
The developer community behind both Svelte and SvelteKit are incredibly passionate. The amount of breaking changes during SvelteKit’s alpha and beta are actually a testament to the many innovations they’ve come up with.
SvelteKit’s new routing system, which solves a number of routing headaches related to full-stack frameworks, is a great example of this.
The main con that we came across with SvelteKit is: it’s still in beta!
Although we rarely came across major bugs or limitations, that there were multiple breaking changes during development. When the new routing structure was released, we were forced to refactor a large portion of the app.
SvelteKit has been nearing v1.0
for a while now. As a matter of fact, the first release-candidate was announced at Svelte Summit Fall 2022! Thankfully, the developers have promised no more breaking changes until after the v1.0
release.
Ease of Use
Svelte is heavily modeled after vanilla JavaScript. Instead of creating a new design paradigm like React with JSX and hooks, Svelte repurposes existing patterns from JS to power features like state management and component architecture
However, developers coming from React often find the state system confusing in it’s simplicity (an oxymoron, we know).