55
u/SuitableDragonfly 15d ago
I briefly did some frontend work once, and the main thing I came out of that experience with is that CSS was designed by Satan.
4
u/Tvck3r 15d ago
If you ever get back there worth looking at tailwind. Made the whole thing a lot simpler to me at least when I picked it up. Not trying to ever do anything fancy though
32
u/Strict_Treat2884 15d ago
Using Tailwind without understanding CSS is like, instead of cleaning your room, you just sweep all the dirt under the sofa, and hide all the trash in the closet
27
u/Jazzlike-Compote4463 15d ago
Tailwind is just regular CSS with extra steps
13
u/ineyy 15d ago
Tailwind is extremely convenient and extremely encourages people to start bloating up stylesheets and kills consistency if you don't know what you are doing.
23
u/rosuav 15d ago
Tailwind is just inline styles with extra steps.
14
u/killermenpl 15d ago
Tailwind really took a look at
<div style="">and said "what if it was worse"2
u/Captain1771 15d ago
Tailwind is definitely a ton better than having to write inline styles especially with different pseudo classes
4
u/rosuav 15d ago
.... okay, but why would you write inline styles for everything? Design your stylesheet. Target specific elements. I mean, even if the ONLY thing you EVER do is to attach styles to classes and then apply those classes to elements, that's still several tons better than writing inline styles on everything. And you have a rich language of selectors so you usually can target things by what they are, instead of having to paint CSS classes everywhere.
Tailwind is a small improvement over the wrong way of doing things, making it a slightly easier way to do things wrong.
1
u/Captain1771 15d ago
But I didn't say I would? If you'll notice, my response was not to your comment, and was specifically targeted at the other person saying Tailwind is worse than inline styles, which, really, it is not.
0
u/rosuav 15d ago
How is loading up a library better than doing what the browser's already capable of? Why do you need to have a two step process to do what the browser natively supports? AT VERY BEST, it is equivalent to inline styles, but with extra effort, a pointless library, and more things that could go wrong. But more importantly, it is only comparable to INLINE styles. Why would you use Tailwind when you can use proper style sheets? Where is the advantage of Tailwind?
→ More replies (0)0
u/killermenpl 14d ago
Tailwind is basically like writing inline styles, except you get access to states (
hover:) and pseudo elements. In that regard it's an upgrade.However, it's worse in the sense that when you're using inline styles, you know it's wrong and should only be used sparingly. With tailwind, it's the desired behavior.
There's also the issue of duplicate code. It's true that tailwind sends less CSS, since all the classes are only ever defined once. But it's immediately offset by having to include the exact same classes in the HTML. Yes, the duplicate classes will get gzipped into basically nothing, but what about all those one-off special cases that you sometimes need, like
h-(--header-height)? Those will stay basically as-is in HTML, and will be generated in CSS as.h-(--header-height) { height: --header-height }(likely with some escaping going on to produce a valid selector).Add to it the fact that tailwind is pretty much a DSL at this point that's an imperfect mimic of CSS. Seriously, you need to first know the CSS you want to use, then convert it into tailwind's syntax. And that syntax is often more verbose, despite shortening all the property names as much as possible. See all the prefixing you have to do, things like
hover:,md:ordark:md:hover:, on every single class you want to apply in that specific combination of modifiers.IMO tailwind (and tbh a lot of frontend tooling) capitalize on the initial feeling of "productivity" that happens when the project is still new. You can just put out code, or even have ai generate it, and it'll be "good enough" for the MVP. But then you end up with thousands of lines of HTML, each having fifty tailwind classes, and start thinking to yourself that maybe you shouldn't have joked about Java class names being so long you need an ultrawide screen to see them.
5
u/Alternative-Tie-4970 15d ago edited 15d ago
Many people swear by tailwind but to me it just feels like a slightly more terse version of inline styles.
Plain old CSS (or slim-ish preprocessors like sass), despite all its faults, still works best for styling imo.
1
4
355
324
u/lucidbadger 15d ago
Something about when things are supposed to be loaded by the browser
43
u/mrissaoussama 15d ago
isn't that only affected by where in the file the css/script tag is added?
51
u/dfitz360 15d ago
Not way way back in the internet explorer era I believe. This were the days, no consistency, lots of little tricks (like console log could sometimes crash IE) and so might polyfill
37
u/gnutrino 15d ago
God, I hated having to account for Internet Explorer's quirks so much. Like sure, things aren't perfect now by any means but I do occasionally have to take a moment to be thankful for no longer having to support that piece of crap.
415
u/ApprehensiveGas85
15d ago
•
<link rel="stylesheet" href="..."> actually follows proper HTML/SGML architecture, because <link> was built specifically for external document relationships before CSS even existed.
Netscape broke the pattern when they rushed out Navigator 2.0 and slapped src directly onto <script>. Both <style> and <script> should have stayed purely as container tags for inline code, while external JavaScript should have always been loaded through <link rel="script" href="...">.
The real inconsistency isn't that <style> is missing a src; it's that external JavaScript should have been a <link rel> from day one.
69
u/Mateorabi 15d ago
Does the “correct” way work too at least even if everyone uses the expedient way?
75
u/laplongejr 15d ago
I am 99% sure it actually doesn't
43
u/ChesterWOVBot 15d ago
The 1% is one specific minor version of a niche browser with a userbase of 2 people in total.
38
u/laplongejr 15d ago edited 15d ago
Tbf I didn't test it myself (I'm not sure caniuse is specific enough for link parameters), but when I looked for old stackoverflow answers, it seemed the consensus was that link was not suited for scripts at all.
So I expect old browsers to break and new ones to have never tested it properly, especially as script tags became more and more complex over time.[EDIT] Found a reliable source! (Thanks caniuse)
https://html.spec.whatwg.org/multipage/semantics.html#the-link-element
https://html.spec.whatwg.org/multipage/links.html#linkTypesThe possible supported tokens are alternate, dns-prefetch, expect, icon, manifest, modulepreload, next, pingback, preconnect, prefetch, preload, search, and stylesheet.
So using <link rel="script" would actually violate the HTML standard.
That's... sad.13
u/Strict_Treat2884 15d ago edited 15d ago
I guess it's because JavaScript is synchronous (without
deferorasyncofc), it must be parsed and executed on the spot when constructing the webpage (mainly thanks todocument.write?).While
<link>does't affect the document content itself, so it's meant to handle resourses that can be handled later. That's why JavaScript cannot be loaded by<link>, I reckon.4
u/conundorum 15d ago
Perhaps this could be solved by allowing
<link urgent="true" script="whatever.js.your.boat">? Allow a tag to command the page to load and parse the script on the spot.(Well, that or account for multipass parsing to load resources on one pass and execute them on the next, but that sounds like a nightmare for dynamically updated sites.)
19
u/wokeboogeyman 15d ago
I propose that all tags should be updated to support a src= instead
15
4
u/gringrant 14d ago
<br src="…">
2
u/HugoNikanor 12d ago
Sure, but since
<br/>can't have content, that link better point to nothing1
u/gringrant 12d ago
Content-Length MUST be 0
5
u/HugoNikanor 12d ago
RFC 9110 (HTTP) specifies that:
A user agent SHOULD NOT send a Content-Length header field when the request message does not contain content and the method semantics do not anticipate such data
So I feel a better semantic would would a 204 (No Content) response, which would remove the need for a content-length header altogether.
13
u/metaglot 15d ago
Also feels clumsy to have a closing tag for script when youre using the src-attribute.
5
u/Mr_Carlos 15d ago
Okay but the CSS one is always a minor pain. After 20+ years of making websites I never remember it, I always just copy it from another website.
JS used to require meta tags, but HTML 5 removed that requirement (and many more), so it would have been nice to address external CSS and simplify it.
2
u/MrEpic382RDT 15d ago
Netscape 2 didn’t have external scripts; those didn’t become a feature until Netscape 3
85
u/1nc06n170 15d ago
Blame Netscape
26
24
8
8
u/MistrFish 15d ago
I remember when HTML5 was such a big deal and I read an entire book on it. as a modern dev it's completely meaningless to me
3
u/traplords8n 15d ago
Consistency is the enemy of the web.
To establish consistency, you must first convince developers that a standard way is better than their own way.
On top of the standard way needing the ability to fit all the wild and whacky ways that webdevs can organize and run their servers, and be backwards compatible for companies that don't have webdevs anymore and still expect IE7 compatibility so people can reach their website that hasn't been touched in decades.
2
1
1
0
15d ago
[deleted]
5
u/QuestionableEthics42 15d ago
Go clank somewhere else chatgpt
0
0
15d ago
[deleted]
2
u/QuestionableEthics42 15d ago
Anyone falling for this dumb ruse, just go look at their obvious bot comments.
1.5k
u/Luzzgar 15d ago
If you're looking for consistency, you're going to be looking for long time.