Ich bin ein Frontend & UI Entwickler aus Bremen. Hier schreibe ich Artikel über Webentwicklung, Design, Software, Workflows und was mich sonst beschäftigt.

Du hast Anmerkungen und Feedback zu meinen Artikeln? Dann schreib mir! Ansonsten folgt mir auf Twitter und abonniert mich auf YouTube.

Last weekend I took part in the VueCamp in Berlin. The VueCamp is an event organized as a BarCamp, i.e. all contributions, discussions and talks come from the participants themselves. And my first impression - that worked very well.

Native Lazy Loading is coming to the web

twitter.com / Direktlink

Last week I integrated the Intersection Observer API in a project and thought how much easier it makes things like Lazy Loading. And now this - with native Lazy Loading I don't even have to write any JavaScript for LazyLoading. A huge performance gain for the web. For everyone.

I ruin developers’ lives with my code reviews and I'm sorry

habr.com / Direktlink

This article by Philip Ranzhin is a very well written example of how to stop being an a**hole. I quote here only the conclusion - but the article is a must-read

This review I kicked off the article with? I didn’t send it. Instead I gave the guy a couple of comments and politely asked to fix a couple of things. No big deal if the code’s not good, I can fix it myself it I need to. But I can’t fix the psyche of a guy broken by dozens of harsh reviews.

My personality today isn’t my disease. It’s a disease of the whole industry, at least in Russia. Our mentality is predicated on the cult of power and superiority. And that’s what we need to fix: just stop being that. It’s quite easy, actually.

If we were being laughed at while young, it doesn’t mean you have to return the favor later on. The vicious cycle can easily be broken. Life becomes easier if you learn to lose arguments, if you can admit that another developer is more talented than you.

It’s an aikido-style move. I fool my internal toxic egomaniac, convince him that accepting your weaknesses is great, and it starts to be proud of what he’s done. And it doesn’t matter what taboos I break in the process if it makes me feel better.

The Great Divide

css-tricks.com / Direktlink

Two front-end developers are sitting at a bar. They have nothing to talk about.

This is a topic that affects every frontend developer. As a freelance developer, I deal with requests on a weekly basis, mostly from recruiters.
If you sort out all messages that are based on Java, hybris, or other technologies I've never heard of, there are only two types of requests left.

A frontend developer for HTML, CSS (or SCSS, Less, or similar). With UX experience. Some Javascript.
A frontend developer for React / Vue.js / Whatever. Some Redux / Vuex / Whatever. And some UX.

This was a creeping process. At a conference a few years ago I talked to someone who now calls himself a "classic frontend developer". But this implies for me that a "classic" developer is less and less needed, maybe even on a par with a book printer (compared to machine production). And I don't believe that.

Nevertheless, this conversation and the abundance of requests for "modern frontend developers" was one of the things I finally wanted to do more with Javascript frameworks. I even enjoy it. But I wouldn't call this work frontend development anymore, because it includes so much more than UI customization and optimization.

I think we need to move away from the term myself. We should split into UX Engineers and JavaScript Engineers. They are different mindsets. Most people are not amazing at both JavaScript and CSS. Let UX Engineers work closely with UX/Design to create great designs, interactions, prototypes, etc. and let JavaScript Engineers handle all the data parts.

But ... I think I'll save the topic for a blog entry.

Introducing Kirby 3

getkirby.com / Direktlink

After over two years of development and seven years after launching Kirby 1, we are back with our biggest release to date…

Woohoo, finally. Kirby is my CMS of choice and I try to use it for almost every project. The version 3 brings is not only a rewrite, but also some useful new features:

  • a new panel, written in vue.js (woooohoo, again)
  • more panel fields options
  • Drafts & custom publishing workflows
  • a new plugin system (btw, do you already know this page?)
  • and the most important part, at least for me: ... REST API and Headless Browser

    Kirby 3 has a built in REST API. You can comfortably create and edit your content in the Panel, and then consume your content in SPAs, mobile applications or static site generators.

With this release I will probably be able to tick off a long open todo point for the Kirby directory. Use Kirby 3 as backend.

The React Handbook

medium.freecodecamp.org / Direktlink

The React Handbook follows the 80/20 rule: learn in 20% of the time the 80% of a topic. I find this approach gives a well-rounded overview. This book does not try to cover everything under the sun related to React, but it should give you the basic building blocks to get out there and become a great React developer.

In case anyone wants to get into React, Flavio has written a great post on Freecodecamp. He covers basics as well as advanced topics.
I'm more of a fan of Vue.js, but it will certainly be useful for me at some point.

Git Command Explorer - Find the right commands you need without digging through the web.

gitexplorer.com / Direktlink

Another link that goes directly to my bookmarks. Although I consider myself to be relatively safe with terminal and git commands, it still happens often enough that I have to search for commands that I don't use often. Git Explorer could be very handy here.

I'd like to see more complex commands like changing an upstream branch or emptying a Git Cache, but especially for Git beginners I imagine this page to be very useful.

By the way - the Typewriter effect is very exhausting.

Atomic Design is messy, here's what I prefer

dennisreimann.de / Direktlink

Der Dennis beschreibt was ihm an Atomic Design stört und was er besser machen würde. Unter anderem spricht er ein ständiges Dilemma an:

A question which I bet has been asked in every team that applies atomic design: “Is this thing a molecule or an organism?”
And in fact: What makes something “small” or “big”? Is it the number of elements or other components it includes? The type of subparts it contains? The visual space it takes up on the screen?