
Hello and welcome to the Developer Diaries 15! August is over already, but
summer is still going strong in Germany. August was a **great** month. It was
very hot, but I enjoyed it a lot!

## 👨🏻‍💻 Work

Last month, I built my first **online shop** with Shopify. I get it now why
Shopify is the GOAT of web shops. Their product is very good. Even without
coding skills, you can get your products to sell online in **under a few
hours**.

I used their React Framework `Hydrogen` based on Remix to build a headless
E-Commerce site. I learned a lot, and I documented the whole process in a blog
post. Make sure to check it out below.

Besides that, I worked on a website to **reduce the client-side JavaScript** to
improve the Page Speed Score on mobile. It’s great how many tools we as
developers get from the browser nowadays, like the
[code coverage](https://developer.chrome.com/docs/devtools/coverage/) from
Chrome

It’s a great help to figure out what JS is used and what’s just imported,
wasting space and recude download speed. On the website, `moment.js` was used to
format dates in a specific way. That reminded me of a previous job, where we
used `moment.js` heavily and already had the discussion around whether we needed
that or couldn’t native JS solve these tasks.

Thankfully, there’s
[this great article on GitHub](https://github.com/you-dont-need/You-Dont-Need-Momentjs)
where people made an in-depth comparison , and the conclusion is: yes, you don’t
need it!

By removing `moment.js` and using basic JS to format dates, I could reduce the
client-side JS by almost **50%** and make it much faster to load on mobile.

## 📝 Blog Posts of the Month

Here are the blog posts of August 2023:

- [Developer Diaries 14](/blog/developer-diaries-14)
- [How to build an E-Commerce website with Shopify Hydrogen V2 and Sanity](/blog/e-commerce-website-with-shopify-hydrogen)

I’m pretty happy about the e-commerce website write-up because it’s a **great
starting point** if you consider building your first headless online shop. I
documented all the steps I took to get up and going with the shop I recently
built.

## 🎓 TIL Posts of the month

Here are the Today I Learned posts of August 2023:

- [Have you used Web Components?](/today-i-learned/have-you-used-web-components)
- [Learn HTML](/today-i-learned/learn-html)
- [CSS Selectors Visual Guide](/today-i-learned/css-selectors-visual-guide)

## 🏋🏻‍♀️ Fitness

My current fitness routine is running two times a week, and doing my bodyweight
strength workout two times a week. I’m motivated to start my week with a 5k run,
and I’m curious how long it will stay that way.

I can imagine that I’ll go back to running once weekly as soon as the weather
changes to more autumn and rainy. I also would love to integrate cycling into my
fitness routine, but it doesn’t fit well right now. I’ll see if this changes
when I switch back to indoor cycling later this year.

## 📚 Reading

I finished three books this month. I got hooked on the Silo Series because it’s
running on Apple+. I managed to avoid trailers and spoilers and try to finish
the books until I start the TV series.

Project Hail Mary might be one of my **favorite books**. The story is just
wonderful. I’m really into science fiction right now, even though I thought that
I disliked that genre. But I think I especially like the books from this genre,
which start in a relatable environment and then enhance into more
science-fiction.

I added a few books from this section to my want-to-read list, and I hope they
are similarly beautiful. Anyway, here are the books from this month:

- [Wool: Book One of the Silo Series - Hugh Howley](https://www.goodreads.com/book/show/51852482-wool)
- [Winter of the World - The Century Trilogy #2 - Ken Follet](https://www.goodreads.com/book/show/12959233-winter-of-the-world)
- [Project Hail Mary - Andy Weir](https://www.goodreads.com/book/show/54493401-project-hail-mary)

## 🎙Podcasts

I listened to the [Syntax.fm](http://syntax.fm/) episode with Ryan Florence
recently. It’s a great talk about not only the framework Remix but also about
the web, web technologies, and the ways they’re evolving in general. I took a
lot of inspiration and further thinking from that.

- [Supper Club × Ryan Florence of Remix](https://syntax.fm/show/649/supper-club-ryan-florence-of-remix)

## 🕹Video Games

I’m still big on Zelda. It still feels like I haven’t even finished half the
game. So much to see!

That's it for this month. See you in the next one!


Developer Diaries 15 is about building an E-Commerce website with Shopify Hydrogen V2 and Sanity, reducing client-side JavaScript, and more.

Developer Diaries 15


If you ever were to be asked to build an E-Commerce website for a client, what’s
the first thing that comes to mind? **Shopify**, right? Recently, I built my
first website with Shopify Hydrogen, and in this blog post, I’d like to share
how to get started with that.

---

- [Going headless: Next.js Commerce vs Hydrogen](#going-headless-nextjs-commerce-vs-hydrogen)
- [The main components](#the-main-components)
- [Opinions](#opinions)
- [Create a shop on Shopify.](#create-a-shop-on-shopify)
- [Install Hydrogen App](#install-hydrogen-app)
- [Create a new hydrogen project.](#create-a-new-hydrogen-project)
- [Start developing with Hydrogen.](#start-developing-with-hydrogen)
- [Integrate Sanity](#integrate-sanity)
- [Deployment with Oxygen](#deployment-with-oxygen)
- [Conclusion](#conclusion)
- [Sources](#sources)

---

## Going headless: Next.js Commerce vs Hydrogen <a name="going-headless-nextjs-commerce-vs-hydrogen"></a>

When I figured out the **requirements** for this website with my client, I
decided to use the **headless** approach of building this E-Commerce site
instead of going with a Shopify template and some third-party apps. Don’t get me
wrong: using the whole Shopify platform is great. You can ship a website fast.

But my reasons for not using it and going headless were the following:

- I wasn’t familiar with [Liquid](https://shopify.dev/docs/api/liquid), so I’d
  have to learn that first to customize and enhance any theme
- The client had a custom design, which I knew I would build faster with the
  tech stack I’m familiar with
- I needed more freedom and more custom functionality

I researched a bit and found two possible ways to tackle this project. As a
regular React and Next.js user (most recent websites I built using Next.js), one
option was using the [Next.js Commerce template](https://nextjs.org/commerce).
The other option was using Shopify’s own React-Framework
[Hydrogen](https://hydrogen.shopify.dev/).

My first instinct was to go with Next.js commerce. I heard a few things about
Hydrogen not being used that much so far. But then I noticed that **Shopify
bought Remix** last year, and a few months ago, they released
[Hydrogen V2](https://hydrogen.shopify.dev/roadmap/) based on Remix! I built one
website the previous year with Remix, and I liked it a lot. The concept of
[actions and loaders](https://remix.run/docs/en/main/pages/philosophy#serverclient-model)
automatically clicked for me.

Besides that, Next.js Commerce felt a little too much developing on **shiny and
new cutting-edge technology**. Some big shops are using it, but I still wanted
to wait a bit before using the `App Router` and `React Server Components` in
production.

Therefore, I decided to go with Hydrogen, and in this blog post, I’ll document
the process of building an E-Commerce Website with Hydrogen v2 and Sanity!

## The main components <a name="the-main-components"></a>

Here’s a quick rundown of the **main building blocks** for this site:

- As mentioned above, I used headless Shopify with Hydrogen based on Remix to
  build the front-end, query of the data and run mutations.
- I used the headless CMS Sanity to gather all the content unrelated to
  products.
- And for styling, I used TailwindCSS.

With these three building blocks I should be ready to go!

## Opinions <a name="opinions"></a>

The team from Sanity built a
[hydrogen sanity demo shop](https://github.com/sanity-io/hydrogen-sanity-demo),
which was a **huge help** to get this website going. They defined some opinions
as general rules for their shop. I liked this idea a lot, so I decided to
implement this as well. Here are the opinions on this project:

- Shopify is the primary source of truth for products and collections
- Sanity is the primary source of truth for editorial content
- Product pages can be enhanced with content in Sanity

## Create a shop on Shopify <a name="create-a-shop-on-shopify"></a>

With the main tech figured out and the opinions formed, it’s time to dive in.
First of all, you need a Shopify shop. I won’t get into detail on how to set
that up because the Shopify docs do a great job of explaining this step in
depth. The important thing here is you **can’t use a development store** when
you’re building with Hydrogen.

## Install Hydrogen App <a name="install-hydrogen-app"></a>

After you've created your shop in Shopify, you have to add the Hydrogen App to
our Shopify store if the shop is set up. This enables you to use the Storefront
API. It gives you access tokens and lets you query your products and
collections.

For this, you have to head over to the Shopify App store, search for Hydrogen,
and install the app.

<Image
  src="/images/hydrogen-shopify-app-store.webp"
  alt="A Screenshot of the Hydrogen App in the Shopify App Store"
  width={1504}
  height={1308}
/>

After that, you can configure it in Shopify to get your access token for the
Storefront API and so on.

## Create a new hydrogen project <a name="create-a-new-hydrogen-project"></a>

Now, the actual developing part starts. On your machine, open a terminal and run
the following command:

```jsx
 npm create @shopify/hydrogen@latest
```

It runs a setup to create a new Hydrogen Shopify website. It offers **a lot of
options**. And if you want to, you can have a **very opinionated** project
setup.

First, it links automatically to your Shopify account and connects to your
existing store if you’ve already set up one. You can give your shop a name,
select if you want to use `JavaScript` or `TypeScript`, and choose which styling
library you want. For me, that was TailwindCSS, so I added that directly.

Finally, you can choose if you want to have routes and more core functionality
immediately set up.

## Start developing with Hydrogen <a name="start-developing-with-hydrogen"></a>

With the project setup, you’re ready to **start developing** with Hydrogen.

If you’ve chosen the option to have pre-configured routes and core
functionality, you will notice that you have an almost complete functional shop
ready to run. That’s amazing!

The Shopify team set **everything necessary**, like fetching collections and
recommended products, creating product detail pages, adding products to the
cart, searching the page, account management, and more! Wow!

I think that’s pretty awesome. They are the experts in building web shops, and
they know **what basic functionality every shop needs**. So why not prepare it
already in the best possible way? This made my job much easier, and I was very
thankful.

So, with the essential building blocks set up, now is the time to tweak your
shop the way you want it to look, implement your custom design, add more
functionality, and adjust it to your needs.

## Integrate Sanity <a name="integrate-sanity"></a>

After finishing everything Shopify product and collections related, it was time
to integrate Sanity as a headless CMS for the editorial content as stated in the
Opinions.

First of all, I installed
[hydrogen-sanity](https://github.com/sanity-io/hydrogen-sanity), which adds a
Sanity Client to the Remix Context. The Sanity team did a great job building
this integration, and it’s cool that these products are so intertangled.

```jsx
npm i hydrogen-sanity
```

`Hydrogen-sanity` enables you to fetch content from Sanity in Remix actions and
loaders using their query client. It also allows you to have a live preview.
After the installation, follow the `Readme` to update your `server.ts` and set
up the `ENV` variables.

Now it’s time to install and run Sanity. There are multiple options available.
You can either get started with a clean template. Or you can choose to use the
**Shopify template**, which means already pre-configured `schemas` for
everything you might need for a Shopify store.

```jsx
npx sanity@latest
```

You can take another _optional_ step when working with Shopify and Sanity. You
can install the
[Sanity Connect app](https://www.sanity.io/docs/sanity-connect-for-shopify) in
your Shopify Store. This app enables you to sync all your products and
collections to Sanity.

<Image
  src="/images/sanity-connect-shopify-app-store.webp"
  alt="A Screenshot of the Sanity Connect App in the Shopify App Store"
  width={1504}
  height={1308}
/>

In Sanity, you can then **enrich** the content for your product and collections
pages. You can also reference your products and collections on every Sanity
page, which is a fantastic feature!

## Deployment with Oxygen <a name="deployment-with-oxygen"></a>

When you’re done developing, Shopify offers the opportunity to use their hosting
service, [Oxygen](https://shopify.dev/docs/custom-storefronts/oxygen), for free.
To get that up and going, you only have to **connect** your Hydrogen App in
Shopify with your **GitHub Account**.

Shopify will then open a Pull Request, which adds a `yaml` file with the
deployment instructions. After that, every git push triggers a deployment. It
could not be easier to deploy your store!

## Conclusion <a name="conclusion"></a>

So these are the steps you have to take to build an **E-Commerce website with
Shopify Hydrogen and Sanity**. I liked the process a lot. The documentation is
excellent. Additionally, the Hydrogen Sanity Demo was a perfect example to have
a sneak peek occasionally and use that as a guideline.

I also liked that you can get a lot of **core functionality pre-configured**,
like routes, handling and adding products to your cart, and so on. This speeds
up the process of building an E-Commerce website by a lot. For my next shop,
I’ll definitely use this stack again!

## Sources <a name="sources"></a>

- [Hydrogen Landing Page](https://hydrogen.shopify.dev/)
- [Hydrogen Docs](https://shopify.dev/docs/custom-storefronts/hydrogen)
- [Hydrogen Sanity Demo](https://github.com/sanity-io/hydrogen-sanity-demo)
- [Hydrogen Sanity](https://github.com/sanity-io/hydrogen-sanity)
- [Oxygen](https://shopify.dev/docs/custom-storefronts/oxygen)


In this blog post I share how I built an E-Commerce website with Shopify Hydrogen V2 and Sanity.

How to build an E-Commerce website with Shopify Hydrogen V2 and Sanity


Hello and welcome to the Developer Diary number 14! As you may or may not have
noticed, I **skipped** the June edition of this blog post series. It wasn’t like
I didn’t have time for it. I just changed my priorities in June.

I focused more on developing Work and drew back on writing for a while. It was a
good decision, and I didn’t feel bad about it. So this blog post will be about
June AND July, I guess. A lot can happen in two months, and **a lot happened**
in the last two months, so let’s dive right in!

## 👨🏻‍💻 Work

I already mentioned that I’m part of the
[Prismic Developer Program](https://prismic.io/hire-a-developer) last month.
It’s a great opportunity because it opens a lot of possibilities. I’d like to
**highlight** one special connection that I made a few weeks ago.

I got an inquiry through Prismic, where one person asked for development support
for a website they were doing for a client. I agreed to a first meeting, and we
met via Zoom. After talking about the project, sharing advice, and helping where
I could, I figured **this person was developing this website while learning
JavaScript, React, and Next.js simultaneously**.

What an inspiring person, but also what a big project to tackle. I was already
overwhelmed with learning JavaScript alone back in the day. So much respect for
this person for keeping good spirits and not giving up. That was really
inspiring.

Besides that, the biggest highlight in July was working on a project with my
friends from [b13](https://b13.com). They are well known for developing huge
websites powered by the CMS [Typo3](https://typo3.org/) and are the experts in
this field. I started my web developer career with them a few years ago, and it
was a lot of fun to work together again. I developed the Frontend for the
project, and they took it and integrated it into the Typo3 environment.

## 📝 Blog Posts of the Month

As you may have noticed, there are no blog posts this month! But I’m not too sad
about it. Like I said in the beginning, I just had **different priorities**. My
backlog is full of ideas, so stay tuned for more in the coming weeks!

## 🎓 TIL Posts of the month

Same as above! 🙂

## 🏡 Life

In the middle of June, we had a small holiday where we did **three days of
hiking** in the black forest. It was amazing. Beautiful landscapes, perfect
weather, and 3 days of walking are wellness for the mind. And it feels great to
walk to your next destination or hotel instead of making just round trips. Would
love to do this more often.

<Image
  src="/images/black-forest-hike.webp"
  alt="An overview over the black forest from a cabin"
  width={1024}
  height={768}
/>

We celebrated our **first wedding anniversary**! Time flies, and it’s already
one year since we got married. I also remembered what a crazy year it was last
year, starting as a freelancer and getting married simultaneously. But it never
felt scary. It felt like doing the right thing all the time.

We finally had our **biggest holiday** this year at the end of July. We went to
the **UK for a wedding**. We took the train to London, and it was our first time
driving through the underwater tunnel with the Eurostar. It was such an
enjoyable experience. I would always prefer this over taking a plane.

You don’t have to worry about your luggage; it takes almost the same amount of
time and feels less stressful. We spent a few days in London before we headed to
Manchester for the wedding. The wedding felt terrific, and we felt very grateful
that we could be a part of it. After that, we went for a few days to Edinburgh,
which we absolutely loved, before heading back to London and taking the train
home.

I’ve already been to the UK before, but I didn’t remember how nice, polite and
friendly the people there are. Traveling by train around the UK was also a great
experience (compared to Germany), and being able to pay for everything with your
phone and having no need for cash made this a perfect holiday.

## 🏋🏻‍♀️ Fitness

I did the biggest cycling tour ever with a great friend. It was 136km in total,
and it was a blast. It was one of the biggest challenges I ever did, and we
crushed it. Can’t wait to start the next adventure like this!

<Image
  src="/images/cycling-tour.webp"
  alt="Me on my bike with a beautiful landscape in the background"
  width={1024}
  height={768}
/>

## 🕹Video Games

I’m totally back into Zelda: Tears of the Kingdom. After neglecting it for a
while, I played a lot while traveling, and it was just so much fun.

That’s it for June and July 2023. See you next month!


Developer Diaries 14 is about shifting priorities, working with friends, and traveling to the UK.

Developer Diaries 14


## 👨🏻‍💻 Work

May was pieced with many public holidays, which meant working only three days a
week often. I know I could work on those public holidays because **I'm my own
boss**, but it felt great to take these breaks, and my wife didn't have to work
on these days anyway, so we took the opportunity.

I was part of a great and exciting project where we built a **collaboration
mode** for a website, and it was a lot of fun learning to work with
`web sockets`.

Besides that, I finally became part of the
[Prismic developer program](https://prismic.io/hire-a-developer), which feels
great. A lot of people reached out through that already.

## 📝 Blog Posts of the Month

Compared to the prior month, this month, **I wrote a lot**. I had more
inspiration and fun with it again, and I have a lot of new ideas I'm going to
write about in the following weeks. Here are the blog posts for May 2023:

- [Scrum vs. Kanban](/blog/scrum-vs-kanban)
- [Developer Diaries 12](/blog/developer-diaries-12)
- [Rich Harris Hot takes on the Web](/blog/rich-harris-hot-takes-on-the-web)
- [Vercel Storage](/blog/vercel-storage)

## 🎓 TIL Posts of the month

Here are the Today I Learned posts for May 2023:

- [The popover API](/today-i-learned/popover-api)
- [The problem with sticky menus](/today-i-learned/the-problem-with-sticky-menus)
- [CSS Nesting](/today-i-learned/css-nesting)
- [Image Carbon](/today-i-learned/image-carbon)

## 🏡 Life

Sommer is here, and it's fantastic. We have a big terrace where we can enjoy
sunrises and sundowners. Compared to a year ago, were we still lived in the city
and our view was the neighbor's wall, this is such a significant upgrade for us,
and I feel that we made a lot of right choices.

Additionally, I'm having a lot of **fernweh**. Our first big holiday is at the
end of July, and I can't wait to get there. I'm so happy for all my friends who
are traveling right now and I can't stop to listen to there stories about it.
But I'm also looking forward to our holiday in July.

## 🏋🏻‍♀️ Fitness

I'm feeling good and strong lately. I follow a great mix of bodyweight fitness
to gain strength and endurance workouts. I started cycling again, and it felt so
much like total **freedom** to me. I just jump on my bike and ride. I often
notice afterward that that's when I almost **don't think**. I'm focused and in
the moment, and that feels fantastic.

## 📚 Reading

I read two books last month. The first one is:

- [Dark Matter - Blake Crouch](https://www.goodreads.com/book/show/27833670-dark-matter)

My first book by blake crouch was Recursion which I read last year. I started
dreaming about it, which shows me how much I was invested in the story. It made
me think a lot about the topics it's about, and it can break your head.

This one is similar. In the most basic terms, it's about the existence of
parallel universes, and reading a story about it makes you question so much that
it's complex and fascinating at the same time.

The second book was:

- [Das Leuchten der Rentiere - Ann Helen Laestadius](https://www.goodreads.com/book/show/61190509-das-leuchten-der-rentiere)

The book started too slow for me. I had a few times when I wanted to put it
away. I'm glad I didn't. The second half is brutal. Not an easy read if you love
animals.

## 🕹Video Games

It's Zelda - Tears of the Kingdom all over the place! I never finished Breath of
the Wild because, at the time, I was oversaturated with open-world games. But
now I'm having so much fun with it, and all the sounds trigger many
**nostalgic** feelings back from 2018. I love it!

That's it for the developer diaries in May 2023. See you next month!


Developer Diaries 13 is about a lot of public holidays, fernweh, the new zelda game and sommer.

Developer Diaries 13


Developers love to **argue** about tech. They love to defend their tech stack to
the blood. They tell each other that language _XYZ_ is superior and only
inexperienced developers would choose _insert random tech stack here_ to achieve
a specific wanted outcome.

Often times these discussions **lead to nothing** because both sides are not
interested in the opinions of others and only want to present their arguments
and convince others why they should throw everything overboard and follow their
advice.

It’s solemnly an ego thing because developers get **attached** so much to their
tech stack. It feels so stupid, like arguing about which nation is better, with
the slight difference that you can’t choose your nationality.

---

**Table of Contents**

- [Your tech stack doesn’t matter](#your-tech-stack-doesnt-matter)
- [Changing your tech stack for the sake of it](#changing-your-tech-stack-for-the-sake-of-it)
- [From PHP to React](#from-php-to-react)
- [From NodeJS to Golang](#from-nodejs-to-golang)
- [Conclusion](#conclusion)

---

## Your tech stack doesn’t matter <a name="your-tech-stack-doesnt-matter"></a>

I want to be honest with you from the beginning. This blog post is inspired by
this video:
[How to OVER Engineer a Website // What is a Tech Stack? by Fireship ](https://www.youtube.com/watch?v=Sxxw3qtb3_g).

If you came here for advice on what tech to use for web development in 2023, I’m
sorry you won’t get that. **I tricked you**.

I won’t tell you to use `Next.js` with a `serverless database` for your CRUD
App. I won’t make the decision for you to pick a specific JavaScript Framework.
I won’t tell you to use `Redux, Recoil, Mobx, or Xstate` for state management in
`React`. I won’t tell you if you need to use `TypeScript` or `JSDoc` for type
safety or if you can skip it totally.

I want to make one particular point in this blog post. **The tech you use
doesn’t matter**. What matters is that you **satisfy the needs of your users**.
Your users don’t care what tech you use, but they do care if your website or
application works as intended and if they can achieve the task or find the
information they came for.

In addition, it matters that you choose and work with technology you’re
comfortable with. Being comfortable means, at least for me, that you know your
way around, you’re experienced with it, you are fast, you can find solutions
quickly, fix bugs, and you know your stuff.

You don’t need to jump the hype train every year or month. Instead, stick with
what you love to use. By following this guideline, you’ll be able to do what
your job is.

## Changing your tech stack for the sake of it <a name="changing-your-tech-stack-for-the-sake-of-it"></a>

I’ve had a few experiences in my web developer career where we, as a team, or
often our team leaders, decided to approach a significant tech stack change. If
you’re working in a larger team, technology choices are more complex and
different than working alone.

People have different experiences, skills, and preferences, and you need to
collect all of that and choose the best matching tech stack based on that. Not
an easy task.

Sometimes this is inevitable. Sometimes you have no choice. For example, when
part of your technology is no longer safe, support for it ends, or better
alternatives exist.

I’ve had a few situations in my career where we approached significant tech
stack changes. I want to highlight two of them here. These were kind of
“Changing your tech stack for the sake of it” situations.

What do I mean by that? Some new tech comes around, and everyone starts jumping
on it and tells you you need to switch to that immediately because it’s cool,
shiny, and new.

There wasn’t enough evidence yet that this technology proved to be better 100%,
and of course, there wasn’t enough experience among the developers.

## From PHP to React <a name="from-php-to-react"></a>

A few years ago, I worked in a team responsible for one particular part of a big
website. This part contained a lot of “legacy” code. It was written a few years
back with mainly PHP. When a new, big part was added to the website, which a
different team was responsible for, the decision was made to build that with
React.

This decision was great, React was established and widely adopted, and the
developers were experienced with it. Based on that decision, another decision
was made to **rebuild our part of the website with React**. Management wanted a
re-brush, a different look for it, so it was clear that we would have to work on
it anyway.

But besides that, there were no complaints or arguments for refactoring. The
performance was great. The only downsides were a bit outdated look and a lot of
legacy, poorly structured PHP code. We were more than happy about the decision
to rebuild it with React. We were all experienced React developers and wanted to
get rid of PHP at that point. We wanted to use what everyone was using at that
time. So it felt great to do the refactoring. Remove the old, in with the new!

Why I’m talking about this? In the beginning, I said it doesn’t matter what tech
you use, right? So this change shouldn’t be a big deal. However, shortly after,
and also a few years later, I reflected on that tech stack change, and **I’m
still not convinced that it was a great idea**.

Performance was **worse** after the rebuild due to our mistakes when working
with React. It took a **long time** to do something like that just for a
different look. We could have worked on fixing bugs or building user features
instead.

I’m not sure there is a right or wrong here. I want to highlight that it doesn’t
matter what technology you use if you focus on building for your users. Changing
your tech stack should be a decision you’ve thought about for a long time and
have a long list of reasonable arguments for it. Our users don’t notice if we’re
using PHP or React. But they do see when the page takes longer to load.

## From NodeJS to Golang <a name="from-nodejs-to-golang"></a>

On another former job, the decision was made to switch from NodeJS to Go on the
backend. The tech stack for most projects before at that company for the backend
was NodeJs, and we had a lot of experienced developers in it.

**Nobody knew Go**, and we needed to kick-start a new and critical project
immediately. The arguments for the switch were that Go was getting traction, and
there was some first evidence that it was faster and better-suitable for
projects that needed to scale.

So the decision was made for us. Everybody on the team needed to learn Go from
scratch. We had one or two persons who had some experience with it but not in a
production environment.

This was tough because we had a **deadline** and needed to **figure out first
every basic stuff** of a new backend language. This was the definition of
learning by doing.

In the end, it worked out, we had a lot of fun working with Go, and we learned a
lot and enjoyed it. But I wouldn’t say that this was a good decision. Everything
we needed to accomplish in the new project, we could have also done with NodeJS,
and it wasn’t much more than a CRUD App, so no scaling was needed right away.

The decision to switch from NodeJS to Go was made company-wide, so it wasn’t
solely a tech stack change to play with the new toys. But I also wouldn’t say
that it was necessary. We needed more time to build stuff because we had to
learn everything first.

We had to do a lot of refactorings all the time because best practices changed,
and we didn’t always do things right. In conclusion, it felt like a tech stack
change for the sake of it. Go seemed to be faster and better for scalable
projects, but we didn’t need that, and NodeJS is still a very capable backend
language suited for almost every bigger backend. But, once again, **our users
didn't notice anything** about that. They just want to get their data.

## Conclusion <a name="conclusion"></a>

The tech you choose doesn’t matter. **There is not best tech stack for web
development in 2023**. Your users don’t care about it. Choose the tech you’re
comfortable with, experienced in and have a lot of fun using it.

Choose the tech with whom you can build features and fix bugs fast, satisfy your
users needs and keep things running. Don’t switch to tech because it’s the new
shiny thing and most importantly: don’t trust the hype.


In this blog post I will share my thoughts on what's the best tech stack for web development in 2023 that will help you to build great web applications.

The best tech stack for web development in 2023


I know what you’re thinking: Oh, come on! Not another blog post about Scrum vs.
Kanban. It’s 2023. Why are we still having this discussion?

The short answer is that **this debate will never be settled**. Because there is
no clear winner, and because of the selfish reason that I wanted to write a blog
post about my opinion and experience on this discussion.

A few days ago, I stumbled upon the article
[“You don’t need a scrum, you just need to do kanban right”](https://lucasfcosta.com/2022/10/02/scrum-versus-kanban.html)
by Lucas F. Costa, which inspired me to re-think and reflect on this and made me
want to express my feelings about it. I also looked into the hacker news
discussion around it, and it was really interesting to read everyone’s opinions
about this topic.

Developers love and hate both, and there seems to be no best framework. We must
constantly remind ourselves that **it’s just a framework** we can use to improve
our work processes. It’s not a guarantee for better work results. For a lot of
people, Scrum works great. It helped them improve their output as a team. The
same goes for Kanban. As I already said: there is no clear winner here.

> Disclaimer: This is solemnly my opinion about it, and no scientifically
> supported report. You can love Scrum, and that is great. You can also use
> Kanban, and that is great. Or hate both.

---

**Table of Contents**

- [You just need to do Kanban right](#you-just-need-to-do-kanban-right)
- [My personal experience with Scrum](#my-personal-experience-with-scrum)
- [Why I think Scrum can help](#why-i-think-scrum-can-help)
- [Why I prefer Kanban whenever I can](#why-i-prefer-kanban-whenever-i-can)

---

### You just need to do Kanban right <a name="you-just-need-to-do-kanban-right"></a>

As I already said at the beginning, this blog post is inspired by reading “You
don’t need a scrum, you just need to do kanban right” by Lucas F. Coast. You
should go check out his whole blog post and read it yourself! I won’t cite all
the great points the author is making, but I’d like to highlight some of them.

Lucas F. Costa says teams can **respond to feedback quicker** when preferring
Kanban over Scrum because they don’t have to wait for the 2-week sprint cycle to
finish.

The **focus is shifted to the task instead of to the sprint-sized batch**.
Developers need to go after the information they need next which **increases
responsibility**, which leads to fewer back-and-forth discussions and fewer
decisions necessary, making them more responsive.

Lucas is also saying that **estimation meetings are wasted time** because they
should instead be used to code. I’m not sure I agree with that. Yes, estimation
is often a random gamble, but I think it still helps to get a feel for the task
and discuss the necessary steps.

What I like about his take on estimations is that instead of focusing on
estimations, focusing on getting the task in the system and out is preferable.

He also states that **making work visible** is no sole advantage of Scrum. The
Kanban board works very well for that.

### My personal experience with Scrum <a name="my-personal-experience-with-scrum"></a>

I’ve worked in many different teams where we used Scrum heavily. So I’ve had
quite some experience with it. Thus please bear in mind that this is my
**personal experience** and, therefore, nothing evidence-based or general
opinion. Nevertheless, here are some things that I noticed over and over again
when working with Scrum.

- Scrum always felt like we did it for everyone **outside** our team but not for
  ourselves. The time the meetings and organization around Scrum took felt
  insane to me. I often felt exhausted and unable to think straight after our
  sprint meetings.
- There usually were **developer deadlocks** where a person could not start to
  work on a new thing because we couldn’t pull it in the sprint. And because our
  planning didn’t allow it and wouldn’t be finished until our sprint ended with
  all the steps involved (review etc.).
- I noticed later that there was **no celebration** after a sprint ended. We
  just started immediately again the next day. Maybe there was a quick patting
  on the back, if any, but then we just jumped into the next planning meeting,
  and the worry about meeting the next sprint goal started again.
- Overall it felt **stressful** to me. We knew early on if the sprint goal was
  manageable or if we needed to ping our Product Owners to adjust the sprint
  goal. But this always felt like a loss.
- Retros felt good, but if you’d zoom out a bit, you’d noticed that we talked
  about the same points every month again, and **solutions were not
  implemented**.
- I often felt like I just wanted to put out the work, and all the planning and
  estimation was a **hurdle**. It wasn’t for me. It was for the stakeholders to
  sell our work and give others a deadline.

### Why I think Scrum can help <a name="why-i-think-scrum-can-help"></a>

I stated a lot of negative points above, but to be clear, I don’t dislike Scrum!
On the contrary, I think it has **excellent benefits** and can help a team
**flourish**.

I think Scrum can help teams who are **not well organized**. Where communication
is not done at its best and where it’s unclear how long specific work takes or
what people are working on. It can help these teams take a closer look at those
things and work on them.

I’ve worked in several different teams where Scrum significantly **boosted our
performance** and output. The main reason for that was that we had trouble
identifying bottlenecks. The communication was not the best, and sometimes we
waited too long to ask for help if we were stuck, and we had a hard time
estimating how long things took.

Scrum put the magnifying glass on these issues and helped to resolve them. It
literally made us more **agile**. We knew early on when trouble was ahead and
could find quick solutions by switching out things and communicating clearly to
our stakeholders. It felt like an ever-ongoing buzz, and so much was happening
and changing constantly.

### Why I prefer Kanban whenever I can <a name="why-i-prefer-kanban-whenever-i-can"></a>

The exact same reasons stated above, which make Scrum helpful, in my opinion,
contributed mainly to the fact that I prefer Kanban.

Whenever I was part of a team where we used Scrum, it was hard for me to get
into the **state of flow**, in a state of uninterrupted focus. Scrum felt to me
like something was going on all the time. I think that's the definition of
agile, but there have to be boundaries. And to me, the boundary of protecting
the developer's productivity was often **overstepped**.

I would say that I am a very good communicator. I let people know about my
status, if I'm stuck on something, if I need help, or if something takes longer
than expected. I've never had complaints from teammates that they don't know
about what I'm up to or that they had to wait for critical information from me.

By being a good communicator and handling things the way I explained above, I
gained a lot of **trust** from people. I appreciate that a lot. The final
conclusion for me here is: **I don't need a framework like Scrum to do my best
work**.

So it can feel hard and unnecessary to be put into a framework that doesn't
benefit me personally. Don’t get me wrong: often we don't have a choice, and I
don't have problems being part of a Scrum team in general. I can adapt and have
fun being part of a team that loves to work with Scrum.

As a freelancer I’m used to come into existing team who flourish by using Scrum
and I can easily **integrate** into that. But: If I have the choice and can pick
what works best for me, I always pick Kanban.

Kanban works way better for me. The planning part is rougher. When things are
done, I'm able to pick the next task, and so on. This suits my work style way
better. Because I can **focus on the output**, delivering the work, and
satisfying users and customers. I love to look at a Kanban board, see the
progress, make it visible, and be able to publish new features when they’re done
and not tied to a two-week cycle.

It gives me more **freedom** and also more **responsibility**. In the end, it
doesn’t matter what framework we use. We need to know how we work best, what we
need to achieve that, and follow the route it takes us. **Delivering great web
experiences where we help users accomplish their goals is what counts**.

### Sources

- [You don't need Scrum. You just need to do Kanban right.](https://lucasfcosta.com/2022/10/02/scrum-versus-kanban.html)


Scrum vs Kanban is an ever ongoing discussion on what agile framwork is superior. In this blog post I'll explain why Kanban works best for me.

Scrum vs. Kanban


## 👨🏻‍💻 Work

This month was a “boring” month. I put boring in quotes because it was the
**good kind of boring**: nothing too stressful, complex, completely unexpected,
and a lot of regular and steady Work. It felt like I’m doing a **routine**,
which I greatly enjoy.

It gave me time to reflect on why I like freelancing, what I enjoy, and what I
want to accomplish. And I always return to this: **I like building great
websites**. I like it a lot when I can help people to get their business out
there on the web.

## 📝 Blog Posts of the Month

The only blog post I wrote this month was my **recap** of the previous month.
While in the month before, writing felt natural to me, and I enjoyed it, I could
not find any motivation to write this month.

I don’t know if it felt like that because I was **missing inspiration** or could
not find the topics that interested me so much that I would want to write about
them. But I tried to embrace it and pause writing until I had fun with it again
without feeling bad about it.

So here’s the blog post of the last month:

- [Developer Diaries 11](/blog/developer-diaries-11)

## 🎓 TIL Posts of the month

Here are the Today-I-learned posts of April:

- [Text-wrap: balance](/today-i-learned/text-wrap-balance)
- [Building accessible modal dialogs](/today-i-learned/building-accessible-modal-dialogs)

## 🏡 Life

We had our first minor holiday this year and went for four days to **Vienna**. A
friend ran the half marathon there, and we were the support crew. I love to
explore a city by walking around without a specific goal and eating a lot of
delicious food.

The weather in Vienna was amazing. When we left our home, it was cold and rainy,
and as soon as we came close to Vienna, we had four days of sunshine and blue
sky all the time. So beautiful. Although it was just a short holiday, it was
terrific, and we had a great time.

## 🏋🏻‍♀️ Fitness

I got a new tattoo this month! But this also meant: **no sport** for at least
two weeks. It felt easier than expected. I thought not working out for two weeks
would be more challenging for me.

But I was also happy to start again at the end of this month. I took it slowly
to not stress my skin too much, and it felt good!

## 📚 Reading

The same lack of inspiration for writing also occurred in my motivation to read.
I didn’t finish a single book this month. It’s not that I didn’t read. It’s more
that I didn’t read close to how much I read otherwise.

But again, I tried not to force it and just be okay with it. It could be the
books I read currently or a lack of desire for Reading. But that’s fine because
it’ll change soon.

## 🕹Video Games

I started playing **Star Wars: Jedi Survivor** at the end of this month! I did
not have this on my list, but I recently saw a few videos on Youtube. It looked
amazing, and without too much research, I just bought it on launch day.

I’m just a few hours in, but I already enjoy it a lot. The story is excellent,
the graphics are very good (even on my Xbox series s), and it’s a lot of fun. I
can recommend it! It reminded me a lot of playing a Star Wars game years ago, so
it brought up a lot of nostalgia.

That’s it for the Developer Diaries in April 2023! See you next month!


Developer Diaries 12 is about "boring" work, a short holiday, pausing working out and finding great joy in a new video game.

Developer Diaries 12


If you watch one talk about the current state of web development, I recommend
the talk by
[Rich Harris: Frameworks, the Web, and the Edge](https://www.youtube.com/watch?v=uXCipjbcQfM).
It made me nod my head so many times I stopped counting.

It's so refreshing to listen to his humble opinions because they are
**detached** from the ever-ongoing discussions around the best technologies of
the web and focus more on a higher goal.

I wrote down my thoughts on some of his ideas to come back later to them every
now and then and **remind me why we are doing this**.

I want to state that I don't agree with everything Rich says in his talk.
However, I think that's pretty normal if you listen to someone's opinions.

### Your Framework is fine.

> The web doesn't suck because of JavaScript. The web sucks because of
> capitalism.

Rich points out that **websites aren't bad because of JavaScript** in this first
section of his talk. They are bad because of how data and algorithms have shaped
our society.

Recipe pages aren't clustered with Modals, Cookie Banners, or meaningless SEO
texts because of JavaScript. They are built like that because, sadly, that's
**how they make most of the money**.

> You shouldn't switch away from whatever makes you productive at shipping
> software.

These things also happen when you use any tech stack besides JavaScript because
they are detached from technology. So it doesn't make sense to jump on the wagon
every time a new framework comes up that claims to be a few milliseconds faster
and ships 10kb less JavaScript if you're intention stays the same: making the
most money, tracking your users, and neglecting user experience on purpose for
that case.

### 0kb of JS is not the goal

> The goal is to satisfy the user's needs, not to ship 0kb of JS.

We need to remind ourselves why we use the technology we use. The goal is not to
ship with 0kb of JS. The goal is to **give users what they want** in your
website or app.

If this means a lot of JavaScript is necessary to deliver the best user
experience, then that's how it is. A lighthouse score of 100 doesn't mean
anything if your users can't solve the task they want to accomplish.

### Most sites should work without JavaScript

> We need to ensure our tools keep working when unexpected things happen.

A thing we as developers do way too rarely is disabling JavaScript on a website
you've just built. So when I listened to Rich talk about this topic, I paused
and opened all the websites I recently built, disabled JavaScript, and tried to
move around them.

It's astonishing to me that this is not our highest priority. Progressive
Enhancements should be enforced way more, and the most crucial user needs should
be enabled to be accomplished without having to rely on JavaScript.

<CoffeeHint />

### MPAs are dead

Rich compares MPAs to SPAs here and explains why MPAs were on the rise, and SPAs
got a bad reputation.

Many of the reasons MPAs were better than SPAs (more accessible, faster, less
buggy, less JS) do not exist anymore because SPA frameworks like Next.js and
Svelte improved a lot and picked up.

The key argument against MPAs: **missing UI persistence**. MPA means when you
click a link, your browser does a full page reload.

UI persistence is only possible with client-side routing, which is only
available in SPAs. And UI persistence is a significant factor for a good user
experience.

### None of this matters

> I don't think AI will take our jobs soon, but I do think there's a
> better-than-even chance that it will change them beyond all recognition.

Rich points out that **the way we do our job will possibly change a lot in the
future due to the development of AI**. He's under the impression that it will
change in a way that code preferences will not play a role anymore in our
day-to-day job.

So we can have discussions and share ideas and inspiration around it, but in the
future, it might not be something we still need to consider.

I think that's an interesting point which I can support. It feels kind of
calming to me because it will mean we'll have the freedom to **focus on other
things but code preferences**.

And if you follow web development on social media, people love to discuss and
argue about code preferences. So if they can ditch that and focus on building
and shipping, it might be a good thing.

### Sources

- [Rich Harris Talk on YouTube ](https://www.youtube.com/watch?v=uXCipjbcQfM)


This blog post summarizes my thoughts on Rich Harris talk about the current state of web development and his opinions on frameworks, the web and the edge.

Rich Harris: Hot takes on the web


On May the first, Vercel announced a new product: **storage on Vercel**. Once
again the web community is **divided** into two big camps.

The first one **loves** this new product and can't wait to use it and ship their
products with it. The second one has a lot of **criticism** to share.

In this post, I'll share the thoughts of both camps, but first, let's have a
look what they announced.

### Vercel serverless storage solutions

Vercel storage is a suite of **serverless storage solutions**. The first one is
**Vercel KV**, a durable Redis database. The second is **Vercel Postgres**.
Vercel partnered with Neon here to introduce a serverless Postgres database.

And the third one is **Vercel blob**, which is file storage on the edge. So a
direct replacement for services like S3, which developers have used heavily for
use cases where you wanted to upload any kind of unstructured data.

What makes the release of this new product of storage on Vercel so interesting
is that all of these three storage solutions run **serverless**. So you don't
need an actual backend and an API layer to communicate to your database.

With the new `app` directory in Next.js, which makes use of React Server
Components, things get even crazier. By leveraging React Server Components, you
can even **directly communicate with your database from your components**.

Here's the example, Vercel shared to showcase their serverless postgres:

```jsx
import { sql } from 'vercel-postgres'
import { redirect } from 'next/navigation'

async function create(formData: FormData) {
  'use server'

  const { rows } = await sql`
    INSERT INTO products (name)
    VALUES ($formData.get('name')})
  `
  redirect(`/products/${rows[0].slug}`)
}

export default function Page() {
  return (
    <form onSubmit={create}>
      <input
        type="text"
        name="name"
      />
      <button type="submit">Create</button>
    </form>
  )
}
```

Let's have a look at what happens here.

- We have a `Page` component, which renders a form.
- When the form is submitted, the `create` function is called.
- The `create` function is declared as a server function by using `use server`.
  This ensures the function is only executed on the server and can't be imported
  from client components.
- Inside the `create` function, we use the `sql` tag from vercel-postgres to
  insert a new product into our database.
- And then, we redirect the user to the newly created product page.

A lot of people pointed out that this might be prone to **SQL injection**. But
it's not a regular template string getting inserted into the DB. Instead it's a
tagged template call, and the `sql` function does very likely sanitize the
input.

### Why people love serverless

Many people are really excited about this. The **developer experience** to build
a website that makes use of a database to store data where the frontend can
query and mutate the data directly has never been easier, in my opinion.

With serverless being a hot topic for years now, and the discussion if this is
the way to go vs. persisting on a separate backend, the release of Vercel
storage is another step towards the serverless future.

### Many Developers still love their backend

Next to the excited crowd are a lot of people who raise some **serious
concerns**. The first one, and probably the biggest one, is that Vercel storage
is just a **wrapper** around other services where you **pay a lot** to have a
better DX.

[Ottomated](https://twitter.com/Ottomated_) made a
[comparison table](https://service-markup.vercel.app/) around the costs of
Vercel storage vs. using other services. Also it's the number one topic, people
talk about on [Hacker News](https://news.ycombinator.com/item?id=35774730).

Next to that, a lot of people are concerned about having to pay very high bills
suddenly due to unexpected traffic spikes.

Lee Robinson did a great job of clarifying these two big critical points
[in this tweet](https://twitter.com/leeerob/status/1653636931291602953). He
talks about how Vercel can be more transparent about the usage controls and the
pricing.

The key takeway is that it's hard to find a **good balance** between a hobby
project not wanting to pay a sudden huge bill vs. a business not wanting there
website goes offline because they've exceeded its limits.

Another negative point I often hear is that Vercel is driving us away from open
source and getting more into vendor lock-in. Guillermo Rauch, the CEO of Vercel,
[argues against it](https://twitter.com/rauchg/status/1653523458616340483), by
saying that "everything about the platform remains composable".

He points out that "serverless databases are cool, but most of the world's
backend and data already exists and are not moving anytime soon."

I find it really interesting to follow these developments around serverless and
I'm curious to see how this will evolve in the future. I will definitely try out
Vercel storage soon, but also keep an eye on the critical points.

### Sources:

- [Introducing storage on Vercel](https://vercel.com/blog/vercel-storage)
- [Storage on Vercel](https://news.ycombinator.com/item?id=35774730)
- [Documentation of the makrup percentage of versel services](https://service-markup.vercel.app/)


Vercel recently introduced storage. A suite of serverless storage solutions like KV, Postgres and Blob.

Vercel Storage


Last month was pretty busy with **new AI changes almost every hour**. Everyone
is either **scared** of what might happen, if we lose our jobs, or if humanity
might get destroyed or enjoying the ride, being **excited** about the stuff that
happens so fast and not engaging with the fear and certainty around it.

I’d like to be part of group 2 and wrote a blog post around this topic:
[AI will make our jobs easier and not replace them](/blog/ai-will-make-our-jobs-easier-not-replace-them).

I’m really curious how all of this will turn out. If you’re interested in
reading a few interesting and inspiring blog posts about this, here’s a small
list:

- [Neither artificial, nore intelligent](https://hidde.blog/artificial-nor-intelligent/)
- [Pausing AI Developments Isn't Enough. We Need to Shut it All Down](https://time.com/6266923/ai-eliezer-yudkowsky-open-letter-not-enough/)
- [I for one welcome our GPT overlords co-workers](https://webdirections.org/blog/i-for-one-welcome-our-gpt-overlords-co-workers/)
- [The Age of AI has begun](https://www.gatesnotes.com/The-Age-of-AI-Has-Begun)
- [WHy ChatGPT Won't Replace Coders Just Yet](https://betterprogramming.pub/why-chatgpt-wont-replace-coders-just-yet-87487a9dda4e)

## 👨🏻‍💻 Work

Work-wise this month was quite **diversified**. I liked it a lot. I refactored a
big project to use TypeScript everywhere, which felt amazing. It made me more
confident to apply changes to the project. I’ve done some rather complex stuff
in this project and used plain JavaScript.

I don’t know how I managed to not break too much without using the proper types.
But now it feels much safer and better to implement new features.

On another project, I built features for a client that users had wished for a
long time. It felt really good to finally be able to give them the things they
were missing and to make both the client and the users happy.

Besides that, I’m **integrating AI** in the form of Chat-GPT and GitHub Copilot
more and more into my workflow. It’s great to explore the possibilities to make
my work more productive. I will write a more in-depth blog post about this soon.

## 📝 Blog Posts of the Month

I had a lot of fun writing blog posts last month. So here is the list of the
posts of March 2023:

- [What is prop drilling and how to avoid it](/blog/what-is-prop-drilling-and-how-to-avoid-it)
- [AI will make our jobs easier and not replace them](/blog/ai-will-make-our-jobs-easier-not-replace-them)
- [Developer Diaries 10](/blog/developer-diaries-10)

The prop drilling post is one I’ve had for a long time in my backlog. I had the
basic idea for it, but only last month did I get inspired by a lot of discussion
around the topic and finally write about it. So I’m pleased about that one.

The one about AI not taking our jobs was one of my most spontaneous ones. As I
already wrote in the introduction of this post, it’s the hot topic number one,
and all the news around made me write down my thoughts about it.

## 🎓 TIL Posts of the month

Here are the Today-I-learned posts of March 2023:

- [CSS Scroll Snap](/today-i-learned/scroll-snap)
- [React Server Components](/today-i-learned/react-server-components)
- [SVG Drawing Animation](/today-i-learned/svg-drawing-animation)
- [Vercel Cron Jobs](/today-i-learned/vercel-cron-jobs)

## 🏡 Life

We had a weekend getaway to the Lake of Constance. Unfortunately, the weather
was typical April weather, so we had everything from rain, storm, and sunshine
to cloudy. But that didn’t bother us too much. We had a great time eating good
food, walking along the lakeside, and just hanging out on our hotel balcony,
reading.

**Sometimes we don’t need to go too far to have a good time**. Just a small
change of scenery is enough to shake things up, get inspired again, and change
curtains.

## 🏋🏻‍♀️ Fitness

No longer living in a crowded city surrounded by hills means I’m having fun
running again. In only 20 minutes, I’m in the forest, which feels so good.

I ran over 15km for the first time in ten years and had no knee pain. What an
achievement.

I also love the combination of bodyweight strength workouts 2x a week and
filling the rest of the week with what I want to do spontaneously and depending
on the time I have, like core workouts, pilates, running, and biking. The
combination of everything that I enjoy is great.

## 📚 Reading

I managed to finish two books this month:

- [Mittagsstunde - Dörte Hansen](https://www.goodreads.com/book/show/40655908-mittagsstunde)

A book about people living on a small island on the north coast of Germany, who
have the typical struggles of people in general and a lot of lessons on life are
told. Great book!

- [The Border (Power of the Dog #3) - Don Winslow](https://www.goodreads.com/book/show/38376040-the-border)

The third book of the Power of the Dog series. I read the first two last year
and anticipated reading the last one of the series because I didn’t want it to
end. I almost couldn’t put the book aside. It’s cruel and brutal to read but
also, on the other hand, very thrilling.

## 🕹Video Games

I saw a video of the new Zelda game for the Switch and dug back onto Breath of
the Wild. I played it the last time in November of 2018. Crazy!

## 🎙Podcasts

Listened to an episode of Wes’ and Scotts
Podcast [Syntax.fm](http://syntax.fm/). A person asked if they could learn web
dev at the age of 47, which was super interesting to listen to.

- **Potluck × Learning Web Dev × Video Streaming × Mono Repos**
  [https://syntax.fm/show/591/potluck-learning-web-dev-video-streaming-mono-repos](https://syntax.fm/show/591/potluck-learning-web-dev-video-streaming-mono-repos)


Developer Diaries 11 is about a lot of thoughts about AI, having a diversified work month and the joy of weekend getaways.

Developer Diaries 11


Prop Drilling is a concept in React that is sometimes unavoidable but, in most
cases, should not be applied. In This article, I will discuss what it is and how
to avoid it.

---

**Table of Contents**

- [Props in React](#props-in-react)
- [What is prop drilling](#what-is-prop-drilling)
- [Context is not the solution](#context-is-not-the-solution)
- [Composition](#composition)
- [Sources and further reading](#sources-and-further-reading)

---

### Props in React <a id="props-in-react"></a>

To understand the concept of Prop drilling, we first need to clarify **what
props are** in React and how they are such a crucial aspect of
Reacts **success** concerning unidirectional data flow.

If you're already familiar with the concept of props in React,
[skip to the next section](#what-is-prop-drilling) in this article. But you also
might learn something new, like I did, although you've been working with React
for a while.

First and foremost, props are short for **Properties**. Props are used
to **communicate** from one component to another. For example, a Parent
Component can **pass information to children** by using the concept of props. To
pass props, you have to add them to the JSX, just like you can do with HTML
attributes.

You can pass some **predefined props** to your child components, like
`className`. You can also pass any props you want to your children. To read the
props, you can either destructure the individual props inside your functions
parenthesis or access the whole props object. Props are almost like function
parameters.

Here is a simple example of passing props down from a parent to a child
component and reading it there:

```JSX
// Parent Component

function ProductDetails() {
  return (
    <ProductHeader
      className="parent-component"
      productName="The best product ever"
    />
  );
}

// Child Component accessing the whole props object
function ProductHeader(props) {
  return (
    <div className={props.className}>
      <h1>{props.productName}</h1>
    </div>
  );
}

// Child Component destructuring the props object
function ProductHeader({ className, productName }) {
  return (
    <div className={className}>
      <h1>{productName}</h1>
    </div>
  );
}
```

Not only can you pass values via props down to your children, but you can also
send whole components through that informational pipeline. The parent component
can access the nested component via the **children's prop** by nesting a
component inside another component.

That's called **passing JSX as children** and is a widespread concept when
composing React apps. This gets important again when we talk about how to avoid
prop drilling. Here's an example of it:

```jsx
function ProductDetails() {
  return (
    <ProductHeader>
      <div>
        <h1>The best product ever</h1>
      </div>
    </ProductHeader>
  )
}

function ProductHeader({ children }) {
  return <div>{children}</div>
}
```

### What is prop drilling? <a id="what-is-prop-drilling"></a>

Now that we understand props in React, let's talk about prop drilling and why it
can become a problem.

We talk about prop drilling when we **pass the same props several levels deep
down the component tree**. Often these props get passed through components that
**are not interested** in them but need to help pass them down to a certain
point where they are required.

Here's an example of that. Imagine you have a component tree like this:

```jsx
<App>
  <Header />
  <MainContent>
    <ProductList>
      <ProductCard>
        <ProductDetailsModal>
          <ProductDetails>
            <ProductHeader />
            <ProductDescription />
            <ProductPrice />
          </ProductDetails>
        </ProductDetailsModal>
      </ProductCard>
    </ProductList>
  </MainContent>
  <Footer />
</App>
```

On the root level, you fetch the data of the products from your API and pass it
down to the components that need it.

Imagine we want to display the name of product in the `ProductHeader` component.
This means we need to pass the prop that withholds this information **all the
way** through our component tree six levels down. On the way five components get
this information, altough they **aren't even interested in it**.

```jsx
const productName = 'The best product ever'

<App productName={productName}>
  <Header />
  <MainContent productName={productName}>
    <ProductList productName={productName}>
      <ProductCard productName={productName}>
        <ProductDetailsModal productName={productName}>
          <ProductDetails productName={productName}>
            <ProductHeader productName={productName} />
            <ProductDescription />
            <ProductPrice />
          </ProductDetails>
        </ProductDetailsModal>
      </ProductCard>
    </ProductList>
  </MainContent>
  <Footer />
</App>
```

Why is this a problem? This seems to be the recommended way to pass down
information in React. For a few levels deep, making use of prop drilling is
fine.

But it gets **messy** if you apply this technique several levels down the
component tree. First of all, passing props down so deeply involves **a lot of
work**. And second, if you make one change to these props, you have to update
these changes everywhere, which makes it **verbose and inconvenient**.

Another big reason to avoid prop drilling is that **debugging is harder**.
Imagine you notice that on the level where you do something with the data, you
pass down so many levels, you get wrong values. So now you must trace the data
through all the components and figure out where something went wrong.

### Context is not the solution <a id="context-is-not-the-solution"></a>

When React Context was introduced, many developers believed this was the perfect
solution for a) **global state management** in React and b) **to avoid prop
drilling**.

Context lets a parent component **provide data to the entire tree below**.
Here's an example of using context with the code from above:

```jsx
const ProductContext = React.createContext()

function App() {
  const productName = 'The best product ever'

  return (
    <ProductContext.Provider value={productName}>
      <Header />
      <MainContent />
      <Footer />
    </ProductContext.Provider>
  )
}

function ProductHeader() {
  const productName = React.useContext(ProductContext)

  return <h1>{productName}</h1>
}
```

First we have to create a context object with `React.createContext()`. Then we
wrap our whole Application with a `Provider` component that provides the data we
want to pass down to the entire tree below.

At the point where we want to access the data, we use the `useContext` Hook to
access the data. In this case it's `ProductHeader`, which, as we've seen in the
example above, lies deeply nested inside the `MainContent` component.

This looks perfect, right? No need to pass props down several levels deep and we
can access it easily, where we actually need it.

If you consider using context to avoid prop drilling, I must disappoint you.
That's a bad idea. **Just because you must pass some props several levels deep
doesn't mean you should put that information into context**.

It's really easy to overuse this concept. So the official recommendation by the
React docs is to use context only for specific use cases and not just to avoid
prop drilling.

One of these use cases is theming, for example. If you want to style your
components differently, context is helpful to provide this information to the
components that need it when a dark mode is applied, for example. You can check
out the other recom use-cases for Context in the
[official React docs](https://react.dev/learn/passing-data-deeply-with-context#before-you-use-context).

### Composition <a id="composition"></a>

So, what else can we do if context is not the perfect solution to avoid prop
dilling? The answer is **composition**. Composition in React means how you
arrange your component tree. Dan Abramov, one of the core team members for
React, even wrote a tweet that
[being good at composing your React components is a top skill to learn in 2023 ](https://twitter.com/dan_abramov/status/1623771055943831553).

Let's recap real quick. First, prop drilling in React can be verbose and
inconvenient because debugging a prop passed down through many components can be
hard to debug.

And If you pass some data through many layers of intermediate components that
don't use that data (and only pass it further down), this often means that you
forgot to extract some components along the way.

Extracting some components along the way is kind of a definition for composition
in React. So you have to ask yourself: does it make sense that this component is
nested down several levels deep and passes data along it's not interested in? Or
can it be on a higher level up the component tree or part of another component
so we can remove a whole level on the component tree?

That's always the first step you have to make, when you notice that you have to
pass props down several levels deep.

Remember when we talked about passing JSX as children? This comes in handy when
you thinkg about composition in React and want to avoid prop drilling. Here's
our prop drilling example from above with a better composition:

```jsx
const productName = 'The best product ever'

<App>
  <Header />
  <MainContent>
    <ProductList productName={productName}>
      <ProductCard>
        <ProductDetailsModal>
          <ProductDetails>
            <ProductHeader />
            <ProductDescription />
            <ProductPrice />
          </ProductDetails>
        </ProductDetailsModal>
      </ProductCard>
    </ProductList>
  </MainContent>
  <Footer />
</App>

function ProductList ({ productName }) {
  return (
    <ProductCard>
      <ProductDetailsModal>
        <ProductDetails>
          <ProductHeader>
            <h1>{productName}</h1>
          </ProductHeader>
          <ProductDescription />
          <ProductPrice />
        </ProductDetails>
      </ProductDetailsModal>
    </ProductCard>
  )
}
```

In this example, composition in React is used to avoid prop drilling by passing
down the necessary props to child components **without having to pass them down
explicitly at each level**. The example demonstrates how to pass the
`productName` prop from the top-level App component down to the ProductHeader
component, which is nested several levels deep in the component hierarchy.

To achieve this, the ProductList component accepts the productName prop and
renders the ProductCard component with the necessary props. The ProductCard
component then renders the ProductDetailsModal component with the necessary
props, and so on until the ProductHeader component is rendered.

They main idea here is, that **we have to pass the prop only into one
component**, `ProductList`. This enables us to give the `ProductHeader` the
`productName` prop way higher up the component tree. This way we can avoid
passing the prop down several levels deep and prop drilling is no longer an
issue.

In conclusion, composition in React is a powerful technique that can help to
avoid prop drilling, which is a common issue when passing props down several
levels in the component tree.

By passing JSX as props we can avoid prop drilling which leads to cleaner and
more maintainable code. By using composition, we can create more modular and
reusable components, which can be easier to reason about and maintain over time.
Overall, composition is a key concept in React development that can lead to more
efficient and effective development practices.

### Sources & Further Reading <a id="sources-and-further-reading"></a>

- [Passing Props to a Component](https://react.dev/learn/passing-props-to-a-component)
- [Passing Data Deeply with Context](https://react.dev/learn/passing-data-deeply-with-context)
- [Tweet by Alex Sidorenko about prop drilling](https://twitter.com/asidorenko_/status/1623751929863016450)
- [Using Composition in React to Avoid "Prop Drilling" by React Training](https://www.youtube.com/watch?v=3XaXKiXtNjw&feature=youtu.be)
- [Passing JSX as children ](https://react.dev/learn/passing-props-to-a-component#passing-jsx-as-children)
- [Prop drilling and component composition in React by Alex Sidorenko](https://alexsidorenko.com/blog/react-prop-drilling-composition/)

```

```


Prop Drilling is a concept in React that is sometimes unavoidable but, in most cases, should not be applied. In This article, I will discuss what it is and how to avoid it.

What is prop drilling and how to avoid it


I firmly believe that AI will make our software developer jobs easier and not
replace them. In this blog post, I will talk about the fear and uncertainty
around AI and how it will change our jobs.

---

Table of contents:

- [ChatGPT-4 is here](#chatgpt-4-is-here)
- [The end of front-end development](#the-end-of-front-end-development)
- [Ways to integrate AI into your developer workflow](#ways-to-integrate-ai-into-your-developer-workflow)
  - [GitHub Copilot](#github-copilot)
  - [ChatGPT](#chatgpt)
  - [GitHub Copilot X](#github-copilot-x)
- [Conclusion](#conclusion)

---

### ChatGPT-4 is here <a id="chatgpt-4-is-here"></a>

ChatGPT-4 got released recently, and everyone is talking about it.
[OpenAI says it is more accurate, creative, and collaborative than the previous iteration](https://openai.com/product/gpt-4).

Watching this evolution of AI and how it might change everything in such a short
time is **mindblowing**. But on the other hand, many people are **worried**
about what will happen to their job when AI can do everything better and faster
than humans.

[New research](https://arxiv.org/pdf/2303.10130.pdf) by OpenAI, Open Research,
and the University of Pennsylvania has revealed which jobs are most at risk of
being automated by AI.

I understand the concerns around this topic. However, it seems like AI might
already **replace** illustrators because so many startups get created which
offer their users image generation services.

### The end of front-end development <a id="the-end-of-front-end-development"></a>

In addition to his, I stumbled over this article by Josh Comeau,
[the end of front-end development](https://www.joshwcomeau.com/blog/the-end-of-frontend-development/).
Although it's a very clickbaity title, it's a very interesting read, and I agree
with the author and share his beliefs.

But, contrary to the title, the author explains that AI **won't be the end of
front-end development** as we know it.

He shares several reasons why AI won't replace developer jobs. I've already
talked about most of them with other developers, friends, and colleagues.

> It's so funny that I wrote about this in 2021 when GitHub Copilot was
> released. And it's interesting to see that my beliefs haven't changed. You can
> check it out here:
> [GitHub Copilot is not stealing our jobs](/blog/github-copilot).

First and foremost, it's astonishing to see that
[ChatGPT can build simple websites from a hand-drawn sketch](https://twitter.com/rowancheung/status/1635744529587359756).
But, as Josh also puts it, that's a job we've seen being done by other tools
already for a long time. To build such simple websites, so many tools have been
available for years, yet web developers continue to exist.

I'm currently working on a large project which includes two different APIs and
several services in separate repositories. I'm primarily working on feature
improvements there and fixing bugs stretching through several services.

I always think about **how AI will be able to do this job for me**. We're
talking about hundreds of files and thousands of lines of code. So there's a
huge difference between generating simple apps and websites and working on a
large project with many services.

So I don't think AI can do my job soon. We're a very long way from that.

> To put this more into perspective, a recent study found that
> [ChatGPT4 produces misinformation more frequently and more persuasively than its predecessor](https://www.newsguardtech.com/misinformation-monitor/march-2023/).
> so there is still a lot of room for improvement.

But I'm also **not scared** at all. On the contrary, I'm very excited about the
future of AI and how it will change our jobs. For example, I think there will be
more and better ways to integrate AI into our work which will lead to
**increased productivity and value**.

Josh also states in his article that we might **delegate** tasks to AI, but we
will still need to understand how it works and how to use it, and I agree.

### Ways to integrate AI into your developer workflow <a id="ways-to-integrate-ai-into-your-developer-workflow"></a>

To summarize the thoughts from above, I think it's **time to be excited about
AI** and not be scared and fear the loss of our jobs. To encourage this, I want
to share a few ways how we can **integrate AI into our developer workflow**
already.

#### GitHub Copilot <a id="github-copilot"></a>

GitHub Copilot is a great example of this. It's already two years old, and many
developers have integrated it into their workflow.

If you haven't heard of it, it's an **AI-powered coding** assistant that can be
integrated via an extension into your IDE, like VSCode. It can provide code
suggestions based on your already written code or write the complete
functionality of a function for you if you give it a descriptive name.

It was free at first but now costs around 20$ a month, but I think it's worth
it.

It helps me to **increase my productivity**. It provides me code solutions
matching the context I'm in and based on the already written code. The best
thing is: it writes tedious and repetitive code for me. As you write there's
always grey suggestions which you can enable by pressing tab.

It's also great with helping to reduce errors because it provides you with the
correct syntax and knows the correct names of functions and variables.

I can't imagine working without GitHub Copilot anymore. I always think about a
problem, figure out a way to solve it, and write out the base layout and
skeleton. GitHub Copilot then fills in the details, which I then tweak to my
needs and preferences. That's a perfect symbiosis between AI and me as a
developer. I give the direction and figure out the architecture, and AI fills in
the blanks.

#### ChatGPT <a id="chatgpt"></a>

Besides GitHub Copilot, ChatGPT can also be integrated in so many ways into your
workflow already to increase your productivity and value created.

One example is to use it to **write tests**. You give it the code of a
component, for example, and it will figure out every behavior and scenario this
component is in and write useful tests for it.

Another use-case is to use it to **write documentation**. I haven't tried this
yet, so I'm not sure how well this works, but from what we've seen already, it
should be very helpful with this. You give it examples of your code and it will
write the documentation for you.

AI-powered tools like ChatGPT can also be integrated into your developer
workflow when you try to **learn a new language**. For example, imagine you're a
front-end developer who works on a project where the backend is written in Go.
You'd like to get a better understanding of a specific backend service because
you want to work with the data that gets manipulated there. But you haven't used
Go much before.

ChatGPT can help you to understand the code and the concepts of Go and answer
your questions. So it helps to increase your productivity, and you won't need to
bother your colleagues with questions all the time.

It's also great to get a better understanding of certain concepts of a new
framework or new additions to a language that you haven't used before.

Finally, I often use ChatGPT to write specific functions that I didn't know how
to write. For example, recently, it wrote me **csv to json compile function in
node with typescript**. I could've written it myself with some research, but it
was **faster** to just ask ChatGPT to do it for me.

#### GitHub Copilot X <a id="github-copilot-x"></a>

I already finished this blog post and published it, and minutes later, I saw the
release post of
[GitHub Copilot X](https://github.blog/2023-03-22-github-copilot-x-the-ai-powered-developer-experience/).
Wow! When I wrote this blog post, I thought about how cool it would be to **have
ChatGPT in your IDE**. And now, with GitHub Copilot X we get exactly that.

A ChatGPT-like experience in your editor with **GitHub Copilot Chat**, which
does far more than the already existing GitHub Copilot, which can only suggest
code.

It enables you to have **context aware conversations**. It knows all the ins and
outs of the codebase you're working in and can help solve bugs, improve features
or help you in general when you're stuck somewhere. That's crazy.

I can't even imagine how the next few years will look like and change the way we
work.

But GitHub Copilot X is not only a ChatGPT addon. It also implements AI
improvements for your **Pull Requests**, to get AI-generated descriptions for
them.

With GitHub Copilot X, you will also be able to get **AI-generated answers about
documentation**. When you have questions about the documentation, it will
provide accurate responses out of the official documentation of the technology.
This will be available for the React, Azure, and MDN Docs first.

And finally, it will be integrated into the **command line interface**, to
compose commands and loops to use for you in your terminal. Have you ever been
searching the web to write a specific command to use in your terminal? Now you
can just ask GitHub Copilot X to do it for you.

**But:** GitHub Copilot X is not the new version of Copilot and **won't be
available soon**. GitHub calls it a **representation of GitHub's vision for the
future**. So it's not an available product we can use right away.

They are testing and trying out ways to provide it to us in the future. But it's
still amazing to see what's possible and what's coming. I can't wait to try it
out.

### Conclusion <a id="conclusion"></a>

To sum it up, I think it's **time to be excited about AI**, not be scared, and
engage with the fear and uncertainty around it. Instead, I think it's time to
**embrace it** and **integrate it into our developer workflow** to increase our
productivity and the value created.

Nobody can predict the future, but I think it's a healthy habit to welcome a
tool like this that brings a lot of change and make the best out of it.

So far, these tools are making our job as developers easier, which I like a lot.
Maybe I'm entirely wrong about this, and in a few years, we'll all turn into
farmers, and AI will take over our jobs. But as long as it doesn't happen, I'm
happy to embrace the change.

### Sources and further reading <a id="sources-and-further-reading"></a>

- [GPT-4 is OpenAI’s most advanced system, producing safer and more useful responses](https://openai.com/product/gpt-4)
- [GPTs are GPTs: An Early Look at the Labor Market Impact Potential of Large Language Models](https://arxiv.org/pdf/2303.10130.pdf)
- [The End of Front-End Development by Josh Comeau](https://www.joshwcomeau.com/blog/the-end-of-frontend-development/)
- [GitHub Copilot is not stealing our jobs](/blog/github-copilot-is-not-stealing-our-jobs)
- [ChatGPT can build simple websites from a hand-drawn sketch](https://twitter.com/rowancheung/status/1635744529587359756)
- [Despite OpenAI’s Promises, the Company’s New AI Tool Produces Misinformation More Frequently, and More Persuasively, than its Predecessor](https://www.newsguardtech.com/misinformation-monitor/march-2023/)
- [GitHub Copilot X: The AI-powered developer experience](https://github.blog/2023-03-22-github-copilot-x-the-ai-powered-developer-experience/)


I believe that AI will make our jobs easier and not replace them. This blog post is about the fear and uncertainty around AI and how it will change our jobs.

AI will make our jobs easier and not replace them


Welcome to Developer Diaries number 10! I recap everything that happened in
February 2023. First and foremost: **Happy Anniversary to me**! My freelancing
career turned one year on February the second. Yay!

## 👨🏻‍💻 Work

As expected, January was low and more relaxed, while February quickly increased
speed. We had a lot of talks with possible future clients. We had pitches,
chemistry meetings, and people contacting us for help to get a better website.

This is a lot of fun because it's always great to see when clients understand
that we can help them a lot.

It's also interesting to see that with all these fantastic tools that enable
people to build websites themselves without the knowledge to code, they still
like to trust experienced contractors for everything beyond a simple landing
page or a blog.

They either don't have the time, knowledge, or other resources and happily pay
someone for it. But I also like the thought that these tools might do easier
jobs for us, not to make us unemployed but to free us so that we can **focus on
other tasks**.

That being said, I used ChatGPT for the first time in a helpful way (and not
just to play with it), which sparred me so much time. It was way **more
efficient than googling**. It'll be interesting to see how it will fit into a
developer's workflow soon.

## 📝 Blog Posts of the month

I had a lot of fun writing last month and a lot of great ideas for new blog
posts. However, my backlog is growing bigger, and I need to prioritize.

Here are the posts from February 2023:

- [The web needs improvement](/blog/the-web-needs-improvement)
- [WordPress vs. Headless CMS](/blog/wordpress-vs-headless-cms)
- [Migrating from Gatsby to Next.js](/blog/migrating-from-gatsby-to-nextjs)
- [Developer Diaries 09](/blog/developer-diaries-09)

I especially liked the **WordPress vs. headless CMS** because it stems from our
discussion with almost every client. Everyone knows WordPress and has used it at
some point. So they are tempted to use it again. It's a great thing about our
job to show them that there might be **better alternatives** for their use case.

## 🎓 TIL Posts of the month

Here are the Today-I-learned posts for February 2023:

- [Vercel Cron Jobs](/today-i-learned/vercel-cron-jobs)
- [Input Attributes for better Forms](/today-i-learned/input-attributes-for-better-forms)
- [What's new in Lighthouse 10](/today-i-learned/whats-new-in-lighthouse-10)
- [Don't use return types in TypeScript](/today-i-learned/dont-use-return-types-in-typescript)

I'm really excited about the Cron Jobs in Vercel and can't wait to have an
opportunity to try them out. It's interesting to see the fantastic output of the
people at Vercel these days.

## 🏡 Life

Never felt the saying _Life flies past_ so true like in the last month. I blink
twice, and it's Wednesday. I blink again, and it's Saturday. It's crazy. That
makes it even more important to me to **enjoy the little moments**. Pause more
often and focus on the now. Don't think about the future too much. Cherish what
I have now.

## 🏋🏻‍♀️ Fitness

I love my workout routine at the moment, and I found a great balance between
everything sports related that I enjoy. It feels so **diversified**. I also
started running again, which felt amazing. I tried running as slowly as possible
to keep my heart rate low and ran almost ten kilometers.

It was the first time in ten years that I did that without pain, which is one of
my most outstanding achievements from the last years. So cool.

Here are my apple watch rings from February 2023:

![Apple Watch Rings from February 2023](/images/apple-watch-rings-february-2023.webp)

## 📚 Reading

I finished two books last month and liked them a lot. Both were Christmas gifts,
and it's great that I have people in my Life who manage to find books I might
enjoy.

- [Zur See - Dörte Hannsen](https://www.goodreads.com/book/show/61073953-zur-see)
- [An der Grasnarbe - Mirjam Wittig ](https://www.goodreads.com/book/show/59457852-an-der-grasnarbe)

## 🕹Video Games

My wife started playing Hogwarts Legacy, and I can't even describe how much she
loves it. It's so cool to watch her play it while whispering, "it's so pretty,"
every five minutes.

I have only tried it for a few minutes, but I plan to play it soon when my wife
is done with her playthrough.


Developer Diaries 10 is about my freelancing career turning one year old, a lot of talks with possible future clients, and a lot of fun writing blog posts.

Developer Diaries 10


Recently, I had a few experiences that shocked me. I wanted to accomplish some
small tasks on several websites. And I **struggled** with all of them. I can
confidently say I wasn't the problem, but the websites were. And the worst of it
was **no valuable error feedback for the user**!

Let's dive right into it. Here are the three tasks I wanted to accomplish:

- ☑️ Change my address on a payment platform
- ☑️ Change my invoice delivery method on a mobile provider's website
- ☑️ Change my Email address on a mobile provider's website

Let's start with the first one.

### Changing my address on websites

I had a little "housekeeping" to do a few days ago. The first thing I wanted to
do, was to change my address on a famous payment platform. So I headed to the
website, logged in, navigated to my profile, and added my new address details.
After clicking save, I got the feedback that the address had changed
successfully. But after heading back to my profile, it was still **the old
one**.

I tried it again a few times, even changing browsers and devices, but I also had
**no success there**. So finally, I was confused and annoyed and moved on to
something else.

### Don't send me receipts on paper, please

Next up on my list was that I wanted to change how I get my invoices from my
mobile provider. By default, they send them printed out to my mailbox, and I
don't need that. I'd be delighted to get them online in my account.

I tried to accomplish that by opening the native app. It even prompted me to
make this change, so I navigated to the menu item. It then opened an in-app
browser, tried logging me in on the mobile providers' website, and showed **an
endless spinner**. That's it. Great!

Of course, I tried again but couldn't get it to work. No user feedback at all
about what I can do differently or where the problem stems from. I ditched the
native app and did it on the website directly. I logged in and navigated to the
menu item. It navigated me to another page showing **an empty orange box**.
Awesome!

So far, two basic tasks on a website have been unsuccessful. But I had to do
another. I wanted to change my Email address on the website of my mobile
provider. Easy task, right? I navigated to my profile, headed to the section
where you can change your Email, and entered my new one. Guess what happened
after clicking on save? Yes, you're right. Nothing!

### The web is not accessible

I don't want to turn this blog post into a big rant. That's not my goal or
primary focus in writing about these experiences.

I also don't want to bash developers or product teams responsible for this.
**Bugs happen. Humans write harmful software all the time**.

But I'm still astonished that simple processes like this don't work. And they're
also not showing any helpful **user feedback** or **error messages**. And I can
imagine these are tasks that many users want to accomplish daily.

I'm a person with a technical background. I know I didn't do anything wrong, and
it's the website's fault that I can't accomplish my goal. But think about other
people who are not tech-savvy. They are just confused and angry and search for
the fault in themselves. That's bad.

It's disappointing that many websites out there are still in **bad condition**.
It's not everyones focus to make their website as accessible as possible. The
web is not accessible at all. And this needs to change.

There are still so many anti-patterns, from popups to cookie banner madness to
newsletter signups covering the whole page.

### AI will not come to the rescue

It's disappointing to know that a lot of websites are still bad. I'm sure the
workflows described above are not the most critical. But that does not make them
less relevant to users.

It's disappointing that in 2023, that these bad experiences even happen on pages
with **millions of customers**.

And I can confidently say that **AI will not help with these cases**. It's
awesome that something like ChatGPT exists. It can help with a lot of tasks
already. But it can't solve the problem that many websites are in bad shape.

On the other hand, I will not lose my job soon because there is still so much
work to do to make the web a better, more user-friendly, and more accessible
place.

### Helpful Error messages

Here are **two things you can do** right away if you have workflows on your
website that your users have problems with. First and most important: give your
users **valuable and actual error messages**. Just showing a yellow error box is
not helpful.

The Nielsen Normal group has a fantastic article about error message
guidelines: [Error Message Guidelines](https://www.nngroup.com/articles/error-messages/).

And second, have a channel open for your users to **communicate feedback and
report bugs**. Always keep communication available to your users. When I wanted
to talk to someone about this problem, I discovered I couldn't find a possible
way to communicate my findings in any manner. This was the most annoying thing
about it.

So if we look back at the beginning of this article, and recap the tasks, I
wanted to accomplish, it looks like this:

- ❌ Change my address on a payment platform
- ❌ Change my invoice delivery method on a mobile provider's website
- ❌ Change my Email address on a mobile provider's website

Our Job is to make the web better. And we need to do better.


Recently, I had a few experiences that shocked me. I wanted to accomplish some small tasks on several websites. And I struggled with all of them.

The Web needs Improvement


If you have been working on the web over the last few years, you have heard the
term **headless CMS**. In this blog post, I will take a closer look at headless
CMSes, share the advantages over a traditional monolith CMS like **Wordpress**,
and clarify why WordPress is still so popular.

---

**Table of Contents:**

- [What is a headless CMS?](#what-is-a-headless-cms)
- [Why WordPress powers over 45% of the Internet](#why-wordpress-powers-over-45-of-the-internet)
- [Disadvantages of WordPress](#disadvantages-of-wordpress)
- [Reasons to go with a headless CMS](#reasons-to-go-with-a-headless-cms)
- [My favorite headless CMS](#my-favorite-headless-cms)
- [Conclusion](#conclusion)
- [Sources](#sources)

---

## What is a headless CMS? <a name="what-is-a-headless-cms"></a>

A headless CMS is a Content Management System that only acts as a **backend
service**. It’s accessible via an API and is missing the viewable part for the
users, hence the term headless.

A headless CMS is a place that **only holds the Content**, nothing else. To make
this Content available to your users, you must fetch it and build your own
“head,” your Frontend.

Traditionally, a CMS has always been both; Frontend and Backend. However, the
shift from traditional CMS to headless CMS emerged due to new requirements that
started to develop.

Content needs to be distributed not only in one place, one single website but on
**multiple platforms**, like mobile apps and third-party platforms.

That’s how the idea transformed: the Content should be **detached** from the
Platform where you view it. In addition to these changing requirements, a lot of
new technology developed. People wanted to be free and more flexible in their
choice of technology and not only use Server-Side Rendering with PHP because
that’s what WordPress uses.

Frameworks like Gatsby, Next.js or Remix showed substantial performance
improvements, and People wanted to use these new approaches. So the detaching of
the Content from the view, the detaching of the Backend from the Frontend, by
using a headless CMS enabled Developers to explore new ways.

## Why Wordpress powers over 45% of the Internet <a name="why-wordpress-powers-over-45-of-the-internet"></a>

So when headless CMS is the new shiny and big thing, why is WordPress still
powering over 45% of the Internet?

Yes, you’ve read right; that number is accurate.
[In 2023 WordPress is used by over 45% of all websites](https://trends.builtwith.com/cms/traffic/Entire-Internet),
which translates to nearly 39 million websites. That’s a market share of 63% of
all the CMS.

WordPress picked the right place and time to shine when it was released. It
started as a blogging platform back in 2003. It was and is still completely
**free**. It’s open source and offers a crazy amount of plugins to enhance your
website with features.

You can get very far initially, without any coding experience, when using
WordPress to build a new Website. If you’re a small business and don’t have the
resources or the money to hire a developer or an agency, **it was and still is a
great option to get a website fast**.

You choose a theme and hosting service and start publishing your content. Due to
its age and popularity, it has a big community where you can find help and
support if you’re stuck.

So WordPress is still a great option if you need a website and want to use a
CMS, right? Why bother with headless CMS if WordPress gives you all you need?

Great question. Let me explain this in-depth in the next section. As I said
before, with limited resources, needs, and requirements, WordPress is a **good
choice**. But unfortunately, it has a lot of **disadvantages** that can grow on
you.

## Disadvantages of Wordpress <a name="disadvantages-of-wordpress"></a>

WordPress might offer a fast way to publish your content initially. But
generally, it has **long and slow build times** when you release something new.
This is because you have to publish the latest content, and your whole website
must be built and published again.

I've already discussed the Plugin ecosystem to enhance your Websites features.
It might be a good idea at first. But it can also lead to a lot of
disadvantages. If you use a ton of third-party plugins, chances are that these
**slow down the performance** of your website dramatically.

Another factor you have to consider is that using plugins always leads to
third-party **dependencies**. You have to check and regularly update them to
newer versions. Otherwise, you risk **security issues**. Even if you have a
basic website and use a free theme, you have to keep this theme up-to-date.

So bad performance, unfortunately, is a thing when using WordPress. Of course,
I'm not saying this is true for all WordPress sites. But you must care a lot to
prevent falling into this trap. You have to pick your plugins carefully. You
must choose your hosting service wisely. In general, **I find it harder to make
a WordPress website fast**.

Security issues are another big thing. If you're using WordPress, you must host
your content and code together. Your content is technically directly accessible
through your Frontend, meaning if you don't take the right actions, your
Database can be accessed through the browser.

I've heard from many people who got **hacked**, and their content was deleted
that way. So you have to be aware of these things, make sure your website is
safe, your Database secured, and your Plugins updated—a lot of extra steps to
take, to use WordPress.

Finally, how content is distributed changed significantly in the last ten years.
Content is not only bound to a website and shared there. But **WordPress is tied
to your content**; if you're using WordPress, your content is tailored for it.

## Reasons to go with a headless CMS <a name="reasons-to-go-with-a-headless-cms"></a>

Now we've learned about the disadvantages of WordPress. What about headless CMS?
Do they share them, or can they overcome them? Let's have a look.

As I already discussed, headless CMS is a different approach. You have a **clear
separation between your Content and your Code**. Your Frontend is decoupled from
your Backend. Your Content is stored in the CMS and accessible via an API. This
is one of the best reasons to choose a headless CMS.

This clear separation brings the biggest benefit. Having one place for your
Content, decoupled from an actual website, enables you to **distribute your
Content on multiple platforms**. The old approach via WordPress meant that your
Content was tailored for your WordPress website, structured in web pages, and
not flexible.

With the headless approach, you treat your Content more like the data and care
about the **meaning less about the presentation**. You focus on the Content,
which then can be distributed on a website, a mobile app, an in-store digital
signage, wherever possible.

The actual head, the presentational layer, can be built with a developer's
preference. This can be with a SPA, a framework like
[Next.js](https://nextjs.org/) or [Remix](https://remix.run/), or a simple,
plain, and static HTML site. You are not bound to the server-side-rendering
technique with PHP, which WordPress uses.

This can lead to a way better experience concerning **performance**. It offers
more flexibility. If you decide to swap the presentational layer, no hurdle
stops you from doing so, as you are detached from your Backend. The only
connection is via an API Call.

This also leads to the final reason to go with a headless CMS. It's **way more
secure than WordPress**. The Backend is separated from the Frontend. There is no
direct unrestricted access through the browser. So to make a POST or DELETE
Request from your website to your headless CMS is way harder.

## My favorite headless CMS <a name="my-favorite-headless-cms"></a>

So there are many reasons to go with a headless CMS nowadays instead of using
traditional Monolith CMS like WordPress. My favorite headless CMS currently is
[Prismic](https://prismic.io/). I’ve done all my client projects with it over
the last two years, and all my clients are happy about it.

I’ve tried others, of course, and compared. I was a long-term fan of
[Contentful](https://www.contentful.com/), for example, until their pricing
became a little too expensive for smaller client websites. So, for now, I’ve
settled on Prismic. But I’m always looking out for better options and comparing
other solutions.

### Prismic

I like Prismic a lot because their Content Editing experience is so
**user-friendl**y. In addition, they follow this approach of
[custom types and Slices](https://prismic.io/docs/content-modeling) to model
your Content, which I like a lot. With custom types, you can build your
documents as needed, while slices can be added as a **dynamic content section**
on your documents.

The **developer experience** is excellent, especially with the
[automated Type generation](/blog/typescript-tooling-in-prismic), which was
added recently.

You have **unlimited languages**, a **preview mode** where content editors can
preview their changes before publishing, and they can even **schedule** when it
should be published. The publication of new Content is also fast. You hit
publish and get the new Content via API.

If you’re working with multiple people, the **history** functionality is handy.
You can see what others changed, deleted, or updated and even jump to later
versions of your Content.

You get unlimited storage and built-in image optimization if you want to share
many **images or other assets**.

What I dislike about Prismic and think there is room for improvement is the
organization of these assets. You cannot add **tags**, order them in
**folders**, or similar things. I had multiple clients lacking this feature, and
I hope it will make it into Prismic soon. Unfortunately, it’s a
[pending feature request](https://prismic.io/docs/content-modeling) that hasn’t
yet arrived on the roadmap.

Another thing where I’m not sure what to think about is that **Prismic tries to
be both: a place for your Content and a page builder**. I know I praised the
possibility of how Prismic enables you to model your Content with Custom Types
and Slices. But if I think about it again, this seems to **contradict** the
headless CMS approach. Where Content is just structured data, and you only care
about the meaning of it, less about the presentation.

What I’ve struggled with the most while using Prismic is the API documentation,
especially when I need to **query relational data**. I’m not sure where my
problem was, but I had a hard time doing that, even after seeking support from
the community.

### Sanity

Next to Prismic, I'm checking out [Sanity.io](http://sanity.io/) at the moment.
They offer all of the features that Prismic has as well. But they have a **more
generous free plan**. In addition, you get more user accounts, while in Prismic,
you must pay for more than one user.

I also like their approach of treating content as plain data where you don't
care about the presentation of it, but you care about the meaning. My first
steps of using [Sanity.io](http://sanity.io/) gave me the impression that it's
more customizable. I'll need a bigger project to get a complete image, but I am
eager to test it.

## Conclusion <a name="conclusion"></a>

So that's it. These are the reasons why I like using a headless CMS, which ones
I'm currently digging, and why WordPress projects don't tempt me.

If you're still on the fence about whether to go with a headless CMS or a
traditional CMS like WordPress, it's worth considering the advantages and
disadvantages of both approaches.

While WordPress is still the go-to choice for many businesses due to its ease of
use and large community, a headless CMS offers much more flexibility and can
help you distribute your content across multiple platforms. Additionally,
headless CMSes tend to be more secure and provide better performance.

## Sources <a name="sources"></a>

- [What is Headless WordPress?](https://www.gatsbyjs.com/docs/glossary/headless-wordpress/)
- [Headless CMS Explained by Knut Melvær](https://www.sanity.io/headless-cms)
- [What Is Headless WordPress—And Should You Use It? by Charlotte Dillon](https://www.netlify.com/blog/what-is-headless-wordpress/)
- [Headless CMS vs. Traditional CMS by Joe Holmes](https://www.sanity.io/headless-cms/headless-vs-traditional-cms)
- [CMS Usage Distribution on the Entire Internet](https://trends.builtwith.com/cms/traffic/Entire-Internet)
- [Usage statistics of content management systems](https://w3techs.com/technologies/overview/content_management)


In this blog post, I will take a closer look at headless CMS and share the advantages over a traditional monolith CMS like Wordpress.

WordPress vs. headless CMS


Recently I decided to migrate my website from Gatsby to Next.js. There were
several reasons for it, which I'll explain in detail below, but the main reason
was that I primarily work with Next.js in clients' projects, so it made sense to
me to migrate my website to it.

Next.js provides fantastic documentation on what you need to do to migrate
successfully from Gatsby no Next.js.

Nevertheless, there are some things I wish I had known when getting into it. In
this blog post, I'll document everything about the process, what to look out
for, and what I've struggled with to make your migration to Next.js a
**success**.

---

**Table of Contents**

- [My Reasons to migrate from Gatsby to Next.js](#my-reasons-to-migrate-from-gatsby-to-nextjs)
- [Updating package.json and dependencies](#updating-packagejson-and-dependencies)
- [Static assets and compiled output](#static-assets-and-compiled-output)
- [Creating Routes](#creating-routes)
- [Styling](#styling)
- [Links](#links)
- [Data fetching](#data-fetching)
- [Images and Image Optimization](#images-and-image-optimization)
- [Site metadata](#site-metadata)
- [SEO](#seo)
- [Conclusion](#conclusion)

---

## <a name="my-reasons-to-migrate-from-gatsby-to-nextjs"></a> My reasons for migrating from Gatsby to Next.js

My main reason for migrating from Gatsby to Next.js was **convenience**. In
client projects, I solemnly use Next.js. The last project, where we used Gatsby,
is two years old. I'm just much more used to it and faster.

I can't say anything terrible about Gatsby. On the contrary, when I chose to use
it initially for my website, I was pleased with it. The ton of plugins enabled
great features and improved my website a lot.

But at the point where I am now, I don't like the GraphQL approach anymore, and
I'm happier with the `getStaticProps` approach by Next.js.

Also, I couldn't get Typescript to run on the project of my website. This is not
Gatsby's fault, but it was another reason for me to migrate.

Using Gatsby with the ton of plugins felt great at first. I needed a sitemap so
I installed a plugin for it. If you want to have an RSS feed here, add this
plugin. But with time, **it felt like relying heavily on jQuery years ago**. A
lot of stuff is happening under the hood, it works, but I don't understand it.

Next.js doesn't use a plugin system and includes more in the framework itself.
So you can play more with it yourself, which I like today. So these are the
reasons I chose to migrate from Gatsby to Next.js. So now, let's talk about the
steps to achieve that goal!

## Updating package.json and dependencies <a name="updating-packagejson-and-dependencies"></a>

To **get started** with the migration, the first step you have to take is to
**delete** all the packages from your `package.json` with Gatsby in their name.

<Image
  src="/images/migration-nextjs-diff.webp"
  alt="This image shows the Diff of the package.json when I removed every gatsby related package"
  width={463}
  height={391}
/>

Also, make sure to delete Gatsby-specific scripts from the `package.json`. After
getting rid of all the Gatsby stuff, we can get into Next.js.

Before installing Next.js, you have to check your React Version. I was still on
17.x.x. This meant upgrading React first!

```bash
npm i react@latest react-dom@latest
```

Now we are ready for Next.js. Install it and add the Next.js
specific **scripts** in your package.json.

```bash
npm i next
```

```json
"scripts": {
  "dev": "next dev",
  "build": "next build",
  "start": "next start",
},
```

My Gatsby site didn't have **TypeScript**, so I also added this. First, you have
to create a `tsconfig.json`. Next.js will automatically fill it. Then install
Typescript and the types for react, react-dom and node.

```bash
npm i typescript @types/react @types/react-dom @types/node
```

It's amazing how Next.js automatically reacts to that and configures TS for your
Next.js project. Nice!

## Static assets and compiled output <a name="static-assets-and-compiled-output"></a>

When we have the packages and dependencies in place, it's time to get into the
project.

In Gatsby, the **public** directory has a different meaning than in Next.js. In
Gatsby, it's the place where the compiled output lands. In Next.js, it's used
for static assets.

So we have to adjust that. The best way to resolve that, according to the
Next.js docs, is by removing `.cache` and `public` from `.gitignore`, deleting
both folders, and renaming the static folder to public.

Then add the `.next` folder to your `.gitignore`.

In Gatsby, everything is inside a src folder. If you start a new Next.js
project, they are not using an src folder, and everything is on root. I got rid
of the src folder, but it's not mandatory.

## Creating Routes <a name="creating-routes"></a>

**Page routes** work differently in Gatsby and Next.js. In Gatsby, you have to
use the `createPages` function in `gatsby-node` and use a template file for
every page. In Next.js, you use **folders** to create routes for pages.

Therefore I created a pages directory and moved every template file as a page
inside of it.

I followed the documentation for dynamic pages and used the bracket syntax and
`getStaticPaths`. It was straightforward to get the route creation to work.

<Image
  src="/images/nextjs-pages-folder.webp"
  alt="This image shows the pages folder with all the pages inside of it which is used to create routes in Next.js"
  width={358}
  height={455}
/>

## Styling <a name="styling"></a>

In Gatsby, **global CSS** files are imported in `gatsby-browser`. To use global
CSS in Next.js, you must create an `\_app.js` file and import it there.

```jsx
import '../styles/styles.css'
import '../styles/night-owl.min.css'
import type { AppProps } from 'next/app'

function MyApp({ Component, pageProps }: AppProps) {
  return <Component {...pageProps} />
}

export default MyApp
```

I also took the opportunity to migrate from styled-components to TailwindCSS. It
was complicated to use styled-components in Next.js, and I rarely use them in
client projects because I'm more productive with TailwindCSS.

## Links <a name="links"></a>

Both frameworks offer a **Link component**, but the syntax is slightly
different. Gatsby's Link has a `to` prop where you have to pass the URL in, and
in Next.js, it's called `href`. So I changed this everywhere and completed the
next step of the migration.

```diff
- <Link to="/blog/">Blog</Link>
+ <Link href="/blog/">Blog</Link>
```

## Data fetching <a name="data-fetching"></a>

**Data fetching** is the topic that shows the most significant difference
between Gatsby and Next.js.

In Gatsby, the default way to fetch data is to use **GraphQL**. In Next.js, you
have different options: `getServersideProps` for **server-side rendering** or
with `getStaticProps` and `getStaticPaths` for **static site generation**.

To migrate the data fetching process, you have to delete every GraphQL query and
integrate your preferred data fetching method in Next.js. For me, this meant
adding the `getStaticProps` function in every page file and querying there for
the data needed.

I'll write a different blog post about how I migrated from querying my blog
posts in Gatsby with GraphQL to doing it in Next.js. It's an interesting topic
on it's on, and it would make this blog post too big. As soon as I publish it,
I'll link it here!

## Images and Image Optimization <a name="images-and-image-optimization"></a>

In Gatsby, I used the `GatsbyImage` Component heavily for responsive images.
Next.js has something similar. The main difference is that it doesn't optimize
images at build time as Gatsby does, but on-demand as users request them.

You can import it from `next/image`, and the usage is pretty straightforward.

```jsx
import Image from 'next/image'

return (
  // ...
  <Image
    alt="a picture of Marco Heine"
    src="/images/marco-heine.webp"
    className="mb-10 max-w-[300px] sm:mb-20"
  />
)

// ...
```

## Site metadata <a name="site-metadata"></a>

In Gatsby, you can define **metadata**, like the title or author, in a
gatsby-config.js file. This data can be queried via GraphQL. For the migration
to Next.js, you can move this data into a config.js file and import it whenever
needed.

## SEO <a name="seo"></a>

Gatsby encouraged everyone for a long time to use `react-helmet`. They have a
built-in solution now, but my project still used `react-helmet`. In Next.js, you
can use `next/head` and add every meta tag as children.

```jsx
import Head from 'next/head'

export const Head = () => {
  return (
    <Head>
      <title>Marco Heine's website</title>

      {/*  add meta tags here */}
    </Head>
  )
}
```

## Optional: Migrating from Netlify to Vercel

As all my client projects are hosted on Vercel, I also wanted to migrate my
website from Netlify to Vercel. This is **optional**. You can migrate your
website from Gatsby to Next.js and still host it on Netlify.

But if you decide to use Vercel, they also have
a [fantastic migration guide](https://vercel.com/guides/migrate-to-vercel-from-netlify).

## Conclusion <a name="conclusion"></a>

I don't know how long it took me to complete the migration. But it was a
**smooth process** from the beginning to the end. I had **no trouble** at any
time, and if you're also thinking about doing it, I recommend it.

I don't know if the Performance of my website improved much because I already
had high Lighthouse scores with Gatsby. But I took the time to change and
refactor some things independent of the migration, which made my website even
more **accessible and faster**.

If you're curious and have read until this point, check out
[the full Pull Request for the migration](https://github.com/marcoheine-com/marcoheine.com/pull/26)

## Sources

- [https://nextjs.org/docs/migrating/from-gatsby](https://nextjs.org/docs/migrating/from-gatsby)


In this blog post I'll document everything about my process of migrating from Gatsby to Next.js and what I've struggled with.

Migrating from Gatsby to Next.js


Welcome to 2023!

It seems a bit late to write this at the start of February, but as this is the
first post of the developer diaries series in 2023, I think it’s still good to
say!

## 👨🏻‍💻 Work

Time goes by fast, and January 2023 is already over. Unfortunately, the year
started slow for me. We had two big projects planned for mid of January, and
both got pushed into later this year.

But that wasn’t a problem; it allowed me to **shift my focus** to other things.
This meant I increased my workload in my maintenance jobs and took a lot more
time to write!

I also tried to plan my year a bit. One thing I’ve learned already after almost
a year of freelancing is that you get a lot of **flexibility** in how you can
work, but you also have to be very flexible. Projects can be canceled,
postponed, or need to start immediately. Everything can happen, and that is what
makes it so fun for me.

When I talked to other freelancers, who are a bit longer in the game, they all
agreed that January is a quiet month concerning freelancing.

People are still on holiday, and it takes time until everyone returns at Work.
Companies are still in the planning phase of the year. Budgets still need to be
approved.

So I was grateful for this relaxed month and took the opportunity. I have a lot
of exciting projects planned for this year, and I can’t wait to get into them!

## 📝 Blog Posts of the month

As I already said, fewer client projects meant more time for focused writing. So
here are the [blog posts](/blog) for January. I’m especially proud about New CSS
features in 2023.

- [New CSS features in 2023](/blog/new-css-features-in-2023)
- [TypeScript Type Guards](/blog/typescript-type-guards)
- [Developer Diaries 08](/blog/developer-diaries-08)

## 🎓 TIL Posts of the month

Here are the [Today-I-learned posts](/today-i-learned) for January:

- [Removing YouTube Shorts with CSS](/today-i-learned/removing-youtube-shorts-with-css)
- [State of Usability in 2023](/today-i-learned/state-of-usability-in-2023)
- [CSS Gradient Text](/today-i-learned/css-gradient-text)

## 🏡 Life

Hello, new category! I also want to write about general things in my life, what
happened, how I’m feeling, and what I’ve learned, so let’s see what this
category will contain.

We moved in January! Moving is always stressful; it takes so much time and
energy. But it was totally worth it. We moved out of the city, as we are not
using most of the advantages a city offers, like going to bars and clubs.

We moved closer to family and nature and got a bigger flat. All in all, it’s a
fantastic life upgrade. We already enjoy the quieter surroundings a lot.

## 🏋🏻‍♀️ Fitness

Due to the whole process of moving, this was, at least for the first few weeks,
the only workout I got. But I’m slowly getting into a great workout routine. The
current plan is:

- yoga on Monday and Friday,
- a strength workout on Tuesday and Thursday,
- a Zone 2 workout (Zwift ride) on Wednesday.

So let’s see how this turns out!

Here are my Apple Watch rings from January:

<Image
  src="/images/apple-watch-rings-january-2023.webp"
  alt="Apple Watch Rings January 2023"
  width="1080"
  height="1412"
/>

## 📚 Reading

I finally finished one of the biggest books I’ve ever read.

- [Fall of Giants - Ken Follett](https://www.goodreads.com/book/show/7315573-fall-of-giants)

I think it’s fantastic, and I definitely will read the other two books of the
series. I’ll take some time first to read some smaller books 😅

## 🕹Video Games

No playing any video games in January!

## 🎙Podcasts

I’m back in the podcast game! I noticed how much a like
the [Syntax.fm](http://syntax.fm/) Podcast by Wes and Steve and I listened to
three episodes this month. I think this will be a habit again soon.

- [Syntax.fm  Container Queries explained ](https://syntax.fm/show/566/container-queries-explained)
- [Syntax.fm Supper Club × Simen Svale Skogsrud and Espen Hovlandsdal from Sanity ](https://syntax.fm/show/565/supper-club-simen-svale-skogsrud-and-espen-hovlandsdal-from-sanity)
- [Syntax.fm Serverless Databases](https://syntax.fm/show/551/serverless-databases)

That’s it for the Developer Diaries in January! See you next month!


In episode 09 of the Developer Diaries I reflect on a quiet January, lot of motivation to write and a new category: Life.

Developer Diaries 09


CSS made a lot of progress in 2022. Many new features were added, and existing
ones were improved and made more usable. Working with CSS these days is
exciting, and I have found my love for it again.

To keep an overview of what's new and what has changed, I will explain in detail
in this blog post all you should know about the new CSS features in 2023.

**Disclaimer:** the features I talk about in this blog post are not new in CSS
in 2023; they will gain major browser support soon or already have it recently.
This means they are usable without thinking about polyfills, and that's the real
deal.

---

**Table of Contents:**

- [Container Queries](#container-queries)
- [:focus-visible](#focus-visible)
- [:has()](#has)
- [subgrid](#subgrid)
- [accent-color](#accent-color)
- [Individual Transform Properties](#individual-transform-properties)
- [Sources](#sources)

---

## <a name="container-queries"></a> Container Queries

Container Queries allow us to modify an element and its behavior not based on
the viewport size but **on the container it's within.**

To use Container queries, you first have to define the container itself.

```css
main {
  container-type: inline-size;
}
```

Optionally you can also set the `container-type` and define a container name all
at once.

```css
main {
  container: main / inline-size;
}
```

Next up, you have to write your container queries. This is possible by using
several math operators. Using math operators in queries is also a great new
addition!

The following query targets every paragraph inside our container with the name
of main when the width of the container is greater or equal to 600px;

```css
@container main (width >= 600px) {
  p {
    padding: 24px;
  }
}
```

Here's another example on CodePen. If the container on the right is larger than
1200px, we make a grid out of the image and the text and position them next to
each other.

<CodePen
  id="GRBxoZQ"
  title="Container Queries"
/>

Why do we need container queries when most of the layout changes can be done by
listening to the viewport width? The answer is **context**. Container Queries
are such a perfect tool for components from whom we don't know beforehand in
which context they will be used.

So we can define the appearance of our component based on the **container
width**, and it adapts. No matter if this component is used in a header, a
sidebar, or a modal, for example.

Another addition to container queries is **container query units**. Container
queries allow us to quickly implement responsive typography using container
query units.

I've already written about responsive typography using
[clamp()](/today-i-learned/clamp-css-function/).

This is typically done by listening to viewport widths. However, with the
addition of container query units, we can replace this now by listening to the
container's width, height, inline size, block size, or the smaller or larger
value of these.

Here's the spec for all the new
units: [https://drafts.csswg.org/css-contain-3/#container-lengths](https://drafts.csswg.org/css-contain-3/#container-lengths).
It has yet to get full browser support, but container queries can be used in
totally new ways if this lands.

## <a name="focus-visible"></a> Focus-visible

If you've been a web developer for a few years, chances are that your Project
Manager or your Customers asked you to remove the "ugly" outlines around buttons
when focused.

The following CSS achieves it:

```css
button:focus {
  outline: none;
}
```

Hint: **Never do that!**
[ They are there for a reason](https://www.a11yproject.com/posts/never-remove-css-outlines/).

If you ever get asked that again, tell them there is now a better solution
`:focus-visible`. This new `pseudo-class` tells the browser when to show focus
rings based on heuristics.

This means it detects input modalities that require visible focus. So, for
example, mouse users won't see them on click, but keyboard users will have them
on tab.

This is an excellent addition to CSS, as it removes them for mouse users, who
won't need it necessarily but keeps it for keyboard users, who heavily rely on
it for accessibility reasons.

Try it out yourself:

<CodePen
  id="bGjvEbj"
  title="Focus-visible"
/>

## <a name="has"></a> :has()

`:has()` is a new selector that, as the name says, gets applied styles if the
argument passed in matches at least one element. There are endless possibilities
for how to use this new selector. It opens up a lot of new ways to select an
element and apply styles to it **conditionally**.

`:has()` is one of the four **functional pseudo-classes** along with `:is()`,
`:where()`, and `:not()`, all of them can accept a selector list.

It's best explained by showcasing a lot of examples, so here we go:

```css
/* selects the ul if it has a direct following li element */
ul:has(> li) {
  margin-left: 1rem;
}

/* selects the a element if it has a direct following img element */
a:has(> img) {
  border: 1px solid yellow;
}

/* selects the last li element if the ul element has li elements */
ul:has(li) li:last-child {
  margin-bottom: 0;
}
```

`:has()` can also be combined with the other pseudo-classes. And it enables us
to do logical operators like `AND` and `OR`.

```css
/*
  Selects the ul if it has a li element which has a direct a as a child
  AND if it has a li which has a span as a direct child
*/
ul:has(li > a):has(li > span) {
  color: lightblue;
}

/*
  Selects the ul if it has a li element which has a direct a as a child
  OR if it has a li which has a span as a direct child
*/
ul:has(li > a, li > span) {
  color: lightblue;
}

/* Selects the section if it hasn't a direct child of h1, which has an h2 and a p as adjacent siblings */
section:not(:has(> h1 + h2 + p)) {
  font-family: Times-New-Roman;
}
```

Yes, you could say that `:has()` is a **parent selector**. You can match an
ancestor element based on containing a specific descendant. But that's not all!

You can also target ascendant elements if the condition returns true on the
initial selector. I've already shown that in the first example, but here are
some more:

```css
/*
  Selects the p if the main has an h1 as a direct child, which is followed by an h2
  AND if the main has an h2 as a direct child who is followed by an h3
  AND if the main has an h3 as a direct child, which is followed by an h4
*/
main:has(> h1 + h2, > h2 + h3, > h3 + h4) p {
  font-size: 2rem;
}

/* Selects the label inside a p element if the p contains a form control
that is required but not currently valid. */
p:has(:required:invalid) label {
  color: red;
}

/* Selects the label inside any element if the element contains a form control
that is required but not currently valid. */
* :has(> label + :required:invalid) > label {
  color: red;
}
```

The examples above are from
[the fantastic blog post by Estelle Weyl](https://12daysofweb.dev/2022/css-has-selector/)
and perfectly showcase the **usefulness** of the `:has()` selector.

This means `:has()` is not solemnly a parent selector. It's a **relational
selector**! As I said at the beginning, this new functional pseudo-class brings
endless possibilities. It's awesome. I'm under the impression that I haven't
even started to grasp the scope of what's possible now.

## <a name="subgrid"></a> Subgrid

Before `subgrid` existed, a grid inside another grid couldn't be aligned along
the tracks of the parent grid. Here's a **CodePen** with a grid inside another
grid:

<CodePen
  id="JjBvpPN"
  title="Nested Grid without subgrid"
/>

Now with subgrid, you can tell the inner grid with
`grid-template-columns: subgrid` that the columns should be aligned with the
ones of the parent.

<CodePen
  id="ZEjoryp"
  title="Nested Grid using subgrid"
/>

Subgrids can be used without limitation downwards, so you can **nest** them
endlessly as long as the parent has the grid property. This opens up many
possibilities for defining grids; it's a beautiful addition!

## <a name="accent-color"></a> Accent-Color

Styling form elements or adding the most minimalistic CSS changes were always a
**pain**. You likely needed external libraries or packages to achieve that.

This changed recently with the introduction of
[accent-color](https://developer.mozilla.org/en-US/docs/Web/CSS/accent-color).

It allows you to set the `accent-color` of user-interface controls.

It's currently usable on `input type= "checkbox"`, `input type= "radio"`,
`input type="range"`, and `<progress>`.

Here's a **CodePen** to showcase its usage of it:

<CodePen
  id="oNMEoqx"
  title="Accent-Color"
/>

## <a name="individual-transform-properties"></a> Individual Transform Properties

The `transform` property was one of my favorite additions to CSS back when it
was introduced. I love to use it to create little animations and transitions.

It lets you define one or more transform functions at once. Here's an example:

```css
.caption:hover {
  transform: rotate(10deg), scale(1.2), translateX(-20px);
}
```

What happens here is that on `hover`, our DOM element with the class of
`.caption` will rotate by 10 degrees clockwise, will scale up to 1.2 of its
size, and will move 20px horizontally to the left.

<CoffeeHint />

There's one **problem** with it. If you want to change just one of the transform
properties later on, like in a media or container query, you must write the
**whole definition** again for all properties.

```css
@media (min-width: 1200px) {
  .caption:hover {
    transform: rotate(10deg), scale(1.8), translateX(-20px);
  }
}
```

We've just applied one change on the scale property but had to write it for all
of them again. If we wouldn't, they would reset to the default.

But this is a thing of the past now! Introducing: **individual transform
properties**.

`scale()`, `translate()`, and `rotate()` can now be used individually without
having to define them inside a transform declaration. Very cool!

Here's our example from above with individual transform properties:

```css
.caption:hover {
    translate: -20px;
    scale:1.2;
    rotate: 10deg;
}

@media (min-width: 1200px) {
  .caption:hover {
     scale:1.8;
  }
}
```

That's it for the new CSS features you can use in 2023! A lot of cool stuff
landed in CSS and it's awesome to see it being improved continuously.

## <a name="sources"></a> Sources

- [State of CSS in 2022 - Adam Argyle](https://web.dev/state-of-css-2022/)
- [2022 CSS Updates - Stephanie Eckles](https://12daysofweb.dev/2022/2022-css-updates/)
- [Finer graind control over CSS transforms with individual transform properties - Bramus, L. David Baron](https://web.dev/css-individual-transform-properties/)
- [Container Queries - Stephanie Eckles](https://12daysofweb.dev/2021/container-queries/)
- [CSS Subgrid - Rachel Andrew](https://12daysofweb.dev/2022/css-subgrid/)
- [Standardizing Focus Styles with CSS Custom Properties - Stephanie Eckles](https://css-tricks.com/standardizing-focus-styles-with-css-custom-properties/)
- [accent-color - mdn web docs](https://developer.mozilla.org/en-US/docs/Web/CSS/accent-color)
- [Level Up Your CSS Skills With The :has() Selector - Stephanie Eckles](https://www.smashingmagazine.com/2023/01/level-up-css-skills-has-selector/)
- [CSS :has() - Estelle Weyl](https://12daysofweb.dev/2022/css-has-selector/)


A lot of new CSS features gained major browser support recently or will gain it soon. In this blog post, I will explain all the new CSS features you can start to use in 2023.

New CSS features in 2023


In a recent project, I used TypeScript Type Guards so much that I wanted to
write a blog post about them with great examples and why I like them. They've
helped me prevent errors and make my code safer and more reliable.

---

**Table of Contents**

- [What are TypeScript Type Guards](#what-are-typescript-type-guards)
- [How to write a great Type Guard](#how-to-write-a-great-type-guard)
- [Built-in Type Guards](#built-in-type-guards)
- [Further reading](#further-reading)

---

## What are TypeScript Type Guards <a name="what-are-typescript-type-guards"></a>

TypeScript Type Guards are used when you only want to allow a specific type in a
function, for example. The need for something like this derives from the fact
that only this particular type has the values you can work with further.

If you'd use a function that's manipulating data in some sort on a type that
would be **missing** these values, you will run into **errors**.

So TypeScript Type Guards are one of the first and best ways to ensure you only
process further in your programming logic with relevant data.

## How to write a great Type Guard <a name="how-to-write-a-great-type-guard"></a>

Let's learn more about Type Guards by looking at an example. To create one, you
have to write a function whose return type is a **type predicate**. The
predicate has the form: `parameterName is Type`.

Imagine you are getting some data from an API of your headless CMS. In your CMS,
users can set the fields of a link element there. The link element would
translate into a TypeScript Interface which would look like this:

```typescript
interface FilledLink {
  url: string
  isExternal: boolean
  isTargetBlank: boolean
}
```

But they can also leave it empty and not add it in. This would look something
like that:

```typescript
interface EmptyLink {
  url: undefined
}
```

When we consume this data via API, we want to ensure we only work with it if
it's a filled link and not `null`. So we only want to go further when it has the
type of `FilledLink`.

Otherwise, if we didn't care and would render a link field in React, we would
run into errors. We would access the URL field, which can be `undefined`, and
our user interface would break.

So here's what a Type Guard for this scenario would look like:

```tsx
const isFilledLink = (link: EmptyLink | FilledLink): link is FilledLink => {
  return link?.url !== undefined
}
```

Let's have a closer look on what happens here. We define a function who takes in
a parameter of type `EmptyLink | FilledLink`. The return type is a type
predicate, which is a function that returns a boolean. The boolean is used to
determine if the type is `FilledLink` or not.

This ensures, that we can work on with the url field, because we know it's not
`undefined` anymore.

This is called a **custom Type Guard** or a **user-defined Type Guard**. It's
the most powerful because you can customize it all the way you want.

## Built-in Type Guards <a name="built-in-type-guards"></a>

There are also built-in Type Guards in TypeScript. The following exist:

- [typeof](https://www.typescriptlang.org/docs/handbook/2/narrowing.html#typeof-type-guards)
- [instanceof narrowing](https://www.typescriptlang.org/docs/handbook/2/narrowing.html#instanceof-narrowing)

- [in](https://www.typescriptlang.org/docs/handbook/2/narrowing.html#the-in-operator-narrowing)

- [equality narrowing](https://www.typescriptlang.org/docs/handbook/2/narrowing.html#equality-narrowing)

I've linked them all to the official TypeScript documentation, so you can read
more about them there. I will write a detailled blog post about these soon, so
stay tuned!

That's it about TypeScript Type Guards, in this case specifically about
user-defined or custom Type Guards!

## Further reading <a name="further-reading"></a>

- [https://www.robinwieruch.de/typescript-type-guard/](https://www.robinwieruch.de/typescript-type-guard/)
- [https://www.typescriptlang.org/docs/handbook/2/narrowing.html](https://www.typescriptlang.org/docs/handbook/2/narrowing.html)


TypeScript Type Guards are used when you only want to allow a specific type in a function. Learn how to write a great Type Guard with examples.

TypeScript Type Guards


Initially, I wanted to skip this version of the developer diary for
December 2022. Unfortunately, it was a chaotic month with much
context-switching, illness, and just pushing through until the year ended.

But then I thought it’s still interesting to reflect on a month like this, so
here we are for Developer Diaries 08, the December 2022 edition!

## 👨🏻‍💻 Work

Work-wise, the month started well structured. I knew I wanted to do a little
less this month, so I didn’t start any new projects. Instead, I worked 2-3 days
a week for an agency from Stuttgart, where I helped with bug fixes and improving
several features.

Besides that, we planned on finishing the
[Aerosol Alliance Website](https://aerosolalliance.com/), which I already talked
about in the last episode of the Developer Diary. We made a lot of progress on
this case over the previous weeks. We implemented many changes that made the
site look more coherent.

As I already mentioned a few times, it’s a cooperation with my friends from
[Studio Vierkant](https://studiovierkant.de/) . It’s so much fun to work with
them on this together. We meet up in their office for a few hours or a day, and
we work next to each other and quickly ship many improvements.

I’m hoping for new opportunities in 2023 to start new projects together!

Work-wise in December, the biggest thing that happened was the finish and
release of the new website for the
[Stuttgarter Kickers](https://www.stuttgarter-kickers.de/) , the second-biggest
soccer club from Stuttgart.

Initially, my Friend Tobi from Werk8 asked me to help with a few things. In the
end, I did most of the Backend and CMS development, and he did most of the
Front-end development.

I love how the new website turned out. It’s super fast and a significant
improvement. Was a lot of fun to work on that project.

## 📝 Blog Posts of the month

I made some progress on some blog posts, which lay deep down in my backlog for a
while, but I didn’t finish one. On the one hand, this means not a lot of
released posts in December 2022; on the other, it means I can kick-start 2023
with many cool new blog posts.

Here’s the only blog post from December 2022:

- [Web Developer Diary 07](/blog/developer-diaries-07/)

## 🎓 TIL Posts of the month

Here are the Today-I-learned posts for December 2022:

- [Clamp CSS Function](/today-i-learned/clamp-css-function/)

## 🏋🏻‍♀️ Fitness

The month started normally; I did my almost daily Yoga/workout session in the
morning and felt good and healthy. Then I got sick like nearly everyone. I
haven’t been this sick since Covid in June. Thankfully it wasn’t Covid again,
but nevertheless, it was one week of being totally knocked out.

Here are my apple watch rings from December 2022

<Image
  src="/images/apple-watch-rings-december-2022.webp"
  alt="Apple Watch Rings December 2022"
  width="1025"
  height="1300"
/>

## 📚 Reading

I never thought this would happen, but I didn’t finish a single book this month.
It’s mainly because I started one of the biggest ones I’ve ever read. It’s the
first part of the Century Trilogy by Ken Follett,
[Fall of Giants](https://www.goodreads.com/book/show/7315573-fall-of-giants) .

I’ve almost finished it, and I can’t wait to read parts two and three, although
I know they also have more than 900 pages.

## 🕹 Video Games

We started playing the new Pokemon games on the switch, and we’re not too happy
with them. Of course, playing Pokemon is always fun, but I didn’t get too
engaged in it. Despite the terrible and unfinished look and the ton of bugs,
which I can ignore, it doesn’t really feel motivated to me to explore on catch
more Pokemon.

So I made a spontaneous decision and bought a totally new game. It’s Xenoblade
Chronicles 3; I always saw my friend Dom playing it. So far I have enjoyed it a
lot!

That’s it for the Developer Diary 08 in December 2022. See you next month!


Number 8 of my developer diaries series is about a chaotic month with the release of one of the biggest projects, context-switching and illness

Developer Diaries 08


November was a great month, I liked it a lot. It was about remembering my
[values](/about/#values), being able to choose with whom I work and great
teamwork.

## 👨🏻‍💻 Work

This month I once again noticed that it's incredible that I can work with people
who share the same **work** **habits** and **principles** as me. They deny a lot
that doesn't fit into these values we have in common.

I can say no to work that contradicts my work ethic, which is a huge privilege,
and I'm more than **grateful** for that.

In November, I was on the edge of finalizing a great project with my friend
Tobi. It will be released in December, and I'm pleased about the outcome.
Working together with Tobi is the most fun and motivational. We have a great
workflow and are both experts in our field, which is a powerful combination.

We already have fantastic projects planned for the next year, and I can't wait
to get started on them. If you also want to start a project and need two great
guys who're able to help you with that,
[check out the website of our collective](https://www.werk8.design/).

Besides that, I worked on the aerosol alliance website for the first time since
the summer. We did a silent go-live a few months ago and are slowly sending
people to it. It's a great project for a great cause, and I'm thrilled I can
help these guys.

## 📝 Blog Posts of the month

I dedicated less time to writing this month. On the one hand, I missed it, and
on the other hand, it felt good to use this time for other stuff. I'm not sure
how to deal with it next month. We'll see. Here are the blog posts for November
2022:

- [What's new in Next.js 13](/blog/whats-new-in-nextjs-13/)
- [Web Developer Diary #6](/blog/web-developer-diary-06/)

## 🎓 TIL Posts of the month

Here are the Today-I-learned posts for November 2022:

- [Tech pays in Europe](/today-i-learned/tech-pays-in-europe/)
- [Never use px for font-size](/today-i-learned/never-use-px-for-font-size/)

## 🏋🏻‍♀️ Fitness

I can't believe I'm saying this, but: I started running again! I quit it over
ten years ago because my knees always hurt. I'm willing to give it another
chance now. I started slow to protect my knees, but it felt amazing running on
the beach in the Netherlands.

Besides that, I'm doing a mix of yoga and bodyweight fitness almost every
morning, which feels like the perfect combination.

Here are my apple watch rings from November 2022:

<Image
  src="/images/apple-watch-rings-november-2022.webp"
  alt="image of apple watch rings of november 2022"
  width={1125}
  height={1302}
/>

## 📚 Reading

I only finished one book this month; I wasn't so motivated to read. I'm not sure
if the book I read was the reason or that I was often too tired to read.

The book I finished was something special. It includes highly controversial and
horrible topics and is not your usual read. Nevertheless, it has an interesting
story. I'm not sure what to make of it yet.

- [The People in the trees - Yanagihara Hanya](https://www.goodreads.com/book/show/16126596-the-people-in-the-trees)

## 🕹Video Games

In November, the new Pokemon games for the Nintendo Switch were released, which
I anticipated very much. So we bought both editions, Violet and Scarlet, so my
wife and I could play simultaneously.

I'm not sure if I like it so far; it has a lot of bugs and looks not too good.
But in the end, it's Pokemon, which I love.

## 🎙Podcasts

I did listen to podcasts, but nothing tech related. I don't know what to do with
this category; my motivation to listen to developer podcasts is insignificant.

## 🔔 A special note

You may have noticed the name change! I was never too sure about the title "web
developer diary." However, I like the new one more and want to try it out. Let's
see where this lead.

That's it for November 2022. See you next month!


Number 7 of my web developer diary series is about able to choose with whom I work and great teamwork

Developer Diaries 07


At the end of October, Next.js released a new big update - **Next.js 13**. This
blog post will look into all the new features and discuss the changes and
improvements.

---

Table of Contents

- Experimental features (in alpha and beta)
  - app directory
  - turbo pack
  - next/font
- Stable features:
  - next/image
  - improved next/link
  - OG Image Generation
- Conclusion

---

The new big and shiny update is divided into two main
categories: **experimental** **features**, released as alpha and beta and not
recommended for production usage, and **stable** **features**.

## Experimental features (alpha/beta)

Let's start with the features you should wait to adapt for your production app,
but they will be available soon.

### New app directory(beta)

With Next.js 13, the new **app** directory is introduced. This is a
significant **mental mode change** in how we build websites with Next.js in the
future. The main idea behind this new approach is to **separate** the views that
don't need data to render and make them available as quickly as possible to the
user. In addition, a loading state for the views that need to fetch data will be
available for that part of the page.

This is possible thanks to **React Server Components**. The app directory will
enable us to define **layouts** that are able to share state across navigations.
These UIs are sharable between pages, and they prevent expensive re-renders.

Before Next.js, we used the **pages** directory. Inside a page, we fetched data
and passed it down to components who displayed it. With the app directory, each
component itself can get the data it needs individually. This is a massive
change, and it will likely lead to significant performance improvements with
less JavaScript sent to the client.

### Turbopack(alpha)

Next.js 13 includes a brand new **bundler**: Turbopack. The Next.js team states
that it is **700x faster than Webpack**. Rust-powered tooling seems to be the
fastest these days. What an improvement.

With an application of around 3000 modules, Turbopack takes **1.8s** to bundle
everything. This incredible speed comes from the fact that it only bundles the
minimum assets required in development. In addition, it has out-of-the-box
support for Server Components, TypeScript, JSX, CSS, and more.

Remember that it's still in alpha, and many changes will happen. But still, what
a fantastic job.

### next/font/beta)

Next.js 13 contains a **brand new font system**, which makes privacy a
first-class citizen. With this new font system, all the CSS and font files are
downloaded at build-time and self-hosted, along with the other static assets.

This means you can use all the google fonts without having one request to google
in your network tab. This is amazing.

The new font system also significantly improves performance by supporting
caching and preloading for google fonts and custom fonts. Layout shifts will
also be a thing of the past by using the font-display CSS property.

## Stable features

Now let's look at the new features you can use **right away** when upgrading to
Next.js 13 stable.

### next/image

The new next/image component brings a lot of benefits. The one I like the most
is that **alt tags are now required**, forcing users to apply more care for
accessibility.

The new syntax will look like this:

```jsx
import Image from 'next/image'
import profilePicture from '/images/profile-picture.webp'

const ProfilePage = () => {
  return (
    <Image
      alt="profile picture of Marco"
      src={profilePicutre}
      placeholder="blur"
    />
  )
}
```

The new image component will also ship less client-side JavaScript and be faster
because the native lazy-loading doesn't require hydration. Overall, it's a
significant improvement where the Next.js team did a fantastic job in making the
image component more accessible and faster.

The Next.js team provided a **codemon** to make upgrading to the new next/image
component easy.

```bash
npx @next/codemod next-image-to-legacy-image ./pages
```

### improved next/link

The Next.js team also made some improvements on the next/link component. The
component won't require an extra `<a>` tag anymore. Yay! With Next.js 13, every
Link component will automatically render an a tag inside. It's such a small
thing, but it will improve the developer experience; I like it.

### OG Image Generation

The Next.js Team created a new library to automatically generate **social
cards**, also known as open graph images. The motivation was to offer an easy
way to create **dynamic** social cards. By using Vercel edge functions, it's
super fast and easy to use. I'm going to try that out soon.

## Conclusion

The Next.js October release brought a lot of minor but helpful improvements and
significant changes which will alter major things in Next.js. I'm excited about
its future and can't wait to build a new project with the app directory
approach.

## Sources:

- [Smashing Magazine article whats-new-nextjs-13 by Atila Fassina](https://www.smashingmagazine.com/2022/11/whats-new-nextjs-13/)
- [Next.js 13 release blog post](https://nextjs.org/blog/next-13)


At the end of October, Next.js released a new big update - Next.js 13. This blog post will look into all the new features and discuss the changes and improvements.

What's new in Next.js 13?


![an open notebook](/images/web-developer-diary-6.webp)

October was a mix of everything. From jumping out of summer straight into cold
and dark weather in Germany, seeking new opportunities, car problems, and
investing more time into learning again.

## Work

In the first two weeks of October, we were still on workation in the south of
France. This was a fantastic experience. I wrote a whole blog post about it, and
I can’t wait to do it again.

At the end of October, one of my favorite work projects **ended**. It wasn’t a
big surprise that it ended. It wasn’t a bad ending. Initially, I needed to help
with the project because one of the leading developers wasn’t available for
three weeks. So we planned that I should help out during August.

That turned into me working on this project for three months. It was a lot of
fun working with awesome people. I learned a lot, and it was not the last time
working together. They left me with such [fantastic feedback](/#testimonials).
It puts such a big smile on my face whenever I read it.

**New Opportunities** came up, and with my friend Tobi from

<a
  href="https://www.werk8.design/"
  target="_blank"
  rel="nooper noreferrer"
>
  Werk8 &#8599;
</a>
, we already planned projects for next year, possibly one of our biggest ones. Exciting
times!

One of my key learnings as a freelancer is that it’s always a constant struggle
between having less work and not too much work. I have no clear vision of how to
handle this long-term, but I think that’s a thing you’ll learn with more
experience.

## Blog posts of the month

October was my best month for blogging. I published a blog post every week,
which felt amazing, and I’m proud of it. **Scheduling** the first 25 minutes of
my day for writing was a **game-changer**. This feels like the perfect time for
me to write.

Here are the blog posts for October:

- [Workation](/blog/workation/)
- [Fixing my SEO mistakes](/blog/fixing-my-seo-mistakes/)
- [Learnings from my last job](/blog/learnings-from-my-last-job/)
- [Web Developer Diary 05](/blog/web-developer-diary-05/)

## TIL posts of the month

I’m trying to establish Wednesday as my today-I-learned day. Here are the
today-I-learned posts of October:

- [Secure JavaScript URL validation](/today-i-learned/secure-javascript-url-validation/)
- [Worlds highest website](/today-i-learned/worlds-highest-website/)
- [Squoosh App](/today-i-learned/squoosh-app/)

## Everything else than web dev

### 🏋🏻‍♀️ Fitness

I felt terrific during October, health, and Fitness wise. During our workation,
we started every day by doing yoga or a short workout on our balcony. It was
almost too good to be true because the sun would rise during our training, and
we were greeted every day by this view.

![image of the sunrise over the town Ollioules](/images/sunrise-ollioules.webp)

As you can see below in my apple rings, I could close them almost daily. And the
funny thing is, you can exactly spot when we traveled back from France.

![image of apple watch rings of october 2022](/images/apple-watch-rings-october-2022.webp)

### 📚 reading

Holidays and time spent not at home meant a lot of time for reading. I managed
to finish three books.

- [The Cartel (The Power of the Dog #2) ](https://www.goodreads.com/book/show/23602561-the-cartel)

- [Freizeit](https://www.goodreads.com/book/show/61100819-freizeit)

- [Man vergisst nicht wie man schwimmt](https://www.goodreads.com/book/show/59828197-man-vergisst-nicht-wie-man-schwimmt)

### 🕹Video Games

Nothing on here at all. But: I’m looking forward to the release of the new
pokemon games in November, still trying to figure out if I should choose scarlet
or violet.

### 🎙Podcasts

I didn’t listen to any podcasts.

That’s it for October 2022. See you next month!


Number 6 of my web developer diary series is about working coming back to germany, feeling healthy and new opportunities.

Web Developer Diary 06


![a picture of a terrace with a table having a macbook on it and a great view of the landscape](/images/workation-1.webp)

Covid changed the world and showed companies that **remote work** is possible
and a valuable alternative to working from an office full-time. In addition,
many employees appreciated the fact of **not having to commute** and being able
to spend more time with their **families**.

We, as software developers, are one of the very privileged groups who can work
from anywhere in the world. We need a laptop and a decent internet connection.
We are not bound to a physical place.

This possibility of being able to work from anywhere, combined with the fact of
being a freelance web developer, freed me completely. Most of my clients work
remotely as well. I've never had to go into a client's office.

I've always wanted to try the concept of **workation**. But working at my desk,
taking a break, stepping outside in the sun, and looking at the beach seemed
like a ridiculous dream. But, with Covid enabling more remote work and me being
a freelancer, deciding for myself where to work, workation seemed possible!

---

**Table of Contents**

- [What is a workation](#what-is-a-workation)
- [How to prepare for your workation](#how-to-prepare-for-your-workation)
  - [Having a decent place to work](#having-a-decent-place-to-work)
  - [Internet connection](#internet-connection)
  - [Safety first](#safety-first)
- [How it went and why you should go too](#how-it-went-and-why-you-should-go-too)

---

## What is a workation <a name="what-is-a-workation"></a>

If you've never heard of workation, it combines **work and vacation.** You go
wherever you want to go in the world for a holiday. You enjoy it, and you relax.
And then you stay a little longer and also work from there.

In September 2022, my wife and I took this opportunity and wanted to try it out.
My wife works as a UX designer, and her company enabled her to work from
anywhere in Europe for up to a few months a year, which is fantastic.

Our chosen place for our workation was the **south of France**, and we aimed for
an eternity of **4 weeks** to test it out. If it worked and we liked it, we
wanted to do it as often as possible during the year.

## How to prepare for your workation <a name="how-to-prepare-for-your-workation"></a>

If you plan to do a workation as well, here are a few things I recommend to
check and plan. When we started looking for a place we wanted to go to, checking
these things helped us to decide and feel comfortable that this workation would
work well for us.

### Having a decent place to work <a name="having-a-decent-place-to-work"></a>

For us, this was the most crucial thing to get right. A small hotel room might
be perfect if you're going on holiday. Most of the time, you use it to sleep
there and spend the rest of the time outside, at the pool, or on trips.

But if you also plan to spend more time there and mainly work from there, your
accommodation needs completely different characteristics. We were looking for at
least a separate dining table with few chairs where you can work.

Because let's be honest here. Lying on a beach, working at the bar, or sitting
in the sun seems great in theory. Maybe it's incredible for a few days. But for
any time longer, you want to have a decent place to work. At least for us,
that's the way we felt about this.

Airbnb has this new option where hosts can mark their space as a good workplace.

![image of Airbnb option](/images/airbnb-dedicated-workspace.png)

It could be clearer what the exact criteria are to mark your place as such.
Airbnb tries to clear this up in

<a
  href="https://www.airbnb.com/resources/hosting-homes/a/how-to-make-your-space-comfortable-for-remote-workers-236"
  target="_blank"
>
  this article &#8599;
</a>
.

The accommodation we chose was marked as a place like this. The pictures showed
a separate table and a chair which you were able to work on. This made our
choice easier because we could imagine how it would be to work from there.

Next to the location itself should offer, there are also some things you can
arrange to have the best place to work outside your typical office. For us, this
meant bringing some **extra gear**. I got a **laptop stand** and a **Bluetooth
mouse** and **keyboard** to prevent staring down at my laptop for four weeks and
hurting my neck.

![image of work setup](/images/workation-2.webp)

This was a great idea so we could have at least some kind of **ergonomic
environment**.

### Internet connection <a name="internet-connection"></a>

Checking that the place you want to spend your workation has a good internet
connection is mandatory. So that's one of the first things we did when we looked
for accommodation on Airbnb.

The internet connection should be good enough to enable two people
simultaneously to have video calls with the camera turned on.

If you're looking at Airbnb, many hosts share screenshots of **their internet
connection speed tests**. This is super helpful. It's easy to write down any
connection speed in your Airbnb ad, but having some proof is very reassuring.

It's advisable to bring an **ethernet cable** as well. Often times the wifi is
okay, but if it varies too often, using the plugged-in connection is much more
reliable and faster.

An excellent **mobile plan** with some extra data as a backup can be a lifesaver
on that.

We were lucky on this. When we found an apartment that met our requirements, the
host had already added a screenshot of the up-and-download, which had high
numbers. Other people mentioned in the **reviews** that they also had worked
from there, which was perfect.

### Safety first <a name="safety-first"></a>

Another thing we wanted to make sure was covered on our workation was safety.
Safety for us meant we should feel comfortable working there because we wouldn't
need to worry about working with **sensitive data** or our tech and devices.

If you're working outside your home or your company office, where these safety
standards are applied, you'll also want to add an extra safety layer.

For us, this meant several things. First, using free wifi, which is still pretty
standard in hotels, is not a good idea. If you can, always
use **password-protected wifi connections.** Using a VPN is also always a great
idea. Finally, encrypting your hard drive is a must-have.

<CoffeeHint />

Suppose you decide to work outside of your accommodation, like in a cafe, bar,
or restaurant where other people can directly see your screen and what you are
working on, it's advisable to apply a **screen protector** on your laptop
screen. This enables only you can see what's going on on your screen.

So these are the things we applied to ensure we could work in a safe
environment. There is a lot more you can do, so if you have any ideas on this
topic, let me know!

## How it went and why you should go too <a name="how-it-went-and-why-you-should-go-too"></a>

This headline spoils it already a bit. After spending four weeks in the south of
France and working from there for 2,5 weeks, I can say **it went great**!
Everything we worried about did not happen. Overall it was a fantastic
experience, and I recommend it.

Of course, it takes some time to get used to a new work environment. Especially
not having a big external monitor. But after a day or two, this wasn't a
problem.

The wifi at our place was good enough so that my wife and I could have calls
with our cameras turned on without sounding like robots.

But there is clearly one best thing to it. It's a fantastic feeling to have a
typical workday and close your laptop and **go to the beach** afterward. Or
another beautiful place. Go for a hike. Or even already during the workday.
Sometimes I got so focused on a work problem that when I took a break and
stepped outside onto the terrace, I was so surprised and amazed to live in this
beautiful place with this fantastic few.

Additionally, it's incredible to have more time to explore another country,
city, or place. Usually, if you're staying somewhere for a few days on holiday,
you need more time to see everything. So you have to choose. But this is hard
because you have this urge to want to try everything. After all, time is tight.

If you also plan to work from there, you can relax. You'll have plenty of time.
You can enjoy everything at a slower pace because you'll stay there longer.

After our first workation, after four weeks of being on holiday and working from
there, it was a great success. We loved it. And we are already planning for more
workations.

Have you already done a workation? Or do you plan to do one? Let me know about
it, I'm super curious! Just write me an

<a href="mailto:marco@marcoheine.com">email</a> or send me a message on
<a
  href="https://twitter.com/marcoheine_com"
  target="_blank"
>
  Twitter &#8599;
</a>
.


I've always wanted to try the concept of workation. But working at my desk, taking a break, stepping outside in the sun, and looking at the beach seemed like a ridiculous dream. But, with Covid enabling more remote work and me being a freelancer, deciding for myself where to work, workation seemed possible!

Workation


[Photo by Benjamin Dada on Unsplash](https://unsplash.com/@dadaben_?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)

![A person sitting on a desk searching on google on their MacBook](/images/benjamin-dada-EDZTb2SQ6j0-unsplash.webp)

The optimization of websites for search engines has always been a mystery to me.
There seemed to be so many factors that get used to calculate how a page gets
ranked on a search engine like google. I even learned how page ranks get
calculated during my master's degree.

Still, it was always a bit hard for me to understand what to optimize for,
concerning keywords and content.

One thing though where SEO is very clear to me is from a technical point of
view. I know that Google ranks websites better that are fast, accessible, and in
great shape technology-wise.

Thanks to different tools and my knowledge as a web developer I know what a
website needs to have to succeed in this area. Still, I neglected that for too
long on my website.

Problems and mistakes I would never have on client websites popped up on my site
and I needed to fix them. Here are all the SEO mistakes I had on my website and
how I fixed them, so you can avoid these pitfalls.

---

**Table of Contents**

- [Multiple h1](#multiple-h1)
- [Trailing slashes](#trailing-slashes)
- [Canonical links](#canonical-links)
- [Canonical points to redirect](#canonical-points-to-redirect)
- [404 - broken links](#broken-links)
- [Missing meta tags (and other stuff in the head)](#missing-meta-tags)
- [Conclusion](#conclusion)
- [Resources](#resources)

---

## Multiple h1 <a name="multiple-h1"></a>

I’ll start with the easiest one. I had several h1 on my pages! I don’t know how
that happened, I guess I didn’t control it at all. Having a hierarchy ofƒ
headings is crucial and I’m a little embarrassed that this happened on my site.

### How I fixed it:

I used different tools to check the order of my headings on all pages and fixed
them. I learned that having correct headings is not that more of a factor in
getting ranked in search engines. Still, it is mandatory to make your
website **accessible**. People who use a **screen reader** are **dependent** on
a correct heading order to grasp the content of your website. Wave is a great
tool to improve on that.

## Trailing slashes <a name="trailing-slashes"></a>

My site is built with Gatsby and deployed and hosted with Netlify. Netlify has
this option to **pretty print** URLs, which adds trailing slashes to every link.

But I did not add them everywhere in my code in Gatsby. This resulted in a lot
of **301 redirects** where links without trailing slashes were redirected to
them with it. That’s unnecessary and bad for SEO.

### How I fixed it:

There were **two ways** to fix this problem. The first one would have been
to **disable** the option in Netlify. This would have removed all the extra
added trailing slashes. But it would have also left me with a great mixture of
URLs with trailing slashes and without.

Since the majority of my URLs have them and Google also indexed them with
trailing slashes, I chose the second option to fix this problem. This meant
adding trailing slashes to every link I set in my code. It was a bit tedious but
necessary and now I try to be consistent with it.

## Canonical links <a name="canonical-links"></a>

I did not set up canonical links at all on my site which is a big mistake. I
often try to spread my blog posts on different platforms besides my website,
like [dev.to](https://dev.to/mkuehb/react-performance-quick-wins-7-easy-ways-to-improve-your-react-performance-part-2-4j3c)
and medium, to reach more people.

Not having set up correct canonical tags is a problem. If search engines look at
pages with the same content, they can't find out which of the resources is the
original one. This means my website could get a **penalty** for
distributing **duplicate content**, although it’s my content!

### How I fixed it:

I set up canonical links on my website and double-checked them on every page. I
used the plugin
[gatsby-plugin-react-helmet-canonical-urls](https://www.gatsbyjs.com/plugins/gatsby-plugin-react-helmet-canonical-urls/)
to do that. It’s a great plugin that makes it easy to set up canonical links.

## Canonical points to redirect <a name="canonical-points-to-redirect"></a>

I had a lot of canonical links that pointed to 301 redirects. This is a
combination of the two problems I explained before. I had URLs that
were **upperCase** in my code, like this
one /today-i-learned/performance-and-useMemo/

Once again the Netlify URL pretty print kicks in and tells the browser hey the
actual URL is /today-i-learned/performance-and-usememo, so it’s not the same and
we need a redirect! Oh no.

The problem here is, that the canonical URL stays the same (with upperCase) and
that’s bad for SEO because we get another unnecessary redirect.

### How I fixed it:

I made sure that all my URLs are lowercase. It’s a bit hard to get Netlify to
acknowledge these changes so I had to delete the upperCase file, remove it from
git and re-add it later with the lowercase URL.

## 404 - broken links <a name="broken-links"></a>

I’ve you’re blogging for some years, you may link to websites that don’t exist
anymore, changed the URL, part of the URL, etc. I’ve had a lot of these issues.

### How I fixed it:

It used a tool to analyze all blog post links and then updated or removed them.
I thought about writing a **CronJob** which clicks on all the links on a newly
published blog post. But in the end, it was not worth the effort.

## Missing meta tags (and other stuff in the head) <a name="missing-meta-tags"></a>

The most important meta tags for me always were the **media-query** one,
the **utf-8**, and the **description**.

Of course, I knew that there were way more but I didn’t know which made a huge
difference for SEO. For example, I didn’t set the open graph tags and Twitter
card tags at all on my site.

### How I fixed it:

Once again I used a tool to analyze the head of my site and set all meta tags in
my SEO component in Gatsby.

## Conclusion <a name="conclusion"></a>

There are a lot of easy mistakes one can make, without even knowing about them.
Take your time to inspect your website in the **dev tools**, check out the head
tag, check if all meta tags are there, and set them to the correct values.

Use different tools to check your website. There are a lot of them out there.
I’ll write a separate blog post soon on what kind of tools I recommend and use.

Fixing **a11y mistakes** also means SEO. First, we should optimize our websites
to the best for our users. Doing the best we can to make
them **accessible** and **fast**. Google recognizes if we succeeded in doing so
and rewards us with a better page rank.

## Resources <a name="resources"></a>

- [Joshua Hardwick - Duplicate content](https://ahrefs.com/blog/duplicate-content)
- [Maxim Heckel - SEO mistakes I have made and how I fixed them](https://blog.maximeheckel.com/posts/seo-mistakes-i-have-made-and-how-i-fixed-them/)
- [Joshua Hardwick - 301 redirects](https://ahrefs.com/blog/301-redirects/)


I had a lot of simple SEO mistakes on my own website that I didn't even know about. In this blog post I share how I fixed them.

Fixing my SEO mistakes


<a
  href="https://unsplash.com/@glenncarstenspeters"
  target="_blank"
  rel="noopener noreferrer"
>
  Picture by Glenn Carstens-Peters
</a>

![a person typing on a computer of tools](/images/glenn-carstens-peters-npxXWgQ33ZQ-unsplash.webp)

At the start of this year, my life changed completely. At the end of January,
**I quit my job** as a software developer at a wonderful software service
company. Starting February the first I became a **freelance web developer**.

It has been almost half a year now since that big change happened. But this blog
post won’t be about my new carrier choice. I’m already planning a separate blog
post on my life and learnings as a freelance web developer, so stay tuned!

**Table of contents:**

---

- [The Beginning: a great team is everything](#the-beginning)
- [The Middle: skyrocketing my developer knowledge](#the-middle)
- [The End: reasons to leave and lessons learned](#the-end)
- [At the horizon](#at-the-horizon)

---

This blog post will be about everything I learned in this last job as a
permanently employed software developer. I think it’s a great moment to **step
back and reflect** on the last two years. Think about everything I learned,
liked and I miss.

### <a name='the-beginning'></a> The Beginning: a great team is everything

I started working at this company in June 2020 as a front-end developer. I
specifically applied for the Frontend Developer React position. I was
immediately excited that I could keep my **React focus**, which I established in
my previous jobs.

Fun fact: I wrote a blog post for the sole purpose to get this job. It’s the one
about [two things I like about react](/blog/two-good-reasons-to-use-react/).
Someone later told me, that having a blog and writing about React was a great
plus when I applied and started at the company.

So keep on blogging people! It can get you jobs, which is pretty cool!

When I started there, I joined a team of 4 other developers. Right from the
start we had a great team spirit, working together was a lot of fun and I
learned so much. I couldn’t wish for better colleagues.

Together with several UX designers and product owners, we developed a B2B
web-based application. I started with smaller front-end tasks, working with
React. Pretty soon I also started working with the backend part of our
application. This meant working with NodeJS and MongoDB.

My view on software development **expanded** as I got the possibility to work on
all ends of an application for the first time. Again I learned so much and I
also think I could expand my skills quickly.

I think I’ve never used `Object.keys` and `Object.entries` so much before as at
that time. Besides developing all these new coding skills, I also learned more
about the **SCRUM process**.

This applies especially to sprint reviews. I think we nailed them all the time
because we put special effort into preparing them. We aimed to show our work to
the clients in the best way possible.

### <a name='the-middle'></a> The Middle: skyrocketing my developer knowledge

After a few months of working in this team on that particular project, a big
change presented itself. I got asked to change projects to support a new and
small one where I would build the front-end of an MVP.

This was a wonderful opportunity because it meant my work there was valued and
they trusted in me and my skills. On the other hand, I got to leave this awesome
team and didn’t have the opportunity to work with them that close anymore.

I did some thinking and then agreed to the change. In the beginning, the deal
was that I would be working there for a few weeks, at most one or two months on
this MVP. Spoiler: I stayed there for more than a year.

After the MVP was done, the project became pretty successful and important. The
team grew and I once more got the chance to work as a **full-stack developer**.
This time it meant learning Golang and working with PostgreSQL.

It’s really funny to see how I started working exclusively at the front-end and
in the end, I worked on everything. **From styling changes with CSS to writing
raw SQL database queries**. It was a lot of fun and I learned so much.

Once more, besides learning new coding skills, there were a lot of different
fields to learn and grow in.

Like learning how to understand clients' and users' needs. And most important:
to **challenge the wishes of our clients**. This is one of the most crucial
things I learned there.

### <a name='the-end'></a> The End: reasons to leave and lessons learned

After working for more than one and a half years for this company, I developed a
desire to work on **different kinds of projects**. I also wanted to gain more
**freedom over my time** again.

As our project team grew bigger, we had more topics to discuss and of course
more meetings. This also meant less time for productive coding and less time to
think deeply about problems. I don’t think this is a bad thing, it’s natural if
a team grows.

But that’s just not what I wanted anymore, so I decided it was time for a
change. A big one in this case for me. I figured that just changing companies
wouldn’t do it for me. I wanted to try out something completely different.

Someone who guided me through this phase always told me, if something is off,
**change it, leave it or accept it**. I think that this is such a great and
simple advice, something I will never forget and often refer to.

I’ve always thought about freelancing one day. But I figured I needed to gain
more experience first. Like working on different projects and learning from
different people. But at this point, it felt like I could do it. And so I went
for it.

<CoffeeHint />

### <a name='at-the-horizon'></a> At the horizon

Almost two years of working as a software developer at this company have taught
me a lot. And it was a wonderful experience. I had the opportunity to work on
important projects. I could participate in delivering great solutions to make
our clients happy and help them to achieve their goals.

I had the best teammates you can imagine and the culture of teaching and
learning was well-established. It was natural to speak up when you didn’t know
something.

Compared to my working situation now I sometimes miss working in a team with so
talented and smart people.

I also loved to pair-program and develop great solutions to complex problems
together. Which does not happen that often anymore when you freelance.

What I don’t miss is the number of meetings or doing stand-ups every morning.
One of the best things this change has brought me is that I can plan my day and
my week according to what I want to work on.

So after all, my last job as an employed software developer had a lot of ups and
also some downs. It was a memorable adventure and I wouldn’t want to miss it.

But in the end, I’m happy with the decision I made. I’m looking forward to
everything I’m gonna learn on this new path as a freelance developer!


In this blog post I share all my learnings from my last job as a permanent employed software developer.

Learnings from my last job


![an open notebook](/images/web-developer-diary-5.webp)

Welcome to Web Developer Diary #05! Another month is over which means I’m gonna
reflect on everything that happened in September 2022! Sometimes I’m brave
enough to try out new things. And I’m feeling so kind of right now. So here’s
the new thing. Try out to describe this month with just one word. And that word
would be: **Fun**!

September was packed. We went to two weddings and danced until our feet hurt. We
went to see Ed Sheeran in the Olympic stadium in Munich. And we drove 1000km to
the south of France with our 20 years old Volvo called Carla.

## Work

This month we were using our huge privilege to be able to work from anywhere in
the world. At least where the internet connection is good enough to enable two
people have video calls at the same time. Without sounding like robots. An where
the timezone kind of matches with the people we are working with.

This month I worked out of a hotel room in a small town where our friends got
married. I worked in a beautiful co-working space in the WunderLocke hotel in
Munich. And I worked in our Airbnb in the south of France on the kitchen table
or the terrace while looking at the Mediterranean sea.

We went here for 4 weeks in total, doing 2 weeks of vacation and 2 weeks of
working from here. We always wanted to try out this thing called **Workation**.
I’m not gonna spoil too much right now because I’m planning to write a fully
detailed blog post on this topic soon.

But what I can say so far: It’s awesome. I imagined it way more stressful when
working not from you’re usual workplace, without a big screen and the fastest
internet connection possible. But with a little preparation and the correct
tools, it works!

## Blog posts of the month

I wasn’t in the mood of writing a lot in September, so it’s just these two blog
posts:

- [Web developer diary 04](/blog/web-developer-diary-04/)
- [TypeScript Tooling in Prismic](/blog/typescript-tooling-in-prismic/)

Nevertheless, I’m very happy especially about the TypeScript Tooling post,
because writing about it made me realize again how much it improves my developer
life.

It’s this time of the year again when I’m thinking about writing a blog post a
week although already knowing that I can’t manage it. We’ll see how this turns
out.

## TIL posts of the month

Here are the Today-I-learned posts of the month:

- [The a11y project](/today-i-learned/the-a11y-project/)
- [web-vitals-element](/today-i-learned/web-vitals-element/)

## Everything else than web dev

### 🏋🏻‍♀️Fitness

I got a new tattoo which meant 2 weeks of not working out at all. After that I
also got sick (not covid thankfully) so another week of not working out.
Surprisingly it doesn't show too much in my apple watch rings. I wonder if I
should be happy about this or worried because I moved a lot although not feeling
that good.

![screenshot of my apple watch rings of september 2022](/images/apple-watch-rings-september-2022.webp)

After taking enough time to recover, I did a lot of light walks and hikes. I
also starting to work out again slowly. Currently, I do it every morning after
my morning coffee while watching the sunrise. It's incredible.

I'm trying to convince myself to move every morning in October. We’ll see how
that turns out.

### 📚Reading

Being on holiday means having even more time to read books and I love it! Here
are the books I read in September:

- <a
    href="https://www.goodreads.com/book/show/12497.No_Country_for_Old_Men"
    target="_blank"
  >
    No country for old men - Cormac MacCarthy &#8599;
  </a>
- <a
    href="https://www.goodreads.com/book/show/206236.The_Power_of_the_Dog"
    target="_blank"
  >
    The Power of the dog - Don Winslow &#8599;
  </a>
- <a
    href="https://www.goodreads.com/book/show/23602561-the-cartel"
    target="_blank"
  >
    The Cartel - Don Winslow &#8599;
  </a>

### 🕹Video Games

I did not play any video games at all, as we are not at home where my Xbox is. I
took my switch with me but did not want to play with it so far.

I’ve never told this but I started playing Pokemon Go when it came out in 2016
and never stopped since then. So that’s what keeps me busy on this topic!

### 🎙Podcasts

I didn’t listen to any tech-related podcasts at all this month. I wasn’t really
in the mood for it. I blame the holidays and me not opening my MacBook once for
two weeks.

That’s it for the recap of September 2022. See you next month!


Number 5 of my web developer diary series is about working from anywhere in the world (still mostly europe) in september 2022, holidays and reading a lot.

Web Developer Diary 05


[Photo by iMattSmart on Unsplash](https://unsplash.com/@imattsmart?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)

![a table with some tools on it](/images/imattsmart-sm0Bkoj5bnA-unsplash.webp)

I researched a lot about Content Management Systems, before starting my
freelance web developer career. I tried a few, disliked some and got stuck with
Prismic. The mental model of shaping websites with custom types and slices just
clicked for me.

So far, Prismic offers everything I need from a headless CMS. A great user
experience for authors, a lot of flexibility for developers and a great
community where asking for help is easy.

---

**Table of Contents**

- [My problems with Prismic](#my-problems-with-prismic)
- [TypeScript is a no-brainer](#typescript-is-a-no-brainer)
- [Improved TypeScript tooling](#improved-typescript-tooling)
- [Conclusion](#conclusion)
- [Resources](#resources)

---

## <a name='my-problems-with-prismic'></a>My problems with Prismic

There is one thing I’ve missed though and that made my work harder. It was to
**manually create TypeScript Types and Interfaces** for my Prismic Custom Types
and Slices.

My usual workflow with Prismic goes like this. Figure out which pages and what
kind of repeatable elements we need and turn that into Custom Types and Slices.

After that I head into my Next.js app and query for the data. The next hours are
spent setting up Types and Interfaces for the Custom Types and Slices.

## <a name='typescript-is-a-no-brainer'></a>TypeScript is a no-brainer

Working with TypeScript is one of the things I learned on my last job as an
employed software developer. It is something I would **never like to miss
anymore**.

This blog post won’t be about why you definitely need to use TypeScript. But I
like to highlight a few points that make working with TypeScript in Prismic a
lot of fun to me and **improve my workflow**.

It makes me faster because my code-editor tells me what kind of fields I have on
a specific element and which fields I don’t have. It’s that simple. I think
that’s always been the main selling point to me.

My code knows what’s there and what’s not. What exists and what does not so a
mispelling of a key in a JavaScript object won’t cause the UI to break. This
prevents bug and improves the developer workflow.

So setting up Types and Interfaces for my Prismic Custom Slices and Types was a
lot of work but necessary. I would query for the data, look at the Prismic API
response and write the Types.

At some point I had built my own types folder which I could reuse on projects or
use it as a starting point. It still was a lot of repetitive work.

## <a name='improved-typescript-tooling'></a>Improved TypeScript tooling

But guess what: this is now work of the past! Prismic recently released a lot of
awesome features around TypeScript tooling! There are two big improvements.
**Prismic ts codegen** and **automatic types in Prismic Client**.

### <a name='prismic-ts-codegen'></a>Prismic ts codegen

Prismic ts codegen is a **new cli tool** that generates types for Custom Types
and Slices. So everything I’ve done manually on my last projects will be taken
care of. Awesome!

It’s super easy to use and I encourage everyone to implement it in future (or
even current) Prismic projects. First you have to install the package:

```bash
npm install --save-dev prismic-ts-codegen @prismicio/types
```

Next you have to create a config file in your root folder:

```bash
npx prismic-ts-codegen init
```

Finally you have to tell it where to find your models for whom types should be
created. If you use the Slicemachine and thus have them in your local project
folder it already should be filled in.

Now you are all set up! If you run `npx prismic-ts-codegen` Types for all your
Slices and Custom Types get created in a single file. And if you need to update
them, just run the command again. It’s so helpful and such a great thing to
have. My prismic developer workflow improved a lot since using it!

### <a name='prismic-client-automatic-types'></a>Prismic Client automatic types

The Prismic Client was also updated to use these automatic types created by
prismic-ts-codegen. This makes working with Prismic and TypeScript a love-love
realationship.

You automatically generate your Types and they are used throughout your app
without needing to do anything. That’s awesome.

When I started working with it, I quickly discovered a case were I thought that
I still would have to do some additional work to run everything smoothly. I’m
talking about typing content relationships. Because querying for linked
documents is not automatically typed in Prismic. But Prismic also got us covered
here. In the
[docs](https://prismic.io/docs/technical-reference/prismicio-client#typing-content-relationships)
they share exactly how to solve this case. Great!

## <a name='conclusion'></a>Conclusion

Working with TypeScript in Prismic just got so much better with the release of
this huge improvement for TypeScript tooling. As I already said many times
before, this improves my workflow a lot and I’m so glad about it!

I’m curious what Prismic has planned for future releases and I’m happpy by
choosing it as my main CMS.

## <a name='resources'></a>Resources

- [Prismic release week improved developer tooling](https://prismic.io/blog/release-week-improved-developer-tooling)
- [Prismic ts codegen on GitHub](https://github.com/prismicio/prismic-ts-codegen)
- [Prismic ts codegen docs](https://prismic.io/docs/technical-reference/prismic-ts-codegen)


Prismic launched some new features aroung TypeScript tooling. In this blog post I will take a look at what they are and how to use them.

TypeScript tooling in Prismic


![an open notebook](/images/web-developer-diary-4.webp)

New Month, new web developer diary entry! This time it’s the fourth and I’m
writing about everything that happened in august!

## Work

I remember from the post last month that I described july as rather slow and
quiet. This month was quite the opposite. Lot of new projects, new opportunities
and new things coming together. The groundwork I put it in the previous months
absolutely paid off.

It’s super interesting to see the effects of networking in action.

This reminds me of a pretty common saying: “never burn bridges”. It’s always
great to keep communication open to people you’ve previously engaged with. Who
knows what’s gonna happen in the future.

I also never thought that something like a simple twitter direct message could
lead to a great time working on a cool project.

So august: busy month, working for different clients, on different projects. But
still fun. I learned a lot of new things and this freelance journey is still an
exciting ride.

## Blog posts of the month

No other blog post published than the previous version of this series
unfortunately.

- [Web developer diary #3](/blog/web-developer-diary-03/)

Some great posts are almost done but need this half an hour additional
fine-tuning before I’m happy with them.

Couldn’t find the time for that but this means I’ll publish more posts in
september! Besides that, one of my recent posts,
[just hit publish](/blog/just-hit-publish/) got featured by two amazing people I
follow for a long time already.

Jeremy featured it in his [link collection](https://adactio.com/links?start=20)
and Stefan introduced it in his newsletter
[web weekly #74](https://www.stefanjudis.com/blog/web-weekly-74/) . That made me
really happy. It’s awesome to hear that someone liked your writing.

## TIL posts of the month

As I already said in the beginning of this pos, I learned some cool stuff this
month and documented it as today-I-learned posts. The theme setting without js
is probably my favorite one. And I've already integrated the checklist of the
a11y project into my developing workflow.

- [Faster page loads with early hints](/today-i-learned/faster-page-loads-with-early-hints/)
- [Setting a theme color without JavaScript](/today-i-learned/setting-theme-without-javascript/)
- [Incomplete list of CSS mistakes](/today-i-learned/incomplete-list-of-css-mistakes/)

## Everything else than web dev

### 🏋🏻‍♀️ Fitness & health

I moved a lot this month and could close my rings almost everyday! It's always
cool to see that I were this active. Gives me a lot of confirmation why I feel
better.

![screenshot of my apple watch rings of august 2022](/images/apple-watch-rings-august-2022.webp)

I pushed my workout time to the morning again. But not right out of bed as it’s
been like for most of my twenties. My new workout time is right after my morning
coffee, so I’m a little more awake and energized and I’m happy with it. This and
a very cold shower are my favorit way to start into a new day.

I did not write my bike a lot as I wasn’t in the mood that often this month. I
miss it but it wasn't a priority. We're travelling a lot the next weeks, so
we'll see when the next time on the bike will be.

### 📚 Reading

I’m in a reading flow and have a lot of fun reading books. I’m still behind my
reading challenge of reading 30 books this year, but who cares. 2 books a month
is also a lot for me and I notice that more and more situations occure where I
grab a book instead of my phone. And that’s all I ever wanted.

This month I’ve read:

- [City on fire - Don Winslow](https://www.goodreads.com/book/show/57558287-city-on-fire)
- [All the light we cannot see - Anthony Doerr](https://www.goodreads.com/book/show/18143977-all-the-light-we-cannot-see)
- [Recursion - Blake Crouch](https://www.goodreads.com/book/show/42046112-recursion)

All three of them are great books I can recommand. I think I’m getting better in
choosing books I might enjoy. Especially the last one made my mind go crazy. I
won't spoil anything but the genre is science-fiction and the main topics are
parallel-universes. I dreamed almost every night about it. What a book.

### 🕹 Video Games

I’m dreading the ending of Elden Ring. I’m still in front of the final boss and
haven’t touched it since. Instead I switched to Dark Souls 1 on my switch and
it’s a lot of fun. I’m curious when I’ll find the courage to actually finish
Elden Ring. Or if I’m going to complete Dark Souls 1 first.

### 🎙 Podcasts

I’ve listened to an episode of darknet diares where

<a
  href="https://darknetdiaries.com/episode/121/"
  target="_blank"
>
  Ed Skoudis shares super interesting stories from his job as a penetration
  tester &#8599;
</a>
. Some of them are absolutely insane and I couldn’t believe them at first. Web Security
is such a fascinating topic.

That’s it for **august 2022** in the web developer diary series. See you next
month!


In number 4 of my web developer diary series I write about everything that happened in august. New Projects, new opportunities, new learnings.

Web Developer Diary 04


![an open notebook](/images/web-developer-diary-3.webp)

It’s August already which means recapping everything that happened in July! July
was a different month. A lot of heat in southern germany. With almost no AC’s
here we are not that used to it.

![a gif of a dog sweating](https://media.giphy.com/media/fAv2n4Tlhshig/giphy.gif)

## Work

Work wise this month started quiet. The month before was already quiet because
of our wedding, our little honeymoon and of course my covid infection. This
meant for july: getting back into the game. I did a lot of what you may call
marketing? But I’m not sure if it’s the right term.

I produced a lot of content for my own website. Wrote blog posts, wrote
today-I-learned posts. Re-organized some stuff on it, added some
[recent projects](/work/#projects) so people can see what I worked on so far.

Besides that I tried to get into SEO for real for the first time. And man, you
can get into some deep rabbit holes in this topic. I tried out the
<a href="https://bloggingfordevs.com/" target="_blank">blogging for devs e-mail
course &#8599;</a> by
<a href="https://twitter.com/monicalent" target="_blank">Monica Lent &#8599;</a>
and totally recommend it. I learned a lot about SEO and tools I could
immediately use to improve my website and blog.

Also I’m pretty happy that I discovered the
<a href="https://ahrefs.com/webmaster-tools" target="_blank">ahref webmaster
tools &#8599;</a>. It’s a massive collection of SEO tools. It can crawl your
website and show you errors like broken links, broken redirects, 404's. I’m
planning to write a whole blog post on easy SEO fixes because I learned so much
when using this tool.

Additionally we almost finished a project for a good cause. It’s the website for
the <a href="https://aerosolalliance.com" target="_blank">Aerosol Alliance
&#8599;</a>. It has the goal to reduce the emissions of spray cans. My friends
from <a href="https://studiovierkant.de/" target="_blank">Studio Vierkant
&#8599;</a> work in the spray paint industry and they’re collaborating with
manufacturers on this topic. It’s really exciting!

## Blog posts of the month

July was one of the best months for me, concerning writing. I managed to publish
3 blog posts. And I’m very happy with everyone of them. I had a lot of fun
writing them. Here are the blog posts of the month:

- [Web developer diary #2](/blog/web-developer-diary-02/)
- [The mistakes I made using react](/blog/the-mistakes-i-made-using-react/)
- [Just hit publish](/blog/just-hit-publish/)

## TIL posts of the month

The Today-I-learned collection grew aswell! It’s getting bigger and bigger every
month. It feels so cool to have this big selection of things I learned,
documented so well for the future me. Here are the Today-I-learned posts of
july:

- [Data fetching in react 18](/today-i-learned/data-fetching-in-react-18/)
- [Efficiently load third-party javascript](/today-i-learned/efficiently-load-third-party-js/)
- [HTML sanitizer api](/today-i-learned/html-sanitizer-api/)
- [Array Sort modifies the original array](/today-i-learned/array-sort-modifies-original-array/)

## Everything else than web dev

Talking about everything else then web dev, I really liked this month. I had
some time to pursue some private projects. I loved getting back into working out
and reading a lot.

### 🏋🏻‍♀️ Fitness & health

With my covid infection last month, I needed to take some time in the beginning
of the month for recovery. I didn’t wanted to take any risk. After some time I
started again with small and light almost daily workouts. And I felt really
good! I think that's also visible in my rings:

![screenshot of my apple watch rings of july 2022](/images/apple-watch-rings-july-2022.webp)
I noticed how I got stronger again. I played a lot with my rings and I almost
forgot how much fun they are!

### 📚 Reading

This was my best month concerning my reading challenge. I know it’s not about
the amount of books I read, but I took a lot of time to read which makes me
happy. I read some great books and can recommend all of them. My favorite one
was where the crawdads sing by Delia Owens. I could feel how I get drawn into
this world. And that is clear a sign of a fantastic book.

Here are the books I read in july:

- <a
    href="https://www.goodreads.com/book/show/50993.East_of_the_Mountains"
    target="_blank"
  >
    {' '}
    East of the mountains - David Guterson &#8599;
  </a>
- <a
    href="https://www.goodreads.com/book/show/40404801-notes-on-a-nervous-planet"
    target="_blank"
  >
    Notes on a nervous planet - Matt Haig &#8599;
  </a>
- <a
    href="https://www.goodreads.com/book/show/36809135-where-the-crawdads-sing"
    target="_blank"
  >
    {' '}
    Where the crawdads sing - Delia Owens &#8599;
  </a>

### 🕹 Video Games

I picked up Mario Odyssey again, which I haven’t finished, although I bought it
3 years ago. But the day will come where I’m gonna collect all the moons. Also I
got pretty excited when I noticed that fall guys was released on the switch.
It’s just so much fun.

After a longer break I also got back into Elden Ring. And man, this game is
still so good. I’m somewhat over 100h in and Level 138. I feel like I’m getting
closer to the end and I just don’t want it to finish. I hope there will be a DLC
soon. I tried out a new build and I’m having a blast.

### 🎙 Podcasts

I picked up two episodes of <a href="http://Syntax.fm" target="_blank">Syntax.fm
&#8599;</a> which made me really interested to dig deeper. The first one was
<a href="https://syntax.fm/show/467/stopping-malicious-actors" target="_blank">stop
malicious actors &#8599;</a> where Wes and Scott talked aber super interesting
web security topics like API-rate-limiting, mistakes with an IP based approach,
DDOS, nonce-tokens, captchas, CSRF (cross site request forgery).

So many topics to learn more about! I’d love to get more into web security one
day. And I will definitely write some blog posts about it soon!

The second episode I listened to was
<a href="https://syntax.fm/show/446/making-content-what-is-our-process-youtube-blog-posts-courses-conference-talks-and-podcasts" target="_blank">Making
Content × What is our Process? Youtube, Blog Posts, Courses, Conference Talks,
and Podcasts &#8599;</a>. Wes and Scott share there approach of producing
content and explain more about what works for them and what doesn’t. Very
inspiring and I could take away a lot for my own content producing process!

That’s it for **july 2022** in the web developer diary series. See you next
month!


In number 3 of my web developer series I write about quieter times, producing content for my website, SEO and other projects.

Web Developer Diary 03


[Picture by Victor Rodriguez](https://unsplash.com/@vimarovi)

![a person jumping in the air before a blue lake and mountains](/images/victor-rodriguez-pWOdBS_l9LQ-unsplash.webp)

Writing blog posts is not easy. In fact I find it difficult. I have days were I
can write a well researched blog post in a few hours. And I have days were I
don’t feel like writing. Or I want to add one more thing but don’t know how to
speak my mind. So this is a reminder to myself: **just hit publish**.

---

**Table of contents:**

- [Why publishing blog posts is hard](#why-publishing-blog-posts-is-hard)
- [Make ugly things, it’s better than nothing at all](#make-ugly-things)
- [There is no bar](#there-is-no-bar)
- [Just hit publish](#just-hit-publish)

---

### <a name="why-publishing-blog-posts-is-hard"></a> Why publishing blog posts is hard

When I write a new blog post, I’m always under the impression that everything I
write needs to be 100% true. Well researched, tested, checked again, whatever. I
don’t want to write about stuff I haven’t tried out to the fullest. I want to
know what I’m talking about.

But in most cases, this kind of perfectionism is holding me back. It keeps me
from publishing. It keeps me from finishing blog posts. It’s such a big hurdle.
Everytime I think about adding the final touches to a blog post, I’m not capable
of producing the mental effort that would be necessary.

That’s why my column for “almost finished blog posts” in my notion document gets
longer every week. And unfortunately I found no way yet to change that. Then I
stumbled over two blog posts, that made me change my perspective on this for
quite a bit.

### <a name="make-ugly-things"></a> Make ugly things, it’s better than nothing at all

The first one is
[Make ugly things](https://medium.com/designer-being/make-ugly-things-d6438eb7ba96)
by Srishti Mehrotra. It’s got the perfect subtitle:

<i>it’s better than making nothing at all.</i>

I can apply the main points she’s talking about 1:1 on my struggles with
publishing blog posts. In her article she writes about wanting to be perfect,
wanting her work to be perfect. And also having a hard time to achieve great
work with this perception. Because this often leads to procrastination and to
zero results.

She describes herself as someone who strives for perfectionism. I’d like to add
a direct quote of her article here, because I can imagine a lot of people can
relate to that:

> “As a result, I take forever to get started, and even longer to finish —
> especially things that matter to me most, the things I can’t afford to mess up
> on. And, guess what… end up doing precisely that!”

To escape this vicious circle she started an **ugly sketch bock challenge**. Her
goal was to draw at least one ugly drawing a day. And this actually turned her
into a person who can kickoff creative work easier then before.

It took off the pressure, because the goal was making something ugly, not
something perfect. It gave her more confidence, she favored quantity over
quality which in the end led to more quality.

There are a lof ot learnings and insights here I could apply to my blogging
process. Write more. Do Not try to make it perfect. Assuming that writing more
will lead to publishing with better quality. Sounds great!

### <a name="there-is-no-bar"></a> There is no bar

The other blog post that changed my perspective on writing blog posts is
[There is no bar](https://chriscoyier.net/2022/06/27/there-is-no-bar/) by Chris
Coyier. It's more like a small note, a gathering of thoughts rather than a long
blog post but it asks the right questions.

> “Why do people have a hard time with that publish button, even on
> ready-to-rock personal sites?”

> “We’re not shootin’ for the Pulitzer over here […].”

He talks about how everyone profits if you put out that thought you want to talk
about. Rather than to wait until you have the perfect words for it. He suggests
to stop overthinking and just put it out there.

### <a name="just-hit-publish"></a> Just hit publish

So these two blog posts, and also other ones like
[Just put stuff out there](https://matthiasott.com/notes/just-put-stuff-out-there)
from Matthias Ott reminded me about the most important thing about blogging. My
motivation to write. It’s **to document and share my learnings**.

And this doesn’t have to be perfect. It has to be on here. That’s the main goal.
So I’m trying to write everyday for just a few minutes, I will not try to make
it perfect and I will just hit publish.


We often try to make things perfect before publishing them, which leads to not making things at all. We just need to hit publish.

Just hit publish


<a
  href="https://unsplash.com/@agforl24"
  target="_blank"
  rel="noopener noreferrer"
>
  Picture by Tai Bui
</a>

![a cat sitting on a laptop keyboard](/images/tai-bui-iPsOfXA79U4-unsplash.webp)

In this blog post I’m gonna share all the mistakes I made, using React. Lately
there is a lot of dicussions going on around using Reacts useEffect. See my
Today-I-learned posts
[missusing useEffect](/today-i-learned/missusing-use-effect/) and
[data fetching in React 18](/today-i-learned/data-fetching-in-react-18/).

The React team published a brand new documention on using React, which is
fantastic. It’s still in beta but I could already refresh a lot of my knowledge.
The best part of the documentation is the following section:
[you might not need an effect](https://beta.reactjs.org/learn/you-might-not-need-an-effect)
.

It’s a whole page on when to not use useEffect and how to use useEffect. It has
so many great real-world examples. I noticed immediately that I use a lot of
patterns which were not the best way to solve things.

This made me realize I need to
[adjust my best practices for react](https://twitter.com/Mkuehb/status/1542426932448567296)
. In this blog post I’m gonna share everything I thought I did right when using
React. But noticed now, I can solve it in a better way, according to the new
react docs.

---

**Table of Contents:**

- [Updating state based on props or state](#updating-state-based-on-props-or-state)
- [Don’t use useEffect for expensive caching](#dont-use-useeffect-for-expensive-caching)
- [Use a cleanup function when doing a fetch in useEffect](#use-a-cleanup-function)
- [Avoid passing data to the parent](#avoid-passing-data-to-the-parent)
- [Conclusion](#conclusion)

---

### <a name="updating-state-based-on-props-or-state"></a>Updating state based on props or state

A common pattern I often used, was updating state when specific props changed. I
almost always used an effect for this. Listen when this props change, fire the
effect, update it. Guess what: You don’t need an effect for that! It’s
unnecessary! And, as I learned now: inefficient! To quote the react docs:

> "When something can be calculated from the existing props or state, don’t put
> it in state. Instead calculate it during rendering."

Don’t ❌:

```jsx
// ...

const [street, setStreet] = React.useState('main street')
const [zipcode, setZipcode] = React.useState('70180')

const [fullAdress, setFulladress] = React.usestate('')

React.useEffect(() => {
  setFulladress(`${street} ${zipcode}`)
}, [street, zipcode])

// ...
```

Do ✅:

```jsx
// ...

const [street, setStreet] = React.useState('main street')
const [zipcode, setZipcode] = React.useState('70180')

const fullAdress = `${street} ${zipcode}`

// ...
```

### <a name="dont-use-useeffect-for-expensive-caching"></a>Don’t use useEffect for expensive caching

In this example we get three values as props, and based on them run an effect.
Inside this effect we run a function to sort our data and set it into state.

Don’t ❌:

```jsx
const MyProfile = ({ name, lastname, hobbies }) => {
  const [contactDetails, setContactDetails = useState(null)

	useEffect(() => {
		setContactDetails(getContactSortedByHobbiesAndName(name, lastname, hobbies)
	}, [name, lastname, hobbies])
}
```

This is, again, unnecessary and inefficient. We shouldn’t use useEffect to cache
something like that. We don’t need to! We can remove the state, the whole
useEffect and once more calculate this value during render!

Do ✅:

```jsx
const MyProfile = ({ name, lastname, hobbies }) => {
  const contactDetails = getContactSortedByHobbiesAndName(
    name,
    lastname,
    hobbies
  )
}
```

As you may have already noticed, this is almost the same pattern as in the first
example. But the React docs add another improvement to it. Imagine our function
here is doing some expensive filtering by comparing thousands of rows. With a
small adjustion we can add free caching to that, without using useEffect!

Even better ✅✅:

```jsx
const MyProfile = ({ name, lastname, hobbies }) => {
  const contactDetails = useMemo(() => {
    return getContactSortedByHobbiesAndName(name, lastname, hobbies)
  }, [name, lastname, hobbies])
}
```

By adding useMemo we can cache this expensive filter or sort operation. It tells
React that it does not need to re-run the inner function unless name, lastname
or hobbies changes.

### <a name="use-a-cleanup-function"></a>Use a cleanup function when doing a fetch in useEffect

I already talked a bit about how I used useEffect wrong in a today-i-learned
post. The key takeaways from this were, that data fetching in react works, but
you need a cleanup function. Otherwise you will face race conditions.

A classic data fetching in useEffect example, which I’ve done a lot, could look
like this:

Don’t ❌:

```jsx
const Searchbar = ({ searchTerm }) => {
  const [data, setData] = useState(null)

  useEffect(() => {
    const response = fetchFromSearchAPI(searchTerm)
    const data = response.json()
    setData(data)
  }, [searchTerm])
}
```

There is one big problem here. If a user triggers this search a few times and
kicks off separate fetches, there is nothing implemented to handle stale
responses. This might result in “wrong” results, which is a race condition. As
the react docs put it: two different requests “raced” against each other and
came in a different order than you expected.

The best way to fix this, is to add a cleanup function:

Do ✅:

```jsx
const Searchbar = ({ searchTerm }) => {
  const [data, setData] = useState(null)

  useEffect(() => {
    let reset = false
    const response = fetchFromSearchAPI(searchTerm)
    const data = response.json()

    if (!reset) {
      setData(data)
    }

    return () => {
      reset = true
    }
  }, [searchTerm])
}
```

This ensures, React will only take the last response from the API and your
component will avoid race conditions.

### <a name="avoid-passing-data-to-the-parent"></a>Avoid passing data to the parent

Another pattern I used almost every time when working in a React project is
passing data from the child to the parent. Imagine you have a child component,
which fetches some data. You pass a callback function to it as props to get the
data to the parent.

Don’t ❌:

```jsx
const Header = () => {
  const [data, setData] = useState(null)

  return <SearchBar onChange={setData} />
}

const Searchbar = ({ onChange }) => {
  const data = fetchSearchResults()

  useEffect(() => {
    if (data) {
      onChange(data)
    }
  }, [onChange, data])
}
```

This pattern seems weird at first. But it helped me for several specific use
case a lot, where it made sense to me to fetch the data in the child component.
But the obvious improvement here is to lift state up.

Do ✅:

```jsx
const Header = () => {
  const data = fetchSearchResults()

  return <Searchbar data={data} />
}

const Searchbar = ({ data }) => {
  // ...
}
```

The data gets fetched in the parent component and then passed down to the child
component. As the [React docs](https://reactjs.org/docs/thinking-in-react.html)
put it: React is all about one-way data flow down the component hierarchy. Makes
error tracing a lot easier. Even though there were some arguments for the child
data fetching, it’s always better to lift it up.

### <a name="conclusion"></a>Conclusion

There are a lot of key take aways from this article. The main thing, that got
stuck in my head is, to think twice whenever I write useEffect in the future. In
most cases I don’t need to! The other key take aways are:

- if it’s possible, calculate something during render and not in an effect
- you don’t need effects to transform data for rendering
- if your code should run because it should be displayed to the user, use an
  effect
- if you fetch data deep down in your component tree, but the parent also needs
  this state, lift it up
- if you want to fetch data in an useEffect, add a cleanup function

The new react docs talk about a lot more situations where you might not need an
effect, with better examples and even some challenges for you. It’s awesome that
they took the time to write something so detailed and helpful. I’m glad I could
rethink some patterns which I thought were the best practices.

Grab a cup of coffee (or your favorite beverage) and take your time to read
through it:
[you might not need an effect](https://beta.reactjs.org/learn/you-might-not-need-an-effect)
. It’s so worth it and I learned a lot.


In this blog post I’m gonna share all the mistakes I made, using React.

The mistakes I made using React


![an open notebook](/images/web-developer-diary-2.webp)

I started this series last month. As we all now, time flies and here we are
again for **web developer diary #2**, the june issue.

June was a crazy month. Less because of work but mainly because me and my wife
got married! It needed a good amount of planning to make sure work won’t get too
stressful this month. Almost all energy and time was needed for the organization
of our wedding.

### Work

As I already said, I figured I needed to block a lot of time for others things
than work. That’s why we managed to launch one of the biggest projects I’ve
worked on so far as a freelancer right away at the start of june.

It’s the website [dieda.de](http://dieda.de) and I’m pretty happy with the
result. It has a lot of interactive parts which were a lot of fun to develop. I
worked on it together with my friends from [Werk8](https://www.werk8.design/).
It was our first project together and I think there will be a lot more to come.

The push to production went pretty smooth. We prepared and planned a lot before
hand so we knew that not a lot could go wrong. The only hickup was a little
confusion with the redirects. But we managed to resolve it quickly.

Once again a great go-live checklist is a life-safer in this case. I will
definitely write a blog post soon about how I prepare for a website launch.

The website runs, it’s pretty fast and the client is really happy. Success!

Besides from this big launch I worked on some smaller projects, which were a lot
less work, thanks to
[my starter kit](https://github.com/marcoheine-com/website-starter-kit). It was
really worth the time I put into this project.

Other than working on client projects I started to produce content again for my
own website. I have a lot of great blog posts almost finished, I can’t wait to
publish! I’m also in the flow of publishing 3-5 today-I-learned posts a month.
It brings me a lot of joy to work on content for my site and I hope I can keep
it up.

### Blog posts of the month

I published two blog posts this month. The first one of course was the kick off
of this series, which I enjoyed writing very much. It feels so good to look back
and reflect on what happened and how it shapes the now.

The second blog post was about my
[website-starter-kit](/blog/website-starter-kit/).

### TIL posts of the month

I managed to publish 3 Today-I-Learned posts this month, which I’m pretty happy
about.

- [How to write great alt text](/today-i-learned/write-great-alt-text/)
- [Automatic ER diagrams](/today-i-learned/automatic-er-diagrams/)
- [Missusing useEffect](/today-i-learned/missusing-use-effect/)

I got a lot more on my notion doc and my
[today-I-learned page](/today-i-learned/) is turning out great. It has got the
different tags you can filter for and the search functionality, which I use a
lot.

### Everything else than web dev

As I already mentioned in the beginning: I got married! It was wonderful and
amazing at the same time. A magical experience. I never thought I would say
things like that but that’s the way I feel about it.

We celebrated two wonderful parties. The first one was the official ceremony
with our family and closest friends. The second one was a big party with all the
people we love.

After our wedding we started our honeymoon with a great time in south tyrol. I
get it now why everyone I know loves to go there. Beautiful nature, great food,
great weather, nice people and just a 5 hour drive. And the best thing: it’s
Italy!

![view of the landscape around meran](/images/view-from-meran.webp)

#### 🏋🏻‍♂️ Fitness & Health

I felt good at the beginning of the month. I did a lot of smaller workouts and
one hour long gravel rides. Due to preparing and celebrating our wedding, I did
not find time for longer workouts or rides. But that didn’t bother me too much.
I felt healthy and fit. Plot twist: than I got Covid.

It’s funny that you can spot the exact time frame when it happened in my apple
watch rings.

![screenshot of my apple watch rings in june 2022](/images/apple-watch-rings-june-2022.webp)

I’m negative now and free of symptoms but still recovering. My heart beat is
still pretty high even when I just go for a little walk. I definitely need to
relax for the next two weeks and don’t do anything too heavy.

#### 📚 Reading

I finished two books this month:

- [Christian Sauer - Draußen gehen](https://www.goodreads.com/book/show/48715024-drau-en-gehen)
  (only available in german I think)
- [Annie Proulx - Postcards](https://www.goodreads.com/book/show/28000.Postcards)

The first one was about the sane thing of walking outside. The author brings it
into the context of creative techniques. He also explains why it’s beneficial to
your work. I liked a lot of his ideas. Even though if you could summarize it as:
when you’re stuck on a problem, go for a walk.

The second one was Annie Proulx’s famous debut book. It’s just so different from
everything I read and that’s what it makes so special for me.

I also started a new book
[David Guterson - Rast of the mountains](https://www.goodreads.com/book/show/50993.East_of_the_Mountains?ref=nav_sb_ss_1_16).
I’m really into it right now and like the story and where it’s going.

The
[reading challenge](https://www.goodreads.com/challenges/11636?ref=nav_profile_rc)
stands on 9 books read out of 30, so a lot more to go. But I think I’m gonna
make it.

#### 🕹 Video Games

Didn’t find a lot of the time to play Elden Ring but got close to the end. I
think I’ve never put so much time into a video game and I don’t regret a minute
of it. Still I’m not feeling it that much right now so maybe take a break of it
for now.

I’m tempted to start playing with my Switch again, haven’t finished Mario
Odyssey!

#### 🎙 Podcasts

I listened to the
[Syntax episode about edge functions](https://syntax.fm/show/454/wtf-is-the-edge-edge-compute-functions).
I’ve heard so much about it and wanted to learn more on this topic. Wes and
Scott talk about what this is all about, the upsides and downsides and what
they’re used for. Can recommend!

That’s it for **june 2022** in the web developer diary series. See you next
month!


In number 2 of my web developer series I write about finishing big projects, celebrating our marriage, having covid and starting new projects.

Web Developer Diary 02


<a
  href="https://lauraheine.com"
  target="_blank"
  rel="noopener noreferrer"
>
  Illustration by Laura Heine
</a>

![an image of a woman thinking](/images/wip.png)

I’ve started working as a **freelance web developer** in february 2022 and so
far it’s been a lot of fun. Helping people to get their content, product or
services online feels very **rewarding**. On the other hand it often feels like
having **three jobs at the same time**. So improving processes plays a major
role in getting better at freelancing.

**Table of Contents:**

---

- [Improving the process](#improving-the-process)
- [The main parts](#the-main-parts)
- [Why I’ve chosen these technologies and honorable mentions](#why-ive-chosen-these-technologies)

---

## <a name='improving-the-process'></a> Improving the process

After my first few client projects I noticed that a lot of the requirements are
the same and I keep **copy and pasting code** from one project to another.

Additionally the setup process of a new project often was the same. This brought
me to the point where I saw the case for a having an (almost) blank page to kick
things off, a white label, a website starter kit.

Note: Of course I know that this is not a big deal and I guess every developer
has their own templates to get started.

But nevertheless I wanted to write about my starter kit, the main parts of it
and what worked best for me so far. To reflect on my decisions and also gain
insights from others and what works best for them.

## <a name='the-main-parts'></a> The main parts

So here it is, my
[website starter kit](https://github.com/marcoheine-com/website-starter-kit).

It’s basically a setup of

- NextJS with TypeScript,
- TailwindCSS for styling
- Prismic as a headless CMS with pre-modeled and pre-built components
- Linting with eslint and prettier

With this setup I’ve already accomplished a lot of different use cases for
client projects.

From basic one-pagers, to landing pages with a handful of subpages, to big
corporate pages with dozens of subpages and web app features like filtering,
sorting, searching, connecting to a database, multiple API routes and
integrating different third-party services.

I have the feeling that this starter kit is ready for all of it and whenever I
start a new client project now, I just use it as a base and get started from
there real quick.

Without thinking or taking the time to setup and install dependancies. This
feels really cool.

## <a name='why-ive-chosen-these-technologies'></a> Why I’ve chosen these technologies and honorable mentions

### NextJS with TypeScript

**NextJS** is just so easy and fun to use, the documentation is fantastic and
all the sites I build with it are super fast, using the static generation
approach. So this was a no-brainer.

But I have to say, after playing a bit with [Remix](https://remix.run/) I’m
hoping it will get more popular and get a Prismic integration one day.

I can totally imagine switching NextJS for Remix, because it makes things even
easier and more natural.

### TailwindCSS

I’ve read all the discussion around TailwindCSS and I understand some of them.
At the end of the day I’m so much faster when I use Tailwind for styling in
comparison to styled-components, which I’ve used for all my projects before.

<CoffeeHint />

### Prismic

The market for headless CMS is huge and I could fill a whole page just about
them. I’ve tried a few and I liked Prismic the most. This is based on their
content modeling approach with custom types and slices.

But it is also mainly based on their editor interface. I have the feeling that
this is more accessible than others for non developers and this is a major
selling point for me.

But this starter kit does not only contain the integration part of prismic as a
CMS. It also has pre-modeled and pre-built components, that almost every website
uses. Like header, footer, menu or text-image.

### Linting with eslint and prettier

No one wants to manually format code. I’ve worked in a project years ago where
there was no automated code formatting and it was horrible. Hours spent by
setting code on the same line. Ugh.

So integrating eslint together with prettier is a no-brainer. Renaming
variables, forgetting one file and you get errors and don’t know why. Not
anymore with basic linting done by eslint.

That’s it, thats my website starter kit, the foundation from what I start all my
projects right now. I’m really curious when I’m going to change things here and
how long I’m going to use this.

What is your stack? What technologies are you using all the time together? I’m
really curious to know! Send me an [email](mailto:marco@marcoheine.com) with
your thoughts on this.


In this blog post I'm going to explain my website starter kit, which I use to kickstart every new client project.

Website Starter Kit


![an open notebook](/images/jeshoots-com-9n1USijYJZ4-unsplash2.jpg)

With this blog post, I’ll start a new series: the **Web Developer Diary**
series!

I saw this idea on Dave Ruperts
[blog](https://daverupert.com/2022/05/vibe-check-16/). He calls it vibe check
and it’s a **check-in** at the end of every month, to **reflect** on things that
happened during this month - work-whise and in private.

I really like this format, because I do a monthly reflection on things anyway
with my _“Ein guter Plan”_ planner
([https://einguterplan.de/](https://einguterplan.de/)) (sorry, only available in
german!).

So without any further ado, let’s start this **Web Developer Diary series** and
see what happened in May 2022!

## Work

I started **freelancing** back in february with one of the biggest projects I’ve
ever worked on and this month was the time of adding the final touches and
preparing everything for **the big launch**. It’s a NextJS static-generated
website where we used Prismic as headless CMS and vercel for deployment and
hosting. This combination is genuinely so much fun to work with. The site is
predominantly static generated content, but the amount of content is A LOT.

I wasn’t sure how user-friendly Prismic is with a ton of documents and custom
types and if we would lose track immediately. But turns out: their filter and
search functionality is actually great. All the people who were adding content
into the CMS were pretty happy with it, which makes me confident in using
Prismic for bigger projects in the future again.

Besides all the static pages this project also included a lot of **interactive**
parts, which made the development challenging and very exciting. That included
the possiblity of filtering and sorting items, a pretty cool interactive map,
and a powerful search based on [algolia](https://www.algolia.com/). Implementing
a search with algolia was very intuitive and rewarding. It’s the first time I
used it and I can highly recommand it.

Besides this big project I also worked on some smaller projects, using the tech
stack mentioned above.

For the first time ever I did some **client outreach** by myself. This means
reasearching companies who have bad websites or no website at all and contacting
them with reasons why a great website will benefit them. I took away **three key
learnings** from that:

- A lot of companies still do not have a website and have only a facebook or an
  instagram page and this really shocks me
- A lof of companies still have really bad websites. Using outdated jQuery
  versions, 10s loading times or more, not accessible at all and just looking
  terrible
- It’s really motivational to tell someone why a good website should be
  important and a priority to them. That confirms me in why I do what I do and
  why I like it so much.

## Blog posts of the month

Unfortunalety I didn’t find the time to finish a blog post completely this
month. But I have some posts in my “almost finished” columns and I’m pretty
excited to publish them in the next weeks.

I’ve already learned so much in this first few months of freelancing, I could
spend a whole week of just writing down everything I learned and turning that
into blog posts. I hope this web developer diary will bring me back into writing
blog posts regularly again!

## TIL posts of the month

I did find the time to add some new Today-I-Learned posts this month, which
makes me really happy.

- [Headless wordpress](/today-i-learned/headless-wordpress/)
- [POST vs. PUT](/today-i-learned/post-vs-put/)
- [Confetti](/today-i-learned/confetti/)
- [Most common accessibility issues](/today-i-learned/most-common-accessibility-issues/)

I also played around a bit with my [Today-I-learned page](/today-i-learned/),
added some nice animations and the coolest part: **a search functionality**!
It’s basically just a client-side filter which checks several parts of the posts
with `.includes()` but it works pretty well and I use it a lot!

Stay tuned for more Today-I-learned posts in the next weeks, my draft folder
gets bigger and bigger.

## Everything else than web dev

### 🏋🏻‍♂️ Fitness & Health

Concerning working out this month was quite a good one. I managed to close my
rings on my apple watch on 22 days. I missed my standing goal only on 2 days
which makes me very happy.

![screenshot of closed apple watch rings](/images/apple-watch-rings-may-2022.webp)

I managed to fit in one, or two workouts every week. My current workout routine
consists of

- 3 sets of pullups alternating with 3 sets of pistol squats
- 3 sets of pushups alternating with 3 sets of ring dips
- and 3 sets of arching active hang

The last one is my progression path to achieving the front lever one day.

Besides bodyweight exercises I rode my bike a lot and I already can feel how I
get fitter. It's a Focus Atlas 6.7 gravel bike and it was one of the best things
I got myself this year. For me it's the perfect combination between mountain
biking and riding fast and I'm having a lot of fun.

### 📚 Reading

I finished two books this month:

- [The Anomaly](https://www.goodreads.com/book/show/56920684-the-anomaly) by
  Hervé le Tellier
- [Once there were wolves](https://www.goodreads.com/book/show/54860573-once-there-were-wolves)
  by Charlotte McConaghy

I liked them both a lot. The latter even made me shed a few tears.

I also started a new book, it’s
[Postcards](https://www.goodreads.com/book/show/28000.Postcards) by Annie Proulx
and I’m really excited about it. It’s the one book who made her win her first
award. I loved Shipping news and Accordion Crimes and I’m really interested what
this book will be like.

I’m currently at 7 books read this year and my goal are 30. You can follow the
progress of
[my reading challenge](https://www.goodreads.com/user_challenges/31803693).

### 🕹 Video Games

I bought an Xbox Series S back in march only for one reason: I wanted to play
[Elden Ring](https://en.bandainamcoent.eu/elden-ring/elden-ring). And what can I
say: I think this is the best game I’ve ever played. The open world is so
enjoyable to explore, the boss fights are unique and a lot of fun and I did not
have on minute where I regretted buying a new console for the sole purpose of
playing one specific game.

If you’re also playing: I’m currently 84h in and level 100.

I’m no expert in the souls games, I just have a lot of fun playing them. I’m
really curious on how long it will take me to finish this game.

That’s it for **may 2022** in the web developer diaries series. See you next
month!


Web Developer Diary 01


<a
  href="https://unsplash.com/@anthonytran"
  target="_blank"
  rel="noopener noreferrer"
>
  Photo by Anthony Tran
</a>

![an image of a woman thinking](/images/anthony-tran-3B6RfJQKBEM-unsplash.jpg)

It's not. And never will. You can **relax** and stop searching for alternative
career ideas. In my opinion Github Copilot is one of the **best things** that
could happen to us developers in the current state of (web) development.

In this blog post I will explain why I think this is the case.

**What you can learn from this blog post:**

---

- [What is GitHub Copilot](#what-is-it)
- [What can GitHub Copilot do](#what-can-it-do)
- [Why it's not stealing our developer jobs](#why-its-not-stealing-our-jobs)

---

## <a name='what-is-it'></a> What is GitHub Copilot

GitHub Copilot was announced on June 29th 2021 as your **AI pair programmer**.
You can read the introduction blog pos over here:
[https://github.blog/2021-06-29-introducing-github-copilot-ai-pair-programmer/](https://github.blog/2021-06-29-introducing-github-copilot-ai-pair-programmer/)

It claims to **help you write better code**.

> GitHub Copilot draws context from the code you’re working on, suggesting whole
> lines or entire functions. It helps you quickly discover alternative ways to
> solve problems, write tests, and explore new APIs without having to tediously
> tailor a search for answers on the internet.

> As you type, it adapts to the way you write code—to help you complete your
> work faster.

As soon as I read the announcement I was hyped. I was tired of writing the same
JavaScript code over and over again. Mapping over arrays, manipulating part of
the data and returning it as some sort of HTML. Sometimes I feel like I'm
**doing nothing else than that**.

I immediately felt like I knew where GitHub Copilot would make my life easier.
Without getting scared that it would do ALL the work.

## <a name="what-can-it-do"></a> What can GitHub Copilot do

As I saw the first few posts coming in from people who where lucky enough to try
it out, I felt supported in my gut feeling, in my assumption in what Github
Copilot could do - and what not.

People showed how GitHub Copilot knew where they were going when writing a
specific function. It took the **tedious work** from their shoulders by writing
out the detailed specifics for them. And this was so cool to see.

I entered my email to join the waiting list and after a few weeks I got the
invitation to the repository and was able to install the Visual studio code
extension.

My first few tries were pretty basic. I defined a function and GitHub Copilot
knew by the name of this function what logic I wanted to write inside of it.

I created a new file, imported React and it suggested the skeleton of a whole
functional component.

I started to use the [Array.prototype.map](http://array.prototype.map) function
on an Array of data I got from a GraphQL query and it suggested to manipulate
parts of the data and knew how to return it as semantic HTML.

I'm still at the beginning of using the advantages of GitHub Copilot but I
already miss it here in Notion where I'm writing this blog post as there are no
suggestions.

**But GitHub Copilot is not just auto-completion**. You can turn **comments into
code**. You can use it to write repetitive code. It can even write **tests** for
you. And it can show you how to write a certain part of your code in a different
way.

I already notice how this makes me **faster and more confident**. I really feel
like I have a copilot with me all the time, a second pair of eyes, supporting me
and making my code less error-prone.

This gives me a lot of **confidence when tackling new problems**.

Maybe this will eliminate the time spent on searching the internet and
understanding how `Array.prototype.reduce` works for the 317th time.

I also can image that GitHub Copilot will make learning and working with a
language you're not that familiar with a way better experience.

This are just my first impressions on it. You can checkout the documentation
here: [https://copilot.github.com/](https://copilot.github.com/)

It shows a lot of detailed examples and usecases.

## <a name='why-its-not-stealing-our-jobs'></a>Why it's not stealing our developer jobs

So when this GitHub Copilot is doing all our work, is it stealing our jobs?

Do we still need people to program? Do we still need human beings for web and
software development?

<CoffeeHint />

Of course this is a highly philosophical and controversial questions because it
points into the direction of "Can AI take over?".

I'm no expert in AI at all and in no means can I answer this questions. **But I
know that GitHub Copilot will not steal our jobs**.

I know this could sound naive and maybe in a few years we're all unemployed and
you can tell me: "I told you so". But I strongly believe that this is not the
case.

My assumption is, that **AIs like GitHub Copilot will help and support us**.
They will make our lives easer. But this doesn't mean we won't have jobs
anymore.

This means we have more time to care for the more complex and bigger problems,
we claim to solve with web and software development.

This means we can solve some tasks faster and have more energy for higher
obstacles.

In the end a human being is always needed to point something like GitHub Copilot
into a certain direction. We have to tell it what kind of function we want to
write, to solve this problem in a certain way.

The **creativity** comes from us, that's one of humans biggest strengths. I know
that AI can become creative too, as we've seen with numerous examples of AI
creating art and music.

But I strongly believe that the best outcome will always be achieved **when
humans and AI work together**.

We're still at the very beginning and GitHub Copilot will learn more and more
about how we program. I'm very excited how this turns out.


GitHub Copilot is not stealing our jobs


[Photo by Brooke Cagle](https://unsplash.com/@brookecagle)

![three people sitting on a table laughing](/images/brooke-cagle-g1Kr4Ozfoac-unsplash.jpg)

Clear communication, always ask questions, check what you really should care for
(hint: it's not the shiny tech stack) and always be nice. My colleagues taught
me alot. Here's part 2 of my learnings.

This blog post is part 2 of a series. Make sure to check out
[part 1](/blog/most-important-things-i-learned-from-my-former-colleagues-part-1/)
aswell.

**What you can learn from this blog post:**

---

- [Hesitate to ask a question? Do it anyway!](#ask)
- [Communicate clearly](#communicate)
- [You won't get along with everybody, and that's okay](#getting-along)
- [We care for the user and their problem (not for the fancy new tech we used to implement this feature)](#users)
- [Be nice](#be-nice)

---

### <a name='ask'></a> Hesitate to ask a question? Do it anyway!

We all know that feeling. You're sitting in a meeting with a bunch of people.
Someone explains the details of a complex topic. They ask, if everyone
understands the topic. Everyone nods.

But you don't understand and you have a lot of questions. But you really
hesitate to ask. Everyone clearly signalled, that they understood it. So why
even bother?

And, if it's a "stupid" question, you don't want to embarass yourself. What if
the problem is just that you haven't listened well enough?

Forget about all this. **It doesn't matter**. If you still have questions and
don't understand something well enough, ask! Ask again. And again.

Because if you're the one who is implementing this feature later and you don't
understand it, that's the real problem. Then you really wasted a lot of time.

In most cases, everyone didn't understand everything. And they will be so
thankful to you, that you asked this question. Because it's hard to admit, that
you have a hard time following along.

So the next time you hesitate to ask a question - **do it anyway**.

### <a name='communicate'></a> Communicate clearly

Communication is hard. In my opinion, for being a good developer your
communication should be a **number one priority**. Communication is one of the
topics where a lot of things can go wrong.

So communicating clearly and improving your communication steadily is so
important.

By clearly I mean **being honest**. Tell your team members what your current
status is. Tell your manager when there is a problem. Don't tell them you can
solve it in five minutes if you don't know yet what the root cause is.

Don't wait till a few hours before the deadline to communicate that you can't
make it.

**Good communication solves problems before they arise and prevents bugs and
errors**. That's why it's a desirable goal.

### <a name='getting-along'></a> You won't get along with everybody, and that's okay

We as humans want to be liked. We want to belong. We want to become a part of a
group or stay a member of a group and we do a lot for that goal. That's our
nature.

It's even harder when you notice that you're having a hard time dealing with
someone. You have different opinions, you always disagree, you always favor
different solutions.

Deep in your heart you want to be on the same page with this person.

But you won't and can't get along with everybody and that's **totally okay**.

<CoffeeHint />

Sometimes you need people who question everything. Even if it's annoying to you
it can have a lot of **benefits** for the development. Rethinking ideas is a
valuable aspect of product development.

If you happen to find such a person, **don't despair**. Be glad, it's a good
thing!

### <a name='users'></a> We care for the user and their problem (not for the fancy new tech we used to implement this feature)

If you break it down to one thing that we're doing in web development, it's
**we're solving problems of people**. We have users whos lifes we want to make
**easier and better**.

That's what the job is for. That's the only thing we should care for.

Of course we need to make decisions on which tech stack to use, how to implement
certain things. We should make these decisions based on the team members we
have. The knowledge we have. But all of these considerations should point at the
user.

Imagine you have three team members who are proficient in TypeScript,. This
means you can develop this certain feature pretty fast with a high quality
standard. Which means the user will benefit a lot from it.

Using another programming language because everyone is using it right now would
be a really bad decision in this case.

You would have to learn the language. It could be of bad quality because you're
not experienced and it would take much longer. And, in the end, the user would
not benefit from it at all.

So always remember: we care for the user and want to solve their problem. Every
decision making should be geared towards this.

### <a name='be-nice'></a> Be nice

I thought about a long explanation with a lot of different examples of why being
nice is so much **better** than yelling, being angry, blaming someone. But this
should be **common sense**.

Being nice opens way more doors and has infinite benefits. And in the end it's
the one thing that does not harm anyone. **Just be nice**.

![a gif of a men saying: the moral of the story is: be nice to people!](https://media.giphy.com/media/WoFjW5lqb9ciUKfYx1/source.gif)


The most important things I learned from my former colleagues - part 2


[Photo by John Schnobrich](https://unsplash.com/@johnschno)

![three people pointing on a laptop screen](/images/john-schnobrich-2FPjlAyMQTA-unsplash.jpg)

I call myself extremely lucky. I had and still have the opportunity to work
together with some **extraordinary human beings.**

They helped me and others to **grow** and get better at what we're doing. Not
only in technical matters but also in soft skills.

This blog post is for me. To always remind me about the most important things I
learned from my colleagues working in the web development industry. And maybe
you can take away something from it, too.

**What you can learn from this blog post:**

---

- [We write code for humans, not machines](#humans)
- [It's always we - not you alone](#team)
- [Seniority has nothing to do with age](#senior)
- [No finger pointing](#finger-pointing)
- [Underpromise - overdeliver](#under-promise)

---

### <a name='humans'></a> We write code for humans, not machines

Do you know that feeling when you used a cool feature of your favorite
programming language? Or refactored a long function? Or turned a long function
into a one liner?

And do you also know the feeling of coming back to this code after a few weeks
and **not understanding a single thing** that is happening there?

You might have had good intentions– improving the code base. But if you don't
put much thought into it and just refactor something because one-line functions
are "cool and smart", you're making things **worse**.

Imagine how this must feel for your fellow co-workers who didn't even write the
code. They need a lot of **mental processing** to follow along here.

So always remember: **we write code for humans, not for machines.** I know in
the end it's the machine who compiles and runs the code. But for the most part,
code should be **human readable.** It should be written for humans so other
humans can understand, change and improve your code.

### <a name='team'></a> It's always we - not you alone

We are a team. We work together as a team and the code, the products, the
features we release are the result of this team work. Nobody is responsible for
something alone. Its always a **team effort.**

I know how it feels to implement a whole new feature by yourself and you feel
the urge to tell everyone about it. That's just your ego talking.

Of course you can be proud of yourself. Celebrate yourself, acknowledge what
your capable of.

But don't forget the work of your teammates that also played a major role in it.
From the conception of the feature to the design, the code review to the
testing. It's always a "we did this together".

### <a name='senior'></a> Seniority has nothing to do with age

When I started working in web development I was often under a certain
impression. I thought that after working for a few years in this area you
**automatically** turn into a **senior developer.** You get this shiny new
title, more money and more respect.

It took me a while until I figured out, that this is **not how it works.** Just
because you're growing older doesn't mean you become a senior. There is so much
more to seniority than just age.

For me personally getting to a senior level means, developing into a specific
person. A person who can **teach**, **motivate** and get the best out of all
their team members. Who has a lot of experience but doesn't brag about it.

Who can **lead** others and also **follow** their advice. Who has a lot of
ideas, opinions but also acknowledges others and can admit when they are
**wrong**.

It's a person you want to **look up to.** A person you look forward to **learn**
more from everyday. And became someone like them eventually.

These are just a few facts and this description only **scratches the surface**.
My good friend Dom wrote a
[fantastic blog post](https://islovely.co/posts/how-to-go-from-junior-to-senior-developer)
about this topic.

I have one planned too on the senior subject, so make sure to check-in again in
a few weeks!

### <a name='finger-pointing'></a> No finger pointing

When things go wrong and you know your colleague messed up, it's super easy to
point at them and shout "they did this, they are responsible"! Don't be that
person. It's **not helpful** in any way.

Of course you need to find solutions for problems and figure out everything that
lead to a specific outcome. But pointing at someone and blame them is the
**wrong way** to handle it.

Why? It's the same I already wrote about above in "It's always we - not you
alone". We are a team and we are always responsible for things as a team, no
matter if it's about success or failure.

When we know that someone contributed to a problem we can talk to them, help
them to improve and tell them what to do next time, so it doesn't happen again.

Fixing problems always works better without finger pointing.

<CoffeeHint />

### <a name='under-promise'></a> Underpromise - overdeliver

When I started as a web developer I was always super proud of the things I did.
And I always wanted to show people what kind of cool things I could make.

This also led to the thing that I could not make **realistic estimates.** I
always wanted to make something super cool and shiny at all costs.

So if someone suggested to build a specific feature and I loved the idea, I
would want to build it without actually thinking about the real effort and time
it would take. I just wanted to do it.

Maybe I already knew from the start that it could take much longer than
expected. But I wanted to ignore that fact and make everyone proud.

Sooner or later I came to the conclusion that this wasn't helpful. If you
promise something and can't deliver, you have to break your promise.

It's way easier and healthier to under promise.

And if all goes well and you have more time for something than expected you
still can over deliver.

**These are the first 5 things I learned from my colleagues working in web
development. This is part one of a series, so stay tuned for more!**


The most important things I learned from my former colleagues - part 1


<a
  href="https://unsplash.com/@blnk_kanvas"
  target="_blank"
  rel="noopener noreferrer"
>
  Picture by Will O
</a>

![a hot air ballon getting ready to fly](/images/will-o-GtYFwFrFbMA-unsplash.webp)

### How I got to know go

> "Wait, what? What's happening here? Your previous blog posts were all about
> frontend development, CSS JavaScript, React. Now this..go? What is it? And why
> are you blogging about it?"

If this new content on my blog confuses you a little, I'm sorry! A lot of new
things happened to me in the last months and one of them is, that I'm **taking a
closer look** on both (all?) sides of web development. Which includes working
with and learning more about **backend technologies**.

My first contact with everything else than frontend was in a project were we
worked with **NodeJS/Express** and **MongoDB**.

This granted me a lof ot knowledge on how all parts of a web application work
together. **From the frontend, to API Calls, middlewares, services, raw SQL and
to the database**.

In the project I'm working in right now, we're using **go** in the backend and
therefore I'm learning go!

And to make the most of it I will **document** everything I learn about go in
this blog post. So I have a place to come back to and look at when I forget
everything.

And maybe you can learn something from it too!

### So...go. What is it?

> Go is an open source programming language that makes it easy to build simple,
> reliable, and efficient software.

At least that's what it says about itself on its website. Let's see what
wikipeda has to say about go:

> Go is a statically typed, compiled programming language designed at Google by
> Robert Griesemer, Rob Pike, and Ken Thompson. Go is syntactically similar to
> C, but with memory safety, garbage collection, structural typing, and
> CSP-style concurrency. The language is often referred to as Golang because of
> its domain name, [golang.org](http://golang.org/), but the proper name is Go.

Ah that tells a bit more about it. Interesting! Now that we are behind the get
to know each other phase, let's see what **topics** I'll cover in this blog
post. As the title says it will be an absolute beginner introduction.

If I'm wrong about something or made mistakes, please let me know!

### What you can learn from this blog post:

---

- [packages, import, export](#packages)
- [Variables](#variables)
- [Functions](#functions)
- [Data types](#data-types)
- [for](#for)
- [if, else](#if-else)
- [switch](#switch)
- [struct](#struct)
- [arrays](#arrays)
- [slices](#slices)
- [range](#range)
- [map](#map)
- [method](#method)
- [pointers](#pointers)
- [pointer receivers](#pointer-receivers)
- [interfaces](#interfaces)
- [errors](#errors)

---

### <a name='packages'></a>packages, import, export

Every go program is made up of packages. You always have to have a **main
package**, where your app starts. You can **import** your own packages or one of
the hundreds of go packages.

A name (of a function, struct etc) is **exported** and therefore can be imported
if it begins with a capital letter.

```go
package main

import (
	"fmt"
	"math"
)

// is not exported
func main () {
	PrintStr()
}

// can be imported from other packages in your app
func PrintStr () {
	fmt.Printf("Hello World")
	fmt.Println(math.Pi)
}
```

### <a name='variables'></a> Variables

There are several ways to declare variables in go. The classic `var` lets you
declare one or more variables at once. The `const` lets you declare constant
variables. The `:=` shorthand lets you declare and initialize a variable at once
inside a function.

```go
var a = 10
const 1 = 10

// shorthand for declaring and initializing a a variable inside a function
a := 10
```

### <a name='functions'></a> Functions

A function in go can take **zero or more arguments**. The type of the input
parameter comes after the variable name. When the parameters have the same type
you can combine the type declaration.

The input parameters are followed by the return type.

A function can return any number of results. In go explizit returns are
required.

```go
func multiply (a, b int) int {
	return a * b
}

multiply(3, 6)
```

### <a name='data-types'></a> Data types

Surprise, surprise go has values like boolean, strings and integer. Here's a
list of all of them.

```go
bool

string

int  int8  int16  int32  int64
uint uint8 uint16 uint32 uint64 uintptr

byte // alias for uint8

rune // alias for int32
     // represents a Unicode code point

float32 float64

complex64 complex128
```

Variables declared without an initial value are given their zero value:

- `0` for numeric types,
- `false` for the boolean type, and
- `""` (the empty string) for strings

### <a name='for'></a> for

Coming from TypeScript, there is no such thing as the array methods map, reduce
or filter in go. The for loop is all you have.

A for loop consists of the following:

- an **init** statement; condition expression; **post** statement

There is no need for **parenthesis** surrounding the three components. The init
and post statements are **optional**.

The for loop can also be used as while().

```go
var a = 10

for i := 0; i < a; i++ {
	a += i
}
```

### <a name='if-else'></a> if, else

If, else is pretty straight forward in go. No parenthesis are needing
surrounding the condition.

```go
var a = 10

if a > 9 {
	fmt.Println(a)
}
```

### <a name='switch'></a> switch

A switch in go only runs the selected case, not all cases that follow. The
default case is **optional**.

The break statement is provided automatically.

You can combine expressions in the same case by using comma separation.

```go
switch time.Now().Weekday() {
    case time.Saturday, time.Sunday:
        fmt.Println("It's the weekend")
    default:
        fmt.Println("It's a weekday")
}
```

### <a name='struct'></a> struct

A struct is a typed collection of fields. Structs are **mutable**.

```go
type server struct {
	host          string
	port          string
}
server{"localhost", "8080"}

type person struct {
	name string
	age int
}
person{name: "Marco", age: 29}
```

### <a name='arrays'></a> arrays

Arrays are numbered sequences of elements of a specific length.

The following creates a variable a as an array of 10 integers.

```go
var a [10]int
```

In go arrays can not be resized, because the length is part of the type.

The built-in **len** method returns the length of an array.

```go
var names [3]string{"Tim", "Mandy", "Stefanie"}
len(names) // 2
```

### <a name='slices'></a> slices

Unlike arrays, slices have no specified length, so they are dynamically sized.
They are build on arrays but are more powerful and therefore more used than
arrays in go.

To create **dynamically** sized arrays (slices), you can use the **make**
function.

```go
// slice of type in with length 5
a := make([]int, 5)

// slice of type string with length 3
s := make([]string, 3)
```

Slices can also be build by slicing an existing array or slice. In the following
example, a slice is formed on the numbers array by specifying two indices, a low
and high bound.

```go
// array
numbers := [5]int{1, 2, 3, 4, 5}

// slice of numbers array
specificNumbers := names[0:3]
```

Its also possible to create **slices of slices.**

```go
board := [][]string{
		[]string{"_", "_", "_"},
		[]string{"_", "_", "_"},
		[]string{"_", "_", "_"},
	}
```

To enhance a slice, you can use the **append** function. This is one example of
what makes slices more powerful than arrays. Append returns a slice with one or
more new values.

```go
var s []int

append(s, 1, 3, 4, 5)
```

Slices can also be **copied**.

```go
s := make([]string, 5)

s[0] = "H"
s[1] = "e"
s[2] = "l"
s[3] = "l"
s[4] = "o"

c := make([]string, 5)

copy(c, s)

```

<CoffeeHint />

### <a name='map'></a> map

A map is combination of key value pairs. In other languages it's often called
dictionary.

```go
// creates an empty map of string - int key - value pairs
m := make(map[string]int)

// sets an the key "age" with the value of 29
m["age"] = 29

// deletes an element of a map
delete(m, "age")
```

### <a name='range'></a> range

To iterate over a map or a slice you can use **range**.

It returns two values: index and a copy of the element at that index.

The index or value can be skipped by using `_`

```go
numbers := []int{1, 2, 3, 4, 5}

for i, num := range numbers {
	fmt.Printf(i, num)
}
```

### <a name='method'></a> method

A method is a function with a special **receiver argument**.

```go
type Server struct {
	host          string
	port          string
}

function (s Server) printServer() {
	fmt.Printf(s)
}
```

See that we pass the Server as s as a **receiver** argument to the `printServer`
function before we the function name declaration?

Everything inside the function body has now **access** to the members of the
struct.

### <a name='pointers'></a> pointers

Pointers hold the **memory address** of a value.

```go
i := 42

// generate a pointer to i
p = &i

// read i through the pointer p
fmt.Prinln(*p)
```

### <a name='pointer-receivers'></a> pointer receivers

Methods can be declared with pointer receivers.

The differences between pointer receivers and value receivers are:

- pointer receivers can modify the value to which the receiver points
- with pointer receivers you can avoid copying the value on each method call
- sending the value of the variable to the function, but not the variable itself
- the value of the variable isn’t passed to the function, just its location
- pointers are adresses to a particular place in memory

```go
type Server struct {
	host          string
	port          string
}

function (s *Server) printServer() {
	fmt.Printf(s)
}
```

Pointers and pointer receivers are little bit more **advanced topic** but it's
good to have heard of them as a beginner.

### <a name='interfaces'></a> interfaces

Interfaces are **named collections** of method signatures. To implement an
interface you just need to implement all methods in the interface.

```go
type interface {
	methodOne() int
	methodTwo() int
}

func methodOne() int {}

func methodTwo() int {}
```

### <a name='errors'></a> errors

A **nil** value in the error position indicates that there was no error.

```jsx
if err != nil {
	// log the error
}
```

Calling code should handle errors by **testing** whether the error equals nil.

And that is it, these are the **programming with go beginner topics** I came
across the last weeks and months while learning and working with go. I hope you
like it!

Did you know everything already or did you learn something new? Do you have
other great examples? Let me know!

You can send me an [email](mailto:marco@marcoheine.com) or message me on
[Twitter](https://twitter.com/marcoheine_com).

### Resources:

- [https://gobyexample.com/](https://gobyexample.com/)
- [https://blog.golang.org/slices-intro](https://blog.golang.org/slices-intro)


In this blog post I share all the things you need to know to get started with golang.

Getting started with golang


In part 1 of this react performance quick-wins series, we already learned about
the following:

- [Always use a key when mapping and no index](/blog/7-easy-ways-to-improve-your-react-performance-part-1/#keys)
- [Use React.Fragments instead of divs as parent element](/blog/7-easy-ways-to-improve-your-react-performance-part-1/#fragments)
- [One useState hook instead of multiple for connected data](/blog/7-easy-ways-to-improve-your-react-performance-part-1/#usestate)

The second part of this series brings you another **4 great quick-wins** you can
apply directly to your code and improve your performance

This Post is Part 2 of a series.

Part 1:
[7 easy ways to improve your React performance - part 1](/blog/7-easy-ways-to-improve-your-react-performance-part-1/)

**What you can learn from Part 2 of this React performance quick wins series:**

---

- [Avoid anonymous functions](#avoid-anonymous-funcs)
- [Define objects outside of your component](#defining-objects)
- [React.lazy and React.Suspense](#lazy-suspense)
- [Virtualized lists](#virtualized-lists)

---

## <a name='avoid-anonymous-funcs'></a>Avoid anonymous functions

It's easy to use an anonymous function when you want to add a quick callback
function to a component.

```jsx
import * as React from 'react'

const MyComponent = () => {
  return (
    <button onClick={() => console.log('Button clicked')}>Click me!</button>
  )
}

export default MyComponent
```

But if you're on the lookout for a quick performance win, that's something you
can avoid.

Anonymous functions aren't assigned an identifier like const/let/var. This means
they **are not persistent** whenever this functional component gets rendered
again. So JavaScript has to **create them again and again,** on every rerender.

> **To be clear:** for most cases this isn't a real problem! The react docs
> event state that
> [it's okay to use anonymous functions in render methods](https://reactjs.org/docs/faq-functions.html#is-it-ok-to-use-arrow-functions-in-render-methods).
> It becomes an actual problem if you're rendering a lot of elements, like
> thousands of table cells, which all make use of an anonymous function.

There is an easy way to solve this. You can change it to a **named function**
and move it outside of the component.

```jsx
import * as React from 'react'

const handleClick = () => {
  console.log('Button clicked')
}

const MyComponent = () => {
  return <button onClick={handleClick}>Click me!</button>
}

export default MyComponent
```

That's it for quick-win number 4: avoid anonymous functions!

## <a name='defining-objects'></a>Define objects outside of your component

Here comes quick-win number 5. Something similar as described above can be
applied to objects.

If you define an object as an object literal and pass it in as props, this
object will have to be recreated on every rerender.

```jsx
import * as React from 'react'

const MyComponent = () => {
  return (
    <div style={{ textAlign: 'center', fontSize: '14px' }}>
      This is the text of my component.
    </div>
  )
}

export default MyComponent
```

Instead, define your object outside of the component. Now it is created once on
the initial render and not being touched on every rerender.

```jsx
import * as React from 'react'

const DIV_STYLES = {
  fontSize: '14px',
  textAlign: 'center',
}

const MyComponent = () => {
  return <div style={DIV_STYLES}>This is the text of my component.</div>
}

export default MyComponent
```

Performance quick-win, whoop whoop! 🚀

<CoffeeHint />

## <a name='lazy-suspense'></a>React.lazy and React.Suspense

With `React.lazy`, you can "lazy load" your components. This means your
component is only rendered when it is truly needed and not loaded unnecessarily.

The less you need to load, the better your performance!

This can easily be combined with React.Suspense for rendering some fallback
content.

I wrote a whole Today-I-learned post about this topic; check it out here:
[Today I learned: React Suspense lazy-loading](/today-i-learned/react-suspense-lazy-loading/)

That's also a great way to improve your React performance without too much
effort.

## <a name='virtualized-lists'></a>Virtualized lists

If you've worked with long lists or tables with many rows in React, you know how
much this can impact your performance. This is because you have to render a lot
of content, usually many divs.

We already learned that too many DOM nodes are not a good idea. Also updates and
rerenders can be painful because they take just way too long.

With virtualized lists, only the list items that are actually in the viewport
are rendered. That's pretty cool. But how does this work? Don't worry; you won't
have to build this yourself. There are already excellent tools out there that do
the job for you.

Check out [react-virtualized](https://github.com/bvaughn/react-virtualized) by
Brian Vaughn.

It's pretty easy to use, and you don't need to worry about displaying long lists
and tables anymore.

So that's it; these are my **7 easy ways to improve your React performance**.
Did you already know all of them? Do you have any additional tips? Let me know!

Just send me an [email](mailto:@marcoheine.com) or message me on
[Twitter](https://twitter.com/marcoheine_com).


In part 2 of this series, we'll look at another four ways to improve your React performance.

🚀 React performance quick wins 🚀 - 7 easy ways to improve your React performance - part 2


At the beginning of the year I wrote a blog post about
[React performance improvements](/blog/react-performance-improvements/). It‘s
one of my favourite blog posts I ever wrote. It’s a great example of documenting
everything while you learn it.

It’s a very in depth analysis. It shows you how to **test and measure** the
performance of your React application and a lot of ways how to improve it. In
the contrary this blog post has the goal to give you a lot of **quick wins** for
your performance. Things you can change and adjust, without too much effort.

So you can see it as an **addition** to my original react performance blog post.
The first one builds the foundation. This one adds the cherry on top.

This post is **part 1** of a **series**.

Part 2: [7 easy ways to improve your React performance - part 2](/blog/7-easy-ways-to-improve-your-react-performance-part-2/)


**What you can learn from this blog post:**

---

- [Always use a key when mapping (and not index)](#keys)
- [Use React.Fragments instead of divs as parent element](#fragments)
- [One useState hook instead of multiple for connected data](#usestate)

---

### <a name='keys'></a> Always use a key when mapping (and not an index)

When mapping over an array and rendering a list of items, make sure you **always
use keys** for every item.

Keys help React identify which items have **changed, are added, or are
removed**. Keys should be strings that identify a list item, such as an ID.

Here is a quick example of the usage of keys. Check the return method of this
component. There we use the id of every animal as a key.

```javascript
import * as React from 'react'
import { AnimalCard } from './animal-card'

const animals = [
  {
    id: 1,
    name: 'dog',
  },
  {
    id: 2,
    name: 'cat',
  },
  {
    id: 3,
    name: 'unicorn',
  },
]

const Animals = () => {
  return animals.map((animal) => {
    return <AnimalCard key={animal.id}>{animal.name}</AnimalCard>
  })
}

export default Animals
```

If you're not using keys, React has to a hard time to figure out which items to
update. This can lead to updating every item although only one changed.

This can be a massive performance impact! 😫

If you don't have access to unique identifiers, indexes can be used as a last
resort. It is **not recommended** to use them as keys but it's better than not
using any keys at all.

If the order of items changes, the index changes as well so React has to update
every item anyway.

You can learn more about why keys are important in this
[article about reconciliation](https://reactjs.org/docs/reconciliation.html#recursing-on-children).

So that's it for quickwin number one: **always use a key when mapping!**

### <a name='fragments'></a> Use React.Fragments instead of divs as JSX parent element

Next up: quickwin number two.

When you return multiple elements from a component, JSX needs a parent element
to wrap them. A quick way to do this, is to put a `<div>` around them.

I admit it, I've done this too, way too many times.

```javascript
import * as React from 'react'

const MyComponent = () => {
  return (
    <div>
      <span>Hi!</span>
      <span>Hope you can learn a lot from my blog posts</span>
    </div>
  )
}

export default MyComponent
```

But the next time you need a JSX wrapping element, think again! You can use a
**React.Fragment** for that!

```javascript
import * as React from 'react'

const MyComponent = () => {
  return (
    <React.Fragment>
      <span>Hi!</span>
      <span>Hope you can learn a lot from my blog posts</span>
    </React.Fragment>
  )
}

export default MyComponent
```

And the best thing is, there is even a **short syntax** for this.

```javascript
import * as React from 'react'

const MyComponent = () => {
  return (
    <>
      <span>Hi!</span>
      <span>Hope you can learn a lot from my blog posts</span>
    </>
  )
}

export default MyComponent
```

But wait, why does this boost my performance? Good question! Here's the thing.
The more DOM elements your React application has, the **longer** the render
process takes.

Google's performance tool lighthouse recommends **not more than 1500 DOM nodes**
in total.

So by removing every unnecessary `div`, like the one we've used way too often as
a JSX parent element wrapper, we already get closer to that goal. And we can
boost our performance!

You can read more about why you should avoid too many DOM nodes in this article:
[https://web.dev/dom-size/](https://web.dev/dom-size/)

<CoffeeHint />

### <a name='usestate'></a> One useState hook instead of multiple for connected data

Another performance quickwin you can achieve easy, is using one `useState` hook
instead of multiple ones for connected data.

Imagine a developer built a form with several `input` elements. Therefore they
added four individual `useState` hooks.

That could look something like this:

```javascript
import * as React from 'react'

const MyBigForm = () => {
  const [username, setUsername] = React.useState('')
  const [email, setEmail] = React.useState('')
  const [password, setPassword] = React.useState('')
  const [nickname, setNickName] = React.useState('')

  const handleUserNameChange = (event) => {
    setUsername(event.target.value)
  }

  const handleEmailChange = (event) => {
    setEmail(event.target.value)
  }

  const handlePasswordChange = (event) => {
    setPassword(event.target.value)
  }

  const handleNicknameChange = (event) => {
    setNickName(event.target.value)
  }

  return (
    <form>
      <label>Username:</label>
      <input
        value={username}
        name="username"
        onChange={handleUserNameChange}
      />

      <label>Email:</label>
      <input
        value={email}
        name="email"
        onChange={handleEmailChange}
      />

      <label>Password:</label>
      <input
        value={password}
        name="password"
        onChange={handlePasswordChange}
      />

      <label>Nickname:</label>
      <input
        value={nickname}
        name="nickname"
        onChange={handleNicknameChange}
      />
    </form>
  )
}
```

There is a lot of `useState` and `onChange` going on here, right? Phew. We can
optimize for the better here!

By **removing** the individual `useState` hooks and implementing a combined one,
we're making sure to **reduce** the size of the component and therefore improve
the performance.

And we can also get rid of all the `handleChange` functions, which all seem to
do the same.

```javascript
import * as React from 'react'

const MyBigForm = () => {
  const [formdata, setFormdata] = React.useState({
    username: '',
    email: '',
    password: '',
    nickname: '',
  })

  const handleOnChange = (event) => {
    setFormdata({
      ...formData,
      [event.target.name]: event.target.value,
    })
  }

  return (
    <form>
      <label>Username:</label>
      <input
        value={username}
        name="username"
        onChange={handleOnChange}
      />

      <label>Email:</label>
      <input
        value={email}
        name="email"
        onChange={handleOnChange}
      />

      <label>Password:</label>
      <input
        value={password}
        name="password"
        onChange={handleOnChange}
      />

      <label>Nickname:</label>
      <input
        value={nickname}
        name="nickname"
        onChange={handleOnChange}
      />
    </form>
  )
}
```

Wow a lot less code and a lot more **readable**, don't you think? It's always a
good idea to keep your state in an object, if you're dealing with **connected
data**.

Don't get me wrong: using and calling multiple `useState` hooks is not a bad
thing! React has no problem with that.

But in this example it's also about **removing duplicate code** and
**rethinking** your components.

And if JavaScript has to allocate the memory for only one function instead of
four, that's also a **performance quickwin**! And that's what we're here for,
right?

That's it for **part 1** of this **React performance quickwins series**! Hope
you could already apply some of them and make your React app even faster.

Let me know if these tips helped or you have other tips, you'd like to share.

Just send me an [email](mailto:marco@marcoheine.com) or message me on
[Twitter](https://twitter.com/marcoheine_com).


In part 1 of this series, we'll look some easy way to improve your React performance.

🚀 React performance quick wins 🚀 - 7 easy ways to improve your React performance - part 1


<a
  href="https://unsplash.com/@lilschk"
  target="_blank"
  rel="noopener noreferrer"
>
  Picture by Lili Kovac
</a>

![a person looking at the horizon](/images/lili-kovac-IMpmnH2IC98-unsplash.webp)

I was in a comfortable position at a previous job. I was working as a frontend
developer and after two years in this job, I knew my way around. I knew about
every feature our product contained. I knew the code. I could tell which
component was responsible for what.

I knew where most of the questions at me where headed before someone finished
them asking. This felt like home. This felt like the absolute **comfort zone**.

---

**What you can learn from this blog post:**

- [What is imposter syndrome](#definition)
- [Why you feel like an imposter](#why)
- [Why you aren't an imposter](#why-not)
- [Overcoming imposter syndrome](#overcoming)
  - [Set yourself realistic goals](#realistic-goals)
  - [Keep track of your accomplishments](#track-accomplishments)
  - [Don't compare yourself to others](#dont-compare)
  - [Your teammates and colleagues may feel the same](#teammates)
  - [Ask for Feedback](#feedback)
  - [Even the experts in our industry feel this way](#experts)

---

After switching jobs imposter syndrome hit me hard. At first I felt like a
**fraud**. Everything was new to me. The code, the tools, the workflow, the
people, the team. I felt like I had to relearn everything. And like I did not
know anything at all.

I always thought that sooner or later somebody would come to me and say: "You
know, we've watched you long enough and now you've been caught. You don't know
anything about software developing." _handcuffs click._

Did you ask yourself questions like **am I good enough**? Do you often have
thoughts like do I know enough to be a good developer? Can I help make this
product better? My skills are way to bad. **I should quit. I know nothing**.

This kind of thoughts are bad and not helpful at all you could say. But still a
lot of people have them.

Chances are you've felt the same at some point in your career. Chances are you
will feel like that everytime you start a new job. This all sounds very
negative. But the good news is: **you are not alone**!

A colleague of mine once told me that they should take two weeks off to learn a
specific technology. Because they feel like they "know nothing about it". And
they are developers, I **learn the most of** and look up to. In my eyes they
know their stuff pretty well.

If anything of this above sounds familiar to you, let me tell you about the
imposter syndrome.

### <a name="definition"></a> What is imposter syndrome?

[Wikipedia](https://en.wikipedia.org/wiki/Impostor_syndrome) gives a very good
definition of imposter syndrome:

> _Impostor syndrome (also known as impostor phenomenon, impostorism, fraud
> syndrome or the impostor experience) is a psychological pattern in which an
> individual doubts their accomplishments or talents and has a persistent
> internalized fear of being exposed as a "fraud"._

If this sounds familiar to you, chances are you also feel like you **do not
deserve** certain things. You think your achievements are not you own and your
success is attributed to **luck**.

For some people it gets even worse. Often **anxiety, stress or depression** go
along side with imposter syndrome.

### <a name="why"></a> Why you feel like an imposter

So the questions is why do we feel this way? What **causes** imposter syndrome?
It does not sound like something that could benefit our work, our life or
anything between. It sounds harmful and could also hold as back.

A lot of developers are **self taught**. Often they suffer from imposter
syndrome because they do not have a CS degree. And this is still required by a
lot of companies. Thus they think, they are not "real" developers, if they
haven't learned their stuff at a university.

Another reason why we feel this way is that the web industry is one of the
**fastest changing industries**. Every week or so this new technology gets
popular. A new JavaScript framework will replace the most popular one right now
and you need to know about it and have learned about it yesterday. Which is
obviously not possible.

So we get the feeling we need no know everything but we can't. And we don't
accept the obvious reasons, we think we as developers, as humans are the
problem.

There is always something new to learn in this industry. This is on the one hand
a really nice thing and motivates me but but it's hard to stay on top.

Every programming task you do at work is like a small challenge. If you succeed
everything is fine. But if you don't find a solution right away you question
yourself. You **question your knowledge** and if you've even **capable** of this
job.

We compare ourselves to others. This new kid just joined the company and already
build this super complex feature. Because they are programming since they are 12
years old. I will never be as good as them. Sounds familiar?

### <a name="why-not"></a> Why you aren't an imposter

Let's take a quick break and a deep breath.

Let me tell you that you took the first step. We analyzed the problem and we saw
the situation for what it really is. There are a lot of ways to grow out of it
and change. From here on the positive takes over.

**You are not an imposter** because you do not need a CS degree to be a good
developer. It can help in some ways but the knowledge to be a good developer is
not only trapped inside a CS degree.

**You are not an imposter** because take a look. See how far you've come. What
you've achieved in your past, all you've done. Even if you're a beginner
remember all the things you've learned so far, even the smallest.

My incredibly talented wife draw this beautiful picture about this topic.

[![Look how far you've come artwork](/images/Untitled_Artwork.png)](https://www.instagram.com/p/CEwsVgKizRo/)

<a
  href="https://www.instagram.com/p/CEwsVgKizRo/"
  rel="noopener noreferrer"
  target="_blank"
>
  (@findingthelittlethings\_)
</a>

I take a look at it as often as I can because it's always a **good reminder**.

**You are not an imposter** because you've got the job right? You convinced
someone to hire you as a developer. That's a big achievement you can't fake.

**You are not an imposter** because remember this one little crazy bug you
solved which seemed like "a hell no we will never solve this bug at all". But
you did.

**You are not an imposter** because you don't know everything. And that's
totally fine. **You can't know everything**. And even if you could, that would
be really boring, right? One of the greatest things in life is that there is
always something new to learn.

### <a name="overcoming"></a> Overcoming imposter syndrome

Now as we have set the clear picture why you are not an imposter, here are more
tips on how to deal with imposter syndrome and eventually **overcome** it.

<CoffeeHint />

#### <a name="realistic-goals"></a> Set yourself realistic goals

Set yourself some realistic goals! Telling yourself that in three weeks you will
know the entire codebase by heart is an impossible goal. Rather set up smaller
goals which are **clear** and **measurable**.

#### <a name="track-accomplishments"></a> Keep track of your accomplishments

Write down everything you achieved. Even the smallest things. Everytime you
struggle, you doubt yourself, take a look at that list. Be proud of what you've
learned and achieved. This helps a lot.

#### <a name="dont-compare"></a> Don't compare yourself to others

Comparing yourself to others is never a good idea. It always leaves you feel bad
about yourself. You don't know the history of others, how they learn and how
they think. Everyone is different and has their own strengths and weaknesses.

The next time you compare yourself to the new team member, who already seems to
know everything - stop right there. Be happy for the new colleague because they
settled so quickly.

Than **compare yourself to you** from last week or last month. There are
definitely things you've learned, features you built and bugs you crushed.

#### <a name="teammates"></a> Your teammates and colleagues may feel the same

Talk to your colleagues about it. Chances are they feel exactly they same as you
do. Help to build a culture in your company where it's easy and desired to share
knowledge. Where you help each other and not knowing everything is considered
normal. Do more pair programming and knowledge sharing sessions.

Learn to be brave and answer questions with: "I don't know an answer to your
question right away. I need to think about it first." I know this seems very
hard, but in the end everyone benefits from that.

Finally be aware of the fact that the work and achievements as a team is, what
counts.

#### <a name="feedback"></a> Ask for Feedback

If you're feeling like an imposter remember that the only person you get
feedback from right now is yourself. To stop this cycle and get a more realistic
view of what is really happening, don't hesitate to ask your teammates and
colleagues for feedback! They can give you valuable answers on how you're really
doing and where you can improve.

#### <a name="experts"></a> Even the experts in our industry feel this way

When I came across [this blog post](https://davidwalsh.name/impostor-syndrome)
by David Walsh, I was astonished. He writes a lot of blog posts about the
JavaScript ecosystems. He worked for Mozilla for over 8 years. Developers go to
his blog to get help, read his tutorials and learn stuff. And even he feels this
way. This shows a whole new perspective. Take your time and head over there to
read this. I'll wait here.

And than you'll see that you're absolutely not alone feeling like this. You're
fine.

### Conclusion

Dealing with imposter syndrome can be hard and your are not alone in this. The
first step is to realize that you suffer from it. From there on you can grow
into a more healthy relationship with yourself. There are a lot of tools you can
use to cope and deal with imposter syndrome.

I hope I could explain this topic a little better and you can use my tips to
overcome imposter syndrome.

Did you ever suffer from imposter syndrome? Do you know friends who feel that
way? Make sure to send them this blog post and let me know what you think about
this topic.


A lot of people suffer from imposter syndrome, myself including. In this blog post I'm gonna talk about what it is and how to overcome it.

How to overcome imposter syndrome


If you would ask me about two good reasons why I like to work with **React** -
and use it primarily when doing frontend development - it would really make me
think.

When I first started to work with React I didn't have a real choice. I started
working at a job where there was no question if we should use
[Angular](https://angular.io/), [Vue](https://vuejs.org/) or
[Svelte](https://svelte.dev/) or anything else.

No, it was already defined that React would be the weapon of choice and there
was already written a lot of code in React. I was just thrown into this React
hole and never had the chance to crawl back out. End of story.

![a gif of two men walking, one falls into a hole](https://media.giphy.com/media/O2zL3TVRhZuGk/giphy.gif)

No not really. Of course not. It's true that I had no choice back then but I
never stopped thinking about how we would build this feature or solve that
problem without React or with VanillaJS or even without any JavaScript at all!

If you google "Reasons to use React" you get a lot clever points and different
opinions. I even read about advantages of React I never heard about before. I
really have to get into this
[Concurrent Mode stuff](https://reactjs.org/docs/concurrent-mode-intro.html).

Anyway, after this research my list of reasons grew bigger and bigger but I
noticed despite all this points being true and reasonable arguments there was no
real point where I could put my heart into.

So I set all the lists and research stuff aside, closed all the tabs and really
started thinking.

![a gif of two girls, sitting on a desk, where one throws all the papers off the desk](https://media.giphy.com/media/B23grX5C9g9sKNt9Xk/giphy.gif)

And this is what I came up with:

### Reason one: popularity

Don't get me wrong. I don't like React because so many cool people use it and if
they would switch to the next cool thing I would switch too.

When we talk about the web development world one big thing you always hear is:
"have you heard about this new JS framework?". In our field everything is moving
so **fast** and everything changes really **quickly**.

But if you take a closer look, you will notice that React is here since
**2013**. That's like **VERY OLD** in this web thingy. It's the one JS framework
with the most GitHub stars (146k in March, 2020) and is used by 3,3 million
people, [according to GitHub](https://github.com/facebook/react).

To translate this: I don't like React because it's so popular in general or it
is so "old". I like it because of all the **perks** these two points bring with
them.

Due to these facts React has a **massive community** behind it. There is always
an active and (in most cases) constructive discussion on Twitter about new
features and problems where you can get help from and learn a lot.

There are super great subreddits like
[/r/reactjs](https://www.reddit.com/r/reactjs) where every news about React is
being discussed, people present cool tools they built with React and if you need
help, people will take a look at your problem and suggest solutions.

There are so much great tutorials, blog articles, video courses and podcasts on
React which teach you everything about it.

A lot people may have had the same problem or bug as you and there are already
bulletproof solutions available. People help each other whenever they can, which
makes the journey to get better in React a lot of fun.

And finally: React has one of the best
[Docs](https://reactjs.org/docs/getting-started.html) I've ever used which gets
better and better everyday.

### Reason two: it's just a view library

React is not a full framework. Instead it focuses on the **view layer,** on
building user interfaces and on building what the user interacts with and what
helps him, accomplish several tasks.

For me, this meant that I did not have that steep of a **learning curve** and it
was very **straightforward** to use. Because the great thing is: if you know
**JavaScript** you're good to go! And that is something, which I think, is
really cool.

React comes into action when you have a static website and want to switch to a
website where the focus is on the user interactions and updates of the user
interface.

You just want to build a view that **reacts** on the user input and is clever
enough to only **update** what should be updated. It enables you to take that
step without shipping you overly complex extra stuff you don't need. That's why
React is your best bet and why I like it so much.

Of course at some point you may need additional tools, which are not included in
React by default - like routing or other state management solutions. But in most
cases you won't need these and you're good to go with what you get from the
beginning.

So that's it, these are my two good reasons to use React. What are yours? Hit me
up on [Twitter](https://twitter.com/marcoheine-com) or send me an
[email](mailto:marco@marcoheine.com).


Two good reasons to use React


In this blog post I'm going to introduce several tipps and tricks to boost the
**performance** of a React application.

I learned a ton while improving the performance of a large and complex web
application recently and wanted to share everything so others don't have to
search all over the internet for this useful and important information.

---

**What you can learn from this blog post:**

- [Where to start](#where-to-start)
  - [Chrome DevTools Lighthouse Audit](#lighthouse-audit)
  - [webpagetest](#webpagetest)
- [The Biggest Problems](#the-biggest-problems)
  - [Time to Interactive (TTI)](#time-to-interactive)
- [And how to solve them](#how-to-solve-them)
  - [Removing DOM nodes](#removing-dom-nodes)
  - [lazy-loading images](#lazy-loading-images)
  - [code-coverage](#code-coverage)
  - [code-splitting](#code-splitting)
  - [React Profiler](#react-profiler)
  - [Chrome Performance Analyzer](#chrome-performance-analyzer)
  - [Bundle-Analyzer](#bundle-analyzer)
- [Conclusion](#conclusion)
- [Sources](#sources)

---

## <a name="where-to-start"></a> Where to start

If you notice that your React App is **slow** or takes a long time to load, you
have a few options to verify that and get an insight into where the biggest
problems are.

### <a name="lighthouse-audit"></a> Chrome DevTools Lighthouse Audit

First of all you can measure your performance score with the **Chrome Lighthouse
Audit** which is available in the Chrome DevTools.

You can choose between measuring the performance on mobile or desktop. If you
just want to get your performance score, you can check off the other audits,
like Progressive Web App or SEO.

![a screenshot of the chrome lighthouse audit settings](/images/chrome-lighthouse-audit-settings.jpeg)

You should also activate **throtteling**, because not everyone is on the newest
MacBook Pro with 64GB of RAM and i9 processor while browsing on a 5G network. I
usually use Applied Slow 4G, 4x CPU Slowdown.

After the audit is finished, you get a nice **overview** over the scores, the
metrics and how they are calculated. You also get opportunities and diagnostics
which can tell you why your app is slow and how to solve common problems.

![a screenshot of the chrome lighthouse audit results](/images/chrome-lighthouse-audit.jpeg)

### <a name="webpagetest"></a> webpagetest

Another tool to verify the perfomance of your React application is
[webpagetest.org](https://webpagetest.org). After you enter a URL and start the
test, it returns a test result and grades specific parts of your application. It
is also pretty useful in finding problems and ways to improve the performance.

## <a name="the-biggest-problems"></a> The Biggest Problems

### <a name="time-to-interactive"></a> Time to Interactive (TTI)

In case of React applications where a lot of JavaScript is involved, often the
**time to interactive** identifies itself as the biggest problem. TTI means how
long it takes a page to become **interactive**.

The TTI gets slowed down by a few things. The ones which are directly related to
a lot of JavaScript code and therefore React are:

- too much main-thread work
- an excessive DOM size
- too much JavaScript execution time

To summarize this: When a user navigates to your page and can not click around
for a few seconds, because your JavaScript is not fully parsed, compiled and
executed, this is **bad**.

Especially when you are using server side rendering where the user already can
see your page but not interact with it yet.

<CoffeeHint />

This all happens because your browser has to execute too much JavaScript at
once, because certain scripts are blocking, because you just want to do too much
at once in your code.

Uff. This sounds a little exausting. We need solutions. Let's tackle the
problems one by one.

## <a name="how-to-solve-them"></a> And how to solve them

### <a name="removing-dom-nodes"></a> Removing DOM Nodes

Perhaps the easiest step to improve the performance of your react application is
to **reduce** the amout of DOM Nodes. If you hide a lot of your components with
CSS, check if you can render them **conditionally** instead.

This decreases the size of the DOM which means less components need to be
rendered, which means less JavaScript needs to be executed.

This will especially be helpful, when you have a long list of items, render all
of them, but show only the first 5 initially. Robin Wieruch has a
[great article](https://www.robinwieruch.de/conditional-rendering-react) on
conditional rendering in React.

### <a name="lazy-loading-images"></a> lazy-loading images

If you load twenty images initially, which are located at the bottom of your
page, meaning the user can't see them at first glance, this is a lot of wasted
time and potential.

Instead you can detect when the user gets closer to the images and then render
them. Because that's the point where you actually need them. The npm package
[react-lazyload](https://www.npmjs.com/package/react-lazyload) makes this
surpringsingly easy.

This results in executing less JavaScript code but it also solves another very
common problem: too many **http requests**.

So its a good idea in general to only render and show the code the user needs to
interact with your React app initially, instead of just rendering everything.

### <a name="code-coverage"></a> code-coverage

Chrome offers the opportunity to detect **unused** code in your application.

The code coverage tab is located in the Chrome DevTools. You can find it in the
command menu when you type _coverage_.

It can track a whole reload of your application and is still tracking and
updating the code coverage when you're interacting with your application.

![a screenshot of the chrome coverage tool](/images/coverage.jpeg)

This is another super easy quick win, which can help you to improve your
performance by removing **unused code**.

### <a name="code-splitting"></a> code-splitting

In a large and complex react application code-splitting is possibly one of the
best ways to improve your performance.

The idea of code-splitting is to split your code in ways it is needed in your
application and therefore render only the code which is needed for the **current
UI**.

Imagine having a Landingpage and a page where you show some articles, let's call
it blog. Does the blog need to download and execute code which is only needed on
the Landingpage? No!

So you can use clever tools, who are capable of detecting where your code is
actually needed and split it up. That's code-splitting.

One of these clever tools is **React.lazy**. You can read and learn more about
it in the
[React docs code splitting section](https://reactjs.org/docs/code-splitting.html#reactlazy).
Please note that React.lazy is not available for server-side-rendering.
Code-splitting in a server rendered app can be achieved with
[Loadable Components](https://loadable-components.com/docs/server-side-rendering/).

### <a name="react-profiler"></a> React Profiler

The
[React Profiler](https://reactjs.org/blog/2018/09/10/introducing-the-react-profiler.html)
is another useful tool to gain more insight about what your React app is doing
and why. It is part of the React Browser Plugin and can be located in the
DevTools.

When you **profile** your app it collects timing information about each
component that is rendered. It also shows how long a specific component took to
render, if it needed to be updated and so on.

So you can either see if a component took way to long to render or identify
unecessary rerenders. Both are ways which can help you to identify performance
bottlenecks.

### <a name="chrome-performance-analyzer"></a> Chrome Performance Analyzer

Another way to collect information about your performance is the Chrome
Performance Analyzer. It's also located in the Chrome DevTools and lets you
record the load performance of your app. This is the place where you analyze
your loading time in to the deepest. It just has so many options.

Take your time to read through the
[documentation of this performance evaluation tool](https://developers.google.com/web/tools/chrome-devtools/evaluate-performance/reference).

It makes sense to spent more time to fully understand what this tool is capable
of. It can totally help you boost your performance because it shows you
everything that's happening with your JavaScript.

### <a name="bundle-analyzer"></a> Bundle-Analyzer

The
[Webpack Bundle Analyzer](https://www.npmjs.com/package/webpack-bundle-analyzer)
is a npm package which "visualizes the size of webpack output files with an
interactive zoomable treemap". To use this package your application has to use
webpack for the bundling of course.

This Analyzer is such a great tool. It shows you exactly what files you give out
to your users, how big they are and also which files should absolutely not be in
your bundle.

In case of the large and complex web app I was working on, by using this
analyzer we realized that some packages where depending on the whole `lodash`
library which is a lot to include in to your bundle if you actually just need
one functionality of it.

## <a name="conclusion"></a> Conclusion

All these steps are great and helpful ways to find out why your React
application is slow and how to change that. You don't have to implement all of
them, maybe already one of them will help you speed up things. I hope you could
learn something here and if you know more ways to boost the performance let me
know!

## <a name="sources"></a> Sources:

- [https://developers.google.com/web/tools/lighthouse](https://developers.google.com/web/tools/lighthouse)
- [https://developers.google.com/web/tools/lighthouse/audits/time-to-interactive](https://developers.google.com/web/tools/lighthouse/audits/time-to-interactive)
- [https://www.robinwieruch.de/conditional-rendering-react](https://www.robinwieruch.de/conditional-rendering-react)
- [https://www.npmjs.com/package/react-lazyload](https://www.npmjs.com/package/react-lazyload)
- [https://reactjs.org/docs/code-splitting.html](https://reactjs.org/docs/code-splitting.html)
- [https://www.freecodecamp.org/news/taming-performance-in-todays-web-app-with-lighthouse-webpack-and-react-loadable-components-b2d3fa04e0ab/](https://www.freecodecamp.org/news/taming-performance-in-todays-web-app-with-lighthouse-webpack-and-react-loadable-components-b2d3fa04e0ab/)
- [https://reactjs.org/docs/optimizing-performance.html](https://reactjs.org/docs/optimizing-performance.html)


React Performance Improvements


In June of 2018 I started learning and working with [React](https://reactjs.org/). In this blog post I will share some things I learned in the beginning and came across or find worth noting.

I would be very happy if other beginners can learn something or find a place to start their React learning journey right here.

**Please note:** In web development a lot of things change really quickly, especially in the JavaScript and React scene. So it can be possible that some information in here is not that relevant anymore. But it was as of the time when my React learning journey started.

---

- [How does React work?](#how-does-react-work)
- [What is JSX?](#jsx)
- [React Components](#react-components)
- [What are Props?](#props)
- [What is State?](#state)
- [How does conditional rendering work in React?](#conditional-rendering)
- [How are events handled in React?](#events)
- [Controlled Components vs Uncontrolled Components](#controlled-vs-uncontrolled)
- [What are default props?](#defaults-props)
- [What are PropTypes?](#proptypes)
- [React Context](#context)
- [What are children?](#children)
- [What are higher-order-components](#hoc)
- [What is Redux?](#redux)

---

### <a name="how-does-react-work"></a> How does React work?

With React you can build **interactive** user interfaces, which get easily updated when the data changes. Dealing with data changes and DOM manipulation can be slow and unnecessary.

In React for every DOM object there is a **virtual** DOM object (like a lightweight copy). So React creates a virtual DOM. When state changes in a component it firstly runs a _"diffing"_ algorithm, which identifies what has changed in the virtual DOM. The second step is reconcilitation, where it updates the DOM with the results of diff.

- When a JSX element is rendered, every virtual DOM element is **updated**.
- React then compares the virtual DOM with a **snapshot** that was taken right before the update.
- By doing this, React figures out exactly which virtual DOM objects have **changed** (diffing)
- Then React **updates** only thos real DOM objects that have changed.

### <a name="jsx"></a> What is JSX?

JSX is a **syntax extension** for JavaScript and was written to be used in React to describe what the UI should look like. It is **not valid** JavaScript, Web browsers can't read it. It needs to be **compiled** (with Babel). Every HTML in a JavaScript file is called a JSX element.
JSX elements are like JS expressions, they can be:

- saved in a variable
- passed into a function
- stored in an array or an object

They can have attributes like HTML elements, they can be nested (if they take up more than one line they must be wrapped in paranthesis) andthey must have at least one outermost element. In JSX HTML class get replaced by className. JS in JSX in JS is possible by wrapping content in `{...}`

### <a name="react-components"></a> React Components

A React component is a small, **resuable** chunk of code, responsible for **one job** (e.g. render some HTML). The name of a component hast to start with a capital letter.

Components render other components (like a page renders a nav bar). To use a component from another file you need to import the file. You can also pass information to a component.

There are several ways to define a component. One is to use a JavaScript Function, another one is to use an ES6 class.

### <a name="props"></a> What are Props?

Props (short for properties) are a way of passing **data/information** from the parent to the child. Props are for **static** data and you can access the props with this.props. It is possible to declare default Props (for the case that no props are available).

A Component can not change their props. Props do not have to just be data. Callback functions my be passed in as props.

### <a name="state"></a> What is State?

State is data which is **changing over time**. State is reserved for **interactivity** and is **private** and fully controlled by a component. State can be updated asynchronously. A parent component can pass its state **down** to a child as props. As soon as the state changes a **rerender** is triggered.

### <a name="conditional-rendering"></a> How does conditional rendering in React work?

Conditional rendering in React works the same way as ins Vanilla JavaScript, so it is possible to use JS operators to create elements representing the current state and let React update the UI to match them. This means you can render only some items depending of the state of your application.

### <a name="events"></a> How are events handled in React?

To handle events in React, you have to add an event listener to an element. (difference to HTML: must be in lowerCamelCase e.g. onClick instead of onclick)

Event listeners are provided when the element is initially rendered, so there is no need to call `addEventListener`. The event listener gets passed in an event handler as props. Naming convention: start with handle, e.g. handleClick.

### <a name="controlled-vs-uncontrolled"></a> Controlled Components vs Uncontrolled Components

An input element whos value is controlled by React is called a **controlled component**. In HTML forms maintain their **own** state and update it based on user input. In React, mutable state is kept in the state property of the component.

These two combined make React the "single source of truth". Then the React component that renders a form also **controls** what happens in that form on subsequent user input, so you write an event handler for every state update.

The alternative to controlled components are **uncontrolled components**, where form data is handled by the DOM itself.

### <a name="default-props"></a> What are defaultProps?

It is possible to define **default values** for component props. They are defined as a **property** on the component.

This is useful when you don't get certain data, which you normally pass in props. Then you can fallback to the props, which you defined as the default.

### <a name="proptypes"></a> What are PropTypes?

With PropTypes you can check the **type** of a prop on a component. This means you can say you only accept a prop, when it has the type of a string. You can also flag props as **required** and set defaults as described above.

### <a name="context"></a> What is context?

Context provides a way to **share data** between components without having to pass props down manually at every level. This means, Context lets you pass a value deep into the component tree without explicitly threading it through every component.

But keep in mind, that Context should not be used only to avoid **props drilling**. The best use case for it is when a lot of components need to access the same prop.

Context ist defined with `React.createContext`. You have to use a **Provider** to pass the current context to the tree below. Then you have to use a **Consumer** to read the current context, React will find the closest Provider and use its value.

### <a name=""></a> What are children?

You can use children on components that represent generic boxes and don't know their children ahead of time. It is used to display whatever you include between the opening and closing tags when invoking a component.

### <a name="hoc"></a> What are higher-order-components?

A higher-order component is a **function** that takes a component and **returns** a **new component**. It is also a wrapper for the old component. It is not part of the React API per se.

### <a name="redux"></a> What is Redux?

Redux is an **advanced** topic and not part of React. It is an **additional** library which comes in handy for problems, React does not solve properly for some developers.

Redux give you a **global state container**, the store. So you have one global state for your whole application and every component can access and update it by using **actions** and **reducers**.

You can trigger an action inside of your component. The reducer always **listen** for specific actions and then talk to the **store** and return the updated state.

### Sources & Further Reading

React has one of the best documentations I have ever used. I regularly head over to there, to fresh up my knowledge. It is written very well and has a lot of useful examples in it.

- [The official React Docs](https://reactjs.org/docs/getting-started.html)


React - my learning journey


[CSS Grid Course Website by Wes Bos](https://cssgrid.io/)

![a screenshot of the css grid course website by wes bos](/images/css-grid-course-screenshot.webp)

I really liked the [JavaScript30](https://javascript30.com/) course by
[Wes Bos](https://twitter.com/wesbos), where you get to code 30 different
projects with plain JavaScript. Now he published another course which is also
available for free. This time it's all about learning
[CSS Grid](https://cssgrid.io/). In this blog post, I will document everything I
learned about CSS Grid in the course.

---

**What you can learn from this blog post:**

- [General setup and basics of CSS Grid Development](#setup)
- [Implicit vs. explicit Grid](#implicit-vs-explicit)
- [Grid-auto-flow](#grid-auto-flow)
- [Sizing tracks](#sizing-tracks)
- [Repeat function](#repeat-function)
- [Sizing Grid items](#sizing-grid-items)
- [Placing Grid items](#placing-grid-items)
- [auto-fit and auto-fill](#auto-fit-auto-fill)
- [Using minmax() for responsive grids](#minmax)
- [Grid template areas](#template-areas)
- [Naming lines in CSS Grid](#naming-lines)
- [Grid-auto-flow dense block fitting](#block-fitting)
- [CSS Grid alignment + centering](#alignment-and-centering)
- [Re-ordering Grid items](#re-ordering)
- [Real-world examples](#real-world-examples)

---

## <a name="setup"></a>General setup and basics of CSS Grid development

In the first few videos, Wes talks about the **tooling setup** for the course.
He uses [browsersync](https://browsersync.io/) for the local development which
is an npm package that automatically updates your browsers once you change the
HTML, CSS, images, or other project files.

It is such a great tool I couldn't work without, and that is why browsersync has
had its safe spot in my build tool setup with gulp for a long time.

Wes also talks about the basics of CSS Grid development with the **firefox
developer tools**. The basic principle reminds me of flexbox. You always have a
parent where you set `display: grid` and define the settings for columns, rows,
and the gap between them.

Child elements inside this parent can be positioned separately. The firefox dev
tools have a special layout window included where you can highlight the grid
View and also show the numbers of the grid cells, which is extremely helpful
when developing CSS Grid.

## <a name="implicit-vs-explicit"></a> Implicit vs. explicit Grid

The difference between explicit and implicit grid tracks is simple. When you
explicitly define grid columns with `grid-template-columns: 100px 100px` you get
**explicit** grid tracks.

If the browser notices that there is not enough space for all your items he
automatically creates a second row.

So these tracks are called **implicit** because the browser creates them and not
explicitly you.

The same applies if you have four items and define two rows. If you now add two
more items, the browser implicitly creates a new row. With `grid-auto-rows` and
`grid-auto-columns`, you can style any implicitely created row or column.

<CodePen
  id="rJoXxY"
  title="CSS Grid - Implicit vs. Explicit Tracks"
/>

## <a name="grid-auto-flow"></a> Grid-auto-flow

If you have two items, define two columns using
`grid-template-columns: 200px 400px` and then add a third item, the browser will
put this item automatically in a new row below like, described before, with
implicit tracks.

This means `grid-auto-flow` is set to row by default. If you set `grid-auto-row`
to `column`, the third item will be automatically put into a new column next to
the other items.

<CodePen
  id="wyNjJK"
  title="CSS Grid - grid-auto-flow"
/>

## <a name="sizing-tracks"></a> Sizing tracks

The `fr` unit represents the amount of space left after all elements are laid
out.

If you define three columns with `grid-template-columns: 200px 200px 1fr`, the
first two columns will be 200px wide, and the last one will take up all the
space that is left.

`fr` stands for **fractional unit**, but Wes likes to call it free space which
helps with remembering the idea of the fr unit.

It is also possible to use the auto keyword. Then an item will be sized
according to the content it contains.

<CodePen
  id="ddaKbb"
  title="CSS Grid - sizing tracks"
/>

## <a name="repeat-function"></a> Repeat function

Instead of writing:

```css
grid-template-columns: 1fr 1fr 1fr 1fr;
```

you can simply use the CSS Grid repeat function and write:

```css
grid-template-columns: repeat(4, 1fr);
```

<CodePen
  id="vdbVeX"
  title="CSS Grid - repeat function"
/>

## <a name="sizing-grid-items"></a> Sizing Grid Items

By default, grid items just flow one after another, and as there is space for
each one, they will fit themselves into the grid as they can.

There is also a way to more precisely size grid items inside a parent grid
container. The instruction `grid-column: span 2` tells the browser to size the
specific child element with the space and width of two columns. The same goes
for `grid-row: span 2`.

<CodePen
  id="zWOYge"
  title="CSS Grid - sizing grid items"
/>

## <a name="placing-grid-items"></a> Placing Grid Items

There are also better ways to position grid items than just sizing them. With
`grid-column-start` and `grid-column-end` you can define where a grid item
should start and where it should end. There is also a shortcut property for this
so with `grid-column: 2 / 5`, the grid item starts with the second column and
ends before the fifth.

You can also define that the grid item should start at the first column and span
over two columns with `grid-column: 1 / span 2`.

If you want your grid item to start at the first column and span over the last,
but you don't know how many columns you have, just use `grid-column: 1 / -1`.

<CodePen
  id="BrByaZ"
  title="CSS Grid - Placing Grid Items"
/>

The second CodePen example below shows all the different ways to place grid
items inside a grid container. Have a look into the CSS to check how it is done.

<CodePen
  id="oqvjOv"
  title="CSS Grid - Spanning and Placing Cardio"
/>

## <a name="auto-fit-auto-fill"></a> auto-fit and auto-fill

With the `auto-fill` expression inside the `grid-template-columns` declaration
you can tell the browser, "hmm, I'm not sure how many columns I want, make each
150px wide, for example, and then fill it with as many columns as possible".

So `grid-template-columns: repeat(auto-fill, 150px);` does that.

The difference between `auto-fill` and `auto-fit` is visible when you have not
enough items to fill the grid.

With `auto-fill` the grid will create as many columns as possible, although you
don't have enough items. So if you have four items and there is space for six,
the explicit grid ends after six items. In comparison to that, `auto-fit` ends
the grid when all available items are placed inside your grid.

In the CodePen example below, open the firefox dev tools, enable the grid view
in the layout window, and you will see the difference between `auto-fit` and
`auto-fill`.

<CodePen
  id="BrayPm"
  title="CSS Grid - auto-fill & auto-fit"
/>

## <a name="minmax"></a> Using minmax for responsive grids

With `minmax()`, you can tell the browser to make the items in a column a
minimum width of `150px` and a maximum width of `1fr`, for example. So the items
will automatically adapt to the available space.

This is also a great way to create a responsive grid without media queries.

When the grid items already have the minimum width declared with `minmax()` and
the browser window gets smaller; they will automatically jump into the next row.

The CodePen example below also shows the difference between `auto-fit` and
`auto-fill` in combination with `minmax()`.

<CodePen
  id="jzOPzg"
  title="CSS Grid - Using minmax() for Responsive Layouts"
/>

## <a name="template-areas"></a> Grid template areas

Grid Template areas come in handy for building a whole layout of a page. Say you
want to have two sidebars left and right and a content place between them. Below
you want to have the footer spanning over the whole row.

With grid template areas, you can type your grid parent into the
`grid-template-areas` instruction exactly how you want the layout to look.

On the grid items, meaning the child items of the parent, you then tell each
item with `grid-area` which part of the layout it should be. That's it! Simple
and easy full-page layout.

The firefox dev tools also offer the possibility to display your grid area names
so you can quickly check if your layout is displayed as you wish it to be.

<CodePen
  id="GxRjdW"
  title="CSS Grid - Grid Template Areas"
/>

## <a name="naming-lines"></a> Naming lines in CSS Grid

By default, you declare to span your grid items over the columns and rows by
using the line names 1,2,3, and so on. CSS Grid also offers the possibility to
rename your line names on the `grid-template-columns` and `grid-template-rows`
declaration on the parent.

So if your initial declaration for the columns and the rows on the grid
container is like this:

```css
grid-template-columns: 1fr 500px 1fr;
grid-template-rows: repeat(10, auto);
```

and you want to span an item inside the middle column from the top to the tenth
line you would say:

```css
grid-column: 2;
grid-row: 2/10;
```

By renaming your columns and rows, you can now position your item inside this
grid using the new line names.

```css
grid-template-columns: [site-left] 1fr [content-start] 500px [content-end] 1fr [site-right];
grid-template-rows: [content-top] repeat(10, auto) [content-bottom];
```

<CodePen
  id="mxdQQN"
  title="CSS Grid - Naming Lines in CSS Grid"
/>

## <a name="block-fitting"></a> Grid-auto-flow dense block fitting

Grid-auto-flow is, by default, set to row, so every item that does not fit in
the same row will automatically be put into a new row below. This can be helpful
but also not really useful in a lot of cases.

If you have a grid with ten columns and you want every sixth item to span over
six columns, there will be a lot of empty space because the six-column-long item
often can't fit in the same row and is put into the next row via
`grid-auto-flow: row` and the space left over is not filled with other items.

In this case, the dense value comes to help.
[MDN](https://developer.mozilla.org/en-US/docs/Web/CSS/grid-auto-flow) describes
this value as follows:

> "Dense is a keyword specifying that the auto-placement algorithm uses a
> 'dense' packing algorithm, which attempts to fill in holes earlier in the
> grid, if smaller items come up later. This may cause items to appear
> out-of-order, when doing so would fill in holes left by larger items".

Go ahead and turn the `grid-auto-flow: dense` instruction on and off in the
CodePen example below to see the difference.

<CodePen
  id="wmMKxY"
  title="CSS Grid - grid-auto-flow block formatting"
/>

## <a name="alignment-and-centering"></a> CSS Grid alignment + centering

Flexbox made centering items on a page really easy. CSS Grid also has its ways
to center items without problems.

There are two main properties that can be used for that. `justify-_` defines
everything on the row axis, and `align-_` defines everything on the column axis.

With `justify-items` and `align-items`, you can define the alignment for your
grid items on the grid container. There is also a shorthand called `place-items`
which you can give two values, the first for the justify-_ property and the
second for the align-_ property.

If your grid items don't fill up your whole grid, you can use `justify-content`
and `align-content` to align them as one inside your grid container.

Finally, with `justify-self` and `align-self`, you can overwrite the alignment
settings on the container and specify them on a single grid item.

<CodePen
  id="GxoqOy"
  title="CSS Grid - Alignment and Centering"
/>

## <a name="re-ordering"></a> Re-ordering Grid items

Imagine having a ten-column wide grid with a logo on the left that spans over
two columns, a nav on the right that spans over eight columns, and a full-width
content below.

It is possible to change the order of the logo and the nav easily so that the
logo will be on the right and the nav on the left.

By default, every item has a value of 0 on the order property. So giving the nav
`order: 0`, the logo `order: 1`, and the content `order: 3` will achieve the
re-ordering.

It is important to mention that this technique will goof up the order a screen
reader will read it, so it is kind of bad practice concerning accessibility if
you use this on a bunch of paragraphs, for example. But for a nav and a logo, it
does not matter that much.

<CodePen
  id="GxojJY"
  title="CSS Grid - Re-ordering Grid items"
/>

## Real World Examples <a name="real-world-examples"></a>

### <a name="album-layouts"></a> Nesting Grid with album layouts

In this example, you can see several album info boxes consisting of an image and
a few details about the album. To achieve this layout, you have to define the
columns on the main grid first, which contains every album info box.

With the following expression, you can define a grid that has columns with a
minimum width of `400px` and a maximum width of `1fr`.

```css
grid-template-columns: repeat(minmax(400px, 1fr));
```

So depending on the available space, the Grid will add columns or remove columns
and shrink or expand them accordingly, which creates a fully flexible and
responsive layout without media queries.

To achieve the layout inside the album info boxes, it is important to know that
grid items can also be grid containers, as we know from flexbox already.

So you can add two columns into every album info box so the album image has a
width of `150px` and the text takes all the remaining space. Vertical alignment
is also possible.

```css
display: grid;
align-items: center;
grid-template-columns: 150px 1fr;
```

<CodePen
  id="jzqXVo"
  title="CSS Grid - Nesting grid with album layouts"
/>

### <a name="css-grid-image-gallery"></a> CSS Grid image gallery

The next example is about building an image gallery with CSS Grid. The basic
grid for this consists of repeating columns and rows that are 100px wide and
high. This example is extended with a little bit of JavaScript to give each
image a different width and height.

Therefore you have to make an array with a length of 50. `Array.from` is pretty
useful in this case. Every Item of this array is an array itself consisting of
two random numbers between 1 and 4. These two values will describe the
horizontal and vertical length of the image.

For every item of the digits array, you then have to build the HTML, which
consists of the image, an overlay, and a close button. By using ES6
destructuring, you can insert the randomly generated numbers for the horizontal
and vertical values and use them as CSS class names.

By doing that, you will get 50 different images in the grid with a random row
and column-span between 1 and 4. Using the dense value on the `grid-auto-flow`
property, you can avoid having too many empty spots in between.

Another useful thing I learned here is that by setting two grid items in the
same row and column, they will overlap. Very practical for adding overlay
elements.

### <a name="flexbox-vs-grid"></a> Flexbox vs. CSS Grid

In general, CSS Grid can do everything Flexbox can do. Some people say that
Flexbox is for laying out elements in one dimension, and CSS Grid is for laying
out elements in two dimensions.

In this example, Wes shows how things solved previously with flexbox can be done
with CSS Grid and in what scenarios Flexbox is still the winner. You can find
all the examples in the CodePen below.

<CodePen
  id="wmoVjp"
  title="CSS Grid - Flexbox vs. CSS Grid"
/>

### <a name="recreating-codepen"></a> Recreating CodePen

In this example, you are recreating CodePen, the tool I have used to display all
the examples before. CodePen is a development environment that allows you to
write code in the browser and see the results immediately.

This example is good practice for learning to layout different sections of a
page with CSS Grid. Basically, it is all about grids inside other grids.

<CodePen
  id="MVmwpZ"
  title="CSS Grid - Recreating CodePen"
/>

### <a name="bootstrappy-grid"></a> Bootstrappy Grid with CSS variables

Bootstrap became very popular for implementing an easy way to use a responsive
grid on a website. It implemented CSS classes for the orientation of your
elements, how they should behave on different viewports, and how far they would
span in your grid.

So a div with the class of `col-sm-4` would span over four columns on a viewport
equal to or greater than 768px wide.

In this example Wes shows how to achieve the Bootstrap principle with CSS Grid.

<CodePen
  id="RMVPdj"
  title="CSS Grid - Bootstrappy Grid with CSS Variables"
/>

### <a name="responsive-website"></a> Responsive Website

In this example, Wes shows how to build a **whole responsive** website with
**CSS Grid**. He divides the page into several sections and then uses almost
every technique of CSS Grid learned in the course to lay out the page.

Another thing Wes teaches here, and I liked, is the usage of aria attributes on
buttons. So Instead of adding and removing a CSS class on the button, you can
simply check the aria attributes value of the button and also use the aria
attributes value for styling.

In this example, the button to open the navigation menu has the aria attribute
`aria-expanded="false"` which indicates by default that the menu is not
expanded.

Additionally, it has the aria attribute `aria-controls="menu-list"` which
indicates that the button controls the element with the class of menu-list which
is, in this case, the navigation.

By changing the values of these attributes with JavaScript, you can toggle the
menu easily.

<CodePen
  id="LdyMJa"
  title="CSS Grid - Responsive Website"
/>

### <a name="blog-layout"></a> Full bleed blog layout

The last example is about building a blog layout with sections of different
width and elements.

<CodePen
  id="eMWwQd"
  title="CSS Grid - Full bleed blog layout"
/>

## Sources & further reading

- [The CSS Grid course by Wes Bos](https://cssgrid.io/)
- [A complete guide for CSS Grid by Chris Coyier](https://css-tricks.com/snippets/css/complete-guide-grid/)
- [CSS Grid Layout by the Mozilla Developer Network](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Grid_Layout)
- [A collection of examples, videos, and other information to learn CSS Grid by Rachel Andrew](https://gridbyexample.com/)
- [Auto-Sizing Columns in CSS Grid: 'auto-fill' vs. 'auto-fit' by Sara Soueidan](https://css-tricks.com/auto-sizing-columns-css-grid-auto-fill-vs-auto-fit/)
- [Layout Land, a YouTube Channel by Jen Simmons all about CSS Grid](https://www.youtube.com/channel/UC7TizprGknbDalbHplROtag)


CSS Grid changed the way how we can build modern website layouts. In this blog post, I will recap everything I've learned about it.

Learning CSS Grid


In this blog post I answered the **HTML Questions** from the Frontend Developer Interview Questions. This is a GitHub repo which contains helpful lists of frontend related questions to test yourself or extend your knowledge.

---

1. [What does a DOCTYPE do?](#doctype)
2. [How do you serve a page with content in multiple languages?](#lng)
3. [What kind of things must you be wary of when design or developing for multilingual sites?](#multilingual)
4. [What are data- attributes good for?](#data-attributes)
5. [Consider HTML5 as an open web platform. What are the building blocks of HTML5?](#html5)
6. [Describe the difference between a cookie, sessionStorage and localStorage](#storage)
7. [Describe the difference between script, script async and script defer](#scripts)
8. [Why is it generally a good idea to position CSS links between head and JS scripts just before the body ends? Do you know any exceptions?](#link-and-script-positioning)
9. [Why you would use a srcset attribute in an image tag? Explain the process the browser uses when evaluating the content of this attribute.](#srcset)

---

### <a name="doctype"></a> What does a DOCTYPE do?

The doctype makes sure the document gets parsed the same way by different browsers. It prevents the browser from switching into ["quirks-mode"](https://developer.mozilla.org/en-US/docs/Web/HTML/Quirks_Mode_and_Standards_Mode) when rendering a document.

### <a name="lng"></a>How do you serve a page with content in multiple languages?

By using the lang attribute on the html element `lang="en"`.

### <a name="multilingual"></a>What kind of things must you be wary of when design or developing for multilingual sites?

You have to enable an easy way for users to change their language. There is also the possibility that people from different countries need different content.

### <a name="data-attributes"></a>What are data- attributes good for?

`data-` attributes ca be used to store extra information on standard, semantic HTML elements without using non-standard attributes.

### <a name="html5"></a>Consider HTML5 as an open web platform. What are the building blocks of HTML5?

MDN lists several groups which form the building blocks of HTML5 and contain many different technologies:

- **Semantics:** allowing you to describe more precisely what your content is
- **Connectivity:** allowing you to communicate with the server in new and innovative ways
- **Offline and storage:** allowing webpages to store data on the client-side locally and operate offline more efficiently
- **Multimedia:** making video and audio first-class citizens in the Open Web
- **2D/3D graphics and effects:** allowing much more diverse range of presentation options
- **Performance and Integration:** providing greater speed optimization and better usage of computer hardware
- **Device access:** allowing for the usage of various input and output devices
- **Styling:** letting authors write more sophisticated themes

### <a name="storage"></a>Describe the difference between a cookie, sessionStorage and localStorage.

When using a **Cookie**, data is sent to the server and is primarly for server-side reading (but can also be read on the client side). The size must be less than 4KB.

When using **sessionStorage**, the data is stored in the browser and can only be read on the clientside. The stored data is only available for one session, so when the browser tab gets closed, the data gets deleted. The storage limit is larger than a Cookie (at least 5MB).

When using **localStorage**, the data gets also stored in the browser and can only be read on the clientside. But it has no expiration date and the storage limit is the maximum of the three.

### <a name="scripts"></a>Describe the difference between script, script async and script defer.

The regular `script` tag is used to embed or reference executable code and is typically used to embed or refer to JavaScript code. When the browser comes during the HTML parsing by a script tag it stops the rendering and executes the JavaScript tag.

Using the script async tag will not block the rendering, but will run the script as soon as it is downloaded and available.

The script defer tag will defer the script and run it after the page is done parsing.

### <a name="link-and-script-positioning"></a> Why is it generally a good idea to position CSS links between head and JS scripts just before the body ends? Do you know any exceptions?

The CSS link has to be positioned in the head so it is downloaded and the styling is available as fast as possible. If the css link is positioned inside the body it is possible that the page is displayed without CSS for a short periode of time. This is called FOUC (Flash of unstyled content).

It is also a good idea to put the JS script before the closing body tag. If you put the JS script tag in the head or before the actual HTML content in the body, the browser will stop the rendering and first download all the JS.

So it could be the case that the web page is only half visible for a short periode of time because the rendering is blocked to download the JavaScript first.

### <a name="srcset"></a> Why you would use a srcset attribute in an image tag? Explain the process the browser uses when evaluating the content of this attribute.

The `srcset` attribute is used to provide the same image in different versions, depending on the viewport. So you can display the image with different width and quality for mobile and different width and quality for desktop.

With the srcset attribute you will allow the browser to choose between, and what size each image is. First you have to insert the file name, a space followed by the image's inherent width in pixels.

The additional attribute sizes adds a set of media queries and tells the browser what image size to choose when certain conditions are true. The sizes attribute contains the media condition (max-width: 680px), a space, followed by the width of the slot the image will fill when the media condition is true.

### Sources & Further Reading

- [Definition of the DOCTYPE in the HTML specification](https://html.spec.whatwg.org/multipage/syntax.html#the-doctype)
- [The HTML lang attritube](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/lang)
- [The data- attribute](https://developer.mozilla.org/en-US/docs/Learn/HTML/Howto/Use_data_attributes)
- [The building blocks of HTML5](https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/HTML5)
- [Cookies vs. sessionStorage vs. localStorage](https://stackoverflow.com/questions/19867599/what-is-the-difference-between-localstorage-sessionstorage-session-and-cookies)
- [The Script element](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script)
- [Render-blocking CSS](https://developers.google.com/web/fundamentals/performance/critical-rendering-path/render-blocking-css)
- [Optimize CSS Delivery](https://developers.google.com/speed/docs/insights/OptimizeCSSDelivery)
- [Responsive images](https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images)


Frontend Developer Interview Questions HTML


I just started the [JavaScript30 Challenge](https://javascript30.com/) by
[Wes Bos](https://twitter.com/wesbos) where you get to code **30 different
projects** and ideas with **plain JavaScript**.

No frameworks - no compilers - no libraries - no boilerplates.

The idea of JavaScript30 is either to code along as this is a video series or to
build it by yourself and compare it with Wes' solution at the end.

I think this is a great idea if you are like me, lacking of ideas for JS
projects, want to learn ES6 and level up your JS skills in general. The perfect
challenge for your daily dose of JavaScript.

To learn to most from it, I coded along or tried to solve it at my own and put
all of it on **CodePen**. You can check it out
[here](https://codepen.io/collection/DapjRG).

If you also like to take the JavaScript30 challenge there you go:
[https://javascript30.com/](https://javascript30.com/)

It's free so enjoy it, have fun and don't forget to thank Wes Bos! You can also
find a list of other peoples experiences and solutions on the GitHub repo:
[https://github.com/wesbos/JavaScript30](https://github.com/wesbos/JavaScript30)


JavaScript30


There are a lot of great blogs, newsletters, tools, websites out there about
Fronted Development. In this blog post I'd like to present you my favorite
**frontend links and bookmarks** which I'm using daily or at least weekly.

I won't categorize them, so this will not be a list of my favorite blogs only,
for example, or my favorite github projects. It will be more like the best
link-list (for me personally) of every category. Also the list itself will not
be in any ranking, I'll just present them to you in a random order.

You'll also be able to find my Frontend Bookmarks on
[GitHub](https://github.com/marcoheine-com/frontend-bookmarks), so please feel
free to make **suggestions** to this list with your own favorite bookmarks and
links. One goal of this blog post will be to get my own list growing as I'm
always looking forward to find new blogs or newsletters about Frontend
Development. Enough with the introduction, let's take a look at my Frontend
Bookmarks.

---

1. [Mozilla Developer Network](#mdn)
2. [CanIUse](#caniuse)
3. [PageSpeedInsights](#pagespeed-insights)
4. [CodePen](#codepen)
5. [GitHub](#github)
6. [CSS-Tricks](#css-tricks)
7. [Smashing Magazine](#smashing-magazine)
8. [Reddit JavaScript & Learn JavaScript](#reddit)
9. [Newsletters](#newsletters)
10. [Conclusion](#conclusion)

---

### <a name="mdn"></a> Mozilla Developer Network

The [Mozilla Developer Network](https://developer.mozilla.org/en-US/) is my
number one visited website currently. It's my central station. It's not only the
biggest and best up to date **documentation** about **web technologies**, it
also offers awesome **articles** and **guides** to learn more about HTML, CSS,
JavaScript, DOM, Web APIs and many more.

I just use it for everything. I use it to look up CSS properties, learn more
about how certain JavaScript methods work and to find out what attributes belong
to a specific HTML element.

If I google a specific frontend problem I usually start with "mdn ..." because
I've always found a solution there. Mozilla recently started the
[Learning web development](https://developer.mozilla.org/en-US/Learn) section
which "aims to provide complete beginners to web development with all they need
to start coding simple websites".

So if you get stuck anywhere, MDN always explains a solution, if you want to
learn more about CSS Layout, HTML audio and video or anything similar, MDN is
the place to go.

My **favorite article** on **MDN** is
[A re-introduction to JavaScript](https://developer.mozilla.org/en-US/docs/Web/JavaScript/A_re-introduction_to_JavaScript).
If you're new to JavaScript or want to re-learn or look up the core concepts, I
highly recommend this article.

### <a name="caniuse"></a> CanIUse

Do your ask yourself daily "Oh I want to use this new CSS property or this HTML
element, but does it work already in Internet Explorer, Opera or in any Android
Browser?" If you've answered yes, I have a solution for you. The website
[caniuse.com](http://caniuse.com/) does this job for you.

You just have to browse there, type in a property or element and CanIUse
provides you up-to-date **browser support tables** for support of front-end web
technologies on desktop and mobile web browsers.

It's also separated by the different versions of every browser, shows the
current published version, browser usage and specific notes, known issues and
resources. So it's not only showing you, which browser supports what, it is also
telling you, why one browser doesn't support this specific CSS property yet.

Great tool I don't want to miss! There is also a CanIUse Node.js module which
let's you look up browser support from the command line.
[David Walsh](https://twitter.com/davidwalshblog) wrote a small
[blog post](https://davidwalsh.name/caniuse-command-line) about it.

### <a name="pagespeed-insights"></a> PageSpeed Insights

**PageSpeedInsights** is a great tool I already mentioned and explained in my
[Website Performance Optimization blog post](https://marcoheine.com/blog/website-performance-optimization/)
so I won't talk that much about it here and just give a brief summary.

You just enter the URL of the website you'd like to test and PageSpeedInsights
loads the page on a small screen and on a big screen, analyzes **what's good and
what's bad** on the website and additionally gives very useful advice on how to
do better.

As I said I've explained this in depth in my blog post so I'd suggest you head
over there if you're interested in learning more about PageSpeedInsights.

### <a name="codepen"></a> CodePen

[CodePen](http://codepen.io/) quotes itself as a "Playground for the front end
web" and I think this describes it perfectly. In short, it's a **code editor in
the browser**. You can quickly write HTML, CSS and JavaScript there and
immediately see the output.

It even got a console recently so it's now also possible to debug JavaScript. I
often use it to quickly try out new HTML, CSS features or **prototype something
really quickly** because this is its biggest advantage: It's fast and you get
the result immediately.

It gets new features and updates recently so you can not only play around with
simple HTML, CSS and JavaScript, you can also use HTML Preprocessors like Haml
or Markdown, CSS Preprocessors like Sass, integrate Normalize.css, add external
CSS, add popular JS libraries like jQuery or add external JS.

Another great thing I love about CodePen is its **collaborative thinking**. You
can share or work together on a "Pen" very easy, you can integrate a "Pen" into
your website like I did on this
[blog post](https://marcoheine.com/blog/new-css-layout/) and you can browse Pens
of others to get inspired or learn something new. I love to browse on CodePen
daily and see everyday the impressive and amazing work of other developers.

### <a name="github"></a> GitHub

I think I don't have to write that much about [GitHub](https://github.com/)
here, it's a very well known service and I guess every developer used it once or
at least heard of it. I think one of the best ways to learn to code is to look
at and inspect other peoples code and that's what I love about GitHub.

You get the possibility to **browse the code of your favorite libraries**,
technologies and tools and get an insight of how these people build their
software. The other great opportunity GitHub features is, of course, OSS.

Everybody is encouraged to contribute to famous projects. I have to admit that I
did not dare to contribute a PR so far, but it's definitely a big thing on my to
do list. I also really like the GitHub
[explore section](https://github.com/explore) where you can find and browse new
projects.

### <a name="css-tricks"></a> CSS-Tricks

I guess I know about [CSS-Tricks](https://css-tricks.com/) since I made my first
real steps in web development back when I did my bachelors degree. Originally
its articles contained **real CSS tricks** but this changed so now it covers
tricks for almost every section in web development! I really like CSS-Tricks for
their **great articles and tutorials**. They are also the creators of
[CodePen](http://codepen.io/).

One of my favorite articles on CSS-Tricks is
[Front End Development is Development](https://css-tricks.com/front-end-development-is-development/)
by Geoff Graham where he explains why some people argue that Front End
Development should not be considered "real development" and why this is just
wrong. It's a great summary of all the aspects a Frontend Developer has to deal
with and it clearly shows that we are "real" developers.

Another article, which I think is really one of the best on CSS-Tricks, was
recently published by Chris Coyier and is called
[A Front End Developer is Aware](https://css-tricks.com/front-end-developer-aware/).
It just starts off, where the other article stopped and explains the position of
a Frontend Developer and why we have to be aware of everything.

"In a general sense, the front end developer is positioned in the middle of lots
of other jobs. Everybody involved in a web team ends up talking with the front
end developers. That makes sense. The front end developers create the actual
thing people interact with. Everything comes together with the front end
developer.

Perhaps that's why it's such a fun job! Because the front end developer is this
central hub position and dealing with lots of different people doing lots of
different jobs, the job can be done better if they are aware. Aware of
everything else that makes a website tick."

I really recommend reading this article and again that's exactly what I like so
much about CSS-Tricks.

### <a name="smashing-magazine"></a> Smashing Magazine

When I wanted to discover more web development resources,
[Smashing-Magazine](https://www.smashingmagazine.com/) wasn't really hard to
find. It's one of the **biggest** and **most important blogs** about frontend
development and in my opinion it's a place where the best and most researched
articles are published.

Compared to other blogs its articles are not short posts or tutorials - they
usually dig a lot **deeper** and explain further contexts. Next to their well
researched articles Smashing Mag also publishes the
[Smashing Book](https://www.smashingmagazine.com/printed-books/smashing-book-5/).

The latest published book, Smashing Book 5, is about "Real-Life Responsive Web
Design" and I highly recommend it. It covers various topics concerning
Responsive Web Design like Responsive Workflow, Design Patterns and Components,
SVG, Flexbox, Testing and Debugging and many more.

On top of that, Smashing Mag organizes a great series of **conferences**: the
[Smashing Conference](http://smashingconf.com/). I wasn't able to attend one so
far but it's definitely on my to do list.

### <a name="reddit"></a> Reddit JavaScript & Learn JavaScript

Of Course you have heard of **reddit**, the "front page of the internet". I use
a lot of subreddits and for that reason I really like the
[JavaScript](https://www.reddit.com/r/javascript/) and
[Learn JavaScript](https://www.reddit.com/r/LearnJavaScript) subreddits.

I try to check them out daily because you'll always find interesting **links,
projects or tools** there or learn something new. Additionally a lot of people
present their projects there attached to some problems they would like to
overcome and it's really fun to read these stories and help them trying to
figure out a solution.

So the JavaScript and Learn JavaScript Reddit pages are great places to get your
**daily dose of JavaScript**. If you're interested in more JavaScript links,
especially focused on learning I'd like to point you to my
[JavaScript learning resources](https://github.com/marcoheine-com/javascript-learning-resources)
GitHub repository at this point. I think it's a great collection of resources
I've used and am using right now to dig deeper into JavaScript.

### <a name="newsletter"></a> Newsletter

Besides online documentation, blogs or tools for frontend development I'm a big
fan of **newsletters**. I really like the idea that someone sends me an awesome
list weekly, where he or she carefully collected the best and most informative
links of the week about any frontend development topic.

Sometimes I already got across the most links but this doesn't matter, mostly
there is always something **new to learn** and **discover**. So far I'm
regularly reading the following three newsletters:

[JavaScript Weekly](http://javascriptweekly.com/) which is obviously all about
JavaScript, [Frontend Focus](http://html5weekly.com/), formerly HTML5 weekly,
which is more like a web platform technology roundup and last but not least the
[Web Development Reading List](https://wdrl.info/). This one is also published
on the Smashing Magazine website.

What I really like about this newsletter is, that's it is seperated in different
sections like concept & design, tools & workflows, privacy, javascript, css/sass
and many more.

### <a name="conclusion"></a> Conclusion

So this is it - these are my **favorite frontend bookmarks**, as I explained at
the beginning: in a complete random order and without categorization. It's not a
big list and I definitely want it to **grow**!

So if you've got any link to a blog, tool, newsletter, project etc. concerning
frontend development, I'd love to check it out and add it to my collection. Feel
free to drop me an email or directly contribute on
[GitHub](https://github.com/marcoheine-com/frontend-bookmarks).


Frontend Bookmarks


I haven't been working for such a long time in the Web and I would definitely
call me a Junior Developer. Though I remember times where I built Websites with
table Layout. It was for several university projects.

I looked back into the code and noticed that I was using a little position
absolute & relative here and there but built the main layout of the page with
tables. Yikes!

---

**What you can learn from this blog post:**

- [Introduction – My Journey with CSS Layout](#introduction)
- [Flexbox – what's that?](#flexbox-whats-that)
- [Flexbox – don't use it for everything](#flexbox-dont-use-it-for-everything)
- [CSS Grid Layout](#css-grid-layout)
- [Conclusion](#conclusion)

---

### <a name="introduction"></a>Introduction - My Journey with CSS Layout

I guess I never heard of semantics these days. All I cared about was, that it
worked. Somehow. After that I also learned about positioning with floats. But it
never felt right for me. I managed to use kind of a combination of floats,
display properties and absolute/relative positioning.

But CSS layout felt always strange for me, I never got behind the real concepts
of it. It always felt like one big hack. This all changed when I first heard
about Flexbox.

### <a name="flexbox-whats-that"></a>Flexbox - what's that?

When I first learned about Flexbox, I was astonished.

I can position two elements next two each other, without the need of clearing
floats?

I can position an element wherever I want it to be and even change the flowing
directions or what happens, when the window shrinks?

I can center elements both, horizontally AND vertically?

Okay, wow. So much cool stuff that was possible now without any weird feeling
fix or hack to make it work.

Flexbox stands for Flexible Box and the main concepts consists of different
properties which allow it to arrange elements on a page such that they behave
predictably when the page layout shrinks, grows or changes in another way due to
different screen sizes or display devices.

You can read more about the concept behind Flexbox on the
[MDN Documentation](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Flexible_Box_Layout/Using_CSS_flexible_boxes).
Sure it took its time until Flexbox got wide browser support but now it's up to
94% of global browser support. For comparison browser-radius only got 90% global
support.

To gain more attention for Flexbox, a lot of smart people made tools to help
others learn the main concepts of Flexbox really fast. My favorite two are
Flexbox [Froggy](http://flexboxfroggy.com/) and
[Flexbox Defense](http://www.flexboxdefense.com/). The first one lets you use
the different Flexbox properties to guide Frogs to their lilypads. The second
one uses Flexbox to position Towers all over a game court and destroy the
incoming enemies with the help of these towsers.

If you haven't tried them out yet, don't hesitate to do it now! If you are not
into Gamification there is also a
[great video](https://egghead.io/lessons/misc-flexbox-fundamentals) by Joe
Maddalone for egghead where he explains all Flexbox properties in ten minutes.

I also tried to contribute to the Flexbox learning movement. I made a small
Flexbox playground where you can see all the Flexbox properties in action. You
can switch between the different properties and immediately see their impacts
and changes on the page layout.

[Flexbox Playground on CodePen](https://codepen.io/Mkuehb/pen/KzrqBY)

I won't get into all the Flexbox properties in this blog post, there are other
great resources which explain all about Flexbox very well, like the Complete
Guide to Flexbox by Chris Coyier on
[CSS-Tricks](https://css-tricks.com/snippets/css/a-guide-to-flexbox/). This
guide explains every Flexbox property in depth and covers every single thing you
need to know to work with Flexbox.

### <a name="flexbox-dont-use-it-for-everything"></a>Flexbox - don't use it for everything

For the first time working on a CSS Layout feels right for me, thanks a lot to
Flexbox. It's great to make simple layouts for small, responsive websites. I
also used it in most cases on my own website. But it also has its pitfalls and
weaknesses. Therefore it's kinda hard to use Flexbox to built complex website
layouts.

Of course it's possible and I've seen a lot of tutorials showing you how to
build a mulitcolumn or a holy-grail layout with flexbox. But it's not meant for
that. [Jake Archibald](https://twitter.com/jaffathecake) explains why Flexbox
shouldn't be used for page layout in this
[blog post](https://jakearchibald.com/2014/dont-use-flexbox-for-page-layout/).
The best use cases for Flexbox are laying out small interface components like
form elements, the links in a menu, everything that's in a single dimension, in
a row or a column.

"But you were so happy and confident about this new CSS layout method and now
you say I should not use it for my overall page layout? I'm confused now!"

Sorry for that but there is another technology that will satisfy all of your
needs, soon. It's called CSS Grid Layout.

### <a name="css-grid-layout"></a>CSS Grid Layout

While Flexbox has been designed to layout individual components and their chunks
of content, CSS Grid Layout is perfectly for overall page layout.

"CSS Grid Layout (aka "Grid"), is a two-dimensional grid-based layout system
that aims to do nothing less than completely change the way we design grid-based
user interfaces." says Chris House in this amazing
[complete guide to grid](https://css-tricks.com/snippets/css/complete-guide-grid/).

The big problem: global browser support is now at
[8.1%](http://caniuse.com/#search=grid). It's currently a
[W3C Working Draft](https://www.w3.org/TR/css-grid-1/) and it's only usable with
the experimental flag enabled in google chrome. But it will be only a matter of
time until CSS Grid will redefine the way we layout websites with CSS.

[CSS Grid Layout on CodePen](https://codepen.io/Mkuehb/pen/EKrNMp)

I won't get any deeper into all the properties of the CSS Grid Layout. There are
some awesome guides out there, which will explain anything you need to know like
the one from CSS-Tricks I mentioned before.

Another great person you will definitely come across when dealing with CSS Grid
is
[Rachel Andrew](https://twitter.com/rachelandrew?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor).
She held some great talks about CSS Grid Layout and works hard to teach people
more about this new technology everday and gain more support for it.

She is also the author and owner of
[gridbyexample.com](https://gridbyexample.com/) where she explains everything
that exists about CSS Grid Layout. It's one big collection of links to articles,
videos and code examples so if you're willing to learn more about this topic,
this is the right place to start.

### <a name="conclusion"></a> Conclusion

I think CSS Grid Layout is great and in combination with Flexbox it seems to
change the way how we create our layouts with CSS completely. After a long
journey with techniques that weren't originally ment for page layout like tables
and floats – which felt (for me personally) always like hacking and trying to
fix it somehow so it works and breaks nothing – a new layout method has emerged
and I'm really looking forward to it. I hope till the end of 2016 it will be
ready to be used in production so we can establish finally a CSS layout method
which is absolutely meant for this job.

### Sources & Further Reading

- [Complete Guide to CSS](https://css-tricks.com/snippets/css/complete-guide-grid/)
  Grid via CSS-Tricks
- [Collection of usage examples for the CSS Grid Layout](http://gridbyexample.com/)
  via Rachel Andrew
- [Making Sense of the New CSS Layout](https://rachelandrew.co.uk/archives/2016/03/25/making-sense-of-the-new-css-layout/)
  via Rachel Andrew – Talk at Fluent Conf
- [The New CSS Layout](http://www.thedotpost.com/2015/12/rachel-andrew-the-new-css-layout)
  via Rachel Andrew – Talk at dotCSS 2015
- [Grid, Flexbox, Box Alignment: Our new System for Layout](https://24ways.org/2015/grid-flexbox-box-alignment-our-new-system-for-layout/)
  via Rachel Andrew
- [An Introduction to the CSS Grid Layout Module](http://www.sitepoint.com/introduction-css-grid-layout-module/)
  via Ahmad Ajmi
- [Deep Dive into Grid Layout Placement](http://blogs.igalia.com/mrego/2016/02/01/deep-dive-into-grid-layout-placement/)
  via Manuel Rego Casasnovas
- [Should I use Grid or Flexbox?](https://rachelandrew.co.uk/archives/2016/03/30/should-i-use-grid-or-flexbox/)
  via Rachel Andrew


New CSS Layout with CSS Grid & Flexbox


Nowadays Websites need to load **fast** to compete and meet user expectations.

If I google something, open up a suggested result and this website doesn't load
in a few seconds I'm immediatly closing it and keep looking for another result.

That sounds harsh and arrogant but that's what I got used to over the last
years.

---

**Table of Contents:**

- [Why Performance Matters](#why-performance-matters)
- [Where to start](#where-to-start)
- [Minify CSS/JS Files](#minify-css/js)
- [Compress Images](#compress-images)
- [Reduce HTTP Requests](#reduce-http-requests)
- [Additional Advice](#additional-advice)
- [Sources/Further Reading](#sources/further-reading)

---

### <a name="why-performance-matters"></a>Why Performance Matters

I don't want to wait up until 4 or 5 seconds for the website to load. I want to
see my results immediatly and if that's not going to happen I'm looking further
even if that website I just closed would have had the perfect answer to my
google search query.

This is why Website Performance and Speed matters to me and why I'm trying to
improve these aspects on every website I'm working on. But am I the only one,
used to this behaviour, not wanting to wait longer than a few seconds for a
website to load?

Luke Wroblewski gathered some
[interesting facts](http://www.lukew.com/ff/entry.asp?1553) about this topic.
The most interesting fact in my opinion is, that:

> _"If a page load takes more than two seconds, 40% are likely to abandon that
> site"_

You can find the sources to all facts on the link above. His Conclusion is that
"speed matters online" and "even 100 millisecond delays in load times negatively
impact user experience and conversions".

A recent example shows that Website Performance/Speed can make a huge
difference. After a "reboot"
[GQ cut the webpage load time by 80%](http://digiday.com/publishers/gq-com-cut-page-load-time-80-percent/).
The reasons for very slow loading times in the first place where mainly a lot of
calls to the server for ad tags, features and additionally the GQ website was
published on multiple CMS.

So they reduced their calls to the server by 400%, migrated to a single CMS,
decluttered the entire website and cut the page load time by 80%, so now it
loads in under two seconds.

**Note:** I'm not saying, that I'm already an expert in optimizing performance
and page speed and because of that I'm gathering a few methods here to learn
even more about these topics for myself.

### <a name="where-to-start"></a>Where to start

While I'm working on a project or if I want to test a website which I find
interesting, the first thing I usually do is heading over to
[Googles PageSpeed Insights](https://developers.google.com/speed/pagespeed/insights/).
With this tool you can test your website twice for efficiency: on mobile and on
desktop.

PageSpeed Insights captures the time your website needs to load the content
"above the fold" and the time for loading the whole content. Additionally it
tests your website on user experience and in the end you'll get a rating between
0 and 100.

But this tool isn't leaving you out in the cold after giving you this rating. It
gives also useful advice on how to achieve a better rating. It explicitely tells
you, what you're doing wrong and how you can change that.

[The Page Speed Insights](https://developers.google.com/speed/docs/insights/rules)
shows, which rules for better speed and which rules for better user experience
must be satisfied. I think it's a great tool which not only tests everything but
also tells you how you can do better.

Another tool I don't want to miss for testing a websites performance is the
[Chrome Dev Tools Network Panel](https://developers.google.com/web/tools/chrome-devtools/profile/network-performance/resource-loading).
It:

> _"records information about each network operation on a page, including
> detailed timing data, HTTP Requests and response headers, cookies and more."_

You just have to open the Chrome Developer Tools (Cmd + Shift + I on a Mac and
Ctrl + Shift + I on Windows) and switch to the Networks Panel. Than just hit F5
to reload and record your pages network activity.

![a gif of the chrome devtools network panel](/images/chrome-dev-tools_network-panel.jpg)

I will just explain the core features here, the link above explains the Network
Panel in depth. It is structured in five panes from top to bottom: The Controls
give you the opportunity to change the look and a few functions.

With Filters you can control which resources are displayed in the Request Table.
The Overview shows a complete timeline of when the resources were retrieved.

The Request Table is the most interesting pane in my opinion. It lists every
resource that was retrieved. You can sort it by name, by size, type and so on.
By default it is sorted by the time it was retrieved. Finally the summary tells
about the total number of requests, the amount of data transferred and the
loading times.

So for a quick use of the Network Panel, you can see just in a few seconds how
much requests your pages needs, how much data is transferred, how long it takes
to load and which are the biggest files that need to load longest.

### <a name="minify-css/js"></a>Minify CSS/JS Files

After having multiple ways of testing your websites performance, there are a few
steps one can take to improve it. Minifying the CSS and JS Files is a big step
to achieve it. This means to delete all whitespaces and comments in the files,
so minified files mostly look like all code is standing on one line.

There are multiple online tools who are able to do that. But as I recently
started using Gulp, it does the job for me. The Gulp Plugin
[clean-css](https://github.com/scniro/gulp-clean-css) just needs the original
folder of your CSS file and the final destination and all the minify stuff is
done in the background.

```javascript
gulp.task('minify-css', function () {
  return gulp
    .src('assets/css/**/*.css')
    .pipe(cleanCSS({ compatibility: 'ie8' }))
    .pipe(gulp.dest('assets/css'))
})
```

### <a name="compress-images"></a>Compress Images

The same goes with compressing Images. Images take the most space on a websites
weight so compressing them is usually a good idea. I also used a Gulp Plugin to
solve this task, [imagemin](https://github.com/sindresorhus/gulp-imagemin), and
saved a lot of space.

```javascript
gulp.task('imagemin', function () {
  return gulp
    .src('assets/img/**.*')
    .pipe(
      imagemin({
        progressive: true,
      })
    )
    .pipe(gulp.dest('assets/img'))
})
```

In Addition to compress the images I'm always looking for ways to not use
images. Therefore I always try to solve issues with CSS before implementing an
Image. There is so much more that can be done with CSS than ever before. Also
inline SVG is a nice solution and I used this technique a lot throughout making
this website.

### <a name="reduce-http-requests"></a>Reduce HTTP Requests

As shown in the example above with the GQ website having a lot HTTP Requests is
one of the biggest performance pitfalls. Every single request increases the page
load time and additionally some requests need to wait because others have to
finish. One way to solve this problem is to combine files.

For example many developers like to have different CSS files. One for the main
page layout, one with the responsive styles and so on. The same goes with JS
files.

But remembering that every single file is one HTTP request, having a lot of
different CSS and JS files seems to be a really bad idea. So combining all CSS
files into one leads to only one HTTP request.

You can still use different CSS files in the development process as there are
several techniques to combine them for production like the sass `@import` which,
in contrast to the CSS `@import` rule, doesn't create an additional HTTP
request.

Another way to reduce HTTP requests is to use Image sprites. This technique
includes to create one single image out of all your background images and leads
to, you guessed it, just one HTTP request instead of many. Than you just
position it so that only the preferred image is displayed and the rest is
hidden. [Kitty Giraudel](https://twitter.com/KittyGiraudel) created a little
script called
[spritesh](http://dev.edenspiekermann.com/2016/02/10/introducing-spritesh/)
which takes all of your SVG files and creates one sprite automatically. Very
helpful!

### <a name="additional-advice"></a>Additional Advice

At this time this should be common sense. If you have a script implemented into
your website, the page stops whatever it is doing when it reaches the script and
executes it. So putting your script into the head will block the page rendering.

The solution for this problem is putting the script before the closing body tag.
The page will render completely and the script tag loads after the DOM is loaded
so there is no half loaded website or something like this.

There are also a few other solutions to this like the attributes
[async & defer](https://developer.mozilla.org/docs/Web/HTML/Element/script) but
as they are not combatible with all browsers yet they won't work correctly in
every browser.

Another useful tip is to enable Gzip. Gzip makes it possible to recude the size
of your complete website. Gzip works on the server and most hosting providers
will automatically compress your website with Gzip.

So that was my experience with website performance optimization so far. I know
I'm just at the beginning of the topic and there are a lot more ways to improve
performance so the learning never stops.

If you have got more tips or advices I would really appreciate it, if you share
them with me. Just send me an [email](mailto:marco@marcoheine.com) or reach out
to me on Twitter!

### <a name="sources/further-reading"></a>Sources & Further Reading

- [Need for Speed 2: Improving Front-End Performance](https://jonsuh.com/blog/need-for-speed-2/)
  via Jonathan Suh
- [Performance & Organization](http://learn.shayhowe.com/advanced-html-css/performance-organization/)
  via Shay Howe
- [The Imortance (and Ease) of Minifying your CSS and JavaScript](http://www.hanselman.com/blog/TheImportanceAndEaseOfMinifyingYourCSSAndJavaScriptAndOptimizingPNGsForYourBlogOrWebsite.aspx)
  via Scott Hanselman
- [Performance Tools by Robin Rendle](https://css-tricks.com/performance-tools/)
  via Robin Rendle


How to optimize your website for performance and speed

Website Performance Optimization


### Where to start?

For a long time I had the idea in my mind of developing my personal website. If you want to work in any field related to the web, its seems very logical to have your own website. 

So I decided to start this project in October 2015. Spoiler: I startet the real development process in February 2016.

I randomly started collecting ideas, things, special features and more, which I wanted to implement into my website. At this point I have to say how important Twitter became for me. Since I started using Twitter and following all these amazing people, I got inspired, got to read new articles on tools and features and I got to see impressive examples of the work of others everyday.

So after a few weeks of collecting and having a long list of cool things my website should include, I got to a point where I decided what color-palette and font I wanted to use. 

At the same time I started sketching some layout concepts with pen and paper. As this is "just" a personal website without having an overcomplex layout, this part of the process didn't took to long.

### Getting a toe into the water

As I finished my design, there was a long period where exactly nothing happend. I added a few ideas and improvements here and there, but it wasn't a constant development process. I always told myself I needed a few days where I could work on it the whole time and where nothing else would bother me.

But as I was in the second semester in my master at this time and there were a "few" things which prevented my mind of focusing completely on the project. So I worked more on a "roadmap" and on project management than on actually developing.

### Down the Waterfall

As I knew I would finish my exams at the end of january, I planned to finally develop the website at the start of february. I knew I had a little time off there and this would allow me to focus 100% on the website. So I prepared everything, made to do lists, canceled all appointments and finally started developing at the beginning of february.

My development environment consisted of a 15" laptop connected to a 21" monitor and I worked on my TV via chromecast additionally. I started with the plain HTML files and finished them, before adding any CSS. 

I liked the idea of making a website work without any CSS and it teaches a lot about accessibility. I work with Sublime Text using the Monokai Bright Theme with the Source Code Pro Font and for me this is a very pleasant combination.


I developed my website with the principles of mobile first in mind, constantly checking everything on different devices (thanks to family and friends) with different OS/browsers. Also the Chrome Developer Tools Device Mode is an awesome tool to use. While adding CSS to make everything pretty an advice of Sara Soueidan on Twitter for CSS layout troubleshooting made my life a lot easier:

```css
* {
  outline: 1px solid red;
}
```

I assume that I was the only person not knowing about this, but I was very thankful for it and it prevented a lot of headaches.

I guess the most visited website during the development process wasn't stackoverflow as you would suggest, it was caniuse.com with no doubt. As I moved on in the process I always red about task runners on Twitter and I thought that I should give it a try. So I started using Gulp, used the sass, livereload, clean-css, uglify, and imagemin plugins for this project and it really improved the development process.

The JavaScript on this website so far is really really basic stuff (like DOM Manipulation) and it's also the point where I need to improve the most.

After two weeks of developing and one week of testing, debugging and improving, the first version of this website went finally online. You may ask yourself why I'm even writing about this, as this is just a personal blog/website and nothing really complex.
 
But for myself it's a starting point which I needed to test my knowledge and to prove to myself what I can and can't do so far.

### At the horizon

So I guess for a first version of this project, I'm very happy with the result. Although so many things on my "want to have list" haven't been implemented yet.

What I've learned:
* I like to make to do lists and not stick to them
* setting up my own development environment
* the most important things belonging into the `head`
* semantic HTML and accessibility
* better structuring and organization of CSS files
* using new CSS features like flexbox, transforms, transitions, animations
* working with (inline) SVG
* make mistakes and learn from them
* sharpen my skills concerning responsive web design
* get familiar with preprocessors (Sass) and use it efficiently
* work the whole day on a problem without solving it, look at it in the evening and solve it in 2 minutes
* using a task runner (Gulp)
* improve performance


The Development Process of this Website


It's finally (a)live! My own website and my own domain are now part of this big
thing called WWW. I welcome you and I'm glad you found your way through the web
to visit my online appearance.

<Image
  src="https://media.giphy.com/media/YEL7FJP6ed008/source.gif"
  alt="a gif of Dr. Frankenstein, yelling: 'It's alive!'"
  width={500}
  height={370}
/>

You may ask yourself who I am and whats the purpose of this website. At first
it's a place for people to get to know me, learn more about me and to get in
touch with me.

You can get to know me on my about site, where I wrote a little bit about who I
am, what I can (and can't) do and what kind of education I was glad to recieve
so far.

Secondly I call this website my own sandbox and big playground.

It's a place for me to show my Frontend-Skills with HTML/CSS/JS, try out new
tools and technologies and just play around with alle the things which are
possible when using web technologies.

According to this you may see this website next to a permanent under
construction sign.

I'll constantly try out, play around and explore new things. So this is very
important for me: If you see anything not working in a particular way, find any
bugs or even spelling errors or you have advice for me how to do things better
and easier PLEASE feel free to contact me and tell me about it!

I love to learn new things everyday and for a constant improvement it's
important for me to learn from and with other people.

Here on my blog I will write from time to time about new things I have learned,
things I'm interested in and things that bother me in my everday life.

This may be mostly about Frontend topics. I'm aware of the fact that others (and
better developers, I look up to) already wrote about most of these topics. But I
like to write these things anyway to learn and improve and familiarize with
them.

So my blog posts may not show new research results and enlighten your mind whith
totally new knowledge all the time.

They will be more like a personal collection and summary of articles, recent
tools and technologies concerning a specific topic, mainly to support my own
learning process.

Anyway I hope you enjoy your stay here, look around and explore and if you would
like to talk to me about Frontend Development I'll happy if you drop me an email
or reach out to me on Twitter.


It's finally (a)live! My own website and my own domain are now part of this big thing called WWW.

Lets do this


The
[Sustainability Web Design Community Group](https://www.w3.org/community/sustyweb/)
announced the
[Web Sustainability Guidelines](https://www.w3.org/blog/2023/introducing-web-sustainability-guidelines/).
It’s all about _“how to design and implement digital products and services that
put people and the planet first.”_

> This guideline provides best practices and recommendations for reducing the
> environmental impact of web development and design, such as minimizing data
> transfer, optimizing images, using green hosting, and more.

The climate crisis is a real threat, and it’s fantastic that people exist who
care to share their ideas on **how to reduce the impact of our industry**. If
you’ve thought the internet is not a part of the problem, think again.

We are responsible for _“2-5% of global emissions, more than the aviation
industry”._ I want to quote some actions from the
[Web Sustainability Guidelines](https://w3c.github.io/sustyweb/) you can take
immediately to participate in this.

- Minify Your HTML, CSS, And JavaScript
- Avoid Code Duplication
- EnsureYour Solutions Are Accessible
- Use HTML Elements Correctly
- Choose A SustainableHosting Provider
- Optimize Browser Caching
- Be Mindful Of Duplicate Data.

These are just a few suggestions tailored to a **more environmental friendly
web**. The list is long, and I’m sure everybody will find something they can
apply there. The key takeaway I get from this is **anything you already do to
improve the accessibility of your website and the loading performance is also
good for the environment**.

If you’re interested in sustainable web design, check out
[https://sustainablewebdesign.org/](https://sustainablewebdesign.org/), listed
as the **Implementation** of the Web Sustainability Guidelines.


The Sustainability Web Design Community Group announced the Web Sustainability Guidelines. It’s all about “how to design and implement digital products and services that put people and the planet first.”

Web Sustainability Guidelines


You may have already heard that a new
[View Transitions API](https://developer.mozilla.org/en-US/docs/Web/API/View_Transitions_API)
has been developed and will soon be available in all major browsers.

View Transitions help the user to stay in **context** when switching between
pages or states. For example, the user might click a link to another page, and
some elements might be animated to make the transition smoother and make it feel
less like a hard switch between the two pages.

It’s what makes most native apps **superior** in that case and looking so cool
and smooth. SwiftUI has had this kind of technology for years.

I have planned a whole blog post about the new View Transitions API as an
in-depth tutorial, but I will wait until every major browser supports them
(looking at you, Firefox), and we can use it in production.

Nevertheless, I’d like to discuss them briefly because
[Astro released a new major version (3.0)](https://astro.build/blog/astro-3)
last week. Part of this new release is enabling developers to use view
transitions inside Astro. That makes them the **first web framework to support
the View Transitions API**.

They offer these four different ways:

- **Morph** persistent elements from one page to another
- **Fade** content on and off the page for a less jarring navigation effect
- **Slide** content on and off the page for a bit more personality
- **Persist** common UI across pages, with or without a refresh

It’s straightforward to implement and use. You just have to import and add the
view transitions routing component on the page you want to use them.

```jsx
---
import { ViewTransitions } from 'astro/dist/components/view-transitions.js'
---

<h1>My Page</h1>
<ViewTransitions />
<div transition:name="fade">
  <p>Some content</p>
</div>
```

Astro will **automatically** create default page animations based on the
similarities between the old and the new pages. That’s all!

You can also identify the corresponding view transition element yourself. For
example, I wanted a view transition on the image in a blog post overview page
and on the image on the individual blog post.

So first, you view the list of blog posts, and when clicking on a specific blog
post, a view transition should happen on that image.

To achieve that, you only need to add the same `transition:name` value on both
image elements. It’s like magic!

If you want to see view transitions live in Astro, check out the
[Spotify clone built by Igor](https://github.com/igorm84/spotify-astro-transitions).
You have to make sure to use Chrome for that.

I’m curious how we’ll take advantage of this new possibility and if it will
change how it feels to browse the web.

## Sources

- [Astro 3](https://astro.build/blog/astro-3)
- [View Transitions](https://docs.astro.build/en/guides/view-transitions/)
- [Can I use view transitions](https://caniuse.com/?search=view%20transitions)
- [Spotify Astro Transitions on GitHub](https://github.com/igorm84/spotify-astro-transitions)


View Transitions will soon be available in all major browsers and Astro is the first framework to support them.

View Transitions are coming (Astro 3.0)


CSS has become way more **powerful** over the last few years. A lot of
significant improvements were added to the language, and I like the way where it
is going.

Recently, I stumbled over this
[CSS Selectors Visual Guide by Sébastien Noël](https://fffuel.co/css-selectors),
and I love it. I would have loved this when I started learning and working with
CSS!

As the name suggests, it is a **visual guide to all the CSS selectors**. You get
an example of the selector on the left and an image of the selected element on
the right. I'm surprised no one else has done this before.

This is a definite bookmark for me. Although I've been working with CSS for
years, I even **learned something new**. I learned about the
[lobotomized owl selector](https://fffuel.co/css-selectors/#lobotomized), which
selects all elements with a preceding sibling.

```css
* + * {
  margin-top: 1.5em;
}
```

It's a great way to select all elements, but not the first one in a container. I
can imagine that I will visit this guide a lot in the future because of the
great overview it provides. If you forgot about the exact selector for valid
inputs or attribute selectors just head over there.


Today I learned about this visual guide to all CSS selectors

CSS Selectors Visual Guide


This is technically not a "Today I learned" post because I already knew that
knowing semantic HTML is important. This post is more of a reminder to myself
and others that HTML is still the most important language to learn.

So today, I learned that learning and knowing semantic HTML is still important.

Every developer saw these websites where the DOM consists of a bunch of `div`s
and maybe even worked on a website like that themselves. I know I did. And I
wasn't proud of it. But thankfully, we can do better.

This week I stumbled over two blog posts. The first one is
[I'm betting on HTML](https://catskull.net/html.html), which highlights their
favorite HTML elements. The second one is
[A Blog Post With Every HTML Element](https://www.patrickweaver.net/blog/a-blog-post-with-every-html-element/)
by Patrick Weaver in which, as the title says, he uses every HTML element in a
blog post.

I'd like to share my favorite parts of these blog posts here, so let's jump
right in.

The range of input types is amazing. You get so much functionality without any
JavaScript.

### Different input types

<label htmlFor="color">Color:</label>
<input
  id="color"
  type="color"
/>

{' '}

<br />
<label htmlFor="date">Date:</label>
<input
  type="date"
  id="date"
/>
<br />
<label htmlFor="datetime-local">Datetime-local:</label>
<input
  type="datetime-local"
  id="datetime-local"
/>
<br />
<label htmlFor="range">Range:</label>
<input
  type="range"
  id="range"
/>

Built-in datepickers? Come on! Everyone who has ever built a datepicker knows
how much work it is to make it accessible and usable. And here we have it for
free.

### Meter

The `meter` element is also pretty cool.

<meter value="0.5">50%</meter>
<meter value="0.75">75%</meter>
<meter value="1">100%</meter>

Firefox shows them all as green, but Safari shows them as red, yellow, and green
depending on the value.

### Progress

And of course, the `progress` element.

<label htmlFor="progress">Progress:</label>
<progress
  id="progress"
  value="0.85"
>
  85%
</progress>

Make sure you use a label for it. Otherwise, it's not accessible.

### Mark

I've worked with JS libraries just to highlight some text. Did you know that's
possible with HTML? I didn't. What a shame.

<mark>highlighted text</mark>

Quick and reasy way to highlight text without any JS.

### Differences between elements

The difference between `strong` and `b` is also interesting. `strong` is for the
meaning of the text and `b` is for the presentation. So use `strong` if you want
to emphasize the text and `b` if you want to make it bold.

I think the same goes for `em` and `i`. `em` is for single words, and `i` is for
phrases.

### Samp

Have you ever used `samp`? I haven't. I didn't even know it existed until I read
Patrick's blog post. It's used to render the output of a computer program. I
always used `code` for that.

<figure className="flex flex-col">
  <figcaption>A little JavaScript program:</figcaption>
  <code>const name = 'Patrick'</code>
  <code>console.log(`Hello ${name}!`);</code>
  <samp>Hello Patrick!</samp>
</figure>

Looks all the same but the last line is rendered as `samp` instead of `code`.

### Wbr

Another one I have never heard before is `wbr`. It's used to tell the browser
where it can break long words. It's a gread thing to use for long URLs. The
points where it breaks are more clear which makes it more readable compared to
not using `wbr`.

These were the highlights of my weekly HTML digest. I strongly recommend reading
both mentioned blog posts above because they cover a lot more than I did here.

## Sources

- [I'm betting on HTML](https://catskull.net/html.html)
- [A Blog Post With Every HTML Element by Patrick Weaver](https://www.patrickweaver.net/blog/a-blog-post-with-every-html-element/)

- [Color](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/color)
- [Date](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date)
- [Datetime-local](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/datetime-local)
- [Range](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/range)
- [Meter](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meter)
- [Progress](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/progress)
- [Mark](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/mark)
- [Samp](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/samp)


Learn HTML! It is still the foundation of the web and the most important language to learn.

Learn HTML


I have **never used** **Web Components** before. I’ve heard of them, for sure.
I’ve seen several blog posts and coding examples about how to build web
applications with them. But I never actually used code that included Web
Components.

I never considered choosing them for a new website instead of React or any other
JavaScript Framework. I always thought: they seemed to be a general approach for
building web applications so we, as developers, wouldn’t need to rely on
independent frameworks anymore. But the point where they would overtake never
came.

Ever wondered why they haven’t succeeded yet? Dave Rupert has a lot to say about
this. He wrote a blog post,
[“If Web Components are so great, why am I not using them?”](https://daverupert.com/2023/07/why-not-webcomponents/)
where he shares his opinion on **why web components haven’t taken over yet**,
and what he’d done differently if he could turn back time.

I’ll summarize his key takeaways here, but make sure you’ll check out his whole
blog post and the included links because reading his take on the topic is super
interesting.

In general, Dave says Web Components have a **marketing problem**. That’s the
biggest problem. This can be broken down into the following points:

- Web Components were designed for framework authors, not the average WordPress
  user. But Framework authors **declined** to use them because their problems
  were already solved otherwise.
- They were marketed as a **Google thing** and a bit too heavy on bashing other
  frameworks and selling Web Components as the only true thing.
- It was hard to convince others to use Web Components without the ability to
  refer to popular products built with them.
- They have been around for a few years but only became indeed **supported
  recently**.
- Their development is **slow**. If you’re waiting for a new feature for them
  available in every browser, you have to wait a couple of years.

Dave made many interesting points, which made me understand better why Web
Components are not there yet where they were supposed to be. I’m curious how
they will evolve in the future!


Have you used Web Components? I have not and I wondered why. Dave Rupert has a lot on opinions why Web Components have not succeeded yet and in this post I summarize his blog post.

Have you used Web Components?


If you wanted to integrate a popover on a website before, you had to reach out
to a **third-party package** in the past because they made it easy to customize
things like positioning and enhancing functionality. This may soon be a tale of
the past!

[The popover API](https://hidde.blog/popover-semantics/) with the popover
attribute was introduced recently and is available in Chromium 114. By using
this new popover API, it will be **easier to integrate popovers into websites**.
It brings all the needed functionality and satisfies all the **accessibility
concerns**. And all of that without using any JavaScript.

To make use of the new popover API, three basic things are required:

- the popover attribute on the element containing the popover
- an id on the element containing the popover
- the element which opens the popover needs to have a popovertarget attribute
  with the value of the popover’s id

```html
<button popovertarget="popover">Open popover</button>

<div
  popover
  id="popover"
>
  <p>Popover content</p>
</div>
```

Implementing such a popover is **accessible by default** because the popover and
its trigger are **connected semantically**. Furthermore, closing the popover
with the ESC key is built-in, making it easy for keyboard users to dismiss it.

In addition to that, the new popover has a **light-dismiss functionality**. If
you click anywhere outside the popover, it will close and return focus. If you
open the popover, the next keyboard tab will stop inside the popover, so **focus
management is handled by default**.

Another great advantage of it is that the popover will always appear on a
separate level above the rest of the page, so there is **no need for manual
z-index handling**.

That’s such a great addition, I can’t wait until it’s stable in all modern
browsers and we can use it! It’s a big step into easier and faster ways to build
websites and improve accessibility by default.

It’s important to note that the new popover attribute **will only add behavior,
not semantics**. Popovers have no default role, and you’re supposed to add your
own semantics to it! Hidde de Vries wrote an
[excellent post about different semantics](https://hidde.blog/popover-semantics/)
that could make sense for popover-behaved elements. He takes a closer look at
menus, dialogs, and listboxes.

### Sources

- [Introducing the popover API by Una Kravets](https://developer.chrome.com/blog/introducing-popover-api/)
- [Popover semantics by Hidde de Vries](https://hidde.blog/popover-semantics/)


The popover API is a new HTML attribute that makes it easy to integrate popovers into websites without the need for JavaScript.

The popover API


If you browse the web, you'll notice quickly that **sticky menus are used
often**. Sometimes I'm happy they're on a website, so I can quickly reach
call-to-action buttons or other important information. But most of the time, it
feels to me that they **take up a lot of space** away, and I intend to
**remove** them.

Seeing them so much in the wild was a validation to me. If implemented this
often, they must be helpful and improve the user experience. But if you think
about it: every website uses cookie banners, e-mail sign-up modals, and other
kinds of overlays, and we all hate them and know it's terrible UX.

So I was curious when I stumbled over this post by Adam Silver:
["The problem with sticky menus and what to do instead."](https://adamsilver.io/blog/the-problem-with-sticky-menus-and-what-to-do-instead/)
He states several well explain arguments on **why to avoid sticky menus and
shares better alternatives**.

His key takeaways, why we should replace them are:

1. **They constantly take up space**
2. **They obscure content**
3. **They break when you zoom in**
4. **They're difficult to access**
5. **Internal page anchors feel broken when clicked twice**
6. **They appear closer than they are**
7. **They obscure links and other focusable elements**

While most are obvious and reasonable arguments, numbers six and seven stood
out. I wasn't aware that sticky menus not only **decrease user experience** in
general but they're also reducing **accessibility** by a lot.

Sticky menus make us think that they are always very close to reach. That might
be true if you're using a mouse. You just move to it and can click. But, ever
tried to navigate to a sticky menu with a keyboard? Oh boy! They are often way
out of the normal document flow and very **hard to reach using the tab key**.

More accessibility problems arise if you're trying to move up the page with your
keyboard. Chances are you reach content that's right below the sticky menus. So
links and other focusable elements are not visible to you because they get
obscured by sticky menus.

Adams's advice on what to do instead is:

- **Keep pages short. This removes the need for a sticky menu**
- **Just let users scroll.**
- **Scrolling is never a problem, is fast, and everyone does it anyway**
- **Instead of putting important CTAs into a sticky menu, put them in a context
  like a CTA at the end of a pricing section**

If you think about implementing a sticky menu, I hope this post helps you to
think again by summarizing Adams's points here and sharing his alternatives.
Because sticky menus can have serious issues!


Sticky menus are used widely on the web but come with some serious issues. In this post I learned about the problems they cause and what to do instead.

The problem with sticky menus


If you've been working with SCSS, you know that **nesting** in CSS is possible
by using this **extension** of the language.

In SCSS, you could write something like this to style the children of a parent:

```scss
.parent {
  color: red;

  .child {
    color: blue;
  }
}
```

To achieve the same thing in CSS, you would have to write something like this:

```css
.parent {
  color: red;
}

.parent .child {
  color: blue;
}
```

This is not a big deal if you only have one child, but if you have multiple it
can get **messy and very repetitive**.

The W3C worked on a new module to finally **enable CSS nesting without the need
of a preprocessor**.

Their main reason for doing this was to increase the "modularity and
maintainability of CSS stylesheets." Furthermore, they explain their motivation
as follows:

> The CSS for even moderately complicated web pages often includes lots of
> duplication for the purpose of styling related content.

Here's how you can nest CSS without the need for SCSS:

```css
.parent {
  color: red;

  .child {
    color: blue;
  }
}
```

It's the same as in SCSS, so if you're used to that syntax, you don't have to
re-learn a lot!

It's also possible to use relative selectors when using nesting:

```css
.parent {
  color: red;

  &:hover {
    color: blue;
  }

  + .sibling {
    color: green;
  }
}
```

The only thing that's not valid is to use nesting selectors that start with an
**identifier**:

```css
.parent {
  color: red;

  input {
    color: blue;
  }
}
```

You can look at all the valid nestings in the
[specification](https://www.w3.org/TR/css-nesting-1/#nesting-rules). They also
provided an in-depth explanation of why there is a need for **restrictions** on
nested rule selectors.

I think that's a great addition to the language. If you want to try it out right
away, you can test it in the latest releases of Chrome, Edge, and Safari. You
can check out the browser support here:
[Can I use - CSS nesting](https://caniuse.com/css-nesting).

### Sources

- [CSS Nesting Module](https://www.w3.org/TR/css-nesting-1/)
- [CSS Nesting](https://developer.chrome.com/articles/css-nesting/)


CSS Nesting is finally built into the language. No need for a preprocessor anymore! In this post, I'll look at the spec and valid selectors.

CSS Nesting


Today I learned about the tool [Image Carbon](https://imagecarbon.com/). It's a
tool that helps you to calculate the carbon footprint of your websites images.

After entering a URL it will show you the amount of CO2 you could reduce by
optimizing your images. It can achieve that by uisng the
[Sustainable Web Design](https://sustainablewebdesign.org/calculating-digital-emissions/)
model.

It checks every image on your page for the format and the size and tells you how
you could improve on that.

Here are the results for my website:
[https://www.imagecarbon.com/sites/marcoheine.com](https://www.imagecarbon.com/sites/marcoheine.com)

Reducing your image sizes by compressing them and using better formats is not
only better for your websites performance but also for reducing the carbon
footprint.


Image Carbon is a tool that helps you to calculate the carbon footprint of your websites images

Image Carbon


If you're working on websites where the content is very flexible, where editors
can add text, for example, via a CMS, you often don't know "the final size, font
size or language of text".

It's hard, especially for headlines, to make two lines consistent in the number
of words per line.

Often it looks weird when a headline breaks on a specific breakpoint and just
one word gets wrapped in the following line.

We always had to use techniques that felt more like hacks to enforce a more
consistent wrap. Using `<br />` tags or `&nbsp;.` Counting the words with
JavaScript and adding `<span>` tags around them.

Very soon, we will have a new CSS property called `text-wrap: balance` that will
help us with this.

To use this CSS property, you will need to apply it like this:

```css
.my-headline {
  max-width: 20rem;
  text-wrap: balance;
}
```

This will ensure that the text is balanced over two lines and that the number of
words stays consistent. At the same time, it does not affect the element's width
and will only affect the words within the element.

Only using this property may not be enough because the text needs to wrap and
therefore needs a max width.

Here's a direct comparison of the same text with and without
`text-wrap: balance`:
![a screenshot showing two headlines, the first one does not wrap nicely, the second does.](/images/text-wrap-balance.webp)

Both have set the same max-width but only the second one has the new property
set. The first one has a weird break where it wraps only one word into the next
line while the second one is balanced over two lines.

Ahmad has a lot of great examples of where this new property could be useful:
[CSS Text balancing with text-wrap:balance](https://ishadeed.com/article/css-text-wrap-balance/)

[Adam Argyle argues](https://developer.chrome.com/blog/css-text-wrap-balance/)
that balancing headlines is the primary use case for `text-wrap: balance.`

It's currently only available in Chrome Canary and behind a flag. But it looks
promising that we will be able to use this property soon in all major browsers.

### Sources:

- [CSS Text balancing with text-wrap:balance](https://ishadeed.com/article/css-text-wrap-balance/)
- [CSS text-wrap: balance](https://developer.chrome.com/blog/css-text-wrap-balance/)


Text-wrap balance is a new way to specify with CSS how lines of text are balanced.

Text-wrap: balance


As we all know, **the web is not accessible**, and that's a big bummer. A lot of
developers know way too less about accessibility, as we see if we look at the
HTML structure of websites, which often just consist of a ton of `divs.`

On the other hand, a lot of companies don't pay for or don't have the budget for
accessibility audits and improvements and the increased workload that comes with
building accessible websites.

It's our job as developers to **make accessibility a mandatory part of our
work** and create awareness for it. Sooner or later, new websites will have to
be accessible by law.

I'm not an expert in accessibility, but I'm trying to improve my knowledge of it
every day and with every new website or component I build.

Recently I built a modal dialog for a website, and here's everything I learned
and applied to make it accessible.

## Building accessible modal dialogs

There are a few key things to remember when building accessible modal dialogs.
First of all, we need to ensure that the modal dialog can be **accessed and
navigated with a keyboard only**.

Next, the **keyboard focus** should be managed properly. When opening the modal,
the focus should be on the first focusable element inside the dialog. This
enables keyboard users to navigate the modal dialog with the tab key right away.

Additionally, the elements behind the modal should be **hidden** from screen
readers and not be focusable so users who use assistive technologies don't get
lost in a sea of content.

To support this, the modal dialog should also be **full-screen on mobile**.

An obvious thing but often not implemented correctly is that the modal dialog
should be **closable with a certain close button** and also be able to be
**closed with the escape key**.

When you implement all of these things, you'll have a pretty accessible modal
dialog and help many of people who use assistive technologies to access your
content without any problems.

The important properties to enforce these things are the following:

### role="dialog"

First and foremost, if you're not using the
[html5 `<dialog>` element](#html5-dialog-element), you need to give your modal
dialog the `role="dialog"` attribute. This tells screen readers that the element
is a dialog and not just a regular div. The proper HTML element for your dialog
can be a `div` or a `section.`

### aria-modal="true"

You also need to give your modal dialog the `aria-modal="true"` attribute. This
tells screen readers that the dialog is modal and that the user needs to
interact with it before they can continue.

It also helps with getting lost in content, which I talked about earlier by
limiting the navigation to the modal dialog content and hiding elements in the
background.

### aria-labelledby and aria-describedby

Next, you need to give your modal dialog an `aria-labelledby` attribute with the
id of the title of the dialog. This tells screen readers which title belongs to
the dialog.

If you don't have a descriptive title element inside your modal dialog, you can
use the `aria-label` attribute instead.

If you have a description for your modal dialog, you can use the
`aria-describedby` attribute to tell screen readers which element contains the
description.

### aria-label="close modal"

Often, close buttons do not consist of descriptive text like "close". Instead,
icons, svgs, or images are used. In this case, you need to give the close button
the `aria-label="close modal"` attribute to tell screen readers what the button
does.

## What about the html5 dialog element? <a name="html5-dialog-element"></a>

There exists a new HTML5 element called `<dialog>.` It was introduced in
Chromium 37 back in 2014. Unfortunately,
[it's not yet widely supported by all browsers](https://caniuse.com/?search=dialog),
but we may be able to use it without any polyfills very soon. So if you're just
looking to support modern browsers, you can use it right now.

It then can be used instead of `role="dialog"` because it's the semantic html5
equivalent.

## Sources and further reading:

- [Technique: Accessible modal dialogs ](https://accessibility.huit.harvard.edu/technique-accessible-modal-dialogs)
- [Modal Dialog Example ](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/examples/dialog/)
- [The a11y Monthly: Making modals accessible](https://yoast.com/developer-blog/the-a11y-monthly-making-modals-accessible/)


Today I learned how to make modal dialogs accessible so that they can be used by people who use assistive technologies to navigate the web.

Building accessible modal dialogs


I never was a big fan of Sliders and Carousels. Also, creating them as a
front-end developer was always a pain. So whenever possible, I suggested using
**horizontal scrolling** as an alternative.

Combining it with the `CSS scroll-snap properties` allows us to create **smooth
and precise scrolling experiences**, which is super cool.

To get started, you have to look at the two properties, and how they play
together to make these scrolling experiences.

The first property is
[scroll-snap-type](https://developer.mozilla.org/en-US/docs/Web/CSS/scroll-snap-type).
It defines the type of scrolling behavior for the scroll container. It can be
set to `x, y, or both`. The default value is `none`.

for example if you set it to `x`, the scroll container will snap to snap
positions on its horizontal axis only.

The second property is
[scroll-snap-align](https://developer.mozilla.org/en-US/docs/Web/CSS/scroll-snap-align).
It defines the alignment of the snap position relative to the scroll container.
It can be set to `start, center, or end`.

If you set it to `start` for example, the snap position will be aligned to the
left of the scroll container. So every item you scroll by snaps until its left
edge is aligned with the left edge of the scroll container.

So far, the theory. Now let's look at some examples to showcase the different
possibilities for creating these scrolling experiences.

Here is a CodePen with examples of the different scroll snap types and
alignments:

<CodePen
  id="WNgWjaM"
  height="800"
  defaultTab="result"
  title="CSS Scroll Snap"
/>

It's awesome see that we are able to create these scrolling experiences with CSS
only and without any JavaScript.


Today I learned about how you create a scroll snap effect in CSS with the scroll snap properties.

CSS Scroll Snap


**React Server Components** are one of the most talked topics in the React
community right now.

They are a new way to build React apps that will be released in the future. They
are not yet available, but we can already start to learn about them.

They were first introduced as an **RFC (Request for Comments)** in
December 2020. Here is the blog post, where they were introduced as a current
research:
[Introducing Zero-Bundle-Size React Server Components](https://beta.reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components)

And here is a link to the RFC, which is super interesting to read, to get the
idea behind them and how the concept developed since then:
[RFC: React Server Components](https://github.com/reactjs/rfcs/blob/main/text/0188-server-components.md)

Dan Abramov, one of the React core team members, has been putting a lot of
effort into educating everybody on Twitter and answering questions about them.

He recently met up with Kent C. Dodds and Joe Savona, whos Tech lead in the
React organization in Meta. I totally recommend to watch the whole video:
[React Server Components with Dan Abramov, Joe Savona, and Kent C. Dodds](https://www.youtube.com/watch?v=h7tur48JSaw&t=427s)

They tried to answer all of Kents' questions about React Server Components and
there was a lot of insights to be learned.

In this post I want to summarize the most important things I know about React
Server Components so far.

In the future, we'll be able to differentiate between **Server Components** and
**Client Components**. Both will have different abilities and limitations. Let's
take a look on the things they can do:

### Server Components

- can directly access server data
- can use this data to generate html and return it to the browser
- read data on the server, pass it down by props
- each component can fetch the data that it needs
- they can hand of the rendering to the client by importing and rendering a
  "client" component
- includes the server into the unidirectional data flow
- maybe we don't need to build APIs anymore, when using server components
- they can't use state or effects
- they can't use browser-only APIs like the DOM
- help to reduce the bundle size, by giving us the ability of shifting
  third-party dependencies to the server

### Client Components

- are inside the server components
- can be interactive JSX components
- HTML created at runtime in the browser from JavaScript
- are marked with 'use client' at the top and therefore only included in the
  bundle if they are used
- can use state, effects, lifecycle methods, custom hooks
- the components we are already used to

To fully understand this new separation, lets take a look at a simple example:

```ts
// server
import db from './db'
import UserDetail from './UserDetail'

export const User = () => {
  const user = db.getUser(id)
  return <UserDetail user={user} />
}
```

```jsx
// client
'use client'
export const UserDetail = ({ user }) => {
  return (
    <div>
      <h1>{user.name}</h1>
      <p>{user.bio}</p>
    </div>
  )
}
```

In this example, the server component `User` fetches the user data from the db
and passes it down to the client component `UserDetail`. The client component
then renders the HTML.

This is a very simple example, but it shows the basic idea of how server and
client components work together.

The split between server and client components will enable us again to **take
full advantage of the server**. By shifting several main tasks, like data
fetching, to the server, we can **reduce the bundle size** and **improve the
performance** of our apps.

I'm very curious to see how this will work in practice. I think it will be a big
step forward for React and the whole ecosystem. And maybe a totally new way to
build web apps in the future.


Today I learned about React Server Components, what they are and how they will be useful.

React Server Components


A good friend of mine, [Tommy](https://github.com/ItsTommyGun), recently built
this cool **SVG drawing animation**. I was curious how he did it because I'd
never done something like this before, and he was kind enough to explain it to
me.

First and foremost, you need an SVG with a stroke because strokes can be dashed.
Here's the SVG we are going to animate like it's being drawn:

<svg
  width="165"
  height="47"
  xmlns="http://www.w3.org/2000/svg"
>
  <g>
    <path
      stroke="#000"
      strokeWidth="2"
      d="m70.1895,4.65437c0,0 -2.48485,-0.39525 -6.58888,-0.67265c-4.99273,-0.33748 -8.23605,-0.67265 -10.70688,-0.67265c-4.11805,0 -8.18497,0.33517 -13.17771,0.67265c-2.46241,0.16644 -4.9458,-0.09537 -6.58885,0c-5.80915,0.33716 -8.2581,0.5181 -9.05968,0.67265c-3.58476,0.69114 -7.48447,2.55199 -11.53051,4.03588c-1.68001,0.61615 -2.62402,1.13847 -4.11802,2.01792c-1.88981,1.11244 -3.19367,3.40762 -4.11804,4.7085c-1.49051,2.09762 -2.05363,3.95418 -2.47082,6.0538c-0.39578,1.99189 0,4.03588 0,5.38117c0,0.67263 -0.47734,2.07563 0,3.36321c0.86053,2.3212 1.81754,3.2372 3.29443,4.7085c1.88267,1.87555 2.62402,3.15642 4.11804,4.03588c1.88978,1.11242 3.24017,2.78763 4.94163,3.36321c2.40622,0.814 6.48882,2.34985 9.05968,2.69058c1.62596,0.21549 6.596,0.23456 12.3541,0c8.26688,-0.33674 18.11936,-0.67265 25.53182,-0.67265c1.64722,0 2.47081,0.67265 9.05968,0.67265c13.17771,0 23.06097,0 28.82624,0c6.58885,0 14.83752,0.37197 23.061,0c7.44667,-0.33683 9.8939,-1.23755 10.70688,-1.34529c5.14167,-0.68144 10.79607,-1.92737 15.64853,-2.69058c4.35523,-0.68501 7.66779,-2.24494 9.88329,-3.36321c0.9908,-0.50011 1.5026,-0.73851 2.47081,-2.01794c0.43299,-0.57218 0.37788,-1.13908 0.82361,-2.01794c0.31518,-0.62143 0,-1.34527 0,-3.36321c0,-2.01794 -0.94246,-3.31891 -1.64722,-4.7085c-0.99668,-1.96517 -2.62752,-3.95618 -4.11802,-6.0538c-1.84875,-2.60179 -4.48905,-5.68417 -6.58885,-7.39909c-2.0998,-1.71492 -3.92127,-2.97033 -6.58885,-4.03586c-2.33965,-0.93454 -8.25684,-2.61075 -12.35412,-3.36323c-3.31308,-0.60845 -6.62075,-0.34941 -9.05966,-0.67265c-2.57086,-0.34073 -7.4325,-0.34125 -11.53051,-0.67265c-4.17915,-0.33796 -7.9421,1.13881 -12.8042,0.15254c-2.52765,-0.51275 -9.14435,0.40914 -14.06916,0.07626c-4.99273,-0.33748 -5.51904,-0.97084 -6.34265,-0.97084c-1.64722,0 -7.14913,-0.74891 -7.97274,-0.74891l-3.7274,0l-3.84628,0.45071"
      fill="none"
    />
  </g>
</svg>

And here's the HTML of it:

```html
<svg
  width="165"
  height="47"
  xmlns="http://www.w3.org/2000/svg"
>
  <g>
    <path
      stroke="#000"
      strokeWidth="2"
      d="m70.1895,4.65437c0,0 -2.48485,-0.39525 -6.58888,-0.67265c-4.99273,-0.33748 -8.23605,-0.67265 -10.70688,-0.67265c-4.11805,0 -8.18497,0.33517 -13.17771,0.67265c-2.46241,0.16644 -4.9458,-0.09537 -6.58885,0c-5.80915,0.33716 -8.2581,0.5181 -9.05968,0.67265c-3.58476,0.69114 -7.48447,2.55199 -11.53051,4.03588c-1.68001,0.61615 -2.62402,1.13847 -4.11802,2.01792c-1.88981,1.11244 -3.19367,3.40762 -4.11804,4.7085c-1.49051,2.09762 -2.05363,3.95418 -2.47082,6.0538c-0.39578,1.99189 0,4.03588 0,5.38117c0,0.67263 -0.47734,2.07563 0,3.36321c0.86053,2.3212 1.81754,3.2372 3.29443,4.7085c1.88267,1.87555 2.62402,3.15642 4.11804,4.03588c1.88978,1.11242 3.24017,2.78763 4.94163,3.36321c2.40622,0.814 6.48882,2.34985 9.05968,2.69058c1.62596,0.21549 6.596,0.23456 12.3541,0c8.26688,-0.33674 18.11936,-0.67265 25.53182,-0.67265c1.64722,0 2.47081,0.67265 9.05968,0.67265c13.17771,0 23.06097,0 28.82624,0c6.58885,0 14.83752,0.37197 23.061,0c7.44667,-0.33683 9.8939,-1.23755 10.70688,-1.34529c5.14167,-0.68144 10.79607,-1.92737 15.64853,-2.69058c4.35523,-0.68501 7.66779,-2.24494 9.88329,-3.36321c0.9908,-0.50011 1.5026,-0.73851 2.47081,-2.01794c0.43299,-0.57218 0.37788,-1.13908 0.82361,-2.01794c0.31518,-0.62143 0,-1.34527 0,-3.36321c0,-2.01794 -0.94246,-3.31891 -1.64722,-4.7085c-0.99668,-1.96517 -2.62752,-3.95618 -4.11802,-6.0538c-1.84875,-2.60179 -4.48905,-5.68417 -6.58885,-7.39909c-2.0998,-1.71492 -3.92127,-2.97033 -6.58885,-4.03586c-2.33965,-0.93454 -8.25684,-2.61075 -12.35412,-3.36323c-3.31308,-0.60845 -6.62075,-0.34941 -9.05966,-0.67265c-2.57086,-0.34073 -7.4325,-0.34125 -11.53051,-0.67265c-4.17915,-0.33796 -7.9421,1.13881 -12.8042,0.15254c-2.52765,-0.51275 -9.14435,0.40914 -14.06916,0.07626c-4.99273,-0.33748 -5.51904,-0.97084 -6.34265,-0.97084c-1.64722,0 -7.14913,-0.74891 -7.97274,-0.74891l-3.7274,0l-3.84628,0.45071"
      fill="none"
    />
  </g>
</svg>
```

The key to the animation are the
[stroke-dasharray](https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/stroke-dasharray)
and
[stroke-dashoffset](https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/stroke-dashoffset)
properties.

The `stroke-dasharray` property defines the **length** of the dashes, and the
`stroke-dashoffset` property defines the **offset** of the dashes.

```css
svg {
  stroke-dasharray: 372;
  stroke-dashoffset: 372;
  animation: draw 0.5s linear forwards;
}

@keyframes draw {
  to {
    stroke-dashoffset: 0;
  }
}
```

The `stroke-dasharray` property is set to 372, which means that the dashes are
372px long.

The `stroke-dashoffset` property is also set to 372, which means that the dashes
are offset by 372px, so the dashes are **not visible** at all.

The animation is set to 0.5 seconds, and the `stroke-dashoffset` property is
animated to 0, which makes the dashes **appear one after another**.

That's how we make our SVG look like it's being drawn!

The `stroke-dasharray` property can be set to any value. The higher the value,
the longer the dashes will be. The same goes for the `stroke-dashoffset`
property. The higher the value, the longer the dashes will be offset.

We set it to exactly the length of the path so that the dashes are the same as
the path, and there are no gaps.

Here's great article by CSS-Tricks that explains this technique in more detail:
[How SVG Line Animation Works](https://css-tricks.com/svg-line-animation-works/).

And here is the result:

<CodePen
  id="PodJEge"
  title="SVG Drawing Animation"
/>

The only drawback is that you need to know the length of the path. That's it, a
simple SVG animation without any JavaScript at all!


Today I learned how to animate SVG drawings using CSS.

SVG Drawing Animation


Vercel released [Cron Jobs](https://vercel.com/blog/cron-jobs) recently! That is
pretty cool. It's a feature a lot of people longed for because something like
this was not available yet when using serverless environment like Vercel.

Now you can automate repetetive tasks without having a backend. To get started
with Cron Jobs in Vercel you have to create a `vercel.json` file. Here are some
example Cron Jobs:

```json
{
  "crons": [
    {
      "path": "/api/backup",
      "schedule": "0 0 * * *"
    },
    {
      "path": "/api/weekly-mail",
      "schedule": "0 0 * * 1"
    }
  ]
}
```

Cron Jobs use a specific syntax to determine the time when the job should be
executed. The schedule string consists of five fields separated by spaces. They
stand for minute, hour, day, month and day of the week.

So the first job in the example above will be executed **every day at
midnight**. While the second job will be executed **every Monday at midnight**.

With the Hobby plan you get two Cron Jobs for free which each can be triggered
once per day, while the Pro plan offers 40 Cron Jobs in total with unlimited
usage per day.

Here's the full documentation of Cron Jobs in Vercel:
[Cron Jobs](https://vercel.com/docs/cron-jobs)


Today I learned that Vercel introduced Cron Jobs recently. So now you can automate repetetive tasks in a serverless Environment like on Vercel.

Vercel Cron Jobs


Filling forms can be an **annoying and painful user experience**, especially if
you're on mobile. If you've ever tried to fill a long form on your phone and the
inputs weren't set up correctly, you know what I'm talking about.

The wrong keyboard opens, and you have to switch to special characters or
numbers all the time.

But this can be made so much easier and user-friendly with some simple steps.
Using the right input type value for the input is the first and, in most cases,
the only step you need to take.

For example, `<input type="email" />` will open up the right virtual keyboard on
mobile. The same goes for `type="url"`, `type="tel"` or `type="number"`.

But there are more attributes you can offer to make the user experience even
better.

Big thanks to Jeremy for teaching me about these attributes in this great
article
[Three attributes for better web forms](https://adactio.com/journal/19842?skin=default).

### inputmode

Inputmode is an attribute that can tell the browser to show a **specific virtual
keyboard**. This is redundant if you've already set the type to
`email, tel, url` or `search`.

But if you have an Input with the type text and you want to tell your users to
enter numbers there, `inputmode="numeric"` is super helpful. You can even
enclose the input by using `pattern="[0-9]*"`.

The other possible values for `inputmode` are
`text, numeric, decimal, search, email, tel` and `url`.

To learn more about it, check out the
[MDN documentation for inputmode](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/inputmode).

### enterkeyhint

As explained above, the inputmode provides help to show the correct virtual
keyboard, whereas the `enterkeyhint` attribute provides help to specify what is
shown on the enter key on a virtual keyboard.

The possible values are `enter, done, go, next, previous, search, send`. This is
helpful in tailoring the user experience to the specific input. For Contact
forms, it's usually `send`, and for search forms, it's `search`.

Checkout the full documentation for
[enterkeyhint on MDN](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/enterkeyhint).

### autocomplete

The autocomplete attribute is my favorite one. It doesn't specify the virtual
keyboard, like the previous attributes. Instead, it tells the browser that there
are values that could be used to pre-fill the Inputs.

This is such a great feature because it makes filling Forms a way more pleasant
experience.

There are several categories with different values you can use. For the `name`
category you can use
`given-name, additional-name, family-name, nickname, honorific-prefix, honorific-suffix`
and `username`. If you don't need to break it down into different parts, you can
use `name` itself.

The same goes for `tel` and `address`. Check out the available attributes on the
[MDN documentation of `autocomplete`](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete).

That's it; these are three awesome attributes you can use to make your forms
more user-friendly. I made a CodePen to showcase all the attributes explained in
this post. Check it out:

<CodePen
  id="wvEGPWK"
  title="Input Attributes for better Forms"
/>


Filling Forms on website can be an unnecessary pain. Recently I've learned about some simple steps to make Forms more user friendly.

Input Attributes for better Forms


If you haven't heard of Lighthouse before, it's a tool that helps you improve
the quality of your website. It's available as a Chrome extension and as a Node
module. It's also integrated into Chrome DevTools.

It's my go-to tool for improving the performance of my websites. I test every a
website with it before I publish it, and I test it regularly after that to make
sure, I don't regress.

[Lighthouse 10](https://developer.chrome.com/en/blog/lighthouse-10-0/) was
released recently and includes some major new features.

### TTI is being removed

One of the most significant changes is that
[TTI (Time To Interactive)](https://web.dev/tti/) is being **removed**
completely. Its 10% score weight is shifting to
[CLS (Cumulative Layout Shift)](https://web.dev/cls/) which will then account
for 25% of the performance score.

Here is a comparison of the metrics that are used to calculate the performance
in Lighthouse 8 and Lighthouse 10.

<Image
  src="/images/lighthouse8-vs-lighthouse10.webp"
  alt="Lighthouse 8 vs Lighthouse 10 performance score metrics"
  caption="Lighthouse 8 vs Lighthouse 10 performance score metrics"
  width={762}
  height={1014}
/>

Google explains the removal of TTI as "being overly sensitive to outlier network
requests and long tasks." They say that other metrics are better heuristics and
tend to correlate better to the Core Web Vitals.

The shifted and increased score weight of CLS will **improve the performance the
score of about 90% of all websites**.

### Back/forward cache

Besides the removal of TTI and the increased score weight of CLS, there are two
completely new features in Lighthouse 10.

**Back/forward cache** will be added as a **new audit**. It will navigate away
from the test page, go back to it to see if it's bfcache-able.

[Bfcache](https://web.dev/bfcache/) will restore the page layout and execution
state nearly instantly, improving the user experience dramatically. However, if
the website prevents the browser from restoring a page from bfcache, the audit
will be impacted negatively and list reasons for the failure.

### Paste-preventing Inputs

Another new audit is **paste-preventing-inputs**. It will check if users can
paste into any input fields on the page. Before that, there was only a check for
password fields. Paste-preventing is a net-negative user experience and should
be avoided.

Some significant improvements to Lighthouse! They are available in the CLI tool,
right away and they will land in Chrome stable in Chrome 112.


Lighthouse 10 was released recently and included some significant new features. In this Today-I-learned Post will have a look at everything new.

What's new in Lighthouse 10


Every week or so a new hot topic gets discussed eagerly in the web development
community. This week it was about the necessity of **return types** in
TypeScript.

A few years ago, when I learned TypeScript, my colleagues taught me that return
are absolutely necessary. I thought it was a no-brainer to define them. I felt
good writing a function and then specifically add the return type.

But as you might have already guessed, I got convinced otherwise last week. To
be clear, there seems to be no absolut consensus about this topic. But I decided
that return types in TypeScript are not necessary and I won't define them
anymore. I'll tell you why.

In TypeScript there are two ways to deal with return types. You can define them
**explicitely** or you can let TypeScript **infer** them.

After listening to all the arguments about the necessity of return types, I came
to a conclusion.

For most of the code I write, I don't need return types. Because if I define
return types I just tell TypeScript what it **already knows**.

But as soon as a function I write is more complex, like containing a switch or
an if statement I will define the return type.

The videos by Matt Pocock
[Don't use return types, unless...](https://www.youtube.com/watch?v=nwSe95uFN8E)
and by Theo
[The Dangers of Return Types in JavaScript](https://www.youtube.com/watch?v=I6V2FkW1ozQ)
helped me to understand the topic better.

As I already mentioned there is no right or wrong here, it just seems to be a
preference. My preference is infer return types whenever possible, define return
types only when TypeScript can't infer them properly.


Today I learned about the discussion if return types are necessary in TypeScript or not.

I'm Marco - a Freelance Web Developer and I make websites.

Hi, and welcome!

Web projects

Stuttgarter Kickers

Dieda

Aerosol Alliance

What others are saying about me

Latest blog posts

Developer Diaries 15

How to build an E-Commerce website with Shopify Hydrogen V2 and Sanity

Developer Diaries 14

Latest TIL posts