Blog – Page 15 – Johan Ronsse

Hey, your API surface is causing unnecessary complexity

August 20, 2020 - Posted in css rant tailwind webdev - 2 comments
I’ve been “fighting” against Tailwind for a while, and there’s 4 different kinds of reactions:
1. Please stfu, Tailwind is awesome, [insert technical argument]
2. Johan, why do you bore me with these technical things? Can you please tweet about cooking? And where is your new post about sim racing?
3. If you don’t like it, just don’t use it
4. Nod – you are right (this is mostly coming from the people from my same “generation” who learned web development around the same time as I did)
The fighting takes the form of blog posts and tweets. On the Routify Discord channel it’s already a running joke that I’m going to vent when somebody comes in to ask a Tailwind question.

Yesterday someone reached our privately, basically to challenge me to channel this negative energy into something positive. I agree that would be nice.

For now you will have to do with this blog post which is still in the rant-o-sphere. But I will take up the challenge to maybe work on something that shows my opinion on how to do it “right”. That’s going to take some time though.

Why do I get so worked up about Tailwind? Because bad frameworks create problems that shouldn’t exist.

I help to maintain Routify, at least from a community and docs perspective. Quite a few support questions that come in are about dev pipelines, and some of them about Tailwind. A CSS framework I don’t like creates a support problem for me. I cannot simply ignore it (so that’s a rebuttal against the point to simply ignore the existence of Tailwind).

What I see is that bad frameworks create a crazy learning path for new devs, where they might waste months learning to work with frameworks with crazy APIs only to find out that they haven’t really learned anything.

Learning modern web development is already intense. But at this point in time, a lot of modern web development leads you down a path where you might not learn all that much, because you are fighting poor decisions made by other people. Maybe if you’re new to this, you think that’s just the way things have to be.

One thing that I want to mention is that not everything about Tailwind is bad. I think the visual look is quite solid. The way the framework is promoted is well done, with well-produced video content and blogging that has gone professional. I mean, this team knows their stuff. I just fundamentally disagree with the premise of littering your HTML with classes. I disagree with shipping a framework that has accessibility issues.

I am often in a position where I am mentoring new hires to our company. A few months ago I pointed someone new to Adam Wathan’s article “CSS Utility Classes and “Separation of Concerns””. This is a great article by the author of Tailwind.

I guess with the above I just want to point out that I am not blind to the Good Parts of Tailwind (just like there are good parts to React ;) *shields from incoming flames*)

But overall I am worried that some framework makers live in their own theoretical world and forget about the real world. They are striving for a technically perfect framework but forego the real-life usage. For them the framework is the project and the lens they view things through. The usage and the actual project where their framework is used is just a detail. When it should be the other way around.

This kind of perspective leads to frameworks that constantly change their mind about what they want to be, leading to work down the line for the users, that often has no real-life value at all.

In my blog posts taking down Tailwind I am mainly writing from a worry of having to maintain a codebase full of classes.

Somebody tweeted this screenshot and I’m like: seriously?

If you look really well you can see that this shows a heading and 2 buttons, but it’s a bit hard to see. If you’re interested why this is just a poor way to develop your things you can go back to the blog posts and see what I had to say.

Today this post is more about a broader perspective. I eventually gave this post the title “Hey, your API surface is causing unnecessary complexity”. This was triggered by Tailwind basically repackaging CSS gradients in their own proprietary syntax and then limiting what you can do with gradient because they don’t support everything. And I’m like: why not simply use CSS? Like, which problem does this solve?

It just adds to the complexity of Tailwind. It creates something new for a dev to understand when they find this code. It creates a new documentation page that has to be maintained. It creates a new surface area for bugs. I think sometimes you just have to stop developing a framework. Sometimes, things are finished. The problem with Tailwind is that since it basically mirrors CSS, it will simply never be finished as long as CSS keeps adding new features. Which they should also put a stop to, in my opinion.

I see what I’m talking about – adding unncessary complexity — happening with both SCSS and the CSS working group. In October last year, SCSS modules were announced and literally nobody cared. I love SCSS – I have been working with Sass since the early days and contributed to the first documentation site of Compass. That was my first introduction to open source. But Sass/SCSS has now reached a maturity point that what people are adding is so niche that nobody really cares anymore. Look: SCSS was already done.

Now the CSS working group is discussing some sort of cascade layering system within CSS itself.

I applaud the efforts to try and solve problems with CSS, but I also fear that maybe they are in vain. I think CSS is already complex enough. You can read my thoughts in the comment below the linked spec.

In a discussion with a fellow dev about Svelte 3, he said Svelte 3’s API is nearly perfect. There is not much to add. In a lot of the pull requests about Svelte where people try to add features, there is pushback because it will make the framework more complex. Personally I love this. I want people to be able to attain Svelte mastery. To understand the API in full.

I don’t want a framework that has a thousand nooks and crannies and that has 2 or 3 ways to do things.

In React world there is the pre-hooks way and the post-hooks way. In Ember world there is non-Octane and Octane. Vue is moving to Vue 3, but at least that is backwards-compatible.

Maybe Svelte will go to a transition at some point where there is a Svelte (4?) API that is vastly different; maybe it won’t.

But I think people should realize they can’t keep adding complexity on top of complexity. People should really stop and think if you really need 500+ Mb worth of node_modules to build a simple website. Developers need to think about the API surface of the tools they are building. There is an optimum point where it’s better to stop instead of cramming in feature after feature.

We are moving towards a world where people are doing web development where they are purging a 1.4Mb CSS file to 28kb ( for the actual selectors they used) on a CI environment that they don’t control. And then one day AWS goes down, and maybe npm gets hacked, and the poor web dev who hasn’t built up fundamental skills doesn’t really know how to do anything anymore, because they always depended on others (what is SSH anyway?).

I think people need to know fundamentals. You can’t depend on a few magical incantations on the terminal that you don’t fully understand.

The same goes for any kind of development. When you write a CSS rule you have to understand what it does and where it is coming from.

When you deploy a website you have to understand what is happening behind the scenes.

When you use a framework, you have to work towards understanding it in full. You have to know why it exists and why you use it.

If somebody wants to use Tailwind and has a set of reasons, that’s fine for me. What I don’t like is people defaulting to things that are popular and then learning a stack that basically abstracts the fundamentals; this leads to a situation where junior web devs work for 3 years but lack fundamental skills because they were too busy trying to fix local problems created by poor frameworks. And that’s what I’m fighting.
Using Yalc as an alternative to npm link

August 17, 2020 - Posted in webdev - 1 comment
This is mostly a reference for myself. For some technical things I tend to use my own blog if I forget something.

This is an example of how to use Yalc as an alternative to npm link . I find that npm link doesn’t always do what it should, and I found yalc to work better.

First, install Yalc:
```
npm i yalc -g
```
(1) Go to your dependency project’s folder, make a branch, do yalc publish

(2) Then go to child project where you use the dependency, install it there with yalc add <projectname> (it replaces the version package.json with your local version)

(3) Restart your project – typically you will have to stop/start the server (Ctrl+C / npm run dev)

I do this with 3 terminal tabs, juggling between those 3 actions. Yalc puts the packages in a temporary .yalc folder on your local computer.

(I discovered Yalc through this post. Thanks Viget!)
Slimme regels a.u.b. (mondmaskerplicht in de praktijk)

August 3, 2020 - Posted in politiek - 1 comment

Wie o wie zit er in dat veiligheidsoverleg en waarom kunnen ze geen slimme regels bedenken?

Het enige dat ze eigenlijk moeten zeggen is dat je altijd verplicht een mondmasker moet bijhebben, en als je dichter dan 1,5m bij iemand anders in de buurt komt, dat je dat dan opzet. En dat het in elke binnenruimte die niet jouw woning is verplicht is om het mondmasker op te zetten.

Vanaf vorige week dinsdag werd een mondmasker verplicht “in het gehele publieke domein” in Antwerpen. Met andere woorden, als je gaat lopen, zoals ik tegenwoordig wel regelmatig ga doen, moet je een mondmasker ophebben. Dit is toch niet te begrijpen? Dit is gewoonweg niet gezond.

Het moeten ophebben van een mondmasker is voor mij goed als het nodig is, maar als het niet nodig is, haalt het ook het plezier weg van bv. een gezond fietsritje op rustige wegen ‘s avonds.

Mijn voorstel: je moet een mondmasker bijhebben, en het aandoen als je mensen passeert dichter dan 1,5m afstand. De regel in paragraaf 2 covert dit reeds.

Laten we het zinnig houden. Er is al reeds een coronaregels-moeheid, laten we niet overdrijven met onzinnige regels die echt niet gaan helpen.
Cooking channels

August 1, 2020 - Posted in cooking
Some recent cooking channels that I like on YouTube:
If you’re curious about my own cooking exploits, follow me on IG.
Pakken wat je kan pakken en sociale fraude

July 23, 2020 - Posted in belgische-problemen ondernemen opinie politiek

Ik ben er 100% voor gewonnen om noodlijdende bedrijven uit de crisis te helpen.

Maar wat ik zie en observeer is dat veel bedrijven — in typische België-stijl — ook gewoon pakken wat ze kunnen pakken.

Voor sommigen was het niet echt nodig om hun werknemers op een tijdelijke werkloosheid te zetten, maar ze deden het toch, en sommigen bleven zelfs gewoon doorwerken om ondertussen van uitkeringen te genieten.

Iedereen heeft zijn eigen perspectief op zijn zaak en in België is er vaak de logica dat “aangezien we toch zoveel belastingen betalen, je moet pakken wat je kan pakken”. Maar er zijn daar duidelijke grenzen aan.

Het laten werken van mensen die op tijdelijke werkloosheid staan is duidelijke sociale fraude. Hier staan grote straffen en boetes op. Helaas loopt het Belgische gerecht achter en is de kans dat iets effectief bestraft wordt mij eigenlijk redelijk klein. En het is net die lage pakkans waar de fraudeurs op rekenen.

Er is een mop over twee Belgen die op café gaan met een Duitser. De ene Belg schept op tegen de andere Belg hoe hij belasting heeft ontweken. De andere Belg is benieuwd hoe hij dat gedaan heeft. De Duitser belt ondertussen de politie.

Het begrotingstekort in België stijgt drie keer sneller dan het Europees gemiddelde (bron). Dit heeft vele factoren, maar één ervan is volgens mij alvast de moraal van sommige bedrijfsleiders.

Dus, neem a.u.b. je verantwoordelijkheid. Maak enkel gebruik van noodmaatregelen als je het effectief nodig hebt. En laten we dit land niet in de afgrond laten storten.
Overheid als marktverstorende factor

July 22, 2020 - Posted in belgische-problemen politiek subsidies

De overheid heeft SmartSchool €200.000 euro gegeven tijdens de crisis, stond er een tijd geleden in Het Nieuwsblad.

Ik verslok me bijna in mijn koffie toen ik dit las. Qua marktverstorende werking kan dit tellen. Was dit dan een reeds bestaande subsidie of een corona-extraatje? Welke logica is er om €200k cadeau te geven aan een bedrijf? Wat met de concurrentie van SmartSchool?

De overheid geeft een bedrijf dat al marktleider is een serieuze boost.

Wat moet iemand die een startup wil oprichten in deze sector nu doen om te kunnen concurreren? Dit is pure oneerlijke concurrentie. En toevallig is dit bedrag net de limiet voor de Europese Commissie qua toegestane steun.

Beeld je nu eens in dat je iets aan het maken bent in de educational space. Je hebt het om te beginnen al moeilijk als startup, en dan geeft de overheid jouw grootste concurrent een cadeautje waarmee jij een heel jaar zou kunnen werken met een team van 4 aan een product, en jezelf nog eens een relatief OK loon zou kunnen uitbetalen. Wtf? Dit is niet oké.
Geld in je vennootschap is zuurstof voor de groei

July 21, 2020 - Posted in belgische-problemen ondernemen opinie politiek

Al jarenlang wordt onze vennootschap met meer dan 30% belast. De vorige crisisbelasting zit nog in de vennootschapsbelasting en is nooit verdwenen. En ondertussen zitten we in een nieuwe crisis.

Van elke cent die wij verdienen gaat er dus elk jaar bijna 1/3 terug naar de overheid. Dit gaat over het geld dat in het bedrijf kan blijven zitten voor verdere groei: dit is nog niet de finale uitkering + belasting. Ik spreek hier dus puur over werkingsgeld om iets mee te doen — een risico mee te nemen, iemand nieuw aan te nemen etc. — niet over de uitkering naar privépersonen. Die belastingsdruk zorgt voor zeer weinig zuurstof om te ondernemen en voor een tragere groei.

Voor een dienstenbedrijf is het eigenlijk heel eenvoudig. Je kijkt naar je overschotten en je berekent je cashflow. Afhankelijk van hoeveel geld je over hebt, ga je meer of minder risico nemen. Ga je nu 2 personen aannemen of 1?

Hoe harder de overheid ons belast, hoe minder mensen wij kunnen aannemen die uiteindelijk zorgen voor werk en groei, die uiteindelijk zorgt voor meer belastingsinkomsten. Door telkens meer te belasten zet je een knip op de groei en is er uiteindelijk weinig om te herverdelen.

In De Afspraak van maandag 15 juni zei Isabel Albers het goed, in een gesprek met Raoul Hedebouw van PVDA (al grappend de Partij van de Armoede genoemd): er moet welvaart zijn om te herverdelen.

Voor de creatie van welvaart moet er ondernomen kunnen worden. Als de overheid constant de groei afremt door een hoge vennootschapsbelasting zet, de de creatie van welvaart moeilijker. Als daarnaast de beloning aan de eindmeet ingeperkt wordt*, wordt het telkens onaantrekkelijker om te ondernemen.

Er was al een gat in de begroting, en na corona is er een krater. Er gaat gezocht worden naar manieren om de staatskas aan te dikken. De overheid moet echt goed opletten hoe ze dat gaan doen, want er is in mijn ogen geen marge meer aan de belastingskant. Als je nog verder gaat belasten zet je automatisch een knip op het potentieel.

Verlaag de belastingen op arbeid, verlaag de vennootschapsbelasting, en zorg voor een groeipotentieel.

*Ja, we zijn de enorme verhoging van de belasting op liquidatie nog niet vergeten (Di Rupo)
Er is een duidelijk economisch relanceplan nodig in plaats van cadeautjespolitiek

July 20, 2020 - Posted in belgische-problemen nederlands politiek - 2 comments

Nota: het is vakantie, tijd om mijn blogpost kladjes toch eens te publiceren. Dit is van een paar weken geleden, over de weggeefpolitiek van de superkern t.o.v. duidelijke structurele maatregelen.

Twee weken geleden op zaterdag konden we de resultaten van het superken-onderonsje lezen: een hele rits maatregelen, o.a. een BTW verlaging in de horeca tot een railpass voor iedereen om binnenlands toerisme te stimuleren.

Vorige week zaterdag was het ook weer cadeautjestijd. In een tijd dat er in mijn ogen budgettaire controle moet zijn of uitgaven die gericht zijn op groei, kregen we in de plaats uitgaven die gericht zijn op behoud en status quo, en een paar onbenulligheden om de kranten en het politiek discours bezig te houden (o.a. de onbenullige discussie rond de Railpass)

Deze week is de formule van de superkern gelukkig afgesloten en zijn de gesprekken rond een regeringsvorming concreter dan ooit. De olijfboomcoalitie werd maandag snel afgeschoten, maar met de deur naar een minderheidsregering open te zetten zijn een aantal partijleiders in actie geschoten om toch te proberen een meerderheidsregering op poten te zetten. Ik volg met aandacht de berichten van 8AM wetstraat insider.

Nu. Terug naar de cadeautjespolitiek.

We hadden eind 2019 al een begrotingstekort van 12 miljard dat afsteven op 15+ miljard. Na Corona wordt er geschat dat het meer dan 50 miljard zou gaan bedragen. Dat we jaren nodig gaan hebben om uit het slop te geraken.

Ik snap het idee van een relance van de economie en van het consumentenvertrouwen op te krikken. Maar deze weggeefpolitiek waar 10 partijen hun cadeautje(s) in de wacht kunnen slepen en het zelfs niet meer nodig om dit te toetsen aan een centrale begroting vond ik een triest eindpunt van een niet-volwaardige regering.

Als je die maatregelen eens bestudeert, met de weinige info die er beschikbaar is, kan je afhankelijk van topic zien dat het ofwel gaat om een aantal kruimeltjes te verdelen (want sommige dingen zijn effectief triviaal op een volledige begroting) ofwel de deur wagenwijd open te zetten richting budgettaire crisis maal twee.

Wat ervoor een moeilijk evenwicht was, kan opeens. Het kan niet op met de uitgaven.

Buiten de NV-A met een symbolische exit op de laatstte superkern durfde geen enkele partij op de rem te gaan staan. Vanuit het idee van samen uit, samen thuis in de noodregering begrijp ik dit. Maar de geformuleerde beslissingen kunnen iedereen wel eens zuur opbreken, als de snel goedgekeurde maatregelen nu allemaal één voor één afgeschaft gaan moeten worden of toch fundamenteel gewijzigd moeten worden wegens niet realistisch.

De superkern blijkt eigenlijk de kern van de onmacht: door 10 ideeën op tafel te gooien die niet uitvoerbaar blijken te zijn, die erna in een parlement met een minderheidsregering gefileerd worden, krijg je uiteindelijk een halfslachtige uitvoering van elk idee, en een politiek waar iedereen naar elkaar kan wijzen maar niemand de verantwoordelijkheid draagt.

Want achter gesloten deuren werd beslist wat goed was voor België, en dat moest dan maar zo zijn…

De normale parlementaire controle, voor zover die nog bestaat in de Belgische particratie, ontbrak volledig in het superkern-beslissingskabinet. Nu hebben we een volwaardige regering nodig om de crisis echt te counteren.

Wat mij interesseert is de mogelijkheid om mijn bedrijf te doen groeien op een goede manier. Ik heb geen behoefte aan extra administratie rond een horecacheque. Ik wil niet gebeld worden met fake sollicitaties waar de overheid me zou voorliegen en mijn tijd verspillen.

We hebben behoefte aan een kleinere overheid, die minder kost, en die minder beslissingen maakt die ongelofelijk veel geld kosten en niets uithalen. We hebben nood aan een overheid die een gedurfd economisch plan op rails kan zetten dat ervoor zorgt dat mensen effectief kan ondernemen.

Wat als de overheid een relance plan op tafel legt dat ondernemers aanzet om actie te nemen en te investeren? Een relance plan dat diegene die durven ook effectief beloont? Waar ik nu de indruk heb dat ik als ik het zou durven om tienduizenden euro’s te investeren in een idee, dat dit gewoon kapot belast gaat worden. En dat ik eigenlijk gewoon de staat aan het subsidiëren ben via mijn bedrijf in plaats van de vruchten te kunnen plukken van slim ondernemen.

Ik heb nood aan een relanceplan waar ik in geloof. Ik zou graag binnenkort een tekst van een relanceplan lezen die ondernemers aanzet om te durven investeren. Zodat we een interessant en ondernemend najaar kunnen beginnen.
Why you’ll probably regret using Tailwind

July 8, 2020 - Posted in css development tailwind webdev - 22 comments
I see Tailwind being used by a lot of people. I totally get why it’s so popular. It looks great, the design choices are sensible, and you have copy-pastable code that reliably renders in the same way.

It nets you results quickly which feels nice and rewarding. I think Tailwind is a perfect framework for two kinds of situations:
1. people who don’t want to learn CSS
2. people who want a standardized look and want to copy paste from an external library (i.e. Tailwind UI)
I mostly wanted to shut up about Tailwind, and I hoped that people would realize it should be avoided after a while. But that doesn’t seem to be happening. So I think I have to fight the fight and talk about why you should not use Tailwind.

I have had a lot of thoughts about Tailwind, and most of these thoughts come from a place of being the code maintainer of a large scale web application codebase. So mind you, when I am talking about regret in the title, I am talking about a big web app context where your code is going to be maintained for years to come.

I am not talking about your Sunday side project. I am talking about real, big work® projects here. I am talking about maintaining something that has a lot of complexity that many people will work on for years to come.

You might be tasked with choosing a CSS architecture for that. And you might have heard about this framework called Tailwind. It’s popular right now and it seems to be the 2020 choice.

You look at the website and you see this nice framework that promises you that things are going to be cool in Tailwind land. And you might be thinking: cool, let’s try that.

I urge you to reconsider your options. I would advise you to not use it.

I really don’t know why Tailwind got so popular over the last year. I think it’s because it does a lot of things right. Surely if the authors can make $1.8M in preorders for Tailwind UI, something must be up. But at a fundamental level, I think its ideas are wrong and lead to problems, and I am going to explain why.

The main problem is that the kind of code you are creating with Tailwind, especially on large scale applications, is the kind of code that you’re going to have to swap out in a few years. Why? Because it’s unmaintainable at best. I will explain below.

An API on top of an API

Tailwind is a framework that heavily relies on utility classes. Utility classes are classes that typically do one single thing e.g. .flex makes a <div> have display: flex. Utility classes create an API on top of what is already a declarative API (CSS itself).

This can lead to problems when
1. the original API (CSS itself) might change in the process, so now you have a mapping problem
2. the mapping itself is not that great, and has bugs on its own
To dive into situation 1, let’s think about how maybe CSS grid will have an evolution in its syntax. Now you don’t just have to update your code, but also the in-between framework (Tailwind).

To dive into an example of situation 2: I was on a project a while ago where somebody mapped Flexbox to utility classes wrongly (i.e. the mapping contained obvious mistakes) and that code had made into production, was versioned, and we couldn’t change it. I thought that was very painful.

Tailwind’s coding style creates its own problems, which you then have to solve

There’s also a deeper problem: because you are essentially recreating the CSS API with utility classes, you end up with a huge file. The current Tailwind utilities.css file is 1.8 megabyte and contains 80 000 lines of code.

Tailwind proponents will tell you that you can remove unused CSS with Tailwind’s tooling. And this is exactly the problem that I want to talk about: now you have to solve a problem that’s inherent to the framework, adding complexity to your project.

In the Routify and Svelte Discord channels I routinely see people struggling to get the toolchain around Tailwind working. So many people struggling with a toolchain that is totally unnecessary is a real problem. Removing code that shouldn’t be there in the first place should not be necessary.

Sidenote: I’m not against utility classes

Surely it feels nice to be able to quickly write flexbox things in a declarative way, and it has it’s uses. I’ve happily wrote declarative flexbox code in the past to quickly set up layouts. I am not against utility classes at all. It’s quite handy to set up layouts quickly with utility classes. I can also totally relate to the idea of designing in the browser with a set of utility classes.

When I do web app layouts we typically have a lot of different panes and panels going on in your app with varied logic about how they should resize. In a prototyping or an early app phase it’s super handy to not have to write a specific (BEM) component for everything and just build things out with utility classes.

But you have to be careful with utility classes. Because what you’re essentially doing is building a complication on top of CSS itself.

When you use a utility classes, for example declaring a flex utility on a div, you are doing it in HTML instead of declaring it in CSS this can quickly lead to unmaintainable code.

I use utility classes in one-off situations. Tailwind style code uses utility classes for everything. Tailwind lovers will now come back to me with arguments about @apply but this is just throwing more complexity on something that is already complex.

Adding complexity to complexity

Tailwind’s HTML code is fine for very simple projects (which will now have the drag of a whole toolchain to purge unused selectors but OK).

But let’s just imagine you have a bit of a bigger project, with a basic app layout that is working, with a few panels and a few buttons.

You now have to update the code for the next requirement – a bit of responsiveness. The UI has to change according to a breakpoint. So you add some Tailwind breakpoint classes to the thing you are making.

You realize your specific situation requires a very specific breakpoint. So you change your Tailwind config to add this breakpoint. You kind of realize it would be easier to just write the breakpoint directly in CSS, but you want to do things the Tailwind way.

If you would do things the regular CSS way, your media queries list basically lives in two worlds: the tailwind config and a local CSS file. And now you’ve lost your breakpoint structure. So you have to adhere to the Tailwind style.

And then let’s say you have a new situation: dark mode has to be supported. So suddenly your colors all have to change according to the dark mode logic. So now you add a bunch of classes to whatever you are creating again… you look at your button code and you see that the color of the button is directly in the HTML (gray-100). And the opposed color is actually called gray-900 in your design system. So now you add a class to the button for the dark situations. And you now realize that there are 7 variants of your button in your codebase and they all have different class combinations.

Now, with the previous responsive example, and this dark thing piled on top of it, you have a sorry mess.

And then you realize that some aspects of what you’re doing would be way easier to handle directly in (S)CSS, using contextual media queries and proper use of the cascade.

Maybe your web app is never going to see the complexity I am talking about. Maybe your apps are not responsive or they don’t support dark mode. But most of my work supports some form of skinnability, is as responsive as possible and needs to be maintained over several yerars.

Putting values on the same class level in HTML is basically destroying the cascade for you. So don’t do it.

Complexity overload and no proper way to manage it

The problem with Tailwind is that you end up with an overload of classes in your HTML and no way to manage these.

Tailwind’s creator says it’s not a problem because your code can essentially lives in deep presentational components and it can be abstracted away. But this kind of coding strategy leads to its own problems (e.g. prop drilling)

I’m especially wary of this situation where you have one button that has 6 HTML classes, and then another button that has 5 HTML classes, and another one that has 7 HTML classes. And they’re all different combinations. Now you have to do some serious digging through the codebase to try and bring everything in line, and you’re going to be comparing which of the three buttons have class overlap. Nobody is waiting for that task. And frankly, it’s probably just not going to happen.

It’s code rot that’s going to happen as soon as you have a few people working on a project with moderate complexity.

I fear for a Tailwind future

I already see Tailwind popping up all the time in Javascript articles that have nothing to do with CSS. The authors use it because it’s a quick way to style their tutorial. In the process they’re halving the shelf life of whatever they’re writing, and dirtying up their examples with a boatload of HTML classes.

I fear for the general codebases of web apps when too many people decide that Tailwind is the way to go. Now, on the other hand, this means I’ll have an infinite stream of work to refactor bad codebases to better ones. So I guess I’m not complaining.

Just do yourself a favor and stop using Tailwind.
Input & output

June 19, 2020 - Posted in nederlands opinie politiek

Een week of twee geleden verscheen er een post in mijn feed van een jonge politicus, ik denk 22 jaar, die na 3 jaar gedemotiveerd was en ermee stopt.

Dat vond ik precies een beetje snel om iets op te geven. Je moet tijd in iets steken om van iets een succes te maken.

Ik ben 14 jaar aan het werk, 9 jaar zelfstandig en mijn huidig bedrijf is 6 jaar oud. Ik timmer aan de weg, en het gaat me soms wat te traag. Maar de weg is sowieso lang.

Ik ga er altijd van uit dat enige vorm van succes minstens 10 jaar zal duren. En dan is het nog snel gegaan. En dan kan je nog een gesprek beginnen over de relativiteit van succes en wat succes dan juist betekent.

In ieder geval, hoeveel moeite je in iets steekt en hoe je het aanpakt vind ik wel een interessant gegeven. Iets om over na te denken. Vooral omdat ik ook nog mijn eigen plaats in de politiek zoek. Ook daar ga ik er van uit dat het een lange weg wordt.

De jongeman in kwestie is teleurgesteld door lokaal haantjesgedrag, door geen kansen te krijgen van de oude garde, doordat er niemand hem helpt als hij campagne voor zichzelf voert.

Maar dan denk ik: wat had je dan verwacht? Wat dacht je dat er ging gebeuren? Dat je je aanbiedt en opeens alle deuren openen? Dat mensen je spontaan gaan helpen in een logica waar het op een bepaalde manier ieder voor zich is?

Hij neemt er een anekote bij van duizenden brieven schrijven en opsturen. Hij vind duidelijk dat hij enorm veel moeite heeft gedaan. Ik kan zijn gevoel wel begrijpen, maar ik denk ook dat het een kwestie is van perspectief.

Het is niet omdat je een volume aan werk verzet, dat daardoor alle deuren openen. Het werk was misschien niet effectief. Misschien was je bezig met het verkeerde werk. Misschien landt je boodschap niet. Misschien heb je (nog) niet de juiste kwaliteiten.

Het effectieve werk in de politiek is politiek bedrijven: de juiste politieke beslissingen nemen vanuit de inhoud. Werken aan de inhoud is je inlezen, je informeren, een idee kunnen formuleren en naar buiten brengen. Hetgene dat dat werk tegelijk helpt en in de weg zit: je collega’s en concullega’s. Afhankelijk van je positie heb je verantwoordelijkheid voor de officiële formulering en uitvoering. Maar je kan even goed politiek bedrijven zonder officieel mandaat. Als ik een opiniestuk schrijf, is dat ook politiek. Als ik een e-mail stuur naar een parlementslid is dat ook politiek.

Er is een soort werk is naast de politiek waar sommigen zich graag aan vastklampen, zich dan jaren inzetten, en denken dat ze daardoor uiteindelijk beloond zullen worden. De blog post in kwestie is een goed voorbeeld. Ik denk dat je dan de foute verwachtingen hebt.

Dit zij-werk heeft weinig te maken met politiek bedrijven. Het lijkt alsof je dan denkt denken dat door maar hard genoeg lokaal te werken het zal helpen om een bepaalde positie te verkrijgen, om vanuit daar dan opeens aan het effectieve werk te beginnen. Misschien kan je het omgekeerd bekijken, en beginnen met het effectieve werk.

An API on top of an API

Tailwind’s coding style creates its own problems, which you then have to solve

Sidenote: I’m not against utility classes

Adding complexity to complexity

Complexity overload and no proper way to manage it

I fear for a Tailwind future