Meme Monday!
Today's cover image comes from last week's thread.
DEV is an inclusive space! Humor in poor taste will be downvoted by mods.
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (65)
reddit.com/r/opengl/comments/gvhqe...
It stands for "Grenade Launcher" because you're going to want one
so accurate
Hahahahah! 🤣
Let's get it going
For some reason as a programmer, a peaceful job on a farm or smth like this sounds too enticing. Of course I'd probably ruin it for myself by trying to think about a way to automate my Potato collection and store my harvest data in the cloud and the optimal data structure to cross-reference potato data in a few milliseconds. :)
I took up photography, it's creative, I get outdoors and I get to control how much or how little I use tech. I shoot film on landscapes, almost none. I shoot digital on architecture and I use loads, to the point I was writing Golang utils to get image meta data extracted
And it's awesome too!
longwalkwoodworking.com/catalog
Does this qualify as a meme? I thought it was funny 😃
Yes
Works for me 🤣
Working in a regulated industry:
It's one character of code, what could it take, three months of change requests?
I've been picking on Tailwind a lot lately on comiCSS 😳
At this point it feels like the Church of Tailwind gaslights people. It breaks many clean code basics like avoid mental mapping, yet we are told that this approach is cleaner and more efficient than writing normal CSS. It's for people who don't get that locally styling everything from zero is the polar-opposite of the design of CSS. Probably it's the same batch of people who tries to go full-OOP or full-FP in JS not understanding that, sadly, the design of the language will always break important details of either approaches.
Sometimes I feel like Tailwind advocates live in a weird fantasy world. So much stuff they say just doesn't seem to conform to reality, like when they say you need to know CSS to use tailwind correctly, or that it makes code cleaner, etc.
I think the main allure is maintainability and code confidence. If you're code isn't dependent on custom "named" classes then you never have to worry about breaking something somewhere else when making a style change. How many times have you changed a class style only to realize it breaks some implementation somewhere else in your app that you now need yet another custom class for though? To your point, no it doesn't make style declaration cleaner, it makes it so you don't have CSS files 1000's of lines long with 100's of unique classes defined that have maybe 1 or 2 property differences.
I'm not a Tailwind advocate but there are legitimate use cases where the philosophy behind Tailwind makes sense. For instance when an app gets too large to maintain any reasonable sense of where classes are applied and you're able to confidently say, "making this style change will only effect this scenario". Or, you have multiple people working on separate teams changing code on the same app. Is Tailwind pointless on a marketing website? Probably. Does it make your mark-up more complex and harder to read? Yes. When you're dealing with an application with 100's of features and UI components and multiple teams though... you'll trade the time it takes to read Tailwind for not having to account for class duplication or test, and fix, your changes to an existing class breaking a different implementation in the app.
Saying that something is more maintainable and at the same time more complex and difficult to read (later in the comment) is contradictory. Complexity and difficulty to read make the code more difficult to maintain. What is it?
Almost none. To be honest, I can't remember having that problem at all. Following a methodology similar to BEM (not necessarily BEM) will avoid that problem completely. If your class is something like module-component-element, you will not get name conflicts and it will be easy to know what each class represents (both in HTML and CSS).
The CSS code generated by tailwind is literally CSS files with 1000s of lines of code with unique classes with just one property. You may not see how the sausage gets made, but it gets made anyway.
Don't take me wrong. Tailwind has good things: CSS code pruning which is great, the apply directive (discouraged by the authors), cross browser support (it adds vendor prefixes)... But I wouldn't list maintainability or small code as pros. I would consider them neutral or put the in the cons column.
And I would say that is a sign you need to learn how to use CSS, not change your tool. For one, knowing when to attach a style to a generic element type or class name as opposed to using a utility class is essential, and many people just never bother figuring this out.
That's why I think it's silly when some people pretend that tools like tailwind don't let you get around learning CSS, because you have to know CSS to use TW effectively. I hear this often as a defence when people don't want to admit that they just don't want to learn actual CSS. It shows that they don't even know what they don't know, because the only way anyone could reach a conclusion like that is by believing CSS is nothing more than knowing some property names and maybe understanding how flex works.
This is both insulting to anyone who actually takes the time to learn CSS properly, and paints a very questionable picture of those TW advocate, making it hard to take their word for anything CSS-related.
I've never liked BEM much, and tend to opt for more of an axiomatic approach to CSS, and I can confirm that I also don't usually deal with these problems. More precisely, it usually isn't a problem, because when I change a rule like "h1 { color: red; }" to "h1 { color: blue; }" it's because I want it to affect headings everywhere.
I call that consistency, and file it as a good thing in the general case.
When I'm dealing with more specific scenarios, I will usually just write more specific rules to reflect that, and tell the browser where or when I want the heading to be blue. Sometimes this even helps me catch myself when I'm using the wrong sort of element or my HTML structure is just weird, which happens relatively often when you're focusing how your page looks.
And in very special cases, adding a
styleattribute is always an option, if I know a change is specific to one exact situation.That is to understand CSS and match elements to a style guideline: things that must move together should move together, while exceptions should be local (unless there is another general rule).
It is a very good explanation and I encourage you to write an article on it. We need more of this to be out there and we need to convince people that reasonable CSS can be short, terse and clean.
I should clarify, it makes the production code more complex and harder to read, not the source code. Yes it spits out files with 1000's of css but I don't care about minified production code's readability or complexity. I care about the source code I maintain and manage. Like I said, I'm not some tailwind advocate but it has gained traction for a reason.
what's meaning?
Array.sort sorts as string, so 100 will be before 20. You need a compare function to fix that.
LOL, I forget about that.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.