Svelte 3 Up and Running

A practical guide to building production-ready static web apps with Svelte 3

Alessandro Segala

• Publisher: Packt Publishing
• Year: 2020
• Print ISBN: 9781839213625
• eBook ISBN: 9781839216152
• Edition: 1
• Topic: Computer Science
• Subtopic: Web Development
• Index: Computer Science

Build your first web project using the Svelte framework and deploy it in the cloud with automated testing and CI/CD

Key Features

• A practical guide to building production-ready static web apps with Svelte 3
• Build faster and leaner frontend and static web apps using the JAMstack
• Deploy your Svelte 3 app to production using cloud services and DevOps principles such as automated testing and CI/CD

Book Description

Svelte is a modern JavaScript framework used to build static web apps that are fast and lean, as well as being fun for developers to use. This book is a concise and practical introduction for those who are new to the Svelte framework which will have you up to speed with building apps quickly, and teach you how to use Svelte 3 to build apps that offer a great app user experience (UX).

The book starts with an introduction to Svelte 3, before showing you how to set up your first complete application with the framework. Filled with code samples, each chapter will show you how to write components using the Svelte template syntax and the application programming interfaces (APIs) of the Svelte framework. As you advance, you'll go from scaffolding your project and tool setup all the way through to production with DevOps principles such as automated testing, continuous integration, and continuous delivery (CI/CD). Finally, you'll deploy your application in the cloud with object storage services and a content delivery network (CDN) for best-in-class performance for your users.

By the end of this book, you'll have learned how to build and deploy apps using Svelte 3 to solve real-world problems and deliver impressive results.

What you will learn

• Understand why Svelte 3 is the go-to framework for building static web apps that offer great UX
• Explore the tool setup that makes it easier to build and debug Svelte apps
• Scaffold your web project and build apps using the Svelte framework
• Create Svelte components using the Svelte template syntax and its APIs
• Combine Svelte components to build apps that solve complex real-world problems
• Use Svelte's built-in animations and transitions for creating components
• Implement routing for client-side single-page applications (SPAs)
• Perform automated testing and deploy your Svelte apps, using CI/CD when applicable

Who this book is for

The book is for frontend or full-stack developers looking to build modern web apps with Svelte. Web developers with experience in leading frontend JavaScript frameworks who wish to learn Svelte will find this book useful. The book assumes a solid understanding of JavaScript and core HTML5 technologies. Basic understanding of modern frontend frameworks will be beneficial, but not necessary.

Chapter 1: Meet Svelte

When developers think of JavaScript frameworks, the options abound. Even within the narrow scope of front-end development that we're covering in this book, most developers will be familiar with (or have at least heard of) tools such as Angular, React, and Vue.

However, you picked up this book because you've heard of Svelte, and you've heard of it's growing in popularity. You've probably also heard that Svelte is different, and that there's something magical about it. I'm using the word magical on purpose: in fact, the original tagline for the Svelte project was "the magical disappearing UI framework."

This book is about the Svelte 3 front-end JavaScript framework, the last version as of the time of writing, which was released in April 2019.

You can use Svelte to build single, reusable components for projects of any kind, including larger applications written with Angular, React, Vue, or any other frameworks. Or, you can build entire web applications with it – just like we'll be doing in this book.

Among all the various frameworks, in most comparisons, Svelte 3 stands out for its ability to produce smaller code bundles that run faster in the browser, compared to Angular or React. This is a big part of what makes Svelte magical. But, perhaps even more importantly, developers largely enjoy working with Svelte 3; building components and applications with it feels to many very similar to using "vanilla JavaScript."

Throughout this book, I'll help you build your first, fully functional project with Svelte 3: a journaling app. We'll go from bootstrapping the development environment all the way to production with an automated continuous integration and delivery pipeline.

While building this sample app, we'll cover the majority of the features of Svelte 3. By the end, you should have a strong foundation to go and create your own apps with Svelte.

In this chapter, we'll cover the following topics:

• Modern web app development
• Why you should use Svelte
• Details on the app we'll be building

Modern web app development

Before we dig deep into Svelte, or any other JavaScript framework for front-end development, it helps to take a quick trip down memory lane and look at how we arrived at modern web app development, and the role that frameworks play.

How the web became static…again

When I built my first website, in 1999, it was just like what you would expect: rich in flashy GIFs, scrolling texts, and eye-hurtlingly bright colors. It was also served by static hosts that were essentially the Italian equivalent of GeoCities.

I had built that website using the most advanced tools available for webmasters at the time: WYSIWYG editors (which stands for What You See Is What You Get): for me, that meant Microsoft FrontPage.

FrontPage worked just like Wix.com and other similar services of present day, where you build your website visually and the code is generated for you. It differed in that it was a native desktop app and, in the middle of the first browser war, it outputted code that ignored web standards and was optimized for Internet Explorer. Of course, all those websites were fully static. (In case you're wondering, I eventually "graduated" to Macromedia Dreamweaver, which was more standards-compliant; Macromedia was later acquired by Adobe, and Adobe Dreamweaver is still maintained today.)

Ten years later, in 2009, I was still building websites, but then I was making them dynamic, with server-side generation in PHP. Those were the days of "rich internet apps," where users could interact with a website, and "web 2.0," centered around collaboration and user-generated content.

Generating web pages on a server was not a novel concept per se: Java EE was released in 1999, Microsoft created ASP in 1996, and the original PHP came out in 1994! However, it was only in the second half of the '00s that those technologies became more accessible to small teams and individual developers, first of all thanks to new, simpler frameworks: for example, Django and Rails were both released in 2005. Additionally, in those years, we started seeing increasingly cheaper options for hosting web applications that require server-side rendering, especially with PHP.

Around the same time, interactivity started to appear in frontends too.

Developers had been building apps that run within browsers for a long time, leveraging plugins such as Java Applets, ActiveX objects, or Macromedia Flash (later, Adobe). Those were plagued with issues ranging from poor performance to serious security flaws, and they always ran almost completely isolated from the rest of the web page and the DOM. JavaScript was mostly considered a tool for designers to add small bits of interactivity to web pages and other gimmicks – just like its creators had originally meant it for.

Then, Google released Gmail in 2004 and the next year, they built Google Maps, and those were among the first large-scale applications to run primarily within the browser itself (any browser) without plugins. They popularized a new way of building web apps, where data is loaded dynamically in response to user action: this technology was then called Asynchronous JavaScript and XML (AJAX). The foundation for AJAX was the XMLHttpRequest API, which existed in Internet Explorer as an ActiveX object and was later implemented by other browsers in a compatible way too.

Another relevant change for JavaScript developers at the time was the creation of libraries such as Prototype in 2005 and jQuery the next year. At a time when browsers were still running JavaScript based on the ECMAScript 3 standard, these libraries provided great help by offering convenient features to web developers, such as easier ways to access and manipulate the DOM. They also helped by abstracting away the complexity of targeting all web browsers, including the then-dominant Internet Explorer 6 and its poor support for web standards.

With the help of AJAX and libraries such as jQuery, it became clear to developers that apps could run within a browser itself, and the amount and sophistication of web apps started growing.

Fast forward to 2020, and browser-based web apps are the new norm, to the point where we can often replace native, desktop apps with web ones running inside the client: from spreadsheets, to photo editing tools, to complex 3D video games.

The last decade brought along a set of innovations that helped make front-end development simpler, more accessible, and more powerful.

This included innovations in browsers, with faster JavaScript engines, and in the standards themselves. New HTML5 and CSS3 specifications added a bunch of new features, including the <video> tag that killed Adobe Flash for good, the last standing of the plugins. As for JavaScript, ECMAScript 2015 (ES2015, often called ES6) was finally released in 2015, after a much-troubled process (which is an interesting story in itself). Innovation is continuing, with technologies such as WebAssembly posed to completely rethink the way we build apps too.

As for the developer experience, a new class of front-end frameworks started to appear with AngularJS 1.0 being released in 2010, whose goal was to make it easier to write large-scale apps in JavaScript, avoiding the creation of unmaintainable "spaghetti code." We'll look a bit deeper at these frameworks and how they work, and how they compare to Svelte, later in this chapter.

Eventually, in what could be called a clear example of Nietzschean eternal recurrence applied to software development, we're back to building web apps that are completely static, and they have never been more powerful. (We're also using a very large number of GIFs once again, but at least we're doing it ironically this time!)

Building apps with the JAMstack

Along with advancements in the web technology and browsers, developers have been able to leverage new paradigms.

One of the most relevant to us in this book is the so-called JAMstack, an acronym of the following:

• JavaScript
• (Reusable) APIs
• (Pre-rendered) Markup

Inside the JAMstack

The JavaScript part shouldn't come too much as a surprise: in the JAMstack, apps are written in JavaScript and run within a web browser. You can interpret this more broadly to refer to all apps that run within a JavaScript VM in a browser, to extend the definition to also include apps that use WebAssembly.

More interesting is the APIs part. One of the most sought-after features of JAMstack apps is how they deliver a great end user experience by allowing interactivity. This is possible thanks to apps interacting with other back-end services through a set of predefined APIs:

Figure 1.1 - A conceptual diagram for a JAMstack application

The most commonly used APIs are RESTful endpoints that are accessed via HTTP(S), just like we'll be using in this book's sample app. More recently, developers have started to leverage GraphQL too as an alternative format, which is especially optimized for data that can be represented by graphs (GraphQL was invented by Facebook, as a matter of fact). Alternative transport protocols are possible too in certain scenarios, such as using WebSocket for two-way data streaming, or protocol buffers and gRPC for apps that need to transfer large amounts of structured data (although gRPC doesn't yet work natively within web browsers and requires a proxy).

Lastly, pre-rendered markup refers to how JAMstack apps are made of bundles of HTML, JavaScript, and CSS files, as well as assets (images, fonts, and so on) that are rendered at "build-time." Using tools such as Webpack, various source files are packaged together and minified. Text content can also be pre-rendered from Markdown documents, thanks to static site generators such as Gatsby, Hugo, and Jekyll.

JAMstack apps are "compiled" and packaged inside the developers' machines or, more commonly, in a continuous integration server. The final bundle, which contains only HTML, JavaScript, and CSS files, in addition to any static asset, is self-contained, and is often deployed to object storage services in the cloud, such as Azure Blob Storage and AWS S3. Because the applications' files are completely static, developers usually place a Content Delivery Network (CDN) in front of the object storage service: this caches the files in edge nodes around the world, delivering faster speeds and lower latencies to all visitors worldwide.

Benefits of JAMstack applications

JAMstack apps are enjoying well-deserved popularity, both with developers and end users.

For teams building and operating apps, the benefits of the JAMstack mainly fall into two categories: simpler operations and better developer experience.

The latter group enjoys a great user experience, being able to use apps that are interactive and yet run within a web browser. But, most importantly, JAMstack apps feel fast.

For operators

On one hand, operations are simpler and cheaper than for traditional web applications:

• Because JAMstack apps are just a bundle of static files, they can be deployed to object storage services on the cloud, which offer high ...

Table of contents

• Svelte 3 Up and Running
• Why subscribe?
• Preface
• Chapter 1: Meet Svelte
• Chapter 2: Scaffolding Your Svelte Project
• Chapter 3: Building Reactive Svelte Components
• Chapter 4: Putting Your App Together
• Chapter 5: Single-Page Applications with Svelte
• Chapter 6: Going to Production
• Chapter 7: Looking Forward
• Other Books You May Enjoy