This just makes my eyes bleed. CSS-in-JS was bad enough but now you want to mix-in SASS and Tailwind? Is there a prize or something for the number of technologies which can be squeezed into a line of JS? Please stop it.
Your opinion that CSS-in-JS is bad is just your opinion. Styled-components can do everything sass/less/postcss can and more, you don't need random binaries installed globally to transpile it to css when building, you get theming for free, it is easier to understand because you can ditch the arbitrary mappings of state variables to css classes, and even get types, it works with SSR and promotes one-file-components which is heavily used in Vue. Oh, you can even extend css syntax to fix small annoyances or add features.
I have been doing frontend dev for nearly 20 years and CSS in JS has always struck me as completely unnecessary. I have yet to see a need for any of it that doesn't introduce more problems than it solves. Do you have any examples of cases where it is needed? Im using SCSS with SSR super well. I dont get why JSS in CSS is seen as superior?
Styled components are basically html element + dynamically generated class, you get scoping for free (you'd have to use css-modules for that otherwise), and you can define custom props and dynamically modify that component's style. This is extremely useful because one pattern I use frequently is element that has a lot of different modifiers like isSelected or isDeleted, in css you need to define classes for each, but here you just don't return some styles if the prop is not set. You also get full typechecking with typescript for all components, their props and theme. You also get autoprefixer out-of-the-box, and as a bonus if you ever wanted to lazy-load parts of your app, the styles for it should tree-shake correctly without any modifications, unlike traditional css.
I fundamentally disagree with your point that CSS-in-JS is a result of developers not knowing CSS. That's ridiculous
CSS-in-JS solves a lot of problems that people that have been writing 'real CSS' have been experiencing for a long time. Writing CSS for very large applications that deal with lots of shared components across engineering teams is a hard task. Some of those problems are alleviated by libraries like styled-components.
It's not for every use case and should only be used when there is a genuine need (rather than 'because it's shiny.') But shrugging off CSS-in-JS because you don't understand it is a bit silly.
Excuse the French, but all the CSS libraries are bad because CSS itself is shit. Defending it is the classic textbook definition of Stockholm Syndrome. It is awful, disgusting, incredibly wrong and inflexible for the modern use case.
Care to explain your issues with CSS in detail? I agree it's Stockholm's, but just never can't even begin to state all the things that are wrong with it without sinking into Tech Tourette (ok for me the original sin is that it started by redundantly defining properties and syntax when we had this already in the form of HTML attributes; in which world did that ever make sense?)
- css is not scoped by default. Predicting the effect of adding a new rule is very hard if you are not using scoping solutions or if you are not constently writing new class names with a strict convention
- because of the first point, css is never refactored in most places. It becomes an ever growing monster of a code base
- css selectors are build to write css that depends on html. A lot of webapp should be writing html that depends on a small set of css rules in order to get a consistent ui
Ah I see you're coming from a webapp developer PoV. In that case, I just wouldn't bother with CSS at all as you've got all the dynamics in your hand anyway to set styles as you please. Except pseudo-classes (even hovers), media queries, transitions/keyframes can't be specified in inline style attributes - just one of the many CSS blunders.
Personally, I'm more interested in HTML as a document format in the original sense. Limited as it is, I just can't fathom the blackout moment where, confronted with a very basic HTML document plus a CSS stylesheet about the same size or more written in a completely different yet redundant syntax, somebody would say "yup, that seems like a reasonable document format for exchanging most of the world's text".
Edit: regarding your scoping requirement, isn't just including the id or class of a component in CSS selectors or, when necessary, sass-like nested CSS rules enough of a scoping mechanism?
Why are there trends in software development? Are we trying to solve problems or we're trying to be trendy? Is this a clothing industry?
I would have thought we should use mature technologies that have been vetted and gone through the trough of disillusionment and onto the ramp of productivity. Proven tech stack that I can rely on gives me peace. Older the tech, the more reliable it is.
The opposite of "trendy" is what we need to popularize and make it cool. It should be cool to use a 5 year old library in JS!
How does a technology become mature if no one wants to test it? I get your point, but we need both type of people in the real world: cutting-edge tech enthusiasts and stable products users. The problem is not that some people try out some fancy new tool, it's that they try it at work and waste lots of money without even being worried about it because it's not theirs. But in few cases it also pays off.
When there is change, there are trends. You don't have to follow them, but some are working on what they think are improvements and others are interested in staying updated on them. Be it novel programming languages or javascript libraries.
It is cool to use 5 year old JS projects like React. If you look at the projects listed in the report, you see the graphs going back to 2016. Which is 5 years ago. And how they have been popular for 5 years.
The loaded script appears to be some free geoip/country detection service, that as a side effect, also does maxmind.com/en/solutions/minfraud-services/device-tracking - unsure what it's used for but it's probably for giving a single page app access to language or country by geo
If you want types for everything, twin+styled-components is going to have more type coverage by definition. Also, redux-toolkit is pretty good for minimal effort fully typed redux.
Jeez, you’d think you were on Reddit with all these comments.
Like it or not, Tailwind (and things that help people use Tailwind) serves a very valid niche. Unwrapping years of legacy CSS, intertwined with CSS injection in jQuery, is no simple feat. Adding Tailwind to that project and only writing Tailwind has helped immensely.
The downside is that there are times when you have a really long list of classes on a given tag, which can be difficult to read and parse. I’m not sure if this tool is right for me or my team, but that’s one use case I could see for using it.
Are we really complaining about emojis in READMEs nowadays? Good grief.
I am saddened by all the negativity around those new css approach.
I like most HN threads but anything frontend is laughed at by people with little frontend experience. They repeat some truth they learned 20 years ago.
Honestly HN is not a good place to discuss frontend stuff. You will only see "get off my lawn" kind of comments.
I posted a negative comment here (look it up), and I can explain why I still believe my comment is constructive, and why I don't think I fit in "people with little frontend experience". It's not an appeal to authority, but more a rebuttal of you affirmation that HN is full of "non frontend people"
1. I have a passion for front end, I have a PhD in Human Computer Interaction.
3. I am the cofounder and CTO of a company whose main product is based on CSS-in-JS (Emotion, Chakra UI)
2. I really like Tailwind and used it on several production projects.
4. So I know very well both of these approaches. I know their advantages and drawbacks.
5. In my comment I state the sad truth about this particular project: It combines the worst of both approaches in terms of performance, without any added value as compared to these approaches. Slow build AND slow runtime, without any added modularity.
This approach is objectively bad and this is why people react like this.
And to be constructive: If you want to use tailwind, use tailwind and you will have performant runtime but less
customizability. If you want to use CSS-in-JS, use it and you will have customizability, but slower runtime. Engineering is trade-offs, but twin is still the worst of both worlds.
Your comment is completely valid. I am just reacting to the usual flow of hate toward any frontend library that do not follow the initial ways of the early days of html/js/css.
I agree on that actually, I’m generally annoyed by these HN comments like « this JS lib is shit because it’s more than 12kb, and why do you need JS anyway »
You can combine together theses classes in another class name for reusability. I've been doing CSS for 15 years and I love tailwind. It's just a bunch of handful predefined classes but they encourage you to write everything in small, single-purposed classes that you combine together.
You can absolutely do that with CSS (and some people probably did for years), but having theses classes already available kind of shows you the way.
Slow at bundle time like tailwind, AND slow at runtime like css in js. I don’t get these tools, the whole point of tailwind for me is the runtime performance combined with high flexibility! Twin is the worst of both worlds.
I'd be interested in a description of the actual real-world benefits the "magic of Tailwind" and the "flexibility of CSS-in-JS" provide. I've only just started trying to understand what concrete advantages Tailwind brings [1], but as I understood it, one of its advantages is that it's not CSS-in-JS. Because it's not necessary: CSS-in-JS prevents styles from one component leaking into another, but Tailwind classes already only apply to the element they are added to.
I'm not ready to dismiss new initiatives off the bat (if anything they can at least be a good learning experience), but I'd like more concrete terms than "magic" and "flexibility" to help me understand the potential benefits.
Right, I'm roughly familiar with that (see the linked Twitter thread), but I'd be interested to know what the author's view of their benefits are, and how this project provides them in a way that either independently does not.
(And potentially also: what are their downsides, and does this project suffer from them as well?)
Ah sorry, I worded that incorrectly. Should've been "the styles defined via Tailwind classes already only apply to the element they are added to."
(Ninja edit:) So to clarify: if I want to add some padding to an element with plain CSS, I have to think of a class name for that element, and then define styles for that class. However, if I happen to use that class name elsewhere in my code, then the styles I've defined there suddenly apply to that element as well. And vice versa: before I can delete a class from my code base, I have to be aware of every element that uses it.
CSS-in-JS solves that: all styles defined for a single component will only ever apply to that component.
The same holds true for Tailwind: you define the styles through the classes you apply, which will not affect other components in your codebase, and likewise, removing them (the Tailwind classes) is safe as well.
So. The readme doesn’t mention React. As far as I can tell it’s not because it’s compatible with everything. Looks more like it’s the “Fish don’t know they’re in water” phenomenon. The author just assumes that the reader will assume that everything is for React only. (I might be wrong! The readme really doesn’t make it clear either way)
One of the nice things about Tailwind is that it’s completely portable, because it’s ”just” CSS. You can use the exact same design system regardless of how your markup ends up on the screen, as long as you can set a class attribute.
Already at version 2, but has breaking changes? Check
Stacking up on yet-to-be-proven-framework (tailwind)? Check
We just need a BLM support message, donation link in the npm install stdout and some more JS shenanigans like support for yarn, gulp, webpack, npx, degit, and the next gen packaging tool soon™ to be released.
Sorry if this is offensive, but this ecosystem offends me and my sanity. This project is going to last 6 months and they'll move onto something else. I think I am finally ready to jump on React since it has been a few years and appears to be stable.
I am not attacking any individual developer or project here, but in recent times, there's been a trend I've been observing and what you're pointing out. I call it the Hipster Driven Development phenomena* and it's just getting worse with every year. People just start by discarding established best practices in the name of being unique and cool and then wind up to the inevitable conclusion - the established best practices were there for a reason.
There's been many such trends to name a few - discarding years worth of stable codebases to try out some shiny new framework, throw away proven technologies to trade for some perceived developer convenience (Eg. PostgreSQL to MongoDB), labeling known terminologies to sound cool (Hacker vs Growth 'Hacker'). All these hipster moves come with a huge cost - they cost morale, time, money, teams, relationships. It just feels so unnatural to accept this as the norm.
In comparison, I just feel like some old dude from the 1950s rambling though these things have started to happen only the last half of the decade or so. Where did we go wrong?
I was with you for the first two paragraphs, but I feel you invalidate everything you said by pretending separation of technologies and separation of concerns are equivalent. That reeks of dogmatism more than anything else.
Its funny that you mention that. After Eich was forced to quit, I've been noticing that everything related to client-side development is highly influenced by liberal mindsets, many of which are also political. I'm also a minority, but I don't want (even if I need) anybody advocating for me.
Of course, both you and me are going to be downvoted because these types oppose (downvote, "cancel") anyone who mentions their presence.
Thanks for hipster driven development then. Frontend development - or really any software environment - would be very sad if everyone was scared to try something new or mix exiting ideas when a field seems to be already saturated by an established framework.
Agree, an interesting observation! I wonder: Junior developers nowadays who learn JS and React as their first, go-to stack for web development, they haven't ever experienced the raw productivity of "just write php and upload it via ftp" or "just write it in rails/django and render stuff server-side".
They come to expect that all development is as slow as theirs, including frontend <--> backend apis (graphql), huge js complexity (webpack), breaking changes (react-router), etc.
I see lots of companies nowadays wanting to hire "React devs". It seems we're collectively forgetting how fast you can ship stuff if you just use proven technology. Makes me wonder where we're headed.
Maybe it'll be a competitive advantage to use old (= proven) technology in the future?
Sorry to burst your bubble but Tailwind is anything but "yet-to-be-proven-framework". It is a very solid and powerful abstraction that has existed for 3 years.
Speaking of piles of abstractions, please enlighten me. What is not a pile of abstraction today? Even x86 instructions are implemented with microcode.
Speaking of tests, anyone with some frontend experience will recognize that jest is a testing library.
I would say that your comment is the epitom of a HN frontend thread ie mean criticism by someone with 0 experience in the field.
Tailwind’s entire premise stands on these pillars which are shaky at best:
- Developers don’t want to write css so they add insane amounts of nuisance in templates. Impossible to read the design language.
- The original author of Tailwind complains about naming classes in the css but Tailwind ironically names things that are “tx—-bb-4-2” or whatever the hell that means. No thanks, I’ll write “customer-support-card” or something useful. Maybe even more generic - “card”.
- Tailwind’s front page is everything that’s wrong with this. Moving around components with “mr-4” tags and shifting it up. Left. Right. Making it larger. That means that there is no standardized design language and you’ll create design that will have no cohesive unity. One component will have “mr-4” margin and another “mr-3”.
We have the technology. Sass can create compositional components with reusability and logical hierarchy. There is no need for this Tailwind nonsense.
Tailwind is a controversial project, not mature. It’s proponents think that others just don’t get it. No, we do. We’ve used it and it makes it very fast to get something working but that’s more telling about one’s inability to take the time to think about layout/design and writing proper sass.
There’s a new wave of thought in design called “design tokens” where you have a set of predefined values that are considered valid as part of the design, e.g. a website can only have spacing of 4px, 8px, 16px, etc.
One component having mr-4 and another having mr-3 is chill if that was the designer’s intention. If not, then it should be picked up during design review and easily fixed (since you end up really only having to pick from like a few values).
I would argue the main point would be you can rapidly build interfaces... like really fast. I worked on a proposal for a client using Tailwind a month ago and we smashed out a whole website in a week. We ended up "extracting components" like buttons and cards and stuff that we found was being reused a lot (kinda like Sass).
As opposed to Styled-Components, the Tailwind classes are very valuable for designers who want to prototype live in the browser.
Also, you were complaining before about design consistency but I would argue that Tailwind allows for very high design consistency. I work with armies of outsourced developers of varying skillsets and I honestly don't trust a lot of them to write clean CSS at all. With Tailwind and Tailwind design tokens, the army of outsource developers are encouraged to work with the design tokens (as opposed to yolo'ing 3px !important everywhere).
I think you might be misinterpreting Tailwind's "pillars":
> - Developers don’t want to write css so they add insane amounts of nuisance in templates. Impossible to read the design language.
It's not so much that developers don't want to write CSS, but that it's largely impossible to delete lines of CSS.
> - The original author of Tailwind complains about naming classes in the css but Tailwind ironically names things that are “tx—-bb-4-2” or whatever the hell that means. No thanks, I’ll write “customer-support-card” or something useful. Maybe even more generic - “card”.
So those are different complaints about naming. Your complain is that names are hard to understand. Tailwind's complaint is that trying to define "generic" (i.e. reusable) classes is practically impossible. Is "card" the right abstraction? Is "customer-support-card"?
> - Tailwind’s front page is everything that’s wrong with this. Moving around components with “mr-4” tags and shifting it up. Left. Right. Making it larger. That means that there is no standardized design language and you’ll create design that will have no cohesive unity. One component will have “mr-4” margin and another “mr-3”.
The idea is that all those margins are part of a set of "constraints" that all compose well together to form a cohesive unity. More about this is written here: https://styled-system.com/guides/why-powers-of-two
> We have the technology. Sass can create compositional components with reusability and logical hierarchy.
This might be the main point: Tailwind means you're not defining reusable styles. All the styles are specific to the component, and the component is the thing you reuse - which we were defining already. So it actually gets rid of yet another tool to create compositional components with reusability and logical hierarchy.
(It's less fast for me to get to something working than e.g. using Bulma is, but I'm expecting that it will rid me of a number of the pains I run to when I'm hitting the limits of its built-in component styles.)
I get the compositional aspects of it. I've used similar utility css classes. They're pretty nifty because its instant gratification. No need to switch context and go to Sass.
However, for production, I always come back and refactor everything into a beautiful Sass file that explains with comments what all the stuff is doing.
Now, the designer can come in and change something in the sass without having to worry about the rest of the app. They can easily debug too 'customer-support-class' straight from chrome browser.
I feel like Tailwind is a prototyping tool that's then shoehorned into production environment and in large applications where the design language (despite of tokens and standards) breaks down.
I definitely see how that workflow works better in your setup, but... That doesn't apply to everyone? Not everyone works somewhere where they have an independent designer that can and will change the actual SASS, whereas others might even have designers that a perfectly comfortable rummaging around in e.g. JSX or Vue components. The indirection of a separate SASS file might not be worth it in those cases.
All of which is to say: just because it's not the best solution in your use case, that doesn't mean it doesn't solve actual problems for others in production.
So you’re just writing your HTML twice, essentially. You can’t change your HTML without changing your CSS, so at that point, what’s the point in writing the CSS? May as well just add the styles right on the HTML.
They’re both fundamentally just part of how it looks, and I don’t see a lot of benefit in trying to keep that separate.
Everyone hates Tailwind before they use it. None of your criticisms are new. Actually using Tailwind makes you realize that creating CSS classes for your components is basically a waste, since you only ever use them in the component itself.
- Unless the same class can be used in multiple HTML templates, there’s no point in giving the class a name.
- Only very general CSS can be used in multiple templates because anything specific will have the brittle base class problem.
PS mr-3 is .75rem and mr-4 is 1rem, so you can see with your eyeballs if you’re using the wrong one.
My experience teaches me that everything born for "fast prototyping" is going to temporary stay for years to come. So tailwind, like bootstrap, just moves the problem from css to html class attribute.
>- Developers don’t want to write css so they add insane amounts of nuisance in templates. Impossible to read the design language.
I don't think this premise is very shaky, unfortunately, if it was shaky I doubt we would be seeing all these solutions coming around trying to help developers avoid writing css, solutions which seem to have uptake in the market.
With tailwind you can create a very small configuration files where you pick a small set of available options for spacing and colors. This is actually a big help to implement a consistent design system. Many people see tailwindcss as a "design system builder".
Please show me the doc for "tx—-bb-4-2". Does it exist or are you just inventing it for some reason? Is "mr-2" unclear?
Sass has nothing to do with tailwind. It would be like comparing typescript and react.
Tailwind can be controversial and mature at the same time. Both things are not exclusive. PHP is controversial and mature.
I don't know about other people but in your particular case I would say that you are showing sign of a knee-jerk reactions and bad faith justifications.
Yikes, my bad. I didn't see a test folder. I am just learning JS coming from an enterprise Java background. We've got our own pile of shenanigans as well, probably just as bad as the JS world, don't worry!
Ok, I am done with this. Anyone wanna start a tea shop in a small town in Asia? I am down. We can bootstrap it, live a simpler life and mingle with the locals. May be even create a little ordering system, postgres v9 in the backend, running on a dingy moth balled Dell PC under the cash register and use jQuery frontend, of course limited to 1024x768 resolution monitor from Compaq with a broken power button.
I picked up a React Native project for next year and am sort of terrified of what I might find jumping back into the world of JS after some time away from it.
A number of JavaScript projects have put support messages for the Black Lives Matter movement into the top of their README or home pages. I think it’s an excellent thing, personally.
Autist here. I see this with so much human behaviour. Often the purpose seems not to be actual measurable progress but rather social signalling. I suppose it serves a social purpose, perhaps it is a precursor to material change. I feel it is important to remember that humans are tribal apes. If we deny our nature, it is much harder to overcome.