
Remix is a new full stack JavaScript framework that gets rid of static site generation and also in other areas, does a few things differently than what we're used to from other frameworks.
It relies on React to render the UI and if you're familiar with Next.js you can certainly spot a lot of similarities. However, there are also clear distinctions, like
nested routes, handling of data fetching and data saving as well as error handling. Let's take a look at those concepts and how they compare to other techniques, currently used in popular frameworks.

## Application structure and routes

The easiest way to get started with a new Remix project is by installing it through npx and following the interactive prompts:

```bash
npx create-remix@latest
```

Once we're done with that, our project's structure is already set up for us and we're good to go. If we compare Remix to Next.js, we'll see that with Remix we're also
writing client side and server ide code inside our route files. However, Remix gives us a little more control to fine-tune things like caching and this also shows in having
two separate files for handling requests  — `entry.client` and `entry.server` that represent our entry points and therefore determine
what's run first on the server and client respectively. We also get a `root.tsx` which holds the root component to our app and renders the `<html>`, first `<meta>` tags, and so on.

<Console buttons={false}>
    <div className="console-item-wrap">
        <div className="output">├── ...</div>
        <div className="output">├── app</div>
        <div className="output">│   <span className="pl-3">├── entry.client.tsx</span></div>
        <div className="output">│   <span className="pl-3">├── entry.server.tsx</span></div>
        <div className="output">│   <span className="pl-3">├── root.tsx</span></div>
        <div className="output">│   <span className="pl-3">├── routes</span></div>
        <div className="output">│   <span className="pl-3">│   <span className="pl-3">└── index.tsx</span></span></div>
        <div className="output">│   <span className="pl-3">├── styles</span></div>
        <div className="output">│   <span className="pl-3">│   <span className="pl-3">└── global.css</span></span></div>
        <div className="output">│   <span className="pl-3">└── utils.server.tsx</span></div>
        <div className="output">├── jsconfig.json</div>
        <div className="output">├── package.json</div>
        <div className="output">├── public</div>
        <div className="output">├── remix.config.js</div>
    </div>
    <div></div>
</Console>

We also see a framework-specific `remix.config.js` which allows to to configure a lot off different details about oour application, such as the default public directory, development ports and much more.

## Nested routing
A very neat mechanism in Remix is the ability to render parts of a page based on the route we're on. When thinking of other frameworks, this would come down to
either a separate route with its own `index` file or specifically matching a route to one or more components. We're used to binding parts of our URL to different routes or components already — the way Remix does it, is best described as nested layouts, where
each part of the URL is by definition bound to a route file. Here's an example from their official site.

<img src="/storage/remix-nested-routes.png" className="img-fluid mb-4" alt="Remix JS nested routes"/>

The route shown above (`/sales/invoices`) would therefore be represented by three files
- `routes/sales.jsx`
- `routes/sales/index.jsx`
- `routes/sales/invoices.jsx`

Our first file is the wrapper that gets called first and based on the rest of the URL decides which "sub-components" should be rendered. The initial state
would be `routes/sales/index.jsx` and when navigating to /invoices, our wrapper pulls in the code from `routes/sales/invoices.jsx`.
The way this is realized in code is not through regular components, but through an `<Outlet />` which is part of `react-router-dom` and allows for this mapping
of nested layouts to routes (route components) rather than regular components.

Under the hood this allows Remix to preload the different parts on a page, which makes it *really* fast and lets us eliminate loading states as much as possible.
There are probably some more interesting things we can do here that I haven't fully explored yet.

## Styling pages and components

Styling components is fairly straightforward with Remix, because it's very close to how it works on the web since forever. Remix brings
its own `LinksFunction` which can be used to import CSS files on a per-route basis. That's also where we have to be a little careful and separate
our CSS into global CSS that should be available to every route and specific CSS that will not be loaded outside a certain route at all.

```JavaScript
import stylesUrl from "../styles/index.css";

export let links: LinksFunction = () => {
  return [{ rel: "stylesheet", href: stylesUrl }];
};

export default function IndexRoute() {
  return <div>Index Route</div>;
}
```

Once again Remix relies heavily on how the web already works, so if we wanted to use preprocessors or frameworks like Tailwind, we'd want to 
pass the compiled resources paths to Remix, just like we would with vanilla CSS files.

## Loading data

To get data inside a route component in Remix, we can use a `loader`, which is just an async function that returns the requested data.
Inside our components, we can then access it through a hook called `useLoaderData`.

```JavaScript
import { useLoaderData } from "remix";

export let loader = async () => {
  return getData(); // does the heavy lifting, DB calls etc. and returns data
}

// Component function starts here
export default function Component() {
    let allData = useLoaderData(); // data is now available inside our component
}
```

Note that the function is always called `loader` by convention and is only executed server-side, which means we also have
access to all `node` features and libraries to connect to databases and fetch data, like we're used to on the server.

If we're passing parameters to our routes, like a dynamic URL often times requires, the loader also has access to that, by passing
in the request parameters like this

```JavaScript
export let loader = async ({ params }) => {
    return params.slug
}
```

## Storing data
If we want to send new user-generated data back to the backend, to save it to a database for example, Remix lets us use so-called `actions`.
Actions rely on forms for the actual data input and are also only executed server-side, despite being in your route file.
The functions are — again by convention — called `action` and can also trigger (return) a redirect. Let's look at an example.

```JavaScript
export let action = async ({ request }) => {
  let formData = await request.formData()
  let title = formData.get("title")
  let slug = formData.get("slug")

  await createPost({ title, slug }) // actual call to store data...

  return redirect("/home")
}

export default function NewPost() {
  return (
    <Form method="post">
      <p>
        <label>Post Title: <input type="text" name="title" /></label>
      </p>
      <p>
        <label>Post Slug: <input type="text" name="slug" /></label>
      </p>
      <button type="submit">Create Post</button>
    </Form>
  );
```

We see that the `action` function takes the `request` as a parameter and thereby has access to everything our form sends over to the server.
From there we're free to use any `node` code to store our data.

## Handling errors
The way Remix handles errors is quite unique, as it allows us to create `ErrorBoundary`s that will be shown in case something with our route 
components didn't work as expected and an error is thrown. That way, if we're using Remix's nested routes, we might see a single <Outlet /> throwing
and error, but not necessarily the whole page. The smart thing about error boundaries is that they bubble up (the routes) to the closest error boundary.
So the easiest case would be having one error boundary at the root level, comparable to a full 404. However, the image below nicely
demonstrates how having multiple small error boundaries (one per route component for examaple) can leave the rest of an application intact.

<img src="/storage/error-boundary.png" className="img-fluid mb-4" alt="Remix JS error boundary"/>



```JavaScript
export function ErrorBoundary({ error }) {
  return (
    <html>
      <head>
        <title>Something went wrong!</title>
        <Meta />
        <Links />
      </head>
      <body>
        ... anything we want to let the user know goes here
      </body>
    </html>
  );
}
```
Implementing an error boundary  is as simple as adding an `ErrorBoundary` function to our route components as shown above.

## Further reading
At the time of this writing, Remix has really only been released yesterday, so there is still a lot to learn and some things
might even change drastically with newer versions.

If you're looking for more resources and want to dive deeper, there's a fantastic tutorial on <a href="https://remix.run/docs/en/v1/tutorials/blog">building a blog</a>
and a small <a href="https://remix.run/docs/en/v1/tutorials/jokes">dad jokes applicaiton</a> in the <a href="https://remix.run/docs/en/v1">Remix docs</a>.

A brief introduction to Remix JS

When building complex applications it's always a good idea to take a step back and think through architectural choices from the get-go. One pattern that really forces us to do that is an event system or the closely related PubSub pattern, which we'll take a closer look at in this article.

The biggest advantage of this pattern is that we get to decouple parts of our application and have them talk to each other through a middleman, or in simpler cases, we just broadcast an event and have a listener that executes when the event is triggered. A big advantage of this pattern is that all our events get routed through *the same* logic before being picked up by the listeners, which allows us to do some extra work and extend all events in our system later on.

Let's clear up some terms before we move into code. Given a simple example like on-page notifications, our core functionality that will be executed can be a simple `alert()` . Now to not call it directly but actually use an event system, we need to implement an `Observer` that will listen to incoming events, delegate our invocation and call all the right functions for us. 

```javascript
const Observer = function() {
    var self = this
    self.events = {}

    return {

        dispatch: function(eventName) {
            // We already know we want to be able to call our observer and
            // it will need to dispatch the actual event
        },

        on: function(eventName, callback) {
            // Our observer will need to be able to listen itself for incoming events
            // that we'll notify the listeners about (via callbacks)
        }

    };

}();
```

This Observer pattern above will be our middleman and listen to events when we define them in like this: `Observer.on('eventName', callback)`. At the same time, it allows us to trigger those events via `Observer.dispatch('eventName')` whenever we want the receivers to be notified. The most important part inside our observer is the `events` object  that will hold all callbacks in the form of `{[eventName: callback()]}`. Let's go ahead and fill the functions with code to see how the Observer pattern works in action.

## Implementing the observer pattern

```javascript
const Observer = function() {
    var self = this
    self.events = {}

    return {

        dispatch: function(eventName) {
            var events = self.events[eventName]
            events.forEach((callback) => callback())
        },

        on: function(eventName, callback) {
            if (typeof self.events[eventName] === 'undefined') {
                self.events[eventName] = []
            }

            self.events[eventName].push(callback)
        }

    }
}()
```

The `on` method is used to register our events and we need to call it before we can actually dispatch an event. it takes an event name and a callback as parameters and pushes both into our events object as described above.

Our `dispatch` function that will be triggered to fire off an event, takes an event name as the only argument. In fact, this should be the same event name that we previously added to the events object when we registered the event with our `on` function.

And with that, we have a working event system that can be used like this:

```javascript
// Listen to an event
Observer.on('testevent', function() {
    console.log('This will be executed when our event fires')
})

// Fire our event
Observer.dispatch('testevent')
```

Keep in mind that this is a very minimal custom event system and there are more mature systems out there. If we were to expand this minimal example, we'd need to take proper care of error handling, unbinding events (`off` function to our `on`), and implement some general checks around passed arguments.
   
If you want to dive deeper into the observer pattern or Pub Sub, here's a great resource for further reading with implementation details: [https://addyosmani.com/resources/essentialjsdesignpatterns/book/#mediatorpatternjavascript](https://addyosmani.com/resources/essentialjsdesignpatterns/book/#mediatorpatternjavascript)

How to write a custom event system in JavaScript

Colors are a pretty fundamental part of building anything for the web and one of the most important parts of a coherent design. If done right it can contribute to brand recognition and generally convey a certain *feeling* people have when interacting with sites / products. Colors are also important to get right because they can make your design inaccessible to a large number of people with disabilities or just bad eyes. 👵

A lot of times developers underestimate their knowledge about colors. Usually we've already encountered many concepts around colors in school when we were still young and just forgot about them or didn't connect the dots to apply them to designing yet.

Let's jump in and look at some of the basic concepts!

## Color Harmonies

This is one of those concepts you've probably heard of before. In fact you might know a few color harmonies like monochromatic, complementary, analogous. It's a great starting point, because color harmonies help pairing colors together in a proven way that *will* look good.

Color harmonies basically describe the position colors have to each other on the color wheel. Analogous colors for example are located right next to each other, while complementary colors are opposite, canceling each other out. Most design tools already have ways that allow you to play with color harmonies.

![image](/storage/colors.png)

Let's say you have picked a brand color (orange: #ED8B3D) and are now looking for colors to match with it. Color harmonies to the rescue. [Here's a handy tool](https://www.sessions.edu/color-calculator/) that allows us to try out different color harmonies and a look at monochromatic and analogous colors already gives us a nice palette of matching colors, sweet! Of course you don't have to stop there and can absolutely tweak the analogous colors as desired. However if you're kinda lost and need a place to start, color harmonies are always worth considering.

## Neutral colors

You can think of neutral colors as a sidekick to your primary color – your hero. The cool thing about neutral colors is – ***drumroll*** – their neutrality, which means you can't really tell what the underlying color is. They usually make your primary color stand out and are themselves soft and less visible, which helps put emphasis on your primary color(s).

Depending on how many colors you're already using and whether you're using a lot of whitespace or not, it can be a good idea to use graphic elements with neutral colors purely to fill space without it all being whitespace.

## Less colors

One of the most common mistakes when using colors, is using too many colors at once. Sometimes this happens over time and you end up with six different shades of blue, sometimes people don't give their colors enough thought. Often this  makes it harder, because there is no way to make all those different colors play nice together.

You can think of it like cooking. You'd never use all the spices in a single dish but instead only use those few that can actually help improve the taste of a dish. Oftentimes using less colors but using them consistently, is the way to go.

When you're wondering *which* colors to choose it makes sense to think about what kind of feeling you want to evoke in people looking at your website or app. Start with two colors and decide on a base trait, like *reliable, fun, bold, minimal* and try adding more colors slowly while keeping up those overall feelings. If a color doesn't fit the overall impression you want to achieve, don't use it.

## Contrast

Contrast is extremely important, especially a color's lightness. It will determine how accessible your design is and how quickly people can gather actual information from your copy. Worst case, it will determine if people can read your message at all or if something in your design is completely illegible or invisible, making for a frustrating experience.

A general rule of thumb is, when it works in greyscale, it will also be legible in color. However there are cases where you want to make sure that what you're designing is actually accessible to everybody. A really handy tool (which costs little money) is the [Mac app call contrast](https://usecontrast.com/). It lets you pick two colors and calculates a legibility score, which allows you to reliably choose colors with a contrast high enough for everybody to read.

Contrast, if used incorrectly can however also contribute to a less balanced layout, because different colors can clash to hard. So you should always keep the overall harmony in ind as well when going for contrasting colors.

## Color is subjective

Lastly, color is a very subjective topic and you should probably not listen too closely to any random article on the internet. 😅 Different people perceive colors differently and there is no exact way of getting this right. At the same time that's the reason why sticking to those general guidelines provided above can be really helpful!

How to suck less at using colors

Most folks know about the `box-shadow` property and use it a lot already in their CSS, however there are certain scenarios where a box-shadow doesn't give us ideal results. There is however also a CSS filter called `drop-shadow` that let's us do some cool things we cannot achieve with box-shadows. It's currently supported in all modern browsers and definitely worth a look. Here's how a drop-shadow looks like in CSS:

```css
.selector {
  filter: drop-shadow(0 10px 12px rgba(0, 0, 0, 0.4));
}
```

## What's the use case?

While box-shadows are sufficient in most scenarios, they can only give us a shadow around the exact shape of an element, which is usually angular or round due to a `border-radius`. With drop-shadows however, we can cast a shadow around elements and even images that stays in direct proximity to the non-transparent parts of the image or element.

So in essence this works on regular HTML elements, SVGs and also transparent PNGs. Here's an example:

```css
.triangle {
	width: 180px;
	height: 180px;
	background: linear-gradient(45deg, yellow 50%, transparent 50%);
	filter: drop-shadow(0.2rem 0.2rem 1rem rgba(0,0,0, 0.8));
}
```

![image](/storage/triangle.png)


One downside we can spot in the syntax here is that we're not able to set a spread parameter the shadow should have. Other than that, the parameters match what we're used to with box-shadows (x-offset, y-offset, blur, color).

The real magic however becomes more obvious when we apply a drop-shadow to a transparent PNG, which gives us the same effect as seen above, instead of just putting a shadow on the whole image or container, we see the shadow aligned to the filled lines and shapes.

```css
<style>
    img {
        filter: drop-shadow(0.5rem 0.5rem 0.5rem rgba(0, 100, 200, 0.7));
    }
</style>
<img src="./waves.png">
```

![image](/storage/waves.png)

A nifty alternative to box-shadows

As developers, we often use a lot of libraries and packages and know very well how to use them. We're used to it, because packages and libraries are a huge part of the ecosystem and a great way to speed up development and free us from rather complicated, repetitive tasks.

When it comes to writing libraries or reusable modules from scratch, however, it's not always so clear where to start and how to make sure our libraries are not breaking anything else in an application. Making sure we're using our own scope, function names and such are only part of what makes a good module. Let's take a close look at how to write our own libraries that can be plugged into different projects without worrying about breaking any existing code.

When we're  the developer who's using a library, we care about simplicity and ideally want to understand what's going on by the name of the function we're calling alone. We're also very used to a certain kind of syntax, which probably looks something like this:

```javascript
Library.init({
	option: "option"
})

Library.doThing(arg1, arg2);

```
   
We can initialize our library with some options and then just call pre-defined and hopefully well-documented functions on the library, possibly passing in some arguments. Sometimes we'll get a return value or promise out of that function call, other times there might be a change in the DOM as a result of calling the function. Either way, we're very used to that kind of syntax when using libraries and so when writing our own we should try to imitate that.

The object literal notation in JavaScript lets us do just that. It also has the added benefit of keeping everything inside our object and therefore we're not putting anything related to our module on the global scope, except the object itself.

```javascript
var Module = {
	// Our Object literal can hold simple variables
  someProperty: "someValue",
	
	// We can also declare further objects inside our object
  config: {
    reload: true,
    language: "en"
  },

	// And of course declare regular, named functions
  saySomething: function (word) {
    console.log(word);
  }
};

Module.say("hi");
```

## The module pattern

We can take the object literal approach one step further with the module pattern, which allows us to declare public and private functions and variables, using closures. We're basically defining a public API that our library/module exposes while keeping other internal states, variables, and functions private and thereby inaccessible from the outside.

```css
var Module = (function() {

  let secret = 0;
	let publicNumber = 2;

  function privateFunc(a) {
    console.log(a);
  }

	function addOne(b) {
		return b + 1;
	}

  return {
		addOne: addOne,
		publicNumber: publicNumber
  }

})()

Module.addOne(Module.publicNumber);
```

As shown above we can now explicitly define what functions and variables should be accessible from the outside by returning an object with only those things that we want the outside to know about. This is great because we can hide away a lot of the heavy lifting or things we don't want to expose because calling them directly would break things. We're basically exposing a little API that is consistent and well structured.

While this pattern is great for frontend libraries and modules, it is also super convenient when writing modules in node. In fact most modules naturally follow this pattern in a way, because they have a (default) export statement. Here's how we can utilize the same structure in node

```javascript
import db from '../models/index.js'

const MessageController = {
    sendMessage: async function(message) {
				// ...
		}
        
    receiveMessage: async function(message) {
        // ...
    },
}

export default MessageController
```

That way we get to keep the clean structure of our object literal / module pattern while being able to just import our module like we would with other modules. We also get to chosse what to export explicitly while we can keep other functions private. Here's how we'd import the above module in node:

```javascript
import MessageController from './controllers/message-controller.js';
```   

Overall we get a lot of benefits when writing our modules that way, such as high reusability, a clear structure, no naming collision with the outside, control over private/public parts of our module and even a shared but encapsulated state for things inside our object literal.

Stay tuned for a look at other useful JS design patterns like singletons or the factories.

Writing reusable modules and libraries in JavaScript

As developers, when using modern UI libraries and frameworks like React, Vue or Web Components, we often like to write our CSS specifically for a single component. That way we can keep our global styles rather manageable and get the additional benefit of a well-structured CSS architecture. At the same time, design systems these days also consist of individual, reusable components that can be used in multiple places. Sometimes these components are put together in UI / pattern libraries, which are a part of a full design design system. One example of this are the [Tailwind UI](https://tailwindui.com/) components, which are customizable and ready to use.

In this article, we'll take a closer look at how we can build our own self-contained and composable components that can be used as part of a larger design system and what we need to pay attention to, in order to create truly **context-independent** layout components.

## Preventing the worst: side effects

The biggest hurdle when writing components from scratch is that we have no knowledge of the context they will be used in. In fact we want to create components that assume nothing about the context they will be used in. That means we need to make sure not to produce any side effects, like additional margins, or we risk breaking the entire layout. Here's a tiny example of a bad component to illustrate those side effects:

```css
.component-1 {
  margin: 2rem;
}

.component-2 * {
  margin: 2rem;
}
```

While it looks fairly simple, it also illustrates how those side effects could look. Using that component in another context, like a list, we'd suddenly push whatever comes above or below it in the layout away by `2rem`. That's not ideal! Instead of applying margins to our component or all children, what we should do is have an unstyled wrapper that doesn't assume anything about where it's used and doesn't create side effects like margins to the surrounding elements. Let's see how we can do that.

```css
.component > * + * {
  margin-top: 1.5rem;
}
```

Now with the `.component` being our outer container that we should not apply any styles to, we now apply them to its children. And of those, we're only giving them a margin if they're preceded by another element – that means out first child will not have a `margin-top` applied, resulting in no side effects for our component overall. We can stack as many children as we want, without affecting any surrounding elements.

## Creating more complex components – two columns

Now that we have a first of idea how we can keep our components isolated, let's look at a more complex component that needs to adjust base on the context it's used in as well as the general screen size. While [container queries](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Container_Queries) aren't fully here yet, they will likely make this example easier in the future. For now, we'll rely on `flexbox` to determine the components layout, depending on the context. Here's what we'll try to achieve – a classic media object with two columns:

![image](/storage/media-img.png)

Because we'll need to break the component's layout into two rows on smaller screens, we'll start out by giving our container the `flex-wrap: wrap` property, which allows the content to flow both ways (horizontally on larger screens and vertically on smaller screens).

```css
.media-element > .media-element-wrapper {
    display: flex;
    flex-wrap: wrap;
}
```

Notice that we're again not applying any styles to our outer element, in order to prevent any side effects. Instead, we wrap our child elements in a `.media-element-wrapper` container. Next, we need to decide which side of our components is supposed to shrink and which when to break. In this example, we'll let the image (the left side) stay the same until a certain breakpoint is reached, while the right side adjusts in its size all the time. We can do that by giving our left-side element  a set `flex-basis`, our right side gets a `flex-basis` of zero. We could as well switch those, so the left side resizes and the right one stays a certain size.

```css
/* our left side */
.media-element-media {
    flex-basis: 280px;
    flex-grow: 1;
}

/* our right side */
.media-element-content {
    flex-basis: 0;
    flex-grow: 999;
    min-width: calc(50% - 1rem);
}
```

With that setup, we're basically done with the component. the left side will stay the same size, until the viewport reaches a min-width of `280px`, which will break the component's layout into vertical alignment. Here's the matching HTML for an input field left and a button on the right side.

```css
<div class="media-element">
    <div class="media-element-wrapper">
        <div class="media-element-content">
            <input type="text" placeholder="Type something..." />
        </div>
        <div class="media-element-media">
            <div class="button">Click me</div>
        </div>
    </div>
</div>
```

As described above, we managed to build this component to be responsive, self-contained, and without side effects. So no matter where in a larger set of components it is used, it doesn't interfere with any elements outside our wrapper. Now if we wanted to style our component and the elements inside the wrapper, we can do so more freely. Of course, spacing should still only happen inside the element, but we can always rely on our adjacent sibling selector or a more recursive version of it to space things evenly:

```css
.media-element > * > * {
    margin: 0.5rem;
}
```

## Wrapping up

When building more components for a complex system, it is a good idea to re-use "atomic components" or patterns, like the adjacent sibling selector and to make sure to regularly look at how the components actually play together on a page. Even when avoiding side effects, everything also depends on the containers our components are used in.

It's also important to set some general rules, like applying a sane `box model` to all elements, to ensure all components will handle spacing consistently.

```css
* {
  box-sizing: border-box;
}
```

This article is just a small example of a single component and there's still a lot more that makes a good design system. If you want to dig deeper, here are some further articles worth reading.

[https://www.invisionapp.com/inside-design/guide-to-design-systems/](https://www.invisionapp.com/inside-design/guide-to-design-systems/)

[https://bradfrost.com/blog/post/css-architecture-for-design-systems/](https://bradfrost.com/blog/post/css-architecture-for-design-systems/)

[https://designsystemsrepo.com/design-systems-recent/](https://designsystemsrepo.com/design-systems-recent/)

## Code
The full code from this example can also be found on [GitHub](https://github.com/allroundio/css-components-example) and on [CodePen](https://codepen.io/allroundio/pen/wvJWWEQ)

Writing self-contained layout components in CSS

We all need some inspiration sometimes. Luckily we have access to a lot of great tools and tons of resources out there that can help us build better things for the web. Here's a short collection of tools and references that can help you speed up your designs or overcome a lack of inspiration.

## Website inspiration
Pages in this category are great to get unstuck if you don't know how to design a certain section or element. See what's hot right now and get inspired by what's out there.

- [https://onepagelove.com/](https://onepagelove.com/)
- [https://siteinspire.com/](https://siteinspire.com/)
- [https://httpster.net/](https://httpster.net/2021/mar/)
- [https://www.awwwards.com/](https://www.awwwards.com/)
- [https://landingfolio.com/](https://landingfolio.com/?offset=2)
- [https://screenlane.com/](https://screenlane.com/)
- [https://www.lapa.ninja/](https://www.lapa.ninja/)
- [https://land-book.com/](https://land-book.com/)

## UI / UX Interactions
below are some great collections that display specific UI interactions or flows inside applications, without much regard for the bigger context.

- [https://littlebigdetails.com/](https://littlebigdetails.com/)
- [https://uxarchive.com/](https://uxarchive.com/)
- [https://tympanus.net/codrops/](https://tympanus.net/codrops/)

## Fonts
Good typefaces can make or break a design. Here's a small collection of great resources to get free and paid fonts.

- [https://www.typewolf.com/](https://www.typewolf.com/)
- [https://fonts.google.com/](https://fonts.google.com/)
- [fonts.com](https://www.fonts.com/)
- [https://www.myfonts.com/](https://www.myfonts.com/)
- [https://typetype.org/](https://typetype.org/)
- [https://klim.co.nz/retail-fonts/](https://klim.co.nz/retail-fonts/)
- [https://pangrampangram.com/](https://pangrampangram.com/)

## Icons / SVG
Finding good icon sets that contain just the right icons for a project can be challenging. Here's a small selection of awesome sets and sites where you can find more.

- [https://iconsvg.xyz/#](https://iconsvg.xyz/#)
- [https://feathericons.com/](https://feathericons.com/)
- [https://streamlineicons.com/](https://streamlineicons.com/)
- [https://lineicons.com/](https://lineicons.com/)
- https://ui8.net/category/icons
- [https://www.glyphicons.com/](https://www.glyphicons.com/)

## Prototyping / Designing
Get your design right by starting with early mockups and prototypes, or move straight into powerful design tools like Figma and Sketch.

- [https://sketch.com/](https://sketch.com/)
- [https://www.figma.com/](https://www.figma.com/)
- [https://www.framer.com/](https://www.framer.com/)
- [https://balsamiq.com/](https://balsamiq.com/)
- [https://www.uxpin.com/](https://www.uxpin.com/)
- [https://gomockingbird.com/home](https://gomockingbird.com/home)

## Other Tools
Some more useful tools that help you generate patters, blobs, encode SVGs and match fonts ✨

- [https://www.heropatterns.com/](https://www.heropatterns.com/)
- [https://www.blobmaker.app/](https://www.blobmaker.app/)
- [https://yoksel.github.io/url-encoder/](https://yoksel.github.io/url-encoder/)
- [https://meowni.ca/font-style-matcher/](https://meowni.ca/font-style-matcher/)

Useful frontend and design resources #1

Just like in the golden days of Bootstrap, popular CSS frameworks like Tailwind involve the danger of many websites looking very similar. Especially with the UI components released as [Tailwind UI](https://tailwindui.com/) it is super easy to get going with a beautiful default for almost every part of a website or application. Don't get me wrong, those are beautiful components throughout and using them to get something up quickly makes a lot of sense. The downside however is that your sites and applications will look very generic and close to others on the web, which means you're missing the chance to leave a lasting impression with you design and gain some brand awareness that a unique design can give.

The irony is, Tailwind is really well suited as a base UI system which is also **fairly easy to customize and make your own.** A lot of times people are underestimating the benefits of unique designs and put the customization somewhere in their backlog of things to do later. Let's change that! Let's take a look at how we can make Tailwind look different while keeping all the underlying goodies.

If you've never worked with Tailwind CSS or utility classes before, there's an introduction article I wrote [over here](https://allround.io/articles/introduction-to-tailwind-css-and-utility-classes). If you're already familiar with Tailwind, great! Let's dive right in!

## Getting started

To get started, let's set up a very basic project that consist of nothing but bare HTML / CSS and JavaScript. Setting up Tailwind with Frameworks like Vue, Laravel and others might vary, because there are better ways of integrating it into the existing build steps. It's worth checking out the official documentation, to get instructions on how to do that – it's pretty good. 

We'll keep it simple and start by creating the bare minimum we need from the terminal.

```bash
# Create our main HTML and CSS files as well as a bare PostCSS config file
touch index.html main.css postcss.config.js

# Initialize project with npm
npm init -y

# Install tailwind with PostCSS, autoprefixer and PostCSS CLI
npm install -D tailwindcss@latest postcss@latest postcss-cli autoprefixer@latest

# Create a minimal Tailwind config file
npx tailwindcss init
```

Next, we need to add the following base config to the PostCSS configuration file we just created, so it knows what to do when compiling our CSS. In general Tailwind is a PostCSS plugin and you can absolutely use it with other preprocessors too.

```javascript
// postcss.config.js
module.exports = {
  plugins: {
    tailwindcss: {},
    autoprefixer: {},
  }
}
```

Finally we want to create an npm script that allows us to compile everything together by typing a single command. This is our build step for this tutorial and as mentioned above, when integrating Tailwind in different frameworks this might look different for you.

```javascript
// package.json — to compile, run:
// $ npm run compile
"scripts": {
    "compile": "postcss main.css -o compiled.css"
}
```

Great! Now we just need to make sure we include the `compiled.css` in our HTML file and that's all we need in terms of boilerplate. Time to start the actual customization.

When it comes to styling the base theme and changing defaults like colors, margins, border radius, fonts and such there is a single file we can use to customize all of that, and that's the `tailwind.config.js` that was just created automatically in our setup step above. By default, it looks like this:

```javascript
module.exports = {
  purge: [],
  darkMode: false, // or 'media' or 'class'
  theme: {
    extend: {},
  },
  variants: {
    extend: {},
  },
  plugins: [],
}
```

And if you're wondering why it's empty and where the actual default theme is coming from, or just want to dig a little deeper into the defaults, [here is a link to the defaults](https://github.com/tailwindlabs/tailwindcss/blob/master/stubs/defaultConfig.stub.js#L7) that get applied if we don't customize anything. However, that's exactly what we're here for – customizing. So let's start doing that by adding our own brand color:

```javascript
module.exports = {
  purge: [],
  theme: {
    extend: {
      colors: {
        primary: {
          light: '#FFF538',
	        DEFAULT: '#FFC233',
	        dark: '#C19A32',
        },
      },
    },
  },
  variants: {},
  plugins: [],
}
```

In order to be able to use this new color class in our HTML, we'll have to run our build step once, by calling our PostCSS compiler from the terminal, like we defined above:

```bash
$ npm run compile
```

Sweet, we now have a new class at our fingertips called `primary` which we can use with all the prefixes and modifiers we defined above (light / dark). Let's try it out and see it in action, by applying the new class to a button element and making the button darker on hover:

```html

<button class="btn bg-primary hover:bg-primary-dark transition p-4 my-4">
	I'm a button
</button>
```

## Looking at spacing and breakpoints

Another important aspect of every layout that we might need to modify or extend, depending on what we want to create are spacings and breakpoints. Luckily for us, creating them is not a whole lot harder than adding our own custom colors, like we just did above. There is a gotcha when it comes to breakpoints however, as they need to be declared in the right order. Let's put it all together and jump into the details:

```javascript
// Let's see why we need this in a second!
const defaultTheme = require("tailwindcss/defaultTheme");

module.exports = {
    purge: [],
    theme: {
        extend: {
            colors: {
                primary: {
                    light: "#FFF538",
                    DEFAULT: "#FFC233",
                    dark: "#C19A32",
                },
            },
			// Here we're adding a new breakpoint class
            screens: {
				xs: "475px",
                ...defaultTheme.screens,
                laaarge: "1600px",
            },
						// Here we're declaring our new spacing classes
            spacing: {
                "small-bear": "2rem",
                "mama-bear": "15rem",
                "papa-bear": "30rem",
            },
        },
    },
    variants: {},
    plugins: [],
};
```

So just to recap what we just added: there's a new require statement at the top and two new blocks for the *spacing* and breakpoints (*screens*). Let's look at the spacings first, because they're rather similar to the color classes we defined earlier. In fact, they work just like our colors, except they don't take any modifiers like `light` – because we don't need that for our spacings. So with those newly defined spacings, we can now add big margins, paddings etc. to our layout. By using the class `m-mama-bear` for example, we'd add a margin of `15rem` to all sides.

When it comes to breakpoints there's a small caveat when creating our own ones, because just like in regular CSS (when writing media queries) the order matters. That same principle applies to Tailwind breakpoints: If we want to declare a breakpoint that is smaller than the default ones, which start at `sm` 640px, we have to make sure to declare it *before* the default breakpoints. That's why in the example above, we're using the require statement at the top to grab all the default breakpoints and then when setting up our breakpoints, we're inserting them after our new `xs`. If we don't do that, our breakpoint will get overwritten just like media queries would be in a regular CSS file. Order matters!

## Applying and extending base styles

So besides creating our own utility classes, we want to take a look at extending the Tailwind base styles. Because Tailwind does a full reset, you can quickly see that a regular `h1` for example doesn't look much like a headline anymore, unless you start applying classes. That's by design and actually gives us a lot of flexibility. When we design complex components however, we might want to have base elements styled a certain way, even without applying a whole lot of classes. A good way of doing that is using the `@apply` rule. It allows us to apply a set of rules to a given CSS selector like this:

```css
/* Require the basic Tailwind CSS */
@tailwind base;
@tailwind components;
@tailwind utilities;

h1 {
  @apply text-2xl; /* Applying our text-2xl rule on the h1 */
	@apply font-bold;
	@apply text-primary; /* We can even apply our custom classes! */

	font-family: monospace; /* And we can mix with regular CSS */
}

h2 {
  @apply text-xl;
}

```

Now without applying any classes directly in our HTML, we have added the predefined properties to our elements right in the CSS. That allows us to give every element a sane default without leaving our predefined system or repeating ourselves. This is great for more complex elements that require custom CSS or edge-cases where we don't want to make a whole new utility class, but just overwrite parts of our system.

## Using and creating presets

Now that we've got a good first look at how to technically customize Tailwind, one more concept that is really worth knowing about is how to use presets. In fact the default styles Tailwind ships with are just a preset as well. If we want to keep a single source of truth for things like color, font and such and work on different projects for the same client, presets are super helpful. They allow us to use a single `tailwind.config.js` as the base and extend it, just like we just extended the default preset. So in fact, every config file is a preset itself. We can use other presets as the base for our project by stating it in our config file as follows:

```javascript
// tailwind.config.js
module.exports = {
  presets: [
    require('./masters/tailwind-base.js')
  ],
  // ...
}
```

Because our presets variable is an array, you can already guess that we can also use multiple presets as our foundation and build on them. The important thing to keep in mind with the whole preset approach is that if there are overlapping rules defined, they will get overwritten in order you're requiring them — just like in regular CSS.

## What's next?

There's still a lot we haven't covered yet, even though all of the above already sets us up with everything we need to really create fully custom layouts with Tailwind. If you want to dig deeper, I'd recommend looking into **plugins** and how to optimize Tailwind for use in production.

Here's a great article on [creating a useful plugin](https://www.nick-basile.com/blog/post/how-to-write-a-plugin-for-tailwind-css/)

and the official documentation is a good starting point to learn [more about optimizing for production](https://tailwindcss.com/docs/optimizing-for-production).

Lastly, you can also grab the full source code of everything we just created above over on GitHub: [https://github.com/allroundio/tailwind-example](https://github.com/allroundio/tailwind-example)

Customizing Tailwind CSS

If you haven't checked out Tailwind CSS yet or don't know what all the buzz regarding utility classes is all about, this article is for you. We'll take a first look at the advantages and get our hands just dirty enough to know what makes Tailwind a great CSS framework and what alternatives there are.

In general when talking about utility classes, you can think of primitive utilities that don't do much individually. In fact they shouldn't do much by themselves but work well when combined with other utility classes. The goal is to have a set of pre-existing classes that we can use to style HTML without writing a lot of custom CSS, which allows us to move faster and re-use those classes as much as possible.

## Keeping it simple

We'll keep it simple and skip all the build-steps and setting up our tooling for now, even though it's an important and powerful part of Tailwind's magic. For now we'll just look at the concept of utility classes and see how they can help us reduce the required amount of custom CSS and allow us to style our content faster overall.

So instead of setting up a build step, we'll start by simply requiring the Tailwind stylesheet into a blank HTML file. That's all we really need to get going.

```css
<link href="https://unpkg.com/tailwindcss@^2/dist/tailwind.min.css" />
```

Let's start by looking at a `<button>` element and make it pretty! First, let's make sure it has a `background-color` —> In Tailwind we get a lot of predefined [background colors](https://tailwindcss.com/docs/background-color), all created with rgba values, which allows our utility classes to change the colors based on the alpha, which we can set with a simple number in our class names like this:
  
```html
<button class="bg-blue-700">I'm a button</button>
```
  
In this case, 700 sets the alpha and we can go lighter and darker from 50 to 900, where 50 is the only smaller step and the basic rule is that we can increase or decrease the alpha in hundreds. So if we wanted a lighter blue, we could set it to `bg-blue-500`. This is great, because it already gives us a clue how we can make use of this for our hover effect! Let's check that out.

In order to give our button a lighter blue on hover, we'll use one of Tailwind's prefixes: `hover:` and combine it with the background, we've just used above: `hover:bg-blue-500` 

Sweet! We have a button that changes its background color on hover! Let's improve it further, by adding a font-color that is easier to read on our blue background. Just like we set the background-color, we can use the class `text-<color>` to set a color on our element. Again like the color palette for backgrounds, Tailwind comes with a set of [predefined text-colors](https://tailwindcss.com/docs/text-color) which can be adjusted by changing the alpha of the base color.

```css
<button class="bg-blue-700 hover:bg-blue-500 text-white">I'm a button</button>
```

*Side note: When using build tools we can also define our own colors, so we are not limited to the predefined palette.*

That's a pretty rad button already and we were pretty fast to get there. This simple button element already illustrates how utility classes can save us  a lot of time, as we have written exactly zero CSS so far, even though we changed the background color, text color and added a hover effect. And we're barely scratching the surface – let's dig a little deeper.

## Digging a little deeper

I'm a sucker for details when it comes to user interactions, so I'm already having a hard time looking at the button we just created. It needs a transition! Luckily Tailwind has our back and we can make use of multiple transition properties, or go with the `transition-all` property, which defaults to the following.

```css
transition-property: all;
transition-timing-function: cubic-bezier(0.4, 0, 0.2, 1);
transition-duration: 150ms;
```

Making sure we adhere to best practices around the `reduced-motion` property, we can even use a prefix called `motion-reduce:` to only show the transition when reduced-motion is not activated. Let's put that together real quick:

```html
<button class="bg-blue-700 hover:bg-blue-500 text-white transition-all motion-reduce:transition-none">I'm a button</button>
```

At this point you probably got the underlying idea of utility classes, utilizing a standardized way of naming with prefixes, the actual class and predefined and adaptable modifiers: `{prefix}:{class}-{modifier}`. One downside people complain about a lot with this expressive approach is that we're overloading our HTML that way and it actually becomes pretty unreadable. It's definitely a good idea to start formatting your HTML a little more according to that and let lines not run too long. The alternative however is probably a rather lengthy stylesheet, so there are always trade offs 🤷‍♂️

```html
<div class="..."
   id="...">
  Heya!
</div>
```

Before wrapping up, let's take a look at the bigger picture of building sites with Tailwind: Layout, spacing and responsiveness. Tailwind comes with a ton of handy classes to support us in all those areas like floats, flexbox and positioning classes, allowing us to build more complex components and layouts quickly. Let's take a look at a classic horizontal navigation bar using flexbox and centering things inside.

```html
<nav class="flex justify-between items-center px-16 bg-blue-700 text-white h-14">
  <h1>Navigation</h1>
  <ul class="flex justify-between w-56">
    <a href="#">
      <li>Link</li>
    </a>
    <a href="#">
      <li>Link</li>
    </a>
    <a href="#">
      <li>Link</li>
    </a>
  </ul>
</nav>
```

*There's a demo below the article.*

Now that wasn't too much to write and we got a pretty solid navigation bar! If we wanted to change things on smaller or bigger devices, we can make use of prefixes again. Tailwind, much like Bootstrap, comes with predefined breakpoints (media queries) that are named as follows:

- `sm` 640px
- `md` 768px
- `lg` 1024px
- `xl` 1280px

Those can be seen as replacements for media queries in your CSS and when introducing them, the unprefixed version we have used so far will only be applied **above** the prefixed version. So if we were to use a class with the prefix `md:bg-blue` and also have a class `bg-yellow` applied to the same element, the background would only be blue for everything above 768px (md) and yellow below that breakpoint.

Just like predefined breakpoints, Tailwind comes with a set of spacings for paddings and margins that can be applied to either one or multiple sides of an element, basically making it a great alternative to `margin-top: x;` and similar declarations. All spacing adhere to the following syntax `m{t|r|b|l}-{size}` which translates to a class like `mt-8` for a margin top of "8", where 8 translates to `2rem`. Those values are as mentioned predefined but can be adapted when using a real build step. It's definitely worth checking out the [Tailwind documentation](https://tailwindcss.com/docs) for exact values and in general a good idea to get a more in depth understanding of everything described in this article.

## Next steps and alternatives

A lot of the advantages of Tailwind actually come from using a build step and creating our own [configurations](https://tailwindcss.com/docs/configuration). This step allows us to define new colors, spacings, fonts, and much more! It's like keeping all the benefits of the utility-first approach but making it your own and adjusting it to your design and requirements. A lot of people seem to skip this step, which is why we see a lot of sites out there these days that use the default Tailwind styles. Don't get me wrong – that's not a bad thing! But you are missing out when not making use of those customizations. In fact, I think it is so important, I want to dedicate another full article to customizing Tailwind.

In the meantime, there are also other utility-first frameworks that came before Tailwind and there will probably be a bunch more to come. Here are some really interesting ones I recommend checking out.

[https://basscss.com/](https://basscss.com/)

[https://tachyons.io/](https://tachyons.io/)

[https://yogurtcss.netlify.app/](https://yogurtcss.netlify.app/)

[https://tedconf.github.io/shed-css/index.html](https://tedconf.github.io/shed-css/index.html)

[https://turretcss.com/](https://turretcss.com/)


*And lastly, here's a working demo to play around with, which contains the basic examples shown in the article.*
<iframe height="500" style={{width: '100%'}} scrolling="no" title="Tailwind CSS introduction" src="https://codepen.io/allroundio/embed/VwPWaJa?height=265&theme-id=dark&default-tab=html,result" frameBorder="no" loading="lazy" allowtransparency="true" allowFullScreen={true}>
  See the Pen <a href='https://codepen.io/allroundio/pen/VwPWaJa'>Tailwind CSS introduction</a> by Allround
  (<a href='https://codepen.io/allroundio'>@allroundio</a>) on <a href='https://codepen.io'>CodePen</a>.
</iframe>

Introduction to Tailwind CSS and utility classes

Using shadows is a great way to avoid klunky borders in otherwise light layouts and they've long surpassed being "just for decoration" elements in websites and apps alike. Especially when creating different levels of elevation that make some elements appear closer to the user than others – like a stack of elements – the use of shadows can make a big difference.

- In general the closer something is to the user, the more attention it will get, just like the closest car in traffic (like buttons)
- Smaller shadows that are closer to the elemet are great for capturing attention, while more diffuse and wide shadows are better suited to separate an element form its surrounding (like overlays)
- Inset shadows can help create a feeling of plasticity or let elements appear bend inwards

To make a layout with shadows as consistent as possible, we should make sure to pick an imaginary lighting position and stick to it whenever using shadows. Otherwise we risk inconsistencies that look weird to users. Elements casting shadows in different directions also make it harder for the eye to quickly see a hierarchy when it comes to eleviation (z-index).

While those general guidelines are a solid start, the real magic of box shadows reveals itself when we use multiple shadows on the same element. In CSS a regular box shadow has the following properties:

```css
box-shadow: x-offset y-offset blur-radius spread-radius color;
```

We can however add more shadows on the same element by comma-separating them:

```css
div {
	box-shadow: 0 4px 6px rgba(0,0,0,0.7),
				0 5px 15px rgba(0,0,0,0.2);
}
```

The first shadow in this example is a box-shadow how it is often used, generally darker, close to the element and rather sharp with only a bit of blur – the classic way of using box-shadows.
The second shadow however has a bigger blur, a higher vertical offset and is rather subtle, giving the element a lot more depth, making it look closer to how we see shadows on objects in real life. If we wanted to achieve a perceived higher elevation that shadow would have to be more subtle the closer it gets and more intense the further "down" it is supposed to be.

While that's already a great improvement over simple box-shadows, we can go even further and create a fake plasticity by adding another shadow to the element. One brand that has incorporated this kind of plasticity into their overall appearance is Algolia. Here's a typical button, which adds a third (inset) shadow to the element, giving it a little edge on the bottom.

![image](/storage/algolia-button.jpg)

```css
.btn {
	box-shadow: 0px 2px 4px rgb(45 35 66 / 40%), /* diffuse shadow behind the button */
				0px 7px 13px -3px rgb(45 35 66 / 30%), /* shadow offset to the bottom for depth */
				inset 0px -3px 0px #d6d6e7; /* boottom "edge" of the button */
}
```

Of course we don't always want to make use of every technique just because we can. When shadows are part of the layout however, it is definitely worth spending a bit of time on nailing those basics to get a clean and consistent look.

Better CSS box shadows

Pure functions form the building blocks of functional programming and help a lot in not repeating yourself and making code easier to maintain. Let's take a close look and figure out what makes them so awesome. At its core pure functions will

- Always return the same output, given the same result
- Have no side effects (mutating, logging, writing to disk, ...)

Here's a very simple example

```javascript
const add = function(x, y) {
	return x + y;
}
```

Given the same x and y, the function will always return the same result and it has zero side effects, because it doesn't fo anygthing but add the two variables.

An impure function on the other hand could look like this:

```javascript
let sentence = "Hello ";

const addWord = function(word) {
  sentence += word;
};

addWord("World"); // x === Hello World (only the first time!)
```

Because it modifies a variable that is out of its scope, the function will return a different result the second time it's called, even if we pass in the same word. The function relies on a shared state, because the variable "sentence" can change outside the function, which makes it non-deterministic.

Those basic examples already illustrate why pure function can be easier to reason about and write test for and why some functions that are impure can be an absolute nightmare to debug.

**Side effects**

The most important part of "no side effect" boils down to "don't alter any outside state". For example, passing an object into a function, pure functions would only modify a clone of that object and never the original object.

```javascript
const alterAnimal = (key, value, object) => {
	// We're cloning the passed object, so we can be sure not to alter
  // the original, which would make the function impure.
  const clone = { ...object }; 

  clone[key] = value;

  return clone;
};

const animal = {
  name: 'Baloo'
};

const result = alterAnimal('category', "cat", animal);

// Because we haven't modified the passed object directly, 
// result now holds an additional property that animal doesn't have
console.log({
  animal,
  result
});
```

Only if we use a (deep) clone instead of the actual animal object, we can guarantee repeatable results and easier testable and understandable code. Altering variables outside of our function's state on the other hand makes it a lot harder to understand what's going on and potentially send us down a rabbit hole when looking for bugs.