Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tailwind vs. Semantic CSS

nuejs.org

Post reply on HN
Print view View original

131–140 of 211 posts

Re: Tailwind vs. Semantic CSS

#131

Post by progx »

k4runa wrote: post #50
progx wrote: post #18

Earlier quoted context omitted.

But who really work like this? The most people and company would not do this extra work and use tailwind for finished products too.

I figure most startups would build an MVP in two weeks and then rebuilt it later or move onto the next version and clean it up a bit in each version that follows.

Never change a running system. If you create a working project, you will not change it, especially a startup.

Possible on a later bigger update (if necessary), a complete app would be rebuild. But here is the same problem: why should you do it, if your project works?

I personally had not seen such an update in early stage of a startup. Did somebody have insights or examples?

Re: Tailwind vs. Semantic CSS

#132

Post by progx »

foldr wrote: post #74
romanovcode wrote: post #40

Earlier quoted context omitted.

Exactly. This is a non-issue if you use @apply (as people should).

But if you make extensive use of @apply then you're just writing normal CSS with an unnecessary preprocessing step.

That is the point. As long as you use tailwind as it is, it works good and you can have fast results.

But with reusable components or unified design, you enter the @apply hell. At this point i could not see benefits of tailwind.

Re: Tailwind vs. Semantic CSS

#133

Post by progx »

jonwinstanley wrote: post #89
jongjong wrote: post #85

This perfectly summarizes what I've been saying. Popular tools are not the most effective ones. The people who are leading our current tech monoculture are not qualified to be making such decisions and imposing them on such large numbers of people. The artificiality of our current tech culture is obvious. It doesn't feel organic, not free market.

Presumably tools only get popular if people find them useful though? As in, if no-one saw value in them then no-one would use them?

People normally use not the best things, they use things they understand.

Then they are so happy, that they understand it, they write blog article about it, other read it and think "it must be a good thing", then more and more use it.

And if more people use it, other think "it must be a good thing, cause many use it". Self runner.

Re: Tailwind vs. Semantic CSS

#134

Post by skydhash »

HelloNurse wrote: post #126
sbergot wrote: post #111

Earlier quoted context omitted.

The issue of this direction is if you need to update the markup, you will need to update the css, which is hard and risky because of css global scoping.

New and updated CSS rules should be usually needed for new "themes", exactly the type of change that semantic markup is robust against (e.g. placing image captions in a sidebar rather than below the respective images), and for backwards compatible extensions of the original design that add support for something new that will only be used in new markup in new pages (e.g. allowing small images inside paragraphs, meant…

> What kind of fragile markup and problematic CSS global rules are you worrying about?

I’m wondering that too. If I’m writing a SPA, styles are usually scopped to the component with a base styles for UI atomic elements. And some conventions around spacing. If it’s a website, it will be separated in layouts and small components Bootstrap-like. An update will be identified as a variant or a special case.

As for coding this, search all files is usually a godsend when refactoring. You can use ripgrep if the editor does not have a good implementation.

Re: Tailwind vs. Semantic CSS

#135

Post by tipiirai »

Loeffelmann wrote: post #115
tipiirai wrote: post #99

Earlier quoted context omitted.

Tailwind example indeed does more, but only slightly. Would increase the size of CSS by 1-3%. The semantic version has clearly enough to prove the point the article attempts to make: significantly less code is needed and the resulting site is leaner & faster.

If you really want to compare code snippet sizes, you must offer the same functionality. Otherwise, the comparison is meaningless. You did the exact same thing before when you compared the Headless UI combobox with your nue.js implementation. Offering fewer features will result in less code. Shocker. Besides, I don't really care for these comparisons. If something is 2x longer code but more maintainable, it is 100% w…

I'm sure most developers can see the bigger picture with a 95-99% a implementation.

Re: Tailwind vs. Semantic CSS

#136

Post by tipiirai »

maciekpaprocki wrote: post #119

This article is a bit bs. the first example of how much code it requires is misleading. you can accomplish this same thing with exactly this same amount of html nodes. You just gonna have more classes. Calling tailwind tightly coupled Vs semantic loosely coupled is also a bit of strange. I would call it composition over inheritance.

I sugest you look for the bigger picture on the article and the baggage you get when using Tailwind.

Re: Tailwind vs. Semantic CSS

#137

Post by pas »

sbergot wrote: post #38
gherkinnn wrote: post #5

This is one of the first Tailwind vs * articles that isn't bad. It makes a good case in the analysis. For a lot of applications (like a blog), what the author calls "semantic CSS" is the right thing to do. But there comes a point at which it is no longer feasible. We have a long history of SMACSS, object oriented CSS, BEM, CSS Modules, scoped CSS, and now Tailwind to make it work. > Because mastering CSS requires pra…

No this article is flawed. It fails to recognize the fact that css and html are always coupled in one direction or another. With tailwind the css is fixed and the html is designed around it. With semantic the html is first created and then you write your css around it. The fact is that updating css in a big project and a big team is very difficult. Rules are scoped globally. It only takes a junior making a few design…

> Rules are scoped globally.

Isn't "CSS scoped to components" nowadays a basic feature of frameworks?

Re: Tailwind vs. Semantic CSS

#138

Post by Loeffelmann »

tipiirai wrote: post #135
Loeffelmann wrote: post #115

Earlier quoted context omitted.

If you really want to compare code snippet sizes, you must offer the same functionality. Otherwise, the comparison is meaningless. You did the exact same thing before when you compared the Headless UI combobox with your nue.js implementation. Offering fewer features will result in less code. Shocker. Besides, I don't really care for these comparisons. If something is 2x longer code but more maintainable, it is 100% w…

I'm sure most developers can see the bigger picture with a 95-99% a implementation.

Features that look easy to implement and are not a big deal can turn out to be massive problems and require a large amount of code to actually pull of. I would, in some cases, count responsiveness to be one of those things. Stuff like that may seem like 5% of the functionality but actually makes up a large chunk of the code. This is why you must always have feature parity if you really want to compare code size.

Re: Tailwind vs. Semantic CSS

#139

Post by d1sxeyes »

willdr wrote: post #75
romanovcode wrote: post #40

Earlier quoted context omitted.

Exactly. This is a non-issue if you use @apply (as people should).

@apply is an antipattern.

Hm. @apply solves a problem. Basically you’re better off writing with the utility classes if you can extract your component out to… well, a component. If for whatever reason you can’t do that, @apply helps you avoid repeating yourself, which seems to be a reasonably good alternative to what’s in TFA.

But there are other (better) options available in most circumstances. Tailwind actually have a pretty good write up here:

https://tailwindcss.com/docs/reusing-styles

That said, it’s easy to come up with a ‘gist’ like

> The semantic version is 8 × smaller, renders faster, and is easier to modify and extend.

but then underneath say you’re not minifying, and you’re not publishing the source code… it’s almost like the author had the conclusion before starting to experiment.

Re: Tailwind vs. Semantic CSS

#140

Post by tipiirai »

tipiirai wrote: post #135
Loeffelmann wrote: post #115

Earlier quoted context omitted.

If you really want to compare code snippet sizes, you must offer the same functionality. Otherwise, the comparison is meaningless. You did the exact same thing before when you compared the Headless UI combobox with your nue.js implementation. Offering fewer features will result in less code. Shocker. Besides, I don't really care for these comparisons. If something is 2x longer code but more maintainable, it is 100% w…

I'm sure most developers can see the bigger picture with a 95-99% a implementation.

I know what you are talking about. Projects tend to slow down at the end of it. But responsiveness is not one of those things, at least on this project. My honest guess is 3%, the menu being the biggest piece. It can also be lazily loaded so that it doesn't increase the amount of primary CSS. Just like the dark mode was implemented.

Having said that, I promise 100% feature parity on my next article. Thanks for the heads up!

Post reply on HN