Cole Peters (@colepeters@mastodon.online) on begin.com:

For years now, the most popular JS frameworks have carried out intense marketing initiatives based on the premise of improving DX

The whole thing goes, however, as in other ecosystems that developers categorically exclude other frameworks as "bad" and some now and then only see the next nail they can hammer.

My toolchain consisted of HTML (version 4), CSS (version 2), and a sprinkling of jQuery on those rare occasions when I could understand how to use it.

Those were the days. I still fondly remember one of my first jobs, where we uploaded our .jars (built by Jenkins, after all) to the production server via FTP. Don't worry, I'm not suggesting that now as the better alternative to a CI/CD pipeline. However, I did learn a few things about Java and application servers there that still help me today.

As a member of a developer experience team, I often get asked what I do, and why it is important for a company. The truth is that developer experience (DX) is a critical aspect of software development that impacts the productivity, efficiency, and satisfaction of developers. In this blog post, I want to shed some light on what DX is, why it matters, and some of the benefits as well as negative aspects of having a DX team in place.

I'm working on the migration of a monorepo from Vue.js 2 to Vue.js 3 right now. As we are in a monorepo we can migrate our applications stepwise but got into a situation where suddenly our Vue.js 2 tests failed with the following error:

Vue packages version mismatch:

- vue@3.2.40 (...)
- vue-template-compiler@2.7.8 (...)

This may cause things to work incorrectly. Make sure to use the same version for both.
If you are using vue-loader@>=10.0, simply update vue-template-compiler.
If you are using vue-loader@<10.0 or vueify, re-installing vue-loader/vueify should bump `vue-template-compiler` to the latest.

This didn't make sense to me at first because we don't have any project that uses vue-template-compiler and Vue.js in version 3. So, why do we see this conflict?

Software development teams often face the challenge of making decisions on what tools, technologies, and approaches to use when building software products. To make these decisions, it's crucial to understand the difference between strategy and tactics, as they have distinct meanings and implications.

There are some dependencies that I automatically add as devDependency if they are needed. This includes tslib, since it obviously belongs to TypeScript and therefore should not play a role at runtime.

In my Eleventy tutorial I already showed how to set up a blog with Eleventy and also how to integrate CSS into an Eleventy website.

Since I like to work with Tailwind CSS, I naturally want to use it in my private projects as well and have tried a few setups here. Most of them use PostCSS and TailwindCSS "classically" and then adjust the scripts in the package.json so that the Eleventy page is built first and then the appropriate CSS is generated. You can do it that way, but in my eyes it made the setup in package.json more complicated.

My alternative uses Eleventy on-board resources to generate the CSS and fits into the existing configuration with just a few lines of code.

Twitter has been a great tool for me and has also brought me a lot in the last 15 years: I've been able to meet many wonderful people, exchange ideas with them and have learned an enormous amount that has helped me a lot in my career so far.

I'm sure that without Twitter I wouldn't have written a book, and I'm sure that my career and, of course, my private life would have looked completely different. Even though I became more and more passive there in the last years, Twitter was something I opened several times a day and enjoyed using.

Unfortunately, Twitter has changed so much in recent weeks and months that I no longer want to support and use it. So now you can only find me on Mastodon. At the moment I'm much more active there, which is surely due to the mood. Feel free to come over! I would be happy if we would network there.

Vor einiger Zeit habe ich eine Einführung in ein Standard-Frontend-Projekt gegeben und dabei mit Blick auf die package.json einige Dinge etwas vereinfacht. In diesem Beitrag möchte ich daher einige dieser Details genauer zeigen. Übrigens: zu diesem Thema habe ich vor ein paar Jahren auch etwas im Blog der codecentric geschrieben. Der Artikel ist größtenteils noch aktuell und wird durch diesen Beitrag ergänzt.

Für diesen Blog möchte ich ein paar Dinge aus dem JavaScript Umfeld zusammenfassen, die mir immer wieder begegnen und stellenweise auch mal für Probleme sorgen. Prototypen sind etwas, dass immer mal wieder für Verwirrung sorgt und hier möchte ich versuchen, dass ganze verständlich zu erklären.

JavaScript ist eine prototypenbasierte Programmiersprache. Das bedeutet also zunächst, dass JavaScript Objektorientierung unterstützt. Laut Definition allerdings eine "ohne Klassen" (was nicht stimmt, mehr dazu später im Artikel).

Während in anderen Programmiersprachen Objekte durch die Instanziierung einer Klasse erzeugt werden (x = new Foo("bar")), wird in prototypenbasierten ein Objekt durch das Klonen eines bereits existierenden Objekts instanziiert. Klonen bedeutet, dass der Klon alle Eigenschaften des Originals hat und nutzen kann.

In meinem letzten Beitrag habe ich bewusst noch ein paar Dinge unterschlagen, die im Umgang mit this hilfreich sein können: bind, apply und call. Zum einen war der Artikel schon gefühlt lang genug und außerdem nutze ich die drei Methoden (so gut wie) nie. Da mich Tobias aber darauf hingewiesen hat, hole ich das Ganze hier nach.