Ik krijg een mail dat overal in mijn district de analoge watermeters vervangen zullen worden door digitale watermeters. Ik lees in de infobrochure volgende:
De verbruiksgegevens worden op een beveiligde manier doorgestuurd naar onze servers. Concreet gebeurt dit 1 keer per dag. Indien gewenst, kan u bezwaar aantekenen tegen het verwerken van uw persoonsgegevens.
Er komt dus een apparaatje in mijn huis dat elke dag gegevens stuurt naar een server waar iemand uit kan afleiden dat ik thuis ben. Hmz ?.
Weet iemand hoe dat dan werkt, zo’n digitale watermeter? Moet die gekoppeld zijn aan je WiFi? Heeft die zijn eigen internetverbinding?
Er is een reëele samenlevingskost gekoppeld aan roken.
Roken is ongezond. Roken leidt tot longkanker. De productie van sigaretten veroorzaakt een onnodige ecologische druk.
Er wordt iets geproduceerd dat per definitie wegwerpbaar is. En dat velen ook wegwerpen, op straat, wat leidt tot vervuiling.
Roken kan nooit aangemoedigd worden.
Maar mensen die willen roken zijn vrij om dat te doen in een omgeving waar ze anderen daar niet mee storen. Als iemand in zijn woning een pakje per dag wil roken moet die persoon dat kunnen. Ik zou het niet aanraden, maar dat is iets anders.
De landen die we graag als voorbeeld nemen van hoe het moet zoals Nederland en Canada hebben een hogere verbruiksbelasting op een pakje sigaretten dan België.
In Australië kost een pakje sigaretten 18,4 euro. In Noorwegen 11,8 euro. In de UK 11,7 euro (bron)
Ik ben voorstander van het verhogen van de accijnzen op sigaretten, zodat de gemiddelde prijs van een pakje naar 8 euro stijgt.
Dit zal er voor zorgen dat roken minder toegankelijk is voor jongeren. Dit zal ook zorgen voor meer inkomsten voor de staat. Dit kan helpen om het gat in de begroting dicht te rijden.
Door de prijs op te trekken naar het niveau van de buurlanden Frankrijk en Nederland vermijden we ook dat mensen over de grens gaan om te kopen. Voor een halve euro per pakje heeft dat weinig zin.
Vele rokers willen bewust stoppen en gaan van pakje naar pakje. Het aankopen van een “sloef” is een grotere stap die je verslaving herbevestigt. Dit doe je niet zomaar. Neem het aan van een ex-roker.
Eén van mijn favoriete films is Tot Altijd, een Vlaamse gebaseerd op het verhaal van Mario Verstraete, een MS-patiënt die vecht voor zijn recht op een waardige dood.
Onlangs keek ik voor een tweede keer naar de film Still Alice, over een docente aan de universiteit die op jonge leeftijd dementie krijgt (met een schitterende Julianne Moore).
Ik ben normaal niet zo’n bleiter bij films, maar bij bovenstaande titels kan ik u garanderen dat de tranen over mijn wangen rollen bij bepaalde scènes.
Waarom raakt mij dat zo? Het gaat over zoveel dingen tegelijkertijd. Het recht op zelfbeschikking. Het onnodig lijden. De onnodige bezetting van het leven van anderen, tegen je eigen wil. Het verlies van intellectuele capaciteit. Onrecht en je eigen beslissingen niet meer kunnen maken. Of zelfs niet mogen maken van hogerop.
Ik heb persoonlijke ervaring met dementie. Mijn oma leed aan dementie. We gingen met de familie op bezoek in het rusthuis. Mijn oma takelde telkens verder af. Na een tijd herkende ze ons niet meer.
Ik heb het één keer aangedurfd om alleen op bezoek te gaan. Ik was daar helemaal niet goed van. Ik was een vreemde voor haar. Ik, die als kleine jongen zoveel was komen spelen. Ik kon geen afscheid meer nemen. Net op de leeftijd dat ik een serieus gesprek kon voeren met mijn oma, was dat niet meer mogelijk.
Het verliezen van de capaciteit om voor jezelf te denken moet één van de ergste dingen zijn die er zijn. In de film Still Alice is de hoofdpersoon een internationaal erkend professor die haar hele leven bezig geweest is met het vraagstuk over hoe mensen taal leren. Na een tijd kan ze niet meer onthouden wat ze het vorige dagdeel gedaan heeft.
Als iemand die ook sterk “met zijn hoofd werkt” komt zo’n film hard aan. Voor sommigen is de jongdementie die in de film getoond wordt harde realiteit. Ik hoorde vorige week nog een verhaal over iemand die zijn vader verloor door jongdementie. Er wordt niet zo vaak over gesproken, maar het is de realiteit.
Iemand die dement is, is nog altijd mens. Je naasten zullen voor je willen zorgen, als je het geluk hebt nog dichte familie te hebben. Maar jij wilt dat misschien zelf niet.
Het is aan de persoon zelf om te beslissen wat er moet gebeuren in zo’n situatie. Net zoals je kan beslissen of je gereanimeerd wilt worden na een bepaalde leeftijd, of wat er met je organen mag gebeuren, is voor mij het ook belangrijk dat je als persoon zelf kan beslissen dat, moest het noodlot toeslaan, dat je zacht kan gaan.
Ik vind het daarom zeer goed dat er een debat is in de Kamer over het recht op euthanasie bij dementie. Ik vond het ook zeer goed dat er een zeer genuanceerd gesprek over was vandaag in de Zevende Dag.
Dat er voorzichtig en zeker niet lichtzinnig met dit thema moet omgegaan worden is duidelijk. Maar ik vind het belangrijk genoeg om hier de nodige aandacht aan te besteden, zodat de juiste wetgeving kan volgen.
Wij hebben met ons bedrijf een schaduwboekhouding. Dit is niet de echte boekhouding, die zit in een specifiek boekhoud programma. Het is een reeks Google Sheets documenten waar onze inkomende en uitgaande facturen in staan. We gebruiken dit om een overzicht te houden.
Wat ik af en toe doe is de data er uit halen en analyseren. Dit doe ik liefst in een aparte omgeving waar ik wat vlotter een aantal zaken kan aaneen koppelen (bv. Apple Numbers.)
Nu wil ik deze tussenstap graag optimaliseren en op basis van de data die er in staat grafieken en data genereren. Van het genre data tabel met top clients, grafiek met top clients per year, revenue per client year over year, enz. En dit rechtstreeks in Google Sheets.
Wie kent er iemand die dit voor ons zou kunnen oplossen? Ik zoek een expert die ook zelf een beetje kan meedenken over wat er nuttig kunnen zijn voor een betere workflow.
Ik zag iemand op Twitter die zei: nu ik op Windows zit, mis ik Preview.app. Want dat opent allerlei formaten zonder last.
Dat is zo, en het doet nog meer. Je kan PDF’s los van elkaar trekken. Je kan PDF pagina’s combineren. Je kan je handtekening digitaal zetten. Je kan PDF’s annoteren.
Je kan een slideshow maken van een hoop JPGs. Je kan een PDF presenteren als slideshow. Er zit heel wat “verborgen” functionaliteit in Preview.app. Van die handige dingen waarvan je niet beseft dat ze geweldig zijn tot je ze moet missen.
(Blog post gecategoriseerd onder: redenen waarom ik niet zo snel naar Windows zou switchen.)
Kenneth Tits heeft het over een cookie banner die je laat wachten als je de cookies niet accepteert, en dit bij Proximus. Peter Fransen geeft als repliek een voorbeeld van VRT NWS waar ik mij ook al aan laten vangen heb.
Dit zijn nu net twee overheidsbedrijven die voor mij het goede voorbeeld moeten geven. Maar wat zij doen is een dark pattern toepassen. Een truukje om je de keuze te laten maken die hen het beste uitkomt.
Ik vind dat een trieste zaak. Deze sites moeten juist het goede voorbeeld geven.
Er stond een tijd een goede demo van de OCR-capaciteiten van Microsoft’s Cognitive Vision API op deze URL.
Ik had die URL goed opgeslagen want ik ben die tool eigenlijk regelmatig beginnen gebruiken om echte data in mijn ontwerpen te krijgen. Het was voor mij de eerste OCR die echt goed werkte.
Ik gebruikte het vaak om van een screenshot naar echte bewerkbare lagen in Figma te gaan. Maar vandaag zag ik dat Microsoft hun site heeft herontworpen, en nu is de demo een andere demo: namelijk het deel van de Cognitive Vision API dat gezichten en andere dingen herkent op foto’s. Heel tof allemaal, maar niet wat ik nodig heb.
Wat doen we dan? Het tooltje opnieuw bouwen. Aldaar.
Nu zou ik daar graag rechtstreeks een bestand op kunnen droppen in plaats van iets te moeten uploaden. Maar dat is iets voor als ik nog eens te veel tijd heb.
Ik hoorde op de radio dat Hilde Crevits claimde dat “bedrijven nog steeds geld blijven krijgen voor opleiding”. Dit in de context van een besparing van 23 miljoen op de KMO portefeuille.
Dit is een fundamentele onwaarheid die ik even recht wil zetten. Bedrijven krijgen helemaal geen geld voor opleidingen. Ze krijgen enkel een korting op een door de overheid erkende opleiding, terwijl het hele bedrag van de opleiding terug vloeit naar het bedrijf zelf.
Het statement van Mevr. Crevits klinkt bijna alsof wij als bedrijf een bedrag van de overheid krijgen om opleidingen mee te betalen. Waar het over gaat is dat je 40% korting kan krijgen krijgen opleidingen die onder de KMO portefeuille vallen.
Dit zijn opleidingen die wij toch niet kopen, dus voor ons bedrijf is dit compleet irrelevant. De betere conferenties rond mijn vakgebied zijn tot nu toe jammer genoeg altijd in het buitenland geweest.
Hoe werkt die KMO Portefeuille? Als onderneming kan je erkend worden als dienstverlener. Dit is een proces waar je moet bewijzen dat je aan een aantal voorwaarden voldoet. Dit is een ingewikkeld proces, ingewikkeld genoeg dat er eens reeks consultants is opgesprongen om dit aan te bieden voor ca. 3000 euro (om dan erkend te worden voor een periode…).
Als je dit doet, dan kan je 40% terug krijgen op een opleiding als deelnemer. Wat bedrijven dan kunnen doen is de opleiding gewoon duurder maken en het verschil in eigen zak steken. De maatregel schiet zijn doel dan compleet voorbij. Zelfs als ze dat niet doen, en de 40% korting gewoon geven op de normale prijs, wordt er een oneerlijk speelveld gecreëerd tussen diegenen die wel willen investeren in de KMO portefeuille en alle bijkomende administratie die daarbij komt.
Een gelijkaardige situatie bestaat bij VLAIO projectsubsidies (vroeger IWT). Er zijn diegenen die mee willen stappen in het verhaal van een (universitaire) partner vinden, met meerdere bedrijven samen werken – en het ergste – hun ideeën periodiek moeten valideren voor een commissie die er toch niets van snapt – om een stukje van de overheidspot te verkrijgen. Voor vele startups is dit gewoon een overbodig blok aan hun been. Het is bijna het tegenovergestelde van een startup zijn.
Je gaat bij de overheid bedelen om een beetje geld om te kunnen ondernemen. Waar ben je dan eigenlijk mee bezig als startend bedrijf? In plaats van een lange subsidieaanvraag in te vullen (al dan niet met wederom de hulp van een dure consultant) zou je beter bezig zijn met je eerste klanten te vinden en een goed product te bouwen.
Dat geld is dan ook meteen de enige reden om mee te doen. Ik heb nog nooit iemand gehoord die mee doet omdat hij of zij het een goede formule vind. Als iemand de formule aan mij wil verdedigen hoor ik dat graag. Mijn mailbox staat open.
Omdat wij software ontwerpen en vele innovatieprojecten zich in de software bevinden, komen wij de bedrijven soms tegen als mogelijke klanten. Ik ben er ook zeker van dat ik al in minstens 2 of 3 projecten heb gewerkt waar het geld uit een overheidspot komt. Ik heb een tijd terug met lede ogen gekeken naar een lijst van IWT subsidies (ik denk uit 2015) waar een hele reeks bedrijven geld kregen voor een “innovatief” project voor iets wat ze toch sowieso gingen doen.
De twee die ik onthouden had was een Barco die 3.3 mio subsidies kregen. Alsof Barco nog subsidies nodig heeft… de 2e beste vond ik een hosting bedrijf dat 220.000 euro kreeg om een nieuw control panel te ontwikkelen. Hallo? Heb je dat niet sowieso nodig als hosting bedrijf?
Je zou kunnen argumenteren dat dat een goede subsidiepot ons als agency/consultancybedrijf in software goed uitkomt. Mijn betoog gaat erover om de subsidiepot sterk in vraag te stellen. Dit is dus letterlijk tegen onze winkel.
Waarom? Waar dit betoog mij over gaat is een eerlijk speelveld creëeren waar je als ondernemer de kans hebt om iets uit te voeren. Zonder dat op je knieën moet gaan voor een IT-reus. Zonder dat je naar Brussel gestuurd wordt om een reeks ambtenaars uit te leggen dat je innovatief project een kans op slagen heeft.
Om terug te komen op waar het geld dan voor gebruikt wordt. Ik zie dan vaak dat het geld gebruikt wordt voor een kost die het bedrijf sowieso ging maken. Maar de ergste situatie is diegene waar het bedrijf het geld eigenlijk niet nodig heeft en er dan maar iets pseudo-innovatiefs mee doet.
De regelingen rond bedrijfssubsidies zorgen voor een oneerlijk speelveld. Wat ik wil als ondernemer is een lagere vennootschapsbelasting, zodat ik het geld dat ik verdien kan herinvesteren.
Als er van elke 100 euro winst 34 euro wordt afgeroomd duurt het lang eer ik een spaarpotje heb om te investeren. Geld dat in een bedrijf kan blijven heeft een hefboomeffect dat ervoor zorgt dat je ermee kan ondernemen. Het interesseert me nog niet zozeer hoeveel het dan kost om dat geld dan uit te keren naar privé. Ik wil geld om te investeren in de groei van een bedrijf en de goede dingen die ik hier mee kan bewerkstelligen.
De overheid zou in mijn ogen beter de vennootschapsbelasting in het algemeen verlagen in plaats van cadeau’s uit te delen aan diegenen die door de administratieve winkel willen gaan (KMO Portfeuille) of zich willen binden in een verhaal dat totaal naast de kwestie is (VLAIO projectsubsidie).
Er is nu 23 miljoen van het budget van de KMO portefeuille. In mijn ogen mag deze maatregel volledig afgeschaft worden. Met wat ik er momenteel over weet zie ik er niets positiefs in. De afschaffing van deze maatregeling zal zorgen voor een kleinere overheid, en een eerlijker speelveld wat betreft privé-opleidingen.
Door een combinatie van overheidsbeslissingen creëert de overheid een landschap van proberen verkrijgen van projectsubsidies, in plaats van een landschap van ondernemers die het heft in eigen handen nemen om te doen waar ze goed in zijn: ondernemen.
Geef ondernemers de vrijheid om te ondernemen en belast ze niet met allerhande goedbedoelde maatregelen die hun doel compleet missen. Creëer een eerlijk speelveld voor alle ondernemingen. Zit niet overal tussen, zodat je het overheidsbeslag kan verlagen. En wie weet komen we dan ooit eens aan een verlaging van de belastingen. Zou dat niet iets zijn?
I looked deeper into Tailwind this weekend. I was aware of this framework and its popularity, but I wanted to dive deeper into it as I was researching it for a future project.
If you have to choose your CSS strategy in 2019, there are different options:
Use a framework that “comes with everything”: frameworks like Bootstrap / Foundation / Fomantic UI / …
Work with a utility first framework like Tailwind (…there’s probably others?)
Custom: build it yourself
A combination of the above
… (and probably something else I forgot now)
And then, in regards to coding strategies, there are different techniques:
Just keep on adding CSS (would not really consider this a strategy…!)
Use something like styled-components or emotion to have CSS-in-JS – which puts you on an entirely different path. And which is definitely something you want to avoid, but that is a topic in itself.
For development speed purposes, a framework is a good thing, especially if it has an underlying layer of Javascript components that are well maintained (I am thinking about the more complex things like datepickers, popovers, etc.)
First up is a disclaimer, I am by no means experienced with Tailwind – I am merely looking into whether it’s a good idea to invest time in it in the first place.
Feel free to counter my arguments in the comments and let’s make it a conversation.
What is Tailwind? What’s the coding strategy?
Tailwind is not as opinionated as most frameworks. It is a set of customizable classes, almost like a set of pre-defined design tokens that you can then use to customize your UI.
This is interesting, especially if you create lots of different things with different looks. You can then change the tokens based on the project you are working on but use similar code to lay out responsive designs.
The general code strategy is to use lots of utility classes to build up a component, for example (from the Tailwind homepage):
This code strategy leads to new problems, especially when used at scale. Most notably the problem with Tailwind is that your template code is littered with CSS classes. Below is an actual example from the docs for a simple card component.
In my opinion this template code already looks complex, and there is not even any logic going on. So a real-life template could become a bit of a monster. And a real-life template is just one of hundreds in a web app codebase.
In the Tailwind documentation there is a page called “extracting components” which talks about strategies to counter this problem. This is good as it shows the framework authors are aware of the disadvantages of their methodology.
The first method the author argues for is to simply extract the code into a component, for example if you are using Vue, you would create a new Vue component and then put the markup in that component. In the “overview” page you can then run v-for loop so the markup for something like 6 items becomes 1 item. The author claims the code is clean enough that way, and the right abstraction is made.
This might be the logical for some situations, but I am not sure about this for the reasons stated above – real world templates are just simply more complex than the stated examples. At least they are in the apps I am working on. However, your mileage may vary; I heard on Twitter that some people were very happy with Tailwind, but then they pointed to their small-ish websites as proof.
The second method for reducing complexity is using something called @apply. This is a Tailwind-specific thing where you use @apply to combine Tailwind utilities into its own CSS class.
For example:
.btn {
@apply font-bold py-2 px-4 rounded;
}
This would then make .btn available as a CSS class, with the consistent design tokens. The processing for this is done with PostCSS.
I think this is interesting but then I worry about how this actually simplifies my code.
Here is some button code from a recent project. This is BEM/ITCSS based. Warning, it is quite long. First up is just the layout code, this is not even about the different variants of the button. I made the code boxes scrollable so you can scan this blog post.
If we were to rewrite this last CSS partial to Tailwind, we might end up with something like this:
/* ==========================================================================
Component: Button Skins
---
Rules of this file: you CAN'T touch the box model here, just colors.
========================================================================== */
/* General
========================================================================== */
.c-button {
transition: 0.18s background ease-in;
}
/* Primary
========================================================================== */
.c-button.c-button--primary {
@apply no-border bg-indigo-600 color-white;
svg * {
fill: #FFF;
}
&:hover,
&:active,
&.c-button--active,
&:active:focus,
&.c-button--active:focus {
@apply bg-indigo-700;
}
}
/* Secondary
========================================================================== */
.c-button.c-button--secondary {
@apply border-indigo-600 bg-none color-indigo-600;
svg * {
@apply fill-indigo-600 // Q: How would I reference this variable in a way that works with the framework? Would I now have to make a set of fill utility classes?
}
&:hover,
&:active,
&.c-button--active,
&:active:focus,
&.c-button--active:focus {
@apply color-indigo-200;
}
}
}
I can’t help but wonder where this kind of code change actually helps us. With the @apply rules you the order of the CSS specificity is much harder to see. You get into niche issues – like, is there a utility class for SVG fill? Does @apply even parse in nested SCSS? (I guess not, and you would have to convert all code to PostCSS logic?)
I really don’t see how @apply would really help to improve the code to make it more legible or understandable. The only thing I can think of is that your design tokens stay consistent, but that’s what we have SCSS variables or native CSS variables for.
Default payload + controlling file size
The payload of Tailwind.css is +-475kb (huge!), which then they advice you can cut down by using PurgeCSS, a project to automatically cut down on the CSS used by scanning templates with a regex (More info can be found on the docs page about controlling file size.)
My first reaction was that I sort of object to this way of working. Automatic removal of CSS can lead to bugs and untestable code.
My feeling is that a real life codebase is just not as simple as scanning a few .html templates for whether a class occurs or not. Template code can come from a variety of places, it can get inserted dynamically through JS, you might build up class names dynamically… in my mind there is no way that a simple template scan can lead to good code.
Just to understand which perspective I am talking from I will talk a bit about my projects. The framework I am working with currently powers over 50 projects. The last project I did was a monolothic web app with over 50 modules (not 50 templates, 50 different modules of functionality, so we are talking hundreds of templates).
What if I fix a bug that only occurs inside an @print media query like I did just a few days ago? How sure am I that its code will remain in the CSS after running PurgeCSS? What if there is a bug in PurgeCSS? I find this a bit dangerous.
But! There is a big but. Eliminating dead code is super interesting. If you would be able to automatically remove the right code, then that is super great. If you would get hints about which code can be safely removed, that is also very cool.
I would need to know more about the PurgeCSS project and look more into it and how well maintained it is to make a final decision. From looking at the docs site it actually looks like quite a mature project, so the jury is still out.
What speaks for Tailwind: better customizability
All frameworks are made from a need, and a framework like Tailwind can definitely be helpful in a lot of cases.
I think it is immensely helpful to make sure people default to good design choices. Especially if you are not that design-savvy this is great. The flipside is that you end up with something that looks very default.
Tying in to the typical client wish for our agency projects to have a platform that looks branded, and incorporates just enough of the brand – a framework that (a) looks very – default – and (b) that is actually quite hard to customize will work against us.
The fact that you can customize Tailwind by first putting in the right design tokens makes a lot of sense. You can customize frameworks like Bootstrap, but “not really”, in a sense that the skinning mechanism only goes so far. By tokenizing your design logic (i.e. padding is multiples of 8, colors are x, y and z) you can basically -really- customize a design instead of putting a slight visual change on a framework.
Bootstrap vs. Tailwind when it comes to the resulting look
Using Bootstrap we have a problem: the project will look too much like Bootstrap. Bootstrap comes with a specific default look, which you might to avoid specifically if you have custom brand needs.
If you deliver custom designs (e.g. fully custom designs made in a design app like Figma) and then compare that to the standard look of Bootstrap, decide on Bootstrap as the base framework, you now have to marry the two. No matter how much work you put into it, the standard look of Bootstrap will always shine through. It seems like with Tailwind, you can entirely avoid that problem by using your own set of design tokens.
PostCSS and its stability
There’s other smaller reasons why I worry that Tailwind as a technology is not the best choice. It depends on PostCSS which is not as mature as SCSS. In fact, when I tried to install a PostCSS plugin for VSCode the first one I found was from an author who said she will no longer maintain it as she moved back to Sass/SCSS ?.
My Friday night experiment night led me to a lot of unfinished Github projects, niche issues with PostCSS, PurgeCSS combined with Vue etc.
I feel like these are not the kind of choices you want to make when you are developing a new project and you want the codebase to have some kind of longevity.
Stable ground
For any web app codebase you will want to use stable ground, frameworks that have proven themselves, and then customize that.
Bootstrap is a great example of a framework that I have extensive experience with and that has proven itself over and over again for a good CRUD app. I am coming back to what I stated in the beginning of this post, a framework is powerful especially if it has an underlying layer of Javascript components that are well maintained.
In our position as an agency delivering different solutions for different clients we will never have the time to dive so deep into every detail as the Bootstrap team did over the years.
It is naive to think that if your project is 2 months long that you can do better than an open source project that has been worked on for 5+ years with thousands of contributors.
My preferred methods – a bit about BEM/ITCSS
I have very good experiences with BEM/ITCSS, so that’s where I am coming from, and that’s what I am comparing Tailwind based CSS against.
A good BEM/ITCSS codebase is probably anyone’s best bet for the most custom look and to build upon for the future. But it does require certain skills to make it.
BEM is a set of manual code conventions, and requires some specific knowledge to be able to follow. Not just any dev in the team can typically do a good job in a BEM environment. In my experience, in any dev team there’s only a small percentage of developers who are really into that front-end part and who really get how to write proper BEM-based CSS.
Many developers simply don’t understand how to do it properly. That’s the reality out there. And we can’t be naive to that fact. It is because BEM is too hard to understand? Is it because too many people write production CSS when they really shouldn’t given their skillset? I don’t know, but I see a lot of bad BEM-based code, and that makes me think.
I still believe it is one of the best methods to deliver a good code base. The reasons why are varied and I would have to explain the whole ITCSS metholody to make sense of it. This blog post is already way too long, so I am just going to focus on one aspect.
If you have to start your project today, and you start with BEM/ITCSS, you can easily simplify the logic if you have scoped components in the future, because the right abstractions are already made (1 CSS file per component ).
E.g. with BEM style CSS you could start with SCSS partials in your main SCSS file e.g. main.scss:
These are the styles for a single component (where .c- is a custom namespace for components)
As the web will move on to newer tech, this can become simpler.
For example, if you have a compiler like in Svelte that automatically scopes the styles to a component (a trend that I can see become really popular next 1-2 years), the code from the original BEM/ITCSS component can simply become:
.component-child { }
.component-child--state { }
So, without the namespacing, but still with the double dash (--) naming convention for --state – because it still makes sense to see the difference.
So my point is that you can easily refactor a BEM/ITCSS based codebase to a styles-per-component style codebase in the future.
In some cases, depending on the framework, you could even do away with giving everything a CSS class. Here’s a link to a Svelte component where all the styles are very simple, just because they are scoped to its own component. This is not unique to this REPL, it’s the case for every Svelte component.
With the kind of CSS scoping provided by the compiler you can even directly style <button> in a component itself which is awesome for custom components. No more inventing of the umpteenth variation of a button and giving it a specific name.
(Do note this example is just a code example, a real finished component would be prettier.)
I believe this kind of CSS scoping is the future, but while Svelte is only now getting popular, and we need to ship code today, sticking to BEM/ITCSS for a while is a logical thing.
Especially because it is not tied to any given JS framework, and because of its set of conventions you can easily refactor it to a simpler version if called for; you could do a global search on all .c- substrings within all _(.*).scss partials and you would be literally done in minutes to simplify the code.
Now, what does all of the above have to do with Tailwind? Well, if you litter hundreds of templates with hundreds of utility classes, you are pretty much ****** if you ever decide to refactor the codebase.
That would be one of my main worries with Tailwind, and that’s why I would probably only use it for smaller projects.
The problem then is that for smaller projects, I don’t want the burden of a framework – I will just write things custom, even in plain CSS, not even using SCSS, and be much faster.
The point of a framework is re-use. But then again, Tailwind is maybe not a traditional framework, but it does come with the “stack burden” of a framework (e.g. a specific way of compiling and cleaning your CSS).
I am aware that I have other “resources” than a single developer (I am a designer – we have a whole design team that can come up with good designs) so I can definitely see the usage for a developer who is not that design-savvy.
Conclusions
Like most technology choices, Tailwind has things going for it and comes with its own set of disadvantages. I am not entirely convinced but the framework is interesting enough that it triggered me to write this super long blog post, so that’s something.
There are definitely good ideas in there and I will have to use the framework in practice to come up with a more conclusive opinion.
Ik heb een tijd geleden online een gast leren kennen die bij Netlify werkt, die een hele interessante filosofie heeft: #learninpublic. Het komt er op neer dat hij op zijn blog vanalles post, screencasts maakt met uitleg, en door het gesprek errond veel bijleert, maar tegelijk anderen inhoud geeft waar zij uit kunnen bijleren.
Ik vind dat een intrigerende manier om om te gaan met de complexiteit van web development. Als je er van uit gaat dat niemand het grote gelijk heeft, dat iedereen ook maar aan het leren is, en dan deelt waar je mee bezig bent, dan kan iemand anders daar van leren.
Voor mij heeft november een beetje een React-thema. Daar wil ik wat meer over bijleren. De resources rond Svelte zijn beperkt en ik wil weten hoe je productief in een React codebase kan werken.
De insteek is een betere deliverable. Je kan met HTML/CSS templates maar zo ver gaan… en dan moeten die nog vertaald worden naar een front-end framework. Ik heb me lange tijd afzijdig gehouden van daar in te werken (met de logica “dat is voor de programmeurs” of “wij doen enkel het presentational deel”), maar ik voel nu de nood om er toch in te investeren om uiteindelijk een betere UI te kunnen afleveren.
Zeker omdat wij zien dat ons prototypes soms té lang blijven leven als 2e codebase, met alle maintenance vandien, wat volgens mij niet gezond is. Het voordeel daaraan is dan weer dat die tot nu toe niet de framework-du-jour volgen (yay for permanence), maar aan de andere kant valt sommige CSS-logica — BEM/ITCSS om maar iets te noemen — ook compleet weg afhankelijk van je framework en zijn capaciteiten (e.g. dead code removal, automated CSS scoping).
Binnenkort komt Bram een workshop geven om ons React-niveau wat op te krikken. Daarnaast ben ik vorige zaterdag begonnen aan deze React: Creating and Hosting a Full-Stack Site. Ik heb de talk over React Hooks bekeken. Als iemand nog aanraders heeft, is dat zeker welkom. #learninpublic
