Masonry layouts with CSS grid
Masonry layout support has been added to the CSS grid specification! 🎉
Embed a web page with a web component and the shadow DOM
Today, my colleague Freek asked for help embedding the webview of an email campaign in an iframe. He needed it in an iframe because embedding the HTML directly caused layout issues because the website’s CSS clashed with it.
After setting up the iframe, we needed to find a way to dynamically resize it based on its contents to avoid double scrollbars on the page. While possible, it required some icky scripting.
I took a step back. The problem at hand was that the CSS needed to be scoped somehow. While iframes were the only solution for a long time, these days we have the shadow DOM.
Going deep
I recently stumbled across an over 5 year old comment on Hacker News about performance.
Lots of people make the mistake of thinking there’s only two vectors you can go to improve performance, high or wide.
- High - throw hardware at the problem, on a single machine
- Wide - Add more machines
There’s a third direction you can go, I call it “going deep”. Today’s programs run on software stacks so high and so abstract that we’re just now getting around to redeveloping (again for like the 3rd or 4th time) software that performs about as well as software we had around in the 1990s and early 2000s
Going deep means stripping away this nonsense and getting down closer to the metal, using smart algorithms, planning and working through a problem and seeing if you can size the solution to running on one machine as-is.
The author talks about “high” and “wide” hardware changes, but this can apply to software too. It’s easier to throw a cache at a slow piece of code than going deep and fixing it.
No need to look far, Electron is built on this principle. We’re adding heavy runtimes to support multiple platforms instead of staying close to the metal, and we pay the price in performance.
BlurHash
Last week, Unsplash added “blurhashes” to their API. Blurhashes are 20-30 character strings that represent a blurred placeholder of an image.
Blurred image placeholders aren’t new, but I was completely stomped to see what kind of gradient maps are generated with only 30 characters.
In short, BlurHash takes an image, and gives you a short string (only 20-30 characters!) that represents the placeholder for this image. You do this on the backend of your service, and store the string along with the image. When you send data to your client, you send both the URL to the image, and the BlurHash string. Your client then takes the string, and decodes it into an image that it shows while the real image is loading over the network. The string is short enough that it comfortably fits into whatever data format you use. For instance, it can easily be added as a field in a JSON object.
Unsplash uses the BlurHash algorithm to generate the placeholders. BlurHash is not a library but an algorithm, and they have 5 first party implementations including TypeScript. There’s also a third party package for PHP.
The algorithm is very simple - less than two hundred lines of code - and can easily be ported to your platform of choice.
Read more about BlurHash on GitHub.
Options, Not Roadmaps
Ryan Singer talked about how they (don’t) deal with roadmaps on the Signal v. Noise blog.
In short: roadmaps are a bad idea because they can create uncertainty, false expectations, and guilt. My favorite argument against long term roadmaps is the uncertainty.
We don’t have a crystal ball. Say we have features A, B, and C we want to build. We don’t know if A is going to work out as planned, and what that would mean for B. We don’t know if we’ll have a eureka in the bathtub one day, and new idea X will suddenly feel much more important than B or C. Or we might start building out B, only to realize that it’s not what we want or it’s harder than we thought and want to bail on it.
That means no explicit promises and no implicit promises either. A list on the wall or in some official strategy document is an implicit promise: “this is what we’re doing next.“ There is no official list of what we’re doing next anywhere in the company.
I strongly believe in not writing down big ideas for a product, because if it really is a good idea it will resurface, preferably multiple times.
That said, client projects are different beasts than homegrown software. Clients expect roadmaps, and there’s less wiggling room for features. You can’t really skip expectations, clients expect them. Mapping client projects is a different puzzle to solve.
Sublime is still sublime
I’m trying something new (well, old): Sublime Text. Sublime was my favourite editor for years. It took me a while to not crave Sublime’s speed in VS Code, but Code’s intelligence and extension ecosystem makes it a worthy competitor.
Sublime has a feel that no other editor has. Scrolling, jumping, and typing are seamless. It’s an analog tool in an Electron infested world. I miss that experience, so I’m giving it another go.
I already miss Code’s intelligence, especially with TypeScript, but Sublime feels like coming home. Time will tell if it will last.
How to schedule posts on a static Hugo site with Netlify and GitHub Actions
If all went well, this post was published automatically. I added the ability to schedule posts on my static blog (built with Hugo). I wrote a short GitHub Action to trigger a build on Netlify every morning.
Building on the web isn't building for the web
Today I read “Web Apps Are Not A Thing, Please Stop” by Robin Rendle, who says we should stop treating websites different from web apps.
I agree that web apps need to play by the same rules as website. However, I draw a different line: between building for the web and building on the web.
The revamped Spatie guidelines
I created the original Spatie guidelines site three years ago. Last month, we consolidated a few of our subsites to our main spatie.be site, including the guidelines.
Laravel Typescript Transformer
My colleague Ruben released a new Spatie package to generate type declarations in TypeScript from a Laravel application.
A rare look into the decision making process of a large project
Last week, the W3C decided they were not going to use WordPress for their next website.
The decision making process behind this is happening in the open, on w3c.studio24.net. Accessibility was the driving force for the final choice between three contending CMS’s (WordPress, Craft, and Statamic), but they did a lot of research before.
Why Do We Interface
“Why Do We Interface?” is a micro-book about interfaces over the ages: from cave paintings to Google Glass to your latest note-taking app. It’s important to understand why we build interfaces in order to get better at building them.
The purpose of any interface, regardless of the technology, is to retrieve, decode, modify, and/or distribute information. […]
The core purpose of graphics in a GUI is not to be pretty The purpose is to be informative.
Some questions to ask yourself when you’re designing an interface:
- How does the interface help us retrieve information?
- Is it easy to decode the information that was retrieved?
- Does the interface allow for easy and clear modification of information?
- Does the interface assist in, and clearly declare when it is going to distribute information?
- How will this interface redefine what it means to be human?
Number five is a bit too bold for my taste, but the first four are valuable guidelines.
Read the book on whydoweinterface.com.
Dont Get Stuck
My colleague Brent tells the story of how he got “stuck” at his old job.
I decided to leave because I got stuck, there wasn’t any room to grow anymore. The perspective of being a developer who’s 5 years behind of modern day practices made me miserable.
Even though I’d been advocating within the company to make significant changes, both on a technical and management level; it didn’t seem achievable. We were still struggling to deliver the quality we promised our clients, we were using out of date technologies, I went home almost every day feeling down and depressed.
I believe “we were still struggling to deliver the quality we promised our clients” is what really wears you down. Using out of date technologies might have held the team back in this situation, but isn’t necessarily the root cause.
I don’t regret having worked for that company: I did learn valuable lessons there. It’s ok to be at a place where there’s little or no room for growth, as long as it’s not too long. Watch out, and critically assess your situation from time to time; you might get stuck without even knowing it.
It’s important to evaluate from time to time. Not just your job, but all of your work. Ask yourself how the project you’re working on is going every now and then. What went wrong in the last few months? What are you happy with? Keeping this in check will keep you from getting stuck.
Read the full post on stitcher.io.
A Tale of Client Side Framework Performance
Jeremy Wagner measured some performance differences between React and vanilla JavaScript. While I’m not surprised that running your code on bare metal code is faster than a framework, it’s interesting to see some exact numbers.
React and ReactDOM total about 120 KiB of minified JavaScript, which definitely contributes to slow startup time. When client-side rendering in React is relied upon entirely, it churns. Even if you render components on the server and hydrate them on the client, it still churns because component hydration is computationally expensive.
If it sounds like I have a grudge against React, then I must confess that I really like its componentization model. It makes organizing code easier. I think JSX is great. Server rendering is also cool—even if that’s just how we say “send HTML over the network” these days.
Even with server-side rendering, React and other virtual DOM frameworks add loading time because they need to load more code and hydrate the page before it’s interactive.
A vanilla addEventListener callback performs about 40 times faster (!) than an event handled in a React component. React’s overhead worth when you have a lot of complex state, not “simple state” like menu toggles.
Read the full article on CSS-Tricks.