I first noticed webmentions in the wild on Hidde de Vries’ blog about two years ago. Last week it finally happened, I added webmention support to my blog too! Well, partial support at least. I’m now receiving and displaying webmentions. Sending them out is a project for another day.
React components have always relied on lifecycle methods for side effects. While lifecycle methods get the job done, they’re often overly verbose and have large margins for error.
It’s easy to forget to “clean up” a side effect when a component unmounts, or update the side effect when props change. As Dan Abramov preaches: Don’t stop the data flow.
React recently introduced a new way to deal with side effects: the useEffect hook. Translating lifecycle methods to useEffect calls can be confusing at first. It’s confusing because we shouldn’t be translating imperative lifecycle methods to declarative useEffect calls in the first place.
This blog was a custom Laravel application for the past few years. While I was happy with the Laravel solution, I’m slowly trying to move away from maintaining my own servers. I’m also drawn to the simplicity and stability of serving plain html, so I decided to look into static site generators.
I quickly discovered that Hugo was what I was looking for. Hugo is a very fast and very popular static site generator.
Some time last year, we released the latest iteration of the Spatie.be website.
There’s a succinct description of what we’re about, followed by a peculiar little block, dubbed “Latest insights from the team”.
Unlike other agencies, we don’t have a company blog. We encourage everyone to write on their own blog and put their latest articles in the spotlight.
Everyone keeps ownership of their content.
There’s nothing fancy backing this feature, blog entries are synced via RSS. If you’re interested in implementing something similar in PHP, our source code is available on GitHub.
For the past three years, I’ve been using both React and Vue in different projects, ranging from smaller websites to large scale apps.
Last month I wrote a post about why I prefer React over Vue. Shortly after I joined Adam Wathan on Full Stack Radio to talk about React from a Vue developer’s perspective.
We covered a lot of ground on the podcast, but most things we talked about could benefit from some code snippets to illustrate their similaraties and differences.
This post is a succinct rundown of most Vue features, and how I would write them with React in 2019 with hooks.
When you visit a website, your browser connects to a server via TCP. With TCP, the first roundtrip can be up to 14 KB large.
In other words, the first 14 KB sent to the client will always be the quickest to render in the browser. The rest of the response is streamed afterwards.
This website’s homepage is about 9.7 KB at the time of writing. Articles are roughly 4-10 KB, depending on their lengths. All CSS is inlined, so besides fonts and images everything is loaded withing the first roundtrip, making page loads fast and snappy.
Not all sites can be contained within 14 KB — most probably can’t. But keep the number in mind, and try to optimize the first 14 KB instead.
Last month, I wrote a post about automatically running prettier before every commit. This ensures that all JavaScript and CSS are formatted correctly before they’re stored in the project’s repository.
Husky and lint-staged have been working hard keeping our front-end assets clean as Spatie, so we decided to expand their responsibilities to keep our PHP files clean too. This is a modified version of my previous post using PHP CS Fixer instead of prettier. There’s also an example of a conmbined configuration to run prettier and PHP CS Fixer simultaneously at the end of the post.
Every now and then, web components hype seems to resurface. Judging by my Twitter feed, it’s a bull market period now. Seems like a good time to share some thoughts.
Vue is the default JavaScript framework for Laravel apps. Being part of the Laravel community, I often get the question why I prefer React, so I’ve decided to write down a few standout reasons.
The other day, I stumbled upon an older article by DHH. “Work on what you use and share the rest”.
My core philosophy about open source is that we should all be working on the things that we personally use and care about. Working for other people is just too hard and the quality of the work will reflect that. But if we all work on the things we care about and then share those solutions between us, the world gets richer much faster.
I’ve been keeping this in the back of my mind the past few months.
I was always adding features because I’d expect other people to expect them. It’s a trap! You’re not making people happier by guessing what they might need. You’re not doing anyone a disservice by building things for yourself.
Building things for yourself makes it easier to ship something you feel happy about. It makes it easier to ship something at all.
Don’t forget to be selfish as an open source maintainer every now and then. It’s a good investment in the long run.
I used to fall in the trap of thinking I needed to add features because other people might expect them to be a part of my code, not because I need them myself.