…the compiler will warn you. In fact the project probably won’t compile.
This prevents you from making a wrong reference. This type of bug is a “wrong reference bug” i.e. we are referencing the wrong thing.
But if you use custom properties, you won’t know if you did something wrong. A color might just fall back to black or the body color and you won’t know if you did something wrong.
:root {
--red: #FF0000;
}
.my-code {
color: var(--redy); /* This error won't be caught! */
}
I recently wanted to make sure I didn’t have any wrong references and had an idea. We can leverage the “fallback” aspect of a custom property to get a visual cue:
What I do in practice is change all variable names temporarily to provide this fallback value (with a regex: replace var\(\-\-(.*)\) by var(--$1, hotpink)), then click through my project to search for anything that looks like the fallback color, in this case hotpink.
When you create a new Figma account, all your plugins are gone. This creates an interesting situation where you’ll only install plugins that you actually use.
The plugin list on my Mono Figma account is huge from trying things in the past and not cleaning it up. But my new freelance account, it’s clean. Here’s the first 12 plugins I installed:
I’ve been a bit dissapointed with the quality of series on streaming platforms. My solution to that: return to great cinema. Here’s ten great movies that were released between 2000 and 2020, in no particular order.
I think one of the biggest problems in computing is transporting complex data from one app to another. Or put another way – manipulating the data that’s on your screen in a sensible way, regardless of the app that you are using.
If I draw a table in Figma, and I have a few numbers, why can’t I make a sum from those? As an alternate solution, why can’t I copy-paste a table-like design, move it to Excel, and make calculations in a then-dynamic table?
This concept of moving something from a “drawing app” to a “spreadsheet app” sort of works between Keynote, Pages and Numbers.
If I make a table in Keynote, I can bring it back to Numbers, with calculations and all, but now the scale and formatting is messed up. But what Apple did here is the beginning of what needs to be done: all apps speak the same language. It doesn’t go as far as I want it to go, but it’s a start.
I dream of a computing world where one app understands what certain objects are and what you want to do. We have had copy/paste between apps since forever, but it’s too simple.
Notion has a concept of blocks. These are also another start but you are locked inside Notion.
If you copy paste out of Notion, you get workable markdown. That’s good, but what if I want to keep continue my work in Pages?
In Figjam, you can now import a CSV as a series of sticky notes.
That’s cool, but I have the feeling that all these small bits and pieces took a lot of engineering work – by people who want to do well. One afternoon a few weeks ago I went deep into MIME types and how the pasteboard can contain different sorts of things. It’s a rabbit hole really.
It also seems quite limited what you can actually because it seems to me you kind of have to parse things on the spot to try and make it meaningful again (in your app). If anybody knows more about this, has a good resource… do tell!
My conclusion at this point in time is that this is really a problem that needs to be solved at the OS level. Apps need much more advanced APIs to be able to talk to each other.
The pasteboard needs to evolve to understand that it’s carrying a spreadsheet with formulas, or an image with an edit history.
What happened in recent years is that instead of solving the problem we now have two problems. On desktop we have the aforementioned poor copy/paste. On mobile we have a logic with share sheets and intents, with a filesystem that is abstracted away. It’s super unclear where your data lives and if you are going to move data from one app to another, it’s a bunch of guesswork what is actually going to happen.
We hebben het vandaag officieel aangekondigd: Mono stopt ermee. Ik schreef in de blog post dat het wat zwaar aanvoelde. En dat is ook zo.
Sommigen vinden dit een moedige beslissing, om op een hoogtepunt te stoppen. Dat is leuk om te horen. Ook de complimentjes over Mono zijn tof.
Maar ergens voelt het ook wel aan als een beetje opgeven. Ik heb hier erg mixed feelings over. Xavier en ik hebben het zoveel gehad over een bedrijf uitbouwen met een mooie cultuur dat het lang volhoudt. Zeven jaar is mooi maar nu ook niet erg lang.
Ik ga nu terug een stukje freelancen, en rondkijken welke uitdagingen er allemaal zijn om aan te pakken.
Mensen vragen – wat ga je nu doen? Sowieso blijf ik gepassioneerd door de dingen waar ik voorheen al gepassioneerd over was. De mix tussen design en development; een stukje management.
Ik wil iets doen met genoeg uitdaging, iets ondernemends, iets waar ik mijn ei kwijt kan. Op een hoog niveau en waar het project dat je maakt ook effectief tot uiting komt. Dat wordt flink zoeken, denk ik.
De meeste mensen gebruiken hun computer omdat het moet, en ik denk dat ik stilaan ook zo ga worden. Want de laatste weken hebben de computers zoiets van: FU Johan, we gaan u gewoon een beetje tegenwerken.
Mijn Withings horloge is gestopt met werken, de minuutwijzer draait niet meer. Een week in rijst leggen brengt geen soelaas. Weer een apparaat voor de IoT graveyard.
Mijn iPhone SE2 heeft ‘s avonds vaak geen batterij meer, terwijl ik ‘m overdag amper gebruik. Mind you, dit is een GSM die 5 maanden in gebruik is.
Mijn Apple Notes app heeft een gigantische memory leak die er basically voor zorgt dat mijn iPhone niet meer functioneert. Er blijft altijd maar storage ingenomen worden waardoor ik uiteindelijk geen plek heb op m’n phone, terwijl er eigenlijk meer dan genoeg plaats is.
Ik ben nu overgeschakeld ben op Bear maar vind het niet helemaal je-dat. Ik zou eigenlijk gewoon graag bij de officiële notes app blijven.
Dan op de echte computer, Alfred en Google Drive zijn geen goede vriendjes, en ik heb er 2 weken over gedaan om een halve oplossing te vinden. Ik zet ook vaak links naar Google Drive folders in de Finder zijbalk voor easy access, maar die verdwijnen telkens. Gelukkig heeft Xavier daar een truukje voor met aliases, dat ik nog eens moet proberen.
De computers, ze zijn precies op zomervakantie. En mijn geduld om elk klein software probleem te gaan researchen is ook een beetje op. Vroeger ging ik daar nog achter en spendeerde ik uren om zo’mn dingen te fixen.
Ik snap Rasmus als hij zegt dat hij bij OSX10 blijft in plaats van 11, omdat je daar nog enige controle blijft hebben over je computer bij problemen. Alle problemen die hierboven beschreven zijn, zijn het gevolg van matige software.
Je zou denken dat dingen vooruit gaan, maar ze gaan ook achteruit. Ik word misschien gewoon “nen oude mens”. Maar mensen moeten ook maar deftige software schrijven gvd.
To draw a line, use the line tool. Sounds logical, doesn’t it?
However, since year and day, I’ve avoided using the line tool and I don’t think I am the only designer to do so.
If you’re using a line for a border, do yourself a favor, and just draw a rectangle instead. What you’ll get in return: maintainability. Precision.
This is for a Figma context but I remember doing the exact same in Sketch.
Why? It will most always be perfectly on the pixel grid, unless you started manipulating the exact values or did some kind of weird transform.
You can also use ⌘ (or Ctrl if you’re on Windows) plus the arrow keys to change a 1 pixel line into a 2 pixel line very fast. No need to go into a side menu.
I love direct manipulation and I’ll use any workflow that allows me to manipulate the canvas directly. I love to hide Figma’s UI and do a lot of design work without every going into a menu.
So dear designers. Use rectangles for borders, not lines.
For the inner shadow people…
Some designers think they are clever and use an inner shadow to prevent the pixel being off-center.
Stop the madness! Who wants to open a lil’ popup and manipulate popup with 7 fields to make sure that you have a line somewhere?
Setup: from fromt to back. Drybag from diving a few years ago, stuffed with small sleeping bag + small inflatable mat. Strapped to front with a few camping straps. Ortlieb frame bag, Decathlon bike bag on top of that, 2 drinking bottles below. 1 Ortlieb back pannier bag, tent poles on rack. Tent: just a cheap Decathlon Quecha tent in the pannier bag. Bike: Trek L500 carbon drive (a good city bike really)Front detail. I bought a quad lock to put my phone on. The decatlon bag holds the phone charger to keep the phone charged because riding with GPS all day consumes a lot of battery.Whoops. Pushing through the sand. The times I wished I had a MTB (I now see the rideable stretch on the left)Kyoto bamboo forest vibes in LichtaartSomewhere in ‘nam. Euh, Mol.<3
This was my first bikepacking adventure. I had a lot of fun taking it on this weekend. I started at home in the morning. Left 9:30 in Antwerp, went to Schilde, passed by the Sas4 tower and the nearby bar, then slept at the mentioned camping. I managed to arrive at 17:00. Next time I think I will go a bit further in a single day.
This route combines a lot of small forest roads in a neat way. I especially loved the singletrack MTB parts, through dense forests. One area in Lichtaart reminded me of Kyoto’s bamboo forest and another near Mol of a bridge in Vietnam. Who needs to go far when you’ve got these wonders near home?
So next day ate at Roovertschje Leij around 14:00, popped into the nearby town Albert Heijn to get some new snacks to be able press on. By Sunday evening I got tired of pushing through the wet sand. It was raining on and off.
I think I was close to Breda at the +-175km point. I Google mapped my way to home, with a boring stretch of 50km Bredabaan. Laid on my bike as I pedalled away to get home 9PM. I am not an experienced biker and I really struggled to take the dirt roads in a faster way.
I did this on a city bike with a carbon belt and one pannier bag. I’m happy I did not take two. It’s doable but next time I am taking a MTB :’). Had to absorb a lot of bumps and the loose sand in places had me either pedalling like crazy to keep velocity or sometimes having to step off to push through the sand. All in all worth it for some incredible sights.
Vital stats:
Distance: 225km
Riding time 13:55 hours
Average moving speed: 16,2km/h
Max speed: 34km/h
Elevation: +453m/-440m
Liters of water drunk: at least 7
Friendly camping people: 14
Most marginality seen in a single kilometer: Brasschaat on a Sunday evening
For a while, I blocked the Tailwind keyword on Twitter. I was a bit mad that @tailwindcss and author Adam blocked me on Twitter after I wrote a bit of criticism that got popular.
I was also tired of getting dragged in every Tailwind related conversation on the Svelte Discord. Apparently people thought it would be fun to mention me every time Tailwind came up. I guess I brought upon myself with these blog posts:
(All I was trying to do was making people reconsider their CSS strategy instead of blindly going for the new popular framework.)
Now, getting blocked by a person, that’s one thing. I guess Adam’s coping strategy with criticism was an “I don’t want to hear it.”
Needless to say, you then create your own bubble of truth. I understand you want your social media experience to be pleasurable. I’ve been getting into some stupid Twiitter fights recently and they can get you annoyed.
The weird thing is we never even had an interaction or anything on Twitter. Then there comes the point where I have to use Tailwind for work and I am blocked by an offical account and – that feels kind of stupid? Getting blocked by a company entity for having an opinion is kind of… strange?
??!
It’d be like my bank wouldn’t want me to be a customer anymore after I critiqued their app (post in Dutch). Sorry. Being critical of these things is part of _my job_.
Anyway.
You know how sometimes you fight something and it just doesn’t die? And then it just becomes part of the ecosystem? I think Tailwind is a bit like that. There’s no going back. It’s just part of the system now.
Just like I don’t like React I will probably never really like Tailwind.
But that doesn’t mean that I can’t be a professional and write the best Tailwind code I can if that’s what’s asked of me. And try to find the good stuff in there, which is what this post is about.
It’s the same with React. The rest of the world already decided a long time ago that React is a good idea. I don’t like it. I think the syntax is too complex and too many parts of the ecosystem try to reinvent the wheel. But there’s definitely good parts to React. Some of the most exciting frameworks I’ve found recently are all written in React.
So generally, if I don’t like a technology, I now have 2 choices: complain about it and try to avoid it or try to deal with it the best way I can.
So after battling Tailwind for a while, a new project came up, where Tailwind was requested as a part of the development.
I was tired of fighting it and I remembered what people argued in the original criticism, “have you actually really used it?” – upon which I argued – “I don’t need to use it to know that it’s bad! I tried it for a two hour experiment and I already know!”
Now. of course a two hour experiment is not the same as real-world experience. It’s not the same as giving it a try in a codebase with multiple people. It’s also not the same as being a deliverable towards a group of people who don’t know much CSS.
You see, it’s all easy to claim the right path for years, but if in the end your deliverable is too difficult to change or maintain, maybe you should question your methods.
I can forever claim that people should just learn CSS but if that happens to be a difficult thing, maybe we should try to make a deliverable that is more… malleable. Even if it creates some maintainability problems.
I know the devs at Spatie love Tailwind; a developer I respect also loves it. So surely there must be something there?
Long story short, the stars were aligned to give Tailwind a real try.
The Tailwind authors themselves argue that all the Tailwind overload of classes a shock at first but gets productive soon.
I don’t know if I was entirely productive at first because I first had to shake up my dev stack to add in support for PostCSS, PurgeCSS and figure out all kinds of Tailwind specific things. That was part of my original criticism – people kept bring up config & build problems in the Routify Discord – but I just happened to be in a productive dev tooling month, and built in all the tooling so I could run a Tailwind-based workflow in earnest.
And after that, going into the work of implementing a UI I had to admit. There is something here.
You know how there’s this huge book called JavaScript: The Definitive Guide and then Crockford’s JavaScript: The Good Parts?
I think there’s also something like Tailwind: The Good Parts.
Documentation is extensive and well written
I love the ⌘+K shortcut
The new Headless UI looks great and solves a real problem
The Tailwind UI project’s look for their component has some good visual choices (although Tailwind’s techniques make that look kind of baked in, especially if you use Tailwind UI)
Tailwind UI’s Figma file has the highest level of quality I’ve ever seen in an external Figma file
The underlying idea of design tokens to customize design output is great; design tokens are now being discussed to be a standard; having a centralized config that builds constraints into CSS systems will help maintainability. A framework that promotes those ideas can be a boon.
Now, time will tell if I’ll really regret going down this route. But for now, I’ll happilly accept Tailwind-based projects and learn as much as possible.
From a team perspective, it’s not just my opinion that counts. It’s the combination of opinions from the client (we often work directly with the dev team), my colleagues and myself.
If more projects come up, and as we learn more about Tailwind, I’m sure I’ll have something new to say. But for now I chose to embrace it as a new workflow. Just don’t say I never warned you if code become unmaintainable in the end.
