DEV Community: Chris Simmons

Introducing Skeleton: A fully featured Svelte component library.

Chris Simmons — Fri, 26 Aug 2022 22:02:00 +0000

I recently had the privilege of writing an article for Smashing Magazine introducing Skeleton, a new open-source UI component library for Svelte and Tailwind. If you're looking for a quick introduction, I'd recommend starting here:

Smashing Magazine: Meet Skeleton: Svelte + Tailwind For Reactive UIs

However I wanted to go a bit further, as it's not every day you get to hear the origins of the tools we use as frontend developers. I want to share details on how my team and I started the library, explain the challenges faced during development, and of course review the progress made since the public debut. My hope is that this can help inspire others seeking to build and share their own web-based libraries as well.

The Origin of Skeleton

Over the last two years I've worked for a tech startup called Brain & Bones, made up a small team of five individuals. As with most startups you tend to wear a lot of hats, so my job covered everything from tech to design - deciding the tech stack, product design, implementing the frontend applications, guiding development efforts for our platform API, as well as managing two very talented developers.

Day to day, we managed number of web-based applications, which meant our choice in frontend framework had a major impact on our ability to build and maintain the platform for the company. Angular was an obvious choice for me, given I've used it professionally for around 10 years. I've watched it grow from the early v1.x days, through the v2.x launch, and eventually evolving into the mature framework we know today. I'm still a fan of Angular's opinionated design philosophy, as well as Angular Material, their official offshoot of Material Design. The Material aesthetic provides a simple but clean interface, and their component system allows for rapid develop of large scale web-based apps.

Last year we welcome a budding young developer to our team, named Thomas Jespersen. Thomas joined with the mission of improving our QA (quality assurance) and testing efforts, but immediately had interest in expanding into frontend development. So I set aside time and began teaching him everything I could, drawing from my 20 years of experience in the field.

We explored the basics of HTML/CSS/JS, various frontend frameworks like React/Vue/Svelte, with our final goal being an introduction to Angular. However, an interesting thing happened along the way. We had a bit of a revelation after covering Svelte. Like many in the frontend space, we were captivated by Svelte's superb DX (developer experience). We knew our platform relied on Angular, but craved the chance to introduce and use Svelte and SvelteKit (Svelte's app framework) in our production environment. Unfortunately we were unsure how to introduce it at the time.

Fast forward to February of this year and we began the planning phases for our next generation and evolution of our platform. We immediately began brainstorming a means to transition from Angular to Svelte/Kit. However, as we searched for UI libraries to replace Angular Material we came up short. Sure options like Svelte Material UI were available. However, we had growing concerns about the trajectory of Material Design. Material Design v3 hasn't really been a resounding success, having only a small handful of components (even today), and is currently limited exclusively to Android. Even Angular Material, a Google-owned project, has been slow to adopt v3. Progress has been moving at a snail's pace. This left us with a dilemma.

It was at this point we started started toying with the idea of building our own component library. Looking deeper into SvelteKit, we realized it provided a turnkey solution for building and maintaining home grown component libraries using built-in packaging options.

This would make it trivial for us to generate components that could meet the requirements of each of our products, while retaining full control over how they looked and operated. Unfortunately this would require more development effort upfront, but after some internal debate, we decided this was fair trade off in the long term. Thus Skeleton was born!

Seeking Inspiration

While planning our vision for the new library, we began auditing and reviewing every competitor we could find. Searching for inspiration, deciding what components to add, and helping define the conventions we would follow.

Here's a small sample of the libraries we reviewed:

After some time and effort, this process led us to a library called Mantine, a React-focused component library offering a huge set of components, deep customization, all housed within top-notch interactive documentation. This quickly became our go-to source for inspiration and has influenced many of the design decisions for our library, most notably in presentation.

Using Tailwind

We knew right from the start that we wanted take advantage of Tailwind CSS. It's powerful utility-based class system aligned with conventions used in our own project for years, but could help standardize the process. This would allow us to develop a turnkey design system and managed styling both inside our components and throughout each app. The first challenge was how to properly utilize Tailwind within Svelte components. There wasn't a lot of precedence available to draw from other libraries. Many libraries we reviewed opted for either vanilla CSS or preprocessors like SASS.

Plus, we needed a way to handle all styles and customization for components using Tailwind classes. Originally we tried writing all classes inline in the HTML, as is standard practice. However this posed issues with CSS inheritance. Providing a default class in a template, then overwriting with another doesn't always cascade over the original style one might expect.

Through experimentation we came up with a creative approach - we would define all CSS classes in the component script tag, then use a layered or conditional statements to control the classes defined on each element.

In the component script tag we would define our base (read: default) styles for an element as shown:

const let cBase: string = `p-4 space-y-4`;

We would also allow for customizable Tailwind classes to be passed as Svelte component props:

export let background: string = `bg-slate-900`;
export let color: string = `text-white`;

We then created Svelte reactive properties to merge these into a "flat" class string:

$: classesBase = `${cBase} ${background} ${color}`;

By doing this, we concatenate the base and custom prop values and, define the order in in which classes are defined, and also open the door to conditional classes, like so:

export let hover: boolean = true;

$: classesHover = hover ? 'bg-emerald-500' : '';
$: classesBase = `${cBase} ${classesHover}`;

This prevented cramming a ton of conditional logic into the component's HTML template markup. Abstracting this provides a simple and well-define paradigm to follow.

Using JavaScript logic we can intercept and modify our classes, allowing for a deep level of control over presentation. We can even accept single prop values that expand to a set of Tailwind classes:

export let size: string = 'sm'; // small

let cSize: string = '';

switch (size) {
    case ('sm'): cSize = 'p-2 text-sm'; break;
    case ('md'): cSize = 'p-4 text-base'; break;
    case ('lg'): cSize = 'p-5 text-lg'; break;
}

$: classesBase: `... ${cSize}`;

Finally, we append the reactive class value to the element. This keeps our templates clean and reduces the Tailwind class "bloat" that turns many folks away:

<div class={classesBase}>...</div>

One thing to note with this approach, however, is that Tailwind's compiler does NOT allow for dynamically constructed classes. If you try to pass a partial value like color name (ex: emerald) and generate bg-${colorName}-500, this will fail. The Tailwind compiler is looking for the exact string match in each file, but Tailwind reads the value literally and will not recognize this. This was a source of many headaches for us early on, so beware!

Themes

The next challenge we faced was how to properly handle themes. Having to overwrite the same prop value over and over for each component would not scale well. Thankfully Tailwind provides a perfect solution via custom color definitions. These work best with RGBA color values, allowing alpha transparency to be adjusted for each color. In other words bg-emerald-500/40 would mean the color is set to 40% opacity.

To handle theme colors, we generate four uniquely named values:

Primary - the primary brand color
Accent - a secondary color for offsets or neutral actions
Warning - for alerts and critical items
Surface - a foundation, such as background colors

We hand craft our default theme using Tailwind's default color palette (emerald, indigo, rose, and gray), but converted each color shade from hex to RGBA. These were defined using CSS custom properties (read: CSS variables), and injected into the Tailwind config file via a custom Tailwind plugin. We have since made this process much easier by offering a set of preset themes and theme generator.

This means no colors are hardcoded into components. We draw from each of these sets and apply color styling in logical fashion.

Need to define a Card component background? Use this as your default:

export let background: string = 'bg-surface-800';

Need to style a Button component using your primary branding color? Use this:

export let background: string = 'bg-primary-500';

Dark Mode

Finally, we needed a solution to intelligently adapt each component theme for Tailwind's dark modes. The solution was to balance colors like a weighted scale. We paired colors from either side of the spectrum.

Here's what that looks like visualized:

In execution, the means if you set your body element's light theme background to bg-surface-50, then the dark theme equivalent should be bg-surface-900 to balance. Here's what the CSS looks like in practice:

body { @apply bg-surface-50 dark:bg-surface-900; }

If you want to style a Card component that's slightly elevated (visually) from the background, you use:

export let background: string = 'bg-surface-100 dark:bg-surface-800';

Regardless of what color surface represents, regardless of light or dark mode, the card element always gives the desired effect. Even though this a delicate balancing act, it's still easy to test during development. Just be mindful to review your components in different different themes and with light/dark mode toggled regularly as you progress.

The First Four Months

From February through May, Thomas and I defined these conventions and began building each component. Internally we had a shared list of component needed to satisfy the requirements of our projects. This included Buttons, Cards, Tabs, etc.

By using Svelte, Tailwind, and our design patterns we had produced a majority of the library within the first four months. Unfortunately, as is often the case with startups, we received news that the company would be shutting down and the team would be let go by the end of the month. Obviously this was devastating to hear. We had a wonderful and supportive culture, we were fully invested in the products were were creating, and of course we were excited to get Skeleton off the ground. In some ways this felt like the things were over before they even really began.

However, since the beginning, we had discussed the possibly of making the library open source. We knew we had something that could be beneficial to many Svelte community. However, the library didn't legally belong to us. Luckily Thomas and I have a wonderful working relationship and friendship with the founder of the company. After a bit of a summer break, we came together and agreed to release the library as open source. It was at that point I resumed work on the project, joined soon after by Thomas, we set about opening it to the public.

Launching the Public Beta

At the end of June we added our final polish to the documentation, added the MIT license, and finally set the GitHub repo and NPM package public. We then began promoting and announcing the project within various Svelte-focused communities.

Since launch we've received a slew of useful feedback and positive comments on Reddit and the Svelte Discord. People were asking hard questions, making great suggestions, and generally pretty excited for what we've created. This of course has fueled our ambition to push forward with the project, especially after the delay in May. In some ways it felt like the Phoenix rising from the ashes!

Since the public launch we've put a lot of effort into building up the Skeleton community on Github, Twitter, and Discord. On a whim, I reached to new sources like Smashing Magazine. To our surprise, we received a very pleasant response from Vitaly Friedman. He offered us a chance to write the articled which is now linked at the top of this page. Smashing Magazine has been a huge influence in my career. I've learned a lot about web development from them over the years. Honestly, I'm still kind of shell shocked that this happened at all!

Likewise we've been thrilled with the Svelte community's reaction - being treated to congrats from folks like Ben McCann, the second highest contributor to SvelteKit after Rich Harris (creator of Svelte).

As well as compliments from members of the Astro core team and even a member of the Svelte Sirens. Both are made up of good people and worth a look!

A Bright Future

We continue to push forward with progress on Skeleton, including a large release this week adding a11y improvements and support for Vite and Astro. We're not stopping there though, we have so much more planned and see a bright future for the library.

It's my hope we can continue to to work on Skeleton for as long as possible and build the best UI component library available for Svelte. If you're interested in giving it a try checkout the official documentation here:
https://skeleton.brainandbonesllc.com/

Join us on Github
https://github.com/Brain-Bones/skeleton

Or drop by and say hello on Discord:
https://discord.gg/EXqV7W8MtY

We would be glad to have you and welcome contributions from anyone willing and able! Seriously, thanks to everyone that continues to help make this possible! 🙏

Let's Talk About Framework-Specific UI Component Libraries

Chris Simmons — Thu, 11 Aug 2022 07:20:04 +0000

A Brief Retrospect of Web UI

To understand how far we’ve come with interface design for the web it's important to understand the progress made over the last 15 years. During this time, tech giants such as Google and Twitter were tasked with creating consistent design across their vast catalog of online products and services. This prompted them to create what I like to refer to as “general purpose” UI frameworks, which included the likes of Bootstrap and Material Design. These brought comprehensive guidelines that covered common UX patterns, addressed accessibility, and a provided a consistent visual aesthetic. Each has had a dramatic impact on web design as we know it.

As time has moved on, monumental advancements have been made for core web technologies. When we think about interfaces, we tend to focus on visual aspects created using HTML and CSS. However, one would be remiss to overlook the impact Javascript has had on user interaction within then frontend space. Early UI frameworks such as Bootstrap opted to integrate jQuery and use direct DOM manipulation to handle interactive elements such as modals and dialogs. But as you may know, this has fallen out of favor due its less than stellar performance, resulting it it eventually being removed from Bootstrap in 2022. Replaced instead with standard Javascript features.

Other libraries, such as Bulma, opted for a different approach. They made the decision to forego javascript altogether and focus purely on the the UI “shell” (the HTML and CSS). Leaving the onus on developers to code their own interactive logic or introduce additional third party dependencies to handle interactive elements.

These days, UI frameworks tend to make heavy use of modern Javascript and utilize components and reactive patterns to handle real-time interaction. Angular, React, and Vue are now well established as the standard for what we know as modern frontend development. Alongside these, we’ve seen the rise of framework-specific UI libraries that aim to provide a “batteries included” approach to UI, with deep integration of each framework’s unique set of features. This includes Angular Material, Mantine (for React), and Vuetify.

Introducing Skeleton

With the emergence of new frameworks such as Svelte, we might expect to see similar tooling appear to pair with these technologies. In fact, that's where Skeleton comes in - a brand new open-source UI component library that tightly integrates both Svelte and Tailwind. In short, it provides a broad set of Svelte components that can easily be adjusted using Tailwind’s powerful utility class system.

Visit the Skeleton documentation site

Skeleton is a project that's very near and dear to my heart, as I'm both the creator and one of a handful of core contributors. Over the last couple years I've found myself really impressed with Svelte and what it brings to the frontend developer’s arsenal. Earlier this year I was working at Brain & Bones when we made the decision to start migrating away from Angular and moving towards Svelte and SvelteKit. The ecosystem is still early days of course, so we immediately realized there was an opportunity to combine Svelte’s intuitive component system with the utility-driven design systems of Tailwind, and thus Skeleton was born.

My team and I realize Skeleton has the potential to benefit many in the Svelte community, and as such we’ve decided to make it open-source. Our hope is to continue to grow the project into a powerful UI toolkit that can help a lot of developers. Whether your skills lie within the frontend space or not.

Skeleton is currently available in early access beta, but feel free to visit the documentation to learn more. The site provides detailed guides to help get you started and covers all available components. You can report issues, request walkthroughs, or contribute code at our GitHub. You’re also welcome to join the Discord community to chat with me and other contributors.

There's so much more I want to share about the project, including a deep into the technical decisions that lead to it's creation. As well as detailing the process for creating and maintaining a project of this scale. Expect posts covering this and more in the near future!

How I built my new portfolio using Pixi.js

Chris Simmons — Sat, 06 Aug 2022 21:18:00 +0000

My New Portfolio

View the site here: endigodesign.com

I recently launched a new version of Endigo Design, my personal portfolio. This is a process I undergo every few years. I devote a few days building a simple site that covers the essentials of who I am and what I do. This time though, I decided I wanted to go big. To flex my combined knowledge and skill between web and game development and create a unique showcase of my work. In this post I’ll review the site and discuss some of the technology and techniques powering it behind the scenes.

Exploring the Site

To begin, let’s take a look at the homepage.

Here you’re provided two options. The first, to view an interactive game-like experience. This operates similar to a virtual art gallery. Whereas you browse a virtual 2D world and inspect each of my projects, represented as monuments or tall black pillars. You’re also provided a means to fallback to a traditional site — which adheres to standard UI and UX patterns for navigating between each project and the About page. This is the safety net and fallback for users that are either in a hurry, or don’t have a device or network connection to property fun the game experience.

For the game experience you’re immediately presented with several unique characters to interact with, as well as a large monument — which triggers a modal embedded version of my biography page. When tapping each character, it trigger a traditional RPG-styled dialog box to appear. Each character provides small hints at how to interact with the world. A throw back to old school 2D Pokemon games.

At this point you’re set loose to navigate the rest of the world. Using your mouse or finger, you can tap and drag to move the camera. There are several uniquely styled biomes provide, which provided a means to group each set of projects. Along the way you’ll find pillars that represent each project I’ve worked on or contributed to. Tapping a pillar provides a description and other media within popup modal.

Each pillar you locate and interact with will immediately begin to animate. This helps visually identify which you have and have not yet visited. Overall it provides a really fun and unique experience, allowing you to take in the sights and sounds of this little world, while browsing my full catalog of work.

Tooling and Technology

When I set out to design this site, I knew right right away I wanted to create a presentation that looked and felt like a traditional 2D top-down RPG game. It would also need to live within the confines of available browser APIs and modern web-based technology. Given this, the use of the canvas element and WebGL were a given. When paired, these allow you to render graphics within either a 2D or 3D context. For 2D this means drawing primitive shapes like rectangles and circles, images (textures), all with direct interaction and input from end users. When combined, these provide the basic building blocks of a game.

Game Rendering

My early prototypes made use of pure HTML and Javascript paired with a canvas element. This would have involved building everything from the ground up. However, I quickly realized this would not be a scale well for a presentation of this size. I was lacking mainstays of game development, such as animated spritesheets and found interaction to be quite tricky. Instead I opted to use Pixi.js.

If you’re not familiar with Pixi, it provides several quality of life improvements and features over your standard canvas integration. This includes, but not limited to:

Containers: which allow you to create a group of elements, similar to Game Objects in engines like Unity.
Textures: preloaded image assets that may be used within your scene.
Graphics: dynamically rendered primitives such as rectangles, arcs, etc.
Sprites/Spritesheets: typically made up of one or more graphics or textures. Pixi even provides animated spritesheets using row and column based references from a single image for character animations.
Interaction: the Pixi API provides a very means to listen to and act on events for any scene object.
Render Loop: a standardized loop meant to handle animation and monitor elapsed time within your scene.
Text: direct support for text, fonts, and even rasterized bitmap for high performance.

Web Application Framework

Next I knew I’d want to utilize UI components and a fully featured web application framework to build the foundation of the site. For this I turned to Svelte and Sveltekit. When combined these fulfill a similar role to tools such as Angular, Next.js for React, and Nuxt for Vue.

I used the follow features extensively via Svelte and Sveltekit:

Components: the reusable blocks of code/templates/styles that create a set of building blocks for the site. Things like the reusable footers, page templates, etc.
Routing: Sveltekit provides a great file-based routing system for helping control navigation of my site and pages.
State Management: which is handled via Svelte writables. The data stores use a pub/sub like model for data flow.
Build & Bundling: Sveltekit was developed on-top of Vite, a build tool created by Evan You (of Vue fame). It provides a very fast and responsive set of tooling for creating local servers, handle hot module refresh, Typescript compilation, building, bundling, and more.

Style and Design

Finally, I needed means to style and control the layout and design of each page and component. For this I turned to Tailwind CSS. Tailwind provides a full suite of utility CSS classes, while still allowing you to “draw outside the lines” with arbitrary overrides. It’s an acquired taste for sure, but a tool that can dramatically increase productivity in the right hands. It pairs really well with component libraries, such as Svelte, React, or Vue.

Pulling it All Together

While each tool is great in their own right, one of the key struggles of building web applications (at any scale) is finding the proper way to make everything work in unison. I’d like to take some time to explain how I paired everything together to build the most critical portions of the experience, with a focus on core game features.

The Pixi Component

The first challenge I faced was determining where to house the canvas element and begin rendering to the screen with Pixi. For this I opted for a simple standalone component. This allowed me to create a basic game manager, and included all logic, layout, and styles all within a single file. This made it quick and easy to jump between shared references and iterate the code.

The rough order of operations goes something like this:

The canvas element is bound using Svelte’s bind:this={elemRef} syntax.
The Pixi application is initialized, which takes in the element reference and sets global settings, such as display size.
A Pixi loader ingests a set of static resources, which allows you to ensure all required elements are preloaded ahead of time. This can be tapped to present a loading progress bar on screen.
When the game app is fully loaded a number of steps occur…
The over world map is generated via a preloaded texture, then injected into the “level” container. This container houses the map and all other entities such as NPCs.
Next, the camera class is initialized, which primarily controls the x/y position of the level container within the 2D world space. I explain this in greater detail in the section below.
I initialize a grid class, which can optionally be enabled to visually display the individual “tile” segmentation and coordinates on-screen for debugging purposes. Tiles have a base of 16x16 pixels here.
A slew of game objects, such as the pillars, npcs, and creatures are initialized and added as children to the level container.
The level container is added to the Pixi stage (the scene). Which finally makes it visible on screen.
On load, I adjust the camera focus to center on my personal character.
Finally the game render loop it started, which enables all animation and movement to function. The camera, container level, and entities have their respective render methods updated per frame.

Camera Controls

Cameras present an interest challenge when rendering in a 2D virtual space. If you have created a game using an engine such as Unity or Godot you may take these for granted, as most provide these turn key. Pixi and canvas require you to solve this yourself. One method for accomplishing this requires a bit of an illusion for the end users. I’ve provided an illustration below to visualize this.

Since the canvas (red) is fixed within the visible page canvas, it cannot actually move. Instead, effect of camera movement is created by moving the the contents rendered within the canvas area itself. This typically involves creating a container that houses your game world map (green). This container may also contain children, such npcs, creatures, and buildings (blue).

Instead of a small guy carrying a camera (ala Mario 64) following you around, it’s the map and it’s children that actually move! It’s a really neat trick that works very well in execution.

To actually handle this in the code, the Camera class simply controls how far a user has dragged from Point A to Point B and sets an offset value represented a x and y. These offset values are then read during the animation loop to update the position of the level container.

Game Objects

Game Objects are not inherent to Pixi. Instead they are a concept borrowed from Unity. These objects may present anything that exists within you game. This is typically handled by creating a containing element (like a group) that includes visual elements (such as an animated sprite), and pairs pairs this with the code containing the logic and rules for how the object should interact with the world.

An NPC (non-playable character) is a good example of one of these. In my game I have multiple NPC entities, each containing their animated sprites for visual idle and walking animations. But also includes a set of logic for handling what happens when you mouse over and click the entity.

A common convention for implementing this via code is using Object-Oriented Programming(OOP for short). OOP involves creating a structured Class that describes the properties of an object, as well as containing the logic for how it should function. One or more of these classes can be instantiated to created standalone copies of that entity.

Returning to that NPC example — my GameObject class describes each NPC’s properties such as name, which texture image to display, and other descriptive details. While also including its own logic, such as an onclick handler that triggers a dialog to appear.

This GameObject class contains all the core and shared properties and functional logic available to all entities in my game. I use this class to instantiate everything from NPCs, to crabs, to even the project pillars. Each instance has its own name, animated sprite reference, coordinate positions, and dimensions. They also share common functionality, via the class methods, that allow them to move on pre-defined paths and handle input events. Note that I do not use every feature on every entity though. Crabs don’t “talk” in my game…but they certainly could!

You might be asking yourself, though, what happens when you need properties or features outside the scope of the base GameObject class? This is where another key feature of OOP comes into play — class inheritance. To do this, I create a separate class that extends the GameObject. This means it inherits all properties and methods of the base class, while still allowing you to overwrite or extend the features specific for this unique type of entity.

I use this to great effect with Layla the Cat, the NPC-like entity that appears near the start of the game. Here I create a Cat class that extends the base GameObject class — which means she can still have her own name, animated sprite, and still trigger features such as dialogs. While still allowing me to overwrite and extend her base functionality. In this case, entities of the Cat type can flip the sprite on the X axis based on the mouse position. This makes her appear to follow the position of the mouse cursor on screen. This is a feature that’s unique to cats, since we know cats love to chase mice!

Wrapping Up

While there’s much more I’d love to cover, it may be keen to save those for later articles! However, if you’re curious to learn more about how the site was built, I invite you to explore the source code, which is available on Github:
GitHub - endigo9740/endigo-design: The portfolio of Chris Simmons

I offer a number of ways to contact me if you would like to follow up and ask me any questions directly as well.

For now thanks for reading and please enjoy the site!

Legacy Posts on Medium

Chris Simmons — Sat, 06 Aug 2022 21:14:33 +0000

I've used Medium to host my personal blog since 2015, however I'm in the process of migrating to here. If you would like to read any of my older posts, please check them out here:

https://medium.com/@endigo9740

All new posts will appear on here going forward.