[HN Gopher] Knowing CSS is mastery to front end development
___________________________________________________________________
Knowing CSS is mastery to front end development
Author : tipiirai
Score : 157 points
Date : 2025-03-02 04:32 UTC (18 hours ago)
(HTM) web link (helloanselm.com)
(TXT) w3m dump (helloanselm.com)
| sublinear wrote:
| > To me, the main reason is different: You won't be a master at
| frontend development if you don't understand underlying
| mechanisms of a language.
|
| True for any paradigm, not just frontend.
| maigret wrote:
| Of course but that's a too general statement. What developers
| IMO fail to get is that CSS is so different because it's a
| language to express design and they don't understand the basics
| of design. Almost all programming languages are about logic and
| taught at all CS / programming schools. But design mostly isn't
| and is much more complex than people think first (check for
| example grid theory).
| mosselman wrote:
| That is a great observation around logic vs design. Any
| resources you recommend for more design theory?
| maigret wrote:
| Definitely this one https://www.amazon.com/Grid-systems-
| graphic-design-communica... but also any other great book
| about design and architecture.
|
| Design have two aspects, the doing (drawing, documenting,
| adjusting) and the thinking (what's the actual problem and
| the concept to solve it, which will give me a frame of
| choices). There is a lot of content on solving the right
| problem - check the resources from IDEO, or for a broader
| view Don Norman for example https://www.amazon.com/Design-
| Everyday-Things-Revised-Expand...
|
| Also don't forget typography basics since most websites,
| apps and documents are mostly only text, there are lots of
| tutorials out there.
| smahs wrote:
| And geometry, which is high school level for the most part
| IMO but combined with cascading in the third (z) dimension.
| Introduce 'relative' with its own coordinate system and then
| do transforms in it (to be fair, its only complex in some
| cases like where the transformed parent is different from the
| relative parent). And then get into the time domain for
| transitions. Its math after all, but not the same that most
| programming courses teach.
| blitzar wrote:
| > You won't be a master if you don't understand underlying
| mechanisms.
|
| Think I got that in a fortune cookie once.
| iammrpayments wrote:
| I'm forking Shopify's polaris-react library for my personal use
| and some of the components are clearly made to people who don't
| know how to use CSS.
|
| For example, there's a component called "InlineStack" which is
| just a javascript wrapper for a div with flex. This stuff drives
| me nuts.
| nfw2 wrote:
| The benefit of components like InlineStack is that the
| components then have names that semantically describe their
| purpose in the layout.
| yolo3000 wrote:
| The fragmentation this creates is not worth it, we're
| building the tower of Babel of web technologies. If you look
| at 'modern' web applications every html component is
| rephrased into something like this 'inlinestack' crap.
| yurishimo wrote:
| The tower of Web Babel was built 5 years ago during peak
| React. It's gotten better tbh as more competition has
| creeped into the web space due to React dropping the ball
| and resting on their laurels.
|
| While I understand the gut reaction to seeing something
| like InlineStack, it's not any different than a utility
| class except the abstraction has been made on the component
| level instead of the CSS level within a bunch of different
| components. The other thing is that these types of
| components provide a layer for abstraction that extends
| beyond the web. If I'm writing a app that targets web and
| native mobile, I can let the compiler decide which version
| to place in the build to take advantage of native features
| of the platform.
|
| At a certain scale, programming becomes about maintaining
| consistency at said scale and less about the craftsmanship
| of an individual component. As a developer who also enjoys
| writing CSS and building layouts myself by hand, I
| understand your frustration but it's misguided towards a
| group of developers who are trying to solve different
| problems.
|
| We don't need to implement everything that FAANG comes up
| with in their "innovation labs" and I 100% believe that
| there is a place for handcrafted code in applications for
| decades to come. But let's not lose site of the fact that
| table saws haven't replaced hand saws. They serve different
| purposes for different audiences and that's okay!
| notpushkin wrote:
| Don't forget that components also add more runtime
| complexity.
| nfw2 wrote:
| Not to be pedantic, but I am legitimately confused about
| how the babel of tower metaphor is being used here. In
| biblical lore, the flaw of the tower of babel was that it
| too successful as a unifying project. Is this what you
| mean in regards to react? It seems that other comment
| meant the opposite.
| Towaway69 wrote:
| I'd personally prefer to write markdown instead of html,
| especially when writing comments on sites like these.
|
| But I have to know that stars represent html italic tags
| (and bunches of other stuff).
|
| Thankfully this has been standardised and every markdown
| parser knows what stars mean. So I only have to learn this
| once.
|
| Most frameworks haven't been standardised and that's where
| the frustration lies.
|
| Abstraction is good when it becomes a commonality, bad when
| it remains niche.
| bryanrasmussen wrote:
| Why is InlineStack any more semantic than say FlexDiv?
|
| Semantics is at some point arbitrarily agreed upon and
| memorized.
| dsego wrote:
| It's not, FlexDiv is just another name for Stack, they are
| describing the same aspect. Eg. you can imagine one CSS
| library using Flex, one Group and the third one Stack for
| the same concept, eg. some other UI frameworks use VBox and
| HBox. But it is still different from TopSectionHeader,
| SectionHeaderInner, SectionBodyWrapper, or whatever other
| names you have to come up with to give your component
| "semantic" meaning according to their content.
| isleyaardvark wrote:
| > to give your component "semantic" meaning according to
| their content.
|
| This is one of the biggest pros for Tailwind, is that it
| leads people away from this misbegotten mindset. The
| scare quotes around "semantic" are right. It's amazing
| how many of the same people stress separation of concerns
| to separate content from presentation, then turn around
| and name the presentation after the content.
| iammrpayments wrote:
| I instead use <div class="flex"><\div> now.
|
| If the class name is not enough for me to guess, I just
| hover the class name and the LSP will show me the applied
| styles.
|
| Another issue is that Shopify changes the name of these
| components for no reason, for example InlineStack was once
| called Inline, then HorizontalStack, then InlineStack,
| while the flex box model hasn't change since 2012
| biohacker85 wrote:
| Naming things is hard but I feel like there is something
| odd about a class name referencing a single CSS property
| as it is basically an inline style: <div style="display:
| flex"></div>
| dsego wrote:
| Not sure why it matters, <b> is the same as <span
| style="font-weight: bold">... If you want, name it
| "stack" or "vbox" instead of "flex".
| nfw2 wrote:
| Because flex just references the layout engine, and div
| intentionally has no semantic meaning. Fwiw I don't think
| InlineStack is a particularly good name either, but the
| criticism of this needs more justification than just "it's
| not how we did things in the past".
|
| Semantics evolve over time. This is true of natural
| language and coding practice.
| korm wrote:
| It's a bit like the <center> tag. A codebase that's littered
| with stuff like "InlineStack" is harder to work with and parse
| because the resulting div soup still requires extra styling,
| which is now both markup and CSS.
| dsego wrote:
| Why is it harder to work with? It makes it immediately
| obvious what the visual layout is and what the purpose of the
| component is and a lot of time all you want to do is have a
| flex on a component and you don't need other CSS to warrant
| yet another CSS class. It's the same reason why utility CSS
| was created (eg <div class="flex">). It also saves you from
| having to come up with a semantic name in your CSS for every
| wrapper.
|
| Compare the following: <Stack gap={2}
| direction="row"> <Box> <Avatar />
| </Box> <Box> <Button />
| </Box> </Stack> -----
| <MyCustomWrapper> <InnerChild>
| <Avatar> </InnerChild> <InnerChild>
| <Button /> </InnerChild>
| </MyCustomWrapper>
| dsego wrote:
| Because sometimes you just need a flex wrapper. And it's easier
| to see InlineStack everywhere in your JSX than deciphering the
| layout from mixed CSS. Whereas plain CSS separates some
| concerns away from HTML, it also intermingles different
| concerns together, like layout, positioning, spacing, look &
| feel, etc. At least with structural or utility components like
| Stack, Group, Flex, or whatever it makes it more obvious what
| the intent is.
| prezjordan wrote:
| You're leaving out the most important bit of a component like
| InlineStack: the props [0]. Yes you can just apply `display:
| flex` to the div you're working on, but like any proper
| abstraction these guardrails make using flexbox correctly the
| easiest path forward (the "pit of a success").
|
| [0]:
| https://github.com/Shopify/polaris/blob/eb6161f6b4e02679b5e8...
| sunami-ai wrote:
| CSS: The AI's Achilles Heel
| smahs wrote:
| On the contrary, I have found reasoning models (DS R1 mostly)
| to be very good at complex positioning and transition problems.
| They can't "visualize" anything, so can't design well unless
| you explain them well (which is the problem in design, most
| people have vague ideas but can't explain it well in CSS
| terms).
| sunami-ai wrote:
| if you can explain it wel in css you might as well write it
| yourself :)
| postepowanieadm wrote:
| If only the web took xhtml path.
| Kwpolska wrote:
| If only XHTML changed anything besides adding pointless
| backslashes to <img>...
| efilife wrote:
| what would it change?
| quectophoton wrote:
| Infrastructure as well.
|
| I don't think anyone _sane_ would let "prompt engineers"
| anywhere near their Terraform/OpenTofu/Pulumi/$OTHER code.
|
| Giving write access to people who depend on LLMs (as in "can do
| almost nothing without it") is a recipe for disaster. Even
| giving write access to a junior is less scary than that, in
| comparison.
| mubou wrote:
| > people who depend on LLMs (as in "can do almost nothing
| without it")
|
| This is what makes me afraid for the future of software
| development. Even in this thread you see people saying they
| "don't write css and just let the ai do it." I don't think I
| could work for a company where the devs don't understand the
| language and just have chatgpt poop out blocks of code until
| it works, but we're starting to see exactly that now. And
| worse: they're _proud_ of it. It 's terrifying.
| einsteinx2 wrote:
| Ironically I feel like these are exactly the programmers
| that are actually at risk of LLM agents replacing their
| jobs in the near/medium term.
| ulrischa wrote:
| "Knowing" CSS in these days is nearly impossible. There are so
| many language features. Don't get me wrong: CSS today is cool and
| nearly anything is possible (can Doom run wirh CSS by the way?),
| but I work as frontend dev for years and I have not the feeling I
| really know CSS in depth
| becquerel wrote:
| I think the doom() function is still getting rolled out across
| the major browsers. IIRC newer versions of Chrome have a
| working implementation.
| sublinear wrote:
| These jokes, as lightheartded as they are, need to stop.
| Especially true on here.
| bryanrasmussen wrote:
| how many features does CSS - the language - have now in
| comparison to JavaScript?
|
| How many features do the various APIs altogether have.
|
| How many features do the various object models have, CSSOM, SVG
| DOM, HTML DOM, Shadow DOM...
|
| What is your knowledge of all these features in comparison to
| CSS features?
|
| Jumping off of that and go look at any mature language and CS
| subject, there is probably too much for you "know" completely,
| but there is of course possibility to "know" a general argument
| for how to use it properly, once that is known individual
| things is just looking up syntax.
| bryanrasmussen wrote:
| ok evidently someone thought that all of these things are
| easier to know than CSS, which is just ludicrous, and gave me
| a downvote to let me know their disapproval of my opinion.
|
| Very Classy. But not CSS Classy.
| JansjoFromIkea wrote:
| I wouldn't get too hung up on downvoting online, ignoring
| deliberately malicious actors the range of reasons for
| downvoting can go from "this person posted a hate crime" to
| "other people already posted something close enough to
| this" or even "this person gave a perfectly valid answer
| but it does not feel like it's taking the discussion in the
| direction I feel it's meant to go"
| bryanrasmussen wrote:
| I know, just every now and then it is particularly weird
| and I comment. Also it was real quick, like I had said
| something so offensive it needed to be pounced on. :)
| mattlondon wrote:
| There is knowing and there is knowing.
|
| I don't pretend to know every dark corner of typescript,
| neither for CSS. But knowing enough detail to be efficient and
| write maintainable and easily extendable code is important.
|
| Don't let perfect be the enemy of good.
| postepowanieadm wrote:
| After reading mixu/cssbook I felt I knew and understood CSS
| quite well. But it was 10 years ago! Every new feature brings
| new edge cases that combine with all existing edge cases. Add
| some features like WebComponents and you have far too much
| undefined behaviour.
| soulofmischief wrote:
| What undefined behavior have you encountered with CSS?
| postepowanieadm wrote:
| Tables and Web Components combined with grid or flex is
| where magic happens.
| bob1029 wrote:
| I think knowing what to ask and where to look represents
| mastery of CSS.
|
| Understanding the approximate power of things like flexbox and
| having some aesthetic taste is much of the battle. You have to
| be willing to get your hands dirty. CSS is almost entirely
| about art. Figure out which paint brushes and techniques work
| best for you. There are a lot of viable paths.
| econ wrote:
| That was then, now it is a 3d engine.
| mablopoule wrote:
| No, it has a 3d engine, one that you can happily ignore
| 99.9999% of the time. CSS has a few gotcha, a few things to
| got to understand about it (selectors, selector priority
| and the way content flow depending on absolute / relative
| positionning), but it is not an impossible language to pick
| up, far from it.
|
| As the grandparent comment said, don't let the perfect be
| the enemy of the good.
| soulofmischief wrote:
| It just sounds like you need to spend more time solving
| problems with CSS. "Knowing" CSS means being able to style most
| things without needing to check any resources or otherwise look
| for help.
|
| Occasionally there might be a particular issue that requires
| contemplation or reading the manual, but that is true of any
| sufficiently complex design system, especially a living
| specification such as CSS.
|
| I recommend familiarizing yourself with new features as they
| are adopted. For example, front end devs are going to need to
| learn Houdini.
| wruza wrote:
| I spent some honest time solving the problems in css. You
| know what was the industry/search approved solution 90% of
| the times? Some greasy hack that assumes sizes and doesn't
| translate elsewhere or generalize into experience. You just
| start to know how to make a single x of X, but X is still as
| big.
|
| Css is a pile of low-effort crap targeted specifically at ad-
| hoc problems web designers had. It can make front pages, and
| sucks at everything else.
| soulofmischief wrote:
| That was way back, things are a lot better now than they
| were 15 years ago. Anyway, I got by quite far never
| assuming sizes with hacks like `height: 0; padding: 100%;`
| etc. But that kind of stuff is almost never needed today to
| get good results.
|
| > It can make front pages, and sucks at everything else
|
| I've made some very slick apps and widgets over the years
| using CSS. CSS isn't the problem, a lack of imagination is.
| CSS actually covers quite a lot of cases today, and with
| Houdini etc being exposed, the sky will soon be the limit.
| econ wrote:
| I knew css at a time, then it ran away from me and mocked me
| from afar.
| phartenfeller wrote:
| For me TailwindCSS actually was helpful in learning CSS. You
| still apply the same core CSS fundamentals. If you created a
| complex layout in Tailwind, you can also do it in normal CSS. I
| look up the exact rules behind their classes frequently in their
| docs.
|
| If you just copy classes and don't care to understand them, it's
| a different story of course.
| robin_reala wrote:
| You don't apply the same core fundamentals because Tailwind
| works to specifically remove _the_ core fundamental of CSS: the
| cascade.
| kristiandupont wrote:
| I guess, but that has certainly been a huge relief in my
| personal experience.
| nfw2 wrote:
| yes, specificity wars make it really hard to reuse
| components across multiple product domains and teams within
| a large org.
|
| by css fundamentals, they just mean what the various style
| properties do.
| arcosdev wrote:
| CSS is still a masochistic mess that should be replaced
| recursive wrote:
| If we were to replace it, what improvements would the
| replacement have?
| noelwelsh wrote:
| Between Tailwind and LLM generation I doubt I'll ever write more
| than a handful of CSS lines by hand in any future project I work
| on. CSS has, for me, become like the ASM output of the compilers
| I use. The result is good enough 99.999% of the time for me and I
| want to work at a higher level of abstraction.
| OsrsNeedsf2P wrote:
| The downvoted comment is correct. The only CSS I've used in the
| last couple years has been to debug issues Claude couldn't
| resolve - and to delete excess styling that wasn't being
| applied anywhere.
|
| It has given me the flexibility, accuracy, scalability, and
| proved the test of time (going strong on 3 years)
| Boltgolt wrote:
| Interesting, I can type CSS much much quicker than describing
| to an LLM what kind of layout I want and with what look
| noelwelsh wrote:
| I find LLMs are best for creating the template, or filling in
| gaps of my knowledge. Examples:
|
| 1. Using a prompt like "Using Tailwind, create a three column
| layout with main content in the center column and smaller
| side columns for ancillary information" will generate HTML +
| CSS faster than I can type.
|
| 2. I use the LLM to generate some CSS styling for setting a
| background blur, which was something I hadn't done before
| using Tailwind. It created code faster than I could find
| things in the documentation, though I had to go and patch it
| up later. In essence it pointed me in the right direction.
|
| If I'm looking at a preview and want to change the styling of
| a particular element it is usually faster to directly edit it
| myself than get an LLM to do that. Tailwind makes this faster
| as the CSS is right there on HTML; I don't have to switch
| between stylesheet and HTML.
| skydhash wrote:
| 1. I've mostly gone to the grid section of the docs of
| whatever framework I'm using (bulma these days) and copy
| paste the example, then copy paste my own code when I have
| enough pages done.
|
| > _Tailwind makes this faster as the CSS is right there on
| HTML; I don 't have to switch between stylesheet and HTML._
|
| I mostly use the web inspector for live edits to get a feel
| then I copy over the final result to the sheet. For more
| complex components, I use Codepen.
| ripped_britches wrote:
| This is why I fully moved to flutter. Everything, including
| styling, is just a widget. It's surprisingly liberating to write
| boring C# looking code that accurately describes a UI component
| without inheritance, overrides, style compiling, etc
| b0m wrote:
| Hi. C# dev here. Would you please elaborate a bit how do you
| use flutter and C#?
| baueric wrote:
| I think he means Dart code resembles C# pretty closely.
| amonith wrote:
| Same, as C# dev I love Flutter. However I just know in my bones
| that Google will ditch it some day. It's been too many years
| without significant adoption and it will stop making sense in
| the corporate spreadsheet one day.
| frou_dh wrote:
| At least according to this post which was on HN recently,
| Flutter lacking significant adoption is a myth:
| https://shorebird.dev/blog/dart-
| macros/#:~:text=Flutter%20ha...
| pjmlp wrote:
| Basically why Flash ruled back in the day.
| notpushkin wrote:
| It also throws away HTML and throws everything on a canvas
| instead, which means three things:
|
| 1. Accessibility is now an afterthought
|
| 2. Giant runtime you have to download for every website
|
| 3. Bewildering non-native behaviour on mobile
| llama_drama wrote:
| > Everything, including styling, is just a widget.
|
| And that's the downside. What would be just two or three nested
| <div>s in HTML+CSS turns into several screens of widgets,
| making navigation and debugging much harder. I once had an
| issue with extra margin in one of Flutter's built-in widgets
| and spent hours trying to figure out why - without success.
| bpev wrote:
| Frankly, I feel like it goes even further than CSS. People don't
| really talk about HTML that much, probably just because it
| doesn't change as much as JS frameworks, etc. But that doesn't
| mean you should ignore it completely and just use a bunch of
| divs!
|
| When you start digging into all the different HTML elements and
| aria guidelines (for example, the differences between `<nav />`
| and `<menu role="menubar" />`), I think development starts to be
| a bit more clear, because you start to see how your tools are
| intended to be used. I think it also makes decisions around CSS
| styling more clear. And as a bonus, your code just starts
| becoming more accessible, which is nice.
|
| https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
| bryanhogan wrote:
| I disagree with many of the comments here. CSS is not too
| complicated. It's a good way to style HTML elements.
|
| There are some popular abstractions to writing CSS such as
| Tailwind. Although I do see it misguiding a lot of people. When
| you don't know CSS but want a webpage, use a template instead. If
| you want deep custom styling you will need to understand CSS.
| Tailwind is just a collection of predefined utility classes which
| you then over use, breaking a few clean code principles along the
| way, but you get a decent looking website without writing all the
| utility classes yourself, which can be helpful especially in
| larger team projects.
|
| There are improvements to this problem such as DaisyUI.
|
| But regardless, they do require some understanding of CSS. And if
| you do understand some CSS, getting to the next level and
| learning how to write scalable CSS is not much harder. The simple
| requirement of having global and scoped styling is a given in
| every modern framework.
|
| This is partly what led me to create a guide on writing modern
| scalable HTML and CSS: https://webdev.bryanhogan.com/
|
| - Tailwind (wow, the website is laggy): https://tailwindcss.com/
|
| - DaisyUI: https://daisyui.com/
|
| - Some modern framework, e.g. Astro: https://astro.build/
| exceptione wrote:
| From daisyui.com: Tailwind CSS provides low-
| level utility classes, wich usually inlcude only one CSS rule.
| daisyUI classes are a combination of multiple CSS rule that are
| named semantically for each part of the UI.
|
| So, to put it simple, Tailwind re-implements css property-value
| pairs as classnames, whereas daisyui re-implements css
| classnames.
|
| It seems like the whole dance is to avoid
| class="btn" style="font-color: #3e3"
|
| So what is different from above is that a style override is now
| possible via class like class="btn font-
| color-3e3"
|
| (or whatever tailwind provides as builtin class). Are these
| layers of indirection worth it, and still needed with modern
| css? I remember we came to css frameworks and BEM _because it
| was difficult to scope css_.
| wwweston wrote:
| > and BEM because it was difficult to scope css.
|
| I suspect this reflects the cultural problem that in many
| organizations no one really wants to create or stick to a
| systematic design.
|
| Scoping CSS isn't trivial as a site grows large, but it's far
| from intractable.
|
| Tailwind's orientation on concrete details everywhere is the
| "just give up" solution -- stop trying to get the
| organization and culture to do work they don't want to do.
|
| EDIT: I'd also guess there's an element of poor feedback
| loops for most development tools. When people people talk
| about things like "I don't want to have to look up what every
| class means", they're speaking to one reality of code
| componentization across the multiple dimensions of
| styling/semantics/markup/logic in development environments
| that often can't support interactive, legible, and
| interconnective feedback as development is done. There are
| probably solutions to this but they're more involved and less
| well known or fungible than just collapsing
| styling/semantics/markup into a single dimension around a
| consistent constrained UI domain language you can add to your
| resume in a week tops. This is friendlier to the predominant
| "culture" for building front ends right now.
| exceptione wrote:
| > Tailwind's orientation on concrete details everywhere is
| the "just give up" solution
|
| Yes, and that is why I am genuinely curious whether going
| the nuclear approach is still needed, or that css
| variables, @scope and what-not of today solves the problems
| of the past.
|
| Because it seems that Tailwind introduces problems that CSS
| sought to resolve, and now DaisyUI seeks to resolve the
| problems of Tailwind.
|
| Are we now at a point that devs do not know enough about
| the basics and are mentally stuck on tools they do know? Or
| is it that the old problems still have not been solved?
| wwweston wrote:
| Yes & yes.
|
| It seems to me _really_ learning CSS has been something
| most devs who started doing anything else have long
| wanted to avoid. I suspect it just scratches different
| itches and feels more like configuration than
| programming. And of course once an abstraction layer
| becomes key in established development culture, the
| opportunities for reward are probably broader with the
| abstraction than with the layers underneath it. Not sure
| styling has coalesced around Tailwind or DaisyUI enough
| to lock that in, though.
|
| I'd guess css vars, @scope, etc do solve some problems.
| I'd also guess something equivalent to full native mixins
| would be needed to solve most technical
| expressive/organizational problems and I'm not sure css
| vars get there. Plus there's the various factors in org
| culture that tend to undervalue all kinds of areas of
| front-end design and engineering (which I'd guess largely
| boil down to a combination of the incentives towards
| conversion-oriented tinkering and bikeshedding pride
| among recognized product stakeholders).
| exceptione wrote:
| > I'd also guess something equivalent to full native
| mixins would be needed to solve most technical
| expressive/organizational problems and I'm not sure css
| vars get there
|
| You said native, but could a CSS preprocessor in the
| meantime fill that gap? If @layer and @scope would fix
| the problems pre-BEM, I think we are done then.
| > Plus there's the various factors in org culture that
| tend to undervalue all kinds of areas of front-end design
| and engineering
|
| Yes, if it is people just don't want to reuse, but want
| to have a quick hack for something like
| <button class="class_6447823468">
|
| then it is more a tool for an organization/skill problem
| I guess.
|
| I just don't see how you can reach and enforce a
| consistent, maintainable styling across a medium to large
| website with something like Tailwind. Do people trade
| quality, consistency and freedom for a limited set of
| design tokens that might be applied inconsistently?
|
| I have to admit I have not done much in css since a long
| time, and given the enthusiasm for Tailwind I wonder if
| my understanding is lacking.
| seanwilson wrote:
| > Because it seems that Tailwind introduces problems that
| CSS sought to resolve
|
| > Are we now at a point that devs do not know enough
| about the basics and are mentally stuck on tools they do
| know? Or is it that the old problems still have not been
| solved?
|
| You should read all of
| https://tailwindcss.com/docs/styling-with-utility-
| classes. Experienced developers use Tailwind because it
| solves real problems with CSS that are hard to understand
| until you've worked on complex sites, with complex
| designs, and/or with large teams. People will often tar
| Tailwind users as people that don't understand CSS well
| when this isn't the case.
|
| Plain CSS is fine for simple designs and document based
| sites, but e.g. cascading styles, specificity, and the
| way styles are spread between files becomes a nightmare
| to grow and maintain later. CSS wasn't invented with the
| kinds of complex responsive UIs and designs we need to
| write now, so it's not a surprise the traditional way
| doesn't scale well.
|
| Ever worked on Java/OOP code with huge complex fragile
| inheritance trees spread across files where you can't
| figure out which piece of code is overriding something,
| or how to make your change without breaking something
| else? It's not unlike that, yet people will blindly
| defend the traditional CSS approach because the flaws
| aren't widely accepted yet.
| crooked-v wrote:
| For me, it's always been much less of a technical thing,
| and much more that the material coming out of the product
| design part of the business is never _actually_ consistent
| enough that you can have a single consistent CSS file drive
| the whole site.
| moralestapia wrote:
| I never got the appeal of Tailwind, it's almost a 1-to-1 map
| from style="" to classname="", they just made the terms
| slightly easier to remember.
|
| Tailwind is a prime example on how good marketing can help you
| win a market, even if the alternative is free, even if it's
| already crowded, even if your product is trash. Marketing wins.
|
| Edit: I have used Tailwind, a lot. Recently, upgrading from v3
| to v4 in a Next.JS project, which was supposed to be a no
| brainer, turned out to be a four hour ordeal. I cannot spend
| that much time just to make sure that "background-color: red"
| still works, lmao, it is such a travesty. Because of that, I'm
| in the process of removing it from my projects now.
| Cu3PO42 wrote:
| For the longest time, I didn't get it either. It took me
| actually trying it out in a project to like it. It's true,
| much of it is the same as writing inline-styles, but it's
| also more powerful than that. Here's a few things that I like
| about it:
|
| - Ability to use pseudo-selectors, etc. in "inline-styles"
|
| - Limited set of predefined values to use for padding,
| margin, and such that make it a bit easier to stay consistent
|
| - Some helpful utilities like good looking shadows and
| animations
|
| Sure, I could achieve all of that in a different way. Nothing
| about it is ground-breaking or even unique, but it's a nice
| package that works well for me.
| dsego wrote:
| > Limited set of predefined values to us...
|
| With the ability to predefine css constants I guess it's
| now possible to use the style prop directly and not have to
| use raw hex colors and pixel values (eg. there are css
| libraries with these https://open-props.style).
| chamomeal wrote:
| That's exactly what I thought until I actually tried
| tailwind. Now I really like it.
|
| It has pros and cons like anything though. Trying to style a
| fundamental component is pretty painful. Like imagine your
| company's main "button" element. It's got 8 different sizes,
| optional icons on both sides, animations, styles, each
| needing to support different color combos. Tailwind is
| miserable for that. You get giant huge balls of spaghetti
| classes all over your button, and it's pretty
| incomprehensible.
|
| But for "glue" styles, it's freakin amazing. Putting those
| components together, giving them spacing, even making simple
| components that don't have lots of conditional properties?
| It's really nice. You can style stuff quickly and
| consistently right from the markdown, you don't have to think
| of classnames for every teeny little thing, and you can
| somewhat imagine what stuff looks like just by looking at the
| jsx.
|
| I remember the crazy hype around it when it got popular, and
| it really put me off. Didn't even try it for a long time. Now
| I'm in a codebase that doesn't have it, and I miss it! I
| don't miss it terribly, but it was a nice little QOL upgrade
| codetrotter wrote:
| > You can style stuff quickly and consistently right from
| the markdown, you don't have to think of classnames for
| every teeny little thing, and you can somewhat imagine what
| stuff looks like just by looking at the jsx.
|
| I still don't understand what it brings over putting style=
| whatever on the element.
| mhitza wrote:
| > I still don't understand what it brings over putting
| style= whatever on the element.
|
| You can't put a style for dark mode and one for light
| mode. Lifting these properties from styles to classes
| allows you to combine them with media queries and states.
| codetrotter wrote:
| Sounded to me like parent commenter was not advocating
| for that sort of thing so much.
|
| They said
|
| > Like imagine your company's main "button" element. It's
| got 8 different sizes, optional icons on both sides,
| animations, styles, each needing to support different
| color combos. Tailwind is miserable for that. You get
| giant huge balls of spaghetti classes all over your
| button, and it's pretty incomprehensible.
|
| Which to me sounds like they would not use Tailwind for
| dark mode / light mode things either. But I might be
| misunderstanding
| wwweston wrote:
| It sounds like you're saying we need to consider the
| flexibility and articulation that classes enable when
| they reflect considerations beyond concrete presentation.
| zelphirkalt wrote:
| If you got lots of "custom" styling for elements, why can't
| one write a CSS class just as easily and give the element
| that class? Why is Tailwind better? Am I not also writing
| the definitions in Tailwind then and assigning those
| classes to my element then? I don't get what the benefit is
| supposed to be.
| chamomeal wrote:
| That's exactly what I do for elements with lots of custom
| styling!
|
| I guess I didn't explain fully, but for things like the
| button example, I use regular ol css modules. Tailwind is
| for all the glue. And in my experience, most of the css
| you write when working on a feature is glue.
| zelphirkalt wrote:
| > Edit: I have used Tailwind, a lot. Recently, upgrading from
| v3 to v4 in a Next.JS project, which was supposed to be a no
| brainer, turned out to be a four hour ordeal. I cannot spend
| that much time just to make sure that "background-color: red"
| still works, lmao, it is such a travesty. Because of that,
| I'm in the process of removing it from my projects now.
|
| What does "it" relate to in the last sentence? Tailwind or
| Next.JS?
|
| Anyway, making sure that background color still works, is
| that an argument for Tailwind? Wouldn't that be a great
| argument for simply using standard CSS properly?
| pessimizer wrote:
| >> I never got the appeal of Tailwind
|
| They're not arguing for Tailwind. They have used Tailwind.
| imiric wrote:
| Agreed. Tailwind is an abomination.
|
| Its biggest problem is that it's a leaky abstraction. The
| classes translate _almost_ 1:1 to the equivalent CSS, but not
| quite and not always. In the best case scenario, you use a
| utility class and don't think about the CSS. In the worst,
| you must understand both how to implement the feature in CSS
| _and_ how Tailwind does the translation. Then you need to
| think how to make Tailwind do what you want to do in CSS.
|
| All of this adds a considerable amount of mental overhead
| while developing. And in the best case scenario developers
| don't even bother learning CSS, which eventually leads to a
| stagnation of knowledge. It wouldn't surprise me if some
| junior frontend developers don't even understand CSS, and
| just call themselves "Tailwind developers".
|
| Yes, all abstractions move the focus to a higher layer up the
| stack, but the troubling thing with Tailwind is that on one
| hand it pretends that it's a lightweight abstraction (or not
| an abstraction at all[1]!), while at the same time causing
| confusion and degradation of knowledge of what it's supposed
| to be abstracting.
|
| And then there's the insanity of seeing dozens of utility
| classes on elements, where if you're not careful, each one
| could look and behave slightly differently. The number of
| times I've been tempted to just change the margin value on a
| single element to fix something is too high. It reminds me of
| the ` ` and single-pixel GIF spacer hacks we used
| decades ago. The claimed solution to this are components,
| which sometimes are not a good fit, or grouping utility
| classes into a single class, but then why am I using Tailwind
| at all? There are also libraries like DaisyUI built on top of
| Tailwind to resolve this problem, but the thought of piling
| more abstractions on this Jenga tower makes me shudder.
|
| I can understand why developers who are not great designers
| would find it appealing, and how it could be useful while
| prototyping, but in both cases using plain CSS (with some
| pre-processor, if you must) would be more maintainable and
| beneficial for the developer in the long run, while only
| slightly more inconvenient in the short-term.
|
| [1]: https://news.ycombinator.com/item?id=33787346
| nickpsecurity wrote:
| "CSS is not too complicated. It's a good way to style HTML
| elements."
|
| Humans think comparatively. So, it might help to tell them what
| CSS replaces.
|
| HTML has many structures: text, images, links, tables,
| divisions, etc. We'd have to style them in a procedurally-
| generated layout. We'd learn a GUI or 2D graphics engine. Maybe
| several, use a cross-platform with its limits, or write our
| own. At one point, we needed native extensions like Flash.
|
| Learning all of that would be difficult even for an experienced
| programmer. Whereas, many casual coders have learned CSS fairly
| easily. Then, it's usually just a matter of twiddling with it
| until it works right. Also, browsers make the twiddling cycle
| fast and easy vs testing homebrew GUI's.
|
| So, it's definitely easier most of the time. It's not always
| what's best. It's a nice baseline for HTML, though.
| jmull wrote:
| Something at the level of bootstrap or daisyui makes a lot of
| sense to me, a developer.
|
| But designers I've worked with -- and I've really got to defer
| to their expertise here -- often seem to be too constrained by
| the fixed design structure on what I'll call "signature" sites
| or pages. For things that aren't that important/visible, sure,
| these general systems work well enough. But for other things,
| there's a specific vision they are trying to achieve, and
| forcing that through something like daisyui and bootstrap is a
| hell of a lot more work (for me) than building from css
| directly, or from utility classes like tailwind provides.
|
| I think the reality is, the developer is building *app-level*
| components from html, css, and js. Naturally, you reach for
| something to take drudgery out of it, thus you work in terms of
| a middle-level abstraction. daisyui and tailwind are both such
| abstractions, so from a high-level there's isn't really much
| distinction or argument to be had. tailwind is somewhat lower
| level and more flexible while daisyui does more for you at the
| cost of reduced flexibility. Obviously, you pick something like
| daisyui when you're pretty sure you don't want/need the extra
| flexibility of tailwind, or tailwind when you're in doubt.
| Since you're going to have an app-level library of components,
| it's just not a big deal either way, just a matter of how
| pleasant it will be to develop and maintain those components.
| grandempire wrote:
| Lately I've been using bootstrap grid only and been happy
| with that.
| osigurdson wrote:
| I think for getting in the 70th percentile of UI design,
| tailwind + daisyui are fine. If you need to have the absolute
| best UI, it is necessary to understand CSS from the ground up.
| tacker2000 wrote:
| Isnt daisyui exactly what we were doing before the tailwind
| stuff came about? Are we now full circle again and need an
| entire plugin to handle this?
| zelphirkalt wrote:
| Yep, this aligns with what I think. Gonna check out your
| website about CSS. In my experience when I need to do some CSS,
| of course I need to look up how to do things, but I get into it
| and then it is rewarding, making something work nicely with
| minimal code. I made a personal website that is responsive
| without media queries at all. Requirements vary, but when you
| have a good grasp of CSS and don't rely on other stuff doing
| CSS for you, you can write good modular CSS, that just works.
|
| The tailwind page doesn't manage to have responsive layout that
| doesn't jump around at arbitrary widths. Instead of
| floating/moving elements seamlessly when the width is reduced,
| they suddenly jump around to their next position. This is
| rather "meh", not great. I guess they go full in with media
| queries.
| madeofpalk wrote:
| I think CSS gets all the flack it gets unfairly because people
| often run into it as a byproduct of other work they do. Whereas
| these developers probably aren't running into
| windows/macos/ios/android app development.
| wruza wrote:
| I've ran into almost all of this, and css is still the worst
| thing in the list. It's literally the highest wtf/gfy per
| minute among all. Barely debuggable, inconsistent, comefrom
| by design, inarticulate crap.
| dsego wrote:
| Especially since all the things that one would expect
| should be easy were just really difficult to do for a long
| time, things like vertically centering, layouts before
| grid/flex, changing a style in one place and not
| accidentally breaking some other part of html. There was a
| lot of tribal knowledge about browser quirks, how to clear
| floating divs for example, selector precedence, how margins
| collapse, etc, it's all just non-essential complexity that
| bites you in the ass when you have the least time to deal
| with it.
| wruza wrote:
| Exactly. Css is magic, in a sense that you can't make any
| sense of it. Just look at this:
| https://stackoverflow.com/a/19719427 , you can "tune"
| collapsing margins by adjusting overflow, float or
| position. Yeah! Imagine adjusting your seat by pressing
| brakes or turning radio off.
|
| _Perhaps the only difference when using hidden is the
| unintended consequence of hiding content if the parent
| has a fixed height_
|
| This is css community fundamentals. It works "perfectly",
| but make sure your height is not specified. Oh, and don't
| change the container type. And with time it all depends
| more and more on other hacks, until your layout turns
| into a knot of hacks and cross-sectional assumptions
| smeared all across the "codebase".
|
| And then you ought to make fully isolated non-leaky
| components with it. I mean, you can't, but here's a hack
| to make them fit together. I mean, in this particular
| case, wow thank god the container is already position
| absolute.
| Izkata wrote:
| > Just look at this: https://stackoverflow.com/a/19719427
| , you can "tune" collapsing margins by adjusting
| overflow, float or position. Yeah! Imagine adjusting your
| seat by pressing brakes or turning radio off.
|
| The seeming complexity here is because people refuse to
| learn the box model, so they learn all sorts of
| incantations and guess at what they need to do:
| https://developer.mozilla.org/en-
| US/docs/Learn_web_developme...
| madeofpalk wrote:
| C is magic in that I can't make any sense of it when I
| don't bother to learn it.
| christophilus wrote:
| Agreed. No static typing. Everything is global. Super easy
| to accidentally break a thing on some other page that you
| aren't aware of. It's just a brittle stack. Tailwind is by
| far my favorite bandaid for dealing with all of that.
| Perfect? No. But it's the best thing I've used in almost 25
| years doing this professionally.
| madeofpalk wrote:
| What are you talking about? CSS is statically typed. It
| has a fairly strict, well defined schema.
| maattdd wrote:
| Most of CSS is indeed statically typed (property have
| statically typed valid values). It's not true anymore
| when you introduce custom properties and IACVT though.
| bluSCALE4 wrote:
| The sad reality is that younger folks are too busy learning JS
| and backend devs just don't understand it. I've yet to learn
| new CSS patterns from anyone I've worked with in front end in
| the last 6 years. On the same note, I've worked on a few teams
| that have made backwards decisions and have chosen dead tools
| instead of embracing new CSS patterns. I think I have to take
| Ana Tudo, Lea Verou and Rachel Andrew for doing enough advocacy
| to keep my skillset relevant.
| PantaloonFlames wrote:
| Thanks for all this.
|
| > And if you do understand some CSS, getting to the next level
| and learning how to write scalable CSS is not much harder.
|
| I want to believe.
|
| I know some CSS and can write SCSS. But reaching the next level
| seems difficult.
| kevinsync wrote:
| I haven't had a chance to read the all the comments so this may
| have already been mentioned further down the line, but -- IMO
| mastering CSS (vanilla) is essential to understanding how
| browsers render content, which itself is vital to understanding
| how to structure content (and by extension, write browser
| JavaScript)
|
| Just learn it! It's worth it. It also makes Tailwind and all
| those abstractions way easier to grasp.
|
| P.S. Sass (SCSS) is incredibly powerful. Learn that too!
| Izkata wrote:
| > Tailwind is just a collection of predefined utility classes
| which you then over use, breaking a few clean code principles
| along the way
|
| I mean, if you're talking Clean Code the book, I think Tailwind
| does that "break it down too far" part pretty well.
| tabony wrote:
| CSS has way more features today than 15 years ago but is easier
| to master in my opinion.
|
| Back then, CSS implementations had a lot more quirks and you
| had to keep all of this in your head. Just because one
| combination of CSS properties in Firefox worked one way did not
| mean it worked even similarly in Internet Explorer.
| sirolimus wrote:
| AI has maketh CSS obsolote
| kristiandupont wrote:
| How so? That doesn't seem true to me at all.
| sirolimus wrote:
| I'm just being hyperbolic as a joke.
| Gualdrapo wrote:
| I agree. But I feel like nowadays knowing CSS is _not_ necessary
| to land a job in FED - while knowing frameworks as React
| /Next/Vue/whatever is.
| bryanhogan wrote:
| The idea is that by knowing HTML and CSS you know how to use
| any framework. Since they are the base technologies that every
| front-end developer should know, a frameworks should build upon
| the principles of these.
|
| This doesn't hold true for React, since they just decided to do
| their own thing, but for frameworks such as Svelte this is a
| core principle they try to stick to.
| nickpsecurity wrote:
| HTML/CSS was on most job descriptions I saw. Entry level wanted
| those and Javascript at a minimum. Your odds are better if you
| know all three.
| albedoa wrote:
| > HTML/CSS was on most job descriptions I saw.
|
| Those are going to be on nearly every FE job description you
| see. I think OP's point is that they are not necessary to
| land a job _despite_ their automatic inclusion in the job
| description.
|
| (Speaking anecdotally, the companies I have worked for either
| don't have any CSS masters to sufficiently test for mastery
| or don't include those experts in the interviewing process.
| Or, more commonly, we are so desperate for framework devs
| that any amount of CSS knowledge is considered good enough.)
| alt227 wrote:
| When I am hiring, I will always prioritise devs who have a
| strong knowledge of HTML/CSS/JS over any frameworks.
|
| If you know the language you can use any framework in that
| language with minimal effort, and the bonuses of being able to
| troubleshoot underlying issues is invaluable.
| andrewstuart wrote:
| Master Css then get the AI to do it.
| RealCodingOtaku wrote:
| The mastery to front end development is understanding the
| semantics of HTML.
|
| At every single company I worked for, I had to teach people to
| stop using div tag for everything. You can style things however
| you want, or even create components that the browser does not
| allow you to style (as long as you have fallbacks).
| jfengel wrote:
| Does HTML even have semantics? You practically can use div for
| everything, and then use CSS to make it act like whatever
| component you wanted.
|
| You should let the defaults do their job, but they don't do
| very much. HTML's main semantic is to give things a
| hierarchical structure. Visually it's a free for all after that
| theandrewbailey wrote:
| Yes, html has lots of semantic elements.
|
| https://developer.mozilla.org/en-
| US/docs/Glossary/Semantics#...
| neontomo wrote:
| > but they don't do very much
|
| no no no, different elements have different behaviours. for
| example, a button automatically has accessibility features
| like being able to tab to it and select with Enter key, which
| is essential for a screenreader. do that with a div and you
| end up building the functionality from scratch.
|
| if all you care about is the visuals, sure, there's little
| difference, but once you scratch the surface you will have a
| poor product by not using the correct elements (where there
| is a clear "correct" ofc, sometimes it's subjective).
| alt227 wrote:
| > I had to teach people to stop using div tag for everything
|
| Can you elaborate a bit on what you mean please?
| dsego wrote:
| I've seen juniors style divs as buttons, it's disheartening.
| azemetre wrote:
| I've seen seniors do the same thing.
|
| The root cause always seem to be the same.
|
| Pressure to get things done now. No time in the future to
| correct things. Possibility of getting fired for falling
| behind your peers that make the same shortcuts while you
| attempt to do things better.
|
| It's always an issue with management that doesn't care about
| doing things correct. So the incentive to keep your job is
| always perverse.
| brigandish wrote:
| The comments here remind of the "Git isn't hard to understand"
| humblebrags that we hear again and again on this forum,
| surrounded by a sea of honest and justified criticism.
|
| If lots of people complain about understanding your product -
| intelligent people - then your product is hard to understand.
| _Why_ is the important question.
| skydhash wrote:
| Usability is a thing and can be improved in some things, but
| sometimes it's people that don't want to read the manual and
| instead spend their day chasing after abstractions. Which they
| will abandon at the first edge case they cannot solve because
| of the lack of foundational understanding.
| omer_balyali wrote:
| It doesn't mean that the product is broken. Sometimes
| intelligence is the worst enemy of self, as you think you can
| easily understand something or not even have to learn it
| correctly, as it looks very trivial. This is the case with most
| software developers that trying to fit mental models from other
| languages to CSS and then expecting it to behave in the same
| way. Mismatch of mental models are not uncommon, especially in
| "intelligent people" as they don't always assume that their
| understanding may be wrong.
|
| For me, biggest issue with CSS is how it's taught, how it's
| learned and mental models around the concepts. Most people have
| a different mental model of how the underlying system works,
| and this mismatch results in developer trying hard to bend CSS
| to his will.
|
| CSS may be good or bad, there can be a better alternative...
| but are there any practical change that may happen soon enough
| that we stop learning and understanding how CSS works? Even we
| have a new language, people will try to use it as they used CSS
| before, so those intelligent people may do the same mistakes
| again.
|
| We are stuck with CSS, whether we like it or not. I've been
| writing CSS since 2001 and it progressed immensely, still there
| are many things that's not possible to do easily with only CSS.
| But still it's the only thing we have for now and to make it
| better or to make a better alternative we have to understand
| how it works before just saying "i need a new tool", as the new
| tool may have the same issues as well.
| karaterobot wrote:
| It's astonishing to me how many front end developers refuse to
| learn how to use vanilla CSS and Javascript, and the lengths they
| go to avoid touching them. I think of a lot of modern web tooling
| as a giant mech suit developers climb into to do battle with the
| underlying technologies of the web. There's so many layers of
| abstraction between you and the medium you work in, you can go
| your whole career without learning how to build a website
| yourself.
|
| The original justification was 'scaling' (a word that stands
| behind a lot of bad behavior, actually), because you cannot just
| write bare CSS for a large production website, _obviously_. But
| then it creeps down the ladder until pretty soon your hobby
| website is a 20 megabyte SPA with 500 NPM packages backing it.
| gjsman-1000 wrote:
| I think you miss the point.
|
| Having 25 developers trying to manage a CSS stylesheet together
| while naming classes does not scale.
|
| Having 25 developers not worry so much about stepping on other
| people's toes with Tailwind scales better.
|
| Or in a nutshell: What is one of the hardest problems in CS?
| Naming things. What is Tailwind's biggest feature? Build a
| frontend with minimal need to name things.
| jakelazaroff wrote:
| CSS modules solved the classname collision problem years
| prior, though.
| recursive wrote:
| When people say "CSS modules", I never know which one they
| mean. There's a feature on the spec track for CSS
| "imports". There's also a family of webpack plugins with
| various behavior. CSS modules, collectively solved it a
| number of times with various trade-offs. You can even end
| up with multiple kinds of CSS modules in the same code
| base.
| exceptione wrote:
| 25 developers working in the same module? Without a common
| style?
|
| Afaik we came from plain CSS -> BEM, because scoping styles
| was hard, so people found a discipline in naming things to
| isolate styling. Scoping did not exist in CSS.
|
| Then we got a movement from BEM -> Tailwind, because doing
| the scoping by hand was a bit difficult(?)
|
| Then we get Tailwind -> Tailwind + DaisyUI because Tailwind
| results in messy concretion.
|
| --------
|
| The question I have: are the modularity/scoping primitives in
| modern css good enough now, rendering Tailwind e.a obsolete?
|
| Are we still using Tailwind because people do not understand
| the original problem?
|
| Maybe someone can enlighten me.
| alt227 wrote:
| Why on earth would you ever have 25 front end developers
| editing the same classes in the same stylesheet?
| gjsman-1000 wrote:
| 12 year old project, 2 developers per year, turnover every
| year. That's all it takes.
| alt227 wrote:
| > Having 25 developers trying to manage a CSS stylesheet
| together
|
| Your comment suggests you mean 25 developers
| simultaneously
|
| 2 developers per year can easily maintain a coherent
| stylesheet.
| azangru wrote:
| > does not scale
|
| CSS already has @layer; and @scope is coming (waiting for
| firefox).
|
| There are naming conventions like bem. There are also tools
| to guarantee unique class names (css modules, 'single-file
| components' in various js frameworks).
|
| There are design systems to standardize and reduce the amount
| of CSS.
|
| There are web components, with their styles encapsulated in
| the shadow DOM.
| sfsefwafawfa wrote:
| Hard agree, written Tailwind since the very inception. I love
| it for exactly this, the purging, JIT, arbitrary values, plus
| you can just write plain CSS any time you want. I have used
| Tailwind on big FAANG sites and boutique shops. Worked great
| for both, scales, and is very customizable.
| isodev wrote:
| > Having 25 developers trying to manage a CSS stylesheet
| together
|
| As opposed to 25 developers trying to manage a React
| component together? I don't think that's feasible either.
| dsego wrote:
| Hence why companies adopt UI toolkits, otherwise it gets
| messy. Without discipline it's hard to develop a set of
| core components and often times devs will duplicate work
| and fail to extract common parts due to the nature of
| working on features across the stack and failing to
| recognize common patterns.
| isodev wrote:
| My point was, you use the language features to separate
| concerns into manageable pieces (which CSS can do just as
| well as TypeScript).
|
| Tawilwind was created at a time when we were still
| feeling the IE days, triton was still a thing and people
| generally had to look up resets or how to setup tooling
| to help them with vendor prefixes (that was before
| Interop was a thing), etc. All this while, designers
| would ship individual design tokens for implementation
| (e.g. a button, a combo box). Things like "styled
| components" would feel like a relief because "oh I can
| style a button without breaking the entire website".
|
| Since then, all these points of friction have been
| improved or removed all together. We wouldn't lose
| anything if we revisit the platform and see how we can
| get all the benefits of tailwind without actually
| adopting it by default.
|
| By the way, the same argument can be made about React and
| revisiting what one can do with modern DOM features.
|
| I guess something all frameworks born in the past to
| solve real problems have in common - we tend to forget to
| deprecate them once the underlying need for them was
| gone.
| bob1029 wrote:
| It has never been easier to build web applications with a
| vanilla stack.
|
| In 2010 there existed incredibly solid arguments for
| abstraction over the DOM. You had browsers with insane quirks
| and you had no choice but to support them. Over a decade and a
| half later, I'd argue we are in a completely different world.
| The only browser that bites my hand these days is Safari, and
| it's barely a nibble compared to what we used to deal with.
|
| Those who adapt to the new reality will likely outpace those
| who continue to hobble themselves with rusty old training
| wheels.
| evantbyrne wrote:
| As with any profession, most workers are just proficient in
| whatever they need to do. The people littering these things
| with comments about how Tailwind is "enough" are probably
| telling the truth for their personal experiences. A lot of web
| developers don't have professional experience working with
| designers and implementing software to visual specifications.
| alberth wrote:
| CSS for _styling_ is straight forward (which makes sense since
| 'CSS' is cascading 'styling' sheets)
|
| CSS for _layout_ takes sometime getting use too.
|
| For me, the benefit of any css framework is not in prepackaged
| styles - it's in simplifying layout for desktop/tablet/phone.
| efortis wrote:
| Why CSS Modules are so unpopular?
| recursive wrote:
| It's not standard yet. Behavior is implementation-defined and
| under-specified. A lot of people have used a thing like
| this[1], but this[2] is on a standards track. In the
| documentation for the first one, it describes a default "file
| scope", but really no definition of what a file is. It seems to
| be referring to a source file pre-build/bundle, but it really
| just doesn't say. That would belong in the documentation for
| some framework, not web platform stuff anyway.
|
| The _idea_ of locally scoped styles is reasonably popular. Like
| vue single-file-components, and n+1 different implementations
| of "CSS modules". What it really needs though, is
| standardization. Things like [2] and the upcoming @scope will
| provide this.
|
| [1]: https://github.com/css-modules/css-
| modules/blob/master/docs/...
|
| [2]: https://github.com/WICG/webcomponents/blob/gh-
| pages/proposal...
| mrcwinn wrote:
| For better or worse, I've been using Tailwind since it was
| released. I'm not even sure I remember intermediate to complex
| CSS. Better places to spend time. I'm really grateful for what
| that team has done.
| Waterluvian wrote:
| CSS is one of those things you can become very effective with,
| without knowing it all. I really don't think you need to know it
| all.
|
| I also think it has a lot of tools you don't always need. Don't
| go crazy with selectors!
| spoonfeeder006 wrote:
| > Custom icons for an input field? Welp, it's not that easy for
| privacy reasons to add a pseudo-class here in certain cases.
|
| What exactly are those privacy reasons? And by custom icon for
| input field is meant replacing the cursor with e.g. an svg?
| AlienRobot wrote:
| The only thing I can imagine is if they are third-party icons?
| I don't understand it either.
| alex-e-leon wrote:
| The issue is that css doesnt allow adding pseudo elements
| (:before/after) to input fields, making adding icons to an
| input a little trickier than with other elements.
| ninetyninenine wrote:
| Css is a garbage api. Styling things should not be this hard. We
| are stuck with it because of tech debt. That's most of web
| technology today.
___________________________________________________________________
(page generated 2025-03-02 23:01 UTC)