Tutorials on Svelte

This article dives deep into the realm of micro-frontends, with a particular emphasis on the Qwik Framework. This article also explores why Qwik may be a superior choice for managing micro-frontends compared to its counterparts like React , Angular , Vue , and Svelte . Micro-frontends represent an innovative design approach where a frontend app is partitioned into small, independent, manageable units that operate cohesively. Each unit, known as a micro-frontend, is managed by a separate team, leading to highly efficient and scalable development processes for complex applications.

SEO is a critical element for any online platform's success. As SEO gained momentum, web development technologies like React , Angular , Vue , and Svelte had to integrate SEO into their core structure. However, there is a technology designed from scratch to incorporate SEO principles into its core structure — Qwik . This article will explore how Qwik promises superior SEO performance compared to other popular web development technologies.

In this article, we will create a data visualization that displays the ratio of Dunkin’ Donuts locations to Starbucks locations (by state) using D3 and Svelte. Which of America’s largest coffee chains keeps your state awake and ready for the 9-5 workday?

In this article, we will create a data visualization that animates the changes in the stargazer counts of popular front-end library/framework GitHub repositories over the past 15 years. Which front-end libraries/frameworks currently dominate the web development landscape? Which front-end libraries/frameworks used to dominate web development landscape?

In this article, we will create a data visualization that displays the frequency of words in the lyrics of a song under the Billboard Hot 100 list, Vampire, by Olivia Rodrigo, using D3 and Svelte. Which words do you think catapult a song to the Billboard Hot 100 list?

SvelteKit is a serverless-first framework for building high-performance, web applications with Svelte. Newcomers to Svelte can think of SvelteKit as Next.js or Nuxt.js, but for Svelte. First announced in October 2020 , SvelteKit entered public beta in March 2021 and is the successor of Sapper , a now deprecated Svelte-based framework. With the Svelte team abandoning sveltejs/template and sveltejs/sapper-template , SvelteKit became the de-facto framework for building any type of web application (of any size) with Svelte. SvelteKit inherits many of Sapper's functionality and features: However, the Svelte team designed SvelteKit to address Sapper's shortcomings: Although the road to v1.0 remains in progress, you can still build production-grade, SEO-friendly applications with the SvelteKit beta. The best part of SvelteKit is the ability to build Next.js-like applications with an amazing developer experience and with Svelte, which exceeds React in terms of performance and size. Svelte's compiler turns Svelte components (written with an intuitive, declarative API) into efficient JavaScript.

To get a better understanding of what Svelte brings us, it helps to step back and look at how we got here: Back in the 90s, in the original version of the web, there was only HTML. Browsers displayed static documents without any interactivity. The only way to get updated information, was by reloading the page, or navigating to a new page. In 1995, Netscape released JavaScript , making it possible to execute code on the end-user's machine.

Disclaimer - If you are unfamiliar with the Context API in Svelte applications, then please read this blog post before proceeding on. You must understand the limitations of the Context API to better understand stores and how they address those limitations. For components in a Svelte application to share data irregardless of the subtree they belong to in the component hierarchy, Svelte provides stores for handling global state via the svelte/store module. Unlike the Context API, which involved setting contexts directly in the <script /> block of a component via setContext , stores can be created outside of a component in their own dedicated modules. Yet, like the Context API, a store can only contain a single value. This value can be a primitive, an object, an array, etc. When a component subscribes to a store, the component can receive the updated value from the store and re-render accordingly. Like props, stores are reactive . Stores are designed to cover practical use cases such as theming, accommodating internalization/localization (i18n), persisting a logged-in user's information, etc.

Disclaimer - If you are unfamiliar with props in Svelte applications, then please read this blog post before proceeding on. You must understand the limitations of props to better understand the Context API and how it addresses those limitations. For components that need to share data to lower-level descendant components (and slotted content) within the same subtree, the Context API offers two methods for these components to communicate data without prop drilling or dispatching events: getContext and setContext . When a component calls setContext , the component defines a context , which is a value (primitive or object) representing data that can only be accessed by the component's descendants via the getContext method. Defining a context with setContext requires the component to supply a context key and a value . The context key helps to retrieve the context value from the closest ancestor component with a defined context corresponding to this key.

Each component of a client-side application contains internal state that encapsulates its own data, which determines the component's behavior and stores business-related data for rendering. When composing many components into a multi-level hierarchy, components must communicate data and coordinate amongst each other to perform more complex tasks. For example, a <SearchBar /> component might pass a list of search results to a <TypeaheadDropdown /> component to display suggestions based on the currently typed query. There are three common approaches to facilitate communication amongst the various components within a Svelte application: Having full control over state within an application allows developers to know how data flows throughout the application, better reason about the data and optimize accordingly. Modeling data flow with props, contexts and/or stores improves the organization of state, normalizes data to reduce instances of duplicated data and curtails the amount of time spent on debugging (quickly identify the component/s or portions of state responsible for a bug). Below, and in two additional blog posts, I'm going to show you:

In Svelte, a component's beforeUpdate lifecycle method is called before the component is updated as a result of a state change. When the component receives new prop values or has its local state modified, the component's beforeUpdate lifecycle method is called before any updates to the DOM are made. Once the beforeUpdate lifecycle method finishes executing, the DOM will be updated with these data changes, which will allow the subsequent call to afterUpdate to have access to a completely synced DOM. Being able to schedule a callback to run at this phase of a component's lifecycle ensures that the value of certain DOM properties, such as a container element's scrollTop , can be cached prior to being updated. Then, these cached values can be used to revert those properties back to what they were originally. Here's a template of how the beforeUpdate lifecycle method is used inside of a component: Note : beforeUpdate is called before the component's initial onMount .

In Svelte, a component's onMount lifecycle method is called after the first time the component has been rendered to the DOM. For example, if you have a component that is wrapped within an {# if} block, then when this block's conditional statement is fulfilled, the component will be mounted to the DOM, at which point onMount will be called. Being able to schedule a callback to run at this phase of a component's lifecycle ensures that DOM elements within the component will be available for your code to access/manipulate. Here's a template of how the onMount lifecycle method is used inside of a component: Considered the most commonly used lifecycle method, onMount covers a wide diversity of use cases such as...

In Svelte, a component's onDestroy lifecycle method is called before the component is removed from the DOM. For example, if you have a component that is wrapped within an {#if} block and it is currently rendered to the DOM, then when this block's conditional statement evaluates to false , the component will be unmounted from the DOM, at which point onDestroy will be called. Being able to schedule a callback to run at this phase of a component's lifecycle ensures that cleanup-related operations can be ran and previous application states can be resumed. Here's a template of how the onDestroy lifecycle method is used inside of a component: Compared to the function returned from onMount , there are specific reasons for using onDestroy :

In Svelte, a component's afterUpdate lifecycle method is called after the component is updated as a result of a state change. When the value of any of a component's props and variables changes, the component's beforeUpdate lifecycle method is executed prior to any DOM updates being made in response to these changes. Once the beforeUpdate lifecycle method is finished running, the DOM is updated to reflect the data changes. After completing this update, the afterUpdate lifecycle method is executed. Being able to schedule a callback to run at this phase of a component's lifecycle ensures that the DOM is completely updated and synced with any new state and prop values. Here's a template of how the afterUpdate lifecycle method is used inside of a component: When using the afterUpdate lifecycle method, remember that it runs on every state and prop change. For components that experience many state and prop changes, it can be quite cumbersome to track which variables/props have changed in order to then execute the appropriate code. This is unlike React's componentDidUpdate lifecycle method , which provides the previous props and state as arguments.

Single-page applications (SPAs) provide user experiences that mirror those on desktop/mobile applications. Navigating from one page to the next no longer requires waiting for the browser to fully refresh the page on each transition, which keeps users engaged and productive. Because only a single page is served to a user, only certain sections of the view are dynamically updated by the browser (rather than the entire view via a full-page refresh) when the user navigates to a new page. To coordinate which sections of the view are dynamically updated for each route a user can navigate to, the single-page application must leverage a router to map these updates to each possible URL and render accordingly. When a router is added to an application powered by a modern front-end library/framework, such as React.js and Svelte, developers are able to quickly build single-page applications due to the declarative APIs offered by these libraries/frameworks. Compared to applications built with React.js, those built with Svelte are smaller (in bundle size) and faster. Svelte's compiler strips out the runtime overhead from outputted bundles and only ships the code that's needed. Additionally, Svelte does not rely on a virtual DOM and diffing algorithms (or other such techniques) for rendering updates. Instead, Svelte's compiler can determine ahead of time which parts of the application should change for a given state change, and when such state changes occur, it will surgically modify the DOM directly.

Modern applications involve many DOM manipulations. Components (and elements) are constantly being removed, added, updated, etc. to deliver incredible user experiences and/or to optimize performance. Sometimes, you may need to execute code when a component is added (such as automatically focusing an input field when a form is loaded like the G-Mail login page) or when a component is removed (such as removing all event listeners associated with that element to prevent memory leaks). Frameworks/libraries such as React.js and Svelte provide component lifecycle methods that allow developers to predictably execute code at these very moments/situations. Having such access into each stage a component undergoes provides more control over how and when the component should be rendered. Commonly, functions can be scheduled to be invoked when these events occur in the lifecycle of a component instance: