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).
// State in React
// MenuComponent.tsx
import { useState } from 'react'
const MenuComponent = () = {
const [isOpen, setIsOpen] = useState(false)
const toggleOpenState = () = {
setIsOpen(!isOpen)
}
return (
<>
<button onClick={toggleOpenState}>Open menu</button>
{isOpen && <div>Menu</div>}
</>
)
}// State in Svelte
// MenuComponent.svelte
<script lang="ts">
let isOpen = false
const toggleOpenState = () = {
isOpen = !isOpen
}
<script>
<button on:click={toggleOpenState}>Open menu</button>
{#if isOpen}
<div>Menu</div>
{/if}Svelte’s adherence to core JS principles means it’s easy to pick up for new and experienced developers alike. Developers from across our team were able to contribute with little to no onboarding needed.
We want to stress this point:
The React way of doing things can have a huge learning curve for developers of all experience levels. Learning Svelte does not have this same level of difficulty, which makes it a great first ‘front-end framework’ to learn.
Svelte's docs contribute to it’s ease of use. They include a helpful hands-on tutorial and sandbox that shows the compiled vanilla JS code output.
Furthermore, SvelteKit is inspired by Next.js and includes some of the features of that framework, including file-based routing and API routes. Our team was also able to pick SvelteKit up quickly because of our thorough experience with Next.js. Just like Next.js, SvelteKit is able to integrate seamlessly with headless CMS platforms like Prismic.
From Next.js to SvelteKit
Since we've been using Next.js for a while, we were curious about how SvelteKit would feel in comparison—meta-framework to meta-framework. What we found was that the learning curve when coming from React to Svelte isn't as wide when learning SvelteKit as Next.js developers. This is because both are opinionated meta-frameworks with the same opinions about path-based routing, data fetching, and more.
The differences between Next.js and SvelteKit from a developer experience perspective are minimal:
- Where Next.js uses a ./pages/index.js route scheme, SvelteKit uses ./src/routes/index.svelte.
- Where Next.js exports a getServerSideProps function for data fetching, SvelteKit exports a load function that returns props to pages.
- Where Next.js exports getStaticProps for pre-rendering, SvelteKit exports prerender = true for the same thing.
For reference, compare the following code snippets between Next.js and SvelteKit:
Next.js
// ./pages/index.js
export async function getServerSideProps() {
const users = await getUsers()
return { props: { users } }
}
export default function Page({ users }) {
return (
<div>
<h1>You have {users.length} users!</h1>
</div>
)
}SvelteKit
// ./src/routes/index.ts
export async function load() {
const users = await getUsers()
return {
props: {
users,
},
}
}<!-- ./src/routes/index.svelte -->
<script>
export let users
</script>
<div>
<h1>You have {users.length} users!</h1>
</div>Both snippets do the same thing: fetch a list of users from a database and display the number of them on a page. The only difference is the syntax and the underlying implementation details, but what we've found is that by understanding the data fetching concepts from Next.js, we can easily translate them to SvelteKit and vice versa.
Across the board, we were pleasantly surprised by how approachable we find SvelteKit when coming from a Next.js background because fundamentally, the concepts are the same, while the underlying details differ between React and Svelte.
Conclusion
All in all, the Monogram team had a blast working with SvelteKit for the first time. We’ll definitely be adding it to our client arsenal alongside Next.js and Nuxt.js.
We ended up loving SvelteKit so much that we rebuilt our DAM (digital asset management) app Raster with it! The result was faster load times and a more approachable developer experience. Give it a try and let us know what you think!
If you’re interested in having a web app or Composable architecture site built using SvelteKit, Next.js, or Nuxt.js, please reach out to us in the form below! 👇