Modern front-end development: skinny jeans and handlebar mustaches ITT

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Modern front-end development: skinny jeans and handlebar mustaches ITT

«‹›235 »

frogbs: May 5, 2004; Well well well

fsif posted:

If you want to learn a modern framework it's as good a project as any. That said, not sure Next.js makes a ton of sense for a simple single page app like that.

Do you know React already? Next is really a React framework; would make more sense IMO to focus on learning just React first. Look up the React docs and make a simple app using create-react-app.

I don't know React yet! So maybe it's best to just start with the basics.

Svelte was another framework I was looking at, but not sure there's any point in learning something that isn't common if i'm essentially starting from scratch.

I think my biggest hurdle is just going to be mentally getting over breaking everything into components even when it seems unnecessary, and using inline styles everywhere. I'm too used to the old HTML + CSS ways!

# ? May 11, 2021 22:48

Adbot: ADBOT LOVES YOU

# ? May 19, 2024 06:54

Harriet Carker: Jun 2, 2009

React might be "overkill" for a project like that, but I also think a simple project like that is a perfect first React project. Hell, build it in vanilla JS, React, and Vue and see what the easy and difficult parts of it for each were.

# ? May 12, 2021 00:31

prom candy: Dec 16, 2005; Only I may dance

You can use regular CSS with React! I think a bunch of us in this thread are horny for TailwindCSS (lord knows I am) but you have a ton of options for CSS with React.

I think React is still kinda the dominant library in the space so it would probably be the best one to learn if you're thinking about job skills, or just being on the same page with the largest number of people.

# ? May 12, 2021 00:41

marumaru: May 20, 2013

I really don't like Tailwind, and I'd actually recommend not using it if you have any interest in learning front-end at all.
My recommendation for those who aren't interested in front-end is to use something established like Bootstrap instead (or, to a lesser extent, Bulma).
If you need to implement a custom design at all, I feel like learning CSS is seriously worth the investment.

Finally, this guy explains most of the things I don't like about Tailwind and similar much better than I can: https://www.aleksandrhovhannisyan.com/blog/why-i-dont-like-tailwind-css/

# ? May 12, 2021 01:10

barkbell: Apr 14, 2006; woof

i used tailwind for a project for a client. i liked a lot of the decisions made about sizing and spacing and such. i dont like the super long list of classes. css in js is good tho.

# ? May 12, 2021 04:05

prom candy: Dec 16, 2005; Only I may dance

marumaru posted:

I really don't like Tailwind, and I'd actually recommend not using it if you have any interest in learning front-end at all.
My recommendation for those who aren't interested in front-end is to use something established like Bootstrap instead (or, to a lesser extent, Bulma).
If you need to implement a custom design at all, I feel like learning CSS is seriously worth the investment.

Finally, this guy explains most of the things I don't like about Tailwind and similar much better than I can: https://www.aleksandrhovhannisyan.com/blog/why-i-dont-like-tailwind-css/

I can definitely understand why people don't like it, but having used a LOT of different approaches to CSS over the years Tailwind is my favourite. It needs to be used with a component library like React though, where things are still split into smaller components with defined boundaries. It would be difficult to use if you're trying to edit a 500 line index.html file.

# ? May 12, 2021 04:21

M31: Jun 12, 2012

I like Alpine for small things like this: https://github.com/alpinejs/alpine

code:

<thisisascriptbuttheseforumsarestupid src="https://cdn.jsdelivr.net/gh/alpinejs/alpine@v2.x.x/dist/alpine.min.js" defer></thisisascriptbuttheseforumsarestupid>
<style>
  [x-cloak] {
   display: none !important;
  }
</style>
<form x-data="{width:10, height: 2}" >
  width: <input type="text" x-model="width">
  height: <input type="text" x-model="height">
  <div x-cloak x-show="width*height >= 10">Bag 1: volume = 10</div>
  <div x-cloak x-show="width*height >= 20">Bag 2: volume = 20</div>
  <div x-cloak x-show="width*height >= 30">Bag 3: volume = 30</div>
  <div x-cloak x-show="width*height >= 40">Bag 4: volume = 40</div>
</form>

I don't suggest it if you want to actually render new stuff dynamically on the client.

# ? May 12, 2021 04:58

Impermanent: Apr 1, 2010

A simple project for your first react project is a good idea. Do familiar projects with new tools and use familiar tools on new projects.

# ? May 12, 2021 05:22

Queen Victorian: Feb 21, 2018

For a getting-up-to-speed project, I think React (sans Redux) is a good approach (though if it were me doing a small project like this I'd probably knock something out in jQuery because I'm a Luddite weirdo and sometimes I miss DOM-touching).

For styling, I would just learn SASS (CSS preprocessor). For me, it solved all the problems I had with vanilla CSS by providing means to implement variables, mixins (style presets/macros, basically), and nested styles for easier readability.

marumaru posted:

I really don't like Tailwind, and I'd actually recommend not using it if you have any interest in learning front-end at all.
My recommendation for those who aren't interested in front-end is to use something established like Bootstrap instead (or, to a lesser extent, Bulma).
If you need to implement a custom design at all, I feel like learning CSS is seriously worth the investment.

Finally, this guy explains most of the things I don't like about Tailwind and similar much better than I can: https://www.aleksandrhovhannisyan.com/blog/why-i-dont-like-tailwind-css/

This, pretty much. I am firmly in the semantic CSS camp and have not had good experiences with utility-first CSS. Luckily it never resulted in implementing some utility framework (but that's moot because I have a new job where I call the shots on this sort of stuff). Tailwind in particular looks like inline styling except you need a decoder ring to understand it. Also the issue that it purports to solve (sticking to a finite set of styles) can be achieved more effectively with variables and mixins in SASS along with a bit of discipline, in my opinion.

I think my stance comes from me originally being a designer and getting my start dealing with HTML and CSS exclusively. I have a much easier time thinking about styling in semantic terms and also a much easier time visualizing components because if I see an element with class 'tooltip' I know exactly what it is, much more so than some div with an absolute position that has a drop shadow and a border radius and is about yay big and uses this font and that line height and has this much padding and that background color and this text color and and... I'd much rather shunt all that poo poo off to the stylesheet and simply assign class tooltip in the markup so I know what the hell it's supposed to be.

Impermanent posted:

A simple project for your first react project is a good idea. Do familiar projects with new tools and use familiar tools on new projects.

This is good advice - small projects are a great setting for trying new things and familiarizing yourself with them.

# ? May 12, 2021 06:39

Ima Computer: Oct 28, 2007; Stop all the downloading!

Help computer.

I can't bring myself to enjoy tailwind, even with nice helper libraries for using it with React. It gives me bad build-your-own-bootstrap vibes. Utility classes have their place, but going all-in on them feels bad. My favorite ways to do styles lately, at least in React projects, has been with theme-scale object-oriented libraries like Styled System/Theme UI. Stitches is looking like a strong up-and-coming contender too.

For most small projects though, the simplest solution is to write plain CSS. Maybe add SCSS/SASS if you want the convenience of nesting or the power of functions/mixins. If you follow some sane class-naming convention, like BEM, and enforce consistency by making extensive use of native CSS variables/custom properties (yes, all the modern browsers support this!), it's really hard to mess up.

# ? May 12, 2021 06:52

Vincent Valentine: Feb 28, 2006; Murdertime

For my CSS I make a vanilla-CSS styles object on a react component and then in-line it all.

Call the cops I don't give a gently caress.

# ? May 12, 2021 07:24

Sistergodiva: Jan 3, 2006; I'm like you,
I have no shame.

If you need SEO regular react is a bad idea. At least it used to be.

Next.js is react with serverside rendering this giving you better SEO.

Gatsby is is also an option. It can generate static pages using react.

# ? May 12, 2021 07:42

Empress Brosephine: Mar 31, 2012; by Jeffrey of YOSPOS

I like bulma but I prefer to write css by hand unless it's some kind of back ended thing then who cares just use bulma.

Id say use Gatsby or next. Gatsby might be easier, and seems to have fallen out of favor recently though.

# ? May 12, 2021 13:00

marumaru: May 20, 2013

Queen Victorian posted:

For a getting-up-to-speed project, I think React (sans Redux) is a good approach (though if it were me doing a small project like this I'd probably knock something out in jQuery because I'm a Luddite weirdo and sometimes I miss DOM-touching).

Nowdays you don't really need jQuery that much anymore, unless your application requires support of a more esoterical browser like IE10/11.
Even Safari tends to behave a little when it comes to JS.
If you miss $, you can just give querySelector a new name. God knows I do

Queen Victorian posted:

For styling, I would just learn SASS (CSS preprocessor). For me, it solved all the problems I had with vanilla CSS by providing means to implement variables, mixins (style presets/macros, basically), and nested styles for easier readability.

I enjoy the developer experience of styled-components, but I've seen a lot of people misuse it (or use it when it's not necessary) and I'm not convinced of its performance impacts really being negligible. I've gone back to SASS.

Queen Victorian posted:

Tailwind in particular looks like inline styling except you need a decoder ring to understand it.

Exactly! I feel like that's just often people not wanting to touch the icky front-end stuff like CSS and instead using a framework that's just CSS with extra steps.

Seriously, this is on their front page. This is one of their selling points. This blows.

And since I'm having my two minutes hate, might as well say: screw Redux. It's not its fault but people just don't know how, and when to use it.
You don't need Redux to make a two-input form. Please stop. :eng99:

# ? May 12, 2021 13:42

marumaru: May 20, 2013

Sistergodiva posted:

If you need SEO regular react is a bad idea. At least it used to be.

Next.js is react with serverside rendering this giving you better SEO.

I'm fairly certain Google, at least, indexes SPAs pretty well nowadays, but naturally gives you lower scores if your site is slow to load (which sadly seems to be the case for many SPAs. Woo 3MB of gzipped JS!)

I do like Next.

Vincent Valentine posted:

For my CSS I make a vanilla-CSS styles object on a react component and then in-line it all.

Call the cops I don't give a gently caress.

A patrol car has been dispatched to your location
I prefer actually having [S]CSS files just because it's a bit cleaner.

Empress Brosephine posted:

I like bulma but I prefer to write css by hand unless it's some kind of back ended thing then who cares just use bulma.

Early in my career I used Bulma for a few things, but ran into the issue CSS frameworks can't escape: if you need a custom design, it's usually just not worth it.
I have nothing against using Bootstrap/Bulma for simple stuff, though.

# ? May 12, 2021 13:47

HaB: Jan 5, 2001; What are the odds?

All the concerns expressed here regarding Tailwind are the exact same ones I had.

Then I tried it.

Now I wonder why I ever wrote CSS any other way.

It's unfortunate that it looks like an awful mess once you see it, but once you start using it you just go :monocle:

The reason you get to that point is when you realize: you haven't written any of your own CSS. There's barely any need to. We have an application at work using Tailwind, and the app.css file is about 20 lines - which are mostly overrides anyway.

That posted article has some valid complaints, but I mean - having to remember Tailwind's numbered classes deal in .25rem increments so that .5rems of padding all around is p-2 isn't any more or less difficult than remembering whatever scheme someone came up with for semantic classes. And for you semantic advocates about to pile on me - I have in fact worked in semantic - it's definitely not any easier to read or get your head around. Just like anything else - it comes down to what you're used to.

code:

pl-4 pb-2 text-green-500 text-bold border border-red-500

is perfectly easy to read after 10 minutes of using Tailwind. I know it's 1rem padding-left, .5rem padding-bottom, with bold green text and a red border. That's more information than:

code:

class="menu_item--left"

because while I see there's only one class applied - I have to go find it to see what style it actually is.

As for the complaint about Tailwind styles getting really long - I can attest that after you have established some base styles (ex. "I know all my buttons will have base set of styles") then you create a class for it, and add which ever other Tailwind classes on the button itself to tweak- it really just doesn't come up that often. I have been working in exclusively Tailwind for about 6 months now, and I have seen styles scroll off past my editor's word-wrap maybe twice. And when they did, they could be tweaked and some of them removed to achieve the same result.

I guess what I'm getting at is: use what you want, but for better or worse, Tailwind requires really giving it a good long try to see the value of it. Dismissing it without at least building the standard TODO list or something in it, isn't giving it a fair shake. Yes - this is the fault of Tailwind.

HaB fucked around with this message at 15:00 on May 12, 2021

# ? May 12, 2021 14:57

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

marumaru posted:

Nowdays you don't really need jQuery that much anymore, unless your application requires support of a more esoterical browser like IE10/11.

jquery does not solve any problems with IE11 or do anything useful for IE11 browser compatibility. jquery was only even semi-useful for browser compatibility back in ie9 and before when the event handler stuff had huge browser issues, and even then jquery event handling sucked.

# ? May 12, 2021 15:02

marumaru: May 20, 2013

I'm not saying it's objectively bad or anything, I just don't like it! :cheeky:

I actually used was forced to use it it for an entire project. I guess I just actually enjoy writing CSS, I find it pretty fun and relaxing.

# ? May 12, 2021 15:10

fsif: Jul 18, 2003

HaB posted:

I have been working in exclusively Tailwind for about 6 months now, and I have seen styles scroll off past my editor's word-wrap maybe twice.

I guess I have a hard time conceptually understanding how this can be done without having a ton bespoke @apply classes (which would kind of defeat Tailwind's purpose). For most container elements, I have three or four properties just for flexbox or grid, then a few for margin and padding and sometimes background color and drop shadow. Add in new properties for different breakpoints, and it seems like you'd hit like 15 utility classes in no time.

Maybe you just get used to the horizontal scanning, but doesn't it make PRs a nightmare? And what about debugging in inspector?

# ? May 12, 2021 15:18

HaB: Jan 5, 2001; What are the odds?

fsif posted:

I guess I have a hard time conceptually understanding how this can be done without having a ton bespoke @apply classes (which would kind of defeat Tailwind's purpose). For most container elements, I have three or four properties just for flexbox or grid, then a few for margin and padding and sometimes background color and drop shadow. Add in new properties for different breakpoints, and it seems like you'd hit like 15 utility classes in no time.

Maybe you just get used to the horizontal scanning, but doesn't it make PRs a nightmare? And what about debugging in inspector?

I guess it depends on your definition of a "ton" of bespoke classes. How many different containers do you really have? How many of them have classes in common? That's pretty much THE use-case for creating your own @apply class. Our button @apply class is 5 classes. Anything that might need to be tweaked is added directly on the element. So if .btn gives me padding/borders/radii, then 3-4 other classes gets me the rest.

Doesn't make PRs any harder than anything else, I'd say. Debugging in inspector is fine, because you can usually pretty quickly isolate it to whichever utility class is causing the issue.

Edit: I would also say that creating @apply classes doesn't defeat the purpose - because the concept of being DRY is still a thing.

# ? May 12, 2021 15:48

prom candy: Dec 16, 2005; Only I may dance

I don't know where this idea that using @apply somehow defeats the purpose. It's utility-first, not utility-only.

Queen Victorian posted:

I think my stance comes from me originally being a designer and getting my start dealing with HTML and CSS exclusively. I have a much easier time thinking about styling in semantic terms and also a much easier time visualizing components because if I see an element with class 'tooltip' I know exactly what it is

I think this is where Tailwind plays really nicely with component libraries. For me, the concept of a Tooltip is a combination of markup, CSS, and probably some javascript behaviour, so all of that would be contained in a <Tooltip /> component, and you'd know you were looking at a tooltip because you'd be editing that file (or editing another file that only contains <Tooltip />). I don't like semantic CSS because for me when I'm building something like a tooltip, the markup and the CSS are pretty much married. Having a separate file with CSS definitions for like Tooltip__Heading and Tooltip__InnerContainer or whatever makes little sense to me. The other thing that makes little sense is having a hundred semantic classnames in your project that are all just some variation of.

code:

.MediaCard__ActionsContainer {
  display: flex;
  align-items: center;
}

Having to think of a name for this thing, open the other file, write it in, and write the classname back in the markup is so much slower and more disjointed than just doing <div className="flex items-center">

marumaru posted:

Exactly! I feel like that's just often people not wanting to touch the icky front-end stuff like CSS and instead using a framework that's just CSS with extra steps.

I don't think this is fair at all. You pretty much need to be proficient with CSS to be proficient with Tailwind. The people who don't want to touch CSS are using UI libraries. I have a ton of experience with vanilla CSS, SASS, BEM, and CSS-in-JS. Oh and table-based design :v:

# ? May 12, 2021 16:51

frogbs: May 5, 2004; Well well well

marumaru posted:

Seriously, this is on their front page. This is one of their selling points. This blows.

I've been intrigued with Tailwind for a while, so I guess i'll try it for my photo bag project. That laundry list of classes in the screenshot is a little suspect though!

I've used Bootstrap a ton in the past, and it looks like Bootstrap 5 just came out. But it sounds like everyone has completely moved on from it?

# ? May 12, 2021 16:53

Ima Computer: Oct 28, 2007; Stop all the downloading!

Help computer.

I'll just leave this indoctrination video for Stitches here (because I'm really jazzed about it, unlike Tailwind)

https://www.youtube.com/watch?v=Gw28VgyKGkw&t=1470s

# ? May 12, 2021 17:06

Macichne Leainig: Jul 26, 2012; by VG

marumaru posted:

Seriously, this is on their front page. This is one of their selling points. This blows.

Sure it looks nasty but I can look at that and very quickly understand what's going on with the layout, padding, text colors, etc.

I'll always champion Tailwind though, it has allowed me to write several web apps that don't look like complete poo poo in a single workday. It's definitely not like, the end-all-be-all CSS framework, but I am not convinced the people who dog on it constantly have explored it enough to see where you can start making things way easier on yourself.

You won't get rid of the class vomit as it's a utility framework and that's just how it works, but if you encapsulate your CSS intelligently - whether via a plain old React component or with @apply - the value really starts becoming apparent IMO.

That said,

fireraiser posted:

I'll just leave this indoctrination video for Stitches here (because I'm really jazzed about it, unlike Tailwind)

https://www.youtube.com/watch?v=Gw28VgyKGkw&t=1470s

This also looks like it owns.

# ? May 12, 2021 17:16

Mecca-Benghazi: Mar 31, 2012

I'm not a real web developer, so I use bootstrap for internal apps that I build. For stuff that I prototype, I use normalize.css (are there better browser resets/normalizes nowadays?) and then write custom scss in Vue components with a toolchain that compiles with webpack and everything :3:

I often end up writing a small utility library in plain CSS in addition to mixins.

# ? May 12, 2021 17:27

prom candy: Dec 16, 2005; Only I may dance

fireraiser posted:

I'll just leave this indoctrination video for Stitches here (because I'm really jazzed about it, unlike Tailwind)

https://www.youtube.com/watch?v=Gw28VgyKGkw&t=1470s

I prefer the Tailwind syntax but if I was still using styled-components or another CSS-in-JS library I would be immediately switching to this, lots of really nice stuff here.

# ? May 12, 2021 19:14

fsif: Jul 18, 2003

So you know, I'm not a hot take artist when it comes to tech. If as many talented developers swear by something like Tailwind and are able to leverage it to be more productive, it obviously has a ton of merit. I've also never seriously attempted to use it in any serious project, so I trust you all when you say some of the things that appear wonky at first blush actually ends up feeling pretty natural.

HOWEVER�

HaB posted:

I guess it depends on your definition of a "ton" of bespoke classes. How many different containers do you really have? How many of them have classes in common?

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.

prom candy posted:

Having to think of a name for this thing, open the other file, write it in, and write the classname back in the markup is so much slower and more disjointed than just doing <div className="flex items-center">

Agreed, but there are other libraries to scope your CSS. They also let you write normal CSS so there's no vendor lock-in. This isn't really a Tailwind-specific advantage.

quote:

I don't think this is fair at all. You pretty much need to be proficient with CSS to be proficient with Tailwind.

Yeah, I think the common misconception that Tailwind lets you avoid learning CSS is clearly bogus.

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 don't know why that is exactly, but I'm a designer turned developer (with no formal CS schooling) and it does feel like Tailwind is purporting to solve problems I don't really have. Could be an incredible amount of arrogance on the design-y devs' parts, but you know, that's kind of how I've seen this debate unfold, heh.

# ? May 12, 2021 19:22

prom candy: Dec 16, 2005; Only I may dance

fsif posted:

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.

Anecdotally I don't fit into this at all. My educational background is in advertising. I love CSS. I'm not a good designer but my favourite part about this job is working with one to build cool user experiences. Tailwind has let me build interfaces way more rapidly, and having used it on some long running projects now (over 2 years) I haven't had any issues with maintainability. It just fits a specific workflow that I've come to enjoy from using React for the past 5+ years where everything is contained in components. When I was using BEM, I had to have the React component open in one window and the CSS file open in the other. When I was using CSS-in-JS I would have to constantly scroll up and down in the same file between the markup and the styles. With Tailwind I finally have markup/style harmony, which means I can just think and write.

# ? May 12, 2021 19:35

fsif: Jul 18, 2003

prom candy posted:

Anecdotally I don't fit into this at all. My educational background is in advertising. I love CSS. I'm not a good designer but my favourite part about this job is working with one to build cool user experiences. Tailwind has let me build interfaces way more rapidly, and having used it on some long running projects now (over 2 years) I haven't had any issues with maintainability. It just fits a specific workflow that I've come to enjoy from using React for the past 5+ years where everything is contained in components. When I was using BEM, I had to have the React component open in one window and the CSS file open in the other. When I was using CSS-in-JS I would have to constantly scroll up and down in the same file between the markup and the styles. With Tailwind I finally have markup/style harmony, which means I can just think and write.

Thanks, that's an interesting perspective. I'd agree that there are times when scrolling up and down in a file with a CSS-in-JS approach can be a pain point. When that does occur, my fix has been to either refactor or have the file twice in two panes side-by-side, but it's still not perfect.

What do you do when your designers deviate from the design system? E.g., they want a margin of precisely 0.35 em, but it falls between two values in your m- classes?

# ? May 12, 2021 19:56

prom candy: Dec 16, 2005; Only I may dance

fsif posted:

What do you do when your designers deviate from the design system? E.g., they want a margin of precisely 0.35 em, but it falls between two values in your m- classes?

Either get back with the designer and convince them stick with the system that they created, add another m- class if I think it's going to be more than a one-off, or just an inline style.

# ? May 12, 2021 20:06

lunar detritus: May 6, 2009

Tailwind solves the "CSS Architecture is hard" problem (and/or "wait, you have to think about CSS???" from backend developers) by completely externalizing it. There's no need to recommend new people in the team to read long FAQs about how BEM works, it's all right there in the HTML. It's not pretty, but it's incredibly practical. Even the messiness is easily solvable since the HTML getting gnarly means it's time to start extracting components (or partials).

I've seen a lot of frontend devs really hating it but they were never the problem. CSS experts working on their own don't really need tailwind (even though it makes developing prototypes a lot faster) but it can make a huge impact in teams with people of different skill levels and interests.

prom candy posted:

I don't know where this idea that using @apply somehow defeats the purpose. It's utility-first, not utility-only.

I'm actually in the "try to avoid using @apply" camp. In my experience, there are very few cases where making a new class using @apply would be better than encapsulating whatever I'm doing into its own component. And the second @apply starts being used in a project it pretty much spreads like a fungus, but I am mostly talking from the experience of having a lot of "full stack" devs copying whatever is already being used in a project.

# ? May 12, 2021 20:06

prom candy: Dec 16, 2005; Only I may dance

lunar detritus posted:

I'm actually in the "try to avoid using @apply" camp. In my experience, there are very few cases where making a new class using @apply would be better than encapsulating whatever I'm doing into its own component. And the second @apply starts being used in a project it pretty much spreads like a fungus, but I am mostly talking from the experience of having a lot of "full stack" devs copying whatever is already being used in a project.

Oh agreed yeah I exclusively use @apply for things that only require one HTML tag to work. If a shared component needs two tags it's not a CSS class, it's a view partial. I just have a handful of things like .btn, .notice, etc.

# ? May 12, 2021 20:18

Queen Victorian: Feb 21, 2018

prom candy posted:

I think this is where Tailwind plays really nicely with component libraries. For me, the concept of a Tooltip is a combination of markup, CSS, and probably some javascript behaviour, so all of that would be contained in a <Tooltip /> component, and you'd know you were looking at a tooltip because you'd be editing that file (or editing another file that only contains <Tooltip />).

As a frontend/designer type, I spend a good chunk of time on the browser in Dev Tools inspecting elements and observing console output and whatnot. So even though the markup doesn't really matter when you're in the code because you can just import <Tooltip /> and call it a day, it matters a lot more in the output, which is where I very often go to test, tweak, and troubleshoot, and it's much easier for me to zero in on <div class="tooltip"> than <div class="[200-character string of utility classes]">. And in the former, if I'm in style tweak mode, I can pull up the .tooltip style from the stylesheet in dev tools and mock style changes on the fly. How would that work in Tailwind? Toggling the utility class properties (which would break styles for any element using that class) or manually adding/editing/deleting classes from the HTML markup? Add element styles (aka inline) and then go find the Tailwind translation?

Maybe my markup/styling process is actually abnormal and backwards on account of me being a BFA designer with mostly self-taught dev skills, but it's how I came to work with this stuff and I've been successful and happy with my methodologies (maybe because I actually do like writing CSS).

quote:

I don't like semantic CSS because for me when I'm building something like a tooltip, the markup and the CSS are pretty much married. Having a separate file with CSS definitions for like Tooltip__Heading and Tooltip__InnerContainer or whatever makes little sense to me. The other thing that makes little sense is having a hundred semantic classnames in your project that are all just some variation of.
code:
.MediaCard__ActionsContainer {
  display: flex;
  align-items: center;
}
Having to think of a name for this thing, open the other file, write it in, and write the classname back in the markup is so much slower and more disjointed than just doing <div className="flex items-center">

This is when I embrace the CSS global namespace. :yayclod:

If I have a bunch of action containers or whatever across multiple components that are basically all the same, I put an .action-container class in the global stylesheet and assign it to all the action container elements. If there is an instance of the action container that needs to be slightly different, I just give it a component-scoped style to modify it:

code:

.media-card {
    //component styles

    .action-container {
        background-color: $different-color;
    }
}

I tend to rely pretty heavily on a global stylesheet to cover frequently occurring basic elements like headings/typographic things, lists, forms, tables (for displaying tabular data, don't worry), tabs, etc. Once it's set up it reduces time and cognitive load of styling new components a lot. I can just drop in a handful of semantic classes instead of styling divs over and over with a buttload of utility classes.

I can't help but feel that a lot of utility-first and CSS-in-JS solutions exist because their creators didn't like or understand global namespace and/or the C in CSS. I can see the idea of CSS and its behaviors and global jurisdiction being weird/unpalatable for someone coming from a pure programming background, but since I came from design, it meshes quite well with me and my holistic approach to style application.

Also, the history of CSS and how it came to be and also what could have been if CSS had not been the winning standard is really interesting.

PS: sorry if this is rambling - I'm fogged up and feeling like crap from vaccine-induced pseudo cold.

# ? May 12, 2021 20:56

prom candy: Dec 16, 2005; Only I may dance

Queen Victorian posted:

As a frontend/designer type, I spend a good chunk of time on the browser in Dev Tools inspecting elements and observing console output and whatnot. So even though the markup doesn't really matter when you're in the code because you can just import <Tooltip /> and call it a day, it matters a lot more in the output, which is where I very often go to test, tweak, and troubleshoot, and it's much easier for me to zero in on <div class="tooltip"> than <div class="[200-character string of utility classes]">. And in the former, if I'm in style tweak mode, I can pull up the .tooltip style from the stylesheet in dev tools and mock style changes on the fly. How would that work in Tailwind? Toggling the utility class properties (which would break styles for any element using that class) or manually adding/editing/deleting classes from the HTML markup? Add element styles (aka inline) and then go find the Tailwind translation?

I use the React DevTools to figure out which component I'm looking at and then generally I'll just edit the element styles if I'm tweaking something. I also really don't like to work without hot reloading so I don't end up needing to use the devtools that often to actually write my CSS, I just edit my source file and the page updates. I can definitely see how Tailwind would be tougher to work with if you have a DevTools-heavy workflow.

Queen Victorian posted:

This is when I embrace the CSS global namespace. If I have a bunch of action containers or whatever across multiple components that are basically all the same, I put an .action-container class in the global stylesheet and assign it to all the action container elements. If there is an instance of the action container that needs to be slightly different, I just give it a component-scoped style to modify it:
code:
.media-card {
    //component styles

    .action-container {
        background-color: $different-color;
    }
}

But not everything that needs display: flex and items-center is an action container, and not every action container needs display: flex and items-center. This is what I'm talking about with naming, at that point really a useful global class name would be something like... flex-items-center! Also that's a lot easier to remember than having to know that when you want stuff laid out in a row it's an .action-container.

In my experience working on teams where people are nesting things has created the hardest to maintain CSS that I've dealt with. We used to do extensive nesting with SASS at my last job and it's what prompted us to adopt BEM.

# ? May 12, 2021 21:53

Queen Victorian: Feb 21, 2018

I don't do deep nesting in the SCSS files - it's usually just one level, and if there's deep nesting poo poo going on it means I've hosed up my markup and/or am paying the piper for dirty lazy code/styles from earlier, but either way it's a sign I need to unfuck stuff.

As for the hypothetical action-container shifting significantly due to different contexts like not always needing to be centered or whatever, I feel like we're maybe thinking along the lines of different design philosophies (or not - my reading comprehension is trash today). I do UI for B2B analytics software, so I'm after functionality and consistency before anything else. If I'm going to make a frequently occurring element to contain or do a specific thing, it's going to look and behave the same regardless of where it's implemented and a deviation (if there even is one) is going to be rare and subtle and would not require complete restyling, just minor modification.

Usually these sorts of widgets are more involved than just needing to center align a thing (for the record I'm not adverse to utility classes and will happily use them as needed for cases where you just need to tweak alignment or something for something that doesn't deserve a whole semantic class). I guess a better example would be my .form-footer class. I've set up form markup to make it easy to throw together a nice-looking form using semantically named building blocks. Form-footer has specific styles like right alignment for submit etc buttons, only bottom corners have border radius, it does not have a top border (or top border radiuses) because it always stacks with other parts of the form, etc. It's also not really a componentizable element that I can make so I can only apply a giant string of utility classes once (I mean I technically could, but the idea of importing a dozen separate component files that each return a basic-rear end div seems pretty gratuitous, even by make-everything-a-component React standards), it's just a div that contains the buttons that appears in every form component.

PS: I can't bring myself to try BEM (officially - my notation is actually already pretty BEM-like) because I can't get over the visual hideousness of the notation (and underscores in class names in general).

PPS: oh yeah, I figure I should add a fat disclaimer/caveat to my styling POV/philosophy: I am the sole keeper of styles and frontend design at my company and was the sole keeper of styles and frontend design at my previous company as well (until the sexist prick new guy started making GBS threads everything up with lazy trash tier markup). The stylesheets I wrote at my previous job were actually quite lovely - brittle, convoluted vanilla CSS abominations that only I could understand and tame, but to be fair I was building on a foundation of garbage and my proposals to clean poo poo up and move to SASS got shelved every version for like five years and I was pressured to get new features out the door more quickly than I had time to implement styling correctly, so the culmination of stylesheet technical debt was significant. At my current job we are in the midsts of a ground-up rewrite, so I can lay a good foundation and set good precedents for future frontend hires.

# ? May 12, 2021 23:53

Empress Brosephine: Mar 31, 2012; by Jeffrey of YOSPOS

What's the deal with SVGs? Every once in a while I'll see a logo thats entirely SVG and i'm impressed, but I can't see how a 100+ line SVG code logo is more optimized / better than a 20kb png?

# ? May 13, 2021 01:29

Ima Computer: Oct 28, 2007; Stop all the downloading!

Help computer.

Empress Brosephine posted:

What's the deal with SVGs? Every once in a while I'll see a logo thats entirely SVG and i'm impressed, but I can't see how a 100+ line SVG code logo is more optimized / better than a 20kb png?

SVG's are vector graphics, so they can be scaled to any size or DPI without quality loss. Also, you can style them with CSS.

# ? May 13, 2021 01:35

dupersaurus: Aug 1, 2012; Futurism was an art movement where dudes were all 'CARS ARE COOL AND THE PAST IS FOR CHUMPS. LET'S DRAW SOME CARS.'

Empress Brosephine posted:

What's the deal with SVGs? Every once in a while I'll see a logo thats entirely SVG and i'm impressed, but I can't see how a 100+ line SVG code logo is more optimized / better than a 20kb png?

SVG is raw text and you can get a lot of text for 20kb; a reasonable SVG is going to be on the order of bytes big. The trade off is that since it�s vector all of that has to be calculated and drawn, so they�re less performant than raster images, but if you�re not going crazy it�s not going to be a huge problem.

# ? May 13, 2021 01:39

Empress Brosephine: Mar 31, 2012; by Jeffrey of YOSPOS

Gotcha. Is there any reason to use them over say a png if i'm not going to be doing any styling or resizing?

# ? May 13, 2021 01:40

Adbot: ADBOT LOVES YOU

# ? May 19, 2024 06:54

fsif: Jul 18, 2003

Yeah. Assuming it's a simple vector image (e.g., logo, icon, etc) the file size will be smaller.

If you're not trying to style it via CSS, you don't have to online the graphic; you can just link it with an img src like you would a PNG.

# ? May 13, 2021 01:46

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Modern front-end development: skinny jeans and handlebar mustaches ITT

«‹›235 »