Why I Am Using Svelte
And Unveiling My Svelte Creations
How has your week been treating you? As for me, I had a rejuvenating hike around the serene Scarlet Oak Pond to catch a glimpse of the fall foliage — it was beautiful! It was an experience that reminded me a lot about what we do here: finding paths through uncharted territories. I’ve attached a photo from the hike:
Now, shifting from the tranquility of nature to the bustling world of web development, let’s dive into today’s topic: Svelte.
As some of you might recall from previous newsletters, Typogram has undergone a transformation, being rewritten from the ground up using Svelte. This three-month intense journey have given me lots to talk about! I am genuinely excited to unpack what I’ve learned, discuss why Svelte might just be the right tool for your next project, and perhaps, how it can make your development experience more enjoyable.
Vite is the way to go
Embarking on my Svelte journey, the starting point was actually with Vite. Let me take you back to May, shortly after our grand launch of Typogram. It was around this time I received a private message that would reroute my tech trajectory. A fellow developer flagged a crucial issue: Typogram’s absence of a proper build process and code minification could leave it vulnerable to hacking or reverse engineering.
Diving into Vite, I found it to be a revelation. It redefined the landscape of front-end development for me. Typogram originally bypassed a build process because my wariness of tools like create-react-app and webpack held me back. But Vite shifted my perspective with a superior developer experience. It offers hot module replacement, code bundling and minification, all wrapped in a straightforward configuration.
If you’re kicking off a new project now, I strongly recommend ensuring that your build process uses Vite. I’d even go as far to advise steering clear of frameworks that can’t be developed with Vite, like Next.js, which is tied exclusively to webpack. This limitation can lead to a less responsive dev server and a less-than-ideal developer experience.
Vite was the missing piece that not only secured Typogram but also elevated my entire approach to building web applications. It leads me to svelte.
Build Time vs. Runtime: A Shift in Strategy
After patching Typogram with Vite, I went down the rabbit hole of build processes. Vite works well with all major front-end frameworks including React, Vue, and Svelte. But here’s where Svelte breaks the mold — it leverages the build time like no other. It is not unfair to consider Svelte almost a new language that gets compiled into vanilla JavaScript. The build process strips away the need for a bulky library file at runtime, which is the typical case with Vue.js or React.js.
Simply put, Svelte does the heavy lifting upfront during build time, so the user's browser doesn’t have to during run time. It’s a straightforward swap: a bit more time spent during build time for a faster, smoother run time for every user out there. 10 seconds of my time in exchange of 1 second of every user's time. That's a solid deal!
Embracing Web Standard Syntax Over Framework-Specific Syntax
When Svelte takes my code and compiles it at build time, the final product is vanilla JavaScript — straightforward and standard. Moreover, peering into a typical Svelte component feels like a homecoming to the web development trinity: the good old HTML, CSS, and JavaScript.
Here’s a guiding principle I’ve adopted: prioritize web standard syntax over bespoke framework syntax. Svelte’s syntax is akin to pure JavaScript. From event dispatching and handling to state declaration — as long as you're versed in JavaScript, Svelte's code will look familiar to you. For a JavaScript developer, Svelte feels intuitive, almost as if JavaScript was always meant to function this way.
This alignment with standard JavaScript syntax not only eases the onboarding process but also reinforces our JavaScript knowledge. It ensures that being a Svelte developer also means becoming a more proficient JavaScript developer. And in the fast-paced tech world where today’s hot tool can cool tomorrow, this means all the expertise you gain is transferable, even when the day that Svelte become unpopular comes.
In the article: Why I Won’t Use Next.js, the author shared similar sentiment:
When I transitioned from Angular.js to React, I left a lot of Angular.js behind me. All of the time I had invested at getting really good at Angular.js felt like a huge waste. I don’t want that to ever happen to me again. So I prefer to focus on a framework that can not only give me what I want from the user experience perspective, but can also give me skills that I can use wherever I develop for the web.
I must admit to a small critique regarding melt-ui for the very same reasons. Melt-ui, a library that’s well-loved in the Svelte community, has a "builder" concept that is a stroke of genius, presenting a component library adaptable to any aesthetic — a feature that speaks volumes to me as a designer. However, its syntax is unmistakably melt-centric. The hours poured into mastering melt-ui are confined to its domain, with little carryover to other areas of Svelte. Regrettably, it wasn’t a match for my needs.
Svelte’s not so secret weapon
React, Vue, and Svelte serve as counterparts in the landscape of front-end frameworks, each providing a similar set of features. The stakes of this front-end frameworks competition are raised by their companion full-stack web frameworks: React is paired with Next.js, Vue is complemented by Nuxt.js, and Svelte boasts SvelteKit. Next, Nuxt and SvelteKit are counterparts to each other, offering full-stack solutions with uniform syntax for front and back ends.
SvelteKit is Svelte’s not-so-secret weapon. It stands out as the only first-party companion web framework in its category. In contrast, both Next and Nuxt were created by different teams than their dependency front-end frameworks. SvelteKit and Svelte share the same creator — Rich Harris — ensuring a unified vision for both. This means that as Harris ideates new features for Svelte, he's concurrently strategizing how to leverage it in SvelteKit. Truly, there's no tighter channel of collaboration than, say, sharing the same brain!
SvelteKit boasts a versatile adapter system that allows for deployment across various platforms, not just limited to Vercel but also including Cloudflare Pages, Cloudflare Workers (remarkably, it has separate adapters for these two Cloudflare services), Netlify, and traditional Node containers. Additionally, there’s a static adapter capable of generating a static site deployable on any platform that serves static content, like GitHub Pages.
Here is a feature that people rarely talk about: @sveltejs/package, which interestingly, flip the table on components vs, routes. Most SvelteKit projects publish routes, which are responsible for rendering the web pages. However with @sveltejs/package, the focus shifts — the components folder becomes the target for publishing, simplifying the process of packaging your Svelte components as an npm package. This feature was my gateway to publishing my own npm package for the first time! Meanwhile, the 'routes' folder is repurposed into a sandbox and documentation hub for these components. How clever!
What I have built
I've created five Svelte/SvelteKit side projects and can’t seem to stop – the ideas just keep flowing. Below are some exclusive sneak peeks into what’s brewing, including the much-anticipated second versions of CodingFont and Symbols to Copy. This is the first time I'm unveiling these links, take a look:
I’m always looking to improve and refine my work, and who better to help guide that process than you? I’d be thrilled to get your initial impressions and constructive feedback on these unreleased projects, you can play a pivotal role in their final form!