DEV Community: Vanessa Otto

The Surprisingly Weird World of Favicons (And How to Survive It)

Vanessa Otto — Mon, 14 Apr 2025 00:00:00 +0000

Not a year goes by without another "how to use favicon this year" article. Let's recap what has changed over the years: Favicons began as simple .ico files introduced by Microsoft with Internet Explorer 5 in 1999. These were small, square icons, typically in resolutions of 16×16 or 32×32 pixels. The .ico file format can support images up to 256×256 pixels. They were designed to appear in browser tabs, bookmarks, and address bars.

To add a favicon to a web page, we add a line of code to the <head> section of an HTML page:

<link rel="icon" type="image/x-icon" href="/favicon.ico">

Over time, the format evolved to support more modern web standards and higher resolution displays. Developers began using formats such as PNG, SVG, and even adaptive icons for mobile platforms, leading to the rise of specialized favicon generators and meta tag configurations. Modern favicons now often include multiple sizes and formats to accommodate different devices, operating systems, and browser requirements, becoming a small but surprisingly complex part of web development. So-called "Apple Touch Icon" sizes are designed to provide optimized icons for different Apple devices and screen resolutions, ensuring a crisp display when a user saves a website to their Home screen. Each size corresponds to specific devices - from older iPhones and iPads (e.g., 57×57, 72×72) to modern Retina displays (e.g., 120×120, 180×180) - and allows iOS to choose the most appropriate icon. So in 20 years, we went from having to worry about an .ico file to a list that looks something like this:

<link rel="apple-touch-icon" sizes="57x57" href="/apple-icon-57x57.png">
<link rel="apple-touch-icon" sizes="60x60" href="/apple-icon-60x60.png">
<link rel="apple-touch-icon" sizes="72x72" href="/apple-icon-72x72.png">
<link rel="apple-touch-icon" sizes="76x76" href="/apple-icon-76x76.png">
<link rel="apple-touch-icon" sizes="114x114" href="/apple-icon-114x114.png">
<link rel="apple-touch-icon" sizes="120x120" href="/apple-icon-120x120.png">
<link rel="apple-touch-icon" sizes="144x144" href="/apple-icon-144x144.png">
<link rel="apple-touch-icon" sizes="152x152" href="/apple-icon-152x152.png">
<link rel="apple-touch-icon" sizes="180x180" href="/apple-icon-180x180.png">
<link rel="icon" type="image/png" sizes="192x192" href="/android-icon-192x192.png">
<link rel="icon" type="image/png" sizes="32x32" href="/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="96x96" href="/favicon-96x96.png">
<link rel="icon" type="image/png" sizes="16x16" href="/favicon-16x16.png">
<link rel="manifest" href="/manifest.webmanifest">

Okay, I admit I cheated a bit in the code snippet above. When I tested the tool, it gave me a manifest.json and not a manifest.webmanifest. See footnote ¹ for more information. We will use the .webmanifest file for the rest of this article.

Manifest

Wow, that's a lot. So what is this manifest.webmanifest? Let's take a look at a sample manifest file:

{
 "name": "Vannsl's Blog",
 "icons": [
  {
   "src": "/icon-36x36.png",
   "sizes": "36x36",
   "type": "image/png"
  },
  {
   "src": "/icon-48x48.png",
   "sizes": "48x48",
   "type": "image/png"
  },
  {
   "src": "/icon-72x72.png",
   "sizes": "72x72",
   "type": "image/png"
  },
  {
   "src": "/icon-96x96.png",
   "sizes": "96x96",
   "type": "image/png"
  },
  {
   "src": "/icon-144x144.png",
   "sizes": "144x144",
   "type": "image/png"
  },
  {
   "src": "/icon-192x192.png",
   "sizes": "192x192",
   "type": "image/png"
  }
 ]
}

The <link rel="manifest" href="/manifest.webmanifest"> tag points to a Web App Manifest file, which provides metadata about a web application in JSON format. This file contains information such as the name of the application, icons in different sizes, theme colors, display mode (full screen, standalone, etc.), and more. It's especially important for progressive web apps (PWAs) because it allows browsers (especially on Android) to provide "add to home screen" functionality with proper icons and branding. More information about this can be found on the web app manifest page.

Implementation

So... do you have to remember all the different formats and sizes? Write all the HTML yourself, create all the favicons? Of course not! But be careful about using NPM packages and libraries to create them for you. Let me explain why.

When I built this blog with Eleventy by forking the eleventy-base-blog repository, I also checked if there was a favicon plugin available. And I found this one. This plugin has two bugs:

Since the last update to the repository was 4 years ago, I think it's fair to say that it's deprecated. While this isn't a problem per se- (it really isn't!). Of course we can use "deprecated" software! But that's another topic for another time)-it unfortunately comes with vulnerable dependencies. So to use it, you'd have to fork it, update the dependencies yourself, make a pull request, wait for it to be published-or use your fork as a plugin.
The README says: "Currently, the plugin does not generate the manifest.json suggested by this article". But as we learned above, we might want one.

So... actually creating all the favicons and writing the HTML and manifest is it? No, still not! The rest of this article is another shout-out to the amazing Tiny Helpers website by [Stefan Judis]. Because it's got you covered! You can use the Favicon Generator² to convert an image from PNG to ICO, from JPG to ICO, or from GIF to ICO, as well as all application icons. The .zip file also contains the manifest. You may also want to rename manifest.jsontomanifest.webmanifest^1:1.

But wait—do we really need all of this?

No, maybe not. In the code above, you can see that I used PNG files for favicons. But we have something better: SVGs. [SVG favicons are supported by some modern browsers (https://caniuse.com/link-icon-svg). And for browsers that do not support them, we can still add the .ico file as a fallback. This again reduces the LOC to something like this:

<link rel="icon" href="/favicon.ico" sizes="16x16">
<link rel="icon" href="/favicon.svg" sizes="any" type="image/svg+xml">
<link rel="manifest" href="/manifest.webmanifest">

Again, you can use the Favicon Generator^2:1 to create the 16×16px fallback .ico file. Again, it comes with a manifest file. However, I'd advise you to modify the HTML output the tool provides. When I tested it, the favicon Generator did not set the sizes attribute of the .ico file to 16x16, but to any. This can cause Chrome to pick the .ico file instead of the .svg file as Colby Fayock explained in his article.

If you want to make it as simple as it was in 1999, you can also just provide the SVG file:

<link rel="icon" href="/favicon.svg" type="image/svg+xml">

Browsers that do not support SVG favicons will create some sort of fallback. For example, this is the google.com favicon in a Chromium browser. And in Safari, the browser falls back to a simple "G" on a gray background. You can see this effect in the screenshot below, looking at the left tab in both browsers (Chrome on top, Safari on bottom). On the right tab, I opened vannsl.io, which uses .png favicons that work in both browsers.

PNG vs. SVG: What to do?

Personally, I will stick with the PNG solution. As I have shown, it is not difficult to create them with the tools provided. I prefer crisp and beautiful favicons on all devices and screen sizes. I don't want to see a 16×16px .ico fallback on a 5K display. (Not that I have one 🤑) However, the SVG solution has better performance and maintainability. You don't have to worry about different resolutions anymore. The SVG file will scale and look good even on a 5K display. It is also very small in size and you will save some bytes, which might be what you prefer! There is another reason why you might want to go with SVGs - because you can play around with them, as described in the next section.

SVG Favicons Dark Mode

Using SVG means that you can add a <style> block. Adding <style> means you can add a dark mode. You can find a demo here on GitLab along with its GitLab repository and a demo here on GitHub along with its GitHub repository.

The favicon contains embedded CSS that changes colors based on the user's system color scheme (light or dark mode). This is achieved by using the prefers-color-scheme media query within the SVG.

<!-- The SVG code of this favicon originally came from the Random Favicon Generator: https://toolcool.org/random-favicon-generator/ and was modified to accept dark mode colors. -->
<svg xmlns="http://www.w3.org/2000/svg" width="250px" height="250px" viewBox="0 0 24 24" stroke-width="1.00" fill="none" stroke-linecap="round" stroke-linejoin="round">
  <style xmlns="http://www.w3.org/2000/svg">
    .favicon-fill {
      fill: rgb(244, 255, 141);
    }

    .favicon-stroke {
      stroke: black;
    }

    @media (prefers-color-scheme: dark) {
      .favicon-fill {
        fill: black;
      }

      .favicon-stroke {
        stroke: rgb(244, 255, 141);
      }
    }
  </style>
  <circle class="favicon-fill" cx="50%" cy="50%" r="50%" stroke="none" stroke-width="0" />
  <g class="favicon-stroke" transform="translate(2.40, 2.40) scale(0.8)">
    <path stroke="none" d="M0 0h24v24H0z" fill="none"/>
    <rect x="4" y="4" width="16" height="16" rx="2"/>
    <line x1="4" y1="16" x2="20" y2="16"/><path d="M4 12l3 -3c.928 -.893 2.072 -.893 3 0l4 4"/><path d="M13 12l2 -2c.928 -.893 2.072 -.893 3 0l2 2"/>
    <line x1="14" y1="7" x2="14.01" y2="7"/>
  </g>
</svg>

The following images show the Safari, Chrome, and Firefox browsers (from left to right) in light and dark mode. Safari does not use the SVG favicon, but an .ico fallback. Chrome and Firefox show the SVG favicon in the correct color mode. Chrome requires a tab reload to update the icon when changing the color mode.

The following images show only the tabs with the favicons:

Troubleshooting

If you're playing around with favicons, be sure to set the sizes correctly, as shown here:

<link rel="icon" href="/favicon.ico" sizes="48x48" />
<link rel="icon" href="/favicon.svg" sizes="any" type="image/svg+xml" />

Otherwise, at least Chrome will take the .ico fallback even though it could render an SVG favicon.

You might see manifest.json and manifest.webmanifest files. As defined in the specs it should be .webmanifest. However, currently both formats are working. People discussed this on a W3C GitHub issue. I'd recommend using .webmanifest because: a) it's what the specs say and b) (I think) VS Code can be configured to check .webmanifest files explicitly against the schema needed for a manifest and therefore also provides autocompletions. I have not tested this though. ↩︎ ↩︎
You can find these and other useful websites on Tiny Helpers from Stefan Judis. ↩︎ ↩︎

Modern Image Formats on the Web: WebP and AVIF Without the Headache

Vanessa Otto — Mon, 07 Apr 2025 00:00:00 +0000

Tired of seeing this Google Lighthouse diagnostic?

Those fancy modern image formats that supposedly only work in Chrome? Maybe you've considered using progressive enhancement—serving AVIF to capable browsers and falling back to JPEGs for the rest—but it all sounds a bit too complicated?

Let's take a proper look at what's possible in 2025 and how easy it actually is to use modern formats.

🧱 HTML Implementation: The `<picture>` Element

Let's start with the trusty <picture> tag:

<picture>
  <source type="image/avif" srcset="/image.avif 1000w">
  <source type="image/webp" srcset="/image.webp 1000w">
  <img loading="lazy" decoding="async" src="/image.jpeg" alt="My image" width="1000" height="1000">
</picture>

The <picture> element allows the browser to choose the best image format: AVIF, WebP, or JPEG as a fallback. The loading="lazy" attribute delays loading the image until it's near the viewport, which helps improve page load speed. The decoding="async" attribute decodes the image in the background, allowing the page to render faster without waiting for the image to finish decoding. While the number 1000 here is only an example, explicitly setting width and height helps the browser allocate the correct layout space before the image loads, which improves visual stability and avoids layout shifts—especially important for Core Web Vitals. Additionally, the srcset attribute allows the browser to choose the most appropriate image based on screen size and resolution.

According to w3schools, browser support for <picture> is excellent.

🎨 CSS Option: `image-set()` for Backgrounds

If you're dealing with background images instead of inline <img> elements, CSS offers a similar mechanism:

.element {
  background-image: image-set(
    url("image.avif") type("image/avif"),
    url("image.webp") type("image/webp"),
    url("image.jpg") type("image/jpeg")
  );
}

This is supported in Safari 17+ , as seen on Can I use.

For most use cases, you'll be covered using either <picture> for inline images or image-set() for backgrounds. However, because browser support for <picture> is more consistent, it's usually the safer choice. When possible, avoid using background images for critical content.

In October 2024, I talked about the image-set() CSS functional notation with my Working Draft Co-Host Schepp in the episode Revision 635: State of CSS 2024, Teil 3/3.

🛠️ Converting Images to WebP and AVIF

So how do you actually get your images into WebP or AVIF? While online tools exist, they're often a black box—you don't always know what optimizations or metadata stripping might be happening behind the scenes. Not to mention the privacy aspect of uploading your files.

If you're more comfortable on the command line and prefer open-source tooling, you're in luck.

🎬 Conversion via `ffmpeg`

On macOS (or any system with ffmpeg installed), you can convert a JPEG to AVIF with:

ffmpeg -i image.jpg -c:v libaom-av1 -crf 30 -b:v 0 image.avif

Let's break down what each part of this command does:

ffmpeg: This is the command-line tool for processing video, audio, and images. It supports a variety of formats and codecs, making it an excellent choice for converting media files.
-i image.jpg: This specifies the input file. In this case, we’re using image.jpg as the source file. The -i option tells ffmpeg which file to process.
-c:v libaom-av1: This option sets the codec to use for the video (or in this case, the image). libaom-av1 is the encoder for the AVIF format, specifically using the AV1 codec, which is known for excellent compression and quality.
-crf 30: The Constant Rate Factor (CRF) controls the output quality. Lower CRF values result in better quality (and larger file sizes), while higher CRF values reduce the quality and the file size. In this case, 30 is a reasonable value for a balance between quality and file size. Typically, CRF values range from 0 (best quality) to 51 (worst quality).
-b:v 0: This option controls the target bitrate. When set to 0, it tells ffmpeg to use variable bitrate encoding, where the bitrate adjusts based on the complexity of the image to maintain a consistent quality throughout. For AVIF, this is usually set to 0 for the best results.
image.avif: This is the output file. ffmpeg will take the input file image.jpg, convert it, and save it as image.avif.

🧪 Conversion via Sharp (Node.js)

Instead of manually converting files every time, consider scripting it—either as a part of your build pipeline or as a simple CLI tool. For this, create a script to convert your images in your project using Sharp, a fast image processing library for Node.js.

I published a repository node-convert-sharp with a basic script. Here's a streamlined version of such a script:

#!/usr/bin/env node

import sharp from 'sharp';
import path from 'path';
import fs from 'fs/promises';
import { fileURLToPath } from 'url';

const __filename = fileURLToPath(import.meta.url);
const __dirname = path.dirname(__filename);

const inputPath = path.join(__dirname, 'input.jpg');
const outputDir = path.join(__dirname, 'output');
await fs.mkdir(outputDir, { recursive: true });

const baseName = path.basename(inputPath, path.extname(inputPath));

// Convert to WebP
try {
  await sharp(inputPath)
    .toFormat('webp')
    .toFile(path.join(outputDir, `${baseName}.webp`));
  console.log('✅ WebP success');
} catch (err) {
  console.error('❌ Error WebP:', err);
}

// Convert to AVIF
try {
  await sharp(inputPath)
    .toFormat('avif')
    .toFile(path.join(outputDir, `${baseName}.avif`));
  console.log('✅ AVIF success');
} catch (err) {
  console.error('❌ Error AVIF:', err);
}

🧰 Running the Script

Install sharp:
Ensure your package.json includes:
Make the script executable:
Run it:

Because of the #!/usr/bin/env node shebang at the top, there's no need to call node convert.js explicitly—the OS will handle it for you.

✅ Final Thoughts

Using modern image formats doesn't have to be a headache. With good browser support, native HTML and CSS solutions, and reliable open-source conversion tools, there's little excuse not to start using WebP and AVIF today.

Faster pages, smaller files, happier users.

Between Diapers and Development – How My Blog Came to Life with Eleventy

Vanessa Otto — Sun, 06 Apr 2025 06:27:55 +0000

📝 Originally published on 2025-03-30 on my blog:

https://blog.vannsl.io/blog/between-dialpers-and-development/between-diapers-and-development/

Foreword

I worked continuously as a software developer for 13 years and 3 months. No gaps, not even a month-long break. And then? Suddenly, maternity leave and parental leave were upon me. Well, after an entire pregnancy, it wasn't that sudden. But I still wasn’t prepared for months of "not working." And yes, every parent is probably laughing out loud at the phrase "parental leave" and "not working." Before, I thought a 40-hour job was full-time. Oh, how naïve.

Time during parental leave is limited, and life is completely dictated by the baby. When you eat, sleep, or shower—all of it revolves around the baby. And then, suddenly, there are unexpected windows of time when the baby sleeps longer than expected or someone else takes over. And you find yourself standing there, thinking: "Now what?" Housework? Meh. Starting an 800-page fantasy epic? Too much commitment.

What I missed the most? Gaming and working. So, I started again. Just 7.5 weeks after giving birth, I ended my break from the Working Draft podcast early and returned while the baby was with its dad. Still, I had plenty of time when the baby napped in the carrier during the day. Because during the day, sleeping only happens when tightly strapped to me in a carrier—preferably while I'm bouncing on a gym ball.

So, I divided my time 50/50 between game consoles and my laptop. Always with headphones, of course. But what was I actually doing on the laptop? I had always wanted to set up a tech blog! The real question was: why had I never managed to do it before giving birth?

The "Right" Tool

The frontend ecosystem offers countless frameworks for blogs. I wanted to take my time, test different tools, weigh the pros and cons, and make the best choice. On my mental shortlist were:

VitePress and Nuxt Content because I usually work with Vue. Solid, Astro, and Qwik because I heard a lot about them at conferences. But are those the right criteria? Well, it depends. For companies, it might be relevant how many developers are interested in a framework—to ensure they can find enough skilled people for projects.

However, as we discussed in Revision 656 (link to come once the episode is released) of Working Draft, we believe developers should be able to work with any framework. Besides, I'd be working on this project alone.

To maximize learning, I could choose something new. Normally, I consider that a valid reason. But given my limited time, that wasn't a priority for me. Another criterion could be long-term viability: Is there a large core team and an active community? Well, who still remembers AngularJS? From Google? And didn’t Facebook/Meta start Jest? I wouldn’t rely too much on that.

I built my portfolio website vannsl.io with Sapper years ago—the predecessor of the SvelteKit framework. But guess what? It’s still running on Sapper. I never rewrote it because I had no real reason to.

So, my decisive criterion was simple: My baby is sleeping now—so I need to move fast. No long learning curves, no complex setup.

As Tobias Struckmeier aptly put it:

"Imho usually the software chosen doesn't matter a lot to my experience. It's the dedication and love put in and in case of a blog anyway the content that makes the gold."

So, I abandoned the idea of a grand evaluation. I needed a domain and hosting, but everything had to be as quick and pragmatic as possible.

Domain and Hosting

In Revision 648: Personal Web Sites, Matthias Ott discussed personal websites and the Indie Web concept with my Working Draft co-hosts Schepp and Peter. The idea? Host your own content instead of relying on platforms like Medium or dev.to. Sounded great—but self-hosting? I simply didn’t have the time.

Buying a new domain? I had vanessaotto.de with Strato, but only for email. My other domains were with Hover. I noticed vanessaotto.com was still available on Strato. Tempting. But the thought of transferring domains or changing plans? No way.

Pragmatism won: The blog now runs on blog.vannsl.io, a subdomain of my already Netlify-hosted portfolio site. Setup time thanks to Netlify DNS? Less than five minutes.

The Tool Decision

My main requirements:

Manage blog posts as Markdown files.
Work on it anytime without a steep learning curve.

I first tried VitePress, thinking it would be easy for me. I followed the Getting Started Guide. But even during setup, I realized: I'd need time to explore themes, actions, and features. I’d need at least an afternoon with full focus. The baby was already stirring in the carrier—so no time for that.

Then I remembered Eleventy. I had heard about it from people who don’t typically follow framework hypes. For example, Stefan Baumgartner’s blog and the Working Draft website both use it. That idea appealed to me. Perfect.

A YouTube tutorial showed me: I only need HTML, JSON, and Markdown. Eleventy automatically generates the routes. Exactly what I was looking for. And Schepp told me that I could even integrate Vue later.

I browsed 11tybundle.dev for inspiration and quickly found a starter template I liked.

I heard rumors about the 100% Lighthouse Score of websites written with Eleventy before. I do not want to talk about Google Lighthouse scores in this article and swallow all my opinions, knowledge and thoughts about this topic now. So, a 100% score should be the default for such a simple website loading basically only HTML and CSS, and maybe a font and one or two lazy loaded images. However, it's still nice to see the confetti after running Google Lighthouse:

The Trade-offs

Normally, I would have:

Picked a color palette from Color Hunt¹.
Checked contrast with Accessible Brand Colors¹.
Created a custom favicon Random Favicon Generator¹.
Set up SEO meta tags.
Chosen a nice font.

Instead, I:

Used the base project’s colors.
Recycled the favicon and primary colors from vannsl.io.
Meta tags and OG images? Uh, maybe later.

And now? Now, I write. Between diaper changes and code. Thanks to Stefan Temme for inspiring this article's title.

You can find these and other useful websites on Tiny Helpers from Stefan Judis. ↩

Zwischen Wickeln und Entwickeln - Wie mein Blog mit Eleventy entstand

Vanessa Otto — Sun, 06 Apr 2025 06:20:53 +0000

📝 Ursprünglich veröffentlicht am 26.03.2025 auf meinem Blog:

https://blog.vannsl.io/blog/zwischen-wickeln-und-entwicklen/

Vorwort

13 Jahre und 3 Monate habe am Stück als Softwareentwicklerin gearbeitet. Lückenlos, nicht einmal ein Monat Pause. Und dann? Plötzlich stand Mutterschutz und Elternzeit an. Na gut, so plötzlich war es nach einer ganzen Schwangerschaft auch nicht. Aber vorbereitet auf mehrere Monate "nicht arbeiten" war ich dennoch nicht. Und ja, alle Eltern lachen nun laut auf bei den Worten "Elternzeit" und "nicht arbeiten". Ich dachte ja vorher ein 40-Stunden-Job sei Vollzeit. Hachja.

Die Zeit in der Elternzeit ist begrenzt, und das Leben ist fremdgesteuert. Wann man selbst isst, schläft, oder duscht – alles richtet sich nach dem Baby. Wenn sich dann plötzlich Zeitfenster auftun, in denen das Baby unerwartet lange schläft oder jemand anderes es übernimmt, steht man erst einmal da und fragt sich: "Und jetzt?" Haushalt? Meh. Ein 800-seitiges Fantasy-Epos anfangen? Zu viel Commitment. Was mir am meisten fehlte? Zocken und Arbeiten. Also fing ich wieder damit an. Nur 7,5 Wochen nach der Geburt beendete ich daher vorzeitig meine Pause vom Working Draft Podcast, und kehrte wieder zurück, während das Baby bei Papa war. Dennoch blieb mir doch noch recht viel Zeit, in der das Baby bei mir tagsüber in der Trage schlief. Denn tagsüber wird ausschließlich geschlafen, wenn es in der Trage fest an mich gezurrt ist und ich am besten noch dazu auf einem Gymnastikball bounce. Also teilte ich diese Zeit 50/50 zwischen Spielkonsolen und Laptop auf. Immer mit Kopfhörern, versteht sich. Aber was mache ich nun eigentlich am Laptop? Ich wollte doch schon immer mal einen Tech Blog aufsetzen! Die Frage war nur: Warum hatte ich das vor der Geburt nie geschafft?

Das "richtige" Tool

Im Frontend-Ökosystem gibt es zahlreiche Frameworks, die sich für Blogs eignen. Ich wollte mir Zeit nehmen, verschiedene Tools zu testen, Vor- und Nachteile abzuwägen und die beste Wahl zu treffen. Auf meiner mentalen Liste standen:

VitePress und Nuxt Content, weil ich üblicherweise mit Vue arbeite. Solid, Astro und Qwik, weil ich auf Konferenzen viel über die Tools hörte. Doch sind das die richtigen Auswahlkriterien? Naja, es kommt darauf an. Für Firmen mag es relevant sein, wie viele Entwickler:innen sich für ein Framework interessieren, um genügend gute Leute für Projekte zu finden. Wobei, wie in Revision 656 (Link folgt, sobald die Episode released ist) des Working Draft besprochen, finden wir, dass Entwickler:innen schon irgendwie mit allen Frameworks klarkommen sollten. Davon abgesehen, werde ich alleine an diesem Projekt arbeiten. Um einen Lerneffekt zu erzielen, könnte man etwas wählen, das man noch nicht kennt. Das finde ich normalerweise einen sehr validen Grund. Nur, was das aufgrund meiner begrenzten Zeit nicht für mich relevant. Ein anderes Kriterium, könnte sein, dass das Framework möglichst lange noch existiert und es ein großes Core-Team und eine nette Community hat. Na, wer erinnert sich noch an AngularJS? Von Google? Und hat Facebook/Meta nicht Jest angefangen? Ich behaupte mal, da kann man sich nicht allzu sehr darauf verlassen. Meine Portfolio Webseite vannsl.io schrieb ich vor einigen Jahren mit Sapper. Das ist der Vorgänger des Meta-Frameworks SvelteKit von Svelte. Aber soll ich euch etwas sagen? Es läuft immernoch mit Sapper. Ich habe mich nie darum bemüht, es neu zu schreiben. Weil ich keinen richtigen Grund dafür habe. Für mich gab es also nur noch ein entscheidendes Kriterium: Mein Baby schläft jetzt – also muss es schnell gehen. Keine langen Lernkurven, keine komplexe Setup-Phase.

Wie Tobias Struckmeier treffend sagte:

"Imho usually the software chosen doesn't matter a lot to my experience. It's the dedication and love put in and in case of a blog anyway the content that makes the gold."

Also ließ ich den Gedanken an eine große Evaluierung fallen. Ich brauchte eine Domain und ein Hosting, aber alles musste so schnell und pragmatisch wie möglich gehen.

Domain und Hosting

In Revision 648: Personal Web Sites spricht Matthias Ott mit meinen Working Draft Cohosts Schepp und Peter über das Erstellen persönlicher Webseiten und das Konzept des Indie Webs. Die Idee: Inhalte selbst hosten, statt auf Plattformen wie Medium oder dev.to zu posten. Klingt gut, aber Selbsthosting? Dafür fehlte mir schlicht die Zeit.

Eine neue Domain kaufen? vanessaotto.de hatte ich zwar bei Strato, aber in einem Tarif, der nur für E-Mails taugt. Meine anderen Domains liegen bei Hover. Auf Strato sah ich, dass vanessaotto.com auch noch frei wäre. Verlockend. Die Idee, jetzt noch Domains zu transferieren oder Tarife zu ändern, ließ ich schnell fallen. Pragmatismus siegt: Der Blog läuft jetzt auf blog.vannsl.io, einer Subdomain meiner bereits auf Netlify gehosteten Portfolio-Seite. Setup-Zeit dank Netlify DNS? Weniger als fünf Minuten.

Die Tool-Entscheidung

Meine Hauptanforderungen:

Blogartikel als Markdown-Dateien verwalten.
Jederzeit daran arbeiten können, ohne mich lange reinfinden zu müssen.

Erst probierte ich VitePress aus. Ich dachte, das sollte mir leicht fallen. Ich ging ein paar Schritte durch den Getting Started Guide. Schon beim Setup merkte ich: Ich müsste mich mit Themes, Actions und Features beschäftigen. Dafür bräuchte ich zumindest einen Nachmittag mit vollem Fokus Zeit. Das Baby wackelte aber bereits in der Trage – also keine Zeit für langes Einarbeiten. Noch nicht einmal in vermeintlich einfache Tools.

Da erinnerte ich mich an Eleventy. Ich hatte es immer wieder von Leuten gehört, die normalerweise keine Framework-Hypes mitmachen. Zum Beispiel laufen Stefan Baumgartners Blog und die Working Draft Webseite darauf. Und den Gedanken etwas zu nutzen, das ich nicht mit einem Hype verband, fand ich erstaunlich verlockend. Perfekt.

Ein YouTube-Tutorial zeigte mir: Ich brauche nur HTML, JSON und Markdown. Die Routen generiert Eleventy automatisch. Exakt das, was ich suchte. Und von Schepp erfuhr ich, dass es möglich sei, Vue später mit in das Projekt hinzuzufügen.

Zur Inspiration ging ich auf die Webseite 11tybundle.dev. Diese beinhaltet einen guten Überblick über aktuelle Releases von Plugins, Blogartikeln, und Webseiten, die Eleventy im Einsatz haben. Und für meine Situation perfekt: Es beinhaltet eine Liste an 27 Starter-Projekten, davon 10, die explizit für Blogs gedacht sind. Ich fand ich schnell ein Starter-Template, das mir gefiel.

Ich habe schon Gerüchte über den 100%-Lighthouse-Score von Websites gehört, die mit Eleventy erstellt wurden. In diesem Artikel möchte ich allerdings nicht über Google-Lighthouse-Scores sprechen und verschlucke daher all meine Meinungen, mein Wissen und meine Gedanken zu diesem Thema. Ein 100%-Score sollte bei so einer einfachen Website, die im Grunde nur HTML und CSS lädt – vielleicht noch eine Schriftart und ein oder zwei lazy geladene Bilder –, eigentlich der Standard sein. Trotzdem ist es schön, nach dem Ausführen von Google Lighthouse das Konfetti zu sehen.

Die Abstriche

Normalerweise hätte ich:

Eine Farbpalette über Color Hunt¹ gesucht.
Kontraste mit Accessible Brand Colors¹ getestet.
Ein individuelles Favicon erstellt (siehe Random Favicon Generator¹) .
Meta-Tags für SEO gesetzt.
Eine schöne Font gewählt.

Stattdessen:

Farben größtenteils vom Base-Projekt übernommen.
Das Favicon und primäre Farben von vannsl.io recycelt.
Meta-Tags und OG Images? Ähm. Kommen später. Vielleicht.

Das Layout ist simpel, und der einzige CSS-Breakpoint sitzt in der Welcome-Box der Startseite. Das Profilbild wird mobil über der Headline und auf Desktop rechts davon angezeigt. Das einzige andere selbst geschriebene CSS Feature ist die kurze Transition des Links in dieser Welcome-Box. Dazu inspirierte mich die Gestaltung der Links von Hans Christian Reinl.

Und jetzt? Jetzt schreibe ich. Zwischen Wickeltisch und Code. An dieser Stelle sei noch Stefan Temme gedankt, der für den Titel dieses Artikels gesorgt hat.

Diese und noch viele weitere nützliche Tools findet ihr bei der Webseite Tiny Helpers von Stefan Judis. ↩

Webpacker, Vue 3, and TypeScript

Vanessa Otto — Wed, 17 Mar 2021 08:07:16 +0000

Versions:

Webpacker 5
Rails 6
Vue 3

Foreword

Compared to Vue 2, Vue 3 is written in TypeScript. As we're used to, the official Vue Documentation is one of the best sources to find out more about how to configure TypeScript in Vue 3. Something that can bother is that most tutorials use the Vue CLI to show how simple TypeScript can be added to the codebase. Although the Vue CLI is a powerful tool and it is actually as simple as running one command to add TypeScript, not each project has the possibility to be configured with the CLI or Vite. This article explains how to add TypeScript to Vue 3 applications within Webpacker, the Webpack gem for Ruby on Rails Fullstack applications.

How to configure TypeScript in Vue 3

1. TS Loader

To install the TypeScript Loader, run:

yarn add ts-loader
# or npm ts-loader

2. TS Config

In the root directory of the Rails App, create the file tsconfig.json. The following JSON is an example of the configuration you could add. Of course, your settings might differ from those. Make sure to adapt the paths which files to include in the TypeScript Compilation (app/javascript/src/**/*.ts and app/javascript/src/**/*.vue) depending on your folder structure. Same for the alias in the paths settings (app/javascript/src/*)

{
  "compilerOptions": {
    "target": "esnext",
    "module": "esnext",
    "strict": true,
    "jsx": "preserve",
    "importHelpers": true,
    "moduleResolution": "node",
    "skipLibCheck": true,
    "esModuleInterop": true,
    "allowSyntheticDefaultImports": true,
    "sourceMap": true,
    "baseUrl": ".",
    "types": [
      "webpack-env"
    ],
    "paths": {
      "@/*": [
        "app/javascript/src/*"
      ]
    },
    "lib": [
      "esnext",
      "dom",
      "dom.iterable",
      "scripthost"
    ]
  },
  "include": [
    "app/javascript/src/**/*.ts",
    "app/javascript/src/**/*.vue",
  ],
  "exclude": [
    "node_modules"
  ]
}

HAVE YOU CHECKED THE PATHS? NO? READ ABOVE THE CONFIG AFTER COPY/PASTING! ;)

3. Webpack Loader

As explained in a previous article about How to add Vue 3 in Rails I put all webpack loaders in a folder called config/webpack/loaders. You can also create your loaders inline.

The Loader Configuration is:

module.exports = {
  test: /\.tsx$/,
  loader: "ts-loader",
  options: {
    appendTsSuffixTo: [/\.vue$/],
  },
  exclude: /node_modules/,
};

In the webpack configuration config/environment.js add the loader:

const ts = require("./loaders/ts");

// ...

environment.loaders.prepend("ts", ts);

Only for reference, this is how my full webpack configuration looks like:

const { environment } = require("@rails/webpacker");
const { VueLoaderPlugin } = require("vue-loader");
const { DefinePlugin } = require("webpack");
const path = require("path");
const vue = require("./loaders/vue");
const ts = require("./loaders/ts");

const customConfig = {
  resolve: {
    alias: {
      "@": path.resolve(__dirname, "..", "..", "app/javascript/src"),
      "~libs": path.resolve(__dirname, "..", "..", "app/javascript/lib"),
      "~images": path.resolve(__dirname, "..", "..", "app/javascript/images"),
    },
  },
};

environment.config.merge(customConfig);

environment.plugins.prepend("VueLoaderPlugin", new VueLoaderPlugin());
environment.plugins.prepend(
  "Define",
  new DefinePlugin({
    __VUE_OPTIONS_API__: false,
    __VUE_PROD_DEVTOOLS__: false,
  })
);
environment.loaders.prepend("ts", ts);
environment.loaders.prepend("vue", vue);
environment.splitChunks();
module.exports = environment;

4. Shims

To get the TypeScript Support working in Vue Single File Components, they have to be defined as a component. Quoting the official documentation about defineCompinent:

Implementation-wise defineComponent does nothing but return the object passed to it. However, in terms of typing, the returned value has a synthetic type of a constructor for manual render function, TSX, and IDE tooling support.

In your folder where your Vue Applications are located (e.g. app/javascript/src), add the file shims-vue.d.ts to add the Shim:

declare module '*.vue' {
  import type { DefineComponent } from 'vue'
  const component: DefineComponent<{}, {}, any>
  export default component
}

5. Linters and IDE Helpers

This is up to you. I use ESLint and Prettier. For IDE Support I switched from Vetur to Vue DX, but I can't strongly agree that you should do the same. The third member of the IDE Party is Volar, which I can totally recommend for pure Vue3+TS Projects, especially if you use the <script setup> syntactic sugar for using the Composition API. Try them out and check what works best for you.

🎉 You're done!

Usage

Vue and TS

Using Typescript in .vue files require the following steps:

Add lang="ts" to the <script> tag
Import defineComponent from vue
Export the component as defineComponent

Example:

<script lang="ts">
import { defineComponent } from "vue";

export default defineComponent({
  // ...
})

Type Declarations

Types can be found in file types.ts the source directory:

// app/javascript/src/types.ts

export interface Item {
  id: number;
  name?: string;
  // ...
}

Import types from that file:

import { Item } from "@/types";

Vue Data and Properties

Type Assertions

Using the as keyword objects were able to override empty objects types to a real type:

const futureItem = {} as Item

futureItem.id = 1;
futureItem.name = "New Item"

Vue Reactive Data Options API

With that, we can assign types to data attributes in .vue files:

<script lang="ts">
import { Item } from "@/types";
import { defineComponent } from "vue";

export default defineComponent({
  data() {
    return {
      items: [] as Item[],
      currentItem: {} as Item
    }
  }
})
</script>

Vue Reactive Data Composition API

TODO :)

Vue Properties

The same does not simply work for Vue Properties. Using the PropType, Generics are set for custom properties.

// Before
props: {
  item: {
    type: Object,
    required: true
  }
}

// Won't work
props: {
  item: {
    type: Item, // this is not valid JavaScript
    required: true
  }
}

// Won't work
props: {
  item: {
    type: Object as Item, // valid JavaScript, but no generic
    required: true
  }
}

// Works
import { defineComponent, PropType} from "vue";
import { Item } from "@/types";

export default defineComponent({
  props: {
    item: {
      type: Object as PropType<Item>,
      required: true
    }
  }
}

Vue Computed Properties and Methods Options API

Computed Properties and Methods don't need special TypeScript Handling in Vue.
Types can be applied as usual in TypeScript:

import { defineComponent, PropType} from "vue";
import { Item } from "@/types";

export default defineComponent({
  data() {
    return {
      items: [] as Item[],
      currentItem: {} as Item
    }
  },
  // Method Parameter types
  methods: {
    function addItem(newItem: Item) {
      this.items.push(newItem)
    }
  },
  // Computed Property Return Item
  computed: {
    firstItem(): Item {
      return this.items[0]
    }
  }
})

Eh, and now?

To learn how to use TypeScript ➡️ (e)Book TypeScript in 50 lessons

Nevertheless, Vannsl Coded, and Talked, and Wrote

Vanessa Otto — Mon, 08 Mar 2021 15:54:56 +0000

How it's like to be a Woman in Tech AMA

You ask I answer: Twitter Call AMA

What's the biggest shit you had to deal with as a public speaker?

I like the way the writer has phrased this question. It doesn't ask for "if" but "the biggest". There are several examples, but it comes down to three main shits.

Ok, I decided to talk first about the "Designer" question. That might also happen to males as well if they studied Mediainformatics as I did:

You're a designer

The first is that I am not only a developer, I have also a background in Human-Computer Interaction. That's a fancy way of saying: I had 4 semesters of psychology courses with a strong focus on Application Design. That's about how to structure components on webpages so they work on mobile and desktop. It's about UX Flows and Accessibility. That's why on some of my portfolios it says that I have a focus on UX Design ADDITIONALLY to being a programmer. I can't tell you how many times people tell in my face: "Hey it's so great that you're talking about Vue.js. I mean, for a designer!"

Conference Organizers

Countless times I received emails such as: "Do you want to speak at our event? We need a woman" I'm not super mad at this. In most cases, people actually meant it friendly, they were just bad with words. What was rather funny happened at a web conference, you know, web development. The thing with computers and stuff. My lanyard said "Vortragender", the German word for "male speaker". In the german language, the default words are usually male. It's different than in English. A developer can be male or female. But in German, we have explicit female endings. It would have been "Vortragende". Since it was on a conference that explicitly asked for a female speaker, I asked why on earth it says the male form. They answered with: "Oh, you know, we asked the (male) PHP developer 4 months ago but he said that he can't change it in the database". It took me a few seconds to progress that. But, apart from all the obvious things I could have asked now, I asked: Why haven't you manually written and printed my lanyard. Without the database. Or just hand-written it. They could not answer. They don't have a gender field in their database table of speakers. Every person is male by default.

Ok, so those were the funny parts. Now to the hurtful memories. When sitting at the speaker dinner, female speakers is usually a topic that comes up once in the evening. The funny thing is, that often males discuss is, sitting next to me, and don't ask for my opinion. Not all of course. The worst thing that happened was a person that was ugly inside. He talked about a small conference he is organizing himself and that he has to say it's blind voting, but obviously, it isn't. Because if it would be blind voting, all speakers would be male, and "someone would kick him in the balls for that". But there is no way that a female would be voted. They are just not as good as the men. Btw, two female speakers were sitting with him at the same table. It was awful.

I heard stories about speaker rooms that female speakers get asked if they're looking for their husband (or worse things). It didn't happen to me.

Conference Visitors

"That talk was really great!!! Especially for a woman!"
"Wow, you don't look like usual female developers. I mean, you don't look like a male."
"You're a designer, right?"

I am so sorry for all designers. I'm SO bad at UI Design. UX Design and Frontend Development are my strengths, but I don't have much practice in UI Design. I'm sorry that people tell me that I would be a designer like it is something less worthy.

Once I spoke at a "why speak at conferences" MeetUp. I had one personal photo in the beginning. It showed me doing a Spartan Obstacle Race. My story to that was that this event gave me so much confidence that I could translate into my job. On the MeetUp page, attendees could give feedback. One was "next time more personal pictures please". WHAT?!

How do you feel to be the only woman in an all-male podcast line-up?

Oh, very comfortable. You know, I am used to be the only female in all-male situations. The difference is the people. I was in situations with all-males because they scared females away. Of course, that's not nice. As long people are good people, I really don't care about their gender, race, age, whatever. If they are not nice, I don't like them. Simple as that. But the truth is, that I am not the only woman in the Podcast. We have a female person who does the post-production of the episodes. Unfortunately, you won't hear her on tape, but I know that she is there :)

What were your biggest challenges in taking/having leadership in software projects?

People have just a bit less trust or confidence than others would believe me. Or that I convince people about something. What I had to deal with was strategic discussions when it came to clients. Women (not men) thought it would be a smarter move to send a male developer, who had way less experience with the project as I did, to meetings about the planning of resources (Resources a.k.a real people).

Btw: Surprisingly, a lot of women have told me that I am not allowed to have a problem with the word "guys" because it's genderless. I don't respond to that anymore, I'm too tired. What happened at some company parties (before Corona) when people didn't know what I do for a living, they ask: "Are you doing Marketing?" 🤷‍♀️

Apart from this, I was really lucky. Most of the companies I worked for valued me for what I am: an incredible developer and wonder woman ;)

Vue3 on Rails

Vanessa Otto — Sun, 11 Oct 2020 17:09:48 +0000

Versions:

Rails 6
Vue 3

Foreword

At work, I do the frontend for the project ZAGE by The Life Company. The application is written in Rails. As I joined, I wanted to add Vue for some parts of the Frontend. But I couldn't find any tutorial on how to add Vue 3 to Rails. So, I wrote that tutorial, I was looking for.

What you should know at the end

This article explains how to install Vue 3 in a Ruby on Rails app. In the end, you should be able to implement a Vue app within an ERB view template. The code of this tutorial can be found in my Github Repository rails-vue3-app.

Content:

Introduction
Create Rails app
- Setup Rails app
- Install yarn
Install Vue3 & Co.
Configure Webpack environment
- Set an alias
- Vue Loader
- Include .vue files
- Set Vue properties
Create Vue app
- Create entry point and SFC
- Create Home controller and view as root route
- Connect Vue and Rails
Next Steps

Introduction

Evan You released the Vue 3 in September 2020. This article does neither focus on the new features like the Composition API nor explain nor explain how to migrate from Vue2 to Vue3. Check out the official documentation and migration guide for that.

While the Vue CLI and Vite are great tools to configure new Vue projects easily, current resources lack information on how to install Vue3 in existing codebases. When you have a Rails 5+ full-stack application, you most likely already have a webpacker configuration. As of the date I'm writing this article, Webpacker offers a skeleton for Vue 2 via rails webpacker:install:vue, but not for Vue 3 yet. I opened a PR, check the state here. So, let's dive right into how to add Vue3 into your tech stack.

Create Rails app (optional)

Setup rails app

To test the setup before adding it to your "real" codebase, you can create a new rails app.

rails new rails_vue3_app --webpack

I'm not a rails developer, so feel free to give me tips and hints, if there are other best practices for rails specific code and commands.

Install yarn

If the output of the previous command says something like:

Yarn not installed. Please download and install Yarn from https://yarnpkg.com/lang/en/docs/install/

...you need to install yarn and install the packages afterward.

npm i -g yarn
cd rails_vue3_app
yarn install

Install Vue3 & Co.

If you run your rails app inside of Docker, you don't need to install anything on your host machine. You can install the packages within your docker container.

To use Vue3, you'll need (guess what :) ) Vue in version 3, Vue-Loader in version 16 beta, and the SFC compiler.

Vue3 is released on npm with the tag next. The current version is still 2.6.x to prevent developers from having to migrate to Vue3 if they don't want to. The same applies to the vue-loader.

# in rails_vue3_app
yarn add vue@next vue-loader@next @vue/compiler-sfc

Check the package.json to see the installed versions. The minimal versions should be:

// ##############################
// package.json
// ##############################
{
  "name": "rails_vue_app",
  "private": true,
  "dependencies": {
    "@vue/compiler-sfc": "^3.0.0",
    "vue": "^3.0.0",
    "vue-loader": "^16.0.0-beta.8"
    // ...
  }
  // ...
}

Webpack environment configuration

Next, we need to tell Webpack what to do with *.vue files. For that, go to the file webpack/environment.js

By default, it should look like this:

// ##############################
// webpack/environment.js
// ##############################
const { environment } = require('@rails/webpacker')

module.exports = environment

Set an alias (optional)

I like to put my Vue applications into a separate folder. I also want to use a Webpack alias for an easier path handling when importing files. I did that with the following configuration:

// ##############################
// webpack/environment.js
// ##############################
// const { environment } = require('@rails/webpacker')
const path = require("path")

const customConfig = {
  resolve:{
    alias: {
      "@": path.resolve(__dirname, "..", "..", "app/javascript/src")
    }
  }
}

environment.config.merge(customConfig)

// module.exports = environment

Add Vue Loader

Now it's time to add the loader. It tells Webpack what to do with files that match to the Regex .vue.

// ##############################
// webpack/environment.js
// ##############################

// const { environment } = require('@rails/webpacker')
// const path = require('path')
const { VueLoaderPlugin } = require('vue-loader')

// const customConfig = {
//   resolve:{
//     alias: {
//      '@': path.resolve(__dirname, '..', '..', 'app/javascript/src')
//     }
//   }
// }

// environment.config.merge(customConfig)

environment.plugins.prepend(
    'VueLoaderPlugin',
    new VueLoaderPlugin()
)

environment.loaders.prepend('vue', {
    test: /\.vue$/,
    use: [{
        loader: 'vue-loader'
    }]
})

// module.exports = environment

Because I like to keep the file webpack/environment.js as clean and readable as possible, I outsourced the configuration of Vue in an own file within the folder webpack/loaders. By default it does not exist, so create it first using the terminal or your IDE. The end result should look like this:

// ##############################
// webpack/loaders/vue.js
// ##############################

module.exports = {
    test: /\.vue$/,
    use: [{
        loader: 'vue-loader'
    }]
}

// ##############################
// webpack/environment.js
// ##############################

// const { environment } = require('@rails/webpacker')
// const path = require('path')
const { VueLoaderPlugin } = require('vue-loader')
const vue = require('./loaders/vue');

// const customConfig = {
//   resolve:{
//     alias: {
//       '@': path.resolve(__dirname, '..', '..', 'app/javascript/src')
//     }
//   }
// }

// environment.config.merge(customConfig)

environment.plugins.prepend(
    'VueLoaderPlugin',
    new VueLoaderPlugin()
)

environment.loaders.prepend('vue', vue)

// module.exports = environment

Include .vue files

Next, open the file config/webpacker.yml and add .vue to the extensions:

// ##############################
// config/webpacker.yml
// ##############################

default: &default
  # ...


  extensions:
    # ...
    - .vue

Set Vue properties

It is strongly recommended to properly configure some properties of Vue in order to get proper tree-shaking in the final bundle. You can find more information in Vue3's README under Bundler Build Feature Flags.

// ##############################
// webpack/environment.js
// ##############################

// const { environment } = require('@rails/webpacker')
// const path = require('path')
const { DefinePlugin } = require('webpack')
// const { VueLoaderPlugin } = require('vue-loader')
// const vue = require("./loaders/vue");

// const customConfig = {
//   resolve:{
//     alias: {
//       "@": path.resolve(__dirname, "..", "..", "app/javascript/src")
//     }
//   }
// }

// environment.config.merge(customConfig)

// environment.plugins.prepend(
//     'VueLoaderPlugin',
//     new VueLoaderPlugin()
// )

environment.plugins.prepend(
    'Define',
    new DefinePlugin({
        __VUE_OPTIONS_API__: false,
        // or __VUE_OPTIONS_API__: true,
        __VUE_PROD_DEVTOOLS__: false
    })
)

// environment.loaders.prepend('vue', vue)

// module.exports = environment

Create a Vue app

Everything should now be correctly set up. It's finally time to add our first Single File Component and load it into a container.

Create entry point and SFC

As explained above, I'd like to collect all Vue related code in a single directory. Therefore, create the folder ./app/javascript/src in your root directory. In there, create the file main.js. It will be the entry point for the Vue application. Leave it empty as it is, we'll come back to it again.

Next, let's create a Vue component. I propose to create the folder ./app/javascript/src/components. In there, create the file HelloWorld.vue. You can name the file also hello-world.vue if you prefer that syntax. Insert the following code:

// ##############################
// app/javascript/src/components/HelloWorld.vue
// ##############################

<template>
  <p>
    {{ message }}
  </p>
</template>

<script>
import { ref } from 'vue'

export default {
  name: 'HelloWorld',
  setup() {
      const message = ref('Hello World')

      return {
        message
      }
  }
}
</script>

<style scoped>
p {
  font-size: 2em;
  text-align: center;
}
</style>

Of course you can write sassy CSS. Therefore add the lang attribute lang='scss' to the <script> section.

Now, let's head back to our main.js file and create the Vue app:

// ##############################
// app/javascript/src/main.js
// ##############################

import { createApp } from 'vue'
import HelloWorld from '@/components/HelloWorld.vue'

export default () => {
    document.addEventListener('DOMContentLoaded', () => {
        const app = createApp(HelloWorld)
        app.mount('#vue-app')
    })
}

Okay, let's recap what has happened. We created an SFC (Single File Component). We created a Vue instance and mounted it into an HTML element with the id vue-app. But what, we haven't written this element yet. So let's do that now.

Create Home controller and view as root route

For that, let's create a HomeController with a view. Alternatively, you can go directly to the .erb file you want to add the Vue app to.

rails generate controller Home index

Next, set the home controller as base route in config/routes.rb:

# -----------------
# config/routes.rb
# -----------------

# Rails.application.routes.draw do
#   get 'home/index'

  root to: 'home#index'
# end

Connect Vue and Rails

Finally, our configuration is done. Now we have a home page. We want to load the Vue app directly in this file. Head to app/views/home/index.html. Add or replace the dummy content with the following line:

<!-- app/views/home/index.html -->

<div id='vue-app'></div>

Let's check out what's going on in the browser. Open your terminal and start the rails and the Webpack server with:

# in one tab
rails server

# in another tab
./bin/webpack-dev-server

Open a browser and go to localhost:3000. If everything works, you should see nothing (but the dummy HTML code if you haven't removed it). When inspecting the DOM, there should be the empty div container with the id vue-app. Our last step to bring it all together is to import the entry point of our Vue application.

To keep it simple, we will add the entry point directly to the application.js in this tutorial. Of course, you can create a single pack for it. You can also use the split chunks feature of webpack(er). But for now, let's open app/javascript/packs/application.js and import our entry point:

// ##############################
// app/javascript/packs/application.js
// ##############################

// require("@rails/ujs").start()
// require("turbolinks").start()
// require("@rails/activestorage").start()
// require("channels")
import initVueApp from "@/main.js"

initVueApp()

Reload the page, you should see "Hello World" now! Have fun playing around with it for a while. Change the style, change the message, change the template. Don't forget, that you don't need to have a single root element in Vue3 anymore. Therefore no wrapping div container or similar.

Next Steps

Congratulations, you have just installed Vue3 in a Rails app. Next, we will talk about how to:

pass properties from Rails to Vue
configure Linters
configure TypeScript

Follow me to receive notifications, when I post those articles. I will link them here at the bottom of this article as soon as they're published.

Photo by Christian Holzinger on Unsplash

Tips for remote goodbyes

Vanessa Otto — Mon, 22 Jun 2020 07:36:41 +0000

Depending on the period of notice you or your coworker leaves a company while most of us are working from home during the Corona situation. The past goodbye parties may have included ordering food and drinks, preparing snacks, ordering some pizza, having BBQ, cleaning the kitchen. How does that look like for goodbyes over video conferences? 40 people (or so) in a video chat, 6 of them talking? So, the question is: what could one do to have a nice goodbye experience remotely?

Here are the key ideas of a nice remote goodbye evening:

📅 Plan ahead
⏲️ Breaks
👗 Dress Code / Motto
🖼️ Slide Show
🎲 Game/Quiz
🥤 Several rooms
📸 Group Photo

📅 Plan ahead

Since coworkers will have to buy their own snacks and drinks (unless you want to send all of them something ;) ) give them a chance to do so. Although there might be a lot of things left to do before leaving a company, don't forget about your party. Create a calendar appointment for one or two weeks beforehand. This makes it also easier for you to plan ahead further actions.

⏲️ Breaks

Dinner break

A helpful gesture for coworkers can be to split up the event in two events. One directly at the end of the business day. For example 6 pm depending on the usual working hours of the company. This appointment can be used for goodbye speeches and giving everyone the opportunity to speak up. Afterward, all of the attendees can take a break after sitting in front of a monitor for most of the day. This gives time to prepare dinner, help with the kids' homework, and whatever needs to be done. The party crew can meet again later at 8 or 9 pm with refreshed eyes and nothing left to do.

Small breaks

In the following, we'll discuss some activities. They imply that the attendees will stay in front of the screen and won't be able to get a fresh beverage. Small breaks (5-10 minutes) that you announce at the beginning of the event can help with that. Everyone can stay focused on activities and leave the computer during breaks.

👗 Have a dress code and/or a motto party

One possibility to increase the anticipation is to come up with a dress code or a motto for the party. Being dressed in the same color looks also nice in a tile layout of video conference tools.

A motto party idea can include everyone using a beach image or filter for the background but I would leave that decision to the individual people.

Another idea is to set up a list of specific food or drinks everybody can enjoy together remotely. This includes a bit of planning but should be feasible. Some ideas are Gin Tonic Friday, Vegetable Chips Thursday, or Wine Wednesday. But it should be made clear that non-alcoholic drinks, especially on evenings before a workday are a good, responsible and reasonable choice :)

🖼️ Slide Show

It's always nice to remember the past years working together by enjoying a photo show together. Here's the chance to get creative. Use a tool of your choice, e.g. iMovie or PowerPoint to gather all of the photos.

🎲 Game/Quiz Time

To involve everyone in the room, it's time to play a game. The options are limitless. Maybe you already had a game you've always played in the office and find an online solution for that. To get a personal touch into the game, you can create a quiz (e.g. using kahoot) including questions on which projects you've been working on, what the name of your kids is of whatever you'd like to tell people.

🥤 Prepare rooms

Since there are already some events going on in the main video chat (e.g. a Slide Show or a Quiz), people won't be able to have meaningful conversations outside the breaks. Depending on how many attendees there are, it could make sense to prepare several video chat instances for people to split up. A nice side effect is that you can give those rooms the names of the original rooms of the office. Ideas are "kitchen" and "balcony" or special meeting room names you might have at your place.

📸 Group Photo

Not being in the same room does not imply that there can't be photos made together. Just that these photos ar screenshots. There is only one very important rule: Ask all of the attendees if it's okay to make that screenshot. If some are not, shutting off the camera or leaving the video call for half a minute are possible fallbacks.

(If Google Meet is used, there is a helpful browser extension called Grid View to see more tiles than usual on the screen)

🎉🥳🎊 Have a great party 🎉🥳🎊

Photos of this article:

Cover image: Photo by Erik Mclean on Unsplash
Breaks: Photo by Toa Heftiba on Unsplash
Game: Photo by Windows on Unsplash
Photo: Photo by Duy Pham on Unsplash

Playwright (vs. Puppeteer): Cross-Browser Testing done right

Vanessa Otto — Sun, 24 May 2020 15:08:13 +0000

Playwright version: v1.0.2

The ecosystem of Frontend Development changes rapidly. This is a curse and a blessing at the same time. The choice of tools frontend developers grows, too. Before reading the whole documentation of a new tool, install it, and start writing testing code, frontend developers might want to make sure it is worth the time and effort before.

So what is Playwright? Is it an additional testing tool? Does it replace a known framework like Jest or Cypress? Let's dive right into these questions:

What is Playwright?
Which role does Playwright play?

What is Playwright?

Playwright is an automated UI testing tool. It's a Node.js library that enables developers to run E2E tests in modern browsers: Chromium, Firefox, WebKit, and even Microsoft Edge.

The enablement of those major browsers is one of the key features of Playwright. It is a powerful argument to prefer this tool above others. But there is more. Frontend developers need to test their code not only in different browsers but on various devices, eventually with offline modes of Progressive Webapps.

Have a look at the core concepts of Playwright to get a feeling for the developer experience. The installation of the testing library is made as simple as possible. After the execution of the install script everything including browser settings is already setup. It is made simple to configure, install, or skip different versions of browsers. Playwright's API is testing-friendly. During the execution of tests, developers can interrupt them with the Developer Tools of the browsers or using the Microsoft VS Code Debugging Tools.

I won't get into the details on how to install and use Playwright. This content could get outdated in the future. Check out the Getting Started to explore the testing tool.

Which role does Playwright play?

Let's have a very short recap. Playwright is a new library for browser automation. Selenium came out in 2004 and was the most used tool for browser automation tests for a relatively long time. PhantomJS helped to render the UI during tests. Google released the first major version of Puppeteer in January 2018. Two years later in January 2020 Microsoft announced Playwright.

It gets interesting when comparing who is contributing to Puppeteer and who is contributing to Playwright. The most active contributors of Puppeteer Andrey Lushnikov and Joel Einbinder are now part of the team of Playwright. In one version of the repository's README.md they stated:

We are the same team that originally built Puppeteer at Google but has since then moved on. Puppeteer proved that there is a lot of interest in the new generation of ever-green, capable, and reliable automation drivers. With Playwright, we'd like to take it one step further and offer the same functionality for all the popular rendering engines. We'd like to see Playwright vendor-neutral and shared governed.

-- Playwright README.md: Q: How does Playwright relate to Puppeteer?

Playwright has all of the features that Puppeteer has, too. The team took advantage of the lessons they have learned during the development of Puppeteer.

One might ask why the team has not decided to improve Puppeteer with those features but create a new framework. Apart from the browser support, what are the differences between Puppeteer and Playwright? Being cloud-native, supporting a BrowserContext for multi-page scenarios, the setting of the user-agent and device emulations are some additional features.

Those features would have led to breaking changes in the Puppeteer API. But testing code in Chromium only might be enough for some codebases. Internal user interfaces for dashboards or Admin Areas don't have to support all of the different browsers or work offline.

The team decided to create a new framework instead. That does not imply that a switch from Puppeteer to Playwright would be a never-ending task. The API and core concept are currently still similar and it should be possible to migrate from Puppeteer to Playwright. If you have any experience, leave a comment!

TL;DR: Playwright is the successor of Puppeteer including support for all major browsers.

Configuring TailwindCSS for Sapper

Vanessa Otto — Fri, 31 Jan 2020 06:46:05 +0000

This article is Part III of my first three posts about Svelte. Part I described how to create Statically generated website with Svelte and Sapper. Part II discusses Svelte Single File Components in more detail.

In this article we will configure TailwindCSS for Svelte + Sapper.

Versions:
Svelte: 3.18.0
Sapper: 0.27.9 (! early state)
TailwindCSS: 1.1.4
@fullhuman/postcss-purgecss: 1.3.0
PostCSS: 7.0.26
PostCSS-CLI: 7.1.0
PostCSS-Load-Config: 2.1.0

TL;DR

I forked the official sapper-template repository. It includes the integration of TailwindCSS, PostCSS and PurgeCSS. You can install the sapper-tailwindcss-template repository. Then you don't have to go through the Step by Step Guide below. To use it, execute the following commands:

npx degit "vannsl/sapper-tailwindcss-template#rollup" sapper-tailwindcss-template
# or
npx degit "vannsl/sapper-tailwindcss-template#webpack" sapper-tailwindcss-template
cd sapper-tailwindcss-template
npm install

To start the local server and watch tailwind, execute these two commands in separated windows of your terminal:

npm run dev:tailwindcss

npm run dev

Vannsl / sapper-tailwindcss-template

Starter template for Sapper apps

sapper-tailwindcss-template

The is a fork of the default Sapper template, available for Rollup and webpack. It extends the default template by installing TailwindCSS, PostCSS and PurgeCSS.

Getting started

Using `degit`

degit is a scaffolding tool that lets you create a directory from a branch in a repository. Use either the rollup or webpack branch in sapper-template:

# for Rollup
npx degit "vannsl/sapper-tailwindcss-template#rollup" my-app
# for webpack
npx degit "vannsl/sapper-tailwindcss-template#webpack" my-app

Using GitHub templates

Alternatively, you can use GitHub's template feature with the sapper-template-rollup or sapper-template-webpack repositories.

Running the project

However you get the code, you can install dependencies and run the project in development mode with:

cd my-app
npm install # or yarn
npm run dev

Open up localhost:3000 and start clicking around.

Consult sapper.svelte.dev for help getting started.

Structure

Sapper expects to find two directories in the root of your project —…

View on GitHub

Existing methods

On Github, there already exists a TailwindCSS Setup Example for Sapper. Although the general setup works, I had problems with PurgeCSS. The not used CSS of the TailwindCSS Framework was not removed when exporting a static version of my Sapper application. Maybe I did something wrong.

I did a bit of research and after a few try and error approaches, I finally got it to work. Here's the Step by Step Guide:

Step by Step Guide

In the following, we'll install Sapper and TailwindCSS.

Create a Sapper app

The following commands will install the example project for Sapper using the Rollup Configuration:

npx degit "sveltejs/sapper-template#rollup" sapper-tailwindcss
# or
npx degit "sveltejs/sapper-template#webpack" sapper-tailwindcss
cd sapper-tailwindcss
npm install

Now your Sapper application is installed. Run npm run dev to start the local server. Open http://localhost:3000 to check out the example project.

Download TailwindCSS, PostCSS and PurgeCSS

The following commands will download the packages for PostCSS and TailwindCSS as devDependencies and PurgeCSS as a dependency:

npm install -D postcss-cli tailwindcss --save
npm install @fullhuman/postcss-purgecss --save

Create the Configurations

The order of the following steps is not important. It will only work when all of the following changes are implemented.

tailwind.config.js

Afterward, initialize TailwindCSS with:

npx tailwind init

This command creates the file tailwind.config.js in the root directory of your project. It contains the following skeleton:

// tailwind.config.js

module.exports = {
  theme: {
    extend: {}
  },
  variants: {},
  plugins: []
}

For more information on how to customize TailwindCSS, please read the official TailwindCSS configuration documentation. You can leave it for now as it is.

postcss.config.js

Create an empty file with the name postcss.config.js. Either by creating this file in your IDE or finder or by executing the following command (if macOS) in the root folder of the sapper application:

touch postcss.config.js

Afterward, append the following content to the file:

// postcss.config.js

const tailwindcss = require("tailwindcss");

const purgecss = require("@fullhuman/postcss-purgecss")({
  content: ["./src/**/*.svelte", "./src/**/*.html"],
  defaultExtractor: content => content.match(/[A-Za-z0-9-_:/]+/g) || []
});

module.exports = {
  plugins: [
    tailwindcss("./tailwind.config.js"),

    ...(process.env.NODE_ENV === "production" ? [purgecss] : [])
  ]
};

rollup.config.js/webpack.config.js

Nothing to do. I added that section here because other approaches include adding PostCSS to the rollup config. There is no need to do this when using the approach of this post.

static/tailwind.css

Now it's time to add the TailwindCSS Styles to your project. Create a new CSS file in the statics directory.

cd static
touch tailwind.css

To import the TailwindCSS Styles, the rules have to be applied in this file:

/* static/tailwind.css */

@tailwind base;
@tailwind components;
@tailwind utilities;

The name of the CSS file is not important. It's best practice to use names like tailwind.css, main.css or global.css. Since the skeleton project of Sapper already provides a global.css, this tutorial recommends to use the name tailwind.css to prevent conflicts. When using a Utility-Based CSS Framework the styles of the preconfigured global.css may not be needed. If you want to, you can also use this file and override the default settings.

Note: This file can be used either for only adding TailwindCSS to the Sapper project or be extended with further global rules and styles. For example, custom CSS classes or Font Faces can be registered here.

package.json

Mostly done. To get the TailwindCSS CSS into the built application for dev and production mode, the following npm scripts in the package.json have to be added:

// package.json

// ...
scripts: {
 // ...
 "dev:tailwindcss": "postcss static/tailwind.css -o static/main.css -w",
 "build:tailwindcss": "NODE_ENV=production postcss static/tailwind.css -o static/main.css",
 // ...
}
// ...

These commands will create (or override if already existing) the file main.css in the static folder. The first command dev:tailwindcss will create a CSS file including all of the TailwindCSS styles. Any change in your source code will be immediately applied to the website with hot module replacement. When executing PostCSS in the production environment with NODE_ENV=production the file main.css will include only the styles of TailwindCSS you're using in your application thanks to PurgeCSS. If you try out both versions, you should see a significant difference in the file size of main.css.

You don't need to name that file main.css. You can choose any name that's not taken yet in your project. In the next section, we'll import the built CSS file in our application. But first, we'll add the statement to execute build:tailwindcss when building or exporting the Sapper application. Therefore add npm run build:tailwindcss && at the beginning of the build and export scripts:

// package.json for rollup

// ...
scripts: {
 // ...
 // "dev:tailwindcss": "postcss static/tailwind.css -o static/main.css -w",
 // "build:tailwindcss": "NODE_ENV=production postcss static/tailwind.css -o static/main.css",
 "build": "npm run build:tailwindcss && sapper build --legacy",
 "export": "npm run build:tailwindcss && sapper export --legacy",
 // ...
}
// ...


// package.json for webpack

// ...
scripts: {
 // ...
 // "dev:tailwindcss": "postcss static/tailwind.css -o static/main.css -w",
 // "build:tailwindcss": "NODE_ENV=production postcss static/tailwind.css -o static/main.css",
 "build": "npm run build:tailwindcss && sapper build",
 "export": "npm run build:tailwindcss && sapper export",
 // ...
}
// ...

.gitignore

If you've initialized a git repository, I recommend to add /static/main.css to your .gitignore file. For example, that's how the .gitignore of the Demo Git Repository looks like:

.DS_Store
/node_modules/
/src/node_modules/@sapper/
yarn-error.log
/cypress/screenshots/
/__sapper__/
/static/main.css

src/template.html

To import the generated main.css file, add the following line in the file src/template.html just above the other import:

<!-- src/template.html -->

<link rel="stylesheet" href="main.css">

Running the project

To run the application in production more, execute npm run build. To generate the static site of the application, run npm run export. By adding npm run build:tailwindcss to these scripts in the package.json, the commands will automatically generate the file main.css.

To run the project locally, execute the following commands in separated windows of your terminal:

npm run dev:tailwindcss

npm run dev

👏 That's it. You're done. 👏

All you need to know to start writing Svelte Single File Components

Vanessa Otto — Fri, 17 Jan 2020 05:41:22 +0000

This article is Part II of my first three posts about Svelte. In my opinion, the principle to have a JavaScript (UI) framework without a framework is the most promising for the future of frontend development. I'm looking forward writing about Svelte. Part I discusses how to create a statically generated website with Svelte and Sapper. Part III shows how to use TailwindCSS with Svelte and Sapper.

Version:
Svelte: 3.16.7

Introduction

Svelte is a modern framework to create cybernetically enhanced web apps. Without loading the whole library on the client, it does all of the work in the compile step. There is a lot more to tell about Svelte, but today we'll only talk about how to create things with Svelte.

This article focuses on writing Svelte Single File Components. It describes how to:

structure a svelte file
- create data attributes
- render markup conditionally
- handle events
compose components
- pass properties to child components
- use slots
continue with Svelte

A .svelte Single File Component (SFC)

Svelte SFCs look very similar to Vue or with other words: like HTML, JavaScript, and CSS. The usual differs slightly from Vue SFCs:

A .svelte SFC starts with the <script> block. It contains the logic of the SFC. It can import child components and export data attributes and properties.

It is followed by the <style> block. It contains the CSS for this component. Compared to other component-based frameworks, the style it automatically scoped to this component without adding a keyword for it.

Styles are scoped to the component by default. For global styles add the keyword: <style global></style>.

The part of the HTML is surprisingly not wrapped inside in a <template> block. There is also no need to wrap all of the HTML tags within one surrounding tag. It's important: there is no <template> block. HTML can just be added to the file.

An example .svelte SFC looks like this:

<!-- component.svelte -->
<script>
  // nothing to do here. This block can be removed.
</script>

<style>
  h1 {
    font-size: 42px;
  }

  p {
    font-size: 14px;
  }
</style>

<h1>Hello World!</h1>
<p>I am a Demo.</p>

By not wrapping the HTML in surrounding tags, there are a few things different from other component-based frameworks:

grid styling might get simpler by having more freedom
besides passing properties, it is not possible to add other attributes like class="" to a child component.

Data attributes

The template language of Svelte is Angular/Vue alike. Like in those frameworks, there are similarities to Handlebars. To use variables within the template, wrap them in curly braces: {VARIABLE}.

<script>
  const title = "World";
</script>

<style>
  h1 {
    font-size: 42px;
  }

  p {
    font-size: 14px;
  }
</style>

<h1>Hello {title}!</h1>
<p>I am a Demo.</p>

Although I would consider it as a bad idea to add HTML via variables in the markup, it's possible by writing <h1>Hello {@html title}</h1>.

Variables can also be used to bind dynamic values to HTML attributes. E.g. an anchor link with a href variable looks like this:

<a href={href} target="_blank" rel="noopener">
  Open Link
</a>

A common mistake at the beginning when using variables for HTML attributes could be to add quotes for the variables. It's href={href} and not href="{href}".

A nice feature is to use shorthand attributes. When the name of the variable equals the name of the attribute, it's enough to add only the attribute in curly braces:

<a {href} target="_blank" rel="noopener">
  Open Link
</a>

Shorthand attributes can reduce redundant code. For example, it's possible to use {href} for href={href}.

It's even possible to spread an object to add several attributes:

<script>
  const link = {
    href: "some src",
    target: "_blank",
    rel: "noopener"
  }
</script>

<a {...link}>
<!-- will be compiled to: <a href="some src" target="_blank" rel="noopener">-->
  Open Link
</a>

Conditional rendering

Compared to other frameworks, if and else blocks are not implemented with directives. For conditional rendering in Vue one would write: <p v-if="true">. For conditional rendering in Svelte one can achieve that by adding pure if blocks, wrapped in curly braces.

{#if Math.random() > 0.5}
  <p>I like Svelte.</p>
{:else}
  <p>I don't like Svelte.</p>
{/if}

For conditional rendering, if-else blocks can be written in curly braces. Else blocks are optional. # opens a block, : indicates a block continuation tag and / closes the block.

Event Handler

Before the era of UI frameworks, developers used Vanilla JavaScript to add logic and behavior onto websites. Onclick handler provided the functionality to add callbacks to HTML elements, as soon as users clicked on them. In Svelte, event handlers are added to DOM elements by using the element directive on:. It's possible to either pass a function as reference or write an inline function.

Use on: to add event handlers on DOM elements.

A few examples to get a feeling for event handlers:

<script>
  let counter = 1;

  function logout() {
    // ... log user out
  }

  function toggleTooltip() {
    // ... show or hide tooltip
  }
</script>

<button on:click={logout}>
  Logout
</button>

<div on:mouseover={toggleTooltip}>
  Info
</div>

<button on:click="{() => a += 1}">
<!-- you can pass the event as property: -->
<!-- <button on:click|preventDefault="{(e) => /* do something with the event e */}"> -->
  a is {a}.
</button>

Let's talk about how to compose components next.

Composing Components

Child Components can be imported in the <script> block. They don't have to be registered any further.

<script>
  import GridItem from '../components/GridItem.svelte';
</script>

The component can be added to the template like other HTML tags.

<GridItem></GridItem>
<!-- or <GridItem /> -->

Child components are written in CamelCase and imported in the <script> block.

The names of the components are case sensitive. It is recommended to use PascalCase for the names. The advantage of that is that it is possible to use Header, Footer and other already taken tag names as names for the Svelte components. This is different from other frameworks where names like TheHeader or TheFooter are a workaround, although also making clear that these components should also only be used once within the page template.

Passing properties

Properties can be passed with curly braces {}to the child components. Children can access the properties by exporting them. While to declare data attributes the syntax is [let/const] variable = 'abc';, the syntax for accessing passed properties is export let variable;.

<!-- Parent.svelte -->
<script>
  import Child from '../components/Child.svelte';
</script>

<Child title="World!"></Child>

<!-- Child.svelte -->
<script>
  export let title;
</script>

<h1>Hello {title}</h1>

An optional default value can be added:

<!-- Child.svelte -->
<script>
  export let title = "my dear friend.";
</script>

<h1>Hello {title}</h1>

Use <Child></Child> or <Child /> for nesting components without using slots.

Use Slots

Now, it is time to create a simple Grid with GridItems slots that can be added by using the tag <slot></slot>. Please be aware of the simplicity of the implementation of this grid, which only allows two columns per row. @vaheqelyan implemented a much more complex version of a Svelte-Grid.

<!-- Grid.svelte -->
<style>
  .section {
    display: flex;
    flex: flex-wrap;
  }
</style>

<section>
  <slot></slot>
</section>

To use several slots within one component, append the attribute name= to create named slots. Named slots and unnamed slots can be combined.

<!-- GridItem.svelte -->
<style>
  .div {
    width: 50%;
  }
</style>

<div>
  <slot name="title"></slot>
  <hr>
  <slot name="content"></slot>
  <slot></slot>
  <!-- or <slot /> -->
</div>

It is a powerful way to create complex compositions of components. In the following we'll see a whole Grid example:

<!-- index.svelte -->
<script>
  import Grid from '../components/Grid.svelte';
  import GridItem from '../components/GridItem.svelte';

  let title = 'World!";
</script>

<h1>Hello {title}</h1>

<Grid>
  <GridItem>
    <h2 slot="title">I will be rendered within the named slot title.</h2>
    <p slot="content">I will be rendered within the named slot.</h2>
    <p>I will be rendered within the unnamed slot.</p>
  </GridItem>
  <GridItem>
    <h2 slot="title">I only have a headline, nothing else.</h2>
  </GridItem>
</Grid>

To add components, data, properties, etc. in Svelte, they only have to be imported or declared in the <script> block. There is no need to register them any further.

Next steps

🤩 Prepared with this knowledge, implement your first basic Svelte Single File Component 🤩

Small static pages often don't need more functionality. To strengthen the knowledge, I recommend using 1h to go through the official tutorial.

There is more to learn. Svelte offers lifecycle hooks, bindings, stores, transitions and much more to create more complex applications. Keep on learning 👨‍🎓👩‍🎓

Statically generated website with Svelte and Sapper

Vanessa Otto — Sun, 05 Jan 2020 10:51:52 +0000

This article is Part I of my first three posts about Svelte. Part II discusses Svelte Single File Components in more detail. Part III shows how to use TailwindCSS with Svelte and Sapper.

In this article we will configure VS Code for Svelte, install the demo application of Sapper, discuss the project structure, run the E2E tests, build the demo application statically and deploy it on Netlify.

Versions:
Svelte: 3.16.7
Sapper: 0.27.9 (! early state)

Introduction

In this article, we will go through the process of setting up a statically generated website with Svelte or more specifically its companion framework Sapper. I'm currently using this framework to build my portfolio web page from scratch. The code of currently unfinished version can be found on my Sapper repository on github.

What is Svelte?

Svelte is a free and open-source software for creating performant web sites. In comparison to React and Vue, Svelte does a lot of work already in the compile step while building the application. React and Vue do a lot of these tasks in the browser. I've tried it out and in my opinion. It's worth to give it a shot or at least keep it in mind.

I won't go further into the technical details of Svelte. The contributors know them better as me. There is a lot of great material on their blog to understand how the framework works. They provide a detailed tutorial. The talk of Rich Harris, the mind behind rollup and Svelte, about Rethinking Reactivity explains everything you need to know about the backgrounds of Svelte. Check them out! Reading the documentary is the key to become a better developer 🙂.

What is Sapper?

Sapper is the companion of Svelte, like Nuxt is it for Vue or Next is it for React. It includes

server-side rendering
automatic routing (using the "routes" directory, similar to "pages" directories of Nuxt and Next)
code splitting
offline support (using service workers)

...and therefore the ability to create statically generated pages.

VS Code Support

Before creating the demo application, the IDE should be configured for Svelte. As we see below more detailed, a .svelte file is organized similar to pure .html files. To enable syntax highlighting, open the settings (JSON) in VS Code. Do that by clicking Cmd + Shift + P to open the Command Palette and open Preferences: Open Settings (JSON) and add the following setting:

"files.associations": {
  "*.svelte": "html"
}

There are also some Svelte Extensions available. I've recommend to install the extensions Svelte language support and Svelte 3 Snippets.

Create a new project

Let's dive into it. To create a new project execute the following commands in the terminal:

npx degit "sveltejs/sapper-template#rollup" sapper-app
# or npx degit "sveltejs/sapper-template#webpack" sapper-app
cd sapper-app
npm install
npm run dev

Project structure

If you already have worked with Nuxt or Next, the folder structure will be familiar to you. The folder structure of the demo application is:

./__sapper__ which includes the built files for production, dev and static modes
./cypress for e2e testing
./node_modules
./src which includes the source files
- ./components which includes the single file components
- ./node_modules
- ./routes which includes page components with names representing the URL path (e.g. index.svelte or about.svelte) and layout files containig the skeletons (e.g. _layout.svelte or _error.svelte)
- client.js, the client entry
- server.js, the server entry
- service-worker.js
- template.html, which contains the content of the wrapping HTML for each page
./static for assets
package.json
package-lock.json
README.md
[rollup|webpack].config.js

Most of the things to develop will be in the directories src/components and src/routes. In both folders, you will find .svelte files. A more detailed explanation about the Single File components will be provided in Part II, I will skip that part for this article.

However, the interesting components for Sapper are the layout and page components. Let's have a closer look at them.

Layout Skeletons

Layout Components structure the wrapping HTML of different pages. It enables the possibility to add Header, Navigation, Footer and other components which should be on several pages more easily. In the example below, we see a skeleton with a Header, Footer and the main content. The content of the page will be provided through the page components. Their content will be rendered in the unnamed <slot></slot>.

<script>
  import Header from '../components/Header.svelte';
  import Footer from '../components/Footer.svelte';
</script>

<style>
  main {
    margin: 0 auto;
    max-width: 1200px;
  }
</style>

<Header></Header>
<main>
  <slot></slot>
</main>
<Footer></Footer>

Have a look at Part II for more details of the naming conventions of child components. Note here, that we can use Header and Footer as names although these names are already given to pure HTML tags. This is possible since Svelte component names are case sensitive. By using PascalCase, it is not needed to add a prefix like "the" for TheHeader or TheFooter.

Routes Component

To create a new page, a new .svelte file has to be added into the src/routes directory. Besides the blocks <script> and <style> page components can use a <svelte:head> block. This block contains HEAD information, like a title or meta description. It is usually put after the blocks <script> and <style> before the template part.

<svelte:head>
  <title>My first Sapper app</title>
</svelte:head>

<h1>Hello!</h1>
<p>This is my first Sapper app</p>

Accessibility Feature

A great feature of Svelte is that it checks the a11y of the template. 👏👏👏
If an <img> tag misses the attribute alt, it prints a warning. It is still possible to compile the application.

E2E Testing

The demo application of Sapper includes a Cypress E2E test. To run tests execute

npm run test

You might get an error that your machine does not know "cypress". That means that you still have to install it. On purpose, cypress is not a dev dependency to minimize the install time. This topic was discussed in this github issue and solved with this commit adding the information to the README.md. You can either add it as a dev dependency yourself with

npm install cypress --save-dev

or install is globally to use it everywhere

npm install -g cypress

Static Build

🎉 That's all you need to know to create your first Sapper application. 🎉

Let's build it. To execute the static build of the demo application, run:

npm run export

and find the built files in the directory ./__sapper__/export.

Netlify Deployment

To deploy the static page on Netlify, initialize the project as a git repository and upload it on GitHub. Import that project on Netlify. Go to the project's settings. Edit the settings for Build & Deploy. The build command is npm run export. The publish directory is __sapper__/export. Trigger the deploy and the application will be built and deployed.

DEV Community: Vanessa Otto

The Surprisingly Weird World of Favicons (And How to Survive It)

Manifest

Implementation

But wait—do we really need all of this?

PNG vs. SVG: What to do?

SVG Favicons Dark Mode

Troubleshooting

Modern Image Formats on the Web: WebP and AVIF Without the Headache

🧱 HTML Implementation: The <picture> Element

🎨 CSS Option: image-set() for Backgrounds

🛠️ Converting Images to WebP and AVIF

🎬 Conversion via ffmpeg

🧪 Conversion via Sharp (Node.js)

🧰 Running the Script

✅ Final Thoughts

Between Diapers and Development – How My Blog Came to Life with Eleventy

Foreword

The "Right" Tool

Domain and Hosting

The Tool Decision

The Trade-offs

Zwischen Wickeln und Entwickeln - Wie mein Blog mit Eleventy entstand

Vorwort

Das "richtige" Tool

Domain und Hosting

Die Tool-Entscheidung

Die Abstriche

Webpacker, Vue 3, and TypeScript

Foreword

How to configure TypeScript in Vue 3

1. TS Loader

2. TS Config

3. Webpack Loader

4. Shims

5. Linters and IDE Helpers

Usage

Vue and TS

Type Declarations

Vue Data and Properties

Type Assertions

Vue Reactive Data Options API

Vue Reactive Data Composition API

Vue Properties

Vue Computed Properties and Methods Options API

Eh, and now?

Nevertheless, Vannsl Coded, and Talked, and Wrote

How it's like to be a Woman in Tech AMA

What's the biggest shit you had to deal with as a public speaker?

You're a designer

Conference Organizers

Conference Visitors

How do you feel to be the only woman in an all-male podcast line-up?

What were your biggest challenges in taking/having leadership in software projects?

Vue3 on Rails

Foreword

What you should know at the end

Introduction

Create Rails app (optional)

Setup rails app

Install yarn

Install Vue3 & Co.

Webpack environment configuration

Set an alias (optional)

Add Vue Loader

Include .vue files

Set Vue properties

Create a Vue app

Create entry point and SFC

Create Home controller and view as root route

Connect Vue and Rails

Next Steps

Tips for remote goodbyes

📅 Plan ahead

⏲️ Breaks

Dinner break

Small breaks

👗 Have a dress code and/or a motto party

🖼️ Slide Show

🎲 Game/Quiz Time

🧱 HTML Implementation: The `<picture>` Element

🎨 CSS Option: `image-set()` for Backgrounds

🎬 Conversion via `ffmpeg`

Using `degit`