|
You can style them with CSS which can be nice depending on what you need. If you’re using something like webpack you can bundle them in with your code and save some get requests (at work all of our icons are SVG and we wrap them in react components), but you gotta have a lot of them for that to be notable. Edit: yeah you can base64 raster images, but that’s much more of a file size hit than SVGs
|
#
?
May 13, 2021 01:46
|
|
|
|
| # ? Jun 10, 2024 21:53 |
|
|
Empress Brosephine posted:Gotcha. Is there any reason to use them over say a png if i'm not going to be doing any styling or resizing? Potentially smaller filesizes (remember to optimize your SVGs!) and infinite resolution!
|
|
#
?
May 13, 2021 02:06
|
|
|
dupersaurus posted:Edit: yeah you can base64 raster images Doesn't that make them bigger, though? And depending on your setup, you might actually be shipping images the client won't even see because it's all in one bundle. (ymmv)
|
|
#
?
May 13, 2021 02:07
|
|
|
Flash was vector based and look where that got us! Edit, so this isn’t a 100% poo poo post. What are people using to make SVG’s these days? I’m so out of the loop on this stuff.
|
|
#
?
May 13, 2021 02:41
|
|
|
frogbs posted:Edit, so this isn’t a 100% poo poo post. What are people using to make SVG’s these days? I’m so out of the loop on this stuff. I message my designer on slack and ask him to send me the icon as an SVG, works great
|
|
#
?
May 13, 2021 02:54
|
|
|
frogbs posted:Edit, so this isn’t a 100% poo poo post. What are people using to make SVG’s these days? I’m so out of the loop on this stuff. I use D3 to generate SVG data visualizations. Otherwise I've used Illustrator and Affinity Designer to create SVG images.
|
|
#
?
May 13, 2021 02:59
|
|
|
Thanks everyone for the help. It's just a silly wordpress site so no webpack or anything cool.
|
|
#
?
May 13, 2021 03:34
|
|
|
frogbs posted:Flash was vector based and look where that got us! Definitely recommend Affinity Designer. Can be had on your PC, Mac or iPad too. One time purchase instead of a subscription and I think it’s on sale pretty often.
|
|
#
?
May 13, 2021 03:36
|
|
|
frogbs posted:Flash was vector based and look where that got us! I like using SVG. You can style it with CSS and attach event listeners to SVG elements. The game boards in these I made using SVG: http://www.mseymour.ca/hex_puzzle http://www.mseymour.ca/hex_book Edit: Oh yeah, and this: http://www.mseymour.ca/football/game_select.html I guess I use SVG a lot HappyHippo fucked around with this message at 18:05 on May 15, 2021 |
|
#
?
May 13, 2021 04:32
|
|
|
fsif posted:On a medium size project, I'd estimate I have a few dozen containers. I don't know how you could get away with fewer unless you have a really simple design. They don't generally share a ton of the same properties consistently with one another, so I would say there are only a handful of shared classes among them. I can't speak for needing "a few dozen" containers, but my current project is decidedly CSS-light compared to others I have worked on due to the simple fact that we don't support mobile in any fashion, and only have 2 breakpoints: below 1200w and everything else. That being said - my only real point is: most of the people I have seen dismiss Tailwind haven't actually tried it - at least not really. They take one look at it, notice a passing resemblance to inline styling and just go "nope!" It took me fiddling with it for about half a workday before I understood what it was offering me, and that turned out to be something much better than my previous sass/scoped per component workflow I had. quote:But just anecdotally (and I'll stress it's purely anecdotal), between speaking with colleagues and following dev hot takes on Twitter, I've sort of recognized a pattern in Tailwind backers versus detractors: the former have generally loathed CSS, have stronger CS backgrounds, and weaker design backgrounds. Reverse is true for the detractors. I can see this. While I don't have a formal CS background - I was definitely a (self-taught) programmer first, and while I wouldn't say I "loathed" CSS, it's never really been my favorite thing; and to style something from scratch, I used to just load it up, add element styles in the browser until I got what I wanted, then copy paste that into my css, adjusting as needed. Oddly enough Tailwind has sort of forced me to think a little more about how I am styling things. But workflow-wise - it's just....faster? I have worked with it long enough now that as I'm writing markup I will go ahead and slap on some base styles I'm pretty sure will be useful. Overall - I have seen a significant drop in the amount of time I spend styling. I tend to value efficiency over most things - so less time doing a thing is a good thing, to me.
|
|
#
?
May 13, 2021 12:13
|
|
|
I quite like CSS and I'm very pro Tailwind. Even though you have to work around it a bit sometimes (hi, psuedoelements). You definitely need to learn regular CSS to understand it and its workarounds. It's not a replacement, they're tools you use together. I really like the way it gives you a very clean reset on ugly browser defaults. Changing the p/m classes quickly to adjust margins and padding between editor and browser is a lot more pleasant than typing out all the syntax in CSS, switching between files and potentially rebuilding your CSS every time (whereas Tailwind you can just work with an unpurged file during development). Literally just typing flex every time in the main doc instead of display: flex in a separate file ends up saving a surprising amount of time on an big site build, I promise you. It's opinionated in pretty sensible ways such as sizing units. It's got syntactically better names than some CSS properties. (I'll admit I seem to be the only one, but using Tailwind has made me better with Flex/Grid in regular CSS, just by reframing how I build them out.) I also think there's a lot of designers who unfortunately don't have an understanding of classes in web design (or a general sense of consistency) so if you're building from a design where literally every component on the entire site is going to be unique just styling them quickly in the HTML is a lot quicker than writing BEM class names all day long.
|
|
#
?
May 16, 2021 08:33
|
|
|
I got super curious and did a deep dive into the world of Tailwind, and I think I have come to understand what the appeal is. It allows for rapid development unfettered by the age old hurdle of having to name poo poo, needing to understand how the hell the complicated parts of CSS actually work, or worrying that if you change something here you break something there. Also there are enough low level design choices already made to provide crucial guardrails to keep the design on track and consistent. Being able to develop while not having to deal with those things is highly alluring and seems like it would be quite freeing. I'm currently working on a greenfield project without a complete design system/global stylesheet in place yet, and for first pass on new components, I will unabashedly make them up with a gloriously reckless pile of inline styles. It's fun and easy and quicker than stopping and thinking about naming all the elements and how they fit in with existing designs and adding them to the component stylesheet before the component has even gelled. There are for sure plenty of fitting use cases for something like Tailwind. That said, the more I've dug into Tailwind, the more repulsive I find it, for a number of reasons. Committing to it feels like an absurdly high price for what basically amounts to better, more convenient inline styles. I don't think it's anywhere worth it when you get to deal with terminally hideous bloated markup that's hard to read, configuration prone to issues, a potential maintenance nightmare down the road, learning curve that involves a bunch of sometimes inconsistent abbreviations for CSS attributes, completely eschewing the power of the cascade, and being pretty hosed if you ever decide that you want to switch away from Tailwind on a large project. Other than the ease, development speed, and easier design consistency, the arguments I saw in favor of Tailwind seemed hollow, not fully informed, or were about something that I didn't regard as a problem in need of solving. "Everything is in one file so you don't have to context switch when working on styling and a developer reading it doesn't have to open a different file to understand the component!" - Sometimes not having all your poo poo mashed together in a single file makes it more readable, it turns out (ask me about all the single-file web forms/apps I wrote in procedural PHP oh god). When I'm working on an aspect of a component that doesn't involve directly dealing with the styling (all of them except for the dealing with the styling one), I don't want those long-rear end ugly strings of presentational classes getting in my way. And then when I am working on the styling, having the markup and the styling files open at the same time and moving between them is not "context switching" because even though styles and markup are different files and different concerns (more on this later), they are very much in the same context and go together like peas and carrots (at least for me). And if some developer needs to learn the codebase, why do they need to know anything more about something like a button than that there's a button and it does a button thing if they aren't in a design role? Unless a developer's role explicitly includes nitpick-level design/styling, they shouldn't need to touch the stylesheet at all, and if they don't need to deal with the stylesheet/presentation, then why pollute the poo poo they do need to look at with presentational baggage? If they need to dig through CSS to figure out how to mark up a new component, that's a documentation/design/organizational problem, not a CSS problem. "Separation of concerns is a myth, so let's not even try." - This one confuses and bothers me. Of course the concerns of what the button is and does and what the button looks like are separate. We have some admin form interfaces that one of backend devs is working on right now. I'm otherwise occupied so he doesn't have any design support, which means he's putting the forms up in raw HTML that I can mark up and style later. He's concerned with getting the forms into the templates and making them operational. poo poo like making the buttons rounded and adding a nice little inset shadow to the input is 100% irrelevant to his task and does not affect the functionality of the form. And then when I go in to style them, the operability of the forms will not be my concern and does not affect how the forms function. The place where the delineation of concerns blurs and codependency happens is nuances of layout and positioning. Sometimes it's not feasible to have perfect separation. In fact, the utility classes that I've created and use are all related to positioning/alignment. But then Tailwind proselytizers argue that because the separation isn't perfect it might as well not exist so just throw everything into the same file. "Naming things is hard." - No loving poo poo. This is a never ending challenge in programming in general, and CSS is no exception. "You don't have to deal with the cascade!" - Yes, let's jettison the C in CSS because we don't understand it and/or it's hard. I think this comes from CSS being one of those things that is super easy to pick up but deceptively difficult to master. If you get dicked over by the cascade enough (it happens to everybody) and it keeps slowing you down, I can understand wanting to just not ever deal with it. But I think it's worth learning (instead of bypassing) because it's really powerful and useful. "Just use @apply!" - Find that you're repeating certain sequences of classes over and over again for recurring elements? Use https://twitter.com/adamwathan/status/1226511611592085504 So you're not actually supposed to use @apply, but instead continue to copypaste your bloated HTML markup. It's just there as a dirty trick to make you think Tailwind is more viable for your use case than it might actually be. The other option is to spin off recurring elements into their own components, but this gets dumb when you start spinning off poo poo like button container divs solely to avoid repeating presentational markup, which kind of defeats the alleged benefit of having all your poo poo in one file so you don't have to switch between them and now you have a mountain of piddly little presentation components that you need to remember to import whenever you need divs or other elements with certain layout/presentational properties. I dunno, but I can't help but think defining a .button-container class in a stylesheet and applying it to the div your buttons are inside of is less of a pain in the rear end. Or am I the one with the brain worms here? I don't even know anymore. Also, I learned that @apply was an abandoned CSS spec proposal, which was abandoned because it was kind of a shitshow: https://xanthir.com/b4o00. "Best practices don't actually work" - this type of presumptuous rhetoric pisses me off in general and Adam's best practices quote on the Tailwind website was bothering me in particular for some reason I couldn't quite put my finger on: quote:"Best Practices" don't actually work. But then it struck me and I figured out why it was bothering me: quote:Diets don't actually work. I can't unsee it. As for best practices, they're actually a lot like diets in the sense that they only work when you're actively practicing them. Going on a diet for a month and then complaining that it doesn't work after that month is an awful lot like establishing your best practices and then complaining that they don't work after you've stopped bothering to practice and enforce them. A diet that's successful long term can be better described as a lifestyle shift and a continuous effort. Best practices can be successful if you keep practicing them. Is it easy? Of course not. Will you cheat and backslide and get lazy about it? Absolutely. But as long as you don't completely give up or think that you're done as soon as you've declared what the best practices are, then they can keep working for you. It's never perfect, but with a good process in place and choosing best over easiest as often as you can, it's something. Also I don't appreciate framework-peddling tech "thought leaders" telling me what does and doesn't work for me. That's for me and my team to determine. So, in conclusion, I didn't like Tailwind before and now I really don't like Tailwind. I don't dislike Tailwind for offering a compelling solution for rapid development or even an alternate way of implementing styles (to each his/her own), I dislike it because of the fans (a few of which tend towards cultishness), the dogma, the particulars of its implementation, the rhetoric they use to sell it, and the idea put forth by the fans that it's a "game changer" and "the future" instead of just a framework that worked really well for their respective use cases. I sure as gently caress hope not. I don't want to have to add Tailwind deprogramming to frontend dev onboarding. Still though, what the popularity of Tailwind tells me is that there is a void in the rapid prototyping space that Bootstrap and co aren't properly filling. Like, at my company we were using Bootstrap super early in development of our new project but had to remove it once I started building the design system because it wants to control everything and conflicts with/undermines any custom styling. I just want something to help out the backend devs but also not interfere with my design work. What I'd like to see (and would consider writing internally if our team got big enough) is a utility stylesheet for the earliest stages of development. This stylesheet would be limited in scope (like a couple hundred classes, not a mapping of the loving entirety of CSS) and very restrictive in terms of options because its job would be to achieve a bare bones presentable state ahead of design work, not a full fledged production-ready design, and it would have a higher level of abstraction than a framework like Tailwind. In my opinion, a failing of Tailwind is the super low abstraction - it doesn't save you from learning CSS because the intricacies of CSS are not abstracted away, just abbreviated and sometimes not self-descriptive (e.g. someone new to Tailwind would have to look up what "p-6" means (I checked - it's "padding: 1.5rem")), so you have to learn how CSS works and also this system that is CSS but written as a CSS stylesheet for writing fancy inline styles with different names for things, but I suppose the trade-off is way more design freedom. I would want to go for a level of abstraction that would call the utility class what its style is while being immediately understandable to someone with zero design and minimal frontend familiarity (sounds like a semantic challenge!). Like for anything typographic or font-related, you could prefix the class with "text-" and use obvious descriptors like "big", "italic", "center", "red", "monospace", etc. Tailwind has a mix of "font-" and "text-" prefixes for attributes that all start with "font-" in CSS, so you've got to remember for which attributes you use text instead of font. In a utility system for non-designers, it'd probably be simpler to just think of all the text as "text" instead of making it match the font-based naming of the CSS attribute counterpart. Positioning is tougher, but I'd want to try to abstract away from the flexbox nomenclature and simplify the implementation (so you don't need to go learn flexbox in order to use the flex classes). Maybe "box" or something, with basic alignments both vertically and horizontally and wordage like "evenly-spaced" for the child elements. And then at the end of the day when you have your real design system in place, you can easily remove and replace it with the actual markup and styles. And holy loving crap this is long now. Please allow me to shut the gently caress up about styling philosophy.
|
|
#
?
May 17, 2021 20:27
|
|
|
Queen Victorian posted:I got super curious and did a deep dive into the world of Tailwind, and I think I have come to understand what the appeal is.  Your "barebones framework" idea is something that I feel would definitely help a lot, but it's hard to do when every application has vastly different requirements, even at the earliest stages.
|
|
#
?
May 17, 2021 20:41
|
|
|
Queen Victorian posted:What I'd like to see (and would consider writing internally if our team got big enough) is a utility stylesheet for the earliest stages of development. This stylesheet would be limited in scope (like a couple hundred classes, not a mapping of the loving entirety of CSS) and very restrictive in terms of options because its job would be to achieve a bare bones presentable state ahead of design work, not a full fledged production-ready design, and it would have a higher level of abstraction than a framework like Tailwind. In my opinion, a failing of Tailwind is the super low abstraction - it doesn't save you from learning CSS because the intricacies of CSS are not abstracted away, just abbreviated and sometimes not self-descriptive (e.g. someone new to Tailwind would have to look up what "p-6" means (I checked - it's "padding: 1.5rem")), so you have to learn how CSS works and also this system that is CSS but written as a CSS stylesheet for writing fancy inline styles with different names for things, but I suppose the trade-off is way more design freedom. I would want to go for a level of abstraction that would call the utility class what its style is while being immediately understandable to someone with zero design and minimal frontend familiarity (sounds like a semantic challenge!). Like for anything typographic or font-related, you could prefix the class with "text-" and use obvious descriptors like "big", "italic", "center", "red", "monospace", etc. Tailwind has a mix of "font-" and "text-" prefixes for attributes that all start with "font-" in CSS, so you've got to remember for which attributes you use text instead of font. In a utility system for non-designers, it'd probably be simpler to just think of all the text as "text" instead of making it match the font-based naming of the CSS attribute counterpart. Positioning is tougher, but I'd want to try to abstract away from the flexbox nomenclature and simplify the implementation (so you don't need to go learn flexbox in order to use the flex classes). Maybe "box" or something, with basic alignments both vertically and horizontally and wordage like "evenly-spaced" for the child elements. And then at the end of the day when you have your real design system in place, you can easily remove and replace it with the actual markup and styles. I think "not having to learn css" is a really ambitious goal for a css framework. Every css framework I've ever seen has ended up being much more complicated than vanilla css, and you'd have to learn both vanilla css and the framework to get work done. Left to my own devices, I'd pick something simple like Milligram for basic styling and do everything else vanilla, and not try to gently caress with css processors/preprocessors (which are generally huge overkill / introduce problems worse than the problems they intend to solve.)
|
|
#
?
May 17, 2021 21:14
|
|
|
marumaru posted:
Yeah that's the thing - third party frameworks go about covering all possible use cases and get super huge and unwieldy in doing so. If I wrote a stylesheet for this purpose, it would be heavily tuned for our use cases, which are data-heavy analytics interfaces for enterprise and internal/administrative data processing interfaces. If someone wanted to use it for an e-commerce site, it'd probably be total poo poo and not helpful. If you can find a highly specialized library/framework that suits your very particular needs, it's always better than a generalist master-of-none solution. For example, my UI component library BlueprintJS, which is optimized for data-focused desktop applications. It's pretty much perfect for us. However, it'd be an extremely poor solution for a mobile-first consumer app, for example. I'm very glad I found something that does one thing extremely well. PS: Blueprint's styling is contained behind a prefix so it targets only its own components by default (also it uses basic CSS and doesn't force you into some bullshit CSS-in-JS paradigm like Material UI does). It doesn't interfere with our custom styles and the component styles can be easily modified, but they are very agreeable and neutral so they don't need all that much modification. It's basically my dream component library. Also saves me a ton of time because buttons and inputs and poo poo are always the things that take me the longest to style, but now they're already styled in a way I like. Bruegels Fuckbooks posted:I think "not having to learn css" is a really ambitious goal for a css framework. Every css framework I've ever seen has ended up being much more complicated than vanilla css, and you'd have to learn both vanilla css and the framework to get work done. I wouldn't even call this pipe dream of mine a framework. I don't see why it would need to be any more complicated than just adding a stylesheet and reading some documentation. I actually really don't like the concept of a "CSS framework" in general - CSS is built into the browser and works fine. I agree that frameworks tend to overcomplicate the poo poo out of styling a website/app. Frontend in general is overcomplicated as gently caress these days. I set out to make the frontend part of the stack of our new project as simple as possible and got rid of a whoooole bunch of stupid needlessly complex poo poo I hated from the old version like Redux and ImmutableJS. The last thing I want is to complicate writing CSS (I do use SASS, but other than the self-contained styles for the UI components and Eric Meyer's reset stylesheet, it's all handwritten custom styles). I was aiming more at "minimal frontend knowledge/experience and/or doesn't like dealing with frontend poo poo" and would assume rudimentary understanding of how HTML works and the very basics of how stylesheets work and how styles are applied to the markup. Stuff like styling text, basic positioning (not necessarily flexbox), padding vs margin, assigning dimensions, colors, etc. Basically all the CSS you learn in the first couple hours of dicking around in CSS. What I'd want to get away from is requiring understanding of advanced concepts like cascade/inheritance, flexbox, responsiveness, and having to be familiar with assloads of different attributes. With the higher level of abstraction, classes would be more involved than a one-to-one mapping. Like for container/wrapper-type elements I'd just build in stuff like padding and margin and handle positioning of child elements and establish implicit relationships between elements that hopefully accomplish what the user is getting at without requiring them to nitpick each attribute and spend time making decisions about superfluous stuff like padding and font size because it's already decided for you. Also, the included documentation would be extensive and explicit with implementation and output examples. All in all, my objective isn't to provide CSS styling powers to those without CSS knowledge - this thing wouldn't provide any means to create a design - it'd be mostly "undesigned" monochrome utilitarian with enough classes to achieve a basic layout/workflow and and enough polish to make it make it look a bit better than the likes of Craigslist. Like with the BlueprintJS library I mentioned above, which excels at being an amazing UI component library for a very specific subset of use cases, I'd want to focus on solving a narrow and very specific subset of problems, which is wanting to provide some temp styling early in a project that everyone on the dev team can use and have that temp styling not get in the way of implementing the real styling. Bootstrap was originally for prototyping consistent-looking internal GUIs at Twitter and then got popular and started doing more and more and became the massive general purpose framework beast it is today. Because it is expected to do so much beyond its original use case, it's not really a good stylesheet choice for prototyping/using as a base anymore. It's just too heavy-handed and wants to do all the design for you so when I've found myself using Bootstrap all I do is fight with it. I don't want to end up there.
|
|
#
?
May 17, 2021 23:08
|
|
|
I honestly think that if you really don't want to learn CSS (shame on you) you should probably just stick to Bootstrap. If your job isn't "writing backends and displaying the data (doesn't matter how; probably just a table or whatever)", learn CSS. Note that "is Tailwind good or not" is not related to this.
|
|
#
?
May 17, 2021 23:48
|
|
|
I disagree wholeheartedly that Bootstrap is hard to work with. Granted I think it’s paramount that you setup your stylesheet build such that you can customize its variables to your needs but that’s been easy to do since version 4.
|
|
#
?
May 18, 2021 01:36
|
|
|
Queen Victorian posted:I got super curious and did a deep dive into the world of Tailwind, and I think I have come to understand what the appeal is. It allows for rapid development unfettered by the age old hurdle of having to name poo poo, needing to understand how the hell the complicated parts of CSS actually work, or worrying that if you change something here you break something there. Also there are enough low level design choices already made to provide crucial guardrails to keep the design on track and consistent. Being able to develop while not having to deal with those things is highly alluring and seems like it would be quite freeing. I'm currently working on a greenfield project without a complete design system/global stylesheet in place yet, and for first pass on new components, I will unabashedly make them up with a gloriously reckless pile of inline styles. It's fun and easy and quicker than stopping and thinking about naming all the elements and how they fit in with existing designs and adding them to the component stylesheet before the component has even gelled. There are for sure plenty of fitting use cases for something like Tailwind. Sir this is a wendys
|
|
#
?
May 18, 2021 02:58
|
|
|
My last significant Bootstrap experience was with Bootstrap 2.3 so that's probably coloring my opinion. It was implemented really poorly before I was hired and I couldn't get rid of the stylesheet because there were components that relied on it and I didn't want to recreate half of Bootstrap to accommodate them. So I fought with it and wrote overrides constantly. Other that that particular experience, frameworks like Bootstrap or Foundation are fine for lots of teams and use cases. They cover your bases and are inoffensive. Bootstrap has a "look" but it's not particularly strong and easy to modify. The only real gripe I have with Bootstrap and similar frameworks is that they are such a good crutch that "knowing CSS" comes to mean knowing how to implement Bootstrap. Unormal posted:Sir this is a wendys Actually I'm pretty sure it's the thread where we talk/complain about all this dumb loving frontend technology we have to deal with these days but yes I'll take a small chocolate Frosty.
|
|
#
?
May 18, 2021 03:50
|
|
|
Queen Victorian posted:I got super curious and did a deep dive into the world of Tailwind, and I think I have come to understand what the appeal is. It allows for rapid development unfettered by the age old hurdle of having to name poo poo, needing to understand how the hell the complicated parts of CSS actually work, or worrying that if you change something here you break something there. Also there are enough low level design choices already made to provide crucial guardrails to keep the design on track and consistent. Being able to develop while not having to deal with those things is highly alluring and seems like it would be quite freeing. I'm currently working on a greenfield project without a complete design system/global stylesheet in place yet, and for first pass on new components, I will unabashedly make them up with a gloriously reckless pile of inline styles. It's fun and easy and quicker than stopping and thinking about naming all the elements and how they fit in with existing designs and adding them to the component stylesheet before the component has even gelled. There are for sure plenty of fitting use cases for something like Tailwind. 
|
|
#
?
May 18, 2021 04:23
|
|
|
If you don't like Tailwind that's fine but you can stop heavily implying that those of us who do don't understand CSS. You can't even really use Tailwind if you don't know CSS already. I've been writing CSS for like 15 years. quote:So you're not actually supposed to use @apply, but instead continue to copypaste your bloated HTML markup. No, he's saying rather than extracting CSS classes with @apply you should extract entire view components/partials, because except for the simplest cases your reusable pieces are probably made up of multiple HTML elements.
|
|
#
?
May 18, 2021 05:02
|
|
|
I got the sense one of the groups it appealed to was people who might not like CSS. I quickly learned that actually you really do need to know CSS to use it effectively, so I don't agree with the common detractor argument that it's a cop out for people who don't know CSS. I didn't think I implied that I did and if it came across that way I didn't intend it to. I read way too many awful Medium pieces and all the arguments I addressed (except for the best practices one) came from articles by community members, and one guy did list "eliminates reliance on the cascade" as a pro, and regarding CSS as an annoying obstacle that Tailwind solved was a common theme in these pieces. Adam Wathan's arguments (I'd read several of his articles previously) are a lot better and my thoughts there are more like "he makes a compelling point about X but his solution is just not my cup of tea". I rather liked him (while disagreeing with him) until I saw the "best practices don't actually work" quote. Much more fun to write thousands of words squawking about the dumb bad arguments by randos though. As for extracting reusable components instead of using @apply, yeah, this would be the correct/preferred course of action, but personally I wouldn't want to be extracting components that are nothing more than divs or other elements styled a certain way, which I presume is what you do if you want to be DRY with an all-in utility paradigm. I'd rather just use a semantic class in the markup and not deal with keeping track of a bunch of purely presentational micro components. Maybe I'm the one doing it wrong by not breaking down components enough/structuring markup in a certain way, but having a component in place of every recurring semantic class doesn't sound very appealing to me. And by necessitating lots of component extraction in order to avoid repetition, it's effectively imposing itself on how you structure your code and how you design your markup. I don't like the idea of a CSS framework holding so much influence over my project. I guess this doesn't apply if you and the framework are already on the same page about how to accomplish things (like me and my pigeonholed component library). But still, the @apply directive definitely seems to get used as an "out" by a lot of users grappling with the repetition. Also as a major selling point to people on the fence - in some cases it was presented as a means to go extract a bunch of semantic classes and loop right back around to what Tailwind was trying to get away from. Some users revealed in comments in the reddit and various other places that they use @apply quite a lot to create semantic classes. This doesn't seem to be in the spirit of what Tailwind is about.
|
|
#
?
May 18, 2021 06:55
|
|
|
For me if a component is built with one HTML element and doesn't need any behaviour I'll use @apply, and if it needs more than one HTML element or needs behaviour I'll use a React component. I think the point with @apply is if you're just using it to recreate BEM you're using it wrong, because you're still creating CSS that's going to be tightly coupled to markup that someone's going to have to remember how to use.
|
|
#
?
May 18, 2021 13:45
|
|
|
So in the example of global markup where you have classes for the structural markup of forms like .form-header, .form-section, .form-footer, etc. that don't serve any behavioral function and only exist to provide layout structure to a form, those are handled by @apply directives? That's like half a dozen @apply classes just for forms. Does that fall within "you should hardly ever use it"? Not sure if that means you shouldn't use it more than a couple times and only as an absolute last resort or like a few dozen times to handle recurring simple markup structure across the application. I get that recreating BEM/full comprehensive stylesheets with it is very much Missing The Point. But a lot of Tailwind users writing articles or answering questions suggest it, which seemed contradictory - they're using this totally different paradigm while singing its praises yet bend it back around to the old familiar paradigm but in a roundabout, less performant way. Now that I've come down from my vaccine reaction manic haze of overly verbose hot takes, I see the importance of going all in if you're going to adopt it and I realize that creators can't prevent people from using their thing in dumb ways and spreading their wrong advice (and giving ammo to skeptics). In regards to BEM, the other big reason I'm iffy on it aside from the ugly notation is the propensity to push you in the direction of making brittle hierarchies of styles and tight coupling. I've been there (except way worse because it was haphazard, mostly arbitrary naming and not a consistent methodology like BEM) and it got out of hand really fast. I strive to set up my design system so that the global styles are 100% agnostic and mostly flat, then reserve BEM-like naming for component styles that need scoping. Component stylesheets are usually very short because I mostly just need to give some rules to the containing/structural elements and once in a blue moon tweak the style of a child component (if I'm modifying a child component every time I implement it, that's a design failing on my part). I think over years of trial and error (lots of error), I'm finally honing in on a sane, mostly maintainable solution that'll work for my product and team. CSS is a special beast and I understand why everyone keeps trying to tame it with frameworks. It's hard and often takes a good long while to arrive at a system that doesn't suck.
|
|
#
?
May 18, 2021 22:51
|
|
|
Queen Victorian posted:It's hard and often takes a good long while to arrive at a system that doesn't suck. Once you move past really caring about the technology and wanting to just ship stuff, a framework like tailwind often makes a lot of sense because it doesn't get in your way and a lot of people who have a domain expertise other than css (maybe the thing they're making a product about instead) can ship something in less time that's good enough, and that's good enough to be a good tool.
|
|
#
?
May 18, 2021 23:50
|
|
|
im really past the technology and while the goal is to ship stuff, i also consider how much pain it'll be to maintain it in the future 
|
|
#
?
May 19, 2021 00:30
|
|
|
marumaru posted:im really past the technology and while the goal is to ship stuff, i also consider how much pain it'll be to maintain it in the future That’s why it’s important to keep changing jobs so you are never forced to maintain your bad decisions.
|
|
#
?
May 19, 2021 00:35
|
|
|
Lumpy posted:That’s why it’s important to keep changing jobs so you are never forced to maintain your bad decisions. I legit worked with a guy who would literally always move teams once he shipped a project, always going to a team that was writing something brand new. Truly the 500IQ move.
|
|
#
?
May 19, 2021 00:39
|
|
|
Unormal posted:Once you move past really caring about the technology and wanting to just ship stuff, a framework like tailwind often makes a lot of sense because it doesn't get in your way and a lot of people who have a domain expertise other than css (maybe the thing they're making a product about instead) can ship something in less time that's good enough, and that's good enough to be a good tool. Oh absolutely. At my old job, where we shipped updates pretty frequently and doing it fast was often valued over doing it right, heavier reliance on a framework (up-to-date properly implemented Bootstrap would have suited us quite well) would have extremely helpful. I was building on an extremely bad and brittle foundation and didn't realize how awful it was. My inexperience at the time didn't help (I was pure HTML/CSS design at the time). In retrospect we should have burned it down and started over when we still had the chance (probably with a correctly installed current version of Bootstrap). Makes the choices by my awful former coworker make more sense. He came from an agency that was notorious for burning through developers and rapidly shipping sites/apps that looked slick and not much else. His markup was sloppy and inconsistent (and sometimes weird and wrong - like he used flex-direction:column-reverse for right alignment which required him to order things backwards in the component markup) and he dropped in poorly named utility classes on the fly to make poo poo just work, didn't make any attempt to learn the existing system and at least while I was still there didn't propose a better system. It put an extremely bad taste in my mouth in regards to utility-first rapid development. But a coherent framework/system that enables the fast development but also enforces consistency? That sounds way better. Hell, I'd probably have a less negative and bitter opinion about it if my first exposure had been a real framework and not slipshod homegrown trash. At my current company I have the luxury of a greenfield project where we are encouraged to take our time to get poo poo right this time because the old version was an unmaintainable nightmare. And I am interested in making it good and maintainable long term because it's an application we build and license to customers and support/maintain. Far cry from an agency or something where you can ship something and be done with it.
|
|
#
?
May 19, 2021 00:46
|
|
|
I'm having a little breakdown with an old typescript project that I'm trying to dust off and start working on again. It's a small express app that worked as an adapter between a static Vue SPA and a couchdb database. It's only a few hundred LoC and maybe half a dozen files. It has a small tsconfig file that looks like this:JSON code:OK, something must be weird on my machine (or so I thought!). Here is the same command run on a GH action: code:
|
|
#
?
May 19, 2021 02:11
|
|
|
Queen Victorian posted:So in the example of global markup where you have classes for the structural markup of forms like .form-header, .form-section, .form-footer, etc. that don't serve any behavioral function and only exist to provide layout structure to a form, those are handled by @apply directives? That's like half a dozen @apply classes just for forms. Does that fall within "you should hardly ever use it"? Not sure if that means you shouldn't use it more than a couple times and only as an absolute last resort or like a few dozen times to handle recurring simple markup structure across the application. I usually use React for that kind of thing, so I'd have <Form.Section /> and <Form.Header /> That lets you do nice stuff like <Form.Section variant="airy" /> (for different styles of sections, ideally defined by a typescript enum so you get autocomplete of valid variants) Or if later on someone says "hey all our form sections need titles now" you can do <Form.Section title="some title" /> instead of having to now add a .form-section-title global class and remember where in the markup it needs to go to look right. And if you make that title prop mandatory your code won't compile until you go back and add titles to all your sections as per the new requirement. You could totally still use this approach with separate CSS, I have in the past and it works fine, but for me once you get to this point it makes a lot of sense to co-locate your styling with your markup because they're practically the same thing.
|
|
#
?
May 19, 2021 20:51
|
|
|
frogbs posted:I don't know React yet! So maybe it's best to just start with the basics. Oh wow, my brain and React do not get along at all! I just ran through this Tic Tac Toe game tutorial, and it just looks like a mess to me. I'm going to keep at it, but I just don't get why some of this has to be this complicated.
|
|
#
?
May 20, 2021 07:20
|
|
|
frogbs posted:Oh wow, my brain and React do not get along at all! I just ran through this Tic Tac Toe game tutorial, and it just looks like a mess to me. I'm going to keep at it, but I just don't get why some of this has to be this complicated. That tutorial uses the "older" React style - no hooks or functional components in there. I promise it is much nicer to use these days
|
|
#
?
May 20, 2021 07:56
|
|
|
frogbs posted:Oh wow, my brain and React do not get along at all! I just ran through this Tic Tac Toe game tutorial, and it just looks like a mess to me. I'm going to keep at it, but I just don't get why some of this has to be this complicated. It's kinda unfortunate they haven't updated the tutorials to use function components and hooks, as IMO that makes things a bit cleaner. Regardless, the beauty of React is you essentially just define the rules for what should be displayed given your data (state), and it handles all the dirty work of adding/removing/updating elements to fit those rules whenever the data changes. When the data changes, you just update the state and React goes back through your rules, figures out what (if anything) needs to change to make the page look how it should given the new data, then automatically makes all those changes. With plain JS you need to manually do all that dirty work (e.g. select all the elements that need to change, manually set the new values/properties for each element, potentially add/remove elements etc). Coming from a more traditional JS background, it can take a bit to wrap your head around this. For instance, It took me a while to get out of the "okay X changed, that means I need to update elements A, B and C" mindset when writing event/change handlers. In React you just set the new state of X, then based on your JSX, React already knows that A, B and C depend on the value of X and will update them accordingly.
|
|
#
?
May 20, 2021 09:12
|
|
|
Splinter posted:It's kinda unfortunate they haven't updated the tutorials to use function components and hooks, as IMO that makes things a bit cleaner. Regardless, the beauty of React is you essentially just define the rules for what should be displayed given your data (state), and it handles all the dirty work of adding/removing/updating elements to fit those rules whenever the data changes. When the data changes, you just update the state and React goes back through your rules, figures out what (if anything) needs to change to make the page look how it should given the new data, then automatically makes all those changes. With plain JS you need to manually do all that dirty work (e.g. select all the elements that need to change, manually set the new values/properties for each element, potentially add/remove elements etc). Thanks, I think that clarifies things a bit. I'm going to try to find more recently updated tutorials that are more focused on what i'm doing (basically searching within a table). I think I just don't like looking at JSX, everything is co-mingled and my brain just stops because it looks like it shouldn't work.
|
|
#
?
May 20, 2021 16:34
|
|
|
frogbs posted:Thanks, I think that clarifies things a bit. I'm going to try to find more recently updated tutorials that are more focused on what i'm doing (basically searching within a table). I think I just don't like looking at JSX, everything is co-mingled and my brain just stops because it looks like it shouldn't work. I hate JSX for the same reason. It looks like an abomination unto the Lord, to me. By extension, I can't stand working in React. Maybe give something else a try? Vue and Angular are still out there.
|
|
#
?
May 20, 2021 16:43
|
|
|
Angular is too big and unwieldy for most purposes. Vue is 
|
|
#
?
May 20, 2021 17:32
|
|
|
use svelte
|
|
#
?
May 20, 2021 17:36
|
|
|
someone has to
|
|
#
?
May 20, 2021 17:36
|
|
|
|
| # ? Jun 10, 2024 21:53 |
|
|
lunar detritus posted:Angular is too big and unwieldy for most purposes. Vue is It's definitely this, but I didn't say it because the last few pages felt kinda tense and I didn't want to seem too opinionated. 
|
|
#
?
May 20, 2021 18:21
|
|