In my experience, customers love sticky headers. And indeed, they prove to be very useful in certain situations. But there are also terrible implementations of this pattern out there. And I cannot blame the developers who created them. Getting sticky headers right is harder than you might think...
A few days ago, I remembered that at my former workplace, karriere.at, we had a pre-commit hook bash script that executed ESLint and Stylelint, not on the entire repo, but only on files that were changed. Because that was pretty handy, I was looking into how I could have the same convenience for my projects...
A few weeks ago, I wrote about naming unit tests BDD style using Given/When/Then. In this article, I have expressed the thought that I do not like to repeat information in the description and in the expect statement. After writing some tests the way I've described in this article, I noticed a couple of drawbacks...
One of my freelancing projects is a Nuxt.js project powered by the headless CMS Storyblok. Because performance is critical, I decided to use Nuxt.js in generate mode outputs static HTML files for each page at build time. But because Nuxt.js needs to generate 1.000+ pages, the build time got long...
One of my top priorities is to create the fastest possible websites (think marketing sites, not web applications), but I also don't want to do without modern tools and a component-based workflow. While there are developments in the right direction, I don't think tools like Gatsby and Nuxt.js are quite there yet when it comes to building content heavy, mostly static sites...
One of my top priorities is to create the fastest possible websites (think marketing sites, not web applications), but I also don't want to do without modern tools and a component-based workflow. While there are developments in the right direction, I don't think tools like Gatsby and Nuxt.js are quite there yet when it comes to building content heavy, mostly static sites...
When multiple people are working together on a project, it is important to define some rules to make sure that everything stays tidy and chaos does not arise. How to name things is one of the areas in which there are always differences in opinion...
For the most time, when writing unit tests, I favored the it should ... pattern for naming my tests. But time and time again, I noticed that when following this naming convention, I either had to write very long test cases or omit important information...
In the last week, thoughts about global state management, technical debt, and using a WET first approach for building components sparked my interest...
In the last week, I enjoyed working with Eleventy and Preact very much. Furthermore, I realized that boring but proven technology is often better than new and shiny tools...