Live data from Hacker News

Shopify acquires Tailwind

tailwindcss.com

371–380 of 406 posts

Re: Shopify acquires Tailwind

#371

Earlier quoted context omitted.

It found its place because working on CSS on any non-trivial scale with multiple engineers is painful. The best way to deal with CSS at scale is not to write CSS. And this comes from me who really likes CSS.

CSS was prob great for early web but now it's just a pig with lipstick on

CSS is one of my favourite things to do and still is. However, most engineers don't really understand it because most engineers don't really bother learning anything, and as a result you typically end up with a mess.

If someone knows what they are doing and is allowed to make a decent UI library, you can have very clean, efficient styling without libs.

Re: Shopify acquires Tailwind

#374
post #42

Serious question: is there a need to reach for tailwind if you are building a new site? Won't using vanilla CSS while taking advantage of the latest features be pretty good, since humans are not manually making edits (which removes many of the pain points of maintaining CSS), while simplifying dependency and the build pipeline?

If it's the case that there's almost never the need to reach for it, and I do find myself in that camp, then a harder question is begged, why is it so popular?

I think there's a lot of technologies that are in the category of categoric mistakes to use, but popular enough and inert enough that they don't get dropped. There might be lots of different explanations depending on the technology, a lot have a reason the moment they are released.

Many third party tech becomes de facto standard at some era, then those features get incorporated into more mainstream tooling like browser css, and at that point the third party tooling exists only because of inertia and adds little value, but increasing supply chain and complexity risk.

Another example on this category is Axios which was essentially a cleaner DX for XMLHTTPRequests in client side javascript before Fetch, and later a polyfill for it. Nowadays it's a blunder to include it, but it ended up in stackoverflow answers and training sets, so it's "safe" to include. Developers that are on the bleeding edge drop it, but those that are catching up and reading tutorials or classes from the previous era, or using llms, use the previous era cutting edge technique, because they aren't evaluating all the parameters of a choice, they are just going with whatever someone else is using, which causes a coalescing around certain central technologies like React, Kafka, Redis.

Regarding Redis, my understanding is that it was popular during one era where databases were used to store state because we didn't know any better and people were moving fast and breaking things, so it was developed as a sort of hack to move things from a database into memory. But nowadays people just use it wherever (because it really is the most blank microservice you can think of, you can slap it anywhere), and people implement it off the bat.

There's lots of more specific reasons why bad third party deps persist. In python there's a library called python-dotenv, which is a categorical mistake to include, but people do it because they come from Node where it is a standard practice. But there's the standard nuance that in Node, it is a built in, but in python it is a third party dependency from a random dev (no offense to the dep dev, only to the users of the dep). It literally is replaceable by calling Open(), write(), and close(), but there it is with a lot of downloads waiting for the day it is targetted and hacked to capture millions of .env files. Personally to me it would be strike 1 of 2 if someone imports it, but there you go.

Yes, there's no reason to import tailwind, it adds nothing, the idea of:

red-color { color: red}

big-text { font-size: 14px}

Is as laughably low quality, the application of a technique in form but not substance, similar to Getters and setters in Java, effectively making every property of a class public, but formally implementing the private keyword and access through functions. 100% a categoric mistake to implement.

I've written elsewhere of a phenomenon where devs avoid lerning a base technology, and rather end up learning a tech on a higher abstraction that ends up being a 1-for-1 of the lower tech, but it gave them the hope that they could avoid doing that learning, and they only drop into that realization by piecemeal ala "we did it not because it was easy, but because we thought it would be easy", and the only cost is that they learned the non-portable version of that technology and now they are vendor-locked professionally into that technology so they will spread it to the next repo, company, job posting and so on.

There's analogues in biology of inert viruses or parasites that don't materially cause damages, but their lifecycle depends on the host. Although to some extent, by competing for resources they always cause SOME damage, but it is important to notice that not all viruses or damages are highly damaging, that's a rare situation of very extreme pathogens, it isn't very beneficial to kill or damage your host. In fact many may be commensal, but there is a tendency to harm.

In conclusion, I think tailwind and such pre-ai slop-deps are more popular because they are inert viral parasites rather than because they provide value.

Re: Shopify acquires Tailwind

#375

Earlier quoted context omitted.

I don't really get this argument. 90% of Tailwind is shorthand for existing CSS properties. There's really not much to learn if you already know CSS.

Except for all those specific shorthands? I used it for months at s previous job and spent a lot of time googling “how do I write X CSS property in Tailwind”

I’m not sure what to tell you. With only a few exceptions, the shorthand follows a very predictable pattern if you already know the property names. IDE completions help too.

Re: Shopify acquires Tailwind

#376
post #42

Serious question: is there a need to reach for tailwind if you are building a new site? Won't using vanilla CSS while taking advantage of the latest features be pretty good, since humans are not manually making edits (which removes many of the pain points of maintaining CSS), while simplifying dependency and the build pipeline?

If it's the case that there's almost never the need to reach for it, and I do find myself in that camp, then a harder question is begged, why is it so popular? I think there's a lot of technologies that are in the category of categoric mistakes to use, but popular enough and inert enough that they don't get dropped. There might be lots of different explanations depending on the technology, a lot have a reason the mom…

I tend to agree. Software development history is a long saga of things that are bad and still popular. Think of how popular J2EE, XML, and SOAP were at some point, and they're just miserable to use or maintain.

Re: Shopify acquires Tailwind

#378
post #86

Earlier quoted context omitted.

This is a good discussion: do LLMs change the calculus for DRY? A major point of components is having a single place where you can change design and behavior across your entire codebase. With LLMs you can with very good accuracy tell them to change the look of "all buttons that are confirmation buttons in modals but not in the login modal". Doesn't matter if there are 10 such buttons or 1000, it'll take a few seconds…

LLMs change the calculus on DRY in some cases. I would say it's still very much a no-no on the frontend side of things. Code repetition is directly correlated with bad loading performance. When you're optimising for people on slow mobile connections, your HTML/JS/CSS being 500KB instead of 1.5MB matters a lot.

That only matters in context: if this repetition allows you to forego React and a zillion JS libraries you’re better off in the end performance wise.

I have never seen a single website where performance downgrade was caused by HTML.

However I’m not advocating for it, just making the case that it’s very hard to do worse than we’re currently doing with front end development.

Re: Shopify acquires Tailwind

#379
post #79

Earlier quoted context omitted.

I don't agree with "nor should it be" - the market decided it was clearly needed. And this isn't unique to Tailwind. For decades, companies in many ecosystems (like .NET, JS, etc) have made lots of money selling component libraries that save developers and companies a lot of time. And I even bought UI.sh in April, and it really was great until the models just natively got much better. I happily paid for Tailwind UI b…

Hey do you have any opinion on the current utility of ui.sh? I wanted to buy it but I'm a bit wary of it just not being useful and they don't have a preview of a single skill.

Wait, you’re thinking about buying “skills” instead of actual components that you can just use? This seems insane to me.

Re: Shopify acquires Tailwind

#380
post #86

Earlier quoted context omitted.

This is a good discussion: do LLMs change the calculus for DRY? A major point of components is having a single place where you can change design and behavior across your entire codebase. With LLMs you can with very good accuracy tell them to change the look of "all buttons that are confirmation buttons in modals but not in the login modal". Doesn't matter if there are 10 such buttons or 1000, it'll take a few seconds…

> do LLMs change the calculus for DRY? Yes it makes it insanely easy to refactor duplicated logic into shared and tested modules. Why would you go the other way?

Components as in React, Vue, etc requires a complete overhaul in frontend rendering, many dependencies, changes in deployment and even have an impact in organizational structure.

If one wants to do server side rendering with HTML templates like the old days there is no real “components” way of doing it (although declarative Shadow DOM is coming along). Partials are not the same thing.

In that scenario some repetition can give you the benefit of keeping a clean stack with no client side rendering.

Post reply on HN